Cloudflare Zero Trust 実務ハンズオン: WARP・cloudflared・Access運用ガイド

設計方針と主要コンポーネントの役割

導入で考えるべき設計方針と、主要コンポーネントの役割を整理します。設計は最小権限と可観測性を中心に組み立ててください。

Access（認証・認可）

Access はアプリ単位の認証・認可を担います。IdP 連携とデバイスポスチャーを組み合わせてアクセス制御を実装します。

• 役割：HTTP/S・SSH・TCP のアプリに対する認証・認可。
• 設計ポイント（推奨）：デフォルト拒否、グループベースの許可、MFA 必須、端末条件（managed／端末証明書あり／OSバージョン）を組み合わせる。
• 注意：デバイスポスチャーで利用可能な信号（例：端末がMDMに登録されているか、端末証明書の有無、WARPの組織登録状態など）は環境やバージョンで異なります。ダッシュボードで利用可能な属性名を必ず確認してください。

Named Tunnel（cloudflared）

Named Tunnel はオンプレや個人サーバを Cloudflare に安全に公開します。cloudflared がコネクタになります。

• 役割：origin と Cloudflare 間の安全なトンネル確立。DNS ルーティングでホスト名公開。
• 設計ポイント（必須）：credentials.json は安全に保管し、サービスは専用ユーザーで動作させること。systemd ユニットの ExecStart は実際のバイナリパスを使うこと。
• 注意：noTLSVerify は一時対処で、本番では TLS を正しく設定し Full(strict) を推奨します。

WARP（エンドポイントクライアント）

WARP はエンドポイントからのトラフィックを Cloudflare 経由へ送ります。デバイスポスチャー情報の送出や Gateway の適用が可能です。

• 役割：エンドポイントのトラフィックを傍受し、Zero Trust ポリシーを適用する経路を提供。
• 運用ポイント（推奨）：MDM 経由での配布と自動登録、証明書配布の自動化、バージョン管理を行う。

Gateway（DNS / HTTP フィルタ）

Gateway はブラウジング制御とマルウェア防御を担います。段階的な適用が推奨です。

• 役割：DNS フィルタ、HTTP カテゴリ制御、Threat Protection、TLS インスペクション（オプション）。
• 注意：TLS インスペクションは法務・プライバシー面の確認が必須です。ユーザ通知や同意が必要な組織もあります。

用語とログの整理

用語の混同を避けるため、ここで統一しておきます。

• チームドメイン：Zero Trust のダッシュボードで使用するチーム識別子（例: .cloudflareaccess.com のような形式）。
• ログ種類：Access ログ、Tunnel (cloudflared) ログ、Gateway の DNS/HTTP ログ、監査ログ（Audit）に分けて扱う。
• 備考：非公式記事を参照する場合は更新日時と対象バージョンを確認してください。Cloudflare 公式ドキュメントで最終的な仕様確認を行ってください。

導入手順（ハンズオン）

ここでは実務で手を動かすための段階的手順を示します。各ステップに「必須／推奨／任意」を明記します。環境に応じて差し替えて実行してください。

アカウント作成とチームドメイン設定（必須）

ゼロトラスト導入の入口です。管理者アカウントとチームの基本設定を行います。

• 手順（概略）：
• Zero Trust ダッシュボードにサインアップしチーム名（チームドメイン）を設定する。必須。
• 初期管理者アカウントに SSO（IdP）連携と MFA を設定する。必須。
• 管理用の API トークンやサービスアカウントを必要最小権限で発行する。推奨。

IdP 連携（SAML / OIDC）と SCIM（プラン依存）

IdP 側と Cloudflare 側の設定を行い、ユーザー・属性の受け渡しを確認します。

• SAML（推奨／必須）：
• IdP 側で Cloudflare Zero Trust をアプリとして追加し、メタデータを取得・設定します。必須。
• Cloudflare 側で SAML を有効化し、email／groups 等の属性マッピングを確認します。必須。

• テストユーザーでログインし属性が届くことを確認します。必須。

• OIDC（推奨）：

• IdP で OIDC クライアントを作成し、コールバック URL を登録します。推奨。

• Client ID/Secret を Cloudflare に登録して動作確認します。推奨。

• SCIM（任意／プラン依存）：

• SCIM はプラン依存の機能があるため、利用可否を公式で確認してください。利用不可の場合は API ベースの同期や IdP 側でのプロビジョニングを検討します。

WARP クライアント配布（OS別の例、必須／推奨）

配布方法は環境に依存します。MDM を使う場合は配布トークン・構成プロファイルで自動登録することを推奨します。

• Debian/Ubuntu（例、推奨）:

• macOS（例、推奨）:

• Windows（例、推奨）:

• iOS / Android（推奨）:
• App Store / Play Store から WARP を導入。MDM での配布と自動登録を推奨。

注意：パッケージ名やサービス名は OS と配布形式で異なるため、公式ドキュメントと照合してください。

cloudflared のインストールと Named Tunnel 作成（必須）

cloudflared の実行パスとサービス化、credentials の保護が重要です。以下は一例です。実行前にパスとバイナリ場所を確認してください。

• インストール例（Debian .deb 取得の例、環境により異なる）:

• バイナリパス確認（必須）:

systemd の ExecStart には上のコマンドで得た絶対パスを使ってください（例: /usr/bin/cloudflared または /usr/local/bin/cloudflared）。

• cloudflared 用の専用ユーザー作成と権限設定（推奨）:

• トンネル作成と credentials の移動（必須）:

• /etc/cloudflared/config.yml の例（必須／推奨）:

• systemd ユニット例（必須; ExecStart のパスは環境に合わせる）:

上記の ExecStart の /usr/bin/cloudflared は command -v cloudflared の出力で置き換えてください。

• 動作確認（必須）:

Access アプリ登録とポリシー設定（必須／推奨）

Access でアプリを登録し、最小権限ポリシーを作ります。テストと段階的適用を推奨します。

• 手順（概略）：
• Zero Trust → Access → Applications → Add application → Self-hosted application を選択。必須。
• Hostname（例: app.example.com）と Session 設定を入力。必須。
• Allowed identities を特定のグループやメールアドレスに限定。必須。
• Device posture 条件（例：managed、端末証明書の有無）を追加する場合は、属性名をダッシュボードで確認して設定する。推奨。
• テストは自分のメールのみ許可する等限定設定で実施し、ログとヘッダ（例：Cf-Access-Jwt-Assertion）を確認する。推奨。

短期検証フロー（Free プラン向け、最小セット）

短時間で動作を確認するための最小手順です。Free プランでは一部の機能やログの扱いに制限があるため、事前に確認してください。

• 必須最小手順：
• Zero Trust アカウント作成とチームドメイン設定。
• 検証端末に WARP をインストールして組織に登録。
• 検証用サーバに cloudflared をインストールして named tunnel を作成し、/etc/cloudflared に credentials を配置。

• Access でアプリを作成し、自分のメールアドレスのみ許可してアクセス確認。

• 注意：Free プランでは Logpush の一部ターゲットや SCIM の利用可否に制約がある場合があります。代替として Logpull API や手動エクスポートを利用してください。

運用・監視・トラブルシューティング

導入後の運用設計と代表的な障害対応、監視のポイントを示します。SIEM 連携やアラート設計を早期に整備してください。

ログ設計と SIEM 連携（必須／推奨）

どのログを収集するかで運用負荷が変わります。ログの種類と送信方法を決めてください。

• 取得すべきログ（推奨順）：
• Access ログ（認証／認可の記録）
• Tunnel（cloudflared）ログ（トンネル状態・接続エラー）
• Gateway の DNS / HTTP ログ（ブラウジング制御）

• 監査ログ（設定変更）

• ログ転送手段：

• 推奨：Logpush を使って S3/GCS/BigQuery 等に送る（プランで制限あり）。

• 代替：Logpull API や定期的なログ収集スクリプトで SIEM に取り込む。

• 注意：Free プランでは Logpush の機能制限や保持期間の差があるため、事前に公式のプラン比較を確認し代替案を用意してください。

監視とアラート設計（推奨／必須）

運用で注視すべき指標とアラート例です。

• 監視対象例：
• トンネルのダウン / 再接続頻度（必須）
• 大量の認証失敗（必須）
• 管理者アカウントの異常なログイン（推奨）

• 証明書の失効や自動更新失敗（推奨）

• アラート例：

• cloudflared サービスが停止したら 5 分以内に通知。
• 一定時間内に認証失敗が閾値を超えたらオンコールへ通知。

代表的な障害と対処（必須）

運用でよくある問題と優先度の高い確認点を示します。

• WARP 接続失敗：
• 確認：クライアントログ、DNS 解決、端末時刻、IdP の許可状態。
• 証明書エラー：
• 対処：openssl s_client でチェーンと SNI を確認。中間証明書や時刻同期を確認。
• cloudflared 起動エラー：
• 確認：credentials ファイルの有無とパーミッション、config.yml のパス、systemd の ExecStart（バイナリパス）を確認。
• IdP 連携エラー：
• 確認：ACS/EntityID の一致、属性マッピング、IdP 側の証明書有効期限。

導入時のチェックリストとコスト考慮（推奨）

短期導入と本番導入で確認すべきポイントを整理します。

• チェック項目（抜粋）：
• ユーザー数・WARP 配布方法のスケーリング計画。
• Logpush/保持要件と SIEM コスト。
• SCIM／SSO 自動化の可否（プラン依存）。
• TLS インスペクション等の法務・プライバシー対応。
• 運用体制（オンコール、証明書更新ローテーション）。

まとめ（短期検証フローと推奨設定）

短期検証で成果を出すには、前提確認→小規模での動作確認→段階的拡張の順に進めてください。まずは Free プランでの最小構成（WARP 1 台、cloudflared トンネル 1 本、Access ポリシーで自分だけ許可）を動かし、ログや権限管理を整えたうえで本番展開に移行することを推奨します。

• 必須：Cloudflare 上でドメイン/チーム設定、Zero Trust 管理者と MFA、IdP 連携の確認。
• 必須：cloudflared は専用ユーザーで動かし、credentials を /etc/cloudflared に移動して chmod 600。ExecStart のパスは command -v cloudflared で確認して指定。
• 推奨：WARP は MDM 経由で配布、証明書やポリシーは自動化。
• 推奨：ログは Logpush/Logpull を組み合わせて SIEM に連携し、アラートを設計する。
• 注意：SCIM や一部 Logpush ターゲットはプラン依存のため、公式ドキュメントで利用可否を確認し、代替手段を用意する。

参考：必ず Cloudflare 公式ドキュメントで最新の手順とプラン差を確認してください。非公式記事を参照する場合は更新日時と対象バージョンを確認のうえ補助的に利用してください。