Cloudflare Zero Trustの導入手順｜AccessとTunnelで社内Webアプリを安全に公開する
社内Webアプリをインターネットへ公開する際、IP制限や共通パスワードだけでは、在宅勤務、モバイル回線、委託先、クラウド環境の変化に追従しにくくなります。Cloudflare Zero Trustでは、Cloudflare Accessで利用者や端末の条件を確認し、Cloudflare Tunnelでオリジンから外向きの接続を作れます。
ただし、VPNを置き換えるという説明だけで導入すると、IdP障害時のロックアウト、サービス間通信の停止、管理者経路の消失が起こり得ます。対象アプリ、認証方式、緊急アクセス、ログ、責任者を先に決めます。
社内WebアプリをCloudflare Zero Trustで保護する基本構成は、オリジンからCloudflare Tunnelを張り、Accessアプリケーションを登録し、IdPのグループや端末条件で許可ポリシーを設定する方法です。人とサービスの認証を分け、緊急経路を用意します。
本記事のポイント
- Tunnelはオリジン側から外向き接続を作り、Accessは利用者・端末・サービスの認証条件を適用します。
- まず少人数・低リスクの社内アプリで検証し、IdP障害や管理者ロックアウト時の緊急経路を用意します。
- 人のアクセスとサービス間通信を分け、最小権限、ログ、期限付き例外で運用します。
この記事で分かること
| 確認対象 | 見る内容 | 判断のポイント |
|---|---|---|
| Cloudflare Tunnel | オリジンから外向き接続 | 公開IP・受信ポートを減らす |
| Cloudflare Access | ID・グループ・端末等で認証認可 | アプリ単位の最小権限 |
| IdP | Google/Microsoft/Okta等の本人情報 | 既存アカウント管理と連携 |
| Service token | 人ではない自動処理 | API・監視・ジョブを分離 |
| ログ・復旧 | 許可・拒否・設定変更 | 監査とロックアウト対応 |
対象アプリと利用者を棚卸しする
社内管理画面、ダッシュボード、検証環境、ファイル管理、運用ツールなど、現在公開されているアプリを一覧化します。利用者、管理者、委託先、サービスアカウント、接続元、利用時間、機密度を記録します。
最初から基幹システム全体へ適用せず、停止時の影響が限定的で、HTTP/HTTPSで提供されるアプリから検証します。DNS、証明書、オリジン到達性、既存認証も確認します。
Tunnelをオリジン側から接続する
cloudflaredなどのコネクタをオリジン環境へ配置し、Cloudflareネットワークへ外向き接続を作ります。公開ホスト名と内部サービスを対応させ、コネクタ停止時の冗長性と自動再起動を設計します。
Tunnelを作っただけでオリジンが自動的に非公開になるとは限りません。既存の公開IPや受信ポートが残っていれば直接接続されるため、動作確認後にファイアウォールとDNSを見直します。
Accessアプリとポリシーを設定する
Accessへ対象ホスト名を登録し、許可・拒否・バイパス条件を設定します。IdPのグループ、メールドメイン、端末姿勢、国、認証方式などを組み合わせ、業務上必要な人だけに許可します。
管理者全員を一つの条件へ依存させると、IdP設定ミスで全員が締め出されることがあります。少人数の検証グループ、段階拡大、設定レビュー、緊急時の承認済み経路を用意します。
人とサービスのアクセスを分ける
監視、CI/CD、Webhook、バッチなどはブラウザでIdPログインできません。人向けの認証をバイパスするのではなく、Service tokenやmTLSなど、サービス専用の認証方式を検討します。
トークンは秘密情報として所有者、利用先、期限、ローテーション、失効手順を管理します。APIキーの運用は、APIキーの棚卸し・ローテーション手順も参考になります。
ログ、障害、緊急アクセスを検証する
許可・拒否ログ、IdPイベント、Tunnelコネクタ状態、オリジンログを関連付けます。誰がいつどのアプリへ接続し、どの条件で拒否されたかを確認できる状態にします。
Cloudflare、IdP、DNS、オリジンのいずれかが止まった場合を想定し、管理者が状況を確認できる独立経路、復旧手順、連絡先を用意します。緊急例外は常設せず、承認、期限、利用ログを必須にします。
本番導入で必要な変更管理と評価方法
Cloudflareの設定は通信経路の手前で効くため、小さな変更でも複数ページや外部連携へ影響します。開発・検証環境で再現できるものは先に試し、本番では対象ホスト、パス、利用者、時間帯を限定して段階反映します。変更票には目的、変更前後、実施者、承認者、確認URL、期待結果、切り戻し条件を残します。
確認は「画面が開くか」だけで終えません。HTTPステータス、レスポンスヘッダー、認証、フォームやAPIの完了、オリジンログ、Cloudflareイベントを同じ時刻で照合します。正常系だけでなく、権限なし、期限切れ、過剰アクセス、外部API停止、再送などの異常系も試し、利用者へ返すエラーと運用担当者が見る証拠を分けます。
導入効果は、表示速度やブロック件数など一つの数値だけで評価しません。可用性、正常完了率、オリジン負荷、エラー率、誤検知、サポート問い合わせ、変更作業時間、月額・従量費を導入前後で比較します。性能が上がっても問い合わせやログインの失敗が増えていれば、事業成果としては改善していません。
料金と上限は利用プランや使用量で変わります。無料枠や小規模検証の結果をそのまま本番へ外挿せず、ピーク時のリクエスト、保存・操作、ログ量、利用者数、サポート、監査要件を公式料金ページと契約条件で確認します。上限へ近づいたときの通知と、機能を縮退させる順序も決めます。
設定の所有者と定期レビュー日を決め、不要なルール、トークン、例外、接続先を残しません。Cloudflare画面だけでなく、設定のエクスポート、コード、変更履歴、復旧手順をチームで参照できる場所へ保管します。担当者の退職や委託先変更があっても、誰が承認し、どこまで戻せるか分かる状態を維持します。
公開後は一週間程度の観測期間を設け、導入前と同じ時間帯・同じURL・同じ業務操作で比較します。異常がなくても、例外が増え続けていないか、想定外の回避策が現場で使われていないかを確認します。問題が見つかった場合は、影響を受けた利用者とデータを特定し、暫定回避と恒久修正を分けて記録します。
また、Cloudflare以外の構成要素を含む依存関係図を残します。DNS、レジストラ、オリジン、IdP、メール、外部API、監視、CI/CDのどこで設定が重複し、どこが単一障害点になるかを明示します。障害時に別サービスの担当者へ連絡すべき条件も決めておくと、Cloudflare側だけを調べ続ける時間を減らせます。
本番の設定変更は、可能ならAPIやInfrastructure as Codeで再現可能にし、画面で行った緊急変更も後から正本へ戻します。秘密情報は設定ファイルへ直接書かず、環境ごとのSecret管理へ分離します。手作業とコードの状態がずれると、次回デプロイで緊急修正が消えるため、復旧後の同期までをインシデント対応に含めます。
公開・変更前チェックリスト
- 対象アプリ・利用者・機密度を一覧化した
- 低リスクの検証対象を選んだ
- Tunnelコネクタを冗長化した
- 既存の公開IP・受信ポートを見直した
- IdPグループとAccessポリシーを最小権限にした
- サービス用認証を人と分けた
- IdP障害・管理者ロックアウトの復旧手順を確認した
よくある質問
Cloudflare Tunnelを使えばVPNは不要ですか？
Webアプリ単位のアクセスでは代替できる場合がありますが、ネットワーク全体や非HTTP通信の要件は別に評価します。
TunnelはオリジンIPを完全に隠しますか？
新しい接続は公開IPを不要にできますが、過去のDNS記録や残った公開ポートがあれば直接接続される可能性があります。
Google Workspaceのグループで許可できますか？
対応するIdP連携と属性・グループ情報を使える構成があります。実際に渡される属性と同期遅延を検証します。
サービスアカウントはどう接続しますか？
Service tokenなどの機械向け認証を使い、人向けのログインバイパスと分けます。秘密情報の期限とローテーションを管理します。
関連ページと関連記事
仕様確認に使った公式情報
Cloudflareの機能、プラン、上限、画面構成は更新されます。実装時は利用する機能の最新公式ドキュメントも確認してください。
まとめ
Cloudflare AccessとTunnelを使い、公開ポートを減らしながらIDベースで社内アプリへのアクセスを制御する実務ガイドです。 設定を有効にしただけで完了とせず、正常系・異常系・切り戻しを同じ手順で確認することが、安全な運用につながります。
