社内ツール・管理画面をVPNなしで守る｜Cloudflare Accessによるゼロトラスト構成

内製AIツールが増えると、何が起きるのか？

URLを知っていれば誰でも入れる検証環境、退職者に残ったアクセス、監査で説明できない権限管理という3つのリスクが積み上がる。

生成AIの普及で、社内チャット、検証用ダッシュボード、部門ごとの管理画面といった内製ツールが急に増えている。エンジニアでなくても、低コードのツールや生成AI自体を使って1日で動くものを作れるようになったことが大きい。作るのが速くなった分、公開の仕方は後回しになりやすい。多くの現場でよく見る積み上がり方は、次の3つに整理できる。

1. URLを知っていれば誰でも入れる。「社外秘のつもりだが、URLさえ知っていれば外部からでも開ける」状態のまま、検証環境が本番相当のデータを扱い始める。Basic認証を掛けていても、パスワードは共有チャットに貼られて使い回され、退職者にも残ったままになりやすい。
2. 退職者のアクセスが残る。ツールごとに個別アカウントを発行する運用だと、退職・異動のたびに削除する対象も個別になる。人事の退職手続きと、内製ツールのアカウント削除が別の作業として存在する限り、どこかで抜け落ちる。
3. 監査で説明できない。情シス審査やセキュリティ監査で「誰が、いつ、何にアクセスできるか」を一覧で求められたとき、IPアドレス制限やBasic認証だけでは「誰が」に当たる記録が残っていない。ツールの数だけ、この問いに答えられない状態が積み上がる。

VPNとゼロトラストは、何が違うのか？

VPNは接続時に一度だけ判定し、ゼロトラストはリクエストのたびに人を確認する。

内製ツールが増えたときの典型的な対応が「VPNを増やす」または「既存VPNの対象を広げる」ことだ。だが、この対応はツールが増えるほど無理が出てくる。VPNの設計は、接続を許可した時点で社内ネットワークのかなり広い範囲に届いてしまう「性善説」に近い。一度つながれば、あとはネットワークの中でどこまで見えるかという話になり、アプリ単位での本人確認は行われない。ツールが1つや2つならVPNのアカウント管理でも回るが、内製ツールが10、20と増えるにつれて、申請・発行・失効のやり取りだけで情シスの工数が埋まっていく。

これに対してゼロトラストは、判定のタイミングをネットワークへの入り口からリクエスト1つひとつへ移す考え方だ。米国NIST（国立標準技術研究所）が2020年8月に公表した『Zero Trust Architecture』（NIST Special Publication 800-207、Rose, S., Borchert, O., Mitchell, S., Connelly, S.著）は、静的なネットワーク境界を守るのではなく、ユーザー・資産・リソースそれぞれを個別に守る考え方としてゼロトラストを整理している。実務の言葉に置き換えると、VPNは「建物の入口で鍵を1回確認する」設計であるのに対し、ゼロトラストは「部屋の扉ごとに、開けるたびにIDを提示してもらう」設計に近い。

表からも分かる通り、ゼロトラストへの置き換えは「VPNをやめる」というより「判定の粒度を細かくする」ことに近い。次の章では、この考え方を実装するCloudflare Accessが具体的に何をしてくれるのかを見ていく。

Cloudflare Accessは、何をしてくれるのか？

IdP連携・ポリシー・Service Token・セッション期間・監査ログの5つで、社内ツールへのアクセスを人単位で制御・記録できる。

Cloudflare Accessは、Cloudflareが提供するSASE（Secure Access Service Edge）プラットフォーム「Cloudflare One」（Cloudflare Zero Trustとも呼ばれる）の中で、Zero Trust Network Access（ZTNA）を担う製品だ。公式ドキュメントでは、すべてのリクエストをアイデンティティとコンテキストに基づいて認証・認可したうえでアクセスを許可する仕組みとして説明されている。本稿の機能記述は、2026年8月時点のCloudflare公式ドキュメント（developers.cloudflare.com）および公式ブログ（blog.cloudflare.com）に基づく。

実務で押さえておきたいのは、次の5つの機能だ。

図：Accessポリシーの設定イメージ。IdPのグループ情報をそのままInclude条件に使うため、新しい権限台帳を作らずに済む。

ポリシーはIdP側のグループ情報をそのまま条件に使えるので、Access専用の権限台帳を新しく作る必要がない。社内IdPのグループ管理さえ運用できていれば、Access側は「そのグループを許可する」というルールを1本足すだけで済む。

導入は、実際どう進めるのか？

既存アプリに手を入れずに前段で守り、社内IdPと接続し、検証環境から始めて型を広げていく。

Cloudflare Accessの導入で最初につまずきやすいのは、「対象のアプリを改修しないといけないのでは」という思い込みだ。実際には、多くの場合アプリ側のコードには一切触れない。

既存アプリに手を入れずに前段で守る。Cloudflare Tunnelは、cloudflaredという常駐プロセスがアプリの動くサーバーからCloudflareへ向けて送信のみの接続を確立する仕組みで、公開用の固定IPを持たず、ファイアウォールでインバウンドポートを一切開けずに社外公開できる。今動いている検証用ダッシュボードや社内チャットのURLは変えずに、その手前にAccessの認証を挟むだけでよい。

社内IdPとの接続。既にGoogle WorkspaceやMicrosoft Entra ID（Azure AD）を使っているなら、新しいアカウント台帳を作らずそのままAccessに接続できる。退職・異動の処理は、人事や情シスが主IdP側のグループを更新する一手間で、Access側の権限にも反映される設計にしておく。

検証環境から始める。全社の内製ツールを一度に囲おうとすると、影響範囲の大きいツールから着手してしまい、関係部署の調整だけで止まる。最もリスクの高いツール——個人情報を扱う検証環境や、管理者権限を持つ社内チャットの管理画面など——を1つ選び、IdP接続とポリシー1本で動作確認する小さいループを先に回す。1本通った型は、次のツールへそのまま複製できる。

よくある失敗は、何か？

バイパス経路の残存、API・Webhookの締め出し、退去プロセスとの非連動が典型的な失敗になる。

Cloudflare Accessを前段に置いても、次の3つを設計しないままだと、ゼロトラスト化したつもりで穴が残る。

バイパス経路が残る。Access導入前のURLやオリジンのIPアドレスに直接到達できる経路が残っていると、Accessを迂回してそのまま入れてしまう。Cloudflare Tunnelでオリジンへの接続をアウトバウンドのみに変え、直接到達できる経路そのものを塞いでおく必要がある。

APIやWebhookを閉め出す。人のログインだけを前提にポリシーを組むと、外部SaaSからのWebhookや監視ツールのAPI呼び出しまで一緒にブロックしてしまう。Service Tokenで機械アクセス用の経路を人間のログインとは別に用意しておけば、この事故は避けられる。

退去プロセスと連動していない。社内IdP側でアカウントを無効化しても、Access側に残った例外ポリシーや、期限を長く切ったService Tokenはそのまま有効であり続ける。退職・異動のチェックリストに、Accessのポリシーとservice tokenの棚卸しを組み込んでおく必要がある。

よくある質問