有关安全漏洞的坏消息似乎无休止地流传到世界各地的IT系统，IT安全问题已成为关注的焦点。 违规行为对一些知名大公司造成了不良压力，对许多公司造成了财务损失，并在某些情况下对国家安全造成了风险。 这些是在IT组织中引起安全问题并再次查看组织的安全策略和过程的正当理由。
但是，某些组织中的安全团队被视为阻碍创新和变更速度。 应用交付团队（开发，质量管理，运营）认为安全团队与他们的目标不符。 应用程序交付团队有动力快速交付新的创新功能。 安全团队决心确保新系统和功能的安全性以及安全功能的强大性。 这些目标似乎不一致。
但是，关于业务成果，目标一点也不矛盾。 业务成果–缩短实现价值的时间，交付创新的业务解决方案，创建高质量的产品，增加市场份额–所有这些都需要应用程序交付团队不断提供功能和安全团队来不断保护它们。 这些团队拥有相似的目标，但是从不同的角度来对待它们。
这些看似对立的目标之间的紧张关系导致了DevOps运动的诞生。 顾名思义，DevOps的开发旨在解决开发（Dev）和运营（Ops）团队之间缺乏协作与合作的问题。 与开发和安全团队一样，对开发和运营团队的评估也有所不同。 根据开发团队产生新功能和创造变更的能力来衡量开发团队。 根据运营团队保持系统稳定和可用以确保稳定性的能力对其进行评估。
DevOps运动旨在解决这一挑战，并打破开发团队和运营团队之间的障碍。 DevOps功能需要改变组织文化（人员），改变团队的工作和协作方式（过程），以及转向自动化以减少容易出错的手动任务（工具）。 DevOps原则以精益思想为基础， 精益思想是导致精益制造原理发展的一系列方法。 DevOps将这些原则应用于应用程序交付，促进开发团队与运营团队之间的协作，减少浪费，最大程度地减少返工，消除流程瓶颈并限制生产过剩。 DevOps利用移动和更改的特性，使更改变得容易，快速和可重复，从而提高了交付速度并提高了稳定性。
随着DevOps的成熟和在企业中的广泛采用，DevOps的范围必须扩大到包括所有为应用程序交付做出贡献的团队和利益相关者。 与DevOps原则促进开发和运营团队之间的协作和信任一样，它们可以改善开发，运营和安全团队之间的协作和信任。
当安全团队仔细检查并保护应用程序交付流程时，必须与开发和运营团队合作以确保DevOps交付管道和流程的安全。 考虑到精益思想的根源，DevOps并非旨在以牺牲安全性为代价来最大化速度。 它旨在在较短的周期内从较小容量的功能块提供快速反馈。 这种快速的交付和连续的反馈周期可以帮助提高安全性。 在DevOps生命周期中包括安全性可确保确保交付的应用程序和系统的安全是整个交付生命周期中的一个持续过程，而不是在交付周期结束时添加的步骤。
正如精益制造彻底改变了工厂自动化和产品交付一样，DevOps改变了应用交付。 工厂自动化的问世要求开发实践以确保产品交付组装线的安全。 进货的组件，生产线工人，自动化专家，组装过程和其他要素必须得到保护和验证。 同样，安全从业人员需要与应用程序交付团队合作，以保护和验证应用程序交付从业人员本身，流程和自动化工具的安全。 安全性必须成为采用DevOps不可或缺的一部分。
本文探讨了应用程序交付中的安全漏洞。 随着组织采用DevOps，必须缓解这些漏洞。 本文还包括有关安全团队如何与应用程序交付团队合作解决和减轻这些安全风险的指南。
管理与安全相关的风险
企业担心企业中使用的所有软件中都存在残留漏洞的风险。 这些风险包括：
- 与供应链有关的漏洞
- 恶意行为者的内部攻击
- 源代码丢失或泄露
- 开发过程的颠覆
- 开发项目中的错误和错误
- 设计，代码和集成方面的缺陷
这些风险适用于任何类型的软件开发生命周期或方法，包括：瀑布项目，敏捷项目或采用更广泛的DevOps方法的项目。 由于DevOps项目具有简化的性质和先进的自动化功能，因此在整个交付生命周期中，必须以连续的方式检测和应对与这些风险相关的事件和状况。
对于每种风险，以下各节介绍了DevOps项目的特殊注意事项。
与供应链有关的漏洞
任何包含在项目外部创建的软件组件的软件项目都可以说具有软件开发供应链。 组件可以由公司内部的供应商创建，也可以由拥有或交付软件项目的公司或组织外部的供应商创建。 来自软件供应链的软件的安全特性对项目中创建的软件的安全性具有重大而持久的影响。
在传统的开发项目（包括瀑布式项目和迭代项目）中，开发团队通常需要评估供应链中软件的安全特性。 评估包括审核组件文档，基于许可和支持能力寻求批准以及执行安全扫描。
DevOps开发团队可以在整个项目生命周期中做出实时设计，编码和集成决策，从而获得最大的灵活性。 由于这个原因，开发团队可能会选择供应链组件，这些组件可以宣传更大的功能和集成的便利性，并且会轻视组件的安全性和保证属性。
为了减轻此限制，请通过采用持续测试（DevOps的主要宗旨），在软件交付过程中进行严格的质量检查。 该实践包括在交付周期的每个阶段进行测试。 这些测试包括开发人员运行的代码级测试，这些测试与组件的使用者共享测试结果。 自动化的功能，性能，集成和安全性测试； 以及对交付的每个组件的手动和自动代码审查。 由于DevOps鼓励在较短的周期内向每个组件交付较小的块或更改，因此结果是在交付组件时不断测试较小的更改。 这种方法减轻了相关的风险。
演员的内部攻击
尽管确切数字尚不清楚，但市场上的证据表明，过去五年来，内部人员实施的所有网络犯罪所占的百分比在统计上是显着的。 这些攻击可能导致源代码丢失，源代码泄露或开发过程的颠覆。
这些攻击可能源自恶意内部人员的直接行动，也可能是由开发环境中使用的网络，工作站或服务器上的恶意软件感染导致的。
为了减少在传统开发环境中发生此类攻击的可能性，通常对开发基础结构进行保护和检测，以检测和警告异常。 DevOps环境中的高级，简化的自动化增加了检测和检测异常的难度，这些异常可能导致源代码丢失，源代码泄露，恶意软件部署或颠覆开发过程。 通过在交付周期内执行的一组测试任务中包括安全测试（白盒和黑盒安全测试），可以减轻这种限制。 这些安全测试在每次迭代或sprint中运行时，都可以检测到任何此类恶意攻击。
虚拟的，软件定义的基础架构使得其配置处于变更控制之下，从而可以进行审核。 重复分解和重建DevOp组装流水线的零件的能力有助于最大程度地减少这些零件上持久性恶意软件的发生。
开发项目中的错误和错误
传统的开发项目，无论是瀑布式还是迭代式，通常都由项目管理以及项目跟踪工具和系统支持，这些工具和系统提供了经过协调的工作流和任务完成检查点。 特别是，在完成软件产品发布之前，需要进行项目审查，其中包括检查主要任务和里程碑完成情况的证据。
应用精益（敏捷）或DevOps方法的项目往往具有较短的交付周期，其中较小的组件或对软件产品的更改被更频繁地交付。 尽管可能不会将每组更改交付给客户或用户，但快速而短暂的周期可能导致不太严格的项目审阅和对主要任务和里程碑完成情况的较不仔细的检查。 这些快捷方式可以使开发项目中的错误和错误不受限制地进入开发周期。 但是，DevOps项目的目标是将软件项目的较小组件交付给质量保证团队和项目审查流程，以减少较大的项目错误和错误首先发生的风险。 通过更频繁地交付较小的软件组件更改，尽早发现较小的错误，可以降低总体风险。
设计，代码或集成方面的缺陷
如果供应链的安全性得到适当管理，并且内部攻击和项目错误得到控制，则任何形式的开发项目中最大的剩余风险就是引入了漏洞，可以在软件部署后加以利用。 这些弱点可能会在整个开发项目的设计，编码和集成中引入。
使用以下策略之一将软件漏洞的可能性降到最低：
- 执行迭代测试和修复。
- 实施“设计安全”策略。
迭代测试和补救策略可以在不限制成本和进度且可以使用综合测试工具的小型项目中使用。 在开发DevOps项目的同时，通过设计确保安全的开发策略也日趋成熟。 IBM安全工程框架所举例说明的安全设计开发策略可以应用于DevOps项目。
使用以下部分中描述的方法，该方法将IBM安全工程框架中的八种基本实践应用于DevOps样式项目。
为解决安全性奠定基础
DevOps自动化的采用类似于制造系统从人力密集型到更加精简和自动化的转变。 制造过程已经从在正确的时间和地点在生产车间交付正确的位置发展到在生产线上定位步骤，再到控制，精确和高速的机器人系统，而不是依靠人工来安装，连接，移动和组装单元。
安全风险适用于非自动化和自动化系统。 探索每种风险如何在制造设施和精简精简的制造环境中出现。
供应链中的漏洞示例
在制造业中，存在多个向组件供应链交付零件的供应商，这会带来漏洞。 这些供应商可以有意或无意地提供低质量或有缺陷的组件。 在传统的供应链中，人们会注意到所提供的组件出现问题时，他们会举起警告线。 此手动过程可降低风险。
在广泛使用自动化的精益项目或DevOps项目中，自动化过程是否会检测到供应问题，这取决于自动化元素是否包含质量保证检查以验证进货。
两种情况下的缓解措施都是管理和验证传入的供应链。 对于精益或DevOps项目，这涉及添加测试门以取代过去由人类执行的监视功能。 例如，可以实施一组自动化测试，以验证刚刚收到的新级别的开源工具包是否在指定的容限内运行，以供包含的应用程序使用。
防止参与者进行内部攻击的示例
在制造过程中，生产线工人可能会故意使配件连接不正确，无法连接某些东西，将异物插入生产线中的装配中，甚至破坏他人的工作，然后通过擦拭干净设备来掩盖其痕迹。
在DevOps应用程序交付环境中，自动化取代了单个从业人员。 但是，自动化工具的程序员（例如，自动化的创建者）也可能会将行为插入自动化中，从而可能部署恶意软件，破坏配置或以其他方式篡改系统。
在这两种情况下，缓解措施都是在工作人员之间进行制衡，或者在自动化的情况下，在自动化代码的创建中涉及多个制衡。 内部控制可通过控制范围，审核范围以及在发布之前进行多次签名和批准来防止。 可以将类似的防护和门作为测试用例创建并内置到自动化中。 考虑到自动化本身的创建可能是一个可能的攻击点。 在变更管理下使用软件定义的基础结构有助于减轻攻击点。
源代码丢失或泄露的示例
为了将制造类比应用于软件开发，源代码要么是用于在装配线上创建装配的原材料，要么是工人创建装配所遵循的蓝图和计划。 无论哪种情况，销毁或删除代码/计划，或篡改代码/计划都将影响组装线上的组装。
对于DevOps应用程序交付环境，对源代码（原始材料或编译器用来构建二进制组件的源）处理不当会导致篡改或损害。 篡改用于开发自动化（机器人运动或部署自动化）的设计材料或说明可能会导致类似的不良结果。
装配线上的缓解措施是对原材料以及计划和设计进行严格的控制和审核，并进行定期的质量保证测试，以确保装配与设计相匹配并且原材料没有被篡改。 在DevOps软件交付模型中，对组件的更多自动化测试可验证它们是否符合规范。 此外，监视，审核和强制执行对设计材料，源代码和源代码的访问以实现自动化（代码组装和部署的恶意行为），以确保它们没有任何安全漏洞或漏洞。
开发过程颠覆的例子
类似于生产装配线，生产线工人可能不遵循设计的装配线过程和程序。 流水线中的每个工人都有一个标准操作程序（SOP）要遵循。 违反这些程序可能会导致产生有缺陷的产品。
在应用程序交付环境中，存在针对从事软件编码，集成，测试，部署和类似任务的从业人员的SOP。 背离这些步骤可能会导致交付有缺陷的软件。 对于机器人或自动化框架，错误的自动化编程可能导致错误。
最近，一家国际金融服务公司的交易错误导致该公司蒙受4.4亿美元的损失，其原因可追溯到部署工程师，他们没有正确执行部署SOP。 由于该公司没有进行自动或人工的质量检查，无法验证部署是否按照正确的流程完成，因此未发现该错误。
为降低装配线的风险，对生产线工人进行有关流程和程序的充分培训，并进行监督和质量检查，以不断确保工人遵循流程。 在应用程序交付环境中，可以使用工具自动执行流程，监督和质量检查。
开发项目错误和错误的示例
在制造业中，人们在工作中会犯错误和错误。 人为进行的工作容易出错。 错误可能由生产线工作人员和设计生产线工作人员的流程引起。
在应用程序交付环境中，错误有多种形式：代码或脚本中的错别字，文档中的错误，数据输入中的错误以及类似情况。
为了减轻装配线上的风险，请实施监督和质量控制，并创建可以防止错误或尽早发现错误的强大系统。 在应用交付系统中，随着时间的流逝，减少错误的方法不断发展。 可以将测试嵌入代码中，以验证代码并验证应用程序中代码组件的正确使用。 DevOps鼓励构建“防脆弱”系统，这些系统包括冗余，强大的错误恢复和自我修复功能。 在此方法的一种极端实现中，一些公司采用了一种方法，其中，如果某个节点的任何虚拟实例检测到它有错误，它将用一个新实例替换自身，并取消提供遇到该错误的实例。 没有尝试修复该错误。
设计，代码和集成方面的弱点示例
在制造过程中，设计师（建筑师和机械工程师），过程工程师（工业工程师和团队负责人）和装配工（机械师和装配工）之间的交接和通信会导致装配不良，制造过程中发生变化，零件弯曲以适合装配，更换飞行中的其他零件以及其他解决方法。 对通常在公司外部的承包商或供应商的依赖加剧了这一挑战。 交接错误的一个臭名昭著的例子是阿波罗13号（Apollo 13）事件，在该事件中，未将月球火箭子系统的电压要求变化传达给承包商，导致在月球飞行期间发生近乎灾难的事故。
在应用程序交付中，当团队将其代码移交给其他开发代码的团队或负责集成，质量保证，构建和部署的团队时，会发生此类移交错误。 需要多个供应商和供应商来完成跨公司边界的这些移交，进一步加剧了这一挑战。
为了减轻制造中的风险，制定了供所有供应商遵循的制造标准。 这些标准，再加上有关组件规格和切换质量检查的大量文档和通讯，有助于缓解这些问题。 在应用程序开发中，已经开发了用于组件接口的行业标准，但是团队仍然必须依靠合同和服务水平协议（SLA）来帮助减轻这些切换挑战。 提供自动化而不是手动切换和部署的标准工具有助于减轻切换带来的风险。
API的经济性和安全性
除了这些安全漏洞之外，API经济的新趋势还增加了其他安全问题。 应用程序编程接口（API）是服务提供商提供给使用这些接口的消费者的编程接口，这些消费者使用这些接口将API公开的应用程序功能包含在他们要交付的应用程序中。 API越来越流行，因为企业将其视为围绕其服务创建市场的一种方式。 市场可能是内部的，对合作伙伴开放，或者对服务的外部消费者开放。 例如，一家银行可能向其支付系统公开API，以便银行的其他部门甚至第三方服务提供商可以在其应用程序中包括利用银行所公开的API的支付系统的功能。
随着越来越多的API可用，API本身或API的恶意用户所引入的安全漏洞风险可能会损害它们所暴露的系统。 为了降低风险，请对API和使用它们的应用程序应用强大的测试协议。
API提供者必须确保开发的API不会将其暴露给可能危害其系统的恶意用户。 这些安全漏洞可能是流氓开发人员有意或无意引入的。 API使用者必须确保通过API访问或传递的数据是安全的，并且应用程序正确使用了API，同时不存在任何安全风险。 供应商和提供商都必须使用正确的身份验证和配置协议，以确保仅允许有效使用API，并且任何第三方都不能滥用所提供的API访问权限。
为了使用DevOps原则减轻这种风险，请持续进行严格的安全测试，以确保API安全性的稳健性。 API提供者和使用者都必须在API的每个新发行版中对API进行严格的自动化测试。 他们必须进行连续测试，以确保及时发现并解决对API的任何滥用或破坏。 这些测试必须包含在API本身的部署过程中，以确保对API以及使用API的所有应用程序的部署过程进行连续的安全性测试，以确保应用程序的安全性。 安全测试和安全监视是跨开发，测试和生产环境的连续处理过程。
结论
在工厂车间和软件开发中采用精益原则可以减少浪费和返工。 同样，就像工厂自动化导致一系列新的潜在安全风险并要求采用缓解这些风险的方法一样，采用DevOps做法也可能导致新的安全风险。 本文介绍了与采用DevOps有关的一些风险，以及缓解这些风险的建议方法。
采用DevOps的好处是可以带来更高效的软件交付。 这种快速灵活的软件开发，测试和交付方法所带来的安全风险得到了很好的识别，并且可以轻松解决。 它们不能被忽略。 正如忽略与工厂自动化相关的安全风险可能会导致严重的质量控制挑战一样，不解决DevOps做法所暴露的相关安全风险也可能导致严重的质量问题。 随着DevOps从具有一套指导原则的哲学发展为具有相关采用途径的一套明确定义的实践，解决这些安全风险必须成为这些实践的固有部分。
采用DevOps的组织和团队可以通过将组织的安全团队纳入DevOps生命周期中来确保减轻安全风险。 这些团队需要成为利益相关者，负责分析和确定哪些风险与组织中的不同项目有关，并制定应对和缓解这些风险的策略。 安全团队必须为DevOps环境贡献以安全为中心的质量门，这是协作的一个示例。
DevOps引入了一种持续交付和连续测试应用程序交付组织正在交付的少量功能的方法。 安全团队可以利用这种交付方法来降低安全风险。 通过持续保护这些较小的功能发布，它们可以在生命周期的早期识别安全漏洞并尽早减轻影响。
翻译自: https://www.ibm.com/developerworks/library/d-security-considerations-devops-adoption/index.html
344
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
