网络安全架构 | 安全架构设计的双模方法论

Posted 2021-04-10 网络安全观

全文约3900字   阅读约10分钟

安全架构治理 的目标，是在设计过程中尽可能早地将安全性集成到数字业务的结构中，而非传统的“与业务对齐”的目标。这意味着须将重点从维护保障性和遵从性，转向提供务实的业务成果。

由于业务和IT呈现出“双模”特征，安全架构设计也应该采取双模方法，以保障“双模IT”。

安全架构的双模方法（bimodal approach），是指采用两个单独的过程，来开发安全架构解决方案，既支持传统项目，又支持敏捷项目。安全架构设计应该变得更加灵活。

模式1（传统模式）：适用于遵循传统开发方法的项目，或基于已被实施解决方案模式的敏捷项目。此模式基于 由内而外的视角，通常关注于 最大化重用现有标准和解决方案； 为已知的、确定性的领域而优化 ；在该模式中，安全架构表现为一个 集权者。

模式2（敏捷模式）：适用于敏捷开发项目，以探索新的、创新的技术解决方案。此模式 基于由外而内的视角， 常常需要使用创新性、不成熟的安全技术，和更灵活、定制化的解决方案； 为未知的、不确定性的领域而优化 ；在该模式中，安全架构表现为一个 合作者。

令人费解的是，Gartner提出的双模方法，在其之后的重量级安全架构文章（即《 》和《 》这两篇）中未见踪影。

笔者推测 ：“双模”可能是被安全架构中不同层次（即概念层、逻辑层、实现层）的不同“变化速率”所吸收和消解。关于这个问题，仍需深入推敲，暂且点到为止。

本文目录

一、挑战与建议

1）关键挑战

2）主要建议

二、双模IT与传统安全架构过程

1）双模IT

2）传统安全架构过程

三、数字业务特性如何影响安全架构实践

四、开发安全架构设计的双模方法

1）模式1方法

2）模式2方法

五、调整安全架构治理理念以支持双模方法

一、挑战与建议

数字业务项目不适合传统的安全架构实践。安全和风险管理领导者 必须采用双模方法（bimodal approach）来开发安全架构，以支持敏捷的数字项目。

 

01

关键挑战

安全架构实践的关键挑战如下：

• 试图将传统的安全设计方法应用到敏捷的数字项目，必然会失败。

• 虽然数字业务意味着创新、敏捷、速度和复杂性，但它并不否认在安全设计和规划中需要某种一致性。

• 传统的安全架构实践让我们对不完整的敏捷项目感到不安，这导致了在数字业务世界中难以管理的风险。

安全架构实践应该变得更加灵活，既支持传统项目，又支持敏捷项目。 

02

主要建议

采用安全架构作为其网络安全管理计划之关键要素的安全和风险管理领导者，必须：

• 研究数字业务的特性如何影响安全架构实践，以了解如何更改安全架构过程。

• 通过建立支持传统项目和敏捷项目的独立方法，开发安全架构规划的双模方法。

• 调整其安全架构管理理念，以支持双模方法。

这三个方面，正好是后面三章（第三、四、五章）的主题。

二、双模IT与传统安全架构过程

01

双模IT

所谓“双模”，来自于“双模IT”的概念。 双模是管理两种独立但一致的工作风格的实践：一种侧重于更具 可预测性的情况，另一种侧重于 需要探索的情况。

• 模式1是为更易理解的领域而优化的。

  它专注于开发已知的东西。

  这包括修复遗留环境，使其适合数字世界。

• 模式2是探索性的，强调通过实验来解决新问题。

  模式2是为不确定性领域而优化的。

模式2通常工作于新计划/倡议，其始于一种假设：在一个 短迭代过程中被测试和适应，潜在地采用了 最小可用产品（MVP ）或 最小市场化产品（MMP ）的方法。

01

传统安全架构过程

传统的架构规划基于迭代步骤，从业务上下文开始，经过三个越来越细粒度的层——概念层、逻辑层、实现层（参见图1）。

图1-传统安全架构过程

对于这些层中的 每一层，都会发布制品（文档、模型、图表、标准等），以便可以重用它。

双模IT中模式2数字计划的敏捷性、动态性，不适用于逻辑制品（如技术标准）和实现层制品（例如产品标准）的重用。这些项目的性质（探索性、迭代性、敏捷性、持续性）和技术（新的、创新的、经常未经验证的），都要求更特别的定制化安全设计。

另一方面， 传统规划方法仍然可以应用于安全基础设施和模式1规划。

三、数字业务特性如何影响安全架构实践

传统的安全架构实践，基于两个关键假设：

• 大多数应用程序或基础设施的开发过程将足够长，以允许安全架构师有足够的时间来为给定的应用程序或基础设施设计适当的安全组件，既可以重用现有组件，也可以设计新的控制组件。

• 在应用程序和基础设施项目中存在足够的一致性和通用性，以使架构安全控制组件（标准）的重用水平更高。

而 数字业务的一个关键特征是应用程序和系统的开发和实现方式的彻底变革，通常被称为“ 敏捷”和“ DevOps”方法。这一变革导致组织 必须采用双模方法来管理IT组合。

如图2所示，传统项目（对应于模式1）往往有固定的范围，而其期限、成本、质量都可以根据情况加以调整（即可变的）。 实现最初的目标是至关重要的。

相比之下， 敏捷项目（对应于模式2）本质上是更具探索性的 ， 具有灵活的范围和固定的期限、成本、质量。因此， 这样的项目通常不适用于逻辑层和实现层制品的重用。项目的性质（探索性、迭代性、敏捷性、持续性）和技术（新的、创新的、经常未经证实的）， 要求更灵活、定制化的安全设计。

图2-敏捷实践与传统实践

尽管如此， 在大多数企业中，遗留环境并没有消失。它通常仍然需要相当时期的变化和发展，即便不是因为别的原因，而只是为了让它更容易数字化（例如通过添加移动前端）。 虽然这些变化可以使用敏捷技术来实现，但通常是通过传统方法来完成的。

这种 动态性意味着，与企业的其他部分一样， 安全架构功能必须采用双模方法。

四、开发安全架构设计的双模方法

安全架构的双模方法是指采用两个单独的过程来开发安全架构解决方案（见图3）：

• 一种传统方法（模式1），用于遵循传统开发方法的项目和计划，或基于已经实施的解决方案模式的敏捷项目。

• 另一种新的动态方法（模式2），支持敏捷开发项目，以探索新的、创新的技术解决方案。

图3-双模安全架构方法

01

模式1方法

模式1方法基于传统的架构实践。该过程从重用 概念层制品（或开发新制品）开始。它们是相对稳定和相对抽象的意图、目标和模型，直接受到业务上下文和相关业务驱动因素的影响。在此之后，通过 逻辑层（那些可以作为实现概念目标的策略而应用的思想、方法、技术）和 实现层（被开发或购买的用于实现概念和逻辑设计的原材料和资源）的抽象，通过迭代地开发（或重用）更详细的制品，开发出必要的 安全解决方案。

如前所述， 此方法基于一组稳定的解决方案模式和一种高级别的重用。

02

模式2方法

相比之下，模式2的方法类似地开始于考虑文档化的业务上下文和驱动因素，以及任何现有的安全原则，其被认为是 概念层制品。 在此之后，安全设计过程变得更加特别 ，并被定制为正在开发的敏捷项目。 并非关注于最大化重用现有标准和解决方案，重点转移到理解在敏捷项目中通常固有的新技术的风险影响，并为它们开发定制化的安全解决方案。考虑到许多敏捷项目的数字技术本质（例如，基于物联网[IOT]、运维技术[OT]、人工智能[AI]或区块链技术），这 常常需要调查和投资更具创新性和不成熟的安全技术。 威胁建模可以帮助这种努力。

然而，务实的架构师理应在这个过程中偶尔参考文档化的安全架构，来检查是否存在可利用的现有模型或标准。

一旦开发了敏捷的模式2项目的解决方案，在实施过程中必须小心，使新的解决方案与现有的技术环境相适配。新解决方案所固有的任何残留安全风险，不应对其将部署的现有环境的隐含风险偏好产生负面影响。这种适配可能需要投资额外的控制（或重新设计的控制），使新的解决方案生产可以适应现有环境的背景。组织还必须投资于管理和支持任何新的、可能创新的、不成熟的安全技术所需的技能或服务。

五、调整安全架构治理理念以支持双模方法

治理安全架构的更加务实的方法，隐含于双模安全架构策略中，并且在一定程度上是双模安全架构策略的先决条件。

主要的目标是在设计过程中尽可能早地将安全性集成到数字业务的结构中，而不是传统的“与业务对齐”的目标。 从治理的角度来看，这意味着将重点从维护保障性和遵从性，转向提供务实的业务成果——安全架构团队必须是“知道中心”（Center of Know），而非“拒绝中心”（Center of No.）。

在实践层面上，这意味着 安全架构必须允许在标准开发过程中有两种不同但同时发生的视角（见图4）：

• 传统的由内而外（inside-out）的视角：基于安全团队的中央权威和经验证的标准。

  从这个角度来看，安全架构作为中央权威，规定了必须采用的刚性标准、规则、指令。

  这通常适用于对遗留环境和模式1项目所做的更改。

• 一种由外而内（outside-in）的视角，基于单个数字解决方案的特别业务需求，更具协作性。

  从这个角度来看，安全架构作为一个促进者，与数字业务所有者合作，以做出适当的风险决策，并开发模型、示例、指导方针，以可选择性地用于敏捷模式2项目。

  由于“由外而内”方法更以客户为中心，它有助于安全解决方案也变得更以用户或客户为中心。

• 此外，在更具创新性、以数字为主导的企业中，安全架构职能部门还必须采用“由外而外”（outside-out）方法，对外部环境进行扫描，找出可以纳入本组织安全架构准则的非正式、通用的做法。
  

图4-确定合适的安全标准以支持数字业务

（本篇完）

安全架构系列