安全架构，应该成为安全规划和安全设计的手段。

一、前言

之前，介绍过美军网络安全系列和零信任架构系列：

美军网络安全系列：参见《美军网络安全 | 第6篇：备受关注的云安全》；

美国零信任架构系列：参见《网络安全架构|《零信任架构》NIST标准草案（下）》；

这些很自然地促使我们思考美军网络安全架构和美国零信任架构的构建逻辑。

我们当然相信，万丈高楼平地起，再美的架构也是历经了岁月磨炼，经由长期实践经验和理论总结而出。这是自底向上的视角。

另一方面，从自顶向下的视角看，它们的背后也存在着顶层架构设计的逻辑。本篇正是这种视角的介绍。初步计划，也会分几篇展开。

安全架构介绍的依据，主要来自于Gartner的相关资料。很幸运地，Gartner在近两年围绕安全架构主题进行了集中研究和输出，为我们提供了所需的知识储备。

二、认识安全架构

1）安全架构的定义

“安全架构”（security architecture）一词仍没有正式的、普遍接受的定义。

Gartner的定义：安全架构是计划和设计组织的、概念的、逻辑的、物理的组件的规程和相关过程，这些组件以一致的方式进行交互，并与业务需求相适应，以达到和维护一种安全相关风险可被管理的状态。

比如，SABSA（Sherwood应用业务安全架构）就是一个用于企业安全架构和服务管理的框架和方法论。

传统的架构规划基于迭代步骤，从业务上下文开始，通过越来越详细的抽象层，即概念层、逻辑层、实现层，最终到达运行解决方。如下图所示：

架构连续体

除了抽象的概念层、逻辑层、实现层之外，架构框架也可以有不同的视图，例如技术、过程、信息。每个层/视图组合中，可能有零到多个组件/工件。一系列示例如下图所示。

架构组件的示例

2）对安全架构的忽视

许多组织都缺少安全架构的观念。

这是因为一个错误的假设，即一个安全控制列表（有时再加一个安全产品的购买清单）足以定义他们在安全领域需要做些什么。即使是那些尚未被纯粹合规性思想所毒害的组织，即那些已经意识到自身风险的组织，有时也会认为“风险驱动控制”，而剩下的只是实施。

合规性要求和控制框架的一个问题在于，它们并不总是反映业务、IT或安全技术的发展。例如，安全技术专家曾试图在一个敏捷的环境中，实现支付卡行业数据安全标准（PCI DSS）的合规性。在这种环境中，代码每天都在变化。事实上，大多数安全团队所处的环境都变化很快，这种变化既包括组织内的，也包括组织外的。

3）对安全架构的认知

安全架构只是地图和图表的观念需要被改变。

安全架构确实是一个创建工件的过程，但它也提供了更多的细节，以确保严格部署控制点来管理组织风险。下图突出显示了安全架构涉及的一些观念。

安全架构认知

组织需要开发一种安全架构能力，使其不断成熟和完善，以解决组织所面临的复杂安全问题。

4）安全架构的意义

安全架构，应该作为一致的、连贯的规划和设计安全性的手段。

安全和风险管理技术专业人员一直面临着挑战：如何将业务问题、威胁、敏捷IT与他们需要构建的防御体系联系起来。安全架构可以解决这类问题。

在信息系统领域，架构并不是一个自然的概念。20世纪80年代，John Zachman的工作（即Zachman框架）将架构带入了现在所知的IT世界。今天，我们的立场是：理解和实现正确的IT架构，尤其是安全架构，是组织成功的关键因素。

如今，随着业务、IT和威胁的迅速变化，安全架构变得更加重要。在过去，一些人希望基于一种合规性的静态控制列表和一种经过时间考验的静态架构，来提供组织所需的风险降低效益。事实上，它从未真正发挥作用。

在云计算、移动性、物联网和人工智能时代，诞生于20世纪90年代的网络防御方法需要发展，或者可能被新的思维所取代。我们的安全必须适应不断变化的数字服务和技术。这就需要重新构建能够支持敏捷、不断变化的环境的安全架构框架和方法论。

如果旧模型不能适应这个新世界，就需要创建新模型。

5）安全架构功能在组织中的定位

关于安全架构功能在组织中的位置，Gartner发现了两种情况：

第1种：安全架构向企业架构组织报告并与之集成；

第2种：安全架构向信息安全组织报告并与之集成。

这两种情况都可能导致成功和失败，而且都不能作为每个组织的正确选择。

第一种选择有时会导致“象牙塔”综合症，安全架构师失去了与运营安全现实的联系。

第二种选择可能会导致一些安全架构师过分痴迷于安全供应商的解决方案，而将实际的架构实践抛在脑后。极端地说，这导致一些组织将安全架构师仅仅视为更高级的安全工程师，而不是企业安全架构专家。这个错误导致了相当大的负面效应。

更重要的似乎不是安全架构的位置，而是安全需求和架构需求是否一致。安全架构，顾名思义，是关于安全和架构的。团队——或者是唯一的安全架构师——将不得不同时管理这两者。

6）安全架构与企业架构的关系

安全架构可以是一些企业架构框架的一部分，但并不是所有组织都使用它们或拥有企业架构实践。当然，安全架构可以在没有企业架构的情况下存在。

此外，企业架构和安全架构团队可能在真实的组织中彼此分离甚至敌对。至少，由于他们的职责不同（例如，业务敏捷性和风险规避的不同），他们可能会提供不同或冲突的建议。

那么，安全架构师是更像企业架构师，还是更像安全专家？当然，答案是“都是”。

安全架构与企业架构功能密切结合，可能是一个很好的方法。可以在项目中启动安全架构的参与，无论是常规运营还是使用敏捷方法。快速和持续的开发，以及敏捷的项目管理过程，可能使得嵌入安全架构过程具有挑战性。然而，寻求部署敏捷方法的组织，如DAD（Disciplined Agile Delivery），应该看到安全架构团队可以参与和增加价值的机会。安全架构师可以作为敏捷交付团队成员（对于足够高风险或高调的项目）或作为支撑角色。

安全架构的实践通常与企业架构非常一致。事实上，我们建议，在共同的领导下，企业架构应作为IT安全的对等组织工作。企业架构团队应该由来自应用程序、基础架构、IT安全的架构师组成。

业务结果驱动的企业架构能力，侧重于创建可操作的建议，以提供创新的方法。它们提供明确的架构指导，并使用完全支持业务活动的工具和实践进行操作。

安全架构师应与企业架构协作，以确保安全架构基于风险的部署建议是明确的，并与企业架构输出保持一致。安全架构提供的指导，提供了完整的可追溯性，可以由多方使用，包括企业领导、风险管理和审计功能。下图说明了安全架构和企业架构之间的协同作用，应该利用和扩展它们来安全地满足业务目标。

将安全架构功能映射到企业架构

任何架构的起点都是业务需求，通过风险评估，业务需求驱动了安全能力的需求。

三、安全架构的优点

安全架构提供了一个动态的安全架构，随着组织和IT系统的发展、变化和转型，该架构会随着组织的发展而成长，并支持实际的维护。

安全架构在风险和合规要求以及组织IT和业务流程的复杂性之间，起着桥梁的作用。

安全架构提供了一种结构化的方法，向任何/所有IT服务、应用程序和平台添加安全控制，以利用业务机会和解决安全风险。

安全架构为解决方案设计提供了灵活性，因为您定义了要遵循的架构原则，而不必是一个预定义的设计和预选好的产品。

安全架构提供了一种机制，从之前未协同的行动方式，向高度逻辑化、结构化的方式转变，允许显性地遵守内部安全政策和外部标准（如需要）。

此外，安全性存在于一个合规性驱动的世界中。通常，监管和法律需要清楚地表明如何满足特定的控制。而一个定义良好的安全架构，就可以证明这一点。它不仅有助于记录原样状态，而且还可以用于规划未来状态。

下图中的类比很好地显示了这一点。

安全架构的类比

总而言之，安全架构可以使您的组织进入正确的“轨道”。

1）改善安全态势

安全架构可以改善组织的安全态势，因为方法和框架可以提供与组织需求相一致的正确控制。安全架构提供了不同的安全视图，每个视图都为组织中不同的干系人（从企业所有者到技术人员）提供了相关性和有用性。

安全态势可以通过实现安全架构过程来改进，这些过程审查重要的设计原则，例如纵深防御/分层、分区和最小权限访问。

安全架构也为组织提供了系统性解决安全风险问题的信心。

安全架构是一种系统性解决业务安全问题以及安全政策和法规要求的方法。它为组织提供了信心，使其能够根据业务和风险状况采用最恰当的控制措施。它提供了一种结构化的方式来沟通安全期望，以便随着业务的适应和变化，可以及时地规划和实施安全控制，以继续提供必要的保护。

2）提供严谨性和结构

安全架构为安全工作提供了严密性和结构，从而始终如一地、可靠地满足策略需求。

很多组织不考虑和不了解安全架构，但会购买和部署安全产品。问题在于，因为缺少安全架构，这些组织无法确定他们部署的安全产品是否会降低风险。这导致，许多组织在某些领域部署了太多的安全技术（通常有很多重叠的功能），而在其他领域部署的安全技术又太少或根本没有。

安全架构方法（方法和框架）通过将决策建立在一个集合逻辑结构上，将严格性应用于这个过程。为了避免退化，存在一些逻辑规则，用于说明它如何随着环境和威胁的变化而变化。如下图所示：

使用安全架构以应用严谨性

安全架构提供了一组分层的概念，包括业务层、逻辑层、技术层。由于不同的激励因素，每一层的“速度”或变化率是不同的，这需要仔细管理。

在业务层和逻辑层，安全性的业务需求必须与业务战略保持一致，逻辑需求必须满足这些业务需求。一般来说，这些层不大会快速变化，但是随着时间的推移，业务需求可能会产生重大变化（例如，引入灵活性/可伸缩性/敏捷性。而安全架构需要人工过程，来跟踪和关注对逻辑安全架构的影响，并考虑这些影响需要如何反馈到架构的技术层中。

在技术层，还有其他因素和条件会影响安全架构的实例化方式。例如，对敏捷性的需求意味着可能需要在交付中嵌入更多的安全自动化。因此，安全架构过程必须以现代软件开发生命周期的速度适应技术的变化。

3）识别当前状态和未来状态，创建路线图

安全架构允许您评估当前状态和开发未来状态，并比较差异，以创建如何实现安全路线图。

概要（Profiles）是控制优先级、预算和解决差距的工具。可以使用NIST CSF来度量控制的实现层，直至子类别。

首先，创建当前状态的概要。然后，评估风险暴露面，并确定未来状态的概要。从当前状态到未来状态的更清晰、更合理的差距分析，参见下图：

使用NIST CSF概要从当前状态转移到未来状态

NIST CSF没有定义由谁执行以及如何执行风险评估，这取决于组织及其内部治理。差距分析利用了这种风险评估。我们可以衡量哪些地方需要解决最大的风险。然后，当我们定义所需状态的安全架构时，我们可以开始将实现工作划分优先级。然后，这种优先顺序可以输入到项目规划和未来预算中。

Gartner建议优先考虑能够提供最快收效和最大影响的任务。这些任务需实现起来相对简单，并解决所识别的最高风险。通常从客户实践来看，简单的实现可以带来更好的结果。这将在最短的时间内为您提供最有效的安全性。然后，应根据风险优先级将任务编排成近期和长期计划。使安全架构成为一个持续的过程，不断评估和规划，提出新的明确安全需求。

4）提供可追溯性

双向可追溯性是安全架构方式的另一个关键优点。它允许组织实现从战略到业务需求再到具体技术或过程的控制。

可追溯性提供了有效控制的持续保证。可追溯性有助于审计工作开展。

风险和机遇可以在概念层面（安全属性）进行评估，并在较低层面进行审查，以确保有效的控制措施到位（或确定必须纠正的差距）。

方法论方法和框架方法的可追溯性略有不同，但两者都依赖于阶段之间严格、可信的步骤。如下图所示：

框架和方法论的可追溯性

四、安全架构的方法

安全架构的实践可以利用方法论方法和框架方法。

最简单的定义：

框架是一套系统的控制点和实践的集合——关于“什么”的条目集合。

方法论是一系列从起点到目标的实施步骤——关于“如何”的指南。

稍微复杂的是，方法论可以引用一个（或多个）框架，其中的一个或多个步骤可以指导客户使用框架。这是很自然的，因为方法论的一个（或多个）步骤可能非常复杂，需要一个框架。

安全架构方法论的一个典型例子是SABSA，同时还有一些与安全架构相关的框架。NIST CSF有时被当作控制框架和有限的架构框架。例如，遵循SABSA方法论的组织也可以使用NIST CSF。

1）安全架构的方法论和框架

安全架构方式（方法论和框架）都建议使用最佳实践、标准和特定领域的控制框架来支持和验证战略思维。这并不意味着必须盲目接受并实现框架中的控制点。相反，指南是提供对所需控制点的洞察，并确保战略架构是完整的，从而实现可追溯性。

安全架构方法论和框架都是通过更好地传达安全期望来提高组织中安全严谨性的有效方法。它们都提供了本文概述的安全架构思路的好处。

2）安全架构方法的差异

安全架构方法论为逻辑架构创建上下文和概念基础。它们代表了通过架构思维获得结果的途径。下图概述了对安全架构的输入。

安全架构的输入

仔细考虑对安全架构的输入，可以使业务期望和安全需求紧密结合。安全架构框架利用用户群体之间的相似性来定义共同点。为了成功并获得最大的价值，用户必须定制框架以适合他们的组织。

方法论和框架都严格定义了在解决方案范围内使用的安全控制措施。

方法的不同会导致不同的误解。安全架构方法论有时被指责过于笨拙、过于复杂或不可操作。而框架则被错误地解释为不灵活或过于规范。

3）安全架构方法论的示例：SABSA

还有其他的方法论，例如Open Group的Open Security Architecture(OSA)和Open Enterprise Security Architecture(O-ESA)。其中，SABSA现在拥有最活跃的社区，其他社区则处于休眠状态。SABSA是一种在全世界都很流行的方法论，组织一直在使用它来开发和维护安全架构。

因此，SABSA是方法论的典型例子。它建立在Zachman企业架构方法论的基础上，根据相关方的视图对架构的各个方面进行了结构化定义（即什么、如何、哪里、谁、何时以及为什么）。SABSA采用了一个类似的结构，称为SABSA矩阵。虽然通常被称为“框架”，但它们并不是一组控制措施的集合。这个结构可以称之为“元框架”，用于帮助描述组成安全架构的视图和组件。

方法论提供了一种系统性的工程方法，来获取业务输入和期望并创建一个可重复、可跟踪的安全架构定义（从底至上和从顶至下）。安全架构方法论提供了使用多个视图来唯一性的定义安全的方法，以支持跨组织的相关方。每一层中各个方面之间的关系允许双向跟踪，展示安全组件和服务如何满足业务需求，以及帮助证明为什么这些安全组件对保护业务需求是合适的。

使用SABSA，架构师应该关注策略域和信任的相互关系，以帮助如何对这些域进行分解，从而建议应该在哪里分配属性。在这里，架构师可以定义需要哪些低层次的控制措施,这需要深入了解业务的驱动因素。要做好这项活动，必须深入了解组织，包括要保护的业务流程和功能。

此外，创建逻辑安全架构时应该将安全标准（用于帮助组织满足监管需求或其他遵从性需求）纳入。获得这些洞察后，将它们转换并映射到工件，以创建处理实体之间逻辑域和信任的控制措施集合。如下图所示：

SABSA逻辑安全架构

SABSA是一种开发有效安全架构的方法论，它关注业务需求，同时考虑处理风险和机会。它提供了从业务计划到可部署安全组件的可跟踪（以及反向跟踪）方法。SABSA是模型、视图和方法的组合，以帮助安全专业人员根据自己的需要全面和系统地定义架构。

SABSA利用不同的视图组合来帮助逻辑地获得和呈现安全架构。这些视图如下图所示。它们支持一开始使用自顶向下的方法（从业务级别往下到从业人员）开发安全架构，稍后，使用自底而上的可跟踪性来确保架构的严密性。

SABSA方法论的核心原则是SABSA矩阵。需要注意的是，并非SABSA矩阵中所有的项目都需要完成，只需要架构师团队认为对组织和范围有用的那些项目。

4）安全架构框架的示例：NIST CSF

需要说明，安全架构框架与控制框架或控制列表是不同的。ISO/IEC 27001包含控制措施，但没有提到安全架构决策和实践；支付卡数据安全标准(PCI DSS)包括一些网络安全架构建议，但交付的是控制措施列表；NIST SP 800-53是联邦信息安全管理法(FISMA)提出的分级的控制措施，几乎不包含架构指导。

而像NIST CSF这样与架构更加一致的框架，既不是标准也不是方法论。相反，它们是帮助描述组织当前和未来网络安全状态的方法。它们允许用户识别跨组织业务活动的网络安全风险，然后构建一个控制能力的概要。这些概要可用于将业务活动与所需的网络安全活动相结合。框架方法是灵活的，可以处理与目标组织相关的不同威胁、漏洞和风险概要。框架与标准紧密交互，寻求使用最佳实践来选择和部署安全控制措施。

框架假定业务上下文需求和驱动是明确和已知的。一些框架假定它们是输入，而另一些框架假定它们是固定的风险和安全需求。

当然，为了从安全架构中获得价值，需要对其定制。这提供了一种“足够好”或“适合我们需求”的方法，而无需实际考虑它是否直接映射到业务上下午以实现安全性。一些安全框架允许一定程度的定制（通常在指导原则或范围内）。

NIST CSF可以用两种不同的方式，创建分层的、基于组织需求的逻辑安全架构：

新部署的能力可以使用NIST CSF确定其安全需求，明确定义与业务需求相匹配的类别和子类别需求。这可以用作部署所需的逻辑安全架构的目标概要文件。

可以评估整个企业现有的部署，提供一个当前的概要文件。然后，在风险评估后，为目标概要文件提供类别和子类别。

当通过目标概要文件定义逻辑安全架构的理想未来状态时，应该考虑其他需求，包括与特定外部标准保持一致的需求。由底向上的方法考虑被保护的技术环境（包括系统和应用程序）时，应确保分层是一致的。不了解技术层可能会导致问题。例如，设置特定的逻辑安全服务，却发现只能通过一组补偿性控制措施来实现，这使得安全架构看起来欠考虑。

框架可以和安全方法论一起成功使用，以便处理业务安全上下文以及涉及框架的需求，例如合规性义务。如下图所示：

使用框架进行架构

如前所述，NIST CSF是一个通用框架。此安全框架提供了一种方法为组织定义逻辑安全架构，使用定制的控制来与本地策略保持一致。它让用户能够识别跨组织业务活动的网络安全风险，然后构建一个控制能力概要。这些文件可用于将网络安全活动和业务活动关联起来。

这种采用框架的方法具有灵活性，并且能够定位与目标组织相关的威胁、漏洞和风险。组织可以调整框架以适应其组织。示例框架如下图所示：

NIST CSF核心功能和分类

五、建议

1）采用安全架构思想

首先要向您的组织介绍安全架构概念和方法。使用安全架构明确安全战略、信任映射关系、域结构和相互关系、风险映射、差距分析以及当前和未来状态概要。

安全架构方法为系统地解决业务安全问题提供了严谨性和说服力。因此，通常在风险评估之后，使用它们来解决确定的安全问题。

使用安全架构方法（如SABSA）为逻辑的和技术的安全架构创建上下文和概念基础。这就使得企业的业务和对安全的期望更加一致，但这个目标对许多企业来说都是困难的。

2）开始演进您的安全架构

当安全架构思想建立之后，无论您使用的是方法论方法还是框架方法，都要开始从高层收集业务安全需求用以指导安全架构。安全架构不是一组固定的控制，而是更智慧的处理风险的方法。

在定义业务上下文时，应确保所有的干系人的需求都得到了表达，以避免组织的某些部分出现空白和缺少内容。需遵循以下步骤：

定义范围并了解环境

获取战略安全愿景

支持开发逻辑安全架构

促进安全技术架构设计

保持安全架构的动态性和生命力

3）创建安全架构

将安全架构作为最佳安全治理的一部分，进行适配和实现。包括安全策略、教育、监控和流程，从而最佳地处理组织安全风险。

为了达到最好的效果，使用安全方法论，并以业务上下文作为输入。然后，随着逻辑安全架构的形成，利用安全框架的最佳实践指导来支持这项工作。

4）维持有生命力的安全架构

对安全架构的一种批评是，它是一次性的活动，很快就不能反映运行时的实际情况。特别是对于采用敏捷开发流程、云本地技术和CI/CD活动的企业而言，这可能是一个问题。

这就需要确保从业务上下文到组件控件的可跟踪性。建立一个持续审查安全架构的流程，以确保由于业务、技术或威胁场景的变化而出现的紧急风险得到处理。

在不断变化的环境中维护当前安全架构的方法包括:

定义和维护安全架构。这些解决方案可以是高级的或已构建的、随时可用的(或重用的)架构解决方案，以适应特定的用例、模式或其他逻辑需求。

将安全架构活动设计为开发和运行活动，以支持持续的管理和控制。

为了支持灵活性和敏捷性的战略需求，安全架构需要适应集成、自动化和其他技术功能的工具。

安全架构可以是一种以书面形式与领导探讨和理解业务方向、策略的活动，目的是为根据内部安全治理和外部标准塑造逻辑安全。它还包括设计完善的技术参考、准备好交付点的组件，以供项目根据需要进行配置。

总之，需要选择创建能够经受住时间考验的有生命力的架构的方法，如下图所示：

架构可持续化

六、结论和预告

当今快速发展的业务环境，需要组织特别关注安全架构。使用安全方法论和框架，可以创建并发展组织自己的安全架构。

关于安全架构的方法论和框架的更多信息，将在下一期《建立安全架构方法的指导框架》中讨论。