1.前言

自微软于2004年提出Security Development Lifecycle（SDL，安全开发生命周期）方法论以来，全球企业逐步将SDL流程融入产品开发体系，以保障安全质量。然而，随着敏捷开发与DevOps模式的普及，传统SDL的线性流程已难以满足快速迭代的开发需求。

2014年，Gartner提出DevSecOps（开发、运维与安全一体化）理念，提倡“将安全性作为共同责任，融入到开发和运维的整个流程中，实现安全左移，使安全成为产品交付中不可分割的一部分”，以此来保障在企业快速发展、快速迭代的同时，保障安全治理效果。

作为最早实践DevSecOps理念的云服务商之一，阿里云通过建设专业工具链、规范化流程与系统化方法论，使得DevSecOps成为云产品安全的基石。

本文将分享阿里云在这一工作中在设计环节的实践经验，希望能够让大家理解阿里云是如何保障产品安全水位，并希望这些经验能够帮助到正在尝试落地DevSecOps解决方案的企业。

2.DevSecOps要解决什么问题？

2.1开发效率与安全治理的矛盾

传统SDL模式中，安全审查多集中在开发流程末期，导致安全缺陷暴露滞后，修复成本高昂。而在开发流程末期修复漏洞，意味着要回滚的操作变多，可能导致项目延迟上线，安全治理成为开发效率的“瓶颈”。

在当前快速迭代的敏捷开发环境中，传统的安全审核流程耗时冗长，与快速交付的需求形成矛盾。当开发团队追求快速迭代发布时，繁琐的安全审核流程往往会成为项目推进的阻碍，导致安全性和效率难以平衡。

2.2产研团队安全意识薄弱

企业内部普遍存在安全意识薄弱的问题，开发人员专注功能实现而忽视代码安全，运维人员侧重系统稳定性而轻视安全配置，同时由于缺乏完善的安全知识共享机制，导致团队整体安全能力提升困难。

2.3人工检查的局限性

现有的安全治理工作过度依赖人工检查，难以适应持续集成/持续部署(CI/CD)的节奏要求。另外，手动安全测试既无法保证充分的覆盖度，也难以满足规模化部署的需求，严重制约了企业安全能力的提升。

2.4团队协作不畅

在传统开发模式下，安全团队往往与开发运维团队是分离的，缺乏有效的沟通机制和协作渠道，导致安全需求难以准确传达。而不同团队间的职责边界模糊更易引发推诿矛盾，难以推进整体安全目标的协同落地。

3.安全架构问题的痛点与解决方案

在DevSecOps实践过程中，最为困难的问题有两个：

1. 如何设计出安全的架构
   
2. 如何确保产品设计在充分考虑安全因素后才能上线
   

3.1如何设计出安全的架构

阿里云作为一家大型云厂商，向全球提供服务，旗下拥有数百款云产品。由于云产品体系庞杂，每个产品团队均设立专职产品安全架构师角色，从业务视角主导安全架构设计，并与安全团队对接。安全团队根据业务类型进行分类管理，针对不同类别的业务，指派具备对应技术栈和攻防经验的安全工程师对接协作，安全工程师与产品安全架构师共同协商、确定最终安全架构设计方案。

在安全设计环节留有足够的人力，是做好安全架构设计的前提，但当人员分散后，会引入新的挑战。不同工程师的经验水平差异可能导致设计能力参差不齐，在应对复杂安全场景时，标准不统一的问题会显著影响云平台整体的架构一致性。

尤其在To B领域，在同一类业务场景下，不同的产品间要考虑安全设计的一致性，否则不同产品间将难以联动。例如，若ECS（弹性计算服务）与OSS（对象存储服务）采用完全独立的鉴权体系，当用户需实现“将OSS文件下载至ECS”的操作时，需要同时使用两套凭证体系，由此产生的代码熵值增加将带来额外的安全风险与治理成本。为此，阿里云在确保具体产品安全设计满足业务需求的同时，同步从云平台整体角度进行全局统筹。

为此，在安全团队内部，也成立了安全架构中台团队，负责制定阿里云整体的安全架构规范，明确不可变更的红线要求与原则性军规，并监督各业务的执行。安全架构中台团队针对云平台整体的安全架构风险进行系统性摸排，牵头设计横向解决方案，并推动方案落地，确保安全架构持续向纵深防御和零信任方向演进。

安全架构规范以纲领性和共识性为目标，仅通过少数可记忆的原则性军规（如零信任原则）引导各方达成基础共识。此类军规在制定后原则上不做修改，除非业务场景或产品形态发生重大变化，从而成为阿里云全平台的安全基础共识。

针对不同技术领域，安全团队设计编写了不同的安全架构标准，例如加密领域中有关密钥管理的要求，对算法强度及场景化技术选型作出明确规定，并根据属性差异，以每半年或一年为周期进行版本迭代与更新，确保规范与当前攻防态势及业务需求保持同步。

为减少设计过程中的失误风险，阿里云还编纂了针对各业务线具体场景的可落地操作规范，提供实施步骤指南及关键链路时序图，以确保技术细节的执行质量。在规范体系建立后，安全团队定期开展多级培训：

• 安全架构中台团队与各业务线安全架构师定期开展技术交流与知识共享，确保安全架构中台团队能够准确把握业务线当前的安全设计现状，同时业务线安全架构师可充分理解中台的全局性设计要求。
  
• 安全团队主导的安全培训将面向业务线安全架构师，通过案例复现与最佳实践讲解，补充专业领域的安全知识，强化团队对安全设计的风险认知与设计能力。
  

3.2如何确保产品设计在充分考虑安全因素后才能上线

即使具备充足的人力投入、完善的设计标准及跨团队知识共享，仍需通过制度与流程保障确保产品设计在进入研发阶段前完成充分的安全评审。阿里云通过以下方式实现这一目标：

• 1. 流程自动化整合
  安全团队在内部安全运营中心平台上构建了线上化安全架构评审功能模块。该模块支持记录评审会议纪要、记录安全要求清单，并与阿里云的安全度量指标联动，可量化追踪整改进度，督促各相关方履行安全责任。
  
• 2. 跨平台协同机制
  安全团队与产品管理团队、各业务线发布平台深度协同，将安全架构评审流程无缝集成至产品全生命周期管理流程。具体措施包括将需求设计文档、业务线管理流程与发布流程中的设计内容自动同步至安全运维中心，强制触发评审流程。

通过自动化技术、线上化跟踪机制与奖惩管理制度的结合，阿里云确保所有产品设计必须经过安全评估确认后，方可正式进入开发与部署环节。

4.从设计之初就将安全纳入考量

在企业中，项目立项后的第一步就是做产品架构设计。从攻防对抗角度，类似租户隔离逃逸、越权等风险，都可以在设计环节就纳入考量。

良好的安全架构设计，能够有效减少“安全治理”与“业务敏捷”之间的冲突。如阿里云首席技术官靖人在谈到大模型安全的时候强调：“每一个环节都需考虑安全问题，确保数据和模型的安全性”。通过在架构中应用加密方案、网络隔离策略等设计思维，可为后续的业务扩展与合规要求奠定框架基础。在阿里云的实践中：

• 安全团队具备一票否决权
  安全是阿里云的生命线。因此在产品管理流程中，安全团队具备产品设计方案的一票否决权，并将安全审核设为产品上线的强制前提。
  
• 产品架构评审&威胁建模
  安全团队会在设计环节介入，辅助产品线完成安全架构的设计与评审工作。对产品的部署架构、网络架构、应用架构、接口交互逻辑和租户隔离架构进行完整的威胁建模，事前识别出产品的安全风险，并给出针对性整改建议。阿里云所有产品的架构评审完成率达到100%，威胁建模知识库累计沉淀了数百条风险判断规则，确保在设计阶段能够覆盖多场景的潜在威胁。
  
• 安全培训与知识共享
  

安全团队定期对研发团队开展安全规范与攻防案例专项培训，系统性提升开发人员的安全意识与实践能力，强化团队对安全设计规范的执行力度。

5.分层纵深防御体系

针对云计算的特殊场景，阿里云重点关注租户隔离方面的风险治理，在不同层级实施了不同强度的加固措施，构建了覆盖虚拟化、网络、网关、应用及主机五个层面的防护体系。各层间形成递进式防御关联，假设任一单层防御失效，仍能通过其他层级阻断攻击。具体措施如下：

• 虚拟化层
  阿里云自主研发的ECS沙箱隔离与袋鼠安全容器技术，通过架构设计解决资源调度场景下的租户隔离需求。针对容器集群内部署严格的NetworkPolicy策略，并集成WebHook拦截机制，实时阻断异常内部访问行为。
  
• 网络层
  采用VPC默认隔离架构实现跨业务间与跨产品间的网络隔离。在核心生产网络中，部署L4层零信任隔离系统，具备基于机器、IP及端口粒度的动态阻断能力；容器环境通过SideCar组件对流量进行清洗与隔离；对于访问公网的网络通道，默认执行“非必要不互通”的安全策略，极大提升攻击者通过C2（命令与控制）通道操控计算资源的难度。
  
• 网关层
  动态流控系统可避免单一租户的异常操作对其他用户造成影响，并开放接口鉴权配置功能，防止因程序编写失误导致越权访问事件。
  
• 应用层
  通过全生命周期安全管控降低编码漏洞风险，并针对0day漏洞场景部署Web应用防火墙与RASP（运行时应用自保护）工具，使应用系统具备对抗未公开漏洞的主动防御能力。
  
• 主机层
  以自研工具安骑士工具为核心，实施主机行为的实时监控与威胁响应，确保异常进程或文件变动可被及时阻断与处置。
  

通过分层设计，阿里云的安全防护体系确保威胁无法突破多层防线，真正实现“一处失效，多层拦截”的纵深防御效果。不同层级的安全架构设计，共同组成了阿里云的纵深防御体系。阿里云的安全防护不仅仅依赖于单层的防御机制，而是永远在“单层防御已被攻破”的假设下，设计更深的防御机制。

6.零信任架构体系

阿里云基于“零信任”的理念，结合自身与顶级黑客团队的对抗经验，实施建设了一体化的零信任安全架构。

零信任的核心理念是不单纯依赖网络请求来源和单一身份凭证，而是通过各层、各场景的信息，综合分析潜在的风险，从而拦截可疑的攻击者，实现动态安全。对于云厂商而言，保护客户数据安全是其核心要务。从设计层面实现这一目标，需要从全链路的角度识别哪个环节对客户数据执行了操作，不仅要防止外部攻击者的渗透攻击，还需要预防内部员工被钓鱼所带来的操作风险。

阿里云平台将身份数据在全链路进行传递，包括主机层、网络层、应用层。其中主机层记录和传递主机硬件身份信息，网络层记录和传递网络IP、端口等四层信息，应用层记录和传递进程信息、接口等应用运行时信息、访问者身份ID 标识信息。阿里云通过零信任体系的建设，实现了以下关键成果：

• 全链路风险控制
  阿里云将云原生身份体系与客户业务体系无缝对接，通过硬件可信根、四层元数据、七层元数据，限制数据仅可在可信范围内使用和传递，应用间调用权限限制到接口级别。攻击者无法通过单一漏洞完成对云平台的渗透工作。
  
• 防御0day漏洞
  阿里云平台的应用环境仅可运行可信组件，且持续监控运行时状态，从而大大缓解了0day漏洞与供应链组件带来的威胁。
  
• 防止内部误操作
  

阿里云通过持续校验请求流量是否可信，对内部操作进行充分审计，从而最大化避免误操作，确保内部操作安全规范。

7.总结

当前大多数的企业的安全治理模式普遍依赖上线前的扫描与上线后的应急响应，这一滞后措施将导致效率与安全的双重困境：安全卡点可能阻碍快速迭代节奏，安全缺陷的后期修复成本高昂且部分设计缺陷无法回滚（如已被客户依赖的架构）。正如古语所言：“上医治未病，中医治欲病，下医治已病”，卓越的安全治理体系需前置安全规划，在设计环节同步实施系统性安全防护。通过明确关键角色职责、建立覆盖全流程的安全标准规范、并强化制度约束，可确保安全设计真正落地。这种设计导向的安全模式在保障业务敏捷扩展的同时，能从根本上降低安全风险并提升系统抗攻击能力。

来源  |  阿里云开发者公众号

作者  |  阿里云安全保障