基于业务驱动的企业安全架构(翻译，原作者john sherwood ；andrew clark； david lynas)— 第三章：安全架构模型 ---仅学习使用_lyh_helen的博客-爱代码爱编程

第 3 章：安全架构模型

本书提出的开发企业安全架构的方法基于六层模型。 该模型被用作架构开发过程的基础 — 一种方法论。 通过遵循与模型层一致的企业架构的开发，方法论变得不言自明。 后面的章节提供了有关这些不同方法中的步骤的指导。

在本章中，您将了解：
六层 SABSA ® 模型及其与 Zachman 框架的关系；
SABSA ® 模型六个水平层中每一层的详细解释；
SABSA ® 矩阵通过应用六个关键问题显示每个水平层的垂直分析：什么？ 为什么？ 如何？ 谁？ 在哪里？ 什么时候？

3.1． SABSA ® 模型

为了建立一个如何创建安全架构的分层模型，有必要暂时回到传统意义上的这个词的使用：建筑物的建造。

SABSA ® 模型由六层组成，其总结见表 3-1。 它密切关注 John A. Zachman 1 在开发企业架构模型方面所做的工作，尽管它已经在某种程度上适应了世界的安全观。 每一层都代表了不同参与者在指定、设计、建造和使用建筑物的过程中的观点。

表 3-1：SABSA ® 模型分层架构视图

这六层的另一种配置可能更有帮助，如图 3-1 所示。 在此图中，操作安全架构已垂直放置在其他五层中。 这是因为其他五层中的每一层都会出现操作安全问题。 操作安全在这些其他层中的每一个的上下文中都具有意义。

图 3-1：用于安全架构开发的 SABSA ® 模型

对于六层中的每一层的详细分析，SABSA ® 模型还使用了在 Zachman 框架中使用的相同的六个问题，这些问题由 Rudyard Kipling 在他的诗“我保持六个诚实的服务者”中雄辩地表达出来。

我有六个诚实的服务员
我有六个诚实的仆人（他们教会了我我所知道的一切）； 他们的名字是什么、为什么、何时、如何、何地和谁。我派他们穿越陆地和海洋，我派他们向东和向西； 但是在他们为我工作之后，我让他们都休息一下。

我让他们从九点到五点休息，因为那时我很忙，还有早餐、午餐和茶，因为他们是饥饿的人。但是不同的人有不同的看法； 我认识一个小人——她养着一千万的侍从，他们一点儿休息都没有！

她为了自己的事情把他们送到国外，从她睁开眼睛的那一刻起——一百万个Hows，两百万个Wheres，还有七百万个Whys！

3.2. 业务视图

当新建筑投入使用时，业主有一套架构必须满足的业务需求。 在最高级别，这由建筑物的描述性名称表示：它是家庭住宅、工厂、办公大楼、体育中心、学校、医院、仓库、剧院、购物中心、机场航站楼、火车站或其他任何地方。 这些业务用途中的每一个都立即意味着一种与其他所有不同的架构，这种架构将在业务方面满足对建筑物功能的期望。

在说明需要什么样的建筑物之后，业主必须决定有关其使用的更多细节：
 你为什么要这栋楼？ 您想要实现的目标。
 它将如何使用？ 详细的功能描述。
 谁将使用这座建筑，包括人员类型、他们的身体流动性、预期人数等？
 它应该位于哪里，它与其他建筑物和基础设施（如公路、铁路等）的地理关系是什么？
 什么时候使用？ 一天、一周、一年的时间以及随时间变化的使用模式。

在完成任何类型的设计工作之前，这种类型的分析是必不可少的。 正是通过这个过程确定了建筑的要求，而了解这些要求是设计满足这些要求的建筑的先决条件。

在设计安全的商业信息系统时，同样适用。 可以采用许多可能的架构方法，但最合适的一种将基于对系统业务需求的清晰理解。
 它是什么类型的信息系统，它的用途是什么？
 为什么会被使用？
 它将如何使用？
 谁会使用它？
 它将在哪里使用？
 什么时候使用？

这些是您必须提出的典型问题。 通过对收到的回复的分析，您应该能够了解安全系统的业务需求。 从这些您应该能够综合满足这些要求的系统架构和安全架构。
在 SABSA ® 模型中，此业务视图称为上下文安全架构。 它是对必须在其中设计、构建和操作安全系统的业务环境的描述。

任何试图定义一个走捷径并避免这一重要步骤的架构的尝试都不太可能成功。 尽管如此，简单的观察表明，许多从事建筑工作的企业并没有认真对待这个阶段。 系统架构工作从技术角度开始，关注技术和解决方案而忽略需求是很常见的。
必须首先了解需求似乎是显而易见的常识，但似乎很少有人知道如何在信息系统领域进行架构开发。 不幸的是，许多技术人员和技术人员认为他们已经知道这些要求，即使他们与可能表达这些要求的人关系不佳。

在架构开发的需求定义阶段走捷径的结果非常清楚。 当人们环顾许多大型企业及其信息系统基础设施经理或应用程序团队时，与商业社区的关系通常很紧张。 多年来，业务人员一直在抱怨信息系统人员无法满足业务需求，而 ICT 是一个严重的成本来源，几乎没有什么切实的好处。 原因很简单：商人是对的。 ICT 供应商的兴趣和技术创新往往推动业务系统开发战略，而不是由业务需求驱动。 那些负责架构和技术战略的人通常无法理解业务需求，因为他们不知道如何去做。 对架构原则的无知是司空见惯的。

本书描述了如何采用分层方法进行安全架构开发。 你们中的许多人会很想翻页以到达可以找到一些解决方案的结尾部分。 你很着急，虽然你知道这种循序渐进的方法是正确的，但你根本没有时间在开胃菜和开胃菜上逗留——你需要去吃肉。 好吧，请注意。 以正确的方式进行架构工作是无可替代的。 您可能会尝试走捷径，但您的努力很可能会导致失败，这会使企业花费更多的钱，带来更少的收益，并破坏业务人员对信息和通信技术作为实现业务的手段的信心发展。

在这里展示的模型中，上下文安全架构涉及：
What？ 业务、要保护的资产（品牌、声誉等）和业务对信息安全的需求（作为业务推动者的安全性、安全的电子商务、运营连续性和稳定性、遵守法律等）；
Why？ 以资产、目标、成功因素以及使这些风险面临的威胁、影响和漏洞表示的业务风险，推动了对业务安全的需求（品牌保护、欺诈预防、损失预防、法律义务、业务连续性等）。
How？ 需要安全性的业务流程（业务交互和事务、业务通信等）；
who？ 业务安全的组织方面（管理结构、供应链结构、外包关系、战略伙伴关系）；
Where？ 业务安全的业务地理和位置相关方面（地球村市场、分布式公司站点、远程工作等）；
when？ 在性能和顺序（业务交易吞吐量、生命周期和截止日期、即时操作、上市时间等）方面，业务安全的业务时间依赖性和时间相关方面。

3.3. 架构师视角

架构师是具有远见卓识的创造性人。 架构师因具有挑战性的业务需求而茁壮成长。 他们汇集了他们的技能、经验和专业知识，创造出一幅充满灵感的建筑图景。 它们提供印象派绘画和高级描述。 这些画是用粗笔和大笔画的。 他们为以后更详细的工作铺平了道路，当其他具有不同类型专业知识和技能的人将用精细的笔触填补空白时。

架构师的观点是可以满足企业业务需求的整体概念。 因此，架构模型的这一层也称为概念安全架构。 它定义了指导在较低抽象层选择和组织逻辑和物理元素的原则和基本概念。

在描述企业安全架构时，这里是描述您将使用的安全概念和原则的地方。 这些包括：
 您想保护什么，在 SABSA ® 模型中以 SABSA ® 业务属性配置文件的形式表达？
SABSA ® 业务属性在第 6 章中有更详细的解释。它们提供了主要工具，通过该工具可以以规范化的形式捕获业务需求。
 就控制目标而言，为什么保护很重要？
控制目标直接来自对业务运营风险的分析，是安全业务动机的概念化。
 在高级技术和管理安全策略方面，您希望如何实现保护？

这些战略制定了概念分层框架，用于在较低级别整合各个战术要素，确保这些要素以有意义的方式结合在一起，以实现业务的总体战略目标。 此类策略包括：应用程序安全策略、网络安全策略、密码基础设施策略、基于角色的访问控制（RBAC）策略等。 对于上下文安全架构中确定的业务需求的每个主要领域，都会有一个安全策略（或策略组）来支持它。
 在实体关系模型和实体相互交互的信任框架方面，谁参与了安全管理？
重要的信任概念涉及管理域内信任的各种策略机构、它们设置用于管理每个域中实体的行为的策略以及域间信任关系。
 您想在哪里实现根据安全域概念化的保护？
这里的重要概念是安全域（逻辑和物理）、域边界和安全关联。
 就时间点和时间段而言，保护何时相关？

重要的概念是生命周期和到期期限（密钥、证书、密码、会话等），以及使用可信时间进行时间戳和时间敏感的业务交易。 同样重要的是与时间相关的性能标准 — 事情必须发生多快。

3.4. 设计师视角

设计师接替架构师。 设计师必须解释架构师的概念愿景，并将其转化为可以设计成真实建筑的逻辑结构。 架构师是艺术家和有远见的人，但设计师是工程师。
在商业计算和数据通信领域，这个设计过程通常被称为“系统工程”。 它涉及整个系统的逻辑架构元素的识别和规范。 此视图将业务建模为一个系统，系统组件本身就是子系统。 它从逻辑安全服务的角度展示了主要的架构安全元素，并描述了控制的逻辑流程以及这些逻辑元素之间的关系。 因此它也被称为逻辑安全架构。
就通过层向下的架构分解而言，逻辑安全架构应该反映和代表概念安全架构中的所有主要安全策略。 在这个逻辑层面，来自更高层的一切都被转换为一系列逻辑抽象。

逻辑安全架构涉及：
what？ 业务信息是真实业务的逻辑表示。 需要保护的正是这些业务信息；
why？ 明确业务信息安全的安全策略要求（高级别的安全策略、注册权限策略、认证权限策略、物理域策略、逻辑域策略等）；
How？ 指定逻辑安全服务（实体身份验证、机密性保护、完整性保护、不可否认性、系统保证等）以及它们如何作为通用的可重用构建块组合成一个复杂的安全系统，满足整体业务需求；
who？ 以模式的形式指定实体（用户、安全管理员、审计员等）及其相互关系、属性、授权角色和权限配置文件；
where？ 指定安全域和域间关系（逻辑安全域、物理安全域、安全关联）；
when？ 指定安全处理周期（注册、认证、登录、会话管理等）

3.5. 建设者的观点

架构的设计者将工作过程移交给建造者。 建造者是可以将逻辑描述和图纸转化为可用于建造架构的技术模型的人。 建造者的工作是选择和组装物理元素，使逻辑设计成为真正的架构。 因此，这种观点也被称为“物理安全架构”。

在商业信息系统的世界中，设计者产生一组描述要构建的系统的逻辑抽象。 这些需要转化为描述实际技术模型并指定各种系统组件的功能要求的物理安全架构模型。 逻辑安全服务现在以用于提供这些服务的物理安全机制和机器来表示。
总的来说，物理安全架构涉及：

what？ 指定业务数据模型和与安全相关的数据结构（表、消息、指针、证书、签名等）；
why？ 指定驱动系统内逻辑决策的规则（条件、实践、程序和行动）；
How？ 指定安全机制（加密、访问控制、数字签名、病毒扫描等）以及托管这些机制的物理机；
who？ 以用户、他们使用的应用程序和安全用户界面（屏幕格式和用户交互）的形式指定人员依赖性；
where？ 指定安全技术基础设施（硬件、软件和通信线路的物理布局）；
when？ 以执行控制结构（序列、事件、生命周期和时间间隔）的形式指定时间依赖性。

3.6. 供应商视角

当建筑商计划施工过程时，她或他需要组建一个由每个建筑行业的专家组成的团队：瓦工、泥水匠、电工、水管工、木匠等等。 每一个都为整个施工过程带来了一些非常具体的生产技能和一些非常具体的产品。

信息系统建设也是如此。 构建者需要组装来自专业供应商的一系列产品和具有集成技能的团队，以便在设计实施期间将这些产品连接在一起。

每个集成商都相当于一个商人，使用的专业产品和系统组件相当于建筑材料和组件。 其中一些“行业”与硬件相关，一些与软件相关，还有一些面向服务。 “工匠”使用一系列组件，包括硬件项目、软件项目以及接口规范和标准。 因此，架构模型的这一层也称为“组件安全架构”。

组件安全架构涉及：
what？ 数据字段规范、地址规范等详细的数据结构规范；
why？ 安全标准；
how？ 产品和工具（硬件和软件）；
who？ 用户身份、权限、功能、操作和访问控制列表 (ACL)；
where？ 计算机进程、节点地址和进程间协议；
when？ 安全步骤计时和排序。

3.7. 运营视角

当建筑物完工时，那些设计、设计和建造它的人会搬出去，但在它的生命周期内必须有人来管理它。 这样的人通常被称为运营经理。 运营经理的工作是处理建筑物的运营及其各种服务，使其保持良好的工作状态，并监控它在满足要求方面的表现。 执行此操作的框架称为“运营安全架构”。

在业务信息系统领域，运营架构与经典系统操作工作有关。 这里只关注该工作中与安全相关的部分。 运营安全架构涉及以下内容：
what？ 确保业务系统和信息处理的运营连续性，维护运营业务数据和信息的安全性（机密性、完整性、可用性、可审计性和问责制）；
why？ 管理运营风险，从而最大限度地减少运营失败和中断；
how？ 执行专业的安全相关操作（用户安全管理、系统安全管理、数据备份、安全监控、应急响应程序等）；
who？ 为所有用户及其应用程序（业务用户、操作员、管理员等）的安全相关需求提供运营支持；
where？ 维护所有运营平台和网络的系统完整性和安全性（通过应用运营安全标准并根据这些标准审核配置）；
when？ 安排和执行安全相关操作的时间表。

然而，回到图 3-1，运营安全架构还有另一个维度 — 它与模型的其他五层的垂直关系。 因此，运营安全架构需要在其他五层中的每一层进行详细解释。 表 3-2 显示了这一点，其中包含与每一层相关的运营活动类型的一些示例。

3.8. 检查员视角

业务信息系统中还有另一种安全观，即检查员的视角，它关注的是确保架构在各个方面都是完整、一致、健壮和“适合用途”的。 在信息系统安全领域，这是由计算机审计员或系统质量保证人员执行的安全审计过程。

然而，SABSA ® 模型并不认为这是一个单独的架构视图。 SABSA ® 审计和保证方法是架构模型作为一个整体支持这些需求。 这种架构的存在是审计人员确定安全正在以系统和适当的方式应用的方式之一。 该框架本身可以提供一种构建审计过程的方法。 此外，安全审计和审查被视为与概念层相关的运营安全架构中的主要战略计划之一（见表 3-1）。
表 3-2：运营安全架构

ACL：Access control list；访问控制列表
ACE：Access control entry (in an access control list)；访问控制条目（在访问控制列表中）

3.9. SABSA ® 矩阵

在上面的部分中，架构模型的六个水平抽象层（上下文、概念、逻辑、物理、组件和操作）中的每一个都进行了检查。 每个部分还介绍了通过每个水平层的一系列垂直切割，回答问题：

What:你想在这一层做什么？ – 您的安全架构要保护的资产；
Why: 你为什么这样做？ – 希望应用安全性的动机，用这一层的术语表达；
How: 你想怎么做？ – 在这一层实现安全所需的功能；
Who:谁参与？ – 这一层安全的人员和组织方面；
Where:你在哪里做？ – 您应用安全性的位置，与该层相关；
When: 你什么时候做？ – 与该层相关的与时间相关的安全方面。

这六个垂直架构元素现在汇总为所有六个水平层。 这给出了一个 6 x 6 的单元矩阵，它代表了企业安全架构的整个模型。它被称为 SABSA ® 矩阵（见表 3-3）。 如果您能够解决这些单元中的每一个提出的问题，那么您将涵盖所有需要回答的问题，并且您可以对您的安全架构是完整的 3 充满信心。 开发企业安全架构的过程是填充所有这 36 个单元的过程。
表 3-3：36 Cell SABSA® 矩阵

3.10. 运营层的详细 SABSA ® 矩阵

当检查表 3-3 的最低层（操作安全架构）并参考表 3-2 时，很明显该操作层可以进一步分解为 SABSA ® 矩阵映射到五个中的每一个 上面的层。 换言之，存在与上下文、概念、逻辑、物理和组件层中的每一个相关联的操作方面。 表 3-4 提供了对操作安全体系结构的更详细了解。

表 3-4：运营安全架构矩阵

3.11. 总结：安全架构模型

本书中使用的 SABSA ® 安全架构开发模型有六层：
上下文安全架构——业务视角；
概念安全架构——架构视角；
逻辑安全架构——设计视角；
物理安全架构——建设视角；
组件安全架构——供应商视角；
运营安全架构——实施视角。

运营层可以被视为跨越其他五个层，因为这些层中的每一层都有运营方面。 通过提出六个基本问题，进一步分析这六层中的每一层：
What?
Why?
How?
Who?
Where?
When?

将水平分层分析与六个关键问题的垂直分析相结合，生成了一个由 36 个单元组成的表格，称为 SABSA ® 矩阵。
还有另一种架构视图——检查员视角。 对于企业安全架构，这是安全审计员的观点。 在 SABSA ® 模型中，这被视为操作安全架构的一个组成部分，因此它在模型中没有单独的层。

SABSA ® 矩阵为开发和记录您的企业安全架构提供了一个框架。 必须依次处理每个单元格（尽管不一定按照严格的顺序）。 因此，安全架构文档的结构很可能是矩阵的每一行都有一个章节，该行中的每个单元格都有一个章节内的部分。 通过采用这种方法，您可以高度确信您的安全架构是全面的。