系列文章（1）：浅谈企业 DevSecOps 实践：基本原则

系列文章（2）：浅谈企业 DevSecOps 实践：平安若何与研发协同事情

系列文章（3）：浅谈企业 DevSecOps 实践: 平安测试集成

系列文章（4）：浅谈企业 DevSecOps 实践: 构建平安工具链

本文旨在辅助平安职员为应用程序平安程序建立一个纲领或结构。 我们将回覆一些常见的问题，好比“我们若何最先构建应用程序平安计谋? ” “我若何最先合并 DevSecOps? ” 及”我应该遵守什么样的应用程式平安尺度? ”我将讨论软件开发生命周期(SDLC) ，先容在实行设计时需要思量的平安事项，并参考一些应用程式平安尺度，作为应接纳哪些平安措施的指引。 这篇文章将辅助你制订战略; 下一篇文章将先容战术工具的选择。

平安设计和你的 SDLC

平安软件开发生命周期(S-SDLC)本质上形貌了平安该若何顺应软件开发生命周期的差别阶段。 我们将研究 SDLC 中的每个阶段，并讨论哪些平安工具和手艺是适当的。 请注意，S-SDLC 通常是作为一个瀑布开发历程描绘的，具有线性历程中的差别阶段，但这现实上只是为了更清晰地形貌——现实的 SDLC 可能是迅速的、极限的，或者像瀑布一样的螺旋式的。 有充实的理由将 S-SDLC 基于更现代的 SDLC之上; 然则架构、设计、开发、测试和部署阶段都可以很好地映射到任何开发历程中的开发阶段。 它们提供了一个很好的起点，可以将当前的模子和流程顺应到 DevOps 框架中。

在我们之前的文章中，我们希望你将 S-SDLC 看作是构建你的平安程序的框架，而不是一个完整的循序渐进的历程。 我们认识到这与课堂教学和维基教学有所差别，然则对于每个阶段的平安设计来说更好一些。

界说和架构

· 参考平安系统架构: 参考平安系统架构适用于差别类型的应用程序和服务，包罗 web 应用程序、数据处置应用程序、应用程序的身份和接见治理服务、流或事宜处置、新闻通报等。 架构在公共云环境、 Kubernetes 集群和服务网格环境中甚至更有用——在这些环境中，我们可以通过计谋严酷控制每个应用程序的操作和通讯方式。 对于云服务，我们建议你行使服务提供商关于部署平安的指导方针，只管他们可能不会称之为“参考平安系统架构” ，但他们确实提供了这些指导方针。 领会应用程序平台，并询问软件设计师和架构师他们使用了哪些方式。 若是对于传统的应用程序，若是他们给你一个茫然的眼神，不要感应惊讶。 然则新的应用程序应该包罗流程隔离、星散和数据平安设计，以及完整的 IAM 模子，以促进职责星散和数据接见控制。

· 操作尺度: 与你的开发团队一起界说最小的平安测试需求，以及要害的和高优先级的问题。 你将需要协商哪些平安缺陷将导致构建失败，并提前界说流程。 你可能需要就修复问题的时间框架杀青一致，并需要某种类型的虚拟补丁来解决难以修复的应用程序平安问题。 你需要预先界说这些事情，并确保你的开发职员和 IT 合作伙伴赞成这些事情。

· 平安需求: 就像在代码验收之前必须运行的最小功效测试一样，你将在部署之前运行一组平安测试。 这些可能是针对你的团队所写的详细威胁而商定的一系列单元测试。 或者你可能要求所有 OWASP 十大破绽在代码或支持产物中获得缓解，将每个威胁映射到所有 web 应用程序的特定平安控制。 不管你选择什么，你的基准需求应该既思量到旧的功效，也思量到新的功效。 越来越多的测试需要更多的资源举行验证，而且随着时间的推移可能会减慢测试和部署周期，因此你可以决议哪些测试可以阻止公布，哪些测试可以扫描以便举行后期生产。

· 监控和器量: 若是你将在每个版本中举行小的迭代改善，那么需要修复什么？ 哪些代码模块对平安有问题？ 什么是有用的，你若何证实它？ 器量尺度是回覆所有这些问题的要害。 你需要思量需要网络哪些数据，并将其构建到 CI:CD 和生产环境中，以器量剧本和测试的执行情况。 这意味着你需要让开发职员和 IT 职员介入网络数据。 你将不断改善器量尺度的网络和使用，然则从一最先就要对数据的基本网络和流传举行计划。

设计

· 平安设计原则: 一些应用程序的平安设计和操作原则提供了重大的平安改善。 例如用于辅助修补和削减攻击者持久性的暂且实例、用于移除攻击外面的不可变服务、用于确保服务器和应用程序准确设置的设置治理、用于设置一致的云环境部署的模板、自动化修复、通过锁定开发职员和 QA 职员而将职责星散出生产资源等等。 同样主要的是，这些方式是 DevOps 的要害，由于它们使软件的交付和治理变得更快更容易。 这听起来似乎有许多需要解决的问题，但 IT 和开发职员也投入其中，由于这也使他们的生涯变得加倍容易。

· 确保部署管道的平安: 随着开发和生产环境加倍牢固，开发和测试服务器成为更具吸引力的目的。 传统上，这些运行环境的平安性很低或基本没有平安性可谈。 然则，对平安源代码治理、构建服务器和部署管道的需求正在增进。 由于 CI/CD 管道提供了进入生产的自动化路径，你至少需要对这些系统举行更严酷的接见控制——特别是构建服务器和代码库。 而且，若是剧本在后台延续运行，而且人工监视很少，那么你将需要分外的监视来捕捉错误和欠妥使用。 许多工具提供了优越的平安性，具有数字指纹、2FA、日志、以角色为基础的接见控制和其他平安特征。 当部署在云环境中时，治理台允许控制整个环境，必须异常小心地举行接见控制和职责星散。

· 威胁建模: 威胁建模仍然是最有成效的平安实践之一。 虽然 DevOps 没有改变这一点，但它确实为平安团队成员提供了机遇，可以指导开发团队成员处置常见的威胁类型，并辅助设计单元测试来应对攻击。 这个时刻你需要决议是否在公司内部培育这个人才，照样约请一个照料，由于没有哪个产物可以为你做到这一点。 威胁建模通常在设计阶段执行，但也可以在开发较小的代码单元时执行，有时也可以通过自建单元测试执行。

开发

,

币游usdt_ALLbet6.com

欢迎进入币游usdt网址（Allbet Gaming）:www.aLLbetgame.us，欧博allbet网址开放欧博allbet网址、会员注册、代理开户、电脑客户端下载、苹果安卓下载等业务。

,

基础架构和自动化优先: 自动化和连续改善是要害的 DevOps 原则，对于平安也同样主要。 正如前面的文章所讨论的，自动化是必不可少的，因此你需要选择和部署平安工具。 我们强调这一点是由于设计很主要，有助于开发职员在交付新代码之前设计出他们需要部署的工具和测试事情。 请记着，许多平安工具需要集成一些开发技术，因此要么设计让你的员工提供辅助，要么介入专业服务。 坏新闻是，在准备历程中需要预先支付用度和完成事情; 好新闻是，未来的每一个构建都将从这些起劲中受益。

· 自动化优先: 请记着，开发并不是编写代码和构建剧本的唯一团队——现在操作也是云云。 这就是 DevOps 若何将修复和加固带到一个新的水平。 运维的 DevOps 角色是提供构建剧本，用于构建开发、测试和生产服务器的基础设施。 好新闻是，你现在正在测试的是生产环境的正确副本。 模板和设置治理解决了传统 IT 多年来一直起劲解决的一个问题: 暂且性的无文档的事情“调整”环境使得环境能够正常事情。 同样，要使环境完全自动化需要做大量的事情——在服务器、网络设置、应用程序等等上面——然则它使未来的事情更快、更一致。 我们采访的大多数团队每周都市构建新的机械镜像，并更新他们的剧本以应用补丁、更新设置和构建剧本以顺应差别的环境。 然则这项事情确保了一致性和平安的基线。

· 平安代码存储库: 你希望为开发职员提供一种简捷的方式来获得平安的和(内部)批准的开放源码库。 我们的许多客户都保留了经由批准的库的内陆副本，使得接见这些资源变得很容易。 然后，在将代码部署到生产环境之前，他们使用身分剖析工具和剧本的组合，以确保开发职员使用的是经由批准的版本。 这有助于削减易受攻击的开放源码的使用。

· Scrum 中的平安性: 如前一章节所述，DevOps 是与流程无关的。 你可以凭据自己的喜欢使用螺旋式，迅速，或手术团队的方式。 然则迅速 Scrums 和看板手艺异常适合 DevOps。 他们专注于较小的、重点突出的、快速可证实的义务上，这很好地实现了协调一致。 我们建议在这个时刻设置你的“平安冠军”程序，在每个团队中至少培训一个人学习平安基础知识，并确定哪个团队成员对平安主题感兴趣。 通过这种方式，平安义务可以很容易地分配给那些有兴趣而且有一定的技术处置这些义务的团队成员。

· 测试驱动开发: 连续集成的一个焦点原则是永远不要将有错误或未经测试的代码提交到代码库中。 错误和未经测试的界说取决于你。 与编写伟大的瀑布式规范文档以提高代码质量或平安性差别，你正在用函数剧本和程序编写计谋文档。 单元测试和功效测试不仅界说而且增强平安需求。 许多开发团队使用所谓的“测试驱动开发” ，其中的测试确保所需的功效——并制止不需要的效果——与代码一起构建。 这些测试用例被存入代码库，并成为应用程序测试套件的永远部门。 平安团队没有充实行使这种类型的测试，然则这是检测特定于代码的平安问题的一个极好方式，而商业工具却没有这样做。

测试

· 为失败而设计: DevOps 推翻了 IT 和软件开发中许多历久坚持的原则。 例如，耐久性已往意味着“正常运行时间” ，但现在是替换的速率。 带有详细产物规格的大型文档已经被便利贴所取代。 对于平安性来说，曾经专注于让代码通过功效需求的团队现在正在寻找赶在其他人之前损坏应用程序的方式。 这种“混沌工程”的新方式有意损坏了应用程序的部署，迫使工程师在可靠性和平安性方面举行构建。 詹姆斯 · 维克特的《哥特列特》中有一句话: 对你的代码要刻薄——就像它雄辩地表达了你的头脑一样。 我们的目的不仅仅是在自动交付历程中测试功效，而且是要真正测试代码的坚硬性，并大幅度的提高可接受发行版的最低平安性。 我们通过在应用程序上线之前有意地对其举行种种功效测试、压力测试和平安测试，从而加强了应用程序的性能——削减了平安专家亲自测试代码所需的时间。 若是你能够找到某种方式来损坏你的应用程序，那么攻击者也有可能损坏你的应用程序，因此，你需要在应用程序启动之前构建测试以及补救措施。 你需要设计这些测试事情，以及构建它们所需的资源。

· 并行化平安测试: 所有迅速开发方式都有一个配合的问题，那就是若何处置比开发周期更长的测试。 例如，我们知道对要害代码片断举行模糊测试所需的时间比迅速 sprint 的平均时间要长。对大量代码举行 SAST 扫描通常要比构建历程长一个数量级。 DevOps 也是云云—— 使用 CI 和 CD 代码可能在建立后的几个小时内交付给用户，而且可能无法执行完整的白盒测试扫描或动态代码扫描。 为领会决这个问题，DevOps 团队同时运行多个平安测试以制止延迟。 他们将大型应用程序分解成服务，以加速扫描速率。 针对已知要害问题的验证由单元测试来处置，以便举行快速抽查，并将失败的代码返回给开发团队。 代码扫描器通常与单元测试或其他功效测试并行运行。 我们的看法是，作为一名平安专家，你应该寻找加速平安测试的方式。 组织效率与速率的测试以及完整性与完成时间的测试，对于我们交谈过的每个开发团队来说，都是一种连续的平衡历程。 将扫描集中在代码的特定区域有助于更快地发现问题。 一些公司还讨论了维护预填充和完全设置的测试服务器的设计——就像他们维护生产服务器一样——守候下一个测试周期以制止延迟。 为了提高效率和快速部署而重写和重新设置测试环境有助于 CI。

预公布

· 弹性 FTW: 有了公共云和虚拟化资源后，快速提供测试服务器变得加倍容易。 我们现在可以通过一些 API 挪用启动新环境，并在不使用时缩容。 行使随需应变的弹性云服务来加速平安测试。

· 测试数据治理: 开发职员和测试职员有一个异常坏的习惯，就是将生产数据复制到开发和测试环境中以改善他们的测试。 在已往的几十年里，这一直是许多数据泄露事宜的源头。 锁定生产环境，这样 QA 和开发职员就不能泄露受管制的数据，这很好，但也确保他们不会绕过你的平安控制。 数据屏障、符号化和种种工具都可以天生高质量的测试数据，从而最大限度的降低它们使用生产数据的念头。 这些工具提供来自生产数据的测试数据，但去除了敏感信息。 这种方式已经证实对于许多公司是乐成的，而且大多数厂商为 DevOps 管道提供了合适的 API 或自动化功效。

部署

· 手动与自动化部署: 通过自动化将新代码推入生产环境异常容易。 但对代码举行审查，或者在泛起错误时举行回滚，要难题得多。 与我们交谈过的大多数团队还不能完全顺应全自动化部署——这会吓坏许多平安职员。 连续的软件交付现实上只有少数公司使用。 大多数公司每隔几周才向客户公布新代码，通常是在一系列冲刺之后。 这些公司通过剧本执行许多部署操作，然则在操作和开发资源可用时手动启动剧本以完全监视推送操作。 有些组织确实对完全自动化的生产推送异常知足，天天会公布几回。 没有单一的准确谜底，但无论哪种方式，自动化都能完成大部门事情，从而腾出职员举行测试和监视。

· 部署和回滚: 为了仔细检查在预部署前的测试中事情的代码能够在开发环境中仍然可以事情，我们交谈过的团队仍然会举行“冒烟”测试，然则他们已经将这些测试进化为自动化和更细粒度的控制。 我们看到了三个常用于增强部署的技巧。 第一个也是最壮大的部署称为蓝-绿或红-黑部署。 新旧代码并排运行，各自在自己的一组服务器上。 在负载均衡器级别，若是发现错误，负载均衡器就会指向旧代码。 第二种是金丝雀测试，其中一小部门单独的会话是针对新代码的——优先的对内部员工的测试职员开放，然后开放给外部客户的子集。 若是金丝雀殒命(遇到错误) ，新代码将退出，直到发出的代码可以修复为止，此时将重复该历程。 最后，特征符号通过设置文件启用和禁用新的代码元素。 若是在新的代码段中发现了事宜错误，则可以关闭该特征，直到该特征获得修复。 在差别的模子和组织之间，自动化和人工干预的水平有很大的差别，但总的来说，这些部署比传统的 web 服务环境加倍自动化。

· 生产环境平安测试: 纵然平安控制失败，应用程序通常也能继续运行。 例如，一个新的部署剧本可能会错过对 web或应用层防火墙计谋的更新，或者应用程序可能在没有任何防火墙珍爱的情况下启动。 验证——至少是要害平安组件的健全性检查——对于生产环境是必不可少的。 我们采访的大多数大公司都雇佣了渗透测试职员，许多公司都有专职的“红队”来检查应用程序运行时的平安缺陷。

· 自动化运行时的平安防护: 许多公司将 Web 应用程序防火墙(WAF)作为其应用程序平安程序的一部门，通常是为了知足 PCI-DSS 需求。 与我们交谈过的大多数公司对这些工具都不知足，以是当他们继续行使 WAF 黑名单时，他们接纳了运行时应用程序自我珍爱(RASP)来填补剩余的空缺。 RASP 是一种应用平安手艺，嵌入到应用程序或应用程序运行时环境中，检查应用层的请求，以实时检测攻击和误用。 除了“应用程序上下文中的 WAF” ，RASP 还可以在应用程序框架的许多地方举行监控和执行，既可以针对特定类型的攻击定制珍爱，也可以允许 web 应用程序请求“完成” ，直到在阻止请求之前发现某个请求确实是恶意的。 在已往三年里，我们接到的险些所有讨论应用程序平安和 DevOps 的电话都讨论了 RASP，而且我们接触的大多数公司都部署了这项手艺。

应用程序平安尺度

现在已经有一些应用程序平安尺度可用。 开放式 Web 应用程序平安项目(OWASP) TOP 10和 SANS 常见弱点枚举 TOP 25 是最盛行的平安破绽，但也有其他威胁和常见弱点列表，这些列表通常侧重于特定的子主题，如云部署或应用程序平安器量。每个尺度都倾向于被一个或多个尺度组织所接受，因此你使用的尺度通常取决于你所处的行业。 或者你可以把它们都用上。

无论你的选择若何，我们的想法都是领会哪些攻击是常见的，并在构建管道中使用一个或多个平安控制和应用程序平安测试来注释这些攻击。 本质上，你构建的是一个威胁矩阵，并将它们映射到平安控制。 此步骤将辅助你设计接纳哪些平安工具并将这些工具放入构建历程，以及在生产中使用哪些平安工具。

Allbet声明:该文看法仅代表作者自己，与www.allbetgame.us无关。转载请注明：usdt充值接口（caibao.it）：浅谈企业 DevSecOps 实践: 平安设计