企业官网建设流程全解析

• 应用安全
• SAST
• IaC

本文围绕 tfsec 内置的aws-iam-enforce-mfa检查规则展开，系统讲解该规则检测的 IAM 配置问题、默认严重级别、不安全的 Terraform 写法与通过检查的安全写法，并结合仓库内的真实示例模块terraform-module/enforce-mfa/aws给出可直接落地的修复方案。读完本文，你将掌握如何编写让 tfsec 放行的 IAM 组配置，以及在本地与 CI 中运行该规则的完整方法。

规则概览：检查什么、为何重要

aws-iam-enforce-mfa是 tfsec 内置的 AWS IAM 安全规则之一，其对应的规则文档位于 docs/checks/aws/iam/enforce-mfa/index.md，并在 mkdocs.yml 中注册到文档站点导航。该规则的检查对象是 AWS IAM 组（aws_iam_group）及关联的组策略：

• 检查项：IAM 组是否启用了多因素认证（MFA）强制；
• 默认严重级别：medium（中等）；
• 检测逻辑：扫描 Terraform 配置中声明的aws_iam_group，判断其是否通过组策略中的条件键aws:MultiFactorAuthPresent对 MFA 提出强制要求。

MFA 强制要求在用户通过密码登录或使用访问密钥执行操作时，额外提供第二个认证因素（如 TOTP 动态令牌、硬件密钥），从而在密码泄露的场景下为账户加一道安全闸门。IAM 用户账户一旦缺少 MFA 保护，攻击者仅需拿到一组口令即可接管账户权限，这正是该规则以medium严重级别提示风险的原因。

该规则与同目录下的 enforce-group-mfa 规则 语义相近（后者检查对象与措辞侧重 "IAM groups should have MFA enforcement activated"），两者共同构成 tfsec 对 AWS IAM 组 MFA 配置的双保险。完整的 IAM 检查清单可参考 docs/checks/aws/iam/index.md。

可能的隐患：不加 MFA 的账户风险

tfsec 对该规则给出的 "Possible Impact" 说明是：

User accounts are more vulnerable to compromise without multi factor authentication activated.

翻译过来即：未启用多因素认证的 IAM 用户账户更容易被攻破。具体表现为：

1. 密码一旦泄露（弱口令爆破、钓鱼、凭据复用），攻击者可无阻碍登录控制台或调用 API；
2. 缺乏第二认证因素时，安全团队难以通过异常登录设备/位置来阻断攻击；
3. 合规审计（如 SOC 2、ISO 27001）通常要求特权账户具备 MFA 强制能力。

因此，该规则建议所有 IAM 组（尤其是包含高权限用户的组）都应绑定带 MFA 条件键的策略。

不安全的示例：这条配置必然失败

原规则文档给出的失败示例非常简单直观：

data aws_caller_identity current {} resource aws_iam_group developers { name = "developers" }

这段配置只会导致aws-iam-enforce-mfa检查失败，原因在于：

• 它创建了 IAM 组developers，但没有为组附加任何策略；
• 组内用户在执行任意 AWS API 操作时，不受aws:MultiFactorAuthPresent条件的约束；
• 因此在 tfsec 的判定中，该组不具备 MFA 强制能力，命中medium级别告警。

在本地验证时，可直接对该文件运行 tfsec：

tfsec .

tfsec 默认扫描当前工作目录（详见 README.md），发现此类问题时退出码非零，在 CI 中即会阻断构建。

安全的示例：用条件键约束 MFA

要修复上述问题，需要为 IAM 组附加一份包含aws:MultiFactorAuthPresent条件键的组策略。原规则文档给出的安全示例通过给组绑定aws_iam_group_policy，在策略的条件块中强制要求调用者已完成 MFA 认证：

resource "aws_iam_group" "support" { name = "support" } resource aws_iam_group_policy mfa { group = aws_iam_group.support.name policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Action": "ec2:*", "Resource": "*", "Condition": { "Bool": { "aws:MultiFactorAuthPresent": ["true"] } } } ] } EOF }

关键点解析：

注意：示例中Action为ec2:*，在实际生产环境中应遵循最小权限原则，将 Action 与 Resource 收敛到业务实际需要的范围（这与 tfsec 的 no-policy-wildcards 规则 的检查思路一致）。

推荐实践：直接使用 enforce-mfa 官方模块

手写策略模板虽然可以绕过检查，但维护成本高。tfsec 原规则文档的 "Suggested Resolution" 明确推荐使用 Terraform 社区模块terraform-module/enforce-mfa/aws来统一落实 MFA 强制。仓库中提供了两份可直接复用的完整示例：

• _examples/mfa/group.tf
• _examples/mfa-module/main.tf

两份示例内容一致，核心配置如下：

data aws_caller_identity current {} resource aws_iam_group support { name = "support" } resource aws_iam_group developers { name = "developers" } module enforce_mfa { source = "terraform-module/enforce-mfa/aws" version = "0.12.0" policy_name = "managed-mfa-enforce" account_id = data.aws_caller_identity.current.id groups = [aws_iam_group.support.name] manage_own_signing_certificates = true manage_own_ssh_public_keys = true manage_own_git_credentials = true }

该模块的入参含义与用途：

注意：示例中创建的developers组不在groups列表内，说明该模块支持按组粒度选择启用范围——未被纳入的组不受 MFA 强制，tfsec 会继续对其报出aws-iam-enforce-mfa告警。在仓库的测试数据 test/testdata/external-module/main.tf 中可以看到该模块在外部模块引用场景下的另一种写法（不显式传入groups与account_id），可用于验证 tfsec 对模块化配置的解析行为。

在 CI 中落地：运行、忽略与排除

将规则接入流水线只需要三步：

1. 本地扫描：tfsec .，扫描指定目录（不传目录则扫当前工作目录），发现问题时退出码非零；
2. 容器化运行：docker run --rm -it -v "$(pwd):/src" aquasec/tfsec /src（镜像选项详见 README.md）；
3. 按需豁免：对于确需豁免的告警，可在对应行添加#tfsec:ignore:aws-iam-enforce-mfa注释；若希望整个模块内的该类告警全部忽略，可将注释置于 module 块上方；如需设置过期时间，可使用#tfsec:ignore:aws-iam-enforce-mfa:exp:2025-01-02格式（详见 README.md）。

若团队暂时不启用该规则，也可通过-e参数在命令行中整体排除：tfsec . -e aws-iam-enforce-mfa。

小结

aws-iam-enforce-mfa以medium级别守护 AWS IAM 组的 MFA 底线：凡是未通过策略条件键强制 MFA 的 IAM 组都会被标记。修复路径有两条——手写带aws:MultiFactorAuthPresent条件键的组策略，或直接引入terraform-module/enforce-mfa/aws模块（参考 _examples/mfa/group.tf 的完整参数）。将本规则与同目录的密码策略类规则（set-minimum-password-length、set-max-password-age 等）组合使用，可系统性地加固 AWS IAM 的身份与访问管理防线。

• 应用安全
• SAST
• IaC