亚马逊AWS官方博客
如何使用 AWS Organizations 简化超大规模环境下的安全保障机制
AWS Organizations 专门提供跨AWS账户的集中治理与管理方案。在本文中，我们将结合自身在Amazon信息安全团队中积累的经验，讲解如何使用AWS Organizations简化信息安全工程师们的日常工作。AWS Organizations中的服务控制策略（SCP）功能将帮助您对组织内的所有账户权限进行集中控制，借此保证账户始终符合组织内访问控制规则的相关要求。以此为基础，您的信息安全团队将建立起一套行之有效的机制，防止AWS账户中发生不安全操作。您也可以根据特定业务需求，修改或添加更多SCP规则。
在本文中，我们将向您展示如何通过SCP限制员工在企业AWS账户中所能执行的操作类型，同时我们将提供Amazon信息安全团队使用的示例SCP展示如何实现以下限制：
- 防止信息安全团队创建的AWS身份与访问管理（IAM）角色遭到删除或修改。
- 防止使用登录配置文件创建IAM用户。
- 防止篡改AWS CloudTrail。
- 防止Amazon Simple Storage Service (Amazon S3) 公开访问。
- 防止用户执行与AWS Organizations相关的任何操作。
所有这些规则，以及相应的实施原因，都将在本文中得到详尽阐述。需要注意的是，Amazon使用的SCP远不止以上几项，本文仅列出几项关于最佳实践的示例供您公开参考。
问题范围
在Amazon公司，安全无疑是重中之重，也是我们直面技术行业新挑战、适应新兴安全威胁、同时鼓励试验与创新的核心前提。Amazon信息安全团队负责保证员工能够快速开发出基于AWS技术的新型产品与服务，同时始终遵循强大的安全标准。我们要如何完成这一艰巨目标？对AWS Organizations及SCP的充分运用，正是解答这个疑问的关键环节。
Amazon拥有成千上万个AWS账户。在AWS Organizations面世之前，Amazon信息安全团队只能通过AWS Config、AWS CloudTrail、Amazon CloudWatch等在各个账户中建立定制化的响应式规则，借此检测并缓解一切可能存在的安全问题。虽然效率不错，但管理众多AWS账户内所有规则，又成为新的现实挑战。具体来讲，信息安全团队需要解决两项特定挑战：
- 我们如何才能建立起预防式方法（即抢先一步阻止不安全行为的发生），而仅将响应式控制作为后备机制？
- 我们如何持续保证运行在AWS账户当中的关键基础设施拥有强大的防篡改能力，而无需构建自定义的监控与修复基础设施？例如，我们创建出大量自定义IAM角色以代理指向AWS账户的单点登录访问。因此，我们必须保证员工不会意外删除这些角色，且未经授权的使用者也绝不可恶意删除这些角色。
AWS Organizations的推出，帮助Amazon信息安全团队找到了克服以上难题的重要方法。
使用预防式控制替代响应式控制
让我们首先来看Amazon信息安全团队为管理AWS账户整体安全状况而制定的部分关键规则。这些属于企业范围之内的安全控制机制，因此我们在组织root中进行定义，以确保部署到组织内的所有AWS账户都。大家也可以在组织单元（OU）或个人账户层级实施这些安全控制机制，借此更加灵活地为组织内的不同部门建立起不同的防护围栏。
规则1：防止由信息安全团队创建的IAM角色遭到删除或修改
Amazon信息安全团队在Amazon使用的各个AWS账户中创建IAM角色，我们则使用这些IAM角色根据Amazon安全策略集中监视并控制访问活动。因此，除了信息安全团队之外，其他任何人都不应具备删除或修改这些角色的权限。
在使用AWS Organizations与SCP之前，Amazon信息安全团队一直使用响应式控制机制扫描各个账户，以保证无人能够删除这些重要角色。响应式控制机制负责检测是否有人以不符合企业安全策略的方式执行配置更新。
这种方法的潜在缺陷包括：
- 这是一种响应式方法，即仅在问题发生后才能将其发现；结合具体场景，即重要角色已经被意外删除之后，才发现问题。
- 这种方法将安全责任交由员工负责，企业只能依靠员工的善意与专业知识保证他们坚守安全规则。
企业员工希望专注于自己的核心竞争力，即业务水平以及高效完成工作的能力。不可能要求他们同时成为信息安全专家。所以，如果能够消除这方面负担，那么组织内的每位成员都能够节省下宝贵的精力与时间。SCP的出现帮助Amazon解决了这一难题。在SCP的支持下，您可以避免将不必要的访问权限授予安全访问团队之外的员工。如以下示例所示，大家可以保证信息安全团队需要的所有角色以字符串InfoSec开头，同时创建一个SCP以防止员工意外删除这些重要角色。
下面来看SCP示例，此SCP能够阻止账户中所有以InfoSec开头的IAM角色遭到删除或修改——除非发起者本身使用InfoSec角色。此示例介绍了如何在SCP中使用条件语句，使得SCP在实际应用中获得巨大的操作灵活性。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PreventInfoSecRoleActions",
"Effect": "Deny",
"Action": [
"*"
],
"Resource": [
"arn:aws:iam::*:role/InfoSec*"
],
"Condition": {
"StringNotLike": {
"aws:PrincipalARN": "arn:aws:iam::*:role/InfoSec*"
}
}
}
]
}
规则2：防止使用登录配置文件创建IAM用户
在企业网络内部对员工进行身份验证时，使用联动身份验证无疑是一种重要的安全最佳实践。这种方法将允许员工使用联合身份认证登录企业拥有的AWS账户，而非为所有员工创建独立的IAM用户并分配对应的密码。
以下原因解释了为何最佳实践是使用联合身份认证，而不是为每一位员工创建各自的IAM用户：
- 使用身份联动验证时，信息安全团队无需控制成千上万个账户与对应的用户个人凭证，因此管理难度得到显著降低。
- 使用联动身份验证时，用户使用临时凭证登录您的AWS账户，其间无需长期存储任何永久性密码，这就降低了外部人士/组织猜测用户密码的可能性。
以下示例SCP，能够阻止员工创建任何独立IAM用户。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PreventIAMUserWithLoginprofile",
"Effect": "Deny",
"Action": [
"iam:ChangePassword",
"iam:CreateLoginProfile",
"iam:UpdateLoginProfile",
"iam:UpdateAccountPasswordPolicy"
],
"Resource": [
"*"
]
}]
}
规则3：防止篡改AWS CloudTrail
对信息安全团队来说，跟踪全部账户当中所有用户所执行的活动无疑至关重要。这除了是一项最佳实践要求之外，不少合规性标准也要求我们维护AWS账户中所有用户活动的确切历史记录。大家可以使用AWS CloudTrail保留这部分历史记录，并使用SCP保证未授权用户无法禁用AWS CloudTrail或对其输出结果进行修改。
以下示例SCP，能够防止对CloudTrail的篡改。要使用此示例，请将其中的exampletrail 部分替换为需要保护的实际跟踪名称。
{
"Sid": "PreventTamperingWithCloudTrail",
"Effect": "Deny",
"Action": [
"cloudtrail:DeleteTrail",
"cloudtrail:StopLogging",
"cloudtrail:PutEventSelectors",
"cloudtrail:UpdateTrail"
],
"Resource": [
"arn:aws:cloudtrail:*:*:trail/exampletrail"
]
}
规则4：防止S3公开访问
作为一项最佳实践，如果您希望外部实体能够公开访问某些项目，则应指定明确的S3存储桶以及其中的具体可公开内容。在此期间，大家必须保证那些敏感信息被安全的保护且未设置成能够被公开访问。为此，Amazon信息安全团队在原则上阻止任何Amazon员工将S3存储桶或其中特定内容公开发布，除非他们已经经过安全审查并获得信息安全团队的明确批准。我们在所有账户中全面使用Amazon S3 Block Public Access功能。以下示例SCP，将阻止员工对这些设置做出变更。
{
"Sid": "PreventS3PublicAccess",
"Action": [
"s3:PutAccountPublicAccessBlock"
],
"Resource": "*",
"Effect": "Deny"
}
规则5：防止用户执行与AWS Organizations相关的任何操作
我们还希望确保只有信息安全团队能够执行与AWS Organizations相关的操作，同时防止任何其他用户执行诸如脱离组织/查找组织内其他账户等操作。以下示例SCP，将阻止用户在AWS Organizations中执行此类操作。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PreventOrgsActions",
"Effect": "Deny",
"Action": [
"organizations:*"
],
"Resource": [
"*"
]
}
]
}
以上SCP将会阻止某些依赖AWS Organizations相关功能读取权限的AWS服务，例如AWS Resource Access Manager (AWS RAM)。如果希望允许AWS Organizations为这些服务提供读取权限，您可以修改SCP，在SCP定义的Action部分中指定更具体的操作。例如，您可以修改SCP以防止成员账户脱离组织，但同时仍允许其使用AWS RAM等功能，如以下SCP所示。关于您能够在各账户中访问的所有AWS Organizations API操作的更多详细信息，请参阅AWS Organizations API参考：按账户执行API操作。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PreventLeavingOrganization",
"Effect": "Deny",
"Action": [
"organizations:LeaveOrganization"
],
"Resource": [
"*"
]
}
]
}
总结
在AWS Organizations面世之前，Amazon的信息安全团队不得不实施自定义的响应式规则，借此管理成千上万个AWS账户的安全控制任务，并保证所有员工都严格遵循企业制定的AWS资源管理策略。AWS Organizations极大简化了这类任务，帮助信息安全团队更轻松地控制Amazon员工能够在其AWS账户中执行的实际操作类型。我们在本文中分享了一部分相关信息与SCP示例，希望帮助大家建立起类似的控制机制。
保证环境安全，绝不总像访问控制策略中的“是/否”那样简单明确。因此，除了使用Organizations SCP之外，我们可能还需要在各类大规模环境中使用AWS Config Rules等技术监控允许执行的更改；但在不同场景之内，这种权限机制同样可能带来隐患。例如，在CloudTrail当中，大家可能希望允许DevOps团队对CloudTrail记录的事件类型做出更改——例如记录所有数据事件，还是只记录管理事件。在这种情况下，您可能需要允许用户访问PutEventSelectors等API。这时，我们建议您使用“cloudtrail-security-trail-enabled”等Config托管规则提醒工程师禁用事件管理中的各类极端情况。通过将预防式措施（例如我们在本文中重点介绍的各项预防措施）与响应式控制（往往具有一定的灵活性）相结合，大家才能真正建立起最佳安全态势，保证快速发展的团队能够充分享受云服务带来的安全性、功能性与灵活性优势。
扩展阅读
请参阅IAM用户指南中的策略评估逻辑部分以了解更多相关信息。
AWS已经发布关于如何创建AWS Organization以及如何创建SCP的详细信息，感兴趣的朋友不妨亲自体验一番。
如果您对本文有任何建议或反馈，请在下方评论区中与我们交流。如果您对本文还有疑问，请在AWS Organizations论坛上启动新线程，或联系AWS支持团队。
希望了解关于AWS Security的更多方法指南、新闻与功能公告？请在 Twitter上关注我们。