TLS inspection(TLS decryption または HTTPS inspection とも呼ばれます)を使うと、Cloudflare Gateway はより深いトラフィック分析を行い、リクエストボディの機密データスキャン、リモートブラウザー隔離セッションへのアップグレード、リクエストの完全な URL とパスに基づくリダイレクトなどの操作を実行できます。
TLS inspection は、ユーザーが機密システムにアクセスするセキュリティポリシーに適しています。一方で課題もあります。TLS inspection を有効にしなくても、ポリシーはユーザー ID、デバイスポスチャ、IP アドレス、解決済みドメイン、SNI、その他多くの属性を使え、Zero Trust セキュリティ実装をサポートできます。
組織は、同じ考え方で動いていたレガシーシステムでの過去の経験から、既存システムとの相互運用を心配して TLS inspection の採用をためらうことがよくあります。ただし、Cloudflare の TLS inspection は能力が高く、パフォーマンスが良く、モダンで、何より柔軟です。すべてのトラフィックを絶対に検査することはできないと理解しています。何かは必ず壊れます。私たちの推奨は、この現実を踏まえています。
TLS inspection を有効にする理由と方法を決めるには、次の手順から始めることを推奨します。
Cloudflare Zero Trust では、ほとんどの高度なセキュリティ機能と data loss prevention (DLP) 機能に TLS inspection が必要です。
一部のセキュリティ組織は、ユーザーのプライバシーと利用規約への懸念から TLS inspection を避けます。これは重要で、ときに複雑な組織判断です。セキュリティ実務に関連する目標を立てると、判断を単純化できます。検討すべき質問:
- 組織の TLS inspection の用途は、「既知」(例: 企業公認 SaaS アプリケーション内の機密データ)の保護ですか、それとも「未知」(例: ユーザーが新しい blob ストレージバケットへファイルをダウンロード / アップロードする)の保護ですか?
- ドメインやホスト名でブロックするつもりですか、それとも完全な URL のポリシーを構築するつもりですか?
- リクエストやファイルの本文を DLP プロファイルと照合してスキャンしたり、ダウンロードしたファイルをアンチウイルス / アンチマルウェアエンジンでスキャンしたりする予定ですか?
- コピー / ペーストのブロック、キーボードのブロック、印刷のブロックなどのデータセキュリティ機能を活用するため、インライン Remote Browser Isolation を使う予定ですか?
これらの質問の大半が「いいえ」で、組織が主にホスト名または DNS ベースのセキュリティコントロールに頼っている場合、ほとんどの TLS トラフィック(すべてではないにしても)を検査する必要はないかもしれません。Cloudflare はセキュア Web ゲートウェイとしても、接続ユーザー向けのセキュア DNS リゾルバーとしても動くため、TLS トラフィックを広く検査しなくても、セキュリティ態勢を高められるポリシー制御を適用できます。
Zero Trust 組織で TLS inspection を有効にする手順は次のとおりです。
- Cloudflare ダッシュボード ↗ で Zero Trust > Traffic policies > Traffic settings を開きます。
- Proxy and inspection で、Inspect HTTPS requests with TLS decryption をオンにします。
-
cloudflare_api_token↗ に次の権限を追加します。Zero Trust Write
-
cloudflare_zero_trust_gateway_settings↗ でtls_decrypt引数を設定します。resource "cloudflare_zero_trust_gateway_settings" "team_name" { account_id = var.cloudflare_account_id settings = { tls_decrypt = { enabled = true } } }
デフォルトでは、Gateway はポート 80 の HTTP トラフィックだけを検査します。TLS 復号 をオンにすると、ポート 443 の HTTPS トラフィックも検査します。
ポート 80 および 443 に加えて、他のポートの HTTP および HTTPS トラフィックを検出して検査するには、you can turn on protocol detection and configure Gateway to inspect traffic on all ports。
TLS inspection では、暗号化トラフィックを検査・フィルタするために、信頼できるプライベートルート証明書が必要です。Cloudflare ルート証明書 は、デバイスに展開するテストや概念実証では単純で一般的な解決策です。Zero Trust で Cloudflare 証明書を生成 できます。
または、ほかの検査や信頼アプリケーションですでに使っているルート CA がある場合は、独自の証明書を使う ことを推奨します。理由の例は次のとおりです。
- ルート証明書が対象デバイス群にすでに展開されている場合、単一の証明書を使うと IT 管理が簡素化されます。
- Git ワークフローや CLI ツールなどの外部サービスが既存の証明書ストアに依存している場合、検査で同じ証明書を提示すると、トラフィックフローが中断されにくくなります。ただし、これらは検査から除外したい対象かもしれません。
- Cloudflare Mesh または Cloudflare WAN の IPsec / GRE トンネルでトラフィックを Cloudflare にオンランプする場合、それらのトンネル背後のデバイスは、組織が選んだ証明書と一致する証明書がなければ、TLS inspection を必要とする HTTP ポリシーを使えません。ネットワークインフラストラクチャには、すでに独自のデバイス証明書が展開されていることがほとんどなので、検査に既存の公開鍵基盤を使うと保護が簡単になります。
Cloudflare 証明書を生成するかカスタム証明書をアップロードしたら、Cloudflare ネットワーク全体に展開するために Available に設定し、検査に使うために In-Use に設定する必要があります。詳細は ルート証明書を有効にする を参照してください。
デフォルトですべてのトラフィックを検査しますか、それとも明示した宛先だけを検査しますか。検査から除外するアプリケーションとエンドポイントの Gateway リストを作り、既存の Do Not Inspect アプリケーショングループに加えて OR 演算子としてリストを追加することを推奨します。例:
| Selector | Operator | Value | Logic | Action |
|---|---|---|---|---|
| Application | in | Do Not Inspect | Or | Do Not Inspect |
| Host | in list | Trusted Hostnames |
組織が TLS inspection を必要とするセキュリティフレームワークを新たに採用する場合は、最小限から始めることを推奨します。実際、初期展開段階では、事前に決めたホスト名、IP、特定のユーザーグループまたはデバイスタイプだけを明示的に検査し、それ以外は検査しない選択が適切なこともあります。Cloudflare は検査をどこでいつ展開するかについて独自で柔軟なアプローチを持つため、デバイスのルーティングテーブルやほかのメモリ制約のあるローカル構成に影響せず、組織が必要とする範囲で限定的かつ細かくできます。
検査対象にすべきでないデバイスやユーザーグループに合わせて、パススルールールを構築できます。
たとえば、権限が限られた会社管理の iPhone が発行されている場合、デバイスポスチャ値に一致するすべてのトラフィックに追加の Do Not Inspect ポリシーを設定します。対象には OS の種類、OS バージョン、またはそれらの iPhone のシリアル番号リスト(MDM ツールからのフックで API 経由で更新)を含められます。
| Selector | Operator | Value | Logic | Action |
|---|---|---|---|---|
| Passed Device Posture | in | iOS 17 or higher (OS version) | And | Do Not Inspect |
| Passed Device Posture | in | iPhone Serial Numbers (Serial number) |
-
検査したくないデバイスシリアル番号のリストを作成します。
Create Zero Trust listbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/lists" \ --request POST \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --json '{ "description": "The serial numbers for administrators", "items": [ { "value": "8GE8721RE" } ], "name": "Admin Serial Numbers", "type": "SERIAL" }' -
シリアル番号リストとデバイスを照合する Do Not Inspect ポリシーを作成します。
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/rules" \
--request POST \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--json '{
"name": "Do not inspect corporate devices",
"traffic": "",
"identity": "",
"device_posture": "any(device_posture.checks.passed[*] in {\"<SERIAL_NUMBER_LIST_UUID>\"})",
"action": "off",
"precedence": 14002,
"enabled": true,
"filters": [
"http"
]
}'IPsec / GRE トンネル、Cloudflare Mesh、または Cloudflare 証明書がインストールされていないほかのデバイスでネットワーク接続デバイスをフィルタする場合は、パススルーポリシーで対応する必要があります。これらのデバイスでは、そのトラフィックの発信元となる送信元ネットワーク IP 範囲について、TLS inspection を明示的に除外します。例:
| Selector | Operator | Value | Action |
|---|---|---|---|
| Source Internal IP | in | 203.0.113.0/24 |
Do Not Inspect |
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/rules" \
--request POST \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--json '{
"name": "Do not inspect corporate devices",
"traffic": "http.conn.internal_src_ip in {203.0.113.0/24}",
"identity": "",
"device_posture": "",
"action": "off"
}'