网络安全架构：建立安全架构方法的指导框架

01
关键发现

■ 架构框架使用集体见解来创建最佳实践，指导用户考虑组织风险和业务环境。这些方法的改编和定制，将帮助组织从中获得最佳价值。
■ 方法论提供了一种系统工程方法，使用业务输入和期望，来创建可重复、可跟踪（自下而上和自上而下）的安全架构定义。
■ 架构框架可与安全架构方法论成功结合使用，从而解决涉及框架（如合规义务）的业务安全上下文和需求。
■ 战略架构、逻辑架构、技术架构的变化速度不同，结果也不同。因为交付方法决定了技术组件是如何建立的，所以编程实现方法可以帮助在变更期间实现严密性。

02
主要建议

作为解决安全架构中的技术、信息和弹性风险的技术专家，您应该：

■ 规划您与组织高级干系人的互动，以积累业务上下文信息并促进安全架构的益处。

■ 使用框架方法（如NIST CSF）加速构建安全架构。您必须计划定制它，以满足您明确定义的业务和战略目标。

■ 使用安全方法论（如SABSA）定义业务上下文，并在架构层次之间提供系统工程级别的可追溯性和严密性。

■ 评估框架和方法论的组合（两者并非互斥）如何能“两全其美”地利用它们各自的好处。

03
问题陈述

安全架构方法论和框架方法为了实现它们的全部价值，执行起来可能很复杂。缺乏经过深思熟虑的安全架构，将导致部署无效的安全能力（要么部署过度，要么存在差距）。客户试图了解如何实现安全架构能力，以便更好地为其组织服务。有几种不同的策略，包括方法论和框架，每种策略都有优缺点。

对安全架构活动的一种批评是，它们通常被视为昂贵的一次性活动或阻碍敏捷交付的活动，并且很快就不能反映运行时的实际情况。本指南解释了如何开始构建您自己的以组织为中心的自定义的安全架构方法的过程，包括如何将安全架构嵌入到交付实践中。它提供了关于如何准备好将安全架构作为组织中正在进行的活动来实现的指导。

04
Gartner方法

安全架构是高度结构化的，无论是就第一原则使用方法论开发，还是定制一个架构框架。成功的实现，需要在选择、设计、集成到现有业务实践的整个过程中，进行仔细的管理。选择并在某些情况下合并方法，以提供最合适的安全架构流程，是实现业务目标所必需的。为了清楚起见，本指南帮助用户准备并为其组织选择最合适的路径。

该指南指导您完成应该计划的活动，以支持实现安全架构方法。阶段从具有确定步骤的战略需求到帮助形成逻辑安全。它建议为了设计过程的顺利进行做好准备，以帮助实现必要的安全组件和技术。实现战略技术目标，意味着安全架构必须是一个活的过程，而不是一次性事件。该方法提供了指导，帮助将安全架构嵌入到业务和ITT实践中，以确保其被接受和集成。

05
风险和陷阱

安全架构项目的常见风险包括：

■ 缺乏深思熟虑的安全架构将导致部署无效的安全能力（要么部署过度，要么存在差距）。要非常周密，并在安全架构实现的各个阶段，包括所有干系人，以确保安全能力没有被错误地部署。

■ 在实施安全架构过程时，未能定义范围将导致定义错误的安全架构。不完整的范围边界，与无范围边界或只是假设的范围边界一样糟糕。因此，应尽一切努力确保覆盖度和完整性。与IT领导一起确认并确保为您的安全架构过程定义了正确范围。

■ 如果在不了解风险的情况下开发安全架构，组织本质上是在开发一个上下文无关的通用控制模板。这将没有重点，也不会解决一个组织面临的真正风险。所有的安全架构活动都应该致力于管理风险。

■ 识别现有的安全和控制框架。如果忽视或忽略此步骤，则所需的控制框架需求与安全架构设计之间可能存在不一致。治理和设计之间缺乏一致性，将导致控制不足或缺失，这可能导致审计失败。与所有安全治理和风险团队合作，并使用组织安全策略和标准，以帮助构建安全架构。

■ 如果没有有效的沟通计划，重大风险将影响安全架构活动的整体成功。如果不计划让干系人，特别是高级职员参与进来，他们很可能不会在你需要的时候立即出现。制定干系人参与计划。

■ 不仔细规划和准备这一阶段的风险，将使我们无法定义有效的安全架构。关键的风险在于没有足够详细的组织和业务流程信息，来决定所需的逻辑安全服务。通过访问这类文档以及与整个组织中可以提供指导的干系人进行联系，可以缓解这些问题。

■ 始终检查分层防御。不要跳过它，因为那样会引入与安全架构缜密性相关的潜在风险。在纸面上看起来所有的要求都得到了满足。但是，应验证补偿控制是否充分满足了要求。

■ 需要定义足够的触发器，以促使安全架构师将现有安全架构应用于新项目。

■ 架构师必须努力确保当业务目标发生变化时，能够及时更新逻辑和技术安全架构。还必须维护和更新为DevOps创建的参考架构和编程组件等构件。

二、指导框架