(四)国防部企业DevSecOps基本原理战术手册

admin 2021年11月30日03:12:46评论340 views字数 7337阅读24分27秒阅读模式

写在前面:

这个系列文档一共有5篇,分别是:

  1. 国防部企业DevSecOps Strategy Guide

  2. 国防部企业DevSecOps Fundamentals

  3. DevSecOps Fundamentals Guidebook:DevSecOps Tools & Activities

  4. DevSecOps Fundamentals Playbook

  5. 国防部企业DevSecOps Reference Design:CNCF Kubernetes

文档顺序为:

(四)国防部企业DevSecOps基本原理战术手册

本文是第四篇。



(四)国防部企业DevSecOps基本原理战术手册


目录

第一步 采用DevSecOps文化

关键文化实践

检查清单

第二步 采用基础设施即代码(IaC)

关键优势

检查清单

第三步 采用容器化的微服务

容器化微服务的关键特性

检查清单

第四步 采用能力模型,而不是成熟度模型

检查清单

第五步 通过关键能力持续推动改进

检查清单

第六步 建立软件工厂

检查清单

第七步 定义有意义的DevSecOps管道

检查清单

第八步 对软件采用敏捷购买策略

检查清单

第九步 不懈追求网络弹性

检查清单

第十步 将实用试验和评估(OT&E)左移进管道

常见测试种类

检查清单

第一步 采用DevSecOps文化

DevSecOps是一种软件工程文化,指导团队打破隔断,统一软件开发、部署、安全和运营。DevSevOps采用成功的关键,是赢得所有参与方的认可:包括领导层、采购、承包商、中层管理、工程、安全、运营、开发和测试团队。整个组织利益相关方,必须将他们的思考方式,从“我”转变到“我们”。打破团队孤岛,理解无法成功地交付、维护、持续工程化软件及其底层基础设施,不是某个团队或个人的失败,而是整个组织的失败。

开启一段DevSecOps旅程之前,必须首先了解成功地实施DevSecOps,不能仅靠完全自动化管道或者开发和运维团队之间的交互来衡量,组织中所有的参与者必须承诺去改变他们看待工作责任的方式,最重要的是,彼此互动。

关键文化实践                    

  • 利益相关方透明和可见

  • 团队成员之间,实时地完全透明

  • 整个团队容易访问所有项目资源,不需要每个人提交权限

  • 采用和接受ChatOps作为DevSecOps团队的通讯骨干

  • 所有技术人员应该关心安全,有发言权,安全内嵌

检查清单

  • 学习DevSecOps文化所涉及的内容

  • 对任何重复的事情,尽量自动化

  • 阅读《如何打造强大的DevSecOps文化》,K.Casey著。https://enterprisersproject.com/article/2018/6/how-build-strong-devsecops-culture-5-tips

  • 阅读《凤凰项目,关于IT、DevOps的小说,助您赢得业务》G.Kim,K.Behr,G.Spafford著。

  • 快速失败,快速学习,小的失败,不要因为同一原因失败两次

第二步 采用基础设施即代码(IaC)

        基础设施即代码(IaC)是使用文本文件来定义基础设施概念和配置,文本文件被签入到源代码库,保持在配置管理下。包括网络、存储、虚拟机、负载均衡、甚至连接拓扑的管理。IaC逐步发展是为了解决发布管道中的环境漂移的现实问题。简而言之,开发环境无法和生产环境配置保持一致。目标是以一种可重复的、保持不变的方式,实现所有基础设施资源和配置的自动化,有助于在任何配置变更事实发生之前,进行同行检查。

        基础设施即代码(IaC)可以采用多种形式。一种是在云服务中,以安全的方式实例化一个云服务模板;另一种通过配置文件或脚本。当选择技术或基础设施即代码(IaC)格式时,考虑到厂商绑定和产品绑定非常重要。Blueprints和Cloud Formation分别适用于微软Azure和亚马逊AWS,造成某种程度的厂商绑定。多云方案,如常见工具Ansible和Terraform提供的方案,避免了厂商绑定,但导致了产品绑定。在所有情况下,基础设施即代码(IaC)都是通过一个或更多的文本文件来指定的。

        GitOps是一种范例,系统以声明的方式进行描述和观察,使用代码指定所需状态,GitOps的好处是基于基础设施即代码(IaC),强调git作用和git驱动的工作流。IaC是GitOps的三个核心实践之一,其他两个是合并请求和依赖 CI/CD管道。

关键优势

  • IT基础设施支持和实现了变更,而不是障碍或者限制

  • 使用自动化和按钮式部署来减轻环境之间的漂移

  • 根据需要,通过GitOps,使用多个审批人,加强变更管理

  • 环境改变完全是自动化和程式化,人员关注其他任务

  • 从故障中更快地恢复,而不是假设故障能完全得到阻止

  • 授权持续改善生态系统,而不是“大爆炸”式一蹴而就的活动

检查清单

  • 学习如何描述基础设施即代码(IaC)的价值主张

  • 了解在基础设施配置中采用GitOps的好处

  • 了解基础设施即代码(IaC)对工具的选择,厂商绑定和产品绑定之间的权衡

  • 探索常见的基础设施即代码(IaC)工具,包括:

  • Terraform

  • Ansible

  • Chef

  • CSP 托管服务工具

第三步 采用容器化的微服务

        模块化开放系统方法(modular open system approach,MOSA)是一个采购和设计战略,由开放标准技术架构和支持模块化、松耦合、高聚合系统架构组成。美国法典 Title 10 2446a部分,和国防部指令5000.02要求采用MOSA。基于软件容器和微服务的现代化软件架构符合MOSA的要求。

        容器是一个轻量级、独立运行、可执行的软件包,除了操作系统,包括需要运行业务服务的一切;代码、运行时、系统工具、系统库和设置。容器运行在彼此隔离的进程之中,多个容器可以运行在同一个操作系统中,彼此不会冲突。所有容器必须符合开放容器计划(Open Container Initiative,OCI)的要求。国防部DevSecOps战略要求CNCF 认证的Kubernetes集群实现容器编排,有超过90个认证的Kubernetes实施和计数。

        微服务架构是应用开发的方法,离散的、模块化的业务服务打包在一个软件容器里面。这些业务服务之间松耦合,可以使用轻量级协议快速组合。如果执行正确,这种方法的主要功能性好处是每个服务能独立发展,还有大量的非功能好处,包括可以更加敏捷地按需扩展、不影响用户群的多个更新选择,在每种服务的级别上,更精确的网络加固,天然支持故障和恢复。

容器化微服务的关键特性

  • 通过服务实现组件化

  • 围绕业务能力来组织

  • 产品高于项目

  • 智能端点,哑管道

  • 去中心化治理和数据管理

  • 通过IaC支持基础设施自动化

  • 故障设计

  • 不断发展的设计支持

检查清单

  • 研究和了解微服务架构的好处

  • 只使用CNCF认证的Kubernetes,保证所需API软件的一致性

  • 使用Iron Bank中加固的容器及其他软件工件

  • 始终注入Sidecar容器安全栈( Sidecar Container Security Stack,SCSS),最大化运行时安全

  • 总是采用服务网格,进一步保护东西向网络流量

第四步 采用能力模型,而不是成熟度模型

        谷歌的DevOps研究和评估(DevOps Research and Assessment,DORA)研究程序主张,与使用成熟度模型对比,研究表明能力模型在鼓励和衡量绩效改进上,都是更好的方法。多个研究已经表明四个关键指标支持软件开发和交付性能。这两类指标是速度指标和稳定性指标。速度部分,测量从提交到生产部署过程,部署频率和交付时间。稳定性部分,测量平均恢复时间,从宕机到平均修复时间(Mean time to restore,MTTR),和变更失败率(百分比)。

指标

高绩效

中等绩效

低绩效

部署频率-组织部署代码的频率

一个需求(每天多次部署)

一周一次和一月一次之间

一周一次和一月一次之间

变更交付时间-从代码提交到代码在生产中成功运行的时间

少于1小时

一周和一月之间

一周和一月之间

平均恢复时间(MTTR)-当服务事件发生时,恢复的时间。(计划外的运行中断,服务受损)

少于1小时

少于1天

一周和一天之间

变更失败率-导致服务降级或要求修复的百分比(导致服务受损,要求热修复,回滚,补丁等)

0-15%

0-15%

31-45%

检查清单

  • 熟练掌握四个关键指标:部署频率、交付时间、MTTR、变更失败率

  • 在每个指标上评估项目和组织,衡量DevSecOps能力进步

  • 通过流程和自动化改进,持续努力改进各项指标

  • 阅读《DevOps手册》,学习三种方式(流,反馈,持续学习和实验)

第五步 通过关键能力持续推动改进

        在整个DevSecOps和它的组织中,有24种关键能力推动改进。这些能力被总结成5大类:持续交付、架构、产品和流程、精益管理和监控、文化。文化变革常常是最难解决的问题。24种关键能力包括:

持续交付

  • 所有产品的工件,都使用源代码库

  • 使用基于主干的开发方法

  • 安全左移

  • 实施测试自动化

  • 实施持续集成

  • 支持测试数据管理

  • 实施持续交付

  • 自动化部署过程

架构

  • 使用松耦合架构

  • 授权团队架构

文化

  • 采用扩展调查,衡量文化变更流程

  • 鼓励和支持持续学习计划

  • 支持和加速团队内部和团队之间的聚合

  • 提供资源和工具,让工作更有意义

  • 支持或体现变革型领导

产品&流程

  • 收集和实现顾客反馈

  • 通过价值流让工作流可见

  • 小的团队工作 

  • 培养和支持团队实验

最小管理和监控

  • 轻量级变更批准流程

  • 应用和基础设施监控,提醒业务决策

  • 主动检查系统健康

  • 改进流程和管理工作,限制在制品(work-in-process,WIP)

  • 可视化工作,监控质量和在整个团队内沟通

检查清单

  • 阅读:《加速:精益软件和DevOps的科学:打造和扩充高效技术组织》《Accelerate :The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

  • 特别注意推动成功转型所需的文化变革

第六步 建立软件工厂

        应该使用DevSecOps构造的软件工厂,来推动所有定制的软件开发。有好几种方法来实例化国防部DevSecOps软件工厂/平台。在这一次,摩擦最小的选择是使用国防部批准的DevSecOps托管服务,Platform One。Platform One作为一个授权使用的平台来运维,集成持续操作授权(continuous,authorization to operate,cATO)实践。它使用好几种企业级服务,包括Iron Bank,作为一个推荐的国防部加固工件库,和Repo One作为源代码管理。

        其他的选择是使用具有国防部授权操作(ATO)或临时授权(Provisonal Authorization)云服务商,建立软件工厂。使用云服务商的托管服务,理想上,通过基础设施即代码实践,建立一个DevSecOps软件工厂。图1 描绘了建立软件工厂的关键阶段。

(四)国防部企业DevSecOps基本原理战术手册

检查清单

  • 认识到软件工厂必须和《国防部DevSecOps战略》保持一致。符合《DevSecOps工具和活动指南手册》要求。清晰地确定在《DevSecOps 基本原理》中定义的各层之间的互连。

  • 软件工厂天生就要设计成多功能,建造和运营的成本很高,明确为什么需要一个新的软件工厂而不是采用现有工厂。

第七步 定义有意义的DevSecOps管道

        每个软件工厂执行多条DevSecOps管道,管道和生产组装线类似。每个管道根据生产的工件,定制特殊的流程。对网络安全测试,没有“一刀切”的方案。因此,每个DevSecOps管道都汇集了好多流程工作流和脚本,运行在一组DevSecOps工具上,和有关的软件工厂一起运行。每个管道的设计必须清晰的确定出各个DevSecOps阶段流程和自动化活动,如图2所示。

(四)国防部企业DevSecOps基本原理战术手册


检查清单

  • 阅读《国防部企业DevSecOps基本原理》

  • 阅读《DevSecOps工具和活动指南手册》

  • 在管道内定义软件生命周期,使用管理流程,符合独特的任务环境、系统复杂度、系统架构、软件设计选择、风险容忍度水平,系统成熟度水平的需要

  • 不要试图使用“一揽子”的方法实现管道,从小处开始,迭代,自动化重复的流程

  • 贯穿软件生命周期阶段,承认持续反馈闭环的价值

  • 紧密配合授权官(Authorization Official,AO)工作,准确理解工件在升级到下一个阶段之前,必须验证每个控制门

  • 在生命周期每个阶段衡量能力

第八步 对软件采用敏捷购买策略

        购买促成(Acquisition Enablers,AE)办公室是国防部内负责采购和维护(Acquisition & Sustainment,A&S)副部长办公室内的一个新组织。这个办公室是创新采购方法的领导者,根据战时速度的要求,交付作战能力。国防部指令5000.02《自适应性采购框架操作》,重构了国防部采购指南,提高流程有效性和实施自适应性采购框架。作为这个框架的一部分,国防部指令5000.87《软件采购途径操作》,于2020年10月2日生效。5000.87指令说明:

  • 建立软件采购途径,作为采购和开发软件密集型系统的首选路径

  • 简化采购模型,在和作战人员/最终用户有关的时间线上,支持持续集成和交付软件功能

  • 建立业务决策工件,以管理风险和实现成功的软件采购和开发

       国防部采购大学(Defense Acquisition University,DAU)以交互式web应用的方式提供培训,特别是在软件采购途径方面教育观众,在采购人员的背景下讨论敏捷软件采购流程。更多信息:https://asf.dau.edu/aaf/software

检查清单

  • 阅读国防部指令8000.87,了解“软件密集型”系统的正式定义

  • 浏览国防部创新委员会(Defense Innovation Board,DIB) 软件采购和实践研究(Software Acquisition and Practices,SWAP)里的关键发现

  • 浏览TechFAR中的收购指南,https://techfarhub.cio.gov

  • 认识到软件可以通过国防部指令8000.87 采购,其他的程序元素可通过不同的途径采购

  • 在生成独特服务之前,如果可能,将企业级服务作为首选

  • 保证你的收购计划认识到,技术进步没有尽头

  • 不要把技术要求锁定到法律合同中,启用新技术 

第九步不懈追求网络弹性

        网络弹性是“包括网络资源在内的系统,对不利条件、压力、攻击或损害,进行预测、承受、恢复和适应的能力”。采用DevSecOps主要的目标是把网络安全内嵌到应用中,作为软件工厂DevSecOps管道流程的一部分。

        网络安全和DevSecOps生命周期的8个阶段中的每个阶段都有关,各种控制门作为通过/不通过决策点。如第7步,定义一个有意义的DevSecOps管道中讨论的,精确设置的测试和流程,每个管道都不同。然而,所有管道必须使用这些控制门,保证网络安全既内嵌,又能透明识别。文化上,授权官(AO)和他们的团队必须由依赖流程结束后的文档工作评估,转向接近实时地持续监控软件工厂的管道和生产环境性能指标。

        转移到DevSecOps包括将使用DevSecOps流程开发的应用,包括具有CI/CD管道的软件工厂,向持续操作授权(continuous,authorization to operate,cATO)转变。持续操作授权和NIST 800-137中定义的持续授权一个意思,根本上与持续的接受和量级理解安全和隐私风险有关。每一个持续授权运维都围绕着一个透明定义和得到良好理解的持续监控程序。

        一本单独的持续授权运维手册即将发布,围绕着平台评估和授权、流程评估和授权(包括持续监控),最后团队评估和授权。

检查清单

  • 对DevSecOps软件工厂CI/CD管道生产的软件,不要使用快速跟踪授权运维(Fast Track Authority to Operate)

  • 在DevSecOps生命周期的每个阶段追求网络弹性

  • 理解Recommendation  B6,“从中低风险部署可执行文件认证向代码/架构认证和开发、集成和部署工具链认证转变”

  • 建立持续监控程序

  • 和授权官(AO)合作,帮助他们转向接近实时指标仪表盘

第十步 将实用试验和评估(OT&E)左移进管道

        国防创新委员会,简要地总结了这一步的目标:“速度和软件周期时间,是管理软件最重要的指标,国防部必须能够更快地部署软件,而不牺牲其测试和验证软件的能力”。

        实用试验和评估(Operational Test and Evaluate,OT&E)意图收集数据,帮助领导做出正确决策。转移这些活动到软件工厂管道内的价值在于,尽早发现问题,当产生这些问题的思路还在开发人员的脑海中时,可以尽快修复,减少风险。在不同的系统中集成比较困难,要求提供更多的原始数据,传递给人工智能/机器学习算法。在流程中尽早保证这种集成工作的能力,而不是集成完成之后再后接,推动相关软件按照作战的速度来交付。

        测试必须先计划,已经在国防部指导5000.87内被正式确定。测试人员应该在敏捷和DevSecOps方面,接受正规培训,保证能够完全融入到团队成员中。DevSecOps文化强调不管他们在团队中的角色和职位,每个人都对质量和测试负责。测试计划必须规划和确定出最能反映功能和非功能要求的指标,以及如何以自动化方式分别收集指标,最后,最重要的一点,最终用户或他们的代表,在工件通过CI/CD管道过程中,必须紧密参与到测试和验收的每个方面。

常见测试种类

  • 单元和功能测试

  • 集成测试 

  • 性能测试

  • 互操作测试

  • 部署测试(临时环境)

  • 运维测试(生产环境)

  • 静态应用测试(SAST)

  • 动态应用测试(DAST)

  • 交互式应用安全测试(IAST)

  • 运行时应用自防护(RASP)

检查清单

  • 在程序开始时,启动实用试验和评估(OT&E),以影响战略、需求、需求建议书(request for proposal,RFP)等

  • 在第一个冲刺(sprint)中。建立自动化收集测试数据指标的计划

  • 持续工作,尽可能压缩测试报告时间,加快纠正

  • 部署和实用试验时,包括操作用户

  • 在管道中包括所有形式的应用安全测试,保证网络弹性

  • 在DevSecOps生命周期的每个阶段,考虑功能的、非功能的、网络测试

 




原文始发于微信公众号(安全行者老霍):(四)国防部企业DevSecOps基本原理战术手册

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2021年11月30日03:12:46
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   (四)国防部企业DevSecOps基本原理战术手册http://cn-sec.com/archives/568325.html

发表评论

匿名网友 填写信息