本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
最佳实践
在实施新 DevSecOps 机制时,至关重要的是要考虑代码创作权的各种来源,以及它们将如何获得授权或可能被屏蔽。通常,工程师只能与其中一个来源进行交互。但是,引入新机制可以将新的作者来源置于最前沿,或者突出来自以前未考虑过的来源的挑战。让我们更详细地探讨以下每个方面:
-
应用程序团队开发人员 — 他们是负责核心应用程序代码的开发人员。必须授权他们根据需要对应用程序代码进行更改和更新,但他们的工作也必须与新 DevSecOps 机制保持一致。
-
中央基础设施开发人员-该团队负责组织的核心基础架构,例如云资源、网络和安全。他们必须参与定义基础设施即代码 (IaC) 和部署流程,以确保新机制的无缝集成。
-
第三方和开源代码库-使用第三方库和开源组件很常见。但是,在新 DevSecOps机制中,必须谨慎管理并保护这些来源。
-
可重复使用的代码和构件 — 促进可重复使用的代码和工件的创建和使用可以提高效率和一致性,但是必须明确定义这些共享资源的所有权和治理。
-
共享存储库和贡献 — 通过共享存储库启用协作代码创作可能很有帮助,但需要仔细管理访问权限、合并策略和代码审查,以保持质量和安全性。
-
IaC 的分支策略 — Git 方法与常见的基础架构设计模式不直接兼容。可能需要针对IaC调整传统的分支策略,以适应管理基础设施的独特挑战。这可能涉及开发专门的工作流程,这些工作流程要考虑基础设施的状态性质、漂移的可能性,以及在更改实时环境时进行仔细的协调。
-
状态管理 — 在 IaC 中,管理基础设施状态至关重要。适当的状态管理可确保实际基础架构与定义的代码保持一致,并防止冲突或意外更改。实施强大的状态管理实践,例如使用远程状态存储和状态锁定机制,对于在多用户环境中保持一致性和防止冲突至关重要。
-
安全-在 IaC 和的背景下 DevSecOps,必须将安全性集成到基础设施生命周期的每个阶段。这包括保护 IaC 代码库本身、实施最低权限访问控制、加密敏感数据以及定期扫描基础设施代码和由此产生的已部署资源中的漏洞。应将自动安全检查和合规性验证纳入持续集成和持续交付 (CI/CD) 管道中,以确保始终如一地应用安全最佳实践。
要设计一种能够有效授权和支持不同团队的 DevSecOps 机制,就需要您确定所有潜在的代码创作来源,并了解他们的需求和挑战。这种方法有助于确保新机制在整个组织中顺利实施和采用。
设计 DevSecOps 机制远不止是技术方面。 DevSecOps 机制的设计和实施具有深远的影响。负责的团队必须仔细考虑文化、组织和人为因素。这种考虑有助于确保解决方案不仅符合技术要求,而且还能为所有利益相关者营造一个积极、富有成效和引人入胜的工作环境。保持适当的平衡对于长期成功和员工满意度至关重要。
考虑以下与 DevSecOps机制设计和部署相关的场景:
-
扩大开发人员和维护者之间的差距 — 实施一个让渴望的开发人员能够轻松快速交付解决方案的系统可能会无意中凸显出维护人员明显缺乏工作的情况。维护者是拥有开发者头衔的个人,但他们的 day-to-day职责已转移到现有应用程序的支持和稳定性上。从历史上看,维护者缺乏新贡献可能不那么明显。这种情况可能导致组织低估这些维护者的关键知识和专业知识,从而可能引起怨恨和士气下降。
-
用过度治理的解决方案击退开发人员 — 构建一个高度管理的 DevSecOps 解决方案,对于渴望开发者来说使用起来很麻烦,可以吸引维护者。但是,该解决方案可能会驱逐组织推动创新所需的人员。除了应用程序和编程语言之外,强迫开发人员学习专有的 CI/CD 机制可能成为采用的重大障碍。高度管理的 DevSecOps 解决方案可能会抑制才华横溢的开发人员。
-
冒着文化不兼容和颠覆的风险——实施一种在文化上与组织现有工作方式不相容的 DevSecOps 机制可能会造成严重的摩擦和阻力。如果该机制的方法(例如,与咨询相比,规范性方法)与组织的文化不一致,则很可能不会被采用。结果,一些利益相关者可能会感到沮丧,并认为该组织正在走向不必要的官僚机构。