AWS公司首席安全官分析和探讨AWS公司的规范性安全性

​尽管AWS公司提供了多种云安全工具，但其理解和实施因用户而异，这可能导致危险的结果。 随着云安全变得越来越复杂，作为全球最大的云计算提供商，AWS公司在建议和协助客户避免常见陷阱方面发挥了更加积极的作用。Steve Schmidt对AWS公司对客户安全采取了更具规范性方法的原因，以及它如何影响事件响应等领域进行了分析和讨论，并解答了为什么限制对云计算资源公共访问这样的问题。随着越来越多的企业将业务迁移到云平台并需要不同级别的指导，AWS 公司扩展了一些方法以提供默认和规范的实施需求。 Schmidt表示，尽管目前采用云共享责任模型，但优先考虑客户服务对于云计算提供商来说是必须采取的措施。他探讨了AWS公司近年来为减少错误配置所做的更改，以及它在事件响应中的作用以及AWS公司如何解决云服务的漏洞。 你曾经在一次主题演讲中谈到了限制用户对AWS云计算资源的公共访问。这似乎在影响客户的大量常见错误配置方面取得了进展，因为我们看到的意外数据泄露或违规事件越来越少，这是怎么做到的? Schmidt：在三年前，我们在默认情况下为S3启用了“阻止公共访问”。对于默认关闭的实例，我们一直采用安全组防火墙规则。自从开始提供服务以来就是这种情况。这是我们长期以来认真对待的事情。而且我认为很多客户对提供的安全工具有了更多的了解;例如，如果使用GuardDuty，它会告诉用户是否有暴露的资源，并会发出警告。现在，用户决定做什么取决于他们自己。我们作为云计算供应商并不知道他们的业务是什么。他们可能正在运行一个网站，在这种情况下，开放它可能是完全合理的。我们对这些不知情是因为没有看到他们的数据。但与此同时，我们必须向他们提供阻止公共访问这样的信息，并向他们说，“请检查一下，可以吗?” 你是否了解AWS公司就公共访问与客户联系的频率? Schmidt：除非是特殊情况，否则我们的安全团队不会主动与客户联系。例如，当Log4J漏洞事件发生时，我们确实联系那些可能易受攻击的客户，并在这种情况下向他们发出警告。但是，在大多数情况下，客户订阅的工具会通知他们。GuardDuty就是警告他们的工具。 具有讽刺意味的是，我的团队很久以前就构建了GuardDuty，这是一个关于用户界面的非常棒的工具。很多人并没有意识到为了启动GuardDuty需要进行大量的配置。花费一段时间才启动它的原因之一是我们构建了用户界面，所以实际上只有一个复选框可以打开它。它成功了。我们看到的效果是惊人的。但是它的启动需要更加简单一些，可以让客户轻松做出决定。 你是否从客户那里得到了很多关于如何进行配置和正确设置资源以使其不公开的反馈?看起来，尽管云服务的设计比客户管理自己的基础设施更容易，但云计算客户仍然在与所有安全控制、设置和配置作斗争。 Schmidt：我们并没有听到多少这样的反馈。我们从客户那里听到的是要求给他们更多规范性指导的请求。他们希望我们告诉他们做事的正确方法。所以我们选择做的是在开始引入的一些服务中体现这一点，例如GuardDuty;它有一套非常规范的标准规则。如果客户愿意，可以选择关闭它们，但它们在默认情况下存在，而客户告诉我们，“你比我更了解这些情况，所以要告诉我应该怎么做。” 在规定性指导上，这种方法是出于客户的要求而采取的必要措施?还是随着云安全变得越来越复杂，最终不得不这样做? Schmidt：两者兼而有之。我们首先要做的是了解客户希望能够使用的选项，然后我们构建了这些选项。然后我们说，“我们现在有很多选择。”而客户往往希望更加简单。有些客户需要默认设置，有些需要指导，还需要规范性实施。而在另一方面是真正的大客户，他们希望采用定制服务，而这些客户是真正希望自己有控制权利的人。我们必须为这两种客户提供服务。现在，客户看到的是GuardDuty之类的复选框将附带的内容，所有功能均已启用。但在幕后，有些客户可以根据具体情况调整这些规则中的每一条，但是我们从认为合适的默认值开始。 如何将事件响应因素纳入这一规定性方法?让我们以Zoom为例，AWS公司已经与该公司合作，帮助扩大其事件响应团队，并提供培训和指导。但是假设遭遇一次重大的网络攻击。即使网络攻击与AWS公司的技术无关，那么AWS公司在事件响应方面的作用是什么?是否调动了安全团队并让客户与他们联系? Schmidt：是的。客户可以联系服务团队和技术经理。通常情况下，我们会了解客户在做什么以及需要什么帮助。然后我们将让相关方参与。我们会为他们提供帮助。这通常可以做一些事情，例如展示他们需要查看的日志以确定正在发生的事情，并为这些日志构建查询，这将为他们提供帮助。还教客户如何启动EMR集群(如果他们以前没有这样做过的话)来解析日志。我们还可以帮助客户做一些事情，例如确保他们适当地对磁盘进行快照，以便他们可以对快照进行取证。 这取决于客户。我们通常可以做些什么为他们提供帮助，这将使他们的员工腾出时间去做自己的事情。例如，我们可以很容易地帮助他们提供快照，因为这是从外部进行API调用的。但我们不能去查看他们的日志，并指出哪些日志有意义，因为那是他们的应用程序，所以这在多个方面进行分工，并确保他们拥有正确的专业知识来提出正确的问题。 这种方法似乎是对云计算责任共担模型的一种转变。在这种模式下，如果在客户的环境中发生安全事件，那就是客户的责任，而不是云计算提供商的责任? Schmidt：尽管我们有共享责任模式，但总是在客户遇到问题时为他们提供帮助。这就是亚马逊公司秉承的一种企业精神。这正是我们内部建立客户服务流程的方式。我们所有高管都经历过一个客户连接客户服务(C2CS)的过程。例如坐下来接听客户服务电话，回答客户问题。首先，可以了解客户的真实感受以及他们的工作方式。但这也是一个让客户开心的机会，因为我们会说，“没问题，我们可以解决这个问题”。我们不会说，“对不起，那是你的问题”，因为这不是我们开展业务的方式。其次，告诉客户“对不起，你只能靠自己了”可不是什么好生意。这不会更好地为客户提供服务。 随着云计算提供商在安全方面发挥更积极的作用，并积极参与应对事件，分担责任似乎正在发生一些变化。你是否担心AWS公司会被进一步纳入事件响应流程? Schmidt：我认为这取决于个人客户。我们提供了所有客户可以订阅的正常服务。我认为这是重要的事情之一——我们将尽所能帮助客户。我们往往“尽力而为”，在这种情况下，我们必须在特定的服务水平协议(SLA)内做出响应。对于那些想要获得帮助的客户，他们通常签署了支持合同。对于其他情况，我们将在适当和合理的情况下尽可能地提供服务。在那里，合理性是一个相对重要的术语。如果有客户说，“请你帮我分析2EB的日志?”然后我们会告诉他们这有点困难。 云计算漏洞的话题最近一直是信息安全社区关注的一个重点，因为没有像传统软件漏洞那样记录它们的通用漏洞披露(CVE)系统。一些专家试图通过启动他们自己的云计算漏洞开放数据库来启动这项工作。你是否认为需要包含云计算漏洞的更好的通用漏洞披露(CVE)系统，即使这些错误不需要与客户的那部分交互?这会让客户受益吗? Schmidt：我不这么认为，其原因是客户的数据已经存在。如果他们在选择的搜索引擎中搜索“AWS安全公告”，将直接进入我们详细描述所有内容的页面。还有一个必须去看看的地方，这不会是权威的信息，我认为这对客户没有帮助。它可能会帮助那些出售工具的人。但是数据就在那里，这很重要。在特定的数据中，我们真正关心的是客户是否必须做些什么。这就是为什么我们总是把它列入安全公告的原因。它非常明确地指出客户需要采取行动，或者客户应该更新到版本X或其他任何内容。 我们非常努力地找出正确的信息级别，以便它有用且不嘈杂。噪音部分是一个问题，因为如果互联网上的每一个异常都被报告到某个地方，那么人们就会迷失方向，错过真正重要的东西。客户需要阅读的部分是采取行动的部分，也就需要更新软件。我们不只是发布公告。实际上我们有一个流程，可以向客户推送警报。如果我们知道客户正在运行RDS MySQ L 3.8.4，将会向他推送一条消息，说明3.8.4版本中存在需要更新的漏洞。客户需要选择在维护窗口期间接受我们提供的软件更新或立即自行更新。