编者按: 以下是Adobe赞助的博客文章:
在Adobe, 安全是我们的首要任务, 我们相信纵深防御, 从监控开始——从收集公共云提供商提供的事件日志和配置数据开始, 到EDR系统和漏洞扫描管道的日志. 这些日志由Adobe安全组织使用SIEM工具集中收集和分析，以便主动识别潜在漏洞或错误配置，并为产品团队生成操作项(以方便跟踪的票据形式).
但要有效地做到这一点，重要的是要确定谁拥有一组特定的资源. 在拥有数千个服务和开发人员的组织中，这不是一项简单的任务. 未分配或错误分配的票证可能会延迟安全问题的解决，从而增加遭受恶意攻击的风险.
那么，我们如何弥合可见性(使用监视工具在基础设施层检测潜在风险)和责任(及时分配和修复这些问题)之间的差距呢?? 通过在多个地方收集必要的所有权信息.
跟踪多个级别的所有者，以准确地路线票
在最高层次上, 团队从集中式云帐户管理门户提供云帐户, 他们在哪里提供他们打算如何使用所请求帐户的详细信息. 收集的与安全相关的元数据片段包括环境(例如.g., dev /阶段/刺激), 接触点, 一个记录安全罚单的Jira项目, 以及请求该帐户的团队或服务的名称. 最后一项是从服务注册中心选择的, 本质上是包含所有Adobe服务和产品的目录. 当与我们内部和商业工具的数据相结合时, 这有助于我们鸟瞰adobe拥有的公共云帐户中的所有资源和活动. 这些信息有助于确保每个VM、S3 bucket、EKS集群等都有一个所有者.它支持公共云上的Adobe应用程序.
除了全局帐户级元数据之外, 我们鼓励团队用任何其他相关信息标记他们的低级资源——包括vm和bucket, 比如他们希望在安检票上贴上标签, 为了更好的跟踪和优先排序. Adobe已经创建了一个资源标记标准，以确保在不同的团队中以统一的方式执行此过程. 虽然最佳实践鼓励团队为他们的微服务提供单独的帐户, 我们确实遇到过服务需要共享底层基础设施和, 因此, 在单个云帐户中运行. 在这里再次, 资源级标签帮助Adobe安全团队识别潜在问题，并将其路由给正确的微服务所有者.
解决共享多租户环境中的挑战
虽然这种问责制模型在虚拟机的世界里工作得很好, 在将应用程序迁移到容器时，事情变得有点棘手. 我们目前使用一个内部的基于kubernetes的平台，我们称之为“Ethos”，它提供了一个容器化的环境和一个托管的CI/CD管道, 它允许产品团队专注于他们的应用程序并加速GTM(进入市场)战略.
帮助推动采用, 我们保持了入门过程的简单:团队只需要提供他们的Git存储库(包含应用程序代码)和一个计费成本中心，以便在这个共享平台上提供名称空间, 它由大量Kubernetes (k8)集群组成，运行在AWS和Azure账户上，由Ethos团队拥有和管理. 在将团队迁移到这个共享多租户平台的同时, 我们开始开发工具，可以提供对固有的不透明Kubernetes基础设施的可见性. 其中一个工具, 法罗岛, 提供所有正在运行的k8s对象及其完整配置的快照. 除了, 我们建立了一个图像扫描管道来扫描cve的容器图像, 为Ethos实现良好的安全覆盖.
或者我们是这么认为的. 当我们回过头来评估端到端管道时, 我们意识到归因元数据是在云帐户级别, 这意味着我们将把安全问题路由给Ethos团队(平台提供商)，而不是相应的负责修复这些问题的产品或服务团队.
介绍Argus项目
我们必须发挥创造性来解决这个问题. 结果就是“阿古斯”项目. Argus的目标是将运行在Ethos上的成千上万个容器中的每一个归为一个产品团队和一个Jira项目，在那里我们可以记录安全票据. 我们决定专注于我们已经拥有的信息:Git存储库, 其中一些是私人的. 在与Git团队的讨论中, 我们发现可以利用GitHub api来检索公共和私有存储库的Git组织管理员. 有了这些信息，我们就有了第一个数据:接触点.
另一个元数据机会是工作流，它将vpc对等的Ethos云帐户与他们自己的帐户组合在一起，以便让他们在共享平台上运行的容器访问数据库和其他私有资源. 这有助于我们确定拥有给定名称空间集的产品团队，并通过元数据引导我们找到他们的Jira项目.
另一个数据源来自应用字符串相似性来匹配“应用程序名称”,这是一个自由格式的文本框，团队在加入Ethos时需要填写, 使用目录中的标准产品或服务名称并选择高质量的匹配项.
将所有这些数据源拼接在一起，我们一开始就得到了30%的归因. 我们构建了一个UI，并定期向确定的所有者发送电子邮件，以检查和填写剩下的70%的元数据. 一年后, 在顽强地推动采用的项目经理的帮助下, 我们已经非常接近100%归因目标了.
协作和问责制是有效安全的关键
最后, Adobe安全团队与Ethos和服务注册团队合作，以确保我们收集了正确的元数据，并在平台登录过程中添加了验证检查, 防止这个过程成为一个不断移动的目标. 再一次。, 对于团队需要在单个k8s名称空间内运行多个微服务的情况, 应用在单个pod上的注释可以覆盖名称空间级别的默认值，并提供更准确的属性.
总之, 虽然很多注意力都集中在增强系统的可见性上, 同样重要的是，帮助确保正确的工程师和团队了解并负责有效的安全. 由于缺乏良好的归因元数据，安全工具可能会发现产品或服务团队无法发现的漏洞. 以标准化的方式收集属性元数据(例如.g., 更少的文本框和更多的下拉菜单有助于弥合这一差距, 从而提高整体安全态势.
作者简介: Gurneet是Adobe运营安全团队的成员，该团队负责开发和管理工具，以帮助改善Adobe在所有产品运营中的安全状况. 她住在印度诺伊达. 在Adobe之前，Gurneet是印度空间研究组织(ISRO)的实习生。.
