详解 DevOps 在企业云安全管理中发挥作用的八大方式

一般来说，安全属于信息安全团队的管辖范围。直到几年前，这种网络安全方法一直运作良好。 向云计算基础设施的转变创造了一个分散的软件开发环境，这对软件开发的增长和规模起到了重要作用。DevOps 帮助团队以更快的速度创建、测试和实施软件——通过在整个软件开发生命周期中使用广泛的服务来支持这种敏捷性。然而，这样做也引入了新的网络安全漏洞，传统的信息安全孤岛无法管理这些漏洞。为了保护 DevOps 环境，创建了 DevSecOps 部门——一个主要支柱是秘密管理的领域。

1. 网络安全是必须的

云计算安全已成为 DevOps 团队职责的一个组成部分，积极主动地进行云安全管理 (CSM) 至关重要。

2. 云安全：防止秘密泄露

除了创建软件外，开发人员现在还必须保护企业的机密免遭未经授权或未经身份验证的访问，并且在开发过程中这样做。秘密是支持访问权限的数字凭证——无论是人对应用程序还是应用程序对应用程序。后者使用“秘密”，例如密码、加密密钥、证书和 API 密钥等。 为了让 DevOps 保护代码免受秘密泄露导致的数据泄露，他们必须首先了解秘密在其环境中扩散的多种方式。秘密通过七个驱动因素滚雪球，包括：基于云原生的开发、多云基础设施、微服务架构、从用户身份到机器身份的转变、AL/ML/数据分析、物联网/嵌入式设备。 这些驱动程序会产生漏洞，因为它们允许更多的错误机会 – 无论是硬编码秘密以加速测试，使用不安全的开源库，还是忽略考虑云的安全性。 虽然有各种技术可以帮助管理机密，包括商业和开源，但一定要考虑企业的预算和要求、当前部署的技术、 DevOps 团队在机密管理方面的经验，以及实施和保持这些技术最新和更新的机会。

3. DevOps 团队保护云基础架构的八种方式

(1) 确定必要的要求

预先警告是预先准备好的，所以这个过程越早开始越好。大多数公司已经至少部分地在云上，所以有时很难退后一步了解大局。 不要忘记——云服务不仅仅是 AWS、Azure 和 Google。云服务涵盖所有这些 SaaS 应用程序。团队是否在使用 Slack 或其他基于 SaaS 的 DM? 如果开发或 DevOps 团队正在使用他们的 Slack 频道来分享公司机密，那么通过暴力攻击获得 Slack 访问权限可能会使整个企业处于危险之中。 需要通过明确的治理来定义和管理对 CI/CD 管道的访问。 由于大多数数据泄露是由导致配置错误、机密泄露和糟糕的数字卫生的人为错误引起的，DevOps 和 DevSecOps 负责管理谁可以访问什么——这是每个连接的安全系统的基本要求。 DBA 需要与开发团队等不同的数据访问权限。通过遵循最小访问权限策略并结合正确配置的堆栈，企业将能够降低风险。 所有 IaaS、PaaS 或实际上任何 XaaS 都需要在最基本的级别(凭证级别)进行保护。Google 会定期向其商业客户发送警报，通知他们潜在的凭据泄露。 无论要做什么，都不要忘记 ShadowIT – 确保企业中的每个人都知道他们的凭据泄露可能是最薄弱的环节。ShadowIT 增加了凭证泄露的风险，仅仅是因为 IT 没有意识到许多外部平台突然连接到受控的内部系统。 最后，要从别人的错误中吸取教训。英特尔有一个方便的安全清单，企业可以将其用作确定云安全要求的基础。

(2) 定义架构

一旦确定了企业的云安全要求，企业将更全面地了解已经使用的云服务类型以及需要添加的其他服务。 云安全始终需要放在首位。企业也有责任保护自己的应用程序、数据、操作系统、用户访问和虚拟网络流量。除此之外，磨练企业员工的配置基础知识。超过 5% 的 AWS S3 存储桶被错误配置为公开可读。 虽然三大云已经投资了很多来保护他们的堆栈，但 PaaS 公司没有这些预算——所以，一定要仔细检查。它被称为“零信任”是有原因的。 借助 SaaS 和 Web 安全，凭证保护再次成为关键。 每种架构类型都需要自己的安全类型——勤奋。例如，混合云基础设施需要“三重打击”的安全性——本地需要高度安全，所有端口都关闭、表面积跟踪，以及高度活跃的安全运营中心 (SOC)。公共云方面需要使用该公共云堆栈可用的最新和最强大的安全技术来保护。它们之间的连接也需要保护免受攻击。

(3) 分析现有控制并找出差距

对安全堆栈采取零碎的方法效果不佳;从头开始构建显然是一种更彻底、更合理的方法。以下是一些使这成为可能的选项：

云访问安全代理 (CASB) 云工作负载保护平台 (CWPP) 云安全态势管理 (CSPM) 静态应用程序安全测试 (SAST) 数据丢失防护 (DLP)

CASB 充当企业和云服务提供商之间的中介 – 并提供配置审计、数据丢失预防、治理和监控等服务。常见的 CASB 包括 Broadcom、Palo Alto 和 Forcepoint。 CWPP 可防止系统过载，例如导致潜在内存溢出的 DDoS 或错误代码。他们监控部署在云基础设施上的云计算资源。CheckPoint、Trend Micro 和 Carbon Black 都提供 CWPP。 CSPM 通过提供持续审计以检测错误配置(包括 Spectral 等)来帮助检测人为错误(安全漏洞的主要原因之一)。 SAST扫描源代码中的潜在漏洞——例如测试后忘记的硬编码数据库访问凭证——以防止由于人为错误/遗漏而泄露机密。 DLP 可能是 CASB 的一部分，也可能是一项单独的技术，通过降低/消除数据泄露风险(无论是不良行为者还是内部资源)，提供工具和策略来保护敏感数据。 这些工具可以单独使用，也可以作为更大安全堆栈的一部分使用。它们可以在整个组织内或仅在特定领域内使用——例如用于开发的 SAST。

(4) 专注于保护自己的的云机密

首先，在理想世界中，通过教育、以安全为中心的文化和足够的工具，永远不会泄露任何机密。但人为错误永远存在。新版本需要更安全。开发人员面临着将代码发布出去的巨大压力。有时他们会采取捷径或尝试使用一个易于记忆的密码来简化跨工具的访问，或者他们使用易于猜测的模式轮换密码。 因此，重点需要放在凭证保护上。密钥和密码需要在可能的情况下自动轮换，无需人工交互。它们必须足够强大以承受攻击。 不要忘记培训员工了解“典型”威胁，例如网络钓鱼、网络钓鱼、中毒链接等。 然而，无论团队多么谨慎，我们都会犯错误。

(5) 扫描错误配置

如前所述，在追求更快、更快、更好的竞赛中，开发人员一直专注于将代码发布出去。加速该过程的一种方法是将机密(例如数据库访问)硬编码到配置中。有时，他们通过将“读取访问权限”设置为“公共”以进行 QA 和测试来偷工减料。 问题是开发人员有太多他们关注的其他事情，以至于他们有时会忘记删除这些访问权限——从而使整个系统易受攻击。自动配置扫描是发现这些类型错误的关键，因为没有人真正有时间专门检查每一行配置代码。

(6) 关注最少访问原则

在理想的世界中，每个人都是 100% 有能力和诚实的，从不犯错误或考虑做错事。 在现实世界中，执行最少访问权限原则——将访问权限限制在严格需要的人身上——将通过降低错误风险、限制损害范围和加强安全性来实现更好的访问管理。例如，当一名会计员工出现错误时，这样的政策可以大大减损失。诚然，最小访问权限可能不是一个足够强大的解决方案，需要通过持续监控来补充，但可以通过以下方式加强：

消除最终用户计算机上的管理员权限 更好地保护帐户凭据 监控特权会话以确保正确使用 限制开发人员访问，除非他们有特定要求 限制对生产系统的访问

权限访问管理技术提供监控、审计和合规性实施。一个好的权限访问解决方案允许轻松分配或即时拒绝，确保仅根据需要进行访问。

(7) 全面且持续地保护 CI/CD 管道

向左移动是关键。安全性应该从第一行代码开始，而不是留给 QA 或测试。主动安全降低了整个 SDLC 出现问题的可能性——从防止不合规和配置错误到限制秘密泄漏和凭证漏洞。 主动和被动安全需要与开发的每一步齐头并进，在加快响应速度的同时保持一切敏捷。每个开发人员都需要考虑安全性，并且需要检查新旧代码是否存在潜在漏洞。

(8) 保持简单

自动化是确保整个 SDLC 安全的最快捷、最简单的方法。配置检查、秘密扫描器、身份访问管理、治理、合规性、屏蔽和合成数据都是重要的解决方案。关键是找到能够最大限度地提高云安全性、最大限度地减少误报并保持高质量代码快速且廉价地推出的组合。 最好的解决方案是最简单的：使用最少的工具构建安全堆栈，提供最高级别的安全性和最低级别的误报。不幸的是，实现这种效果相当复杂。许多公司提供可以简化流程的一体化工具或兼容套件，但不能总是指望这一点。与所有庞大的项目一样，最好的方法是一次迈出这一步。 永远不要忘记云安全，企业应检查自己的服务水平协议，找出云提供商留下所有漏洞并进行修改。