TLS 検査を適用するデバイスとアプリケーション、適用しないものを検討したので、最初の HTTP ポリシーを作成します。
ポリシーを作成するときは、一貫した命名規則を使います。ポリシー名は Cloudflare アカウント全体で一意にし、同じ構造に揃え、できるだけ具体的にします。
新しい HTTP ポリシーを作成するには:
-
Cloudflare ダッシュボード ↗ で Zero Trust > Traffic policies > Firewall policies を開きます。
-
HTTP タブで Add a policy を選びます。
-
ポリシーに名前を付けます。
-
Traffic で、許可またはブロックするトラフィックを定義する論理式を組み立てます。
-
論理式に一致したトラフィックに対する Action を選びます。たとえば、TLS 復号を設定している場合、埋め込み証明書 を使う一部のアプリケーション（一部の Google 製品など）は HTTP 検査に対応していないことがあります。こうしたアプリケーションの検査をバイパスするポリシーを作成できます。
セレクター 演算子 値 アクション Application in Do Not Inspect Do Not Inspect Cloudflare の脅威インテリジェンスに基づき、Command & Control、Botnet、Malware などの 既知の脅威 をブロックするポリシーの追加も推奨します。
セレクター 演算子 値 アクション Security Categories in All security risks Block -
Create policy を選びます。
-
次の権限を持つ API トークンを作成 します。
種類 項目 権限 Account Zero Trust Edit -
（任意）API の環境変数に アカウント ID と API トークンを含めます。
-
Create a Zero Trust Gateway rule エンドポイントへ
POSTリクエストを送ります。たとえば、TLS 復号を設定している場合、埋め込み証明書 を使う一部のアプリケーション（一部の Google 製品など）は HTTP 検査に対応していないことがあります。こうしたアプリケーションの検査をバイパスするポリシーを作成できます。Create a Zero Trust Gateway rulebash 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 applications", "description": "Bypass TLS decryption for unsupported applications", "precedence": 0, "enabled": true, "action": "off", "filters": [ "http" ], "traffic": "any(app.type.ids[*] in {16})", "identity": "", "device_posture": "" }'{ "success": true, "errors": [], "messages": [] }API は、ポリシーの概要とリクエストの結果を返します。
Cloudflare の脅威インテリジェンスに基づき、Command & Control、Botnet、Malware などの 既知の脅威 をブロックするポリシーの追加も推奨します。
Create a Zero Trust Gateway rulebash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/rules" \ --request POST \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --json '{ "name": "Block known risks", "description": "Block all default Cloudflare HTTP security categories", "precedence": 0, "enabled": true, "action": "block", "filters": [ "http" ], "traffic": "any(http.request.uri.security_category[*] in {68 178 80 83 176 175 117 131 134 151 153})", "identity": "", "device_posture": "" }'
詳細は HTTP ポリシー を参照してください。
ほとんどの場合、Gateway は HTTP ポリシーを 上から下の順（DNS ポリシーと同様）で評価します。Do Not Inspect アクションのポリシーは終端アクションです。配置場所に関係なく機能上は常に先に適用されるため、ほかのポリシーより上に、論理的な順でまとめることを推奨します。
Do Not Inspect ポリシーの順序を正しくしたあと、Allow ポリシーを続けます。Allow ポリシーの説明には、Allow アクション固有の注意点（ヘッダー ID、証明書の不一致時の扱い、Isolate しないトラフィックなど）を書いておきます。
次に、Isolate ポリシーと Block ポリシーを並べます。Block ポリシーをほかの結果のポリシーと混ぜる場面もあります。その進め方でも問題ありませんが、意図しない結果を招くほど緩い Allow や厳しすぎる Block にならないよう確認してください。
ユーザーに影響する Block などのアクションを本適用する前に、まずポリシーを Allow アクションにして影響を測ります。ユーザーの操作を監視し、ログでそのポリシーに絞って、どのトラフィックが一致したかを確認します。想定どおりのアクティビティなら、意図したアクションとして適用して問題ないことが多いです。
ポリシーが想定外のトラフィックフローや宛先（意図しないユーザーやデバイスグループなど）に一致する場合は、ポリシーが緩すぎたり厳しすぎたりしていないか見直します。ポリシーの設計が正しそうなら、意図したポリシーより先に別のポリシーが一致していないかを確認します。Gateway ポリシーの 適用順序 を確認し、すべてのポリシーが意図どおりに連携していることを確かめます。