任务:确定安全性模式
在系统体系结构的初始设计期间,安全性架构设计师负责确认和选择关键的安全性模式,这些模式将确保系统所需的安全性级别。
用途

通过选择预定义的模式为安全性解决方案的开发提供关键机制。

关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
主要描述

此任务的目标是使架构设计师能够确定适用于体系结构元素的高级别的安全性模式,以满足安全需求和策略。 随后将使用适用于特定技术和平台的详细模式,通过下游设计和实施任务对这些模式进行优化。

关于安全性模式的更多信息,请参阅概念:安全性模式

步骤
确定安全需求

在本步骤中,角色:安全性架构设计师负责为项目及其关键体系结构元素捕获高级别的安全需求。这些需求是在工件:软件体系结构文档工件:补充规范中捕获的,而这些需求会对解决方案的体系结构产生重大影响,因此也应包含在工件:参考体系结构中。安全性架构设计师的角色就是从项目干系人处抽取这些复杂的需求并用易于理解的语句(意图)表达出来。

此阶段特别强调“意图”的原因在于:许多情况下,当您在需求收集会议(请参阅指南:需求研讨会)中征询安全性方面的需求时,大多数项目干系人会回答“当然了,一切都必须安全”,那么这是否意味着所有内容都必须经过加密、审计等,而得到的回答是“ 哦是的,请这样做”。此时安全性架构设计师会解释这个决定所涉及到的成本,复杂性等方面的影响,这时组中的成员才能开始就哪些模式与体系结构中的哪些元素相关进行有意义的讨论。 这些模式就表达了系统在安全性方面的意图,而设计级别模式则表达了实现该意图的机制,最终的实施模式表达了用于实现此意图的技术。

确定信任边界

在任何安全性解决方案中,信任都是一个关键的方面。对安全性的需求基于以下前提:双方共享某一信任级别,而该级别的范围可能是从“完全信任”(因此没有安全性需求)到“完全不信任”(过于偏执的规则)。

  1. 无信任 ... aka 盲目信任:供应商可以提供一个公共服务,而不必信任调用系统。调用系统可以发送没有证明的身份并期望供应商在处理请求时接受此身份。 这种情况下不会采取任何措施防范伪装攻击。
  2. 基于网络配置的信任:没有提供信任的软件配置。可能是通过将网络分成几个具有防火墙的子网对网络进行配置,以此方式来限制可向供应商传送消息的机器数量。 与此关联的机器将只能看到子网中的目标调用系统和供应商系统。 有时也使用 VPN 来限制潜在的调用系统。
  3. 基于基础结构的信任:对基础结构(例如,传输协议 ...可能是 MA SSL 或 SSL + BA)进行配置以识别调用系统,从而验证它是否是可信系统。 除了供应商处理请求时应接受的调用者身份,Web service(SOAP)消息中别无他物。
  4. 基于令牌的信任:点对点令牌信任 - 消息中存在一个声明调用者身份的令牌,经证明它是由可信的调用系统(例如 SAML 或 LTPA)创建的。 第三方令牌信任 - 消息中存在一个声明调用者身份的令牌,经证明它是由可信的第三方系统 KDC/STS(例如 SAML 或 Kerberos)创建的。
  5. 基于令牌环境的信任:包含令牌和消息的签名 - 在由可信调用系统创建的消息中存在一个签名,该签名中包含消息以及声明调用者身份的令牌(用于对调用系统进行认证)。 消息中有两个令牌 - 一个用于认证调用系统是否是可信系统,另一个用于确定调用程序。 需要某种机制将这两个令牌绑定在一起并与消息(例如签名)绑定。
  6. 最大程度的“信任”是认证。任何提供证明的令牌都能够免去为建立信任而需要的额外机制。

信任区域

在大型组织中,比较有效率的做法是将企业细分为多个管理区域并建立不同的信任区域。在不同的区域之间,可建立各种信任关系子类型。以下是双方建立信任关系的几种方法(只有一方与最终用户有关系)。

  • 直接信任 - 令牌交换:信任域 1 对最终用户进行认证,信任域 2 需要身份或标识(身份传播)。 某些情况下(例如只需个性化)可能不需要认证。
  • 直接信任 - 令牌验证:信任域 1 可以创建一个提供其自己证明的新声明(身份声明),此证明可以认证已识别用户。 信任域 2,评估此声明是否来自于信任方(信任域 1)并用它替代认证用户本身。
  • 令牌服务和 ISP:有时信任关系是在多方之间建立的,对用户的认证分离为单独的服务(身份服务供应商)。 这些身份服务供应商具有不同程度的功能。有些可以查看请求的目标并确定该用户是否已通过认证,并了解当前令牌是否需要与第二个令牌交换,并可以将此请求重定向到适当的某方。
  • 间接信任:有时各方之间没有直接的信任关系,但它们都信任某个第三方,从而通过该第三方来“代理”交换。
  • 授权:可建立直接信任关系和间接信任关系的组合。
确定高级别的安全性模式

本任务中确定的高级别安全性模式如下。受安全需求影响的系统体系结构元素(安全性同时影响软件元素和硬件元素)现在可以与一个或多个模式(首选工件:软件体系结构文档中记录的模式)关联,这样就可以在设计期间的活动中对它们进行优化。

身份和认证

最终用户具有一个标识(用户名)和/或一组标识(标题、角色和别名)以及证明(密码),它们可能存放在膝上型计算机或 PDA 等客户机系统上的某个位置。 为了进行认证,当提示用户向应用程序确认自身时,他应向该应用程序出示标识和证明。 如果应用程序验证了标识和证明,则用户就成功地“通过认证”,且身份立即变为“已认证身份”。 如果应用程序实施了业务逻辑并强制使用其自己的安全性策略,它需要将其数据/ 元数据存储在身份数据/元数据存储库(文件系统,数据库等)中。 随着 Web 的出现,最终用户不再仅在自己的系统上存储应用程序客户机代码,而是经常通过浏览器来访问应用程序,而网络会通过最终用户提供的 URI(统一资源标识符)找到应用程序。

单点登录

当用户具有多个应用程序,且这些应用程序分别具有不同的标识和证明时,有时候很难对身份数据和元数据进行管理以作出正确的决策。 单点登录(SSO)是适用于各种技术(人工或自动)的术语,它用于降低复杂度。

SSO 解决方案可以基于客户机或服务器/服务,并且可以与应用程序进行紧耦合或松耦合。 基于 Web 的 SSO 涉及基于浏览器的解决方案,通常包含 Cookie。 在基于客户机的紧耦合 SSO 中,用户的责任是对保留在多个应用程序存储库中的多个标识/密码进行注册和同步。 有些 SSO 依赖于“身份映射”,有些则提供“身份传播”或“身份声明”。 联合 SSO 中的新启动计划允许用户向第三方身份服务供应商注册,随后由该第三方来管理用户信息,因此提供了一种松耦合方式。在企业中,后端 SSO 可包含用作 ISP 的企业。后端 SSO 包含用于所有应用程序的公用存储库,且每个应用程序/服务器都重新配置为不使用本地存储库。 后端 SSO 还可以为用户信息保留多个存储库,并利用管理进程强制对多个存储库中的身份数据进行同步。 当涉及多个身份时,通常需要将应用程序划分为多个域,这些域通常与管理域关联。

数字身份

随着人们和企业越来越依赖于计算机技术,创建的与身份相关的信息大量增加。 由于意识到身份盗用问题,政府正在立法以对作为身份信息保管者的企业提出保护这些信息方面的要求。

数字身份解决方案 - 有两大策略用于管理数字身份。一种是“以用户为中心”,即依靠用户主动地参与身份保护,方法是向第三方供应商注册,然后向他们信任的供应商授予访问其身份数据和元数据的许可权。Liberty Alliance 是引领此策略的组织,但还有一个与 The Apache Foundation 合作 Higgins 启动计划正致力于开放式源代码工作。

第二种是以企业为中心的模型,在此模型中,由企业为其客户、合作伙伴以及员工提供身份管理服务。 每种方法所使用的底层技术是相同的,但提供数字身份管理的监管和职责有所不同。 企业所处理的信息量与个人不同,因此具有不同的伸缩需求。 企业还需要具有自己的系统,以便根据企业角色管理用户访问以及更改企业情况(即您始终是“我自己”,但您不一定始终在同一家公司工作。)

权限

随着人们和企业越来越依赖计算机技术,谁能访问什么资源已编写为规则。 设计应用程序时,谁能访问什么信息的决定可能取决于业务环境信息,或可将其外部化为应用程序并由单独的中间件来处理。 大多数产品和计算机系统都实施了一组“访问控制”机制,但通常都将自己的已授权用户名与资源名称相映射,这称为“访问控制表”。

消息保护

有两种基本保护类型:完整性保护(证明消息在传输过程中未经更改)和机密性(应用密码术来确保只有经过授权的接收方才能够看到此消息)。 当消息通过协议发送时,可对每条消息进行数字签署或加密,或者网络协议可以签署/加密两个入口点之间的所有流量。 当协议提供此保护时,即通常所说的“点对点”(即网络端点到网络端点)。

属性
先行作业
多次出现
事件驱动
正在进行
可选
已计划
可重复
关键注意事项
本任务中所确定的安全性模式都是高级别的,且与特定的技术或平台没有依赖关系;但每个模式都需要由任意数量的特定于技术或平台的模式支持。 对于由项目选择的技术和平台,这些详细模式的定义必须提供给实施者。
更多信息
概念