Cloudflare Access（ゼロトラスト）

解決する課題

• 社内アプリにアクセスするたびにVPNクライアントの接続・管理・障害対応が発生し、運用負荷が高い
• VPNは一度接続するとネットワーク全体が信頼領域になり、侵害時の被害が水平展開しやすい
• 社外パートナーや個人デバイスに社内ネットワークそのものを開放したくない
• リモートワークの拡大で「社内だから安全」という前提が崩れ、社内外を区別しないアクセス制御が必要
• SSHやRDPなどレガシーなプロトコルへの接続もID連携した形で統制したい

主要概念と用語

• Cloudflare Access: アプリケーションやネットワーク資源への接続を、リクエストごとにID・デバイス条件で検証し認可するゼロトラストアクセス制御サービス。Cloudflare Oneの構成要素の1つ
• アプリケーション（Application）: Accessで保護する対象の単位。SaaS・セルフホストWebアプリ・SSH／RDPなど任意のホスト名やプライベートネットワーク範囲を登録する
• Accessポリシー（Access Policy）: 「誰が」「どの条件で」アプリへ許可／ブロック／バイパスされるかを定義する規則。IDプロバイダのグループ、国、デバイスの姿勢（posture）などを組み合わせられる
• アイデンティティプロバイダ（Identity Provider, IdP）: OktaやAzure ADなど既存のSSO基盤と連携し、認証結果をAccessの判定材料にする仕組み
• デバイスポスチャ（Device Posture）: 証明書の有無、ディスク暗号化、OSバージョンなど、接続元デバイスの状態を確認するチェック
• WARPクライアント: エンドポイントにインストールするエージェント。プライベートネットワーク上のアプリやSSH／RDPをブラウザなしで保護する際に用いる
• Access for SaaS: サードパーティSaaSアプリの前段にAccessのSSOレイヤーを挟み、追加の認可条件を課す構成
• Service Token: 人間のログインを介さない、サービス間通信（CI/CDなど）向けの認証情報

仕様・制限・クォータ

• AccessはCloudflareのグローバルネットワーク上で動作し、専用のVPNゲートウェイやアプライアンスを自前で構築する必要がない
• 保護対象はブラウザベースのWebアプリから、WARPクライアント経由の**プライベートネットワーク（SSH／RDP／任意のTCP）**まで幅広く対応する
• ポリシーはユーザー・グループ・国・IPレンジ・デバイスポスチャなど複数条件のAND／OR組み合わせで記述できる
• 主要なIdP（SAML／OIDC対応のプロバイダ）と連携でき、Cloudflareの組み込みワンタイムPIN認証も利用できる
• アプリ数・ポリシー数・同時セッション数などの具体的な上限はプランによって異なるため、契約中のプランとダッシュボードの表示に従う
• セッション有効期間（再認証を求める間隔）はポリシー側で調整可能

内部の仕組み

Accessで保護したアプリへリクエストが届くと、Cloudflareのエッジはまずユーザーが有効な認証セッションを持っているかを確認します。持っていなければ、設定したIDプロバイダのログイン画面へリダイレクトし、認証が成功するとCloudflareが署名付きのトークンを発行します。

このトークンには、ユーザーの識別情報に加えて、必要であればデバイスポスチャの検証結果が含まれます。エッジはリクエストのたびにトークンとAccessポリシーを照合し、許可条件（特定のメールドメイン、グループ、国、デバイス状態など）を満たしているかを判定します。条件を満たさなければ、たとえログイン自体は成功していてもアクセスはブロックされます。

Webアプリ以外の保護にはWARPクライアントを使います。エンドポイントにインストールされたWARPは、SSHやRDPなど任意のプライベートネットワーク宛の接続もCloudflareのエッジを経由させ、同じAccessポリシーエンジンで認可判定を行います。これにより、ブラウザ経由のSaaS・セルフホストアプリと、非HTTPプロトコルへの接続を同一のポリシー言語で統制できます。

設計パターン / ベストプラクティス

• 既存のIdP・グループ構造をそのまま利用し、Access側で二重にユーザー管理をしないようにする
• ポリシーは最小権限を原則にし、部署やプロジェクト単位のグループで許可範囲を絞る
• 機密度の高いアプリにはデバイスポスチャチェックを追加し、未管理デバイスからのアクセスを制限する
• 人間のログインを伴わないCI/CDや自動化にはService Tokenを発行し、個人アカウントの認証情報を使い回さない
• SSH／RDPなど非HTTPの資産はWARPクライアント＋プライベートネットワークの構成で統一的に保護する
• 段階導入では、まず監査（ログのみ）モードやバイパスなしの緩いポリシーで動作確認してから制限を強める

運用・監視

• Access監査ログでログイン試行・許可／ブロックの判定結果を記録し、誰がいつどのアプリにアクセスしたかを追跡する
• ポリシー変更やアプリ設定の変更はCloudflareのアカウント監査ログで確認できる
• ログイン失敗や異常なアクセスパターンは、SIEM連携やログ転送先で継続的に監視する
• アクセスできないという問い合わせが来た場合は、IdP側の認証結果、Accessポリシーの条件、デバイスポスチャの順に切り分ける
• IdPのグループ変更が反映されるまでのタイムラグを考慮し、権限変更後は反映状況を確認する

コスト

セキュリティ

• 暗黙の信頼を置かないゼロトラストの原則を、社内・社外を区別せず全接続に適用する
• IDだけでなく**デバイスの状態（証明書、暗号化、OSバージョンなど）**を認可条件に含め、侵害端末からのアクセスを抑止する
• 最小権限のポリシーにより、侵害されたアカウント1件が及ぼす被害範囲を限定する
• Service Tokenや管理者権限は定期的にローテーション・棚卸しし、不要な認証情報を残さない
• 監査ログを外部のログ管理基盤へ転送し、改ざん耐性のある形で保持する
• Cloudflare Gateway・DLPなど他のCloudflare Oneコンポーネントと組み合わせ、認可後の通信内容の検査も行う多層防御を構成する

関連サービス・比較

Cloudflare Accessは、通信内容の検査を担うCloudflare Gatewayや、エンドポイントの経路を作るWARPクライアントとセットでCloudflare Oneを構成します。AWSでは同様の考え方を持つVerified Accessが近い位置づけです。

ハンズオン / CLI例

Cloudflare Accessの設定は主にダッシュボードやTerraformで行いますが、wranglerが利用するCloudflare APIトークンの認証確認と、APIによるアプリケーション作成の一例を示します。

# wrangler経由でCloudflare APIトークンの有効性を確認
wrangler whoami

# 保護対象アプリケーション（Self-hosted）を作成
curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/access/apps" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "internal-dashboard",
    "domain": "dashboard.example.com",
    "type": "self_hosted",
    "session_duration": "24h"
  }'

# 作成したアプリにAccessポリシー（特定グループのみ許可）を追加
curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/access/apps/${APP_ID}/policies" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "allow-engineering-group",
    "decision": "allow",
    "include": [
      { "group": { "id": "engineering-group-id-xxxx" } }
    ]
  }'

# 登録済みAccessアプリケーションの一覧を確認
curl -X GET "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/access/apps" \
  -H "Authorization: Bearer ${CF_API_TOKEN}"