十项要诀助力 AWS 账户安全提升

Original URL: https://aws.amazon.com/cn/blogs/security/top-10-security-items-to-improve-in-your-aws-account/

如果您有意愿改善您AWS账户中云安全性，那么AWS首席信息安全官Stephen Schmidt在AWS re: Invent 2019大会上提出了十大最重要云安全提示。在这些提示如下图所示，我们能够带着更清晰的思路采取行动。

1) 准确的账户信息

当AWS需要就您的AWS账户与您联系时，我们会使用AWS管理控制台中预先定义的联系信息，包括用于创建账户的电子邮件地址以及Alternate Contacts之下列出的邮件地址。因此，大家应该保证所有电子邮件地址不致指向同一位联系人。您还需要建立一套流程，用于定期检查这些电子邮件地址是否正常运行，以及您是否会对通知邮件做出回复（特别是从abuse@amazon.com处收到的安全通知邮件）。关于如何设置备用联系人，以保证当首选电子邮件地址不可用时仍将由其他人收到重要提示消息，请点击此处了解更多详细信息。

2) 使用多因素验证（MFA）

多因素验证MFA是保护您的账户免受不当访问的最佳方式。请始终保证在您Root用户以及AWS身份与访问管理（IAM）用户中设置MFA。如果您使用AWS Single Sign-On (SSO) 控制指向AWS的访问，或者借此与企业身份存储进行联动，也可以在其中启用MFA机制。将MFA与联动身份提供程序（IdP）结合起来，意味着大家能够继续使用组织内的现有MFA流程。要了解如何具体操作，请参阅在AWS中使用多因素身份验证（MFA）。

3) 禁止硬编码secrets

在AWS上构建应用程序时，大家可以使用AWS IAM角色以交付临时使用凭证，借此调用必要的AWS服务。当然，某些应用程序需要使用周期更长的凭证，例如数据库密码或者其他API密钥。在后一种情况下，请千万不要以硬编码形式将secrets保存在应用程序或者源代码当中。

大家可以使用 AWS Secrets Manager控制应用程序中的凭证信息。Secrets Manager能够帮助我们在整个软件生命周期之内轮换、管理并检索数据库凭证、API密钥以及其他保密信息。用户及应用程序可以直接调用Secrets Manager API检索保密信息，从而避免以明文形式进行敏感信息硬编码。

这里推荐大家参阅如何在Amazon EC2上通过AWS IAM角色运行应用程序。另外，为了获得最佳效果，也建议大家参考如何使用AWS Secrets Manager安全地为AWS Lambda函数提供数据库凭证。

4) 限制安全组

安全组机制，是保证网络访问您在AWS上所配置资源的一种重要方式。借此，您可以保证仅打开必要端口，并通过已知网络范围之内启用连接，从而遵循安全最佳实践提出的基本要求。大家可以使用AWS Config或者AWS Firewall Manager等服务，以编程方式保证虚拟私有云（VPC）安全组使用与您预期相符的配置。Network Reachability规则工具包则可分析您的Amazon Virtual Private Cloud (Amazon VPC) 网络配置，确定外部网络（例如互联网、虚拟专用网关或者AWS Direct Connect）能否访问Amazon EC2实例。AWS Firewall Manager还能够将AWS WAF规则自动应用于整个AWS账户当中各类面向互联网的资源。关于更多详细信息，请参阅关于VPC安全组中的变更检测与响应。

5) 数据分类策略

不同的数据有着不同的用途，因此必须对其做出正确数据分类以保障安全性。其中的核心，在于立足严格的安全状态与灵活的敏捷性之间做出权衡。严格的安全措施必然带来冗长的访问控制流程，但能够为数据安全提供更有力的保证。但这样的安全管理思路，往往与敏捷及快节奏的开发需求背道而驰；在开发环境中开发人员需要自助访问数据存储的权限。为此，请认真规划数据分类方法，借此满足广泛的访问要求。

当然，数据的分类方式不需要像公共数据与私有数据那样非此即彼。各类数据有着不同程度的敏感度，您拥有的数据可能属于敏感性和机密性的不同级别。应设计适当的预防与检测控制措施组合，从而适当地匹配数据的敏感性。在以下建议中，我们主要探讨公共数据与私有数据之间的差异。如果您目前还没有建立数据分类政策，那么先从public与private角度区分可能是个不错的起点。

如何对已分类或正在分类的数据进行保护：

1. 如果您拥有面向公共数据的Amazon Simple Storage Service (Amazon S3)存储桶，请将其中所有数据转移至某一单独AWS账户中提供公开访问。设置策略，仅允许流程（而非人员）将数据移入这些存储桶。这使您可以阻止在任何其他AWS账户中创建公共Amazon S3存储桶的功能。。
2. 使用Amazon S3可以阻止不应通过Amazon S3共享数据的任何帐户中的公共访问。。
3. 使用两个不同的IAM角色进行KMS的加密和解密。这使您可以将数据输入（加密）和数据查看（解密）分开，并允许您通过分析该角色来对失败的解密尝试进行威胁检测。

6) 集中管理CloudTrail日志

日志记录与监控，永远是强大安全计划中的重要组成部分。只有及时调查环境中的意外变更并配合活动分析，才能真正在数据访问层面实现安全状况监控与迭代升级。AWS建议大家将日志（特别是AWS CloudTrail日志）写入仅用于日志记录的AWS账户（日志归档）S3存储桶内。存储桶还应使用正确权限，防止日志被删除并对静态数据进行加密。日志集中整理完成后，您可以进一步与集成SIEM解决方案或者通过AWS服务进行日志内容分析。点击此处，了解如何使用AWS服务实现AWS CloudTrail日志可视化。将CloudTrail日志集中化之后，您还可以使用同一Log Archive帐户来集中来自其他来源（如CloudWatch Logs和AWS负载均衡器）的日志。

7) 验证IAM角色

当您使用AWS账户进行迭代和构建功能时，您最终可能会创建出多个IAM角色，其中某些角色将随时间推移而不再必要。这时，可以使用AWS IAM Access Analyzer查看对内部AWS资源的访问活动，并确定您在AWS账户之外共享访问的位置。还可以定期使用Security Hub或Prowler等开源产品定期重新评估AWS IAM角色和权限，从而获得必要的可见性，用以验证当前治理、风险与合规性（GRC）策略的合规性。如果您已经完成了这些步骤，并创建出多个角色，则可以搜索未经使用的IAM角色并将其删除。

8) 设计发现结果的自动响应（不只是GuardDuty）

AWS Security Hub、Amazon GuardDuty以及 AWS Identity and Access Management Access Analyzer都属于托管型AWS服务，可为您的AWS账户当中提供具备可行的发现结果。您可以轻松启用相应功能，并实现跨多账户集成。当然，启用只是第一步，接下来大家还需要根据发现结果采取相应行动，具体操作由您的事件响应策略决定。对于每个发现，请确保您已确定所需采取的应对措施。

我们当然可以通知相关人员执行响应操作，但随着大家在AWS服务应用方面的经验日渐丰富，建议您尽可能自动响应由Security Hub或者GuardDuty生成的发现结果。大家可以点击此处，了解如何根据Security Hub发现结果自动执行响应与修复操作。

9) 密钥轮换

Security Hub提供的一项重要功能，就是通过CIS Benchmarks查看您AWS账户的当前合规状况。其间，该工具会查找密钥使用周期超过90天的IAM用户。如果您实际需要的是访问密钥而非权限角色，则应定期执行密钥轮换。您可以点击此处，了解管理AWS访问密钥的最佳实践。如果您的用户通过联动验证访问AWS，则无需为这部分用户发放AWS访问密钥。用户将向IdP进行身份验证，并在目标AWS账户中获取相应的IAM角色。如此一来，您不需要不长期凭证，并且您的用户将具有与IAM角色关联的短期凭证。

10) 安全嵌入到开发周期

之前的九项要点，基本都集中在实际实施的技术配置层面。最后一条则与“参与开发周期”的人员有关，也可以概括为“提高组织内的安全文化”。人员应立足所在的各个组织部门，帮助企业更安全地启动解决方案。只要安全意识深入人心，我们就可以根据特定场景引导并培训员工，帮助他们了解自己需要采取哪些举措以提高所构建产品的安全性水平。从本质角度讲，安全是每一个人的工作——而非仅仅由那些职位中包括“安全”二字的员工负责。

每个组织内安全专职人员的主要工作是通过改变流程引导员工以最简单、最可行的方式保障安全。例如，每个团队不应建立只属于自己的独立身份联动或日志记录解决方案。只有协同配合，企业的整体安全态势才会更上一层楼，并在云时代下继续保持可靠的保障能力。安全工作的目的在于降低安全参与门槛，帮助同事们与安全团队顺畅对话，及时为普通员工提供引导与支持。关于建立卓越安全团队的更多详细信息，请参阅培养安全领导力。

这就是我们今天要分享的十大云安全保障要求，希望这些能够在实践当中为大家提供支持，在安全的基础之上打造出更灵活的创造空间。

如果您对本文有任何建议或反馈，请在以下评论区中与我们交流。

关于AWS安全运营方法的更多新鲜资讯，请在 Twitter上关注我们。

本篇作者