Accessで実現する外部パートナーとの安全迅速な協業体制

Webサイトの制作やデジタルマーケティングの施策は、社内メンバーだけで完結することはほとんどありません。広告代理店、Web制作会社、システムベンダー、外部ライター、その他のフリーランスなど、プロジェクトごとに多くの外部パートナーが関わるのが普通です。

その際、毎回のように手間と時間がかかるのが、「プレビュー環境」や「CMS管理画面」などへのアクセス権限の付与と管理です。公開前のサイトは見せたいし、CMSで記事を入稿してもらいたい。しかし、そのプロジェクトとは関係のない社内システムや、他のデータまで見えてしまうのは問題です。

そのたびにBasic認証の共通パスワードを設定して共有したり、個別のVPNアカウントを作成したりするのは手間がかかります。またプロジェクト終了後に、そうしたアカウントや権限を消し忘れる、という危険も伴います。こうしたアクセス管理の非効率さは、プロジェクトをスタートさせるまでの準備に要する時間を長引かせるだけでなく、セキュリティ上のリスクともなっているのです。

この節で取り上げる「Cloudflare Access」は、Zero Trustの考え方に基づき、外部パートナーとの協業において、必要な人に、必要なアプリだけを、安全かつ迅速に公開するためのアクセス管理基盤です。

外部パートナーが増えると「共通パスワード」と「VPN」による管理では無理が出る

複数の外部パートナーが関わるプロジェクトにおいては、アクセスを許可したい範囲がメンバーによって異なります。たとえば、以下のような分類が考えられます。

• Web制作会社： 公開前のプレビュー環境や検証サーバーへのアクセス
• 外部ライター： CMSの記事投稿、編集画面へのアクセス
• 広告代理店： キャンペーン管理画面やアクセス解析ダッシュボードへのアクセス

このように、個人ごとに異なるアクセス権を付与したいにも関わらず、実際の現場では、以下のような運用が常態化しがちです。

• Basic認証の共通パスワードを関係者全員にメールやチャットで共有する
• 社外メンバー全員にそれぞれVPNアカウントを発行する

共通パスワードによる運用では、実際は誰がアクセスしたのかをログから判断することが難しく、担当者がプロジェクトを離れた後も、全員に共通のパスワードはそのまま残ってしまいます。かといってパスワードを変更すれば、今度は現在関わっている全員に対して、新たなパスワードを再び通知する手間が発生します。

一方、VPNアカウントを発行する運用では、IT担当者の個別設定作業が必要となり、開通まで数日待たされることも稀ではないでしょう。また、外部パートナーを社内ネットワーク全体へ迎え入れてしまうという過剰な権限付与のリスクを抱え込むことにもなります。

アクセス管理で重要なのは、単に「入れるか、入れないか」の二者択一ではありません。「誰が、どのアプリに、どんな条件で、いつまでアクセスできるのか」をスマートに制御することが肝要です。共通パスワードや個別VPNアクセスでは、その要件を満たさないのは明らかでしょう。

Cloudflare Accessはアプリの入口で本人を確認する

Cloudflare Accessは、ユーザーと、CMSやプレビュー環境といった対象のWebアプリケーションの間に入り、アクセスしてよい人物かどうかを事前に判定するゲートキーパー（門番）の役割を果たします。

ユーザーが対象のURLにアクセスしようとすると、まずCloudflare Accessが本人確認を要求し、あらかじめ設定された条件（ポリシールール）を満たした人だけを、その先のアプリへ通します。

確認・判定に使用できる条件には、以下のようなものがあります。

• メールアドレス、メールドメイン（例： 「@partner-company.com」）
• IdP（認証基盤）のグループ、属性（Google Workspace、Microsoft Entra ID、Okta等）
• 接続元国、IPアドレスやデバイスのセキュリティ状態

自社社員は社内の認証基盤（Google Workspace等）で全ツールへアクセスできる一方、制作会社は「プレビュー環境のURL」だけ、ライターは「CMSのログイン画面」だけを開けるようにする、といった制御が簡単に実現できます。

利用者を社内ネットワーク全体へ接続させるVPNとは異なり、業務に必要なアプリの入口だけを開くというZTNAの思想を、Web制作やマーケティング現場への対応に応用したのがCloudflare Accessなのです。

出典： Cloudflare Docs: Cloudflare Access

出典： Cloudflare Docs: ZTNA

「URLを公開してないから大丈夫」という隠蔽型管理からの脱却

マーケティングやWeb制作の現場で、Cloudflare Accessの価値が最も効果的かつ分かりやすく発揮されるのが公開前のプレビュー環境の保護です。

新商品のキャンペーンページやブランドサイトの改修時、本番公開前の社内関係者や制作会社との確認作業を考えてみましょう。その際、「検索エンジンにインデックスされていない未公開の複雑なURLだから大丈夫」と、何の認証もかけずにアクセス可能にしているケースが少なくありません。

しかし、公開前のサイトには、未発表の商品画像や価格、プロモーション計画、プレスリリース案など、競合他社や外部に漏れてはならない重要情報が詰まっています。URLを隠しているだけの状態は、鍵をかけずにドアを閉めているのと同じようなものであり、セキュリティ的に安全とは言えません。URLが検索結果に出なくても、インターネット上に公開されている以上、第三者がアクセスする可能性は残ります。

そこにCloudflare Accessを設定すれば、URLを知っているだけではページを表示できなくなります。あらかじめ許可されたメールアドレスやアカウントで認証を通過したユーザーだけが画面を閲覧できるようになるのです。

隠して守るのではなく、正当なユーザーを入口で確認して通す、という構成へ切り替えることで、公開前資産の漏洩リスクを確実に防ぐことができます。

自社アカウントを発行せずに安全に認証する

外部パートナーとの協業において、ごく一部の機能に対するアクセスのためだけに社内アカウント（Google WorkspaceやMicrosoft Entra ID等）を発行するのは避けたい、と考えるのは当然でしょう。アカウントの発行数に応じてライセンス費用がかさむ上、ID管理の手間も増えるからです。

Cloudflare Accessでは、自社のIdP連携に加え、「ワンタイムPIN（PINコード認証）」によるフレキシブルな認証方式が利用できます。

• 自社社員： 既存のGoogle WorkspaceやMicrosoft Entra IDでログイン
• 外部パートナー： 許可されたメールアドレスへ届く「6桁のワンタイムPIN」でログイン

外部パートナーに自社アカウントを新規発行することなく、相手の普段のメールアドレスを指定するだけで、安全な本人確認とアクセス許可が完了します。

また、プロジェクトの期間に合わせてアクセス権限を都度申請、時限承認する機能（Temporary authentication）などを活用することで、プロジェクト期間中だけアクセスを許諾し、終了後は自動的に遮断する、といった運用も容易になります。

アカウント管理の手間を排除しつつ、許可された本人しか通さない、という強固なアクセス制御を両立できる点が、Cloudflare Accessの大きなメリットです。

出典： Cloudflare Docs: IdP integration

出典： Cloudflare Docs: One-time PIN login

いきなり全体に適用するのではなく、特定のプレビュー環境からスモールスタートする

Cloudflare Accessの導入にあたって、社内の全アクセス環境を一気に変更する必要はありません。実際の導入では、以下のような段階的なスモールスタートが推奨されます。

1. まずは外部パートナーと共有する「特定のプレビュー環境」だけにAccessを適用する
2. 効果や操作感を確認し、「CMS管理画面」や「検証サーバー」へ対象を拡大する
3. 社内向けのWebツールや管理画面の保護へ、順次適用を拡大する

CloudflareのZero Trustプランには、50ユーザー未満のチームやPoC（概念実証）向けに無料で利用できるFree Planの枠も用意されているため（2026年9月現在）、最初から大がかりな予算取りや全社ネットワークの変更を考えず、目の前にある現場の課題解決から即座にテスト、導入を始めることができます。

出典： Cloudflare Docs: Zero Trust plans

DOMOの視点

Cloudflare Access導入の前に、外部パートナーとの協業ルールを整理する

DOMOとしてCloudflare Accessの導入を検討する際に最初に整理すべきと考えるのは、誰がどの環境に入り、どこまで権限を持ち、いつまでアクセスできるのかという協業の運用ルールです。

特に制作会社や広告代理店など、外部パートナーが関わるプロジェクトでは、開始時には数人だったメンバーが途中から増えたり、パートナー企業側で担当者が入れ替わったりすることが日常的に起こります。

共有パスワードやVPNアカウントの場当たり的な発行を重ねるのではなく、以下のようなライフサイクルをあらかじめ定義しておくことが重要です。

1. アクセス対象を絞る： この会社にはプレビュー環境のみ、このライターにはCMSのみと限定する
2. 即座に参加させる： ワンタイムPINや既存IdP連携で、初日から作業を開始できる環境を提供する
3. 確実に権限を消す： プロジェクト終了時や契約満了時に、自動的かつ確実にアクセスを閉じる

Cloudflare Accessの本当の価値は、単にセキュリティを厳しくすることではありません。「プロジェクトの立ち上げスピードを上げ、必要な人をすぐ参加させ、終わったら安全に退出させる」という一連の協業プロセスをシンプルに整えることにあると考えます。

まとめ

Cloudflare Accessは、社内システムやWebアプリの入口で本人確認を行い、許可されたユーザーだけを必要な環境へ通すZTNA（Zero Trust Network Access）サービスです。以下のような効果を発揮します。

• 「共有パスワード」や「全社VPN」からの脱却： アプリ単位で必要な人にだけアクセス権限を付与し、過剰な権限共有や不透明なアクセスを排除
• 公開前資産と管理画面の保護： URL隠しに頼っていたプレビュー環境やCMS管理画面に対して、ワンタイムPINや既存IdP連携による確実な本人確認を導入
• スモールスタートで協業スピードを上げる： プレビュー環境1つから段階的に導入でき、外部パートナーの参加待ち時間を大幅に短縮

外部パートナーとのアクセス管理に時間を取られているようなら、プレビュー環境や管理画面の整理から始め、Cloudflare Accessの導入を検討するとよいでしょう。

覚えておきたい用語

• Cloudflare Access： ユーザーを認証し、許可されたアプリへのアクセスを制御するCloudflareのZTNAサービス
• ZTNA： Zero Trustの考え方に基づき、必要なアプリへのアクセスだけを許可する仕組み
• IdP： ユーザーの本人確認を行う認証基盤
• アクセスポリシー： 誰が、どの条件で、どのアプリへアクセスできるかを定めたルール
• ワンタイムPIN： 一度だけ利用できる認証コードを使って本人確認する方法
• Basic認証： ユーザー名とパスワードでWebページへのアクセスを制限する仕組み
• プレビュー環境： Webサイトを一般公開する前に、関係者が確認や検証を行うための環境
• PoC： 本格導入の前に、小さな範囲で効果や実現性を確認する検証