应用安全左移

应用安全左移 使用正确的安全工具弥合DevOps与安全之间的鸿沟 彼得·康拉德 应用安全左移 作者：彼得·康拉德 版权所有©2022O’ReillyMediaInc.版权所有。在美国印刷。 由O’ReillyMedia,Inc.�版，地址：1005GravensteinHighwayNorth,Sebastopol, CA95472。 购买O’Reilly书籍可用于教育、商业或促销用途。大多数图书也提供在线版本 （http://oreilly.com）。如需了解更多信息，请联系我们的企业/机构销售部门：800-998-9938或corporate@oreilly.com。 采购编辑：JenniferPollock开发编辑：GaryO’Brien制作编辑：KateGalloway文案编辑：LizWheeler校对：GregoryHyman室内设计师：DavidFutato封面设计师：RandyComer插画师：KateDullea 2022年4月：第一版 第一版的修订历史 2022-04-06：首次发布 O’Reilly是O’ReillyMedia,Inc.的注册商标。应用程序安全性左移、封面图片和相关商业外观是O’ReillyMedia,Inc.的商标。 本文所表达的观点仅代表作者个人观点，并不代表�版商的观点。虽然�版商和作者已尽力确保本作品中包含的信息和说明准确无误，但�版商和作者不承担任何错误或遗漏的责任，包括但不限于因使用或使用而造成的损害。使用本作品中包含的信息和说明的风险由您自行承担。如果本作品包含或描述的任何代码示例或其他技术受开源许可证或他人知识产权的约束，则您有责任确保您对其的使用符合此类许可证和/或权利。 这项工作是O’Reilly和NGINX合作的一部分。请看我们的编辑独立性声明.978-1-098-12732-9[LSI] 前言 从设计到部署，安全对于应用程序开发和支持中的每个人都很重要。无论你是开发人员、安全或运维工程师，还是公司的CISO（首席信息安全官），都已经正在考虑安全问题。全面地考虑安全，需要考虑所有可用的工具及其在软件开发流水线中的位置。 将安全左移意味着从流水线的最早阶段就引入工具和流程来承载安全性，而不是在最后阶段匆忙地进行一些安全测试草草了事。 本报告将帮助你了解为什么安全左移是如此重要以及如何做到这一点。你将了解组织在更快、更安全地交付应用程序的压力下所面临的挑战，同时左移如何帮助解决这些问题，并且需要整个组织改变思维才能实现这一切。 在报告结束时，你将能够向你的组织提�一些应用程序安全建议，并且将通过工具来创建你和你的团队可以应用的策略，以使安全成为每个人的首要任务。通过团队之间和谐的关系和一组共享的安全优先级，任何组织都可以通过将安全左移成功地使其应用程序、服务和开发流程更加健壮。 介绍 左移并不是一个新想法。随着现代软件流程的发展使一切变得连续，左移已经成为传统被局限于开发与生产阶段之间的测试阶段的各种流程的规范。安全左移意味着从设计的最早阶段开始实施安全策略、控制和设计，一直持续到生产。 尽管人们普遍认为安全左移是一个好主意，但很难就哪些工具和方法最适合这项任务达成一致。一部分公众的讨论关注在与代码和容器相关的扫描工具、自动修复以及专为现代应用程序和基础设施设计的其他新的安全工具上。具备在运行时保护应用程序的悠久历史的工具似乎已经过时，被贴上“遗留”工具的标签，在现代软件开发环境中失去了地位。 事实证明，这些有着长期历史的工具在当今的企业中仍非常重要。诸如Web应用程序防火墙(WAF)这类工具提供了运行时保护和有关应用程序性能的宝贵反馈，帮助开发人员和安全工程师完善代码和策略。WAF和其他工具并没有停滞不前，而是已经适应了现代基础设施和应用程序，随着威胁行为者开发�更复杂的攻击而变得更加智能。 随着企业将应用程序迁移到云端，左移变得越来越重要。现代应用程序不再是单体，而是由大量服务组成，这些服务呈现�复杂、多样化的攻击面，仅靠代码扫描和良好的编程实践已无法防御。左移必须不仅仅是设计上的安全性。企业需要执行一个有意识的文化转变，使安全成为每个人的责任，从设计到生产的整个过程都要涵盖，这一转变的驱动力是经由利用来自运行时工具的反馈而不断完善的政策。 传统上，开发团队和安全团队似乎总是处于对立状态。开发人员面临着快速交付更多功能的压力，而安全团队则被视为看门人，有时会停止开发以调查问题。安全左移所必需的文化变革需要开发团队与安全团队的共同合作。这意味着每个参与者都需要新的工作方式。安全团队必须成为良好实践的推动者，提供保护应用程序和基础设施的护栏，同时又不会阻碍工程进展。从设计到部署，开发团队必须承担一定的安全责任。 从根深蒂固的流程到预算，再到内部政治，许多因素都可能致使如此重大的文化转变举步维艰。本报告对云原生应用程序架构的当前安全形势、一些类型的威胁以及将左移策略引入持续集成和持续部署(CI/CD)软件流水线的一些策略和工具进行了调查。 第1章DevOps和DevSecOps 传统的软件开发过程专注于创建单体应用程序，它将设计、构建、测试和交付分为不同的阶段，但是事后看来，这种方法显然既不灵活也不高效。为了应对日益增长的压力，敏捷开发方法将大型任务分解为若干更小的单元，从而使得流程变得更加灵活。随着研发人员遍布全球，将大家束缚在单一的代码库上已不再现实。应用程序架构将从单体模型转向微服务，这使得分散的团队可以在不同的服务上分别工作且不会互相影响。管理日益庞杂的微服务开发迫使软件开发流水线中的所有步骤都是连续的，这也是DevOps发挥作用的所在之处。 DevOps DevOps是一种概念，是涵盖了多项目标的一系列实践。DevOps将开发和运营结合在一起，模糊了开发、构建、部署和维护应用程序各阶段之间的职责界限，也打破了负责其中不同任务团队之间的界限，使他们能够建立应用程序和功能的持续集成和部署。图1-1展示了软件开发和部署CI/CD方法的各个阶段。 图1-1.DevOpsCI/CD流水线中的软件开发阶段 持续集成意味着在开发后尽快将代码变更合并到共享的主代码库中，使代码库与每个人的最新工作保持同步，以便可以尽快进行测试和发布。持续部署使发布的过程以及生产部署的测试能够自动化运行。通过不断合并和测试变更，DevOps流水线降低了独立工作的分布式团队发生集成冲突的风险。 从本质上讲，DevOps旨在打破阻碍质量持续提升的障碍。通过相关步骤左移到 开发流水线的早期阶段，测试和反馈循环变得更快，这意味着开发人员开始更多地承担测试自己代码的职责。DevOps在很大程度上依赖自动化来降低每一步的风险，同时改进编码、测试和部署变更的工作流程。 DevOps带来了更高效的开发和部署，同时质量更高、故障更少、恢复时间更短。但是DevOps有一个没有明确解决的问题，那就是安全性。越来越快的压力致使团队很难优先考虑安全性，这也被视为开发过程中的障碍。 在传统的瀑布开发模型中，安全性通常是在最后添加的。图1-2展示了瀑布模型，其中涉及安全性的方面通常发生在验证和维护步骤中。 图1-2.软件开发的传统瀑布模型 这种安全方法在传统的单体软件开发过程中并不十分有效，对于基于现代微服务的应用来说就更糟糕了。因此�现了一种新的思维方式，将安全性集成到整个开发过程中：从DevOps演变为DevSecOps。 DevSecOps 当开发和安全性分开时，自然会产生摩擦。开发人员可能会将自身视为变革的驱动力，而将安全视为持续的障碍。众所周知，安全团队会因执行审计或调查问题而叫停开发。同时，开发人员却一次又一次地制造或忽略相同的问题，而不采用明确的解决方案。 DevSecOps将安全性作为DevOps的优先事项，将其置于应用程序开发的中心环节，并且对软件流水线中的每个人建立安全第一的理念。在DevSecOps模型中，安全是每个人的职责。这也是减少开发人员和安全工程师之间产生摩擦的第一步。 与DevOps一样，DevSecOps专注于打破团队之间的重重阻碍，使沟通变得更 透明化，目标是从一开始就在每个产品中构建安全性，在开发过程中尽可能地保持原有的速度和敏捷性。正如DevOps赋予更多开发人员测试自己代码的职责一样，DevSecOps将构建安全且合规的代码视为每个开发人员的首要任务。 DevSecOps将安全实践构建到应用程序开发生命周期的每个阶段，并在每个步骤提供反馈。安全性通常甚至在设计阶段之前就开始了，以培训的形式帮助开发人员学习安全的编码实践。安全团队与开发人员一起工作，帮助培训他们，记录安全策略和最佳实践，并指导每个人接纳安全思维方式。随着组织的DevSecOps实践的成熟，不同的团队开始将自己视为单一文化的一部分，并将安全视为核心目标。 DevOps和DevSecOps如何改变团队 虽然安全性曾经被视为开发结束时的附加功能，但DevSecOps使人们意识到应用程序中的每个组件都有可能受到攻击，并且必须在设计上保证绝对的安全。通过为软件开发过程带来灵活性和透明度，DevSecOps便转向于可在任何环境中部署的云优先软件。随着越来越多的公司认识到需要将安全性纳入软件开发的核心，DevSecOps逐渐成为主流，DevSecOps已经被证实是DevOps的自然演变，就像DevOps自然地从敏捷方法中成长�来一样。 DevSecOps所代表的理念转变意义重大。安全和DevOps团队的工作有了一个共同的目标：快速、安全地将高质量的产品推向市场。开发团队也将不会感觉到总是被安全流程阻断其工作，安全团队也将发现自己不再需要重复解决相同的问题，这使得团队能够保持强大的安全态势，能够发现并且防止漏洞、配置错误或者违反合规性策略的行为等。开发、运营和安全团队共同进行威胁建模，共享知识，籍此预测或者消除产品在其开发过程中涉及的潜在缺陷。 除了态度的转变之外，DevSecOps还提供了切实的好处。通过尽早地发现问题，团队可以为其客户提供更好、更安全的产品和服务。当紧急补丁或意外漏洞存在较少时，最终用户体验也会更好。DevSecOps可以更早地发现漏洞并且在部署之前就修复它们，这样也可以减少客户的宕机时间，从而使企业更具成本效益。 采纳DevSecOps的挑战 采纳DevSecOps实践具有非常明显的优势，但这并不意味着其中的每一步都很容易，从保护分布式应用程序的日常机制到重大的理念变革，DevSecOps都会为团队带来潜在的挑战。 传统意义来说，安全性侧重于易于理解的应用程序边界，通常围绕在单个数据中 心之间。随着企业采用DevOps、云原生以及基于微服务的应用架构，应用程序和安全性之间的挑战也将会分散开来。这些应用程序由在多个环境中运行的微服务组成，跨多个网域进行通信，并且处理来自全球的设备和用户数据，这就使得这些服务之间的攻击面又大又难定义，几乎不可能盘点这些服务之间的所有交互或者是通过公共和专用网络传输的所有数据。 与此同时，当应用程序的所有权从团队转移到更多的部门时，安全性很容易被抛在一边。如果单个工程团队认为安全是专门的安全团队的问题，那么他们就不会重视安全性。这往往会将安全性推向软件开发过程的后期阶段，此时安全性也将会变得更加困难且效率极低。 只有当开发团队充分了解安全时，左移才有效。开发人员不仅需要良好的安全开发实践经验，而且还需要足够的知识来理解他们负责解决的问题，这也就意味着需要花费时间和金钱来进行培训。 解决这些问题的关键是创建一种协作的理念，以安全为焦点建立快速、持续的迭代过程。这意味着之前许多独立分散的团队需要学习如何在一起协作：进行开发、IT运营和保持安全。安全性必须成为整个软件开发过程中各个方面的一种实践，并且必须保持持续，且不能中断。开发团队必须提供指导并且指导过程也不能中断，就像流水线的开发和运营部分一样保持连续性。 好消息是收益大于成本，当每个人的