爱生活，爱IT
全部博文（436）
分类： 系统运维
2006-01-26 13:59:47
4.3身份和信任管理
4.3.1 身份认证综述
伴随着开放式网络系统的飞速发展,比如银行结算系统等关系国计民生的大型网络系统的普遍应用,认证用户身份和保证用户使用时的安全,正日益受到各方面的挑战。在不与网络连接的个人计算机中,资源和个人信息可以通过物理保护来实现。在分时计算环境中,操作系统管理所有资源,并保护用户信息不被其他未授权的用户使用。这时操作系统需要认证每一个用户,以保证每个用户的权限,操作系统在用户登录时完成这项工作。然而，在网络系统中,用户需要从多台计算机得到服务,控制访问的方法主要有以下三种方法:
a)服务程序不进行认证工作,而由用户登录的计算机来管理用户的认证来保证正确的访问。在封闭式网络中,网络中的所有计算机以及他们之间的通信都在严格的控制之下,此时这个方法是一个可供选择的方案。
b)收到服务请求时,对发来请求的主机进行认证,对每台认证过的主机的用户不进行认证。半开放系统可以采用这个方法,每个服务选择自己信任的计算机,在认证时检查主机地址来实现认证,这种方法应用于rlogin和rsh等一些可以远程执行的程序中。
c)对每一个服务请求,都要认证用户的身份。在开放式系统中,主机并不能控制登录它的每一个用户,而且还有来自系统外部的假冒等情况发生,以上a、b两种方法都不能保证用户身份的真实性,只有使用方法c。
开放式系统的认证有以下几种需求:
安全性:认证机制必须足够安全,不致成为攻击的薄弱环节。
可靠性:认证服务是其他服务的基础,它的可靠性决定整个系统的可靠性。
透明性:用户应该感受不到认证服务的存在。
可扩展性:当和不支持认证机制的系统通信时,应该保持一切不受影响。
一般而言，认证的机制分为两类：简单认证机制和强认证机制。简单的认证中只有名字和口令被服务系统校验。由于明文的密码在网上传输极容易被窃听截取，一般的解决办法是使用一次性口令（OTP，One-Time Password）机制。这种机制的最大优势是无须在网上传输用户的真实口令，并且由于具有一次性的特点，可以有效防止重放攻击（Replay Attack）。根据一次性口令生成机制的不同，通常OTP可分为：时间同步的安全标志符，Challenge-Response的Crypto Card（密码卡）和增强的S/Key（安全密钥）等。RADIUS协议就是属于这种类型的认证协议；强认证机制一般将运用多种加密手段来保护认证过程中相互交换的信息，其中，Kerberos协议是此类认证协议中比较完善、较具优势的协议，得到了广泛的应用。
下面讨论几种常用的身份认证机制，并对它们的安全性进行分析。
4.3.2 RADIUS认证机制
RADIUS（Remote Authentication Dial In User Service）协议最初是由Livingston公司提出的，原先的目的是为拨号用户进行认证和计费。后来经过多次改进，形成了一项通用的认证计费协议。RADIUS认证要用到基于挑战/应答（Challenge/Response）的认证方式。
RADIUS是一种C/S结构的协议，它的客户端最初就是NAS（Net Access Server）服务器，现在任何运行RADIUS客户端软件的计算机都可以成为RADIUS的客户端。RADIUS协议认证机制灵活，可以采用PAP、CHAP或者Unix登录认证等多种方式。RADIUS是一种可扩展的协议，它进行的全部工作都是基于Attribute-Length-Value的向量进行的。
RADIUS的基本工作原理是用户接入NAS，NAS向RADIUS服务器使用Access-Require数据包提交用户信息，包括用户名、密码等相关信息，其中用户密码是经过MD5加密的，双方使用共享密钥，这个密钥不经过网络传播；RADIUS服务器对用户名和密码的合法性进行检验，必要时可以提出一个Challenge，要求进一步对用户认证，也可以对NAS进行类似的认证；如果合法，给NAS返回Access-Accept数据包，允许用户进行下一步工作，否则返回Access-Reject数据包，拒绝用户访问；如果允许访问，NAS向RADIUS服务器提出计费请求Account-Require，RADIUS服务器响应Account-Accept，对用户的计费开始，同时用户可以进行自己的相关操作。
RADIUS服务器和NAS服务器通过UDP协议进行通信，RADIUS服务器的1812端口负责认证，1813端口负责计费工作。采用UDP的基本考虑是因为NAS和RADIUS服务器大多在同一个局域网中，使用UDP更加快捷方便。
RADIUS协议还规定了重传机制。如果NAS向某个RADIUS服务器提交请求没有收到返回信息，那么可以要求备份RADIUS服务器重传。由于有多个备份RADIUS服务器，因此NAS进行重传的时候，可以采用轮询的方法。如果备份RADIUS服务器的密钥和以前RADIUS服务器的密钥不同，则需要重新进行认证。
RADIUS协议应用范围很广，包括普通电话、上网业务计费，对VPN的支持可以使不同的拨入服务器的用户具有不同权限。
4.3.3基于DCE/Kerberos的认证机制
DCE/Kerberos是一种被证明为非常安全的双向身份认证技术。DCE/Kerberos的身份认证强调了客户机对服务器的认证；而其它产品，只解决了服务器对客户机的认证。
Kerberos一种为网络通信提供可信第三方服务的面向开放系统的认证机制。
每当用户(client)申请得到某服务程序(server)的服务时,用户和服务程序会首先向Kerberos要求认证对方的身份,认证建立在用户(client)和服务程序(server)对Kerberos的信任的基础上。 在申请认证时,client和server都可看成是Kerberos认证服务的用户,为了和其它服务的用户区别,Kerberos用户统称为principle, principle既可以是用户也可以是某项服务。认证双方与Kerberos的关系用下图表示:
当用户登录到工作站时,Kerberos对用户进行初始认证,通过认证的用户可以在整个登录时间得到相应的服务。Kerberos既不依赖用户登录的终端,也不依赖用户所请求的服务的安全机制,它本身提供了认证服务器来完成用户的认证工作。时间戳(代表时间的大数字)技术被应用于后来的Kerberos中来防止重放攻击。
Kerberos保存principle及其密钥的数据库。私有密钥(private key)只被Kerberos和拥有它的principle知道,在用户或服务登记时和Kerberos协议生成。使用私有密钥,Kerberos可以创建消息使一个principle相信另一个principle的真实性,进行认证工作。Kerberos还产生一种临时密钥,称作对话密钥(session key),通信双方用在具体的通信中。
Kerberos提供三种安全等级。
只在网络开始连接时进行认证,认为连接建立起来后的通信是可靠的。认证式网络文件系统(Authenticated network file system) 使用此种安全等级。
安全消息(sage messages)传递:对每次消息都进行认证工作,但是不保证每条消息不被泄露。
私有消息(private messages)传递:不仅对每条消息进行认证,而且对每条消息进行加密。Kerberos在发送密码时就采用私有消息模式。
基于DCE/Kerberos和公共密钥的用户身份认证是非常安全的用户认证形式，但是，它们实现起来比较复杂，要求通信的次数
多，而且计算量较大。
四、基于公共密钥的认证机制
目前在Internet上也使用基于公共密钥的安全策略进行身份认证，具体而言，使用符合X。509的身份证明。PKI是通过使用公开密钥技术和数字证书来确保系统信息安全并负责验证数字证书持有者身份的一种体系。例如，某企业可以建立公钥基础设施（PKI）体系来控制对其计算机网络的访问。在将来，企业还可以通过公钥基础设施（PKI）系统来完成对进入企业大门和建筑物的提货系统的访问控制。
PKI让个人或企业安全地从事其商业行为。企业员工可以在互联网上安全地发送电子邮件而不必担心其发送的信息被非法的第三方（竞争对手等）截获。企业可以建立其内部Web站点，只对其信任的客户发送信息。
在电子交易中，无论是数字时间戳服务(DTS)还是数字证书(Digital ID)的发放，都不是靠交易的自己能完成的，而需要有一个具有权威性和公正性的第三方(third party)来完成。认证中心(Certificate Authority)就是承担网上安全电子交易认证服务、能签发数字证书、并能确认用户身份的服务机构。认证中心通常是企业性的服务机构，主要任务是受理数字凭证的申请、签发及对数字凭证的管理。认证中心依据认证操作规定(Certification Practice Statement)来实施服务操作。
1 ）认证系统的基本原理
利用RSA公开密钥算法在密钥自动管理、数字签名、身份识别等方面的特性，可建立一个为用户的公开密钥提供担保的可信的第三方认证系统。这个可信的第三方认证系统也称为CA，CA为用户发放电子证书，用户之间（比如网银服务器和某客户之间）利用证书来保证信息安全性和双方身份的合法性。
2 ）认证系统结构
整个系统是一个大的网络环境，系统从功能上基本可以划分为CA、RA和Web Publisher。
核心系统根CA放在一个单独的封闭空间中，为了保证运行的绝对安全，其人员及制度都有严格的规定，并且系统设计为一离线网络。CA的功能是在收到来自RA的证书请求时，颁发证书。一般的个人证书发放过程都是自动进行，无须人工干预。
证书的登记机构Register Authority，简称RA，分散在各个网上银行的地区中心。RA与网银中心有机结合，接受客户申请，并审批申请，把证书正式请求通过建设银行企业内部网发送给CA中心。RA与CA双方的通信报文也通过RSA进行加密，确保安全。系统的分布式结构适于新业务网点的开设，具有较好的扩充性。通信协议为TCP/IP。
证书的公布系统Web Publisher，简称WP，置于Internet网上，是普通用户和CA直接交流的界面。对用户来讲它相当于一个在线的证书数据库。用户的证书由CA颁发之后，CA用E－mail通知用户，然后用户须用浏览器从这里下载证书。
证书链服务（有时也称"交叉认证"）是一个CA扩展其信任范围或被认可范围的一种实现机制。如果企业或机构已经建立了自己的CA系统，通过第三方认证中心对该机构或企业的CA签发CA证书，能够使得该企业或机构的CA发放的证书被所有信任第三方认证中心的浏览器、邮件客户所信任。
在一般的实现机制中，常将基于公共密钥的SSL策略集成在一起，多用在Web应用方面。认证服务器通过公共密钥管理服务器（PKMS）与SSL连接起来。PKMS实际是身份认证网关和建立基于SSL的加密通道，客户端不必使用客户端软件，可使用SSL浏览器登录到PKMS，PKMS将用户的身份映射成系统用户身份并且通过RPC进行传输，也就是将SSL的用户标识传递给认证服务器。PKMS是用来与Internet用户之间临时建立起相互信任的安全会话过程，然后将Internet用户身份映射到系统访问控制机制可以管理的用户身份。
基于公共密钥的认证过程：
在PKMS和使用支持SSL、S-HTTP的浏览器用户之间的身份验证是建立在公开密钥加密数字签名和授权证明之上的。数字签名工作如下：
一旦两个用户互相验证了身份，他们就可以交换用来加密数据的密钥（如DES加密密钥）。（公开密钥加密方法对于大量的数据加密来说速度太慢）。浏览器应该能够在类似的交换过程使用它的公开/秘密密钥组合对来验证它的身份。但是目前还没有出现支持浏览器身份验证的产品。
为了利用数字签名，接收方必须拥有发送方的公开密钥。公开密钥是通过授权证明（Certificates of Authority, CA）来发布的。PKMS把它的经公开密钥加密的CA发送给浏览器。（多数公钥产品只使用了服务器方的身份验证，所以在CA中只需要包含PKMS的公开密钥）这些授权证明是由可信赖的第三方生成的并且经过可信赖的第三方用秘密密钥"数字签名"的。
用户的浏览器（或者其他客户方的程序）要接收由受信赖的第三方签发的正确的CA就必须要配置受信赖的第三方的公开密钥。（浏览器用户使用配置好受信赖的第三方公开密钥的浏览器，来验证CA中的受信赖的第三方的数字签名）。如果该浏览器没有配置受信赖的第三方的公开密钥，它就无法验证安全网关的身份。一些浏览器预先配置有受信赖的第三方公开密钥，并且用户不能增加其他的签发CA的受信赖的第三方。这限制了将无关公司推出的浏览器的用户与公司拥有的服务器之间建立相互信任关系的能力。
五、基于挑战/应答的认证机制
顾名思义，基于挑战/应答（Challenge/Response）方式的身份认证机制就是每次认证时认证服务器端都给客户端发送一个不同的"挑战"字串，客户端程序收到这个"挑战"字串后，做出相应的"应答"。
认证过程为：
1) 客户向认证服务器发出请求，要求进行身份认证；
2) 认证服务器从用户数据库中查询用户是否是合法的用户，若不是，则不做进一步处理；
3) 认证服务器内部产生一个随机数，作为"提问"，发送给客户；
4) 客户将用户名字和随机数合并，使用单向Hash函数（例如MD5算法）生成一个字节串作为应答；
5) 认证服务器将应答串与自己的计算结果比较，若二者相同，则通过一次认证；否则，认证失败；
6) 认证服务器通知客户认证成功或失败。
以后的认证由客户不定时地发起，过程中没有了客户认证请求一步。两次认证的时间间隔不能太短，否则就给网络、客户和认证服务器带来太大的开销；也不能太长，否则不能保证用户不被他人盗用IP地址，一般定为1-2分钟。
密钥的分配和管理：
密钥的分配由维护模块负责，当用户进行注册时，自行设定自己的口令字。用户的密钥由口令字生成。
一个口令字必须经过两次口令字检查。第一次由注册程序检查，强制口令字必须有足够的长度（如8个字符）。口令字被加密后送入数据库中，这个口令字标记为'未检查的'。第二次，由离线的口令字检查工具进行检查，将弱口令字进行标记，当下一次用户认证时，认证服务器将强制用户修改口令字。
密钥的在线修改由认证服务器完成，它的过程与认证过程基本类似。
安全性分析：
下面就认证的安全性进行剖析，分析常见的攻击方法对认证服务器的攻击效果。
1) 网络侦听（sniffer）
认证过程中，密钥和口令字不在网络上传输，所以网络侦听攻击无效。而在密钥的在线修改过程中，新口令字使用旧的密钥加密传送，网络侦听攻击仍然无效。
由于采用了单向Hash函数来对口令字和随机数进行处理，侦听者很难从侦听到的报文得到用户的口令字。
2) "重放"攻击（replay）
由于认证服务器每次选取的随机数不同，即Challenge不同，所以无法通过"重放"前面侦听到的认证报文来完成以后的认证。
3) 口令字猜测（password guessing）
侦听者在知道了认证算法后，可以对用户的口令字进行猜测：使用计算机猜测口令字，利用得到的报文进行验证。这种攻击办法直接有效，特别是当用户的口令字有缺陷时，比如口令字短、使用名字做口令字、使用一个字（word）做口令字（可以使用字典攻击）等。
对付这种攻击的办法是使用一个很长的口令字，并避免使用用户名字中的字，避免使用一个字（word）做口令字等。系统本身对口令字要求严格，首先口令字必须取的足够长（至少8字节）。用户的登记和修改口令字的程序强制用户的口令字长度。其次，离线的口令字检查工具，将弱口令字标记，强制用户限期修改。这样，用户的口令字就有足够的抗攻击强度。
4) 跟踪地址攻击
即攻击者在看到用户认证后，设法将自己的机器地址更改为用户的IP地址，从而冒充用户上网。但由于攻击者无法完成后续的认证，在1-2分钟内，攻击失效。
对于一个大型的企业来说，往往拥有大型的和相对健壮的网络架构，这个网络也许也是安全的。但是这个网络的运营和管理往往会有较高的成本。下面，我们用一个具体的例子来看一下在一个大型企业环境中，如何利用IBM 的Tivoli产品 Identity Manager来构建安全的企业网络。
ABIS公司是一个投资银行，总部位于某大城市。公司经营着各种金融业务，该公司因而从各种业务中盈利，因为业务的多样性，公司也具有不同的运作环境。但是，ABIS公司很少触及Internet上的交易，它的业务主要是提供给各个用户的金融代理服务以及在全球不同的股票证券市场处理交易。因为公司业务的多样性，于是有非常多的操作规则，在全球因为制度的原因也有不同的政策和规则的约束。因此ABIS公司在因特网上除了简单的信息服务以外很难提供其他服务。公司的规模大致是全球不同的国家共有70，000员工要访问财务数据系统，e-mail，和公司内部网上的应用程序。另外还有10，000家银行以外的合作伙伴的用户，这些用户通过VPN访问特定的系统。公司在全球不同地方都有很小的数据中心，同时主数据中心在总部。这也是大型企业的一个典型的IT运营环境。该公司目前有一个很健壮的安全和网络架构。系统也受到监控，并且每季度都要进行一次风险评估。
然而，要做到健壮又安全的网络架构，使ABIS注意到运营成本问题。公司检查了运营成本并且进行了成本分析之后，发现如果把信息基础架构更有效的管理起来可以明显的节约成本。于是公司计划实施一套身份确认项目来节约成本，同时公司发现IBM Tivoli Identity Manager是最适合的一套系统。
下面我们来看一下该公司的业务上的具体需求。为了降低总体IT运营成本并且集中用户管理，我们实施IBM Tivoli Identity Manager方案的目标是把安全风险降低到商业业务可以接受的程度。当然实施之前，必须同时确认了实施该解决方案所消耗的时间和投资回报率是可以接受的。对于实施这套方案，公司的目标有三个：1、降低总体运营成本。2、增加员工的劳动生产率。3、提高用户满意度。并且在进行成本分析的时候，确立了对于该公司的整体业务环境，全球的安全策略是唯一的，也就是说网络架构中任何接入点的安全程度都要求一样。于是，我们把需求进一步细化成如下几条：
有了需求就可以进行方案设计了。开发各个功能模块的需求是我们要做的下一步工作。调查是生命周期管理中的第一步。一般在接手这样的设计的时候，需要针对相关的职能人员做一份调查问卷或者在会议上进行调查。由于是接触到职能人员，这样可以发现很多在实施方案的时候要注意的事情。例如谁发起的整个过程、采用的是什么操作系统、用户需要访问多少系统、谁最终完成工作、这个工作有没有监控，还要注意一些其他方面，例如密码，组里的成员，受管理的系统和程序，策略和工作流等等。
下一步，我们需要看一下安全设计的目标。这一步是原型设计和实施阶段的基础。安全设计的目标应该包括身份识别管理、密码管理、策略管理、商业流程管理和监控管理，除此之外还有与运营有关的所有的标准、准则、政策等等。同时，对于公司里的各种工作职责的人应该有访谈，咨询到一些对于安全和运行方面的要求，例如访问系统的需求、属性、应用等等。
在这个投资银行中，我们进行了访谈，并且做出如图的利用Tivoli Identity Manager的原型。这个图表明了Tivoli Identity Manager在整个环境中的作用。
收集了这些信息之后，就可以开始定义工作流程了。工作流程一般是以流程图方式表示出来的。下图是一个普通的工作流程图。流程图对于显示创建或者修改需求是很有用的。
这仅仅是一个例子，简单的演示一个非常简单的身份管理的需求。在实际的应用中，情况可能要复杂的多。我们一般都有特定的方法来收集和研究这些信息。此时，我们可以借助有经验的人员完成这项事情，或者对于更大型的架构，我们可以请咨询公司来完成这样的工作。
下一步，我们需要研究出IBM Tivoli Identity Manager的架构。在这里，经过调查研究，ABIS已经定义好了实施IBM Tivoli Identity Manager的架构。包括下面这些方面：1、最重要的，每个用户要有一个单一的密码。2、管理系统必须利用安全模型来进行系统管理。3、用户界面友好，可以很直观的来改变密码或者完成其他管理工作。4、商业流程要集成在身份识别系统当中。5、对用户的各个活动和对资源的利用有清晰的监控能力。6、公司中的所有的系统上的身份认证都可以在一个集中的位置进行管理。7、数据的来源要求授权。8、在全球对于用户的帐号可以采用统一的安全策略。
有了上面的这些需求，就可以构架一个简单的IBM Tivoli Identity Manager了。下图给出了一个简单的Identity Manager构架。
IBM Tivoli Identity Manager服务器的组件都位于管理区域内，也就是上图中的Management Zone。管理区域是一个非常关键的区域，对安全性要求很高，这个区域是不能随便访问的。上图中，Identity Manager代理程序和WEB服务器位于生产区域（Production Zone），下图是系统结构图。用户访问首先会与代理程序的身份信息的通讯，根据策略信息，用户对于资源的访问会被允许或者拒绝。如果访问被允许，用户就可以直接和资源进行互动，而不是和Identity Manager代理程序。
