去年7月，亚马逊云科技（Amazon Web Services，AWS）上线了一项脱离标准身份与访问管理（Identity and Access Management，IAM）角色的全新认证方式——一键生成、长期有效、不绑定角色。对治理团队来说，这是噩梦的开始。
作者在第一部分修了单个智能体（Agent）的11个安全漏洞。但真正的问题在于：任何开发者开一个新沙盒账户，不看手册直接部署，所有修复瞬间归零。手册不是治理，让手册变得多余才是治理。
本文讲如何在组织层面强制落地这项服务的安全控制——让不安全的配置无法部署，而非仅仅"不建议"。全部基于Terraform，全部对照AWS文档验证。
三层架构：预防-检测-响应
作者的设计分三层：
第一层，服务控制策略（Service Control Policy，SCP）——预防层，在部署前拦截危险配置；第二层，AWS Config规则——检测层，捕获已存在资源的漂移；第三层，EventBridge加简单通知服务（Simple Notification Service，SNS）——响应层，漏网之鱼触发实时告警。
逻辑很简单：第一层生效，第二层永远静默；第二层触发，第三层叫醒值班的人。纵深防御不是为了偏执，是因为人会犯错，环境会漂移。
动手前先用这两条命令确认组织结构：
aws organizations describe-organization 查看组织是否存在并获取根ID；aws organizations list-organizational-units-for-parent --parent-id $ROOT_ID 列出所有组织单元（Organizational Unit，OU）。
第一层：服务控制策略的硬边界
SCP在IAM策略之前评估——请求还没到达服务就被拦截。即使是账户根用户也无法覆盖。这是硬 enforcement 的正确工具。
⚠️ 警告：必须先在沙盒OU测试SCP，再挂到单个测试账户，最后才组织级生效。配置错误的SCP会立即锁死OU内所有账户的合法访问。
SCP 1：彻底封禁该服务的API密钥
2025年7月推出的这项API密钥功能，如果团队用不上，就封禁创建和使用。作者强调需要两条语句才完整，网上大多数示例只写一条——不够：
第一条语句拦截 iam:CreateServiceSpecificCredential，阻止创建；第二条语句拦截模型调用相关操作，阻止使用。两者缺一不可。
（原文代码块展示完整SCP JSON结构，含Condition字段对ServiceName的精确匹配）
SCP 2：强制模型调用必须走VPC端点
该服务的模型调用默认走公网。作者要求所有相关调用操作必须来自VPC端点。
SCP条件：StringNotEquals 检查 aws:VpcSourceIp 是否存在。不存在 = 非VPC流量 = 拒绝。
副作用：本地开发和CI/CD管道需要额外配置——要么走VPN进VPC，要么用具备VPC端点的自托管运行器（self-hosted runner）。作者认为这个摩擦值得，因为公网暴露的模型调用端面太大。
SCP 3：禁止未加密的模型输出存储
该服务的智能体默认把对话历史、执行轨迹、知识库检索结果写进S3。很多团队忘了加密。
这条SCP拦截两个动作：s3:PutBucketEncryption 时拒绝空加密配置；创建智能体时若S3目标桶的加密未配置或密钥非客户自主管理（Customer Managed Key，CMK），则拒绝。
热门跟贴