在分布式环境中使用 DCE 安全性框架的安全考虑因素

5Seven

简介

安全理念起源于我们自己的本地操作系统（OS）环境。未联网的隔离机器比联网的机器更加安全。在网络中，没有公共的控制点来监管或控制网络资源（计算机或用户）。对操作系统的保护止于网络。人们所能看到的只是通过网络传输的一系列数据包。这使假冒的用户很容易模仿合法用户。如果未采用安全措施，那么将难以区分虚假的和真实的消息。

只有在确立了发送消息的用户的真实性之后，才能够实施安全措施。一般的安全措施首先会验证用户，通常使用用户名和密码进行验证。密码是确立用户真实性的实体。用户名可以让多个人知道，而密码只能让具有合法授权的人知道。

分布式环境安全机制会实现一种高级且复杂的安全模型，如 图 1 所示。所有安全活动都集中在安全服务器上。安全服务器对网络执行的任务与操作系统对本地系统执行的任务相同。

快速了解 DCE 安全模型

在 DCE 中，安全服务器是中央控制点，控制网络上的安全活动。安全服务器后台程序使用 MIT Kerberos 来管理身份验证。在 DCE 中使用此身份验证服务，RPC 能够向用户提供数据可用性保证和数据隐私保障。所有客户端/服务器都依赖安全服务器对在网络上传输的消息进行身份验证和授权。DCE 还可以验证安全服务器本身。

首先，用户必须登录到 DCE，以使用 DCE 提供的服务。这个登录过程通过安全服务器来进行。用户向安全服务器提供一个秘密密钥（密码）来证明其身份。此秘密密钥只有该用户和安全服务器知道。一旦安全服务器通过秘密密钥确认了用户的身份，用户登录到 DCE 的过程就完成了。这是一种一次性过程，在用户本身从 DCE 注销之前不必重复执行。此过程也称为单点登录。在这之后，只要用户希望访问任何 DCE 服务，它就会向安全服务器获取一个安全证书。此证书用作用户向网络中任何机器证明其真实性的凭证。用户然后将凭证传送给承载用户所需 DCE 服务的服务器。该服务器接收调用并检查证书，然后判断用户是否被授权使用此服务。如果是，则接受调用并处理请求。否则，决绝请求。

图 1. 基本 DCE 安全模型

分布式安全机制中常用的术语

下面是本文将经常提到的一些术语：

身份验证：确认用户身份的过程。身份验证用于验证用户对其身份的声明。最容易理解的示例就是登录过程。验证用户名和密码是一项身份验证操作。

授权：一旦用户经过了身份验证，就会检查它可以使用哪些资源和服务。这就是授权。

完整性：只有授权用户有权通过网络修改消息/数据。一旦用户创建了消息，消息就不应在传送到目的地的途中被修改。对消息的这种更改检查称为完整性检查。

签名：当用户通过网络发送消息时，它会对消息进行签名。这种签名是验证合法用户是否是此消息的作者的一种方式。

密钥：密钥是一种在明文与密文之间相互转换的方式。在数学上，它是一个参数，用于确定一个算法的函数输出。

加密：这个过程将消息转换为一种形式（密文），如果没有用于将消息转换为密文的密钥，几乎不可能将密文转换为原始消息。这种方法广泛用于阻止通过网络对数据进行未授权访问。

单元：单元指的是一组用户、客户端或服务器，它们共享相同的 DCE 服务。

主体：主体可以表示从用户、客户端和服务器到单元的任何实体。

访问控制列表（ACL）：ACL 是一种数据结构，它将一个服务的权限列表与一组主体相关联。它描述可访问和使用服务的主体集和允许的访问类型。

身份验证 RPC（Authenticated RPC）：在 DCE 中，只有在确认了调用客户端和被调用服务器的身份之后，RPC 调用才会成功。这种保证由身份验证 RPC 通过向在服务器和客户端之间交换的消息/数据包添加额外的字段来实现。

一般的分布式安全技术

本节将非常简洁地介绍分布式环境中使用的两种最重要的安全技术。

• 秘密密钥加密
• 公开密钥加密
  

尽管 DCE 目前基于秘密密钥系统，但在本文后面将介绍 DCE 如何利用并扩展这些技术，以提供一种更为安全的环境。

秘密密钥加密

秘密密钥加密是分布式系统安全机制中一种最重要的技术。它涉及使用在服务器和客户端之间共享的秘密密钥。使用同一个秘密密钥加密和解密在它们之间交换的消息。由于对加密/解密使用了相同密钥，所以这种技术也称为对称加密。

公开密钥加密

公开密钥加密使用一对密钥：一个用于加密，一个用于解密。因为涉及到一对密钥，所以它也称为非对称加密。用户拥有一对密钥：公钥和私钥。所有人都知道公钥，而私钥是秘密的。要发送给用户的消息使用他/她的公钥加密。这些消息只能使用对应的私钥解密。Rivest-Shamir-Adleman (RSA) 系统是这种技术的最好例子。

什么是 Kerberos？

最初，Kerberos 是麻省理工学院在 Athena 项目中开发的一种身份验证服务。Kerberos 是根据秘密密钥加密并使用可信第三方身份验证而设计的。网络中的所有客户端/服务器都依赖一个称为密钥分发中心（KDC）的第三方进行安全通信。KDC 负责密钥分发和可能在网络上发生的所有身份验证过程。

Kerberos 在本质上包含一个称为 Kerberos 身份验证协议（KAP）的复杂过程。当两方希望对彼此进行身份验证时，它们执行 KAP 来完成。此协议实际上包含一系列消息，其中包含秘密密钥以及有助于客户端和服务器安全地相互验证的其他信息。KAP 涉及三方：客户端、服务器和 KDC。图 2 以一种图示方式演示了 KAP 的工作原理：

图 2. Kerberos 身份验证协议（KAP）

对图 2 作如下说明：

• 客户端首先向 KDC 发送一条消息，请求一个新的票证。这将指定客户端以及它希望连接到的服务器的身份。KDC 通过生成一个随机会话密钥（K.session）创建一个票证，这个票证包含客户端的身份和其他一些有用信息。
• KDC 然后加密票证并将加密结果发送给客户端。
• 客户端接收 KDC 的回复，然后使用自己的秘密密钥解密消息。客户端保留会话密钥，将票证按原样转发给服务器。
• 服务器从客户端接收票证，然后使用自己的秘密密钥进行解密。这样，服务器将得到客户端的身份和会话密钥。
  

上述协议是最基本的 KAP 和它在 DCE 身份验证机制中的实际实现。票证包含客户端/服务器相互信任所必需的所有信息。

在此身份验证信息交换过程中生成的会话密钥可用于客户端/服务器与 KDC 之间的所有未来通信。它可用于验证消息、提供完整性检查，以及提供加密密钥来保证数据的机密性。尽管使用了非常有效且易于管理的可信第三方，但 Kerberos 也存在一些不足。在 Kerberos 中，KDC 是整个网络的单一故障点。

DCE 如何扩展 Kerberos

DCE 有效地实现了三种网络服务，它们是：

• 身份验证服务
• 特权服务
• 注册表服务
  

身份验证服务与 Kerberos 中的 KDC 相同。另两种服务是对 Kerberos 的扩展和增强。将这三种服务相结合，DCE 在分布式环境中实现了一种非常有效的安全机制。在了解每个服务的详细信息之前，您应该记住，所有这些服务都是由一个 RPC 服务器实现的，该服务器称为安全后台程序或 secd。

身份验证服务

DCE 身份验证服务是 Kerberos 模型中的密钥分发服务。它提供了票证和会话密钥。但身份验证服务在 Kerberos 中只是密钥分发服务的一个组成部分。DCE 通过两种类型的票证服务强化了这一服务。

• 服务票证 （Service ticket，STkt）
• 票证授权票证（Ticket-granting ticket，TGT）
  

票证是一条加密消息，包含一个会话密钥和一些其他的服务器/客户端标识信息。

服务票证（STkt）

在 DCE 中，服务票证是一种数据结构，身份验证服务使用该结构将客户端身份和会话密钥传递给服务器。客户端必须获得 STkt 来对服务器进行身份验证。它之所以称为服务票证，是因为客户端使用它来获取服务。

服务票证对服务器进行身份验证，包含两部分，如图 3 所示。第一部分是目标服务器的主体名称。票证的第二部分对客户端不可见。它使用目标服务器的秘密密钥进行了加密。STkt 的加密部分包含客户端的名称、身份验证服务生成的一个可供客户端和服务器使用的会话密钥，以及 STkt 的有效期。

图 3. 服务票证的结构

票证授权票证 (TGT)

在 DCE 中，TGT 用于获取服务票证 (STkt)。TGT 包含供在客户端与身份验证服务之间使用的会话密钥。基本上，TGT 包含两部分，如图 4 所示。第一部分包含身份验证服务及服务器，第二部分是加密的，包含票证有效期和 TGT 会话密钥。TGT 会话密钥是 TGT 最重要的部分。这个密钥由身份验证服务生成，由客户端和身份验证服务共同用于所有未来通信。

TGT 还提供了一个位置，供身份验证服务存储它在以后响应此客户端的 STkt 请求所需的所有信息。

图 4. 票证授权票证的结构

身份验证服务工作模型 - 使用 TGT 和 STkt

图 5 演示了在 DCE 身份验证服务中如何使用 TGT 和 STkt。

获得包含供与身份验证服务器一同使用的会话密钥的 TGT

客户端需要使用在其本身与身份验证服务之间共享的会话密钥来与身份验证服务进行未来的通信。为了获得共享的会话密钥，客户端向身份验证服务发出一个 TGT 请求（身份验证 RPC）。客户端请求消息主要包括客户端主体名称、期望的票证有效期。

身份验证服务创建一个 TGT。该 TGT 包含客户端的身份、一个随机生成的 TGT 会话密钥和 TGT 的有效期。整个 TGT 使用身份验证服务的秘密密钥加密。身份验证服务向客户端发出一条响应消息，其中包含 TGT、TGT 会话密钥的一个副本和其他信息。为了传送到期望的客户端，此响应消息使用客户端秘密密钥进行加密。

客户端使用它的秘密密钥解密来自身份验证服务的消息。现在，客户端拥有了会话密钥，它可以使用该密钥向身份验证服务验证自身。

图 5. 身份验证服务工作模型

获取包含与安全服务器一起使用的会话密钥的 STkt

STkt 请求的主要目标是获得一个新会话密钥，供客户端与安全服务器一起使用。客户端通过身份验证 RPC 向身份验证服务发出一个 STkt 请求，以获取供客户端与任何服务器通信所用的新会话密钥。此消息包含目标服务器名称和 TGT。此消息的完整性通过一个校验和来保护，该校验和使用客户端与身份验证服务器之间的会话密钥进行加密。

身份验证服务从请求中提取出 TGT，使用自己的秘密密钥解密它，然后验证请求。检查了请求客户端的身份后，身份验证服务构造一个 STkt，供客户端用来验证目标服务器。STkt 响应消息包含在客户端与目标服务器之间使用的会话密钥，还包含客户端的身份。STkt 然后使用目标服务器的秘密密钥加密，这样目标服务器就能够使用自己的秘密密钥解密 STkt 请求。身份验证服务然后使用 TGT 会话密钥加密 STkt 和会话密钥的副本，再将消息发回给客户端。

客户端已经拥有从前面的 TGT 请求获得 TGT 会话密钥。所以客户端使用这个 TGT 会话密钥副本解密消息。最终，客户端从 STkt 获得与目标服务器一同使用的共享会话密钥。

客户端使用会话密钥与服务器通信

客户端向服务器发出 RPC 调用，并将包含会话密钥的 STkt 作为 RPC 协议的一部分传递给服务器。服务器 RPC 运行时验证 STkt。如果它是来自客户端的有效请求，它使用服务器秘密密钥从 STkt 提取会话密钥。在这里，客户端已经过了身份验证，服务器知道用于与这个特定客户端通信的共享会话密钥。

接下来，客户端收到来自服务器的调用结果。客户端使用共享会话密钥解密该结果。现在，客户端和服务器都有了共享会话密钥的副本。使用此会话密钥，客户端和服务器可以安全地相互通信。

特权服务（授权服务）

身份验证服务的总体目标是，与客户端希望向其进行身份验证的服务器安全地交换客户端身份和会话密钥。在这里，DCE 的特权服务通过加入特权属性证书（PAC），增强了身份验证服务。DCE 安全服务使用 PAC 来描述客户端的安全属性。这些安全属性包括主体身份和组信息。在 DCE 特权服务中，服务器借助从 PAC 获得的信息，判断给定客户端是否有权执行特定操作。通常 PAC 包含制定访问控制决策所需的授权信息。

PAC 的组成部分

• 身份验证标志：此标志显示此 PAC 是否经过了 DCE 安全机制的身份验证。
• DCE 单元 UUID：一个单元的 UUID，主体在该单元中的注册表中注册。
• 主体 UUID：一个主体的 UUID，PAC 中描述了该主体的安全属性。
• 主要组 UUID：同一单元中此主体主要属于的组的 UUID。
• 辅助组 UUID：同一单元中此主体所属的所有组的 UUID。
• 外来组 UUID：此主体所属的、在远程调用中注册的组的 UUID。
  

特权服务使用 PTGT 和 PSTkt 来交换 PAC。简言之，PTGT 和 PSTkt 分别是 TGT 和 STkt，它们包含 PAC。图 6 展示了 PTGT 和 PSTkt 的结构。从图中很容易看出，PTGT 类似于 TGT，而 PSTkt 类似于 STkt。但是它们之间存在两个重大区别：

• 特权票证还包含一个客户端 PAC；
• 特权票证将特权服务指定为客户端，而 TGT 和 STkt 指定了真实的客户端。
  

图 6. PTGT 和 PSTkt 的结构

下一节通过图 7 介绍 DCE 中的特权服务的工作原理。

获得 PTGT

客户端首先将一个 TGT 发送给授权服务，授权服务然后向客户端提供一个 STkt 和一个会话密钥。STkt 和会话密钥供客户端用来与特权服务通信。客户端将一个 PTGT 请求发送给特权服务，其中包含 STkt 和会话密钥。

特权服务解密请求，获得会话密钥，并确认客户端的身份。特权服务然后生成一个新的会话密钥，也就是 PTGT 会话密钥。同时，特权服务在从注册表服务获得此客户端的所有信息之后，生成 PAC。现在，特权服务将此信息复制到 TGT 中，并使用身份验证服务的秘密密钥加密它。这个 TGT 是一个 PTGT，因为它包含特权信息。特权服务现在将请求发送回客户端。此请求消息使用客户端传递给特权服务的会话密钥进行加密。

客户端获得响应消息，解密它，然后获得 PTGT 和 PTGT 会话密钥。

获得 PSTkt

客户端现在拥有了从身份验证服务获得 PSTkt 所需的一切，以及 PTGT 和 PTGT 会话密钥。客户端将一个 PSTkt 请求发送到身份验证服务。此请求消息包含服务器（客户端希望从该服务器获得服务）名称和一个客户端 PTGT 副本。

身份验证服务获取 PSTkt 请求，使用其秘密密钥解密它。在确认了 PSTkt 请求中的相关字段之后，身份验证服务继续生成一个 STkt。它将 PTGT 中的 PAC 复制到 STkt 中，将客户端设置为特权服务并生成一个新会话密钥。目标服务器将使用此会话密钥来确认客户端的身份。因为此 STkt 包含 PAC，所以它也是 PSTkt。而且此 PSTkt 使用目标服务器的秘密密钥进行了加密。身份验证服务构造一条响应消息，其中包含 PSTkt 和新会话密钥的一个副本。整条消息使用 PTGT 会话密钥加密并发送回客户端。

客户端收到响应消息，解密它，获得 PSTkt 和与目标服务器一同使用的会话密钥。

图 7. 特权服务工作模型 - 使用 PTGT 和 PSTkt

使用 PSTkt

客户端现在向目标服务器发出一个 RPC 调用，向它发送包含会话密钥和 PAC 的 PSTkt。目标服务器接收 PSTkt 并使用自己的秘密密钥解密。为了保证 PAC 确实是由特权服务发出的，目标服务器检查并确认在 PSTkt 中指定的客户端确实是特权服务。最后，服务器执行 RPC 调用，将结果返回到客户端。

注册表服务

注册表服务是 DCE 安全机制所提供的第三种网络服务。注册表服务为一个单元的所有主体、组和帐户信息维护一个数据库。此信息供前两个服务（身份验证服务和特权服务）和 DCE API 使用。它主要包含以下信息：

• 单元信息：包含单元名称、单元 UUID、运行的注册表服务的版本和注册表可以分配给主体的 UNIX® ID 的范围。它还存储了单元的整体信息，比如单元范围的安全策略、票证有效期等。
• 主体、组和组织信息：包含单元的所有主体、组和组织（PGO）的列表。对于每个 PGO 条目，还存储了相应的 UUID、名称和 UNIX ID。
• 帐户信息：DCE 帐户就像操作系统上任何其他本地帐户一样。用户必须登录到 DCE 帐户才能使用 DCE 提供的服务。每个帐户表示一个主体和该主体所属的组列表。帐户信息包含两部分：网络和本地系统。网络部分包含获取票证和其他服务所需的信息（比如，它包含主体秘密密钥）。本地部分包含主目录和要运行的 shell 等信息。它还负责支持网络范围的单点登录，这意味着登录到 DCE 帐户也会自动将用户登录到所有相关联的本地帐户。
  

DCE 安全性与 Kerberos 有何不同

从前面的细节可以看到，DCE 实现的身份验证服务非常类似于 Kerberos 协议中所遵循的过程。这种相似性源于这样一个事实：DCE 身份验证服务建立在 Kerberos V5 的源代码之上。尽管 DCE 安全机制是对 Kerberos V5 的扩展，但它在许多方面不同于 Kerberos。最明显的不同就是特权服务和注册表服务，它们只有 DCE 才有。此外，一些 DCE 工具，比如身份验证 RPC 和 DCE、ACL，也不是由 Kerberos 提供的。而且，除了 UDP/IP 以外，DCE 身份验证服务还使用 DCE RPC 在网络上进行通信。这与 Kerberos 仅使用 UDP 协议进行通信的事实形成了鲜明对比。

结束语

本文主要介绍了分布式系统安全性的背景知识。我们首先强调了安全性对分布式环境的重要性，概述了 DCE 安全模型。然后详细介绍了分布式安全领域所使用的一般技术，以及 Kerberos。最后，本文详细解释了 DCE 安全机制的工作原理和实现，简略提及了它与 Kerberos 的不同。本文可以作为更深入理解使用 DCE 的分布式安全机制的起点。

作者简介

Avadh N. Pandey 自 2008 年开始担任 IBM DCE 和 TXSeries 的三级支持工程师。他于 2007 年毕业于 Indian Institute of Technology, Roorkee。他关注的领域包括 UNIX 系统和网络。

Jithesh Moothoor 自 2006 年开始担任 IBM DCE 和 TXSeries 产品的三级支持工程师。他关注的领域包括高性能计算、云计算和 UNIX 系统。您可以在 大学内的云计算解决方案 上看到他的一篇文章。

http://www.ibm.com/developerworks/cn/aix/library/au-aixsecuritydce/index.html