dev-kfarmer/grc-cloud-control-crosswalk

# 云控制交叉映射 将一个云安全控制映射到多个合规框架，只需单一证据，而无需分别检查每个框架。本实验针对 AWS S3 静态加密进行演示，并根据 SOC 2 CC6.1、ISO 27001 A.8.24 和 NIST 800-53 SC-28(1) 进行了评估。 **可视化概览：** https://dev-kfarmer.github.io/grc-cloud-control-crosswalk/visual-overview.html —— 在一个页面上展示 pipeline、通过/失败矩阵以及例外情况登记表。 ## 为什么各个框架会存在分歧 这三个框架设定的标准并不相同： - SOC 2 和 ISO 接受任何形式的服务器端加密。 - NIST SC-28(1) 仅在存储桶使用带有客户管理密钥的 SSE-KMS 时才算通过。AWS 托管密钥不计入其中。 因此，同一个存储桶可能会通过两个框架，却在第三个框架中失败。足够仔细地阅读控制要求，从而明确这条界限划在哪里，正是本项目旨在展示的技能。 ## 包含哪些内容 | 路径 | 用途 | |---|---| | `control-spec.md` | 控制定义：所需证据、各框架的通过/失败标准、例外规则。在任何代码编写之前完成。 | | `iam/readonly-evidence-policy.json` | 收集器使用的五个只读权限。无写入权限。 | | `terraform/` | 搭建一个一次性的测试环境：五个存储桶（每种结果一个）、一个客户管理的 KMS 密钥以及上述 IAM policy。 | | `evidence_collector.py` | 读取每个存储桶，并根据一次提取的证据根据所有三个框架对其进行评估。 | | `test_evidence_collector.py` | 包含模拟 AWS 调用的单元测试。无需真实的 AWS 账号。 | 特意使用了两个 AWS 身份。`grc-lab-admin` 通过 Terraform 构建测试环境。`grc-lab-readonly` 运行收集器。审计基础设施的身份不应同时具备修改它的权限。 ## 运行方式 ``` # 创建测试 buckets（只需一次，需要 admin profile） cd terraform terraform init terraform apply -var="aws_profile=grc-lab-admin" # 运行 collector（read-only profile） cd .. pip install -r requirements.txt python evidence_collector.py # 运行测试（不需要 AWS） python -m unittest test_evidence_collector.py -v ``` 收集器会生成三个文件：`evidence-output.json`（完整记录），`evidence-output.csv`（审计员会阅读的摘要），以及 `exceptions.csv`（仅包含被豁免的存储桶及其记录在案的原因）。 运行示例： ``` grc-evidence-lab-sse-kms-cmk-... Encryption: encrypted (aws:kms, key: CUSTOMER) SOC 2 CC6.1: PASS ISO 27001 A.8.24: PASS NIST 800-53 SC-28(1): PASS ``` ## 遇到的一些问题 自 2023 年 1 月起，AWS 已默认对所有新存储桶应用了 SSE-S3 加密，并且您无法将其关闭。我创建的一个完全没有加密配置的存储桶，依然被报告为已加密。 这意味着 SOC 2 和 ISO 的“无加密”失败场景实际上已不可能在当前的 AWS 账号中发生。这些控制要求是在默认设置改变之前编写的。代码仍然处理了这种情况，但目前测试它的唯一方法是使用模拟响应，这正是其中一个单元测试所做的工作。这也使得 NIST 对客户管理密钥的要求，成为了目前唯一需要经过刻意操作才能达到的标准。 ## 尚未完成 - 仅支持 AWS。Azure Storage 加密将作为后续版本的等效实现。 - 专注于将一个控制要求从头到尾完整落地，而不是对多个要求浅尝辄止。 - `grc-lab-readonly` 使用的是长期有效的 access key。生产环境中应改用基于角色的短期凭证。

标签：AWS, DPI, ECS, GRC, Python, Terraform, 合规自动化, 后端开发, 无后门, 逆向工具