在考虑了 TLS 检查应当和不应当应用于哪些设备和应用程序之后，是时候创建你的第一个 HTTP 策略了。
在构建所有策略时使用标准的命名规范。策略名称在 Cloudflare 账户中应保持唯一，遵循相同的结构，并且尽可能详细。
要创建新的 HTTP 策略：
-
在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Traffic policies（流量策略） > Firewall policies（防火墙策略）。
-
在 HTTP 选项卡中，选择 Add a policy（添加策略）。
-
为策略命名。
-
在 Traffic（流量） 下，构建一个逻辑表达式，定义您要允许或阻止的流量。
-
选择当流量匹配该逻辑表达式时要采取的 Action（操作）。例如，如果您配置了 TLS 解密，某些使用 嵌入式证书 的应用程序可能不支持 HTTP 检测（例如某些 Google 产品）。您可以创建一条策略来为这些应用程序绕过检测：
选择器 运算符 值 操作 应用程序 (Application) in 不检测 (Do Not Inspect) 不检测 (Do Not Inspect) Cloudflare 还建议根据 Cloudflare 的威胁情报，添加一条策略以阻止 已知威胁（例如命令与控制 (Command & Control)、僵尸网络 (Botnet) 和恶意软件 (Malware)）：
选择器 运算符 值 操作 安全类别 (Security Categories) in 所有安全风险 (All security risks) 阻止 (Block) -
选择 Create policy（创建策略）。
-
创建具有以下权限的 API 令牌：
类型 项目 权限 Account Zero Trust Edit
2.（可选）配置您的 API 环境变量以包含您的 账户 ID 和 API 令牌。
3. 向 创建 Zero Trust Gateway 规则 端点发送 POST 请求。例如，如果您配置了 TLS 解密，某些使用 嵌入式证书 的应用程序可能不支持 HTTP 检测（例如某些 Google 产品）。您可以创建一条策略来为这些应用程序绕过检测：
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 还建议根据 Cloudflare 的威胁情报，添加一条策略以阻止 已知威胁（例如命令与控制 (Command & Control)、僵尸网络 (Botnet) 和恶意软件 (Malware)）：
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) 操作策略是终结性操作，我们建议按逻辑顺序将其排在所有其他策略之上，因为无论它们放置在哪里，它们在功能上总是优先触发。
一旦“不检查”策略排序正确，接下来应跟进 Allow 策略，并且 Allow 策略说明中应包含针对 Allow 操作的任何特殊考虑事项（如标头 ID、证书不匹配处理和非隔离流量）。
接下来，列出你的隔离 (isolate) 和阻断 (block) 策略。可能存在你希望在其他策略结果中混合阻断策略的场景。这是一种可以接受的做法，但你需要确保没有过于宽松的允许策略或过于严格的阻断策略而导致意外效果。
在确立阻断或会影响用户的其他操作之前，先通过将策略设置为 Allow 操作来测量影响。监控用户的操作并在日志中查找（通过该显式策略进行排序），以查看哪些流量操作与之匹配。如果该活动完全符合你对策略的预期，你可能可以安全地将其作为其预期操作来实施。
如果你的策略匹配了非预期的流量流或目的地（例如非预期的用户或设备组），请审查你的策略以确保其不过于宽松或严格。如果策略设计看起来正确，请确定其他策略是否在预期策略之前发生了匹配。你可以审查 Gateway 策略的执行顺序，以确保你的所有策略都按预期协同工作。