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