企业官网建设流程全解析

• 应用安全
• SAST
• IaC

本指南以 tfsec 内置检查aws-dynamodb-enable-at-rest-encryption为核心，讲解其触发条件、判定逻辑、Terraform 修复示例，以及如何在本地与 CI 流水线中实际运行该检查。读完本文后，你将能够识别未启用服务端加密的aws_dax_cluster配置、写出通过检查的合规代码，并掌握结合严重级别过滤、规则忽略与同组检查（aws-dynamodb-enable-recovery、aws-dynamodb-table-customer-key）构建 DynamoDB 安全基线的方法。

检查概览：规则 ID 与默认严重级别

aws-dynamodb-enable-at-rest-encryption是 tfsec 针对 AWS DynamoDB 资源组提供的安全规则之一。其官方定义位于 docs/checks/aws/dynamodb/enable-at-rest-encryption/index.md，在仓库的规则总表 rules.md 中登记如下：

该检查的默认严重级别为 high，意味着一旦命中，tfsec 默认会将其作为高优先级问题报告，适合直接阻断不合规代码合入。

值得注意的是，tfsec 为历史版本向下兼容保留了旧的数字规则 ID。在 internal/pkg/legacy/map.go 中可以确认如下映射关系：

"AWS081": "aws-dynamodb-enable-at-rest-encryption",

也就是说，旧版本 tfsec 输出的AWS081规则在最新版本中等价于aws-dynamodb-enable-at-rest-encryption。如果你的既有 CI 配置或忽略注释中使用了AWS081，迁移到新 ID 时无需改写逻辑。

检查对象与风险说明：为什么 DAX 需要静态加密

根据 docs/checks/aws/dynamodb/enable-at-rest-encryption/index.md 的说明，本检查同时覆盖两类对象：

• Amazon DynamoDB Accelerator（DAX）集群：DAX 是 DynamoDB 的内存加速层，用于缓存热点数据、提供微秒级读取延迟；
• DynamoDB 表：DAX 背后的持久化存储层。

文档给出的核心依据是：静态加密（encryption at rest）为数据提供了额外一层保护，能够防止对底层存储进行未授权访问后直接读取数据。AWS 为 DynamoDB 及其加速组件提供透明的服务端加密（SSE），加密过程发生在数据写入底层存储之前、读取之后自动解密，对应用透明无感。

由此引出的可能影响（Possible Impact）为：一旦底层存储被攻破，未加密的数据可被自由读取。官方给出的修复建议（Suggested Resolution）是：为 DAX 集群启用静态加密。

从实现上看，Terraform AWS Provider 在aws_dax_cluster资源中通过server_side_encryption嵌套块控制该能力，其中enabled = true/false决定是否开启加密。本检查正是围绕该配置块的三种不安全形态展开判定。

判定逻辑：三种会被判定为失败的写法

当aws_dax_cluster资源出现以下任一形态时，aws-dynamodb-enable-at-rest-encryption检查将报告失败（对应文档中的 Insecure Example）：

# 失败形态 1：完全没有服务端加密配置 resource "aws_dax_cluster" "bad_example" { // no server side encryption at all } # 失败形态 2：声明了 server_side_encryption 块但内容为空 resource "aws_dax_cluster" "bad_example" { // other DAX config server_side_encryption { // empty server side encryption config } } # 失败形态 3：显式关闭了服务端加密 resource "aws_dax_cluster" "bad_example" { // other DAX config server_side_encryption { enabled = false // disabled server side encryption } }

这三种形态分别对应：

1. 配置缺失：未声明server_side_encryption块。从规则设计意图看，tfsec 认为默认值不可靠，显式声明加密才是合规基线；
2. 空块声明：虽然写了server_side_encryption {}，但未提供任何参数。空块并不会产生有效的加密语义，仍需判定为失败；
3. 显式禁用：enabled = false是最直接的违规信号，明确表明加密被关闭。

合规写法：显式开启服务端加密

通过检查的写法（对应文档中的 Secure Example）非常明确——在aws_dax_cluster中显式设置server_side_encryption { enabled = true }：

resource "aws_dax_cluster" "good_example" { // other DAX config server_side_encryption { enabled = true // enabled server side encryption } }

将上面的不安全示例替换为这一形态后，aws-dynamodb-enable-at-rest-encryption检查即可通过。

实战增强：一份可运行、可复现的完整示例

文档中的示例为了聚焦判定逻辑省略了 DAX 集群的必填参数。为了便于在真实 Terraform 工程中直接落地验证，下面给出一个补全必填字段、可直接terraform plan的对照版本（补全参数仅用于使配置合法，不影响检查对server_side_encryption的判定结果）：

# 不合规：DAX 集群未启用服务端加密 resource "aws_dax_cluster" "bad_example" { cluster_name = "bad-dax-cluster" node_type = "dax.r5.large" replication_factor = 1 iam_role_arn = aws_iam_role.dax.arn subnet_group_name = aws_dax_subnet_group.main.subnet_group_name # 缺少 server_side_encryption 块 } # 合规：显式开启服务端加密 resource "aws_dax_cluster" "good_example" { cluster_name = "good-dax-cluster" node_type = "dax.r5.large" replication_factor = 1 iam_role_arn = aws_iam_role.dax.arn subnet_group_name = aws_dax_subnet_group.main.subnet_group_name server_side_encryption { enabled = true } }

上述配置假设你已预先定义aws_iam_role.dax、aws_dax_subnet_group.main等依赖资源。若想快速验证检查行为而不搭建完整环境，也可以直接使用文档中的最小化示例运行扫描。

如何实际运行该检查

tfsec 的完整使用方式见 README.md。对包含上述aws_dax_cluster资源的目录执行：

tfsec .

tfsec 会扫描指定目录（默认当前工作目录）下的全部 Terraform/HCL 文件；若发现任何问题，退出码为非零，否则退出码为 0，这一语义让检查天然适合接入 CI 门禁。

用严重级别过滤，聚焦 high 风险

由于本检查默认严重级别为 high，你可以通过--minimum-severity让 CI 只拦截高优先级问题（参数定义见 internal/app/tfsec/cmd/flags.go）：

# 只报告 CRITICAL 与 HIGH 级别的问题 tfsec . --minimum-severity HIGH

--minimum-severity的可选值为CRITICAL, HIGH, MEDIUM, LOW；传入非法值时 tfsec 会直接报错提示（见 flags.go）。

在 Docker 中运行

不安装本地二进制，也可以用官方镜像扫描当前目录（见 README.md）：

docker run --rm -it -v "$(pwd):/src" aquasec/tfsec /src

输出格式与文件导出

默认输出为lovely可读格式，也可通过--format选择json、csv、checkstyle、junit、sarif、markdown、html等格式，便于对接不同 CI 平台（参数见 flags.go）：

# 输出 JSON 报告 tfsec . --format json # 同时输出多种格式到文件（首个格式额外打印到 stdout） tfsec . --format json,sarif --out scan-results

违规代码的豁免与排除策略

使用行内注释忽略

对于确实需要临时豁免的 DAX 集群，可参考 README.md 的忽略机制，在违规行或资源块上方添加注释：

#tfsec:ignore:aws-dynamodb-enable-at-rest-encryption resource "aws_dax_cluster" "temporary_example" { # 已知风险，业务评审通过，限期整改 }

忽略注释还支持过期时间，确保豁免不会永久遗留（见 README.md）：

#tfsec:ignore:aws-dynamodb-enable-at-rest-encryption:exp:2026-06-30 resource "aws_dax_cluster" "temporary_example" { # 到 2026-06-30 后该忽略自动失效 }

使用--exclude排除规则

若要在整个扫描中禁用该检查（例如历史存量代码尚未整改），可使用--exclude参数（见 flags.go）：

tfsec . --exclude aws-dynamodb-enable-at-rest-encryption

多个规则 ID 用逗号分隔。推荐仅在迁移过渡期使用此方式，长期建议通过注释忽略并配合过期时间管理存量风险。

与 DynamoDB 检查组的配合：构建完整安全基线

本检查并非孤立存在。tfsec 针对 DynamoDB 一共提供三条规则，索引见 docs/checks/aws/dynamodb/index.md：

其中：

• 静态加密（本文主题）解决"数据是否加密存储"的问题，是最基础的底线；
• 客户管理密钥（table-customer-key/index.md）解决"加密由谁掌控"的问题——DynamoDB 默认使用 AWS 托管密钥，若需自行控制轮换等策略，应在aws_dynamodb_table的server_side_encryption块中指定kms_key_arn；
• 时间点恢复（enable-recovery/index.md）解决"数据被误删/恶意删除后能否回滚"的问题，通过point_in_time_recovery { enabled = true }开启。

生产环境的 DynamoDB 加固建议同时满足这三条规则：aws_dax_cluster显式开启server_side_encryption，aws_dynamodb_table使用 CMK 并开启 PITR，再结合 tfsec 的--minimum-severity HIGH门禁与忽略过期机制，即可形成从"加密"到"密钥可控"再到"可恢复"的完整数据保护闭环。

小结

aws-dynamodb-enable-at-rest-encryption是 tfsec 中一条默认高严重级别的 DynamoDB 静态加密检查，覆盖aws_dax_cluster的三种不安全形态：完全缺失server_side_encryption块、空块声明、以及enabled = false。合规修复方式单一且明确——显式设置enabled = true。结合仓库中的 rules.md 规则总表、legacy/map.go 的旧 ID 映射，以及 README 与 flags.go 中记录的运行、过滤、豁免方式，你可以在本地与 CI 中稳定落地该检查，并联合 DynamoDB 同组规则构建完整的数据安全基线。

• 应用安全
• SAST
• IaC