OpenGroup 和 SABSA 研究院联合发表了一份白皮书,名为《TOGAF 与 SABSA 集成:看 SABSA 和 TOGAF 如何相辅相成共同创建更好的架构》,旨在研究将风险管理和安全架构方法集成到 TOGAF 这一建立完善的企业架构方法论中。Jim Hietala,Open Group 的副总,在其博客上引用了白皮书中的以下几行文字来解释这一文章的用意:
长久以来,信息安全一直被认为是一门单独的学科,孤立于企业架构之外。这份白皮书记录了使用 SABSA®安全架构方法来增强 TOGAF®企业架构方法论的方式,从而创建一种全面的架构方法论。
文章一开始简要介绍了 TOGAF 和 SABSA 用于集成的相关概念,包括:TOGAF 架构开发方法(ADM)、TOGAF 内容元模型、SABSA 模型、SABSA 矩阵、SABSA 生命周期以及 SABSA 业务属性概要。因为这两套方法论都是业务驱动的,这就被用来作为捆绑两种方法论的基础。此后的章节便着重于集成的一些细节,它们遵循以下三大原则:
- 风险管理是选择安全措施的驱动力——使用 SABSA 方法来进行运维风险管理是由业务驱动的而非威胁驱动。而业务驱动的方式也考虑到了在为取得积极成果中所涉及的风险全景,而威胁驱动方式只注意最小化或消除损失故障的可能性。这种相辅相成、积极的风险观是 TOGAF-SABSA 集成的根本基础。
- 需求管理在成功的架构开发中起着核心作用——TOGAF 遵循需求驱动的方法,SABSA 业务属性概要则为获取架构需求提供了一个强大的技术支持。
- TOGAD 架构开发方法论(ADM)是一个主流的架构交付流程——这份白皮书中展示了哪些安全架构工件关联到 ADM 中的相关各阶段,这样安全架构就成为企业架构的有机组成部分。如此一来,SABSA 以 TOGAF 的语言来描述,就为 TOGAF 和 SABSA 提供了一种共同的语言,从而促使从业者之间能更好的进行信息交互。
另外集成需要遵循以下三大规则:
• 当某一工件看似出现在不同的架构层次时,那么抽象层次最高的那个应被用做映射。这样一来,集成就可以将其重点放在企业层次。而企业层次恰恰是 SABSA 提供增值的地方。
• 如果两个不同的映射相互抵制,那么请使用最明显的那个。这是因为大多数架构师社区更可能接受最明显的映射,所以这么做更务实些。
• 集成的范围限于那些最重要的和最有用的元素和概念上。
TOGAF 没有指定任何需求管理方法,所以 SABSA 的业务属性概要(BAP)方法被用来获取需求,这是因为它确定了一套以风险为基础的方法来定义那些基于业务目标的需求。业务驱动和安全服务定义之间的两种方法的可追溯性是通过 SABSA 工件连接所达成,它可以扩展应用到企业在 TOGAF 信息系统服务目录中的所有服务,使其仅用 TOGAF 工件便符合业务需求。维护实体关系的 TOGAF 内容元数据得到增强:
业务属性概要在当前元数据中最适合的位置在动机扩展(Motivation Extension),位于对象“Goal”的所在之处。Goal 有自己一套关系解说,即所谓的驱动(对应于 SABSA 的业务驱动)和“目的”(对应于 SABSA 的控制目的)。
最后,该白皮书细致分析并描述了 SABSA 工件和 TOGAF ADM 各阶段之间的映射,见下图概括:
查看英文原文: Integration of SABSA Security Architecture Approaches with TOGAF ADM
评论