你的Amazon S3存储桶安全吗？你知道哪些是公共的还是私人的？你知道应该是哪一个吗？数据泄露代价高昂。众所周知，Facebook最近曝光了5.4亿条用户记录，这也是FTC罚款50亿美元的一个原因。不幸的是，这类违规行为越来越普遍。有一个账户显示，7%的amazonwebservices（AWS）S3存储桶是可公开访问的。虽然其中一些存储桶是有意公开的，但非公共敏感数据意外暴露在面向公共的存储桶中的情况非常普遍。  Databricks安全团队最近也遇到了这种情况。我们收到一个公共桶中包含的潜在非公共对象的警报。虽然结果是良性的，但我们开始改善我们的整体桶安全状况，并能够在任何时候都肯定地回答上述问题。我们不仅要对过去和现在不公开的内容进行更严格的控制，而且还要监控我们有意公开的资源，以防无意的曝光。我们的S3存储桶安全解决方案作为对初始警报的响应，我们采取行动确定所有S3存储桶和公共/非公共状态。由于Databricks是一家云本地公司，我们已经部署了JupiterOne，这是一个商业云资产管理解决方案，允许我们快速查询和确定哪些资产是公共的。可以使用开源工具，比如Lyft的地图绘制，它允许类似的查询功能。通过查询的输出，我们能够快速识别和分类我们的公共桶，并确定它们是否应该保持公开。在验证了我们的桶是否应该公开之后，我们想解决几个问题：我们有意公开的存储桶中是否有任何现有的非公开文件？我们如何防止水桶和它们的对象无意中公开？我们如何持续监控公共桶中的秘密并获得实时警报？工具为了解决这些问题，我们发现、实施并创建了工具。下面的每个工具都解决了上述问题之一。是的，等等为了解决我们的第一个问题：我们有意公开的存储桶中是否有任何现有的非公开文件，我们重新使用了Níels Ingi的YAR工具（通常用于扫描Github存储库中的机密）来扫描我们现有的公共存储桶。我们启动了EC2实例，同步了bucket内容，使用针对我们的秘密的附加模式定制了YAR配置，并运行了YAR。为了加快速度，我们编写了一个脚本，它包装了YAR，允许并行执行，并对结果应用漂亮的格式。带有秘密上下文的示例YAR输出如上所示，YAR为围绕秘密的行提供了上下文，这使我们能够更快地对识别出的潜在秘密进行分类。云托管访问管理为了解决第二个问题，即如何防止bucket及其对象无意中公开，我们使用了云托管。我们已经为其他目的部署了这个自我识别的"开源云安全、治理和管理"工具，很明显它也可以帮助我们完成这项工作。cloudcustidan的实时遵从性使用AWS Lambda函数和CloudWatch事件来检测配置的更改。我们添加了一个云托管策略来自动为bucket及其通过任何访问控制列表（acl）公开的对象启用AWS公共访问块。我们创建了一个内部策略和流程，以获取有意公开的桶的异常，这些桶需要保持禁用状态。这意味着，在云托管程序的强制执行和JupiterOne对配置了公共访问的bucket发出警报之间，我们可以确保我们的bucket都不是无意中公开的或公开对象的。S3机密扫描仪为了解决我们的第三个问题，即如何持续监控公共存储桶中的机密并获得实时警报，我们需要额外的保证，即我们有意公开的存储桶中的对象不会被非公共对象更新。重要的是，我们希望尽快得到这些信息，以限制我们在意外接触事件中的暴露。我们想出了一个简单的解决方案。我们使用S3事件来触发对S3桶中对象的任何修改。无论何时创建或更新bucket对象，bucket的事件都会为更改创建一个SQS队列条目。然后Lambda函数处理这些事件，使用模式匹配（类似于YAR方法）检查每个文件的秘密。如果找到任何匹配项，则将输出发送到警报队列。安全团队接收来自队列的警报，允许对潜在的暴露做出近乎实时的响应。S3机密扫描架构有了以上所有的问题，我们感觉很好，直到…难题在我们部署了上述工具后不久，Databricks安全团队就接到了一个警报，该故障似乎是由我们的新工具和流程引起的。为了解决眼前的问题，我们不得不回滚我们的云托管变更。通过Databricks的事后处理过程，可以清楚地看到，尽管已经发送了关于工具和流程更改的通知，但这还不够。我们的解决方案并没有得到普遍的理解，这给那些突然有桶强制执行访问限制的人带来了困惑。此外，在一个案例中，当安全团队跟踪到一个bucket是公开的时，它几乎被删除了。所有者表示不再需要存储桶，但在删除访问权限后（删除存储桶之前的一项预防措施）我们发现一个未知团队正在使用表面所有者未知的存储桶。很明显，明确的桶所有权是我们成功保护桶的关键。明确、权威的所有权意味着我们能够快速得到警报的答案，并为有意公开桶的例外程序提供一个负责方。虽然我们采用了一些使用标记进行所有权标识的最佳实践，但在实现中存在一些不一致之处。这意味着，即使人们"做正确的事情"，结果也不一致，也很难清楚地确定所有者。重新审视我们的解决方案当我们可以获得更清晰的所有权信息并提供更好的沟通时，我们不再强制执行最初的解决方案。我们再次转向JupiterOne来查询我们的S3所有权信息。有了一个字面的bucket列表，我们找到了每个AWS帐户所有者，以帮助确定每个bucket的明确所有者。我们发布了关于所有权所需标记标准的政策，以确保所用方法的一致性。我们还发布了一些政策，明确了云托管公共访问块和异常过程。我们的CISO向领导层和更广泛的公司发出了通知，以提高对我们新政策和流程的认识和支持。我们通过云托管将所有权标记强制添加到我们的总体技术策略中。重要的是，我们的沟通过程有助于确定对我们执法方法的一些修改。最初，我们确定要删除缺少兼容所有权标记的bucket。虽然这适用于非生产资源，但对于生产资源来说过于激进。相反，对于生产资源，我们更新了云托管程序，在我们的票务系统中创建带有定义的服务级别协议（sla）的票证，以确保所有权不会丢失太久，并且不会使关键资源处于风险之中。实施一个明确的所有权过程并向领导层提供清晰的沟通，AWS帐户所有者和用户比我们最初的技术解决方案实施花费了更多的时间，但这意味着这一次我们可以在不担心中断或意外删除重要内容的情况下启用它。Databricks喜欢开源Databricks是开源社区的一个重要参与者——我们是apachespark的最初创造者™，三角洲湖™，考拉和更多-和安全的数据是极其重要的我们。因此，我们很自然地为自己解决了这个问题，并希望与社区分享结果。然而，作为安全专业人士，我们考虑了哪些应该是我们产品的一部分。我们经常看到开源工具，但在本例中，我们发现对工具同样重要的是围绕这些工具的通信、策略和过程。基于这个原因，我们是一个开源桶旅-一个完整的解决方案，以确保您的公共桶。开源存储库包括每个解决方案阶段的详细描述，以及逐步实现的指南，包括实现的工具的代码。也许同样重要的是，它还包括维护明确的存储桶所有权、强制公共访问块和获取异常的策略。它通过电子邮件模板扩展了政策，以便领导层和用户沟通，以确保在实施之前对政策和流程有很好的理解。让我们都能够回答关于我们的公共S3数据的问题，避免成为问题的一部分。看看我们的开源桶旅解决方案。免费试用Databricks。今天就开始吧