企业官网建设流程全解析

• 应用安全
• SAST
• IaC

本篇指南围绕 tfsec 内置的 AWS DocumentDB（aws_docdb_cluster）安全检查规则展开，系统讲解日志导出、存储加密、客户托管密钥（CMK）三类检查的检测逻辑、默认严重级别与修复方法。读完本文，你将掌握每一条检查的触发条件与可复制的安全/不安全 Terraform 示例，并能直接在 tfsec 扫描结果中定位和修复对应的 DocumentDB 配置缺陷。

概述：tfsec 如何覆盖 DocumentDB

tfsec 是面向 Terraform 模板的静态安全扫描器（目前已成为 Trivy 的一部分），它通过解析 HCL 代码、将资源抽象为通用数据模型后执行规则扫描，最终输出包含检查 ID、严重级别与修复建议的结果。本仓库的文档体系将检查按云厂商与服务分层组织，DocumentDB 检查收录在 文档索引页 中，共包含三条规则：

从仓库结构看，DocumentDB 检查与 api-gateway、rds、s3 等 AWS 服务检查一同登记在 AWS 服务索引，并通过 mkdocs.yml 中的documentdb导航节点（含enable-log-export、enable-storage-encryption、encryption-customer-key三个子页）生成文档站点。这三条规则全部作用于aws_docdb_cluster资源，扫描执行链遵循 ARCHITECTURE.md 描述的流程：*.tf 文件 → parser.Parse() → adapter.Adapt() → scanner.Scan() → Results；其中规则的实际判定逻辑由 tfsec 依赖的 defsec 规则库（go.mod 中github.com/aquasecurity/defsec v0.84.1）提供，tfsec 负责 CLI 编排、结果输出与文档生成（见 cmd/tfsec-docs）。

检查一：DocumentDB 日志导出应启用（aws-documentdb-enable-log-export）

详细说明见 enable-log-export 检查文档。

为什么要开启日志导出

DocumentDB 默认不提供审计功能。为了能够准确审计集群的使用情况（例如谁在何时对集群数据做了变更），应当启用导出日志，将审计记录投递到 CloudWatch Logs。若未开启，审计轨迹对集群变更的可见性将非常有限，一旦发生误操作或恶意改动将难以追溯。

检查规则与严重级别

• 默认严重级别：medium
• 检查 ID：aws-documentdb-enable-log-export
• 检测属性：aws_docdb_cluster上的enabled_cloudwatch_logs_exports参数

该参数用于声明导出到 CloudWatch Logs 的日志类型列表。对于审计场景，有效的取值应包含"audit"；如果该参数缺失、为空，或仅填写了"something"这类无效值，则会被判定为不合规。

不安全示例（触发告警）

以下配置因将enabled_cloudwatch_logs_exports设为无效值"something"，无法产生有效审计日志导出，将失败aws-documentdb-enable-log-export检查：

resource "aws_docdb_cluster" "bad_example" { cluster_identifier = "my-docdb-cluster" engine = "docdb" master_username = "foo" master_password = "mustbeeightchars" backup_retention_period = 5 preferred_backup_window = "07:00-09:00" skip_final_snapshot = true enabled_cloudwatch_logs_exports = "something" }

安全示例（通过检查）

将日志导出类型明确设置为"audit"，即可让集群审计日志真正流向 CloudWatch Logs，从而通过该检查：

resource "aws_docdb_cluster" "good_example" { cluster_identifier = "my-docdb-cluster" engine = "docdb" master_username = "foo" master_password = "mustbeeightchars" backup_retention_period = 5 preferred_backup_window = "07:00-09:00" skip_final_snapshot = true enabled_cloudwatch_logs_exports = "audit" }

补充说明：enabled_cloudwatch_logs_exports在 Terraform AWS Provider 中属于可选参数，支持audit、profiler等取值。生产环境建议与 CloudWatch Logs 的日志组、保留策略配合使用，确保审计日志长期可查。

检查二：DocumentDB 存储必须加密（aws-documentdb-enable-storage-encryption）

详细说明见 enable-storage-encryption 检查文档。

为什么要加密底层存储

对 DocumentDB 底层存储启用加密，可确保即使承载数据的磁盘被入侵或泄露，磁盘上的数据依然无法被直接读取。反之，未加密的敏感数据在磁盘物理层面临被窃取或篡改的风险。

检查规则与严重级别

• 默认严重级别：high（存储加密缺失属于高风险问题，故严重级别高于日志导出检查）
• 检查 ID：aws-documentdb-enable-storage-encryption
• 检测属性：aws_docdb_cluster上的storage_encrypted参数

storage_encrypted控制集群存储是否加密。由于该参数在未显式指定时的行为可能退回未加密状态，检查要求其被显式设置为true；一旦被设为false或缺失，即判定不合规。

不安全示例（触发告警）

resource "aws_docdb_cluster" "bad_example" { cluster_identifier = "my-docdb-cluster" engine = "docdb" master_username = "foo" master_password = "mustbeeightchars" backup_retention_period = 5 preferred_backup_window = "07:00-09:00" skip_final_snapshot = true storage_encrypted = false }

安全示例（通过检查）

resource "aws_docdb_cluster" "good_example" { cluster_identifier = "my-docdb-cluster" engine = "docdb" master_username = "foo" master_password = "mustbeeightchars" backup_retention_period = 5 preferred_backup_window = "07:00-09:00" skip_final_snapshot = true storage_encrypted = true }

补充说明：storage_encrypted在 Terraform AWS Provider 中默认值为false。需要注意，集群创建后无法直接修改存储加密状态，因此应在首次创建aws_docdb_cluster时就把storage_encrypted = true写进配置；如需变更，只能新建集群后迁移数据。这与 AWS 官方"静态加密"（encryption at rest）最佳实践一致。

检查三：DocumentDB 加密应使用客户托管密钥（aws-documentdb-encryption-customer-key）

详细说明见 encryption-customer-key 检查文档。

为什么使用客户托管密钥

使用 AWS 托管密钥可以为 DocumentDB 底层存储提供基础加密保护；但若要获得更精细的控制权（例如自定义密钥生命周期、集中管理密钥轮换、按部门隔离密钥权限），则应使用客户托管密钥（Customer Managed Key，CMK）。若仅依赖 AWS 托管密钥，你将无法对加密密钥进行细粒度控制。

检查规则与严重级别

• 默认严重级别：low（在存储已加密的前提下，密钥管理方式属于控制面优化项，故级别较低）
• 检查 ID：aws-documentdb-encryption-customer-key
• 检测属性：aws_docdb_cluster上的kms_key_id参数

检查要求集群通过kms_key_id显式引用一个客户托管 KMS 密钥；若集群仅设置了storage_encrypted = true却未指定kms_key_id，则仍会判定不合规。

不安全示例（触发告警）

仅开启存储加密、但未指定任何kms_key_id的集群，将失败该检查：

resource "aws_docdb_cluster" "docdb" { cluster_identifier = "my-docdb-cluster" engine = "docdb" master_username = "foo" master_password = "mustbeeightchars" backup_retention_period = 5 preferred_backup_window = "07:00-09:00" skip_final_snapshot = true }

安全示例（通过检查）

先创建一个开启了自动轮换的aws_kms_key，再通过kms_key_id把集群加密绑定到该客户托管密钥上：

resource "aws_kms_key" "docdb_encryption" { enable_key_rotation = true } resource "aws_docdb_cluster" "docdb" { cluster_identifier = "my-docdb-cluster" engine = "docdb" master_username = "foo" master_password = "mustbeeightchars" backup_retention_period = 5 preferred_backup_window = "07:00-09:00" skip_final_snapshot = true kms_key_id = aws_kms_key.docdb_encryption.arn }

补充说明：kms_key_id在 Terraform AWS Provider 中接受 KMS 密钥的 ARN。上述示例同时设置enable_key_rotation = true，保证密钥定期轮换，这是客户托管密钥相对 AWS 托管密钥的核心控制优势之一。实际落地时还应结合 KMS 密钥策略限制使用者范围，遵循最小权限原则。

三条检查的共性与联动关系

将三条规则放在一起看，它们共同构成了 DocumentDB 集群的"可审计 + 静态加密 + 密钥自主可控"安全基线：

• aws-documentdb-enable-log-export（medium）：解决"出了问题能否追溯"的问题；
• aws-documentdb-enable-storage-encryption（high）：解决"数据落盘是否安全"的问题；
• aws-documentdb-encryption-customer-key（low）：解决"加密密钥是否自主可控"的问题。

推荐的安全配置组合为：storage_encrypted = true、kms_key_id = <客户托管 KMS 密钥 ARN>、enabled_cloudwatch_logs_exports = "audit"。三者可同时出现在同一个aws_docdb_cluster块中，一次扫描即可验证全部三条规则。

如何在实际项目中运行与验证

在包含aws_docdb_cluster资源的目录下执行 tfsec 即可触发上述检查：

tfsec .

输出中会按检查 ID（如aws-documentdb-enable-storage-encryption）分组显示失败结果、严重级别、违规行号与修复建议。你可以参照本仓库的 规则总览 确认检查 ID 与描述的对应关系，也可以在扫描时通过配置文件或命令行参数（如最低严重级别过滤）控制结果展示。

若希望以文档形式沉淀团队约定，可参考仓库中检查文档的写法——每个检查页包含 Explanation、Possible Impact、Suggested Resolution、Insecure Example、Secure Example 与 Links 六个板块，tfsec 的文档由 cmd/tfsec-docs 自动生成并维护在 docs/checks/aws/documentdb 目录下。

小结

tfsec 针对 AWS DocumentDB 提供了三条互补的检查规则：aws-documentdb-enable-log-export（medium，要求审计日志导出）、aws-documentdb-enable-storage-encryption（high，要求存储加密）、aws-documentdb-encryption-customer-key（low，要求客户托管密钥）。通过本文给出的不安全/安全示例，你可以快速理解每条检查的判定逻辑，并将修复方案直接应用到自己的 Terraform 配置中，在基础设施即代码阶段就完成 DocumentDB 安全基线的收敛。

• 应用安全
• SAST
• IaC