社内ツール・管理画面を、VPNなしで守るにはどうすればよいですか？
Cloudflare Accessをアプリの前段へ置き、利用者と条件を確認します。オリジンへの直結経路と、既存セッションの失効も検査します。
生成AIの普及で、社内チャット、検証用ダッシュボード、部門ごとの管理画面といった内製ツールが増えています。短い試作で動くツールを作れるため、公開の仕方は後回しになりやすくなります。
内製ツールが増えるときに想定する失敗は、次の3つです。
- URLを知っていれば誰でも入れます。「社外秘のつもりだが、URLさえ知っていれば外部からでも開ける」状態のまま、検証環境が本番相当のデータを扱い始めます。Basic認証を掛けていても、パスワードは共有チャットに貼られて使い回されます。退職者にも残ったままになりやすくなります。
- 退職者のアクセスが残ります。ツールごとに個別アカウントを発行する運用だと、削除する対象も個別になります。人事の退職手続きと、内製ツールのアカウント削除が別の作業である限り、どこかで抜け落ちます。
- 監査で説明できません。情シス審査やセキュリティ監査で「誰が、いつ、何にアクセスできるか」を一覧で求められたとします。IPアドレス制限やBasic認証だけでは、「誰が」に当たる記録が残っていません。
根っこは同じです。「ネットワークに入れるかどうか」だけで守っている限り、入った後の一人ひとりを見分ける手段がありません。
典型的な対応は、「VPNを増やす」か、「既存VPNの対象を広げる」ことです。ただ、ツールが増えるほど無理が出ます。従来の構成でVPN接続後に広いネットワークへ届き、アプリごとの認可もない場合は、到達範囲が広がります。VPN製品や構成によって制限は異なります。内製ツールが10、20と増えると、申請・発行・失効のやり取りだけで、情シスの工数が埋まっていきます。
ゼロトラストは、判定のタイミングを、ネットワークの入口からリクエスト1つひとつへ移す考え方です。米国NIST（国立標準技術研究所）が2020年8月に公表した『Zero Trust Architecture』（NIST Special Publication 800-207）は、これを整理しています。守る対象は、静的なネットワーク境界ではありません。ユーザー・資産・リソースそれぞれを個別に守る考え方です。
実務の言葉にすると、ここで比較するVPNは「入口で認証した後、広い範囲へ到達できる」構成です。ゼロトラストは「部屋の扉ごとに、開けるたびにIDを提示してもらう」設計に近くなります。
Cloudflare Accessは、Zero Trust Network Access（ZTNA）を担う製品です。SASE（Secure Access Service Edge）プラットフォーム「Cloudflare One」の一部です。公式ドキュメントは、次の仕組みと説明しています。すべてのリクエストを、アイデンティティとコンテキストに基づいて認証・認可します。本稿の機能記述は、2026年8月時点の公式情報に基づきます。出典は、developers.cloudflare.comとblog.cloudflare.comです。
Cloudflare Accessの導入は、どんな手順で進めますか？
検証環境の1本から始め、IdP連携、自動化の経路の分離、退職・異動の手順との連動、横展開の順に進めます。
最初につまずきやすいのは、「対象のアプリを改修しないといけないのでは」という思い込みです。実際には、多くの場合、アプリ側のコードには触れません。
- リスクの高いツールを1つ選び、前段を作ります。全社の内製ツールを一度に囲おうとすると、関係部署の調整だけで止まります。個人情報を扱う検証環境や、管理者権限を持つ管理画面など、最もリスクの高い1つを選びます。Cloudflare Tunnelは、
cloudflaredという常駐プロセスを使います。このプロセスが、アプリの動くサーバーからCloudflareへ、送信のみの接続を確立します。公開用の固定IPは要りません。ファイアウォールでインバウンドポートを開けずに、社外公開できます。公開するホスト名、DNS、Tunnelの接続先を確認し、その前段にAccessを配置します。既存URLを維持できるかは現在の公開構成によります。 - 社内IdPを接続し、ポリシーを1本作ります。IdP（社内のID基盤）は、Google WorkspaceやMicrosoft Entra ID（Azure AD）、Oktaなどをそのまま接続できます。汎用SAML／OIDCにも対応します。IdPが未整備なら、Cloudflare組み込みのワンタイムPIN（メール認証）も使えます。ポリシーは、「誰が」「どのアプリに」「どんな条件で」アクセスできるかを、アプリ単位でルール化します。まず「情シス部のみ許可」を1本作ります。公開範囲は、アプリごとに分けられます。検証環境は情シスのみ、社内チャットは全社員、といった使い分けです。IdP側のグループ情報をそのまま条件に使えるので、Access専用の権限台帳は要りません。IdPのグループ管理を運用できていれば、Access側は「そのグループを許可する」ルールを1本足すだけです。
- 自動化の経路を、人のログインから分けます。Service Tokenは、人のログインを介さない通信を認証する仕組みです。Client IDとClient Secretを発行します。監視ツールやAPI連携、CI/CDなど、人が操作しない経路を塞がずに残せます。セッション期間も決めます。ログイン後に再認証を求めるまでの有効期間で、アプリごとに設定できます。既定は24時間で、15分から1か月の範囲で調整できます。機微な管理画面ほど短くします。
- 退職・異動の手順とAccessを連動させます。退職・異動のとき、IdP側のグループ更新と、Accessの許可条件を対応させます。既存セッションが直ちに無効になるとは限りません。退職時はセッションの失効を行い、拒否されることまで試験します。退職・異動のチェックリストに、Accessのポリシーとservice tokenの棚卸しを組み込みます。
- 対象を広げ、監査ログを月次で見ます。1本通った型は、次のツールへそのまま複製できます。検証で固めたポリシーを、他の内製ツールや管理画面へ広げます。監査ログは、誰が、いつ、どのアプリに、許可されたか拒否されたかを記録します。月次で確認する運用に乗せます。情シス審査や社内監査で、アクセス権限の一覧をそのまま出せます。
契約前に、対象人数、必要な認証機能、ログ保持期間を現在のプランで確認します。記事の手順は、1つのWebアプリを前段で保護する設計例です。全社ネットワークの移行や、アプリ内部の業務認可を代わりに行うものではありません。
うまくいかない例には、どんなものがありますか？
バイパス経路の残存、API・Webhookの締め出し、退職・異動の手順との非連動、最初から全社ツールを狙うことが典型です。
Accessを前段に置いても、次を設計しないままだと、ゼロトラスト化したつもりで穴が残ります。
- バイパス経路が残ります。Access導入前のURLや、オリジンのIPアドレスに直接到達できる経路が残っていると、Accessを迂回して入れます。Cloudflare Tunnelでオリジンへの接続をアウトバウンドのみに変え、直接到達できる経路そのものを塞ぎます。
- APIやWebhookを閉め出します。人のログインだけを前提にポリシーを組むと、外部SaaSのWebhookや、監視ツールのAPI呼び出しまでブロックします。Service Tokenで、機械アクセス用の経路を別に用意します。
- 退職・異動の手順と連動していません。社内IdP側でアカウントを無効化しても、Access側に残った例外ポリシーは有効です。期限を長く切ったService Tokenも、そのまま有効であり続けます。
- 最初から全社が使うツールを狙います。影響範囲の大きいツールから着手すると、関係部署の調整だけで止まります。
1本のツールを守って終わりにしません。内製ツールが増えるたびに同じ型を複製し、退職・異動の手順や監査と連動させ続けます。それで初めて、「説明できる状態」が維持されます。
VPNとゼロトラストは、何が違いますか？
比較対象は、VPN接続後に広いネットワークへ届く構成と、アプリの前段で認証・認可するAccess構成です。VPN自体の制御能力は製品と設定で異なります。
| 観点 | VPN | ゼロトラスト（Cloudflare Access） |
|---|---|---|
| 判定のタイミング | 接続時の認証が中心の構成 | リクエストのたびに毎回 |
| 接続後の到達範囲 | 社内ネットワーク全体に届くことが多い | 許可されたアプリ単位に限定 |
| 本人確認の粒度 | アプリの別認可がない場合、接続可否が中心 | IdPのID・グループ単位で、誰がアクセスしたかを記録 |
| 退職時の対応 | VPNアカウントの削除を個別に実施 | 社内IdP側の無効化と連動させやすい |
| ログに残るもの | 接続ログ（IPなど）中心 | 誰が・いつ・どのアプリに・許可か拒否かを記録 |
ゼロトラストへの置き換えは、「VPNをやめる」というより、「判定の粒度を細かくする」ことに近い作業です。
よくある質問
無料枠はありますが、対象人数、必要機能、ログ保持期間を現在の公式プランで確認してください。人数上限や保持期間を、過去の紹介値だけで判断しません。退職者調査など長期保存が要る場合は、導入前に条件を照合します。
多くの場合は不要です。Cloudflare Tunnelを使えば、アプリ自体にコードを追加せずに済みます。インバウンドポートも開けずに、前段でAccessを挟めます。既存URL、DNS、既存認証との併用は、現在の構成を確認して決めます。アプリ側で利用者のIDを使う場合は、追加の検証実装が要ることがあります。
Google Workspace、Entra ID（Azure AD）、Oktaなど、主要なIDプロバイダと連携できます。汎用のSAML／OIDCにも対応するため、多くの社内IdPをそのまま接続できます。ID基盤がない小規模チームでも、組み込みのワンタイムPIN（メール認証）から始められます。
人のログインを前提にしたポリシーだけでは、外部からのAPI呼び出しやWebhookまでブロックします。Service Tokenを使えば、自動化された通信専用の認証経路を、別に用意できます。認証は、Client IDとClient Secretで行います。導入時に、人が使うのか、システムが使うのかを、経路ごとに分けて設計します。
次の一歩は何から始めればよいですか？
リスクの高い内製ツールを1つ選び、検証環境として、Accessの前段とポリシー1本を試します。
- 個人情報を扱う検証環境や、管理者権限を持つ管理画面から、1つを選びます。
- Cloudflare Tunnelで前段を作り、社内IdPを接続して、ポリシーを1本作ります。
- 監視ツールやWebhookなど、人が操作しない経路を洗い出し、Service Tokenで分けます。
この記事は、どの資料をもとにしていますか？
2026年10月3日にアプリ保護とセッション管理の公式手順を照合しました。本文は構成の設計例で、導入効果の実測ではありません。料金・人数上限・ログ保持の数値を今回更新済とは扱いません。