DevOps 并不意味着每个人都需要成为开发和运维方面的专家。在角色往往更加专业化的大型组织中尤其如此。相反，DevOps 思想的演变使其更侧重于关注点分离。如果运维团队可以为开发者部署平台（无论是在本地还是在公有云中）并避免干预，这对两个团队来说都是好消息。开发者可以获得高效的开发环境和自助服务。运维可以专注于保持底层管道的运行和维护平台。
这有点像合同。开发人员期望运维提供稳定且功能正常的平台。运维期望开发人员能够处理与自行开发应用程序相关的大部分任务。
话虽如此，DevOps 也关乎更好的沟通、协作和透明度。如果它不仅仅是开发和运维之间的新型隔离墙，效果会更好。运维需要对开发者想要和需要的工具类型以及他们通过监控和日志记录编写更好的应用程序所需的可视性保持敏感。反之，开发者需要了解如何最有效地利用底层基础设施，以及什么会让运维人员夜不能寐（字面意思）。同样的原则更广泛地适用于 DevSecOps，这个术语明确提醒我们，安全性需要嵌入到整个 DevOps 管道中，从采购内容到编写应用程序、构建应用程序、测试应用程序以及在生产环境中运行应用程序。开发者（和运维）不需要突然成为安全专家，除了他们已经承担的其他角色之外。但是，他们通常可以从提高对安全最佳实践的认识（这可能与他们已经习惯的不同）以及转变观念（不再将安全视为某种不幸的障碍）中获益。
以下是一些观察结果。
开放 Web 应用程序安全项目 (OWASP) Top 10 列表提供了一个了解 Web 应用程序中主要漏洞的窗口。列表中的许多条目对于 Web 程序员来说都很熟悉。跨站脚本 (XSS) 和注入缺陷是最常见的缺陷之一。然而，引人注目的是，原始 2007 年列表中的许多缺陷仍然在 2017 年的列表中 (PDF)。无论是培训还是工具存在问题，许多相同的编码缺陷都在不断出现。
新平台技术加剧了这种情况。例如，虽然容器不一定要求以不同的方式编写应用程序，但它们与新模式（例如 微服务）相吻合，并且可以放大某些安全实践的效果。例如，正如我的同事 Dan Walsh (@rhatdan) 所写，“计算中最大的误解是您需要 root 权限才能运行应用程序。问题不在于开发人员认为他们需要 root 权限。而是他们将这种假设构建到他们构建的服务中，即服务在没有 root 权限的情况下无法运行，这使得我们所有人都变得不那么安全。”
默认使用 root 访问权限曾经是一个好的做法吗？并非如此。但对于通过其他方式充分隔离的应用程序和系统来说，这可以说是（也许）一种站得住脚的做法。但随着一切互联互通、没有真正的边界、多租户工作负载、具有许多不同级别访问权限的用户，更不用说日益危险的威胁环境，容错空间要小得多。
自动化无论如何都应该是 DevOps 的组成部分。这种自动化需要包括整个过程中的安全性和合规性测试。代码来自哪里？是否涉及第三方技术、产品或容器镜像？是否存在已知的安全勘误？是否存在已知的常见代码缺陷？机密信息和个人身份信息是否被隔离？我们如何进行身份验证？谁有权部署服务和应用程序？
您没有编写自己的加密代码，是吗？
尽可能自动化渗透测试。我提到自动化了吗？它是使安全性成为持续性的重要组成部分，而不是偶尔完成一次的清单项目。
这听起来很难吗？可能有点难。至少可能有所不同。但正如一位参加 DevOpsDays OpenSpaces 伦敦的人对我说：“这只是技术测试。它不是神奇的或神秘的。”他接着说，参与安全以更广泛地了解整个软件生命周期甚至并不难（这绝对是一项不错的技能）。他还建议参加事件响应演习或 夺旗演习。您甚至可能会发现它们很有趣。
本文基于作者将在 红帽峰会 2018 上发表的 演讲，该峰会将于 5 月 8 日至 10 日在旧金山举行。在 5 月 7 日之前注册即可节省 500 美元注册费。在付款页面上使用折扣码 OPEN18 应用折扣。
评论已关闭。