软件开发生命周期 (SDLC) 通常包括四个阶段：

• 需求
• 设计
• 编码
• 测试

SDLC 的第二阶段（设计阶段）的目标是得到系统的总体设计。设计阶段包括两个子阶段：HLD 和详细设计（Detailed-Level Design，DLD）。对于 HLD，您作为安全企业架构师（Security Enterprise Architect，SEA）将对 SOA 安全实现的功能需求和非功能需求进行检查，并设计总体解决方案体系结构。与企业架构师（Enterprise Architect，EA）类似，SEA 负责以下事项：

• 确定公共模式，以便了解系统之间的高级关系，从而能够对旧系统进行变更来创建新系统。
• 获得正确的体系结构，这对于软件系统的设计至关重要。错误的体系结构会带来灾难性的后果。
• 对软件体系结构有详细的了解，将允许团队在设计备选项之间作出明智的决策。
• 提供体系结构表示形式，这对复杂系统的高级属性的分析和描述非常重要。

最基本的观念是，对于任意成功的 SOA 安全实现而言，构造良好的 HLD 非常关键，SEA 对带领 SOA 安全团队进行其创建工作负有最终的责任。

尽管 SOA 安全实现 HLD 非常重要，但 SOA 安全团队并不是总能清楚地确定 HLD 的目标应为什么。在没有专用体系结构资源的情况下，团队成员经常被体系结构概念所淹没，而且不熟悉可帮助其管理整个流程的建模工具。

这里，除了建议的工具外，还提供有用的提示和规则，供 SOA 安全团队成员采用和包含到流程中，以创建成功的 SOA 安全实现 HLD。

在开始编写 HLD 文档之前，SOA 安全团队成员应该记住一些基本的首要规则。实际上 HLD 应该：

• 为关系图或关系图组，注释尽可能少。
• 开始时尽可能简单尽可能抽象。
• 能够被所有涉众理解。
• 满足需求文档中列出的整个安全需求集。
• 使用的关系图数量尽可能少：只有一个关系图最好了，但并非总是可行。
• 包含所有主要对象，但必须对其进行保护，并以通用的方式对其进行表示。
• 包含对象间所有的关键安全关系。
• 用于生成所有安全测试用例。
• 利用面向对象的概念，如封装、继承和多态性。
• 作为生成 DLD 的起点。

您的重点应该放在提供关键问题的答案，如“我们何时开始？”“我们如何继续？”“我们如何知道何时已经完成了？”

SOA 安全团队的 HLD 工作的主要目标是创建可作为沟通工具的文档：文档必须针对整个团队并代表整个团队的立场。在 SOA 团队成员陷入体系结构文档的细节之前，应该将重点放在对其需求进行全面检查上，了解其总体安全目标是什么。HLD 必须清楚地从 SOA 实现的总体安全性的角度说明其设想。

将团队就主要涉众 SOA 安全实现问题达成的协议正式化就是下一步要进行的工作。例如，文档应该包括以下问题：

• 我们需要什么？（安全人员和需求文档）
• 我们要构建什么？（开发人员）
• 我们所投资的是什么？（高层管理）

HLD 还必须提供更为复杂问题的答案，如非功能需求等。这些需求包括系统审核与控制、可扩展性、弹性、垂直伸缩性和水平伸缩性、多站点问题以及第三方工具的集成。

决定何时开始 HLD 工作并不容易。受到广泛认可的行业指导原则是，将能力成熟度模型集成（Capability Maturity Model Integration，CMMI）3-4 级别（请参见）作为实现企业 SOA 安全战略的基础。在开始进行相应的工作前，应该完成很多详细的需求文档。而且，必须同时了解 SOA 安全服务实现的大部分内容。在开始 HLD 前，团队应该已经列出了其需求，了解用于满足这些需求的服务，并将这些服务与相应的需求建立了联系。

在深入开展 HLD 的工作前，团队应该创建其必须加以保护的所有实体的列表。在安全领域中，必须保护的项目称为主体。以下是典型 SOA 系统的高级主体：

• 应用程序或服务
• 硬件
• 消息
• 编排
• 服务组件
• SOA 组件（例如，企业服务总线（Enterprise Service Bus，ESB））
• 用户
• 实用工具

此外，SOA 安全团队应该生成高级图形表示形式，以说明团队成员将如何保护主体之间的交互。 显示主体如何进一步划分为参与者 和资源，其中每个参与者可以为调用资源的功能的人员或计算应用程序，而每个资源则是服务功能、数据、组件或实际效果。主体之间的安全中间层可以进一步分解为执行点、决策点、契约和属性。

由于上面列出的每个主体可能与其他主体交互，因此 中所示的中间层要求为每个交互提供一个这样的关系图。对于具有 中所示的聚合的 SOA 实现，大约可能会有 1000 x 1000 个交互。即需要考虑的（至少在 HLD 中如此）主体间的潜在交互数量为 1,000,000。

SOA 主体	计数
应用程序或服务	50
硬件	50
消息	700
编排	50
服务组件	50
SOA 组件 (ESB)	1
用户	50
实用工具	49
共计	1000

随着对主体间的交互的进一步细分，将出现特定的 SOA 安全服务来专门负责保护这些交互。在开始 SOA HLD 前，团队应该创建将服务与主体关联的表格。 显示了一段需求文本摘录，其中的 identification 服务与所有主体关联。

需求编号	服务	描述
1	Identification	所有主体必须能够唯一进行标识。
2	Identification	安全性必须提供分配给所有指定主体的唯一标识的机制。
3	Identification	安全性必须提供记录何时添加、删除或修改主体的标识。
4	Identification	安全性必须提供用于管理标识的管理接口。

可以通过主体/服务表对此关联关系进行进一步说明，此表在构造 HLD 时非常有用。 所示的就是一个这样的表格。

审核	身份验证	凭据	标识
应用程序或服务			X
硬件			X
消息			X
编排			X
服务组件			X
SOA 组件 (ESB)			X
用户			X
实用工具			X

请注意，此流程不是静态的，而是动态的：收集了足够的需求后，团队就基本上准备好开始初级 HLD 的工作了。随着其他需求的添加，将继续影响 HLD。而且，随着 HLD 的不断充实，在达到稳定状态（一个文档中的更改不会对其他文档造成影响）前，也可能会出现其他意料之外的需求。

首先，团队不应太过于关注一个体系结构概念，因为创建 SOA HLD 的过程可能变化非常大，涉及到很多涉众。因此，最好使用有助于 HLD 设计和 HLD 设计管理流程的工具。SOA 安全团队成员应该熟悉“”之类在线教程。同样，HLD 的目的首先是向 SOA 安全团队进行清楚地说明。然后，应该与 EA 合作，确保文档与企业模型的总体体系结构概念一致。

让我们从 所示的简单关系图开始。

这里的“SOA 安全集合”代表满足所有 SOA 安全需求的所有安全服务。它渗透到整个 SOA 实现中，可以充分满足当前和以后的需求。值得注意的是，此关系图满足前五个规则，即：

• 为关系图或关系图组。
• 开始时尽可能简单尽可能抽象。
• 所有涉众都能够理解。
• 满足需求文档中列出的整个需求集。
• 使用的关系图数量尽可能少。（只有一个关系图最好了，但并非总是可行。）

不过，图 2 并不满足任何其他规则，因此必须对其进行进一步的优化，不过务必注意，这样的关系图比一张白纸可有用得多。

通过在下一个关系图（）中将图 2 作为基础关系图使用，可向您的 SOA 集合添加 SOA 安全服务、主体和主体交互元素。此外，还可包括第三方工具和电子边界之类的元素。除了主体与安全服务的中间层之间的交互外，还要考虑除了 SOA 安全性提供的服务外还提供关键服务的第三方工具和服务。

仔细研究一下这个关系图，会发现此图满足其他规则需求，包括：

• 包含所有主要对象，但必须对其进行保护，并以通用的方式对其进行表示
• 包含对象间所有的关键安全关系
• 利用面向对象的概念，如封装、继承和多态性

保护此实现的所有主要 SOA 安全服务。可以根据需要包括其他服务，但包括超过三个或四个服务并不会得到更多的信息。图 3 也包含所有的主体：通过使用不同的形状，可将其用于以多态的方式表示所有主体交互。

如果假定每个主体的每个边界都是执行点 (EP) 和决策点 (DP)，则已在此关系图中包含了 HLD 所需的所有元素。将不会提供关于这些 EP 或 DP 将如何实现的细节：这些细节将在详细设计部分予以介绍。

以此 HLD 为基础，您可以着手生成 DLD（首要规则第 10 条）。在这种情况下，可以使用与产品无关的统一建模语言（Unified Modeling Language，UML）概念来说明 SOA 安全服务之间的关系，如 中所示。

在 中，根据 HLD 关系图提供了安全服务的详细组件关系图。

创建 SOA 安全 HLD 时，务必从详细需求开始着手。通过使用正确的工具设计和管理流程，并遵循本文中的首要规则，您和 SOA 安全团队可以创建所有人都认为清楚的 HLD，而不会陷入概念的泥潭中。

本系列的下一篇文章（最后一篇）将重点讨论创建用于生成 SOA 安全测试用例的有用概念。为了遵循规则 10，您将使用此 HLD 开始生成测试用例。在此之前，欢迎您提供有用的意见和建议。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-421360/，如需转载，请注明出处，否则将追究法律责任。