企业官网建设流程全解析

• 应用安全
• SAST
• IaC

本指南围绕 tfsec 内置规则aws-cloudfront-enforce-https展开，说明该规则如何识别允许明文 HTTP 通信的 CloudFront 分发、为什么这类配置被判定为 critical 级风险，以及如何通过viewer_protocol_policy参数完成修复。读完本文后，你将能独立在 Terraform 项目中定位该隐患、用最小改动完成 HTTPS 强制化，并理解 tfsec 中该规则与 CloudFront 其他安全规则的配合方式。

规则速览

该规则在 tfsec 的规则登记表 rules.md 中的完整定义如下：

配套的严重级别与修复信息，记录在规则说明文档 docs/checks/aws/cloudfront/enforce-https/index.md 中：

• 默认严重级别：critical（严重）
• 检测对象：aws_cloudfront_distribution资源
• 可能的影响：CloudFront 可通过未加密的连接被访问
• 建议的解决方案：仅允许 CloudFront 分发使用 HTTPS 通信

值得一提的是，该规则还有一个历史遗留 ID。在 internal/pkg/legacy/map.go 中可以看到"AWS020": "aws-cloudfront-enforce-https"的映射关系——早期版本的 tfsec 曾以AWS020编号标识此规则，该映射文件保证了旧报告、旧忽略注释在新版本中仍然可被正确识别。

为什么必须强制 HTTPS：来自规则文档的安全背景

规则文档对风险成因的解释非常直接：纯 HTTP 是未加密且人类可读的。这意味着如果攻击者对连接进行窃听（eavesdrop），就能看到在客户端与 CloudFront 之间往返流动的全部数据——包括表单内容、会话凭证、业务敏感信息等。

HTTPS 的本质是"运行在加密（TLS）连接之上的 HTTP"，即使数据在传输途中被截获，窃听者也无法解读其中的内容。因此，凡是面向公网提供内容的 CloudFront 分发，都应当拒绝明文 HTTP 请求，这正是本规则存在的原因：默认情况下，tfsec 不允许 CloudFront 分发以allow-all的策略开放明文访问。

关键参数：viewer_protocol_policy

规则的核心判断对象是aws_cloudfront_distribution中缓存行为（cache behavior）块内的viewer_protocol_policy参数。该参数决定了 CloudFront 在收到请求时，对"查看者（viewer）使用何种协议访问"这一问题的处理策略，主要取值包括：

从配置位置上讲，该参数通常出现在default_cache_behavior块中；当分发配置了多个缓存行为时，各ordered_cache_behavior块同样需要接受检查。

不安全示例与触发条件

规则文档中给出的"不安全示例"非常精炼：只要viewer_protocol_policy被设置为allow-all，检查即失败：

resource "aws_cloudfront_distribution" "bad_example" { default_cache_behavior { viewer_protocol_policy = "allow-all" } }

仓库中的示例文件 _examples/1509/main.tf 提供了一个更贴近真实场景的失败样例，它同时暴露出 HTTPS 相关的两个问题：

resource "aws_cloudfront_distribution" "bad_example" { default_cache_behavior { viewer_protocol_policy = "allow-all" } viewer_certificate { cloudfront_default_certificate = true minimum_protocol_version = "TLSv1.0" } }

该示例中allow-all会触发aws-cloudfront-enforce-https，而minimum_protocol_version = "TLSv1.0"又会触发另一条规则aws-cloudfront-use-secure-tls-policy——可见真实的 Terraform 配置往往同时违反多条安全规则，一次扫描就能把隐患全部暴露出来。

安全修复：redirect-to-https 与 https-only

规则文档给出的"安全示例"将策略改为redirect-to-https：

resource "aws_cloudfront_distribution" "good_example" { default_cache_behavior { viewer_protocol_policy = "redirect-to-https" } }

该配置可通过aws-cloudfront-enforce-https检查。修复的核心思路是：

1. 不允许明文直通：彻底移除allow-all，避免 HTTP 流量以明文形式被 CloudFront 服务；
2. 引导用户走加密通道：redirect-to-https会把尝试用 HTTP 访问的用户自动重定向到 HTTPS 地址，兼顾安全与用户体验；
3. 更严格的选择：如果业务上不需要兼容 HTTP 客户端，也可以直接使用https-only，从协议层面拒绝一切非加密请求。

需要说明的是，viewer_protocol_policy只是"查看者与 CloudFront 边缘节点之间"这一段的协议策略；若要端到端保证传输加密，还应配合viewer_certificate块中的证书与 TLS 版本配置（详见下文配套规则一节）。

在项目中运行与验证

tfsec 通过静态分析 Terraform 代码来发现此类配置问题（见 README.md 的项目概述），无需真正执行terraform plan或创建云端资源。典型使用方式：

• 在 Terraform 项目根目录直接运行tfsec，默认输出格式会以"通过/失败"列表展示每条规则的命中情况；
• 支持 JSON、SARIF、CSV、JUnit 等多种输出格式，便于接入 CI 流水线；
• 安装方式多样，如 macOS/Linux 的brew install tfsec、Windows 的choco install tfsec或scoop install tfsec（详见 安装指南 与 快速上手）。

扫描结果中，aws-cloudfront-enforce-https的命中项会按 critical 级别醒目展示，并附带问题描述与修复建议，可直接作为工单或代码评审的依据。

与 CloudFront 相关的其他安全规则联动

该规则并非孤立的。CloudFront 在 tfsec 中共有四条配套检查，全部收录在 docs/checks/aws/cloudfront/index.md 中，建议在加固分发配置时一并审视：

• enable-logging：CloudFront 分发应开启访问日志，用于审计与溯源；
• enable-waf：分发前端应部署 WAF，抵御常见 Web 攻击；
• enforce-https（本文）：禁止明文 HTTP 通信；
• use-secure-tls-policy：拒绝过时的 SSL/TLS 协议版本，要求使用 TLSv1.2 及以上。

其中use-secure-tls-policy与本文规则在证书配置上有天然关联：该规则文档指出，当使用cloudfront_default_certificate = true（即 CloudFront 默认的cloudfront.net域名）时，API 只允许将minimum_protocol_version设置为"TLSv1"，强行设置更高版本会导致terraform plan产生永久性 diff；此时唯一的选择是评估后忽略该规则。这提醒我们：HTTPS 强制化不是改一个参数就结束，证书、TLS 版本与域名方式需要整体权衡。

何时需要忽略该规则

若业务确实存在必须放行明文 HTTP 的场景（例如临时性灰度、兼容老旧客户端），可以通过 tfsec 的忽略机制在代码中显式豁免，具体语法与配置方式见 忽略规则指南。需要强调的是，忽略仅应用于有充分理由的例外情况，不应成为绕过 critical 级安全约束的常规手段。

源码级佐证与延伸阅读

本规则的相关实现证据分散于仓库各处，便于读者继续深入：

• 规则登记：rules.md 中的aws-cloudfront-enforce-https条目；
• 规则说明：docs/checks/aws/cloudfront/enforce-https/index.md（本文的直接素材来源，含规则文档末尾附带的 AWS 官方文档与 Terraform Provider 文档链接，可在仓库内对应页面查看）；
• 旧 ID 映射：internal/pkg/legacy/map.go 中AWS020与规则名的对应关系；
• 失败样例：_examples/1509/main.tf，展示allow-all与TLSv1.0同时触发的真实形态。

综上所述，aws-cloudfront-enforce-https是 tfsec 对 CloudFront 分发实施传输加密底线的一条 critical 级检查。在 Terraform 代码中把viewer_protocol_policy从allow-all调整为redirect-to-https（或https-only），即可在数行配置内完成修复；配合 WAF、访问日志与 TLS 版本策略，可以构建一套相对完整的 CloudFront 安全基线。

• 应用安全
• SAST
• IaC