企业官网建设流程全解析

• 应用安全
• SAST
• IaC

本篇技术指南围绕 tfsec 内置安全检查规则aws-dynamodb-table-customer-key展开，说明该规则为何要求 DynamoDB 表在静态加密中使用 AWS KMS Customer Managed Key（CMK）、不满足要求时的影响，以及如何通过 Terraform 配置server_side_encryption块通过检查。读者读完本文后，能够直接识别并修复不满足该规则的 DynamoDB 表定义，并掌握在 tfsec 命令行与配置文件中定位、过滤、忽略该规则的具体做法。

规则概述：为什么要使用 Customer Managed Key

DynamoDB 表在默认情况下即启用静态数据加密（encryption at rest），使用的是AWS 托管的加密密钥（AWS managed encryption keys）。这意味着即使你不写任何加密配置，数据也会被加密，但这套机制存在一个关键限制：

使用 AWS 托管密钥无法对加密进行细粒度控制（fine grained control）。

例如，你无法自主管理密钥的轮换周期、无法按团队或项目隔离密钥的使用权限、无法在审计与合规场景中证明密钥的完整生命周期归属。为此，tfsec 提供了aws-dynamodb-table-customer-key这一内置检查，强制要求 DynamoDB 表使用Customer Managed Key（客户托管密钥，CMK）进行静态加密，以便把密钥的管理权（如enable_key_rotation轮换）掌握在自己手中。

该规则在仓库中的定义信息如下：

• 规则标识：aws-dynamodb-table-customer-key
• 旧版 ID（legacy ID）：AWS092，映射关系定义于 internal/pkg/legacy/map.go
• 所属云平台/分类：aws / dynamodb，登记于 rules.md
• 默认严重级别：low（低）

其中旧版 IDAWS092的存在意味着：如果你的历史代码或 CI 配置中使用了tfsec:ignore:AWS092之类的旧式忽略注释，tfsec 仍能通过 internal/pkg/legacy/map.go 中的FindIDs反向映射将其解析到新规则 ID，旧规则可以通过--migrate-ignores迁移到新结构（详见 docs/guides/usage.md）。

检查详情：说明、影响与建议修复

Explanation（规则说明）

DynamoDB 表默认使用 AWS 托管密钥进行静态加密。为了增强对加密过程的控制，并自主管理密钥轮换等要素，应改用 Customer Managed Key。

Possible Impact（潜在影响）

使用 AWS 托管密钥无法提供细粒度的加密控制，组织在密钥管理、合规审计方面会受限。

Suggested Resolution（建议修复方式）

为 DynamoDB 表启用服务端加密（server side encryption），并指定一个 Customer Managed Key（即 KMS 客户主密钥）。

不安全的示例（将触发检查失败）

以下 Terraform 配置会触发aws-dynamodb-table-customer-key检查失败。表虽然配置了流、副本等属性，但完全没有声明server_side_encryption块，因此加密密钥落回 AWS 托管密钥：

resource "aws_dynamodb_table" "bad_example" { name = "example" hash_key = "TestTableHashKey" billing_mode = "PAY_PER_REQUEST" stream_enabled = true stream_view_type = "NEW_AND_OLD_IMAGES" attribute { name = "TestTableHashKey" type = "S" } replica { region_name = "us-east-2" } replica { region_name = "us-west-2" } }

安全的示例（将顺利通过检查）

以下配置会通过aws-dynamodb-table-customer-key检查。要点是：

1. 先创建aws_kms_key资源，并开启enable_key_rotation = true，保证密钥定期轮换；
2. 在aws_dynamodb_table中声明server_side_encryption块，设置enabled = true，并把kms_key_arn指向该 KMS 密钥。

resource "aws_kms_key" "dynamo_db_kms" { enable_key_rotation = true } resource "aws_dynamodb_table" "good_example" { name = "example" hash_key = "TestTableHashKey" billing_mode = "PAY_PER_REQUEST" stream_enabled = true stream_view_type = "NEW_AND_OLD_IMAGES" attribute { name = "TestTableHashKey" type = "S" } replica { region_name = "us-east-2" } replica { region_name = "us-west-2" } server_side_encryption { enabled = true kms_key_arn = aws_kms_key.dynamo_db_kms.key_id } }

关于server_side_encryption块中的两个参数，结合 Terraform AWS Provider 的常见用法补充说明：

• enabled：布尔值，是否启用服务端加密。此处必须显式为true，否则检查会认为表未使用客户托管密钥；
• kms_key_arn：KMS 密钥的 ARN 或 ID。示例中引用aws_kms_key.dynamo_db_kms.key_id，即引用同文件中 KMS 资源的属性。只要该参数指向一个 Customer Managed Key，即可满足"客户托管密钥"的要求。

如何在实际项目中定位与处理该规则

运行扫描并过滤结果

tfsec 默认会对当前目录下的 Terraform 文件执行全部内置检查（详见 docs/guides/quickstart.md）：

# 扫描当前目录 tfsec # 扫描指定目录 tfsec ./tf/prod

如果只想查看与 DynamoDB 客户密钥相关的告警，可使用--filter-results参数只输出指定规则的命中结果：

tfsec --filter-results aws-dynamodb-table-customer-key .

若规则误报、或你确认某些表允许使用 AWS 托管密钥，也可以使用-e/--exclude在本次运行中排除该规则，或用-m/--minimum-severity设置最低报告级别（CRITICAL/HIGH/MEDIUM/LOW），该规则默认级别为low，需要注意如果设置--minimum-severity MEDIUM，本规则的 low 级告警将不会出现在输出中。完整参数说明见 docs/guides/usage.md。

在配置文件中统一管理该规则

更推荐的做法是把规则纳入 tfsec 配置文件统一管理。配置文件默认放在.tfsec/config.json或.tfsec/config.yml，也可用--config-file显式指定（详见 docs/guides/configuration/config.md）：

--- # 提高该规则的严重级别，使其在团队中引起足够重视 severity_overrides: aws-dynamodb-table-customer-key: HIGH # 或者：从运行中排除该规则 exclude: - aws-dynamodb-table-customer-key

按需忽略该规则

对于确实无法改造的存量表，可以用行内注释忽略（详见 docs/guides/configuration/ignores.md）。注意 tfsec 同时支持新 ID 与旧 IDAWS092：

resource "aws_dynamodb_table" "legacy_table" { #tfsec:ignore:aws-dynamodb-table-customer-key # 或使用旧 ID：#tfsec:ignore:AWS092 name = "legacy" hash_key = "TestTableHashKey" attribute { name = "TestTableHashKey" type = "S" } }

还可以为忽略规则附加过期日期，防止"忽略"被永久遗忘：

#tfsec:ignore:aws-dynamodb-table-customer-key:exp:2026-12-31

与同目录其他 DynamoDB 检查的协同

aws-dynamodb-table-customer-key属于 DynamoDB 主题下的三组检查之一，汇总页见 docs/checks/aws/dynamodb/index.md：

实际加固时，建议把三项检查一起纳入基线：先保证加密开启（high），再保证恢复能力（medium），最后把密钥升级为客户托管并控制轮换（low）。三者共同覆盖 DynamoDB 数据保护的"加密、可恢复、可控密钥"三个维度。

小结

aws-dynamodb-table-customer-key是 tfsec 对 DynamoDB 静态加密"更细粒度控制"诉求的落地规则：默认加密并不足够，密钥管理权同样重要。通过在其 Terraform 定义中显式添加server_side_encryption { enabled = true, kms_key_arn = ... }并配合开启自动轮换的aws_kms_key，即可通过该检查。结合 tfsec 的--filter-results、配置文件severity_overrides/exclude以及带过期时间的行内忽略注释，团队可以在不打断既有工作流的前提下，将这一规则纳入日常的 IaC 安全扫描。

• 应用安全
• SAST
• IaC