开发人员安全问题

DevOps并不意味着每个人都必须是开发和运营方面的专家。 在角色往往更专业的大型组织中尤其如此。 而是，DevOps思维的发展方式使其更加关注关注点分离。 在一定程度上，运营团队可以为开发人员（无论是本地部署还是在公共云中）部署平台，并且可以避开障碍，这对两个团队都是好消息。 开发人员可以获得高效的开发环境和自助服务。 操作可以集中在保持底层管道运行和维护平台上。

这是各种各样的合同。 开发人员期望ops提供稳定且功能强大的平台。 Ops期望开发人员将能够自行处理与开发应用程序相关的大多数任务。

也就是说，DevOps还涉及更好的沟通，协作和透明度。 如果不仅仅是在开发人员和运营人员之间使用新型隔离墙，那么它会更好。 操作人员需要对开发人员所需的工具类型以及通过监视和记录以编写更好的应用程序所需的可见性敏感。 相反，开发人员需要一些知识，以了解如何最有效地使用基础结构以及什么可以使夜间运行（字面上）。

相同的原则更广泛地适用于DevSecOps，该术语用于明确提醒我们，需要从购买内容到编写应用程序，构建，测试和在生产中运行整个DevOps管道中嵌入安全性。 开发人员（和运营人员）除了已经戴上的其他帽子之外，突然不需要成为安全专家。 但是，他们通常可以受益于对安全最佳实践的更多了解（这可能与他们习惯的习惯不同），并摆脱将安全性视为不幸的障碍的思维定势。

这里有一些观察。

“开放Web应用程序安全性项目（ OWASP ）的前10名”列表提供了一个进入Web应用程序中最重要漏洞的窗口。 Web程序员会熟悉列表中的许多条目。 跨站点脚本（XSS）和注入漏洞是最常见的。 但令人惊讶的是，原始2007年列表中的许多缺陷仍在2017年列表中（ PDF ）。 无论是培训还是工具上的最大错误，许多相同的编码缺陷不断涌现。

微服务 ），并可以放大某些安全措施的影响。 例如，正如我的同事Dan Walsh （ @rhatdan ）写道：“计算中最大的误解是您需要root才能运行应用程序。问题不在于开发人员认为他们需要root。而是因为他们建立了这个假设进入他们所构建的服务中，即服务无法在没有root的情况下运行，从而使我们所有人的安全性降低。”

默认使用root访问是否是一种好习惯？ 并不是的。 但这可以说是（也许）可以辩护的应用程序和系统，而这些应用程序和系统被其他方式充分隔离了。 但是，在所有内容都连接在一起，没有真正的边界，多租户工作负载的情况下，具有许多不同级别的访问权限的用户（更不用说在更加危险的威胁环境中进行操作了），捷径的余地要少得多。

无论如何， 自动化应该是DevOps不可或缺的一部分。 自动化需要在整个过程中包括安全性和合规性测试。 代码从何而来？ 是否涉及第三方技术，产品或容器映像？ 有已知的安全勘误表吗？ 是否存在已知的常见代码缺陷？ 机密和个人身份信息是否被隔离？ 我们如何认证？ 谁有权部署服务和应用程序？

您不是在编写自己的加密货币，对吗？

尽可能进行自动化渗透测试。 我提到自动化了吗？ 这是使安全性连续不断的重要组成部分，而不是偶尔执行的检查清单项目。

这听起来很难吗？ 可能有点。 至少可能有所不同。 但是，作为伦敦DevOpsDays OpenSpaces的参与者，我对我说：“这只是技术测试。它不是神奇或神秘的东西。” 他接着说，加入安全性并不是获得整个软件生命周期更广泛理解的一种方式（这不是一项不好的技能）。 他还建议参加事故React演习或夺旗演习 。 您甚至可能会发现它们很有趣。

本文基于作者将在5月8日至10日在旧金山举行的Red Hat Summit 2018上的演讲 。 5月7日前注册可节省500美元的注册费用。 在付款页面上使用折扣码OPEN18来应用折扣。

翻译自: https://opensource.com/article/18/4/what-developers-need-know-about-security

开发人员安全问题