你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

创新安全性

创新是组织在数字时代的命脉，需要支持和保护。 创新安全性会保护创新过程和数据免受网络攻击。 数字时代的创新表现为使用 DevOps 或 DevSecOps 方法开发应用程序来快速创新，而无需等待传统的瀑布式阶段性计划，这在两个版本之间可能需要几个月或几年的时间。

要开发新功能和应用程序，需要成功满足下面 3 种不同的需求类型：

• 业务开发 (Dev)：应用程序必须满足业务和用户需求，这些需求通常快速发展。
• 安全性 (Sec)：应用程序必须能够抵御来自迅速发展的攻击者的攻击，并利用安全防御方面的创新。
• IT 操作 ()：Ops应用程序必须可靠且高效执行。

将这三个需求合并在一起并创建共同的文化至关重要，但通常具有挑战性。 开发、IT 和安全团队的领导必须共同努力来推动这种变化。 有关详细信息，请参阅领导力要求：融合文化。

观看以下视频，详细了解用于实现安全和快速创新的 DevSecOps 方法。

什么是 DevSecOps？

技术创新通常是在快速精益和敏捷开发方法的背景下进行的，该方法将开发和运营结合在一起，形成 DevOps 流程。 我们已了解到，将安全性集成到流程中对于降低创新流程、组织发展和组织中现有资产的风险来说至关重要。 将安全性集成到流程中会创建一个 DevSecOps 流程。

通过设计和左移来确保安全性

由于组织采用 DevOps 和其他快速创新方法，因此安全性必须成为贯穿组织及其开发过程的一条主线。 在流程的后期集成安全性非常昂贵，而且难以修复。

在时间表中将安全性左移，将其集成到服务和产品的构想、设计、实现和运营中。 随着开发团队转向 DevOps 并采用云技术，安全性必须是该转变的一部分。

在瀑布模型中，安全性在传统上是开发完成后的质量关口。

DevOps 扩展了传统的开发模型（人员、过程和技术），将操作团队包括在内。 这项更改减少了将开发团队和运营团队分隔开来所产生的摩擦。 同样，DevSecOps 扩展了 DevOps，以减少来自独立或完全不同的安全团队的摩擦。

DevSecOps 是将安全性集成到 DevOps 生命周期的每一个阶段，从构想开始，再到体系结构设计、迭代应用程序开发和运营。 团队必须同时与创新速度、可靠性和安全弹性这些目标保持一致。 在相互理解和尊重彼此需求的基础上，团队将首先解决最重要的问题，无论这些问题的来源是什么。

云采用框架的“组织”方法提供了有关组织中 DevSecOps 结构的进一步上下文。 有关详细信息，请参阅了解应用程序安全性和 DevSecOps 功能。

为何要使用 DevSecOps？

DevOps 带来了敏捷性，DevSecOps 带来了安全敏捷性。

世界上几乎每个组织都希望进行软件开发，来通过创新获得竞争优势。 保护 DevOps 流程对组织取得成功来说至关重要。 攻击者已经注意到这种向自定义应用程序的转变，并在攻击过程中越来越多地攻击自定义应用程序。 这些新的应用程序通常是有价值的知识产权的丰富来源，其中包含有价值的新创意，但这些创意尚未商业化。

要保护此创新，需要组织解决开发过程和托管应用程序的基础结构中的潜在安全漏洞和攻击。 此方法既适用于云，也适用于本地。

攻击者可能会利用以下内容中的漏洞：

• 开发过程：攻击者可能会发现应用程序设计过程中的弱点，例如，使用弱加密或不加密进行通信。 或者，攻击者可能会发现设计实现中的弱点，例如，代码不验证输入并允许 SQL 注入等常见攻击。 此外，攻击者可能会在代码中植入后门，这样他们稍后就能回来，在你的环境或客户的环境中利用这些后门。
• IT 基础结构：攻击者可能会使用标准攻击来破坏开发过程所在的终结点和基础结构元素。 攻击者还可能执行多阶段攻击，使用盗用的凭证或恶意软件从环境的其他部分访问开发基础结构。 此外，软件供应链攻击的风险使得将安全性集成到你的过程中至关重要，目的是：
• 保护组织：防范源代码供应链中的恶意代码和漏洞
• 保护客户：防范应用程序和系统中的任何安全问题，它们可能会对你的组织造成声誉损害、责任或其他负面业务影响

DevSecOps 之旅

大多数组织发现，对于任何给定的工作负载或应用程序，DevOps 或 DevSecOps 实际上是一个两阶段过程。在此过程中，先在一个安全的空间孵化想法，随后将想法发布到生产环境并以迭代方式不断更新。

此图显示了这种创新工厂方法的生命周期：

安全创新是下面这两个阶段的集成方法：

• 想法孵化：在该阶段，会建立和验证初步想法，并为最初的生产使用做好准备。 此阶段从新想法开始，并在第一个生产版本满足下列方面的最小可行产品 (MVP) 条件时结束：
  • 开发：功能满足最低业务要求
  • 安全性：功能满足生产用途的法规合规性、安全性和安全要求
  • 操作：功能满足成为生产系统的最低质量、性能和可支持性要求
• DevOps：此阶段是应用程序或工作负载的持续迭代开发过程，支持持续创新和改进

领导力要求：融合文化

要满足这三个要求，需要将这三种文化合并在一起，以确保所有团队成员都重视所有类型的要求，并朝着共同的目标一起努力。

将这些文化和目标一并集成到真正的 DevSecOps 方法中可能会很困难，但是值得投资。 许多组织都经历了因独立工作的开发、IT 运营和安全团队造成的高度不正常的冲突，这导致了以下问题：

• 价值交付缓慢且灵活性低
• 质量和性能问题
• 安全问题

虽然在新开发中出现一些问题是正常的，也是预料之中的，但团队之间的冲突通常会大幅增加这些问题的数量和严重性。 发生冲突的原因通常是一个或两个团队具有政治优势，时常凌驾于其他团队的要求之上。 随着时间的推移，被忽视的问题越来越多，也越来越严重。 如果放任不管，DevOps 的这种动向可能会变得更糟，原因是为了满足业务需求和客户偏好的快速发展，决策的速度会加快。

要解决这些问题，需要创造一种共同的文化，重视得到领导层支持的开发、安全和运营需求。 这种方法可让你的团队更好地协同工作，并帮助解决任何给定冲刺 (sprint) 中最紧急的问题，无论他们是在提高安全性、操作稳定性，还是添加关键的业务功能。

领导技巧

这些关键技巧可帮助领导打造一个共同的文化：

1. 没有人能百辩百胜：领导者必须确保没有一种思维方式主导所有决定，否则可能导致出现对业务产生负面影响的不平衡情况。

2. 期待持续改进，而不是完美无缺：领导者应设定持续改进和持续学习的期望。 构建成功的 DevSecOps 项目不是一朝一夕就能完成的。 这是一个循序渐进的过程。

3. 拥抱共同的兴趣，也支持独有的个人价值观：确保团队能够看到他们正在朝着共同的结果努力，每个人都能发挥独特的用途。 所有要求类型都是关于创建和保护相同的业务价值。 开发是为了创造新的价值，而运营和安全性则是为了保护和维护该价值，防范不同的风险情况。 整个组织中的各级领导者都应传达这一共性，并说明它对于满足各种类型的要求来说是多么重要（无论是立即取得成功，还是长期成功）。

4. 达成共同的理解：团队中的每个人都应该对以下内容有基本的了解：

   • 业务紧迫性：团队应明确了解面临威胁的收入。 此视图应包括当前收入（如果服务已脱机），以及可能会受到应用程序和功能交付延迟影响的未来收入。 这应直接根据领导利益干系人发出的信号得出。
   • 可能的风险和威胁：根据威胁情报团队的输入（如果有），团队应了解建立应用程序组合可能将面临的威胁。
   • 可用性要求：团队应在操作要求方面达成共识，例如所需的运行时间、应用程序的预期生存期，以及故障排除和维护要求（比如，在服务联机时进行修补）。

5. 演示所需行为并进行建模：领导者应对其希望团队做出的行为公开建模。 例如，表现出谦逊、专注学习和重视其他科目。 另一个示例是，开发经理讨论安全性和高质量应用程序的价值，或者安全管理人员讨论快速创新和应用程序性能的价值。

6. 监视安全方面的摩擦程度：实现安全性自然会产生摩擦，从而拖慢流程速度。 对于领导者来说，关键是监视实现安全性所产生的摩擦程度和摩擦类型：

   • 正常摩擦：就像锻炼使肌肉更强壮一样，在 DevOps 流程中集成安全方面的适当摩擦级别可迫使在适当的时刻进行批判性思考，从而强化应用程序。 如果团队正在学习并运用这些知识来提高安全性，例如，思考攻击者试图破环应用程序的原因和方式，并发现和修复重要的安全 bug，那么他们就已步入正轨。
   • 不正常的摩擦：警惕弊大于利的摩擦。 如果工具生成的安全 bug 具有较高的假正率或误报，或者为修复某些问题而在安全方面做出的努力超过了攻击可能带来的影响，通常会发生这种情况。

7. 将安全性集成到预算计划中：确保将安全方面的预算按比例分摊给在安全方面的其他投资。 这与音乐会之类的实际活动相似，其中活动预算将物理安全纳为一项标准。 某些组织在一般情况下分配 10% 的总成本在安全方面，从而确保始终如一地应用安全最佳做法。

8. 制定共同的目标：确保应用程序工作负载的性能和成功指标反映了开发、安全和运营目标。

注意

无论是对于整个组织，还是对于特定项目或应用程序，理想情况下，这些团队都应共同创建这些共同的目标，来最大限度地获得支持。

标识 DevSecOps MVP

在从想法过渡到生产的过程中，请务必确保能力满足最低要求，或者满足每个要求类型的最小可行产品 (MVP)：

• 开发人员 (dev) 着重代表快速提供满足用户、客户和业务领导者期望的能力的业务需求。 确定最低要求，确保能力有助于组织取得成功。
• 安全性 (sec) 着重于满足合规性义务，并防范不断从组织资源中寻求非法收益的攻击者。 确定满足法规合规性要求的最低要求，保持安全状况，并确保安全操作可快速检测并响应主动攻击。
• 操作 (ops) 关注性能、质量和效率，确保工作负载可长期持续提供价值。 确定最低要求，确保在可预见的将来无需进行大规模体系结构或设计更改即可执行和支持工作负载。

随着团队从自己的经验和其他组织那里学习，MVP 的定义可能会随着时间和不同的工作负载类型而改变。

将安全性本机集成到流程中

安全要求必须侧重于与现有流程和工具的本机集成。 例如：

• 应将威胁建模等设计活动集成到设计阶段
• 应将安全扫描工具集成到持续集成和持续交付 (CI/CD) 系统中，例如 Azure DevOps、GitHub 和 Jenkins
• 应使用与其他 bug 相同的 bug 跟踪系统和流程（例如优先级方案）来报告安全问题。

随着团队的学习和流程的成熟，应不断改进将安全性集成到流程中的方式。 安全评审和风险评估应确保将缓解措施集成到端到端开发过程、最终生产服务和底层基础结构中。

有关 DevSecOps 的详细信息，请参阅 DevSecOps 技术控制。

操作过程技巧

转型需要在操作过程中逐步朝着这一理想状态前进。 在此过程中，很多组织将不得不应对复杂性和挑战。 本部分概述了组织面临的一些常见问题。

• 培训和文化转变是关键的早期步骤：你可带上自己的资源勇往直前。 你的团队通常将需要培养新的技能并采用新的观点来了解 DevSecOps 模型的其他部分。 这种培训和文化转变需要时间、精力、管理层的支持，还需要定期跟进，来帮助个人充分了解和见证转变的价值。 彻底改变文化和技能有时可能触及个人的职业认同，从而可能产生巨大的阻力。 理解和表达每个人及其情况为什么改变、哪些方面改变了，又如何改变，这一点至关重要。
• 改变需要时间：你的团队多快适应采用新方式操作带来的影响，你就进步得多快。 在转变过程中，团队总是必须执行其现有的作业。 重要的是，仔细确定首要任务的优先级，并管理对此变化发生速度的期望。 专注于循序渐进的过程将对你的组织很有帮助，在此过程中，最重要、最基础的要素放在首位。
• 资源有限：组织在早期经常面临的一个挑战是，寻找安全性和应用程序开发方面的人才和技能。 随着组织开始更有效地协作，他们可能会发现隐藏的人才，例如具有安全思维方式的开发人员，或者具有开发背景的安全专业人员。
• 改变应用程序、代码和基础结构的特性：随着无服务器、云服务、云 API 和无代码应用程序（如 Power Apps）等技术的引入，应用程序的技术定义和组成正在发生根本性的变化。 这种转变正在改变开发做法、应用程序安全性，甚至授权非开发人员创建应用程序。

注意

某些实现将运营责任和安全责任并入到站点可靠性工程师 (SRE) 角色中。

尽管对于某些组织来说，将这些责任并入单个角色可能是理想的最终状态，但这通常极大地改变了当前企业做法、文化、工具和技能集。

即使你的目标是 SRE 模型，我们也建议先采用本指南中所述的实用“快速制胜和逐渐进步”方法将安全性嵌入到 DevOps 中，来确保获得良好的投资回报率 (ROI) 并满足即时需求。 这将逐步增加运营和开发人员的安全责任，让你的用户更接近 SRE 的最终状态（如果你的组织计划稍后使用该模型）。

后续步骤

有关 DevSecOps 的更详细指导，请查看 DevSecOps 技术控制。

若要了解 GitHub 高级安全性如何将安全集成到持续集成和持续交付 (CI/CD) 管道中，请参阅关于 GitHub 高级安全性。

如需有关 Microsoft IT 组织如何实现 DevSecOps 的详细信息和工具，请参阅安全 DevOps 工具包。