一般来说，平安属于信息安全团队的管辖范畴。直到几年前，这种网络安全办法始终运作良好。
向云计算基础设施的转变发明了一个扩散的软件开发环境，这对软件开发的增长和规模起到了重要作用。DevOps 帮忙团队以更快的速度创立、测试和施行软件——通过在整个软件开发生命周期中应用宽泛的服务来反对这种敏捷性。然而，这样做也引入了新的网络安全破绽，传统的信息安全孤岛无奈治理这些破绽。为了爱护 DevOps 环境，创立了 DevSecOps 部门——一个次要支柱是机密治理的畛域。
1、网络安全是必须的
云计算平安已成为 DevOps 团队职责的一个组成部分，积极主动地进行云平安治理 (CSM) 至关重要。
2、云平安：避免机密泄露
除了创立软件外，开发人员当初还必须爱护企业的秘密免遭未经受权或未经身份验证的拜访，并且在开发过程中这样做。机密是反对拜访权限的数字凭证——无论是人对应用程序还是应用程序对应用程序。后者应用“机密”，例如明码、加密密钥、证书和 API 密钥等。
为了让 DevOps 爱护代码免受机密泄露导致的数据泄露，他们必须首先理解机密在其环境中扩散的多种形式。机密通过七个驱动因素滚雪球，包含：基于云原生的开发、多云基础设施、微服务架构、从用户身份到机器身份的转变、AL/ML/ 数据分析、物联网 / 嵌入式设施。
这些驱动程序会产生破绽，因为它们容许更多的谬误机会 – 无论是硬编码机密以减速测试，应用不平安的开源库，还是疏忽思考云的安全性。
尽管有各种技术能够帮忙治理秘密，包含商业和开源，但肯定要思考企业的估算和要求、以后部署的技术、DevOps 团队在秘密治理方面的教训，以及施行和放弃这些技术最新和更新的机会。
3、DevOps 团队爱护云基础架构的 8 种形式
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 平安的最快捷、最简略的办法。配置查看、机密扫描器、身份拜访治理、治理、合规性、屏蔽和合成数据都是重要的解决方案。要害是找到可能最大限度地进步云安全性、最大限度地缩小误报并放弃高质量代码疾速且廉价地推出的组合。
最好的解决方案是最简略的： 应用起码的工具构建平安堆栈，提供最高级别的安全性和最低级别的误报。可怜的是，实现这种成果相当简单。许多公司提供能够简化流程的一体化工具或兼容套件，但不能总是指望这一点。与所有宏大的我的项目一样，最好的办法是一次迈出这一步。
永远不要遗记云平安，企业应查看本人的服务水平协定，找出云提供商留下所有破绽并进行批改。