“安全永远是我们的首要任务。——沃纳·沃格尔斯，亚马逊副总裁兼首席技术官

敏捷性、成本、自主和更快的上市时间是为什么大多数客户将在06工作负载到云——让我们找出我们可以移动安全←左边对齐到这些软件开发原则——安全不应成为瓶颈,您可以使用云安全的工作负载在云上。

目标受众

如果您已经使用AWS Cloud几年了，我相信您能够理解我在这篇文章中试图表达的观点。请与更广泛的观众分享你的经历。如果你即将开始你的旅程，这是一个很好的开始，因为我将总结我多年来学到的一些实践。

我想你已经和AWS合作至少一年了。因此，在本系列的这一部分中，我不会详细解释本文中提到的任何AWS服务;相反，我将重点介绍您应该实现的策略，以获得更好的安全体系结构。本系列的其他部分将介绍一些实现。

在过去的两年里，我花了大量的时间与我的团队和其他云专家通过许多开源平台一起工作，试图改进AWS云上的安全实践。虽然在纸面上听起来很简单，但是在生产规模上实现它是一项非常具有挑战性的任务，需要跨不同的团队和非常不同的技术堆栈集进行协作。

不要担心，因为我们将涵盖所有的细节和即将发布的帖子。希望你能从我们的错误中吸取教训，并利用我们的胜利。重要的是，与我们分享你的经验。

这就解决了。我们走吧，走DevOps的路!

文化

消除指责的循环

在讨论AWS上的安全实现之前，让我们先从我们(安全人员)、我们的文化、我们的流程和思维方式开始。

“总的来说，我们辜负了客户。——VMWare首席执行官帕特•盖尔辛格(Pat Gelsinger)表示。

帕特说的对极了，我们的安全团队。多年来，我们关注的是威胁，而不是建立安全能力。首先，安全团队将大部分时间花在应对威胁上，而不是预防威胁。

我们应该更多地讨论收缩攻击表面的实现和预防机制。复杂、缓慢和团队间的冲突破坏了许多组织。只有当您将简单性应用于流程，将更多的协作精神应用于企业文化，并将可靠的安全原则(由数据支持)应用于决策引擎时，您才能看到事情正在朝着正确的方向发展。我也同意安全团队资金不足的说法，他们总是为了“最好的性价比”而奋斗。“这使我们更聪明!

我们的团队必须共同努力，以实现组织的安全目标;最后，安全应该是每个人的工作。我们花在互相指责上的时间越少，我们就越容易有效地合作。

共享责任模型

我知道，你在想，从哪里开始呢?我知道您正试图赶上每天发布新特性或bug修复的应用程序团队，他们有很多需要担心的事情。我知道这很容易跳的很酷的东西,开始实施策略通过自动化或其他方式,但理解你作为一个客户的责任就是你需要开始,所以开始与共同责任模型因为你会避免很多新手的错误。

AWS共享责任模型

根据您对AWS计算服务(EC2、ECS/EKS或lambda等)或公共云模型(IaaS、PaaS或SaaS)的选择，您作为客户的责任可能会发生根本性的变化，但是我们不会在本文中详细讨论这一点，因为这篇文章可以独立撰写。

但是，在高层次上，您应该非常担心数据的安全性，因为您不能将此责任转移给AWS，无论您使用什么AWS服务或采用什么公共云模型，这都是您的义务。

您越接近无服务器，就越不需要担心补丁管理和OS级别的安全加固噩梦。

对于您的公共云模型也是如此，您越倾向于SaaS，就越不需要担心基础设施安全性。请注意，我不是提倡SaaS，我只是陈述事实。

公共云模型

多账户模型

理解了作为客户的安全性职责之后，就可以考虑大规模地实现治理了。早期采用者学到的重要经验之一是;从安全和成本管理的角度来看，将应用程序部署在一个AWS帐户上是一种危险的做法，因为它会使云管理过程复杂化。

AWS帐户体系结构

我将让您决定如何构建您的帐户，但是上面的图表说明了一个常见的模式。

您需要为开发人员提供一个沙箱帐户来尝试新功能，并为每个产品提供正式的开发、预戳和戳帐户。拥有一个日志帐户，您可以在其中聚合所有CloudTrail日志、配置规则、S3访问日志和其他与安全相关的数据，审计人员可能需要访问这些数据，以防发生违规。

您还需要一个用于对其他帐户执行策略的管理帐户。尝试将帐单委托给帐单管理帐户，而不是使用主帐户。使用主帐户对链接帐户应用组织服务控制策略。

资源标签是一个巨大的问题，成本控制是当今企业面临的重要问题之一。再一次，多账户模型来拯救，因为您已经将每个产品部署到一个单独的AWS帐户上，所以您知道“产品团队”可以吃掉整个账单，您不应该过多地担心他们的标记缺陷事件，尽管我认为标记对于许多其他原因是必要的。

许多为所有应用程序使用一个帐户的AWS客户都经历了服务限制不断增加的痛苦。您有许多工程师在争夺有限的资源(s3 bucket、计算机资源和其他资源)，更不用说AWS有一些无法为您增加的硬限制。

我一直最喜欢的多账户模式的好处是它提供的有限爆炸半径。我可以确保开发团队A不能访问开发团队B的账户，这样他们就不会破坏他们的东西。我也可以在晚上睡觉时知道，如果我的猫在AWS账户120上的图像处理产品被入侵，我在其他AWS账户上的其他产品将不会受到影响。我想你现在看到了使用这个模型的好处:)而且它不会花费你更多的钱!在您开始使用资源之前，AWS帐户是免费的。

云计算赋能

确保您所做的一切不会毫无理由地阻塞您的开发人员。必须在允许开发人员快速开发和确保环境安全之间取得平衡。首先要确保开发人员知道，您并不是要充当拦路虎，而是要充当推动者。

建立一个商定的安全基线，该基线需要满足您的业务的每个帐户，以符合特定于行业的法规。

解剖学和速度是必不可少的业务安全所以确保你对齐安全实践你的业务工作在和谐,说这很简单,因为它需要大量的传福音,了解你的产品和基础设施除了你所有的合规要求。

自动化&策略as Code (PaC)

云托管

我不知道您的想法，但是用代码构建安全策略并在几分钟内将其部署到生产环境中，这种想法非常酷。你可以控制你的策略的版本，知道谁做了一个糟糕的合并，以及最后一个好的版本是什么。

还记得开发人员需要等待五周才能批准防火墙请求吗?那些日子一去不复返了。开发人员现在可以在几秒钟内创建安全组规则，并在更短的时间内向全世界开放端口22。

开发人员从不关心充满过时安全策略的冗长文档，他们从不阅读这些文档，即使您花费了宝贵的时间来更新它们，他们也不会这样做。

那么你应该怎么做呢?如果您正在考虑自动化您的安全策略，那么您应该拍拍自己的肩膀。为了跟上速度，云提供了你的业务;安全策略需要像您的基础设施一样灵活。您需要像您的应用程序团队一样快速或缓慢地移动。

在AWS、AWS组织服务控制策略、IAM策略以及特定于服务的策略(如KMS键策略和bucket策略)上定义策略的方法有很多。

自动化使这种灵活性成为可能，而编写策略是不可思议的，因为可以将安全策略视为基础设施和应用程序代码。策略可以在git中检入、修改、改进、重构、由多人查看，应用于应用程序代码的所有内容都可以应用于策略代码。

您可以使用Lambda和CloudWatch事件等服务，或者利用云托管等开源工具来帮助您通过自动化实现遵从性。

关键是，自动化您的安全控制，或者准备好输掉这场战斗。

实时检测、通知和修复是非常云化和人性化的。

如果您的开发人员在部署Prd期间向全世界开放了s3 bucket，请检测到这一点，并立即通知他们您已经检测到这个问题并为他们修复了它。如果您在产品投产两周后发现安全性问题，那么说服构建器修复它将不是一项有趣的工作。实时反馈通常很受欢迎，因为他们可以立即采取行动。

身份和访问管理

AWS  IAM

AWS IAM是AWS安全的核心。如果你和我的忍者交谈，他们会告诉你，让AWS的IAM正确是一个游戏改变者，因为在我看来，这是AWS最强大的服务之一。

AWS IAM使您能够定义非常细粒度的策略，帮助您轻松设置边界和实现最小特权原则。IAM集成了所有AWS服务，甚至包括允许您直接在其上建立策略的服务，如s3和KMS。

IAM的关键是使用角色并假设这些角色，而不是在任何地方都必须使用API键。此外，尽可能自动化策略、组和角色的创建，并为策略、角色和组定义良好的命名转换，以避免配置偏移。理解条件和IAM操作可能比较棘手，但是如果您想要严格控制访问策略，那么这是必不可少的。

我给您的建议是，请避免使用单一的AWS帐户模型，这样您就可以避免切割策略。

数据安全

通过加密静止、传输中的数据，并确保只有需要访问数据的人才能访问数据，从而确保数据的安全是至关重要的。尽管这看起来很简单，但是许多组织都不能理解它。

我经常在google上搜索s3 bucket泄漏的数据，并与我圈子里的人分享我的发现，以吓走所有人。我记得有好几天没有听到这种新闻。

我学到的教训是尽早对数据进行分类，并确保所有数据存储都有所有者。您还应该加密所有内容，并确保所有数据存储都受到保护。

KMS是不可思议的，因为它为您完成了所有繁重的工作，创建主键、数据键和键旋转都是由AWS为您管理的。如果你想有更多的控制权，你可以带客户的钥匙，自己管理他们。

基础设施安全

由于AWS为您处理物理基础设施安全性，所以您可以关注VPC中的流量和资源的安全性。首先创建私有和公共子网，使用VPN或bastion主机访问服务器。使用nacl和安全组来限制流量是必须实现的最佳实践。

通过利用不可变基础设施的概念，避免使用SSH之类的协议，因为它本质上提供了更大的安全性。

不修补实例只是重新构建一个新的AMI，不进行适当的更新，只是从一个基本映像进行销毁和构建。

使用AWS git-secrets检测意外签入git存储库的密钥。使用EC2角色而不是API密钥，也不要忘记您的EC2密钥对，如果这些泄漏，rest确保您的服务器将在短时间内挖掘比特币。

如果您使用s3作为静态web主机，我强烈建议使用CloudFront发行版作为bucket的前端，并利用AWS原始访问标识将bucket限制在发行版中。该模式将对象隐藏起来，使您能够访问AWS WAF和Shield等不能直接与s3一起工作的安全特性。

 

弹力

Netflix混乱的猴子

高可用性、操作的连续性、健壮性和恢复能力以及灾难恢复通常是使用AWS部署云的原因。多az和多区域部署都是我们都需要根据AWS架构良好的框架进行调整的模式。

使用诸如AWS架构良好的工具可以帮助您在AWS上部署更具弹性的工作负载。AWS使您更容易为失败进行架构，大多数服务提供高可用性和持久性，其他服务可以被架构为更具弹性。AWS建议我们在设计时考虑四大支柱;安全性、可靠性、成本优化和性能。

AWS架构的四大支柱

在完成设计和实现阶段之后，可以通过引入混沌工程和增强对基础设施的信心来测试基础设施，还可以定义能够帮助您在出现故障时更快地恢复的过程。您可以从单个节点(AZs)开始测试，或者取下整个区域，看看您的应用程序如何处理这些问题。

日志记录和监控

必须启用CloudTrail、Config和VPC流日志，并将其聚合到日志帐户中。您还应该确保在每个区域中都启用了这些服务，如果有人试图禁用其中任何一个服务，则会通过自动化得到通知。

还应启用AWS guardduty和AWS SecurityHub;两者都提供出色的监视功能。被动监视是不够的，我们应该以实时自动化来应对安全事件为目标。

事件响应

说到实时自动化，我们应该拥有一个剧本，帮助指导我们业务中的安全专业人员和涉众更有效地响应安全事件。

不知道谁拥有这些数据，不知道如何处理一个受攻击的实例或更糟的事件——一个被劫持的AWS帐户——是一个糟糕的处境。我们需要尽可能地自动化，但我们也需要定义的职责和文档化的流程，以便我们可以参考。我认为这个主题写起来会很有趣，所以我很快就会在这里停下来写一篇博客!

DevSecOps

这是一个很像DevOps的流行词汇。DevSecops或SecDevOps是在CI/CD工作流上实现安全性的实践。当代码通过所有较低的环境进入生产环境时，将扫描并检查其安全性漏洞。

我们不会等到安全团队在我们的代码投入生产前的最后一分钟才祝福我们的代码，我们会尽早从安全性着手，在编写代码时使用IDE插件来查找安全性bug。使用Docker bench等工具以及其他可以轻松与Jenkins集成的工具是一个很好的起点。

DevSecOps是一种以“每个人都对安全负责”的心态来处理IT安全的方法。它涉及到将安全实践注入组织的DevOps管道。目标是将安全性合并到软件开发工作流的所有阶段。这与它的前辈开发模型相矛盾——DevSecOps意味着您没有为SDLC的最后阶段保存安全性。

合规验证

你有客户的信用卡信息吗?医疗保健信息?或任何个人识别资料(PII)?当您根据特定于行业的最佳实践检查基础设施时，您需要了解您正在做什么。

如果你不遵守行业规则，你就不能做生意。我们可以使用AWS配置规则来持续审计我们的基础设施。如果我们不需要遵守其他框架，如PCI DSS或HPPA，那么我们至少应该从CIS基准开始。

 

原文：https://itnext.io/architecting-security-governance-across-your-aws-accounts-part-1-introduction-ae200624424d

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】