tfsec 检查项详解：为 CloudFront 分发开启 Access Logging（aws-cloudfront-enable-logging）

• 应用安全
• SAST
• IaC

【免费下载链接】tfsec

Tfsec is now part of Trivy

项目地址：https://gitcode.com/gh_mirrors/tf/tfsec

点击查看免费下载

本文深入讲解 tfsec 内置检查项aws-cloudfront-enable-logging：它为什么要求每个 AWS CloudFront 分发（distribution）配置访问日志（Access Logging），检查失败会产生什么影响，以及如何在 Terraform 代码中通过logging_config修复。读完本文，你将掌握该检查的判定逻辑、完整修复写法、在命令行与 CI 中的落地方式，以及如何结合 tfsec 的忽略、排除与最小严重级别机制灵活管理这一检查项。

检查项速览

属性	值
检查 ID	aws-cloudfront-enable-logging
旧版 ID	AWS071（见 internal/pkg/legacy/map.go）
服务	aws / cloudfront
默认严重级别	medium
目标资源	aws_cloudfront_distribution
触发条件	未配置logging_config块
建议修复	为分发启用logging_config访问日志配置

该检查项与同属 CloudFront 系列的其他检查（aws-cloudfront-enable-waf、aws-cloudfront-enforce-https、aws-cloudfront-use-secure-tls-policy）一起收录在 docs/checks/aws/cloudfront/index.md，并在 rules.md 中被登记为一条 AWS 规则。

为什么需要 CloudFront 访问日志

CloudFront 访问日志（Access Logging）会为分发收到的每一次用户请求生成日志文件，其中包含请求时间、客户端 IP、请求方法、URI、响应状态、字节数、Referer、User-Agent 等详细信息。官方文档对本检查的解释是：

你应该配置 CloudFront Access Logging，以创建包含 CloudFront 收到的每个用户请求详细信息的日志文件。

从安全与运维角度看，访问日志是排查攻击行为、分析访问模式、做合规审计和计费核算的基础数据来源。缺少访问日志意味着：发生异常访问或安全事件时没有任何请求级证据可用于溯源，等于"丢失了关于访问和使用的关键信息"——这正是本检查项被标注为 medium 严重级别的原因：不直接造成数据泄露，但显著削弱可观测性与事后分析能力。

判定逻辑：有没有logging_config

该检查的判定非常直接：aws_cloudfront_distribution资源中只要存在logging_config块即视为通过。tfsec 通过 root.go 中的 Terraform 扫描器对 HCL 进行静态解析，以 defsec 构建的资源状态模型为基础执行内置规则，因此即使logging_config的某些属性不完整（例如未设置prefix），也不会触发本检查——它只关心日志开关本身是否打开。

不安全的示例（会失败）

resource "aws_cloudfront_distribution" "bad_example" { // other config // no logging_config }

只要资源中没有任何logging_config块，运行 tfsec 就会得到一条 ID 为aws-cloudfront-enable-logging、严重级别为 medium 的失败结果。

安全的示例（会通过）

resource "aws_cloudfront_distribution" "good_example" { // other config logging_config { include_cookies = false bucket = "mylogs.s3.amazonaws.com" prefix = "myprefix" } }

logging_config块内常用参数说明（与 Terraform AWS Provider 的aws_cloudfront_distribution资源定义保持一致，参考原文档链接指向的#logging_config小节）：

参数	说明	备注
bucket	接收访问日志的 S3 存储桶	必填，通常写成<bucket-name>.s3.amazonaws.com形式
prefix	日志对象键的前缀，便于按环境/项目归类	可选，建议设置，如myprefix
include_cookies	是否在日志中包含 Cookie 字段	可选，默认false；出于隐私与日志体积考虑建议保持false

注意：示例中的bucket值mylogs.s3.amazonaws.com是占位写法，实际使用时需替换为真实存在且策略允许 CloudFront 写入的 S3 桶。目标桶通常还应配置生命周期策略以定期归档或清理日志对象，避免存储成本无限增长。

在命令行与 CI 中验证与落地

直接运行检查

在包含上述 Terraform 文件的目录中执行：

tfsec .

扫描器会解析目录下所有 HCL 文件，命中aws-cloudfront-enable-logging时输出 medium 严重级别的失败结果；默认退出码为 1（存在 CRITICAL/HIGH/MEDIUM 级别失败时），若失败结果全部为 LOW 则退出码为 2，全部通过为 0，退出码逻辑见 root.go。

只关注本检查项

想单独验证这一条规则，可用--filter-results只保留指定检查：

tfsec --filter-results aws-cloudfront-enable-logging .

该参数最终会通过ScannerWithIncludedRules注入扫描器（见 flags.go），从而只运行（或只输出）与规则 ID 匹配的检查。也可用--exclude排除它：

tfsec --exclude aws-cloudfront-enable-logging .

按严重级别门禁

该检查默认是 medium。若只希望在高于 medium 的问题上阻断流水线，可设置最小严重级别：

tfsec --minimum-severity HIGH .

--minimum-severity支持 CRITICAL、HIGH、MEDIUM、LOW 四个取值（见 flags.go），非法的取值会在 configureOptions 中被拒绝并报错。也可以在配置文件（.tfsec/config.json或config.yml）中通过minimum_severity全局控制，详见 docs/guides/configuration/config.md。

生成多种输出格式

CI 中常用--format指定输出（lovely、json、csv、checkstyle、junit、sarif、text、markdown、html 等），多格式用逗号分隔并配合--out写文件：

tfsec --format sarif --out tfsec.sarif .

临时豁免：忽略注解

如果某条分发确实不需要访问日志（例如仅内部使用的测试分发），可在资源上以行内注释豁免：

resource "aws_cloudfront_distribution" "test_example" { #tfsec:ignore:aws-cloudfront-enable-logging // other config // intentionally no logging_config }

忽略规则支持多种形态：可写在块前、行尾，可带过期日期:exp:YYYY-MM-DD，可按 workspace 限定:ws:名称，旧版 IDAWS071也仍然可用，完整语法见 docs/guides/configuration/ignores.md。tfsec 对旧版 ID 的兼容正是通过 internal/pkg/legacy/map.go 中的AWS071 → aws-cloudfront-enable-logging映射实现的，运行时由ScannerWithAlternativeIDProvider(legacy.FindIDs)注入（见 flags.go）。

从源码看本检查的定位与运行机制

• 规则登记：aws-cloudfront-enable-logging出现在 rules.md 的规则清单中，作为 aws/cloudfront 分类下的一条可检索规则；
• 旧 ID 兼容：旧版 IDAWS071与现用 ID 的映射定义在 internal/pkg/legacy/map.go，保证使用旧 ID 配置忽略/排除的存量项目无需修改即可继续生效；
• 扫描执行：tfsec 命令行入口 cmd/tfsec/main.go 调用 root.go 中基于 defsec 的 Terraform 扫描器，内置检查以嵌入式策略随ScannerWithEmbeddedPolicies(true)一并加载（见 flags.go），因此无需额外下载即可对aws_cloudfront_distribution执行检查；
• 结果过滤：--filter-results、--exclude、--minimum-severity、--include-passed等参数均在 flags.go 的configureOptions中转换为扫描器选项，覆盖从"只看这一条"到"整体门禁"的各类使用场景。

迁移到 Trivy 的说明

tfsec 的 Terraform 扫描引擎与内置规则体系已被整合进 Trivy 的 IaC 与错误配置扫描能力中。当前仓库的 README.md 与 tfsec-to-trivy-migration-guide.md 均说明：tfsec 仍可使用，但后续工程投入转向 Trivy。在 Trivy 中对应规则仍以相同的检查语义（CloudFront 分发需启用访问日志）继续生效，迁移时注意沿用统一的规则 ID 语义即可。

小结

你要做的事	对应动作
让检查通过	为每个aws_cloudfront_distribution添加logging_config { bucket = ... }
单独验证	tfsec --filter-results aws-cloudfront-enable-logging .
临时豁免	资源内添加#tfsec:ignore:aws-cloudfront-enable-logging
全局排除	tfsec --exclude aws-cloudfront-enable-logging .
提高门禁	tfsec --minimum-severity HIGH .

aws-cloudfront-enable-logging是典型的"配置完备性"检查：修复成本极低（一个logging_config块），收益却是请求级日志带来的可观测性与审计能力。建议在 Terraform 模块模板中默认开启访问日志，并把该检查纳入 CI 门禁，从根本上避免"上线后发现没有日志"的被动局面。

参考链接（原文保留）

• Terraform AWS Provider 文档：aws_cloudfront_distribution资源的logging_config参数说明（见原文档 docs/checks/aws/cloudfront/enable-logging/index.md 的 Links 小节）
• AWS CloudFront 开发指南：Access Logs 使用说明（同上 Links 小节）

赞分享

• 应用安全
• SAST
• IaC

【免费下载链接】tfsec

Tfsec is now part of Trivy

项目地址：https://gitcode.com/gh_mirrors/tf/tfsec

点击查看免费下载

相关推荐

• tfsec 检查规则详解：启用 AWS ECR 镜像扫描（aws-ecr-enable-image-scans）

  tfsec 检查规则详解：启用 AWS ECR 镜像扫描（aws ecr enable image scans） 本篇技术指南围绕 tfsec 内置检查规则 a

  应用安全SASTIaC

• Nanobot OpenAI 兼容 API 完整指南：用 /v1/chat/completions 把本地 Agent 接入任何应用

  Nanobot OpenAI 兼容 API 完整指南：用 /v1/chat/completions 把本地 Agent 接入任何应用 Nanobot 内置了一套

  应用安全SASTIaC

• tfsec 静态检查实战：为 AWS Elasticsearch 域启用静态加密（aws-elastic-search-enable-domain-encryption）

  tfsec 静态检查实战：为 AWS Elasticsearch 域启用静态加密（aws elastic search enable domain encryp

  应用安全SASTIaC