将安全所有权扩展到整个组织

Clarke：(00:05)
Megan，非常感谢您今天能够光临。

Megan：(00:07)
非常荣幸。

Clarke：(00:08)
您能和我们谈谈您的背景以及您是如何来到 AWS 的吗？

Megan：(00:13)
我担任不同的安全角色已经超过 15 年了，最初是一家医院的网络安全专家。后来，加入西雅图的一家全球零售商，负责不同的安全工程和架构工作。实际上，我们在 2014 年成为了 AWS 的客户，我帮助制定了云安全战略，并在那里实施了安全控制。然后，我加入了 Slalom，成为他们开发安全运维团队的一员，帮助北美各地的客户做同样的事情，即制定云安全战略和实施安全控制。再后来，我加入了 AWS，实际上是作为太平洋西北地区的企业解决方案架构师，然后加入了安全专家团队。

Clarke：(01:02)
太棒了。

Megan：(01:03)
所以说，我来到这里差不多四年了。是的。

Clarke：(01:04)
很好。

Megan：(01:04)
谢谢。

Clarke：(01:05)
我认为您一定拥有计算机科学背景。是什么吸引您开始关注安全？

Megan：(01:12)
说起来真的很有意思。最初我从事的是机械工程方面的工作，我在波音公司实习了三个暑假，与 767-400 生产线的模具工程师一起工作。当时我问他们，如果他们有机会再去上学，他们会学什么？ 他们跟我说是计算机科学。我说，“好吧。” 后来我发现所有人都这么说。于是我说：“好吧，我要选计算机安全或计算机科学的课。” 后来发现，我很喜欢。真是太有趣了。这门课就是要解决谜题的，对吧？

Clarke：(01:47)
对。

Megan：(01:47)
班上一半的学生中途退出了，因为这不是他们的兴趣所在。而我一往无前。其中一门选修课是数字安全，这听上去很有意思。我上了那门课，然后就迷上了。我觉得真是太有意思了。只是有更多不断变化的谜题要解。实际上，我构建了 IDS 作为我计算机科学学位的毕业设计。我构建了一个小程序来分析网络数据包捕获，并确定恶意的网络行为。真是太有趣了。

Clarke：(02:21)
太棒了。很明显，这开启了非常棒的职业生涯。

Megan：(02:23)
是的。

Clarke：(02:24)
在 AWS，您是一名高级安全解决方案架构师。这是什么意思？ 您担任这个职位的主要职责是什么？

Megan：(02:33)
我帮助客户了解 AWS 的安全性。我指导他们构建基础、设置防护机制、实施安全控制，还帮助他们理解“云的运营模式是什么？ 是怎样一种情况？” 我还在活动、构建研讨会、构建者会议以及内部领域帮助培训客户。因此，我们在内部开展了一些项目，在这些项目中，我们举办了内部现场讨论，就安全的不同方面对他们进行培训。将他们的安全级别从 100 级提高到 300 级，帮助他们在与客户对话时更加高效。

Clarke：(03:20)
Megan，在 AWS，我们有非常强大的安全文化，我们有许多机制来帮助实施这种文化。您有特别喜欢的机制吗？

Megan：(03:29)
非常荣幸。我们的其中一个流程是提交 sev two。无论您在公司担任什么职位，如果您认为有安全问题，就可以提交一个工单，称为 sev two。另一方面，有一名安全工程师将帮助评估这是否是一个问题，并采取相应措施。如果不是安全问题，就没有问题。很好。不会指责任何人。我们的想法是，我们不希望任何人因为认为存在安全问题而感到担心或害怕。我们希望了解这种情况。我们希望以一种良好、积极的方式对此做出反应。这得到了领导层的支持，非常不错。我认为，很多时候，通过进行安全培训，当您与自己的领导交谈时，好像每个人都会积极地考虑安全问题。我认为这孕育了一种围绕安全的透明文化，以及我从未在任何地方见过的开放氛围。我对此心存感激。

Clarke：(04:44)
对。当您与整个客户组织中不同级别的所有不同客户交谈时，您是否鼓励他们关注某些特定领域，以帮助他们尝试建立自己的安全文化？ 那种没有指责的安全文化？

Megan：(05:01)
非常荣幸。我在许多领域都发现了这个问题。我倾向于鼓励客户建立一种思维方式，即运营他们的安全团队就是帮助企业、帮助开发人员。如果他们确实从安全角度将正确的事情简单化，铺平道路，这样如果他们采用正确的模型，确定透明的安全要求，就可以加快速度，不会遇到大量障碍。我认为，他们在一起合作时，在安全和开发之间达到了很好的平衡。我真的很希望看到这种方法对客户也有效。我也确实在一些客户案例中看到过。我认为，这只是提供了一种在安全方面和开发方面运营的好方法，在这两方面，他们相互合作，相互帮助。

Clarke：(06:00)
所以说，安全不是说“不”，而是实际上试图帮助他们取得成功的部门？

Megan：(06:05)
是的，当然。

Clarke：(06:07)
从客户领导的角度来看，公司的最高层领导可以做些什么来帮助培养我们试图在客户关系中建立的安全文化？

Megan：(06:20)
我认为，与传统方式有很大的不同，对吗？ 不仅仅是安全团队要对安全负责，这是不可能的。开发人员需要承担许多责任。实际上，我喜欢向客户介绍，“嘿，这是 AWS 和客户之间的共同责任模型，”但是您可以将所有不同的安全控制和云安全方面的共同责任模型扩展到您组织的其余部分，并使其对每个人都透明。

Clarke：(06:53)
对。

Megan：(06:53)
然后，让这些事情变得容易做，容易做对。实际上，是在您自己的组织内扩展共同责任模型，让每个人都明白，我认为这是一种非常有效的方式。

Clarke：(07:05)
太棒了。我敢肯定，您的许多客户拥有的安全专家比他们想要的要少得多。您是否见过安全团队可以将他们的关注点和影响力扩展到客户组织的其他部门的情况？

Megan：(07:22)
太多了。我认为，首先，我们并不总能找到合适的从业者。所以有时，这意味着稍微拓宽思路，想一下“如果您的安全人员不一定了解云，但他们对云感兴趣，请为他们提供通往云的道路。” 如果您的开发人员或 DevOps 人员对安全感兴趣，但不一定具备相关背景，请为他们创造条件。提供一些培训。我认为，有很多可用的工具。我最喜欢的其中一种方法是观看以前的 re:Invent 视频，re:Inforce，进行 30 分钟、45 分钟的安全基础最佳实践会议。很多与客户一起录制的视频都是很好的例子，展示了客户是如何做到这一点的，它们让我们跳出定势思维，我认为这真的很有帮助。此外，AWS 解决方案架构师助理或专业证书是获得这些基本概念的一个非常好的方法。当然，安全专员认证也非常好。

Clarke：(08:39)
过去的 18 个月，对每个人来说都很艰难。我们经历了疫情，更多的人居家办公。从某种程度上来说，疫情增加了还是减少了人们对云的采用？ 您在客户那里看到了什么？

Megan：(08:54)
非常荣幸。我看到一些大客户不得不增加他们对云的采用，以应对刚刚发生的变化。网上零售业务真正爆发，因为实体店不得不关门歇业。我们从中看到了一些有趣的模式。我认为，我们从其他客户那里学到了一些经验，这取决于他们如何着手构建他们的初始基础安全和多账户策略。如果他们能够利用自动化，会做得非常好，因为他们可以构建更多账户并实施自动化。他们已经实现了构建这些安全基础的自动化，他们的控制就在那里。然而，如果他们还未实现自动化，我们当然会为他们提供不需要自动化的方案，并让他们尽快升级。但是如果手动完成的话，就很痛苦，而且很慢。我认为，确保一切……所有防护机制、您的多账户都是自动化的，这很重要。我有一个很好的例子，说明了现实世界是如何迫使人们这样做的。我知道当我开始成为 AWS 的客户时，我们有两个开发团队。六个月后，有 20 个开发团队、系统投入生产，其他人都想加入平台。所以，我很早就学到了这个教训，我想很多客户都经历过这个教训。

Clarke：(10:31)
因为这样您就不得不返工，以达到想要的安全标准。

Megan：(10:35)
完全正确。

Clarke：(10:37)
因此，从某种程度上讲，安全团队，客户内部的安全团队。有没有一种方法可以让这种安全性引领客户走向云计算？

Megan：(10:50)
我认为，我在客户那里看到过这种情况，很多时候安全性是最后一项。但他们不必如此。我认为，如果他们可以采用他们在本地采用的安全框架，并针对云进行控制和更新，做一些映射，并提前将这些防护机制实施到位，将会容易得多。他们将为人们部署做好准备。而且，如果没有人逼您，那太好了。您可以定义一些指标。您可以设置自动化，而不需要有人敲后门说，“嘿，我们走吧。” 我还认为，作为一个安全团队，这给了我们这个机会，让我们对安全需求保持透明，帮助开发人员了解他们需要如何构建以及安全团队期望什么规格。我认为，这又回到了开发人员和安全之间的关系……这是一种更有效、更高效的关系，它将有助于实现开发人员试图实现的业务功能。

Clarke：(12:10)
对。我可以想象，一旦您看到安全团队在您之前采用云，您就会建立起一定程度的信心和信任，作为一名开发人员或产品所有者，您会想，“好吧，如果安全团队都在做这件事，我真的没有任何借口了。”

Megan：(12:25)
完全正确。我认为，我所看到的一件事是，如果客户给出这些安全要求并给出例子，比如内部 Wiki 方面的“安全的身份和访问策略是什么样的？”，“什么是安全的安全组，什么是不好的安全组？”，这和实际的例子真的相差很远。这正是我们正在谈论的。对于您的访问策略，没有与资源相对应的操作，诸如此类。另一件事是，如果开发团队因任何原因而受阻，这时安全团队挺身而出，例如，如果客户正在努力满足特定的安全要求，如果安全团队每周一次在办公时间或通过 Slack 频道提供帮助，对开发人员来说，这确实可以使整个过程变得更容易。他们拥有一支能够解决问题的团队。很多时候，他们与这些人建立友谊，这样他们就不必 24 小时被困在那里或发生类似的事情。他们只需执行一个快速反馈循环。也许，这也是一种反馈，比如，“嘿，我们的文档太复杂了，”或者“我们需要指定一些东西”，或者如果我们要求人们在主机上启动安全代理，为什么我们不为他们编写一个脚本，并在代码库中提供该脚本呢？

Clarke：(14:02)
通过您刚才分享的内容，我也听到了一些您的普通安全团队可能不具备的技能。因此，如果我们看一下传统的安全团队，他们一直在运行 IDS 和不同的网络服务，修补系统，无论是什么情况，但我听到了您的意见，如果我错了，请纠正我，安全团队现在必须真正了解开发周期是如何工作的，甚至可能知道如何编写自己的代码？

Megan：(14:33)
非常荣幸。我想我们没有……根据安全从业者的背景，您可能没有开发人员背景或 CS 学位，这不是必需的，但我认为了解一点 Python 编程对任何人都没有坏处，Cloud Formation 很容易学习。Ansible 只是一个 YAML 配置文件。我认为，像开发团队一样运营，使用敏捷实践和 Backlog，对于一个从安全角度管理优先级的产品所有者来说，绝对很有帮助。首先，了解开发人员如何工作，这实际上是一种非常有效的工作方式。当我还是一名从业者时，这就是我们做事的方式，因为，特别从安全的角度来看，事情变化得如此之快，业务需求也变化得如此之快。突然之间，您不得不扩大规模，改变运营方式。这可以帮助您有规律且有效地重新安排优先顺序，确定什么是应该优先考虑的。

Clarke：(15:39)
几乎是在组织内部将安全作为服务来运行吗？

Megan：(15:44)
确实是这样。

Clarke：(15:46)
很好。我们稍微转换一下话题，把注意力放在最近的新闻上。您不用费心寻找，就会听到一个又一个关于勒索软件的故事。您从客户那里看到了什么？在勒索软件缓解技术方面，您给了他们什么样的建议？

Megan：(16:11)
仅仅在过去的两个月内，我可能就勒索软件与客户进行了 20 多次直接对话。我喜欢这样的对话，就像在说，“嘿，我们想了解 AWS 传递的信息是什么。” 这意味着，他们把我们当成了合作伙伴，这太棒了。通常，我会列出 10 大最佳实践，因为勒索软件没有灵丹妙药。您真的必须有一个强大的安全计划，强大的安全控制，并确保它们有效地运作。但是肯定会涉及一些关键领域，因此我们将介绍多账户策略，即最低权限访问。我反复强调的一个方面是，您是否使用静态、长期的即时消息凭证？ 如果是，现在该审视一下，首先确定还有必要使用它们吗？ 我们是不是可以重新构建？ 如果真的需要它们，因为在某些情况下混合访问需要它们，那么我们要最大限度地减少附加到该凭证的访问权限，这样它们可以在环境中做的事情就很少了，然后监控它何时被使用，只将它作为一种风险。把它添加到风险登记簿上。不要让它消失。如果将来有机会弃用，就将其弃用。这往往是我们看到的其中一个最大的风险，可以说，我们希望确保我们能够主动帮助客户避免糟糕的日子。

Clarke：(17:44)
据我所知，勒索软件缓解实际上只是做了非常非常好的安全基础工作。这是一个公平的评价吗？

Megan：(17:52)
是的。修补并不是一个新概念。实际上，在 AWS，您可以通过许多不同的方式来实现这一点。您可以使用自动扩缩组进行淘汰和替换，并从您的 CICD 管线重新启动您的系统。您可以使用 Systems Manager。就这一点来说，Systems Manager 一半是操作工具，一半是安全工具。您能用它做的事情太神奇了。确实。有很多选项。我们也会谈到这些。我认为这是一个很好的对话，客户就此问我的另一个问题是，“嘿，我们以前在本地进行隔离网络的备份。我们真的有磁带备份，把它们放在铁山卡车上，这样就没人能接触那些备份了。我们如何在 AWS 中做到这一点？” 一切都是 API，所以它们是相互关联的，但是如果您将安全性、安全边界视为 AWS 账户，那么您可以创建一个单独的账户，使用不同的……并将备份发送到该账户。您可以使用推送拉取型机制实现自动化，以便拥有备份的登录账户。然后，您从一个已知的好的来源拉取一个单独的账户，可以使用 S3 对象块写入一次，从 S3 存储桶读取许多蠕虫，进行一些真正强大的安全控制，最大限度地减少访问，甚至减少账户管理员的数量。对于 AWS Backup，他们刚刚宣布，我想是两周前，或者是最近，AWS Backup 文件库锁定允许您做类似的事情，一次写入，多次读取，应用于该文件库。因此，基本上，这样做是为了防止您在备份完成后对其进行更改。您无法删除任何内容。借助 AWS Backup 文件库锁定，您可以设置策略、访问策略并防止他人对其进行任何更改。它本质上类似于 S3 对象块，因为数据存储在那里，在特定时间内禁止访问。

Clarke：(20:05)
明白了。除了您提到的一些工具和最佳实践之外，我没有听说的一件事是事故响应准备。这有多重要，客户在这方面应该做些什么？

Megan：(20:19)
当我们具体讨论这些勒索软件时，我总是会问客户：“您真正进行过勒索软件安全事件的桌面演练吗？” 因为，桌面演练非常重要。如果您从未从事过事故响应工作，那会是一种充满压力的情况。桌面让您有机会解决很多在实际活动中不需要处理的问题，您只需要专注于调查，不会有任何问题。在桌面演练中，您将进行一项基本的练习，我们如何知道事件发生了？ 我们是否可以访问我们所有的 AWS 账户来进行我们需要的调查？ 我们会在哪里看到事件？ 会通过我们的安全操作中心吗？ 我们是否有一个手册，概述了这些人需要进行的所有活动，以便他们能够一致地做出响应，并拥有做出这些决策所需的数据？ 然后，我们是否让正确的利益相关者参与进来？ 因为如果我们遇到安全事件，我们需要知道如何与我们的客户沟通，与他们的客户沟通。只是需要解决许多问题，我们的专业服务团队也可以参与进来帮助客户解决这些问题。我们已经这样做过很多次了，熟能生巧，对吗？ 我认为，每当对某个场景有恐惧的时候，就告诉自己，“好吧，练习。” 然后，就没那么可怕了。这就像练习和提高某项技能一样简单。

Clarke：(21:55)
您提到了其他利益相关者。所以，这不仅仅是安全团队的演练？

Megan：(22:00)
不，完全不是。

Clarke：(22:01)
哪些其他利益相关者应该参与这些桌面演练？

Megan：(22:06)
是的。当然，根据您的演练和遇到的事故的类型，法律部门、隐私团队、安全管理部门通常会参与进来成为您的帮助台，也可能是应用程序和开发团队，帮助了解我们是否要采取任何类型的缓解措施。这会对下游产生什么影响？

Clarke：(22:36)
我的意思是，客户层次结构的所有级别都参与进来了吗？ 我是说，首席执行官会参加这些桌面演练吗？ 或者，哪些级别？ 到什么程度为止？

Megan：(22:50)
是的。我认为，这取决于谁想要参与其中并了解这个过程，因为当您实际经历一个安全事件时，它通常是保密的。您要确保只有需要知道的适当人员知道该事件，这样沟通才能以有计划的方式进行。但是对于演练来说，没有理由不让那些想参与的人参与进来。如果首席执行官感兴趣，一定要让他参与进来。

Clarke：(23:21)
太棒了！

Megan：(23:22)
每个人都能从中学到东西。

Clarke：(23:24)
最近新闻中的另一个热门话题，也是客户经常询问的话题是零信任的概念。零信任对您意味着什么？

Megan：(23:34)
是的。传统上，对于我们环境的访问和安全控制，我们非常依赖网络边界。而今天，我们想要做的实际上是在 API 层进行身份验证和授权调用。这意味着，无论是用户访问我们的环境，还是 API 到 API 的调用，我们都希望确保网络通信路径中的每一步都经过身份验证和授权。

Clarke：(24:10)
Megan，感谢您今天能够光临。

Megan：(24:12)
是的。谢谢。真是太有趣了。