微软安全指南 Microsoft TechNet Security Guide 1 目录 编辑者言 3 优化基础架构, 实现 IT 投资价值 IT 基础架构不仅是一项具有战略价值的资产, 而且是软件系统赖以提供商务企业有效运转所必需之服务功能和用户应用的关键基础 从 IT 角度出发, 企业 IT 机

Transcription

1 微软安全指南 1 目录 编辑者言 3 优化基础架构, 实现 IT 投资价值 IT 基础架构不仅是一项具有战略价值的资产, 而且是软件系统赖以提供商务企业有效运转所必需之服务功能和用户应用的关键基础 从 IT 角度出发, 企业 IT 机构的目标就是要开发并维护易于管理的 IT 系统和解决方案, 优化商务流程, 提高业务效率, 降低总体拥有成本 (TCO), 面向客户与合作伙伴提供兼具可预见性和可依赖性的服务 专家专栏 6 ADFS 的身份联合 Jan De Clercq 越来越多的企业希望能够找到一种可以将内部网络的部分资源和信息通过安全 可控的经过授权的外部用户进行分享的方式 企业之所以有这样的需求, 就在于这样做能够加强企业与供应商或者客户之间的联系和合作, 让供应商和客户使用他们自己已有的帐户, 而无需在企业内部系统中重复创建, 当然这些访问必须经过企业的控制和授权 对于上述这种需求, 目前存在几种解决方案可供企业进行选择 其中一个就是身份联合 微软公司发布的 Windows Server 2003 R2 中一个最核心的亮点就是它提供了身份联合的功能 (Active Directory Federation Services,ADFS) 11 微软证书生命周期管理 Jan De Clercq Microsoft Certificate Lifecycle Manager 为你的 Windows PKI 增加高级证书和智能卡管理能力 在微软平台上进行高级安全身份验证, 不可缺少的就是 Windows 证书颁发机构 CA, 但浮现在管理员眼前的就是那一个又一个的管理页面, 还有那让人困惑的配置流程 ; 另外, 如何管理智能卡和 USB 令牌? 微软新推出的 Certifi cate Lifecycle Manager (CLM) 将会给您一个完整的解决方案 16 抵御 DOS 攻击的六条军规 Steve Riley 还记得 2000 年 2 月的 Internet 攻击吗?17 岁的加拿大孩子 Mafiaboy, 使用 52 个国家的 75 台计算机在 10 秒内发送了 个消息, 使得 11 个站点瘫痪, 导致了大约 17 亿美元的损失 为什么那些著名的网站都遭受了攻击, 而 Microsoft 和 MSN 得以幸免? 很简单, 因为他们没有完全遵守抵御 DOS 攻击的 6 条军规! 微软安全指南 1

2 目录 解决方案 18 微软身份和访问管理指南 在组织的发展过程中, 往往会累积了多个用于存储 管理和使用数字身份的系统及标准 这些系统可包括目录服务 人力资源 (HR) 数据库 财务系统和自定义应用程序, 以及面向员工 客户和合作伙伴的网站 与使用多个身份系统和标准相伴的复杂性增加了成本和间接管理费用, 而且随着应用程序表面区域的增大, 也带来了更多的安全漏洞隐患 第一部分 : 基本概念...24 本文由三个章节组成, 它们解释了基本的数字身份和访问管理概念, 以及微软平台的功能 第 1 章 : 简介...25 第 2 章 : 术语和计划...26 第 3 章 : 身份和访问管理技术...39 第 4 章 : 目录服务...46 第 5 章 : 身份生命周期管理...48 第 6 章 : 访问管理...51 第二部分 : 平台和基础结构...63 本文探讨的业务挑战是许多组织在处理身份和访问管理时遇到的相同问题 第 1 章 : 简介...64 第 2 章 : 选择平台的方法...65 第 3 章 : 问题和要求...72 第 4 章 : 设计基础结构...83 第三部分 : 访问管理和单一登录...90 本部分阐述了通过与 Windows Server 2003 目录和安全服务进行集成来改进 Intranet 访问管理的业务挑战 安全问题 工具和协议 第 1 章 : 简介...92 第 2 章 :Intranet 访问管理的方法...94 第 3 章 : 问题和要求 第 4 章 : 设计解决方案 案例研究 116 微软公司确保身份一致性的方法 为确保企业的身份存储区中不存在任何非托管帐户, 微软信息技术 ( 微软 IT) 部门开发了 AutoConsistency Manager 应用程序 AutoConsistency Manager 使得微软在其通往端到端身份管理服务 ( 基于 Microsoft Identity Integration Server (MIIS) 2003 而构建 ) 的长期路线图上又向前迈出了一步 2

3 编辑者言 IT 基础架构不仅是一项具有战略价值的资产, 而且是软件系统赖以提供商务企业有效运转所必需之服务功能和用户应用的关键基础 对许多组织机构来说, 其自身的成长壮大和新技术的迅速发展催生出极其复杂 不灵活且难以管理的数据中心和桌面系统平台 通常情况下, 这些系统本身的成本代价既十分高昂又相对固定, 而且不因商务需求的不同而改变 与此同时, 处在这种环境下的 IT 专业人员也面临着来自企业信息工作者的越来越大的压力 信息工作者要求 IT 环境下的一切都能 正常运转 例如, 随时随地访问信息资料并收发电子邮件 ; 与内部团队成员及外部合作伙伴实现即时协作等 从 IT 角度出发, 企业 IT 机构的目标就是要开发并维护易于管理的 IT 系统和解决方案, 优化商务流程, 提高业务效率, 降低总体拥有成本 (TCO), 面向客户与合作伙伴提供兼具可预见性和可依赖性的服务 基础架构优化模型为了帮助组织机构实现上述战略目标, 微软开发了 核心基础架构优化 (CIO) 模型 用于评估企业 IT 基础架构成熟度的可操作基准规范 在核心模型基础上, 开发出另两套功能模型 : 商务效率基础架构优化 (BPIO) 模型和应用平台基础架构优化 (APIO) 模型 以上 图 1: 基础架构优化模型 微软安全指南 3

4 编辑者言 三套模型共同描绘出所有企业所必需之关键基础架构的全息图景, 基础架构优化模型 (Infrastructure Optimization Model,IOM) 由代表技术成熟度的四个连续渐进水平 ( 阶段 ) 组成 : 基本型 标准型 合理型和动态型, 如图 1 所示 核心 IO 模型 (CIO) 核心 IO 模型定义了六项构建更灵活 IT 基础架构所必需的功能, 力求通过下列有助于发掘技术商业价值的关键基础架构功能为核心展开 : 桌面计算机 服务器与设备管理, 身份与访问管理, 安全保障与网络服务以及数据防护与恢复 ( 图 2) 通过实施 CIO, 可以提高技术决策者对系统的控制能力以及对系统的了解, 简化安全 管理以及其他可帮助人们取得出色绩效的功能 应用平台 IO 模型 (APIO) 针对 APIO 模型五大关键领域的投资有助于促进业务增长, 对 APIO 模型的贯彻主要围绕下列基础架构功能展开, 以期实现 IT 职能与业务目标的统一 : 商务智能 数据管理 软件开发 面向服务的体系结构与商务流程管理以及用户体验 借助 APIO, 技术决策者可以展示在机动性 灵活性以及跨 IT 平台的互操作性方面的 IT 投资和价值, 并通过整合以实现商业智能 服务导向型架构 业务流程 数据管理以及应用程序管理 商务效率基础架构优化模型 (BPIO) BPIO 模型映射组织机构的基础架构优化级别, 并且提供 IT 基础架构资产的优化指导, 从而力求更好的通过三个关键功能领域来实现 IT 基础架构资产的全面价值 : 统一通信与协作 企业内容管理和商务智能 BPIO 可以简化组织机构协作过程, 条理化内容管理, 并通过安全有效的基础架构解决方案提高业务洞察力, 从而帮助组织机构实现随时随地连通员工流程和信息的目标 IO 的意图在于帮助客户实现 IT 基础架构投资价值, 促使 IT 基础架构成为与所在企业相得益彰的战略资产, 并最终帮助客户围绕 全员就绪 (People Ready) 的理念营造 IT 基础架构 全员就绪的 图 2: 核心基础架构优化模型 4

5 编辑者言 商务企业 组织机构和基础架构应与行业环境相适应 它们可实现人员 信息与商务流程的有机结合, 帮助增强市场反应能力 消除低效环节, 从而, 以兼顾成本效益原则与时效性的方式推出新产品和服务 根据 IT 标准开发并保持高效运转的优化基础架构不仅有助于确保 IT 标准得到贯彻, 而且, 可为以环境和用户为中心的成本控制 安全防护及风险化解努力提供支持 身份与访问管理身份与访问管理属于核心 IO 的重要组成部分 ( 图 3), 它描述了客户应如何对人员和资产的身份实施管理 ; 应为管理和保护身份数据 ( 如同步化 口令管理和用户支持 ) 部署哪些解决方案 ; 如何对企业移动用户 客户和 / 或合作伙伴从防火墙以外发出的资源访问请求实施管理等 在帮助组织机构将身份与访问管理架构从基本型到动态型发展的过程中, 微软有丰富的产品和技术可以对企业提供有效的帮助 而在身份与访问管理方面达到合理型或动态型发展阶段的企业, 则大多以用于管理桌面计算机安全设置的 Active Directory 组策略和安全模板 置于严密控制下的桌面计算机和跨越多个不同系统实现用户支持的集约化管理为主要特征 为了帮助组织机构的 IT 专业人士, 特别是 IT 经理和架构人员深入了解基础架构优化模型, 以及如何利用微软产品与技术实现组织机构 IT 身份与访问管理架构的顺利发展, 我们特组织了本技术指南, 比较完整的阐述了组织机构身份与访问管理的技术架构 解决方案和产品概述, 同时还包含了微软公司是如何在内部实施身份与访问管理的 IT 实践 本技术指南涉及的产品与技术包括 :Windows Server 2003 Windows Server 2003 R2 Microsoft Identity Integration Server 2003 Active Directory Active Directory Application Mode Active Directory Federation Services Windows Rights Management Services 等 图 3: 身份与访问管理阶段模型 微软安全指南 5

6 微软安全指南 1 身份和访问管理指南专家专栏 专家专栏 ADFS 的身份联合 作者 /Jan De Clercq 越来越多的企业希望能够找到一种可以将内部网络的部分资源和信息通过安全 可控的经过授权的外部用户进行分享的方式 企业之所以有这样的需求, 就在于这样做能够加强企业与供应商或者客户之间的联系和合作, 让供应商和客户使用他们自己已有的帐户, 而无需在企业内部系统中重复创建, 当然这些访问必须经过企业的控制和授权 对于上述这种需求, 目前存在几种解决方案可供企业进行选择 其中一个就是身份联合 微软公司发布的 Windows Server 2003 R2 中一个最核心的亮点就是它提供了身份联合的功能 (Active Directory Federation Services,ADFS) 对很多读者而言, 也许身份联合还是一个比较复杂和陌生的术语 的确, 身份联合 是由一系列组件和独立术语构成的一门复杂技术 在本文中我将首先为大家简单描述身 份联合的功能 企业将如何从该项技术中获益, 然后举例说明 ADFS 的运行原理 面临的难题 身份联合的目标是为了降低企业将内部资源和信息向经过授权的外部用户访问的难度和安全风险 潜在的用户可能是来自合作伙伴, 或者是企业的客户 例如, 对于一个属于制造业的公司, 它很有可能希望上游供应商能够进入它内部的原材料供应数据库 ; 或者一个行业咨询顾问公司, 它会允许签约客户进入内部网络, 查看有关调查报告和数据报表 上述这些需求中最为核心的就是, 如何才能在保证安全和可控制的前提下为经过授权的外部用户提供访问 从前, 最常见的两种解决方案是 Web 访问管理系统 (Web Access Management System) 和身份经纪人 (Identity Broker) 而现在, 新的身份联合提供了第三种, 也许是最佳的解决方案 要建立一套 Web 访问管理系统, 绝大多数的企业会选择购买通用型的软件产品 此类型的众多软件产品中, 要算来自 CA 的 etrust SiteMinder 和 Oracle 的 Access Manager 最为流行 这些 Web 访问管理系统通过为每一位外部用户定义一个独立的帐户来实现对企业内部资源的控制和访问 但是这种解决方案在扩展性方面存在很大缺陷, 因为为每一位外部用户创建帐户将很快成为一个负担, 而且也不易于外部用户的使用 试想如果很多企业都部署了类似的 Web 访问管理系统, 那么用户就需要记住多个在不同企业的帐户和密码, 很快管理这些帐户和密码就会成为用户和管理员们共同的恶梦 另一个解决办法就是让用户只使用一个帐户, 就能够访问多个不同企业的内部网 6

7 身份和访问管理指南专家专栏 络 这种办法被称为 : 身份经纪人 (Identity Broker) 最著名的身份经纪人例子就是微软公司主推的 Windows Live ID( 以前被称为微软 Passport) 身份经纪人解决方案同样并非完美 最关键的问题在于只有很少的企业能够放心地将自己的帐户管理外包给第三方实体 而且, 使用集中存储帐户的方式有可能成为被攻击目标和单故障点 身份联合将是解决数据访问难题的第三种解决方案, 这种方案完全不会出现上面两种方案的缺陷 而且, 身份联合为用户提供了单点登录的功能 (SSO), 允许企业通过他们自己的帐户进行控制 身份联合也不会出现帐户存储和管理的单故障点 当然世界上不存在完美的事物, 目前的身份联合解决方案仍然缺乏一些有用的功能, 例如, 与 Web 访问管理系统相比, 它在应用程序集成 审计和报表方面, 表现都稍逊一筹 理解身份联合 身份联合, 也被称为联合身份管理, 它是连接不同帐户身份提供者与资源提供者之间的桥梁 在身份联合的世界中, 任何一个组织既可以是身份提供者, 也可以是资源提供者 所谓的身份提供者是指, 一个颁发和管理帐户身份的组织 资源提供者是指, 一个提供资源, 并对访问进行控制的组织, 这里的资源可以是一个数据库, 也可以是一个 Web 应用, 或者文件等等 大多数的组织这两种角色兼而有之 : 它们向合作伙伴提供资源访问, 同时又向自己的内部员工颁发和管理帐户 在身份联合的环境中, 身份提供者和资源提供者通常被比喻为孤岛, 它形象的表示了这些实体之间的隔离状态 这些孤岛在不同的组织之间广泛存在, 甚至很多时候在一个组织内也会出现孤岛的情况 对身份联合有一个最常见的误解, 那就是身份联合只适用于不同组织之间, 保证数据安全 可控交换的技术 实际上, 对于组织内部由于安全或者策略等各种原因出现的信息孤岛, 利用身份联合技术同样可以为组织带来很多益处 能够将不同组织间信息孤岛联合起来, 身份联合技术会立刻让人非常感兴趣 不同组织的信息孤岛通常都具有与其他组织和系统所不同的操作模式和工作原理 它们有着不同的帐户命名标准 不同的用户身份验证机制, 以及不同的对资源进行访问控制的方式 这里的联合标准则提供了一种在表达帐户 身份认证 访问控制等多个方面, 能够为各种不同身份提供者和资源提供者所共同接受的通用语言 目前, 业界主要存在三种身份联合的技术标准 每一种技术标准都有它自己的阵营 微软 IBM 和 VeriSign 主推被称为 Web 服务联合 (WS-Federation) 的技术标准 附文 身份联合的标准之争 简单介绍了 WS- Federation 的内容和它的主要竞争对手 很多打算实施身份联合的企业都希望使用同一个技术标准 但是, 实际上这并不是必须的 : 因为很多身份联合解决方案 ( 例如,HP OpenView Select Access 和 IBM Tivoli Federated Identity Manager) 都提供了在多个不同标准之间兼容或者转换的功能 在 WS-Federation 标准中包括两个支持配置文件 : 一个是被动模式客户端 (Passive Client); 另一个是主动模式客户端 (Active Client) 被动模式客户端通常是指支持 HTTP 协议 安全套接字层 (SSL) 保证能够安全传输 HTTP 数据包的浏览器 对于一个被动模式客户端而言, 它通常对是否进行了联合一无所知 而一个主动模式客户端则将能够理解联合协议, 而且它比被动模式客户端更加复杂, 功能更加强大也更加安全 主动模式的客户端能够支持简单对象访问协议 (Simple Object Access Protocol,SOAP) 在本文撰写的时候, 微软 ADFS 中的 Security Assertion Markup Language(SAML)1.1 提供了对 WS-Federation 被动客户端的支持, 但暂时还不支持主动客户端 ADFS 的体系构架 总体而言,ADFS 构建于其他几个重要的微软身份管理组件之上, 它们包括活动目录 (AD) 和活动目录应用程序模式 (ADAM), 并且与微软的 IIS 紧密集成 图 1 显示了在一个简单 ADFS 部署中的核心组件 : 联合服务器, 它运行了 ADFS 联合服务模块 一个 ADFS Web 代理和一个 AD 或者 ADAM 服务器 7

8 微软安全指南 1 身份和访问管理指南专家专栏 关于验证 cookies 和安全令牌是如何具体在身份提供者和资源提供者之间交换传递的细节, 我将在下面的内容中为大家介绍 ADFS Web 代理的主要作用就是使 IIS 服务器上的 Web 应用程序能够与 ADFS 协同工作 ADFS Web 代理知道如何与联合服务器处理 ADFS 验证 cookies 和安全令牌 图 1:ADFS 部署核心组件 在图 1 的身份联合应用中, 它允许来自身份提供者 的浏览器用户访问一个位于资源提供者网络中 IIS 服务器 上的一个 Web 应用 这位浏览器用户使用的是身份提供 者颁发的一个 AD 账户 ADFS 提供基于 X.509 证书的工具, 在身份提供者和 资源提供者之间创建信任关系, 从而实现信息和数据的 安全交换 ADFS 的信任关系是单向的 如图 1 中的例 子, 是资源提供者信任身份提供者 这种信任关系是不 可传递的, 也就意味着, 假如 A 信任 B,B 同时也信任 C, 但是不会因此就有 A 自动信任 C 的情况 在身份提供者和资源提供者之间实现 ADFS 身份联合 的关键, 就在于两边的联合服务器 : 在身份提供者一边的联合服务器使用 AD 或者 ADAM 验证用户 当用户身份得到成功验证, 身份提供者这边的联合服务器将产生验证 cookies 和安全令牌 在该安全令牌中将包含用户的信 息, 包括用户名 组成员关系 邮件地址 然 后联合服务器还会对该安全令牌签名, 以防止 被第三方篡改 在资源提供者一边, 当用户尝试访问 Web 应用 时, 资源提供者的联合服务器将检查用户提供 的验证 cookies 和安全令牌 联合服务器将 cookies 和令牌转换为 Web 应用程序能够理解的格 式, 然后将它们交给 Web 应用程序 对于一个现有的 Web 应 用程序, 若想要在 ADFS 中使 用, 那么就需要进行一些代码的改动, 这样该 Web 应用 程序才能理解 ADFS 的安全令牌 要为一个 Web 应用程 序启用 ADFS, 你可以使用验证管理器 (Authorization Manager) 引擎 ( 在微软管理控制台中添加插件, 或者 ASP.NET 中的 API) 另外, 如果你的 Web 应用程序恰 好是微软的 SharePoint Portal Server, 那么恭喜你, 你无 需任何修改,SharePoint Portal Server 天生就支持 ADFS ADFS 的运行原理 图 2 显示了 ADFS 实体之间 ADFS 消息的传递 需要记住的是, 本例是通过 ADFS 使一个来自身份 提供者的浏览器用户成功访问资源提供者中一个 Web 应 用的场景 实现上述功能的后台支持和 ADFS 消息传递 如下 : 步骤 1: 来自身份提供者的一位浏览器用户向位 于资源提供者网络中的一个 Web 服务器发起访问 请求 步骤 2: 这时 ADFS 的 Web 代理检测到该用户没 有经过 ADFS 验证, 接着将该用户转给资源提供 者的联合服务器 步骤 3: 在这个步骤中, 浏览器用户向资源提供者 的联合服务器提供他所在域的信息 该用户所在 域其实就是我们所说的身份提供者 假如这是该 用户第一次访问该 Web 应用, 那么用户提供的 8

9 身份和访问管理指南专家专栏 信息将包括用户名 所在域或者电子邮件地 址 在接下来的请求中, 资源提供者的联合服 务器将从用户提供的 cookies 中读取信息 步骤 4: 根据身份提供者所在域提供的信息, 资 源提供者的联合服务器将该浏览器用户转向身份 提供者的联合服务器, 要求用户身份验证 步骤 5 : 浏览器用户使用他的 AD 账户和密码在他所在域的联 合服务器上进行身份验证 步骤 6 : 根据 AD 服务器的验 证, 身份提供者的联合服务器 确认验证成功, 然后为该用户 产生一个验证 cookie 和 ADFS 安 全令牌 步骤 7 : 身份提供者的联合服 务器将浏览器用户连同安全令 牌和 cookie 一道, 返回给资源 提供者的联合服务器 步骤 8: 资源提供者的联合服务器将安全令牌转 换为它的 Web 应用程序能够理解的格式 该联合服务器还会产生一个新的验证 cookie, 然后将浏览器用户 ( 包括安全令牌和新的验证 cookie) 重定向到 Web 应用程序的 ADFS Web 代理 这时, ADFS Web 代理将最后检查验证 cookie 和安全令图 2:ADFS 实体之间的 ADFS 消息传递 身份联合的标准之争 目前主要存在三种身份联合的技术标准 : Security Assertion Markup Language(SAML) 标准主要由 Advancement of Structured Information Standards(OASIS) 组织发起 SAML 提供了一种将身份数据签入一个 XML 消息的方法 SAML 版本 1.2 和 2.0 目前被广泛用于联合部署中 SAML 2.0 可以被看作是 SAML 1.2 和 Liberty Identity Federation Framework(ID-FF)1.1 的结合 要了解更多信息, 请访问 php?wg_abbrev=security Liberty ID-FF 1.2 和 Liberty Identity Web Services Framework (ID-WSF) 1.1 标准主要由 Liberty Alliance 组织发 起, 它是一个由超过 150 个致力于标准化联合身份技术标准的业界公司组成 要了解更多信息, 请访 问 WS-Federation 标准主要由 IBM 微软和 VeriSign 发起, 它是作为另一个包括范围更广的 Web 服务的组 成部分出现 从一定程度上讲,WS-Federation 标准与 Liberty Alliance 标准相比有很多重复的地方 也 正是因此,2005 年 Sun Microsystems 与微软公司达成协议,WS-Federation 标准与 Liberty Alliance 标准在 Web 单点登录领域能够互操作 要了解更多关于 WS-Federation 标准的信息, 请访问 xmlsoap.org/ws/2003/07/secext; 要了解更多关于 WS-Federation 与 Liberty Alliance 互操作性的信息, 请 访问 9

10 微软安全指南 1 身份和访问管理指南专家专栏 牌, 通过后将允许用户访问该 Web 应用程序 步骤 9:Web 应用程序读取该用户的验证信息, 然后将相应的内容返回给浏览器用户 ADFS 的 Web 单点登录 ADFS 也是一个 Web 单点登录 (SSO) 解决方案, 它帮助企业将网络内部的 AD 和基于 Web 的应用程序扩展到 Internet 如果是部署了 Windows 2003 的企业在寻求 Web 单点登录的解决方案, 那么 ADFS 应该是第一选择 虽然, 目前的 ADFS 与其他纯 Web 单点登录方案的功能相比还是要逊色一些, 例如 CA 公司的 etrust SiteMinder 和 HP 公司的 OpenView Select Access, 而且在 Web 应用程序上可能还需要一些开发和底层工作, 但是要知道 ADFS 是伴随 Windows 2003 R2 免费提供的, 而且与微软的 IIS Web 服务器和 SharePoint Portal Server 紧密集成 ADFS 要获得成功的关键, 在于它不仅能够与 AD 和 IIS Web 应用程序协同工作, 而且它还必须能够与非微软的身份和资源提供者协同工作 很多软件开发商已经同意在 ADFS 的构架中推出与 ADFS 兼容的产品, 这样就将 ADFS 的应用范围扩展到了其他非微软的环境中 例如, 来自 Centrify 和 Quest Software 公司的产品, 就已经将 ADFS 的 Web 单点登录扩展到非 IIS 的 Web 服务器上, 例如 Apache Tomcat 和 IBM 的 WebSphere 微软也表达了 ADFS 能够与其他身份管理产品互操作的决定, 包括 IBM CA Oracle BMC Software Ping Identity 和 RSA Security 若要更进一步了解微软 ADFS 的技术细节, 请参考 ADFS 白皮书, windowsserver2003/techinfo/overview/adfsoverview. mspx 关于作者 Jan De Clercq 是 HP 安全办公室成员之一, 擅长身份管理和微软产品的安全 他是 Mission Critical Active Directory: Architecting a Secure & Scalable Infrastructure (Digital Press) 一书的作者之一 您可以通过 jan.declercq@hp.com 与他联系 10

11 身份和访问管理指南专家专栏 微软证书生命周期管理 Microsoft Certificate Lifecycle Manager 为你的 Windows PKI 增加高级证书和智能卡管理能力 作者 /Jan De Clercq 在微软平台上进行高级安全身份验证, 不可缺少的就是 Windows 证书颁发机构 CA, 但浮现在管理员眼前的就是那一个又一个的管理页面, 还有那让人困惑的配置流程 ; 另外, 如何管理智能卡和 USB 令牌? 微软新推出的 Certificate Lifecycle Manager (CLM) 将会给您一个完整的解决方案 强力的用户验证是身份管理服务最基本的功能之一 : 它是一个在组织之间访问资源和安全地交换身份标识数据的密钥体系 用户验证解决方案包括多个验证要素 ( 例如 PIN 或 password 知识, 指纹等生物数据 ), 它们共同组成了当今强验证市场的技术 比较流行的强验证方案是智能卡和 USB 令牌 如果你已经在微软共用密钥架构 (PKI) 环境中部署了智能卡或 USB 令牌, 你应该知道 Windows 缺乏高级的智能卡和 USB 令牌的部署 管理和维护功能 现在, 微软在 Certificate Lifecycle Manager (CLM) 中完善了这一领域, 它也可以为不使用智能卡或 USB 令牌的 Windows PKI 部署中的证书管理提供更多的价值 CLM 最重要的特性是它可以灵活地部署和管理证书 智能卡以及 USB 令牌 让我们首先看一看 CLM 是如何容易管理, 以及是什么使它成为如此优秀的工具 然后我将介绍 CLM 的组件和结构 起源与竞争 CLM 是微软对 idnexus 进行改造的产品, 该产品在 2005 年收购于 Alacris 在本文撰写时,CLM Beta 1 已可以下载, 微软考虑将 CLM 作为 Microsoft System Center 组件的一部分来提供, 而不会包含在 Windows Server 发布中 ( 不像 Windows PKI 服务 ), 也不会将其捆绑到公司的身份管理解决方案 Microsoft Identity Integration Server (MIIS) 部署 CLM 很简单 :CLM 安装程序是一个向导, 可以自动配置主要的 CLM 组件 提供类似功能的竞争产品有 Intercede 的 MyID Corporate ( Athena Smartcard Solutions 的 AthenaCard Management System (CMS 11

12 微软安全指南 1 身份和访问管理指南专家专栏 scs.com),aladdin Token Management System (TMS aladdin.com), 以及 SafeNet Card Management System (CMS / 等 易于管理 CLM 为证书 智能卡和 USB 令牌提供了单点管理 在 CLM 基于 Web 的管理界面 ( 如图 1 所示 ), 你可以管理活动目录 (AD) 中用户的证书和智能卡的生命周期 在没有部署 CLM 的 Windows PKI 环境中, 你必须使用多个微软管理控制台 (MMC) 管理单元和命令行工具来完成同样的工作 例如, 如果没有 CLM, 要定义证书配置文件, 你必须使用 MMC 证书模板管理单元, 要批准或拒绝用户证书申请, 你又要使用 MMC 证书授权管理单元或 certutil.exe 命令行工具 图 1:CLM Web 管理界面 利用 CLM, 你可以为证书或智能卡登记用户, 批准或拒绝证书申请, 解锁智能卡, 定义证书配置文件, 以及生成与证书和智能卡相关的报表, 所有这些都在一个界面中执行 CLM 管理界面也为多个 Windows Certificate Authorities (CA) 提供了一个统一的界面 你可以使用 CLM 界面向不同的 Windows CA 发送证书颁布和撤销请求 受 PKI 管理员欢迎的另一个功能是 CLM 强大的报表能力, 它可以使你轻松地生成 AD 环境中证书和智能卡使用的详细报告 图 2 显示了一个 CLM 报表例子, 它 图 2 :CLM 报表样例给出了所选时间范围内 CLM 请求类型的分类目录 除了 Web 管理界面,CLM 还包含一个允许用户管理个人证书和智能卡的 Web 界面 在这个界面中, 用户可以请求证书 永久智能卡或临时智能卡 ; 查看证书和智能卡详细信息 ; 或者更改智能卡的 PIN 12

13 身份和访问管理指南专家专栏 灵活性 CLM 对于企业来说是 一个灵活的证书和智能卡管 理工具 你可以轻易地自 定义 CLM 的逻辑, 以适应 组织的证书和智能卡管理需 求, 你可以在 CLM 管理界 面中进行大多数自定义, 不需要或只需要一点点自定 义代码 那些希望在 CLM 界面隐藏特定功能, 或希 望在 CLM Web 页包含公司商标的组织, 也可以在 CLM Web 界面和相关逻辑中进行一些小的调整 CLM 灵活性的一个较好例子是, 你可以用它轻易地 支持集中或非集中模式的智能卡和 USB 令牌发行 在集 中模式中, 一个管理员提供智能卡或令牌并发送给用 户, 然后用户解锁并使用 在非集中模式中, 管理员 只是将智能卡发送给用户, 然后用户自供应 CLM 也包含大量的逻辑设置, 默认是禁用的, 它 们可以是证书或智能卡发行过程中自动化的一部分 例 如, 组织可以配置 CLM 自动分发智能卡解锁代码或通过 指导用户登记智能卡 最后,CLM 具有内置并且易于定制的工作流 管 理委派以及自服务功能 下面的例子说明了这些功能 : 工作流 在 CLM 界面中你可以定义, 在给用户 登记给定证书类型之前, 证书管理器批准的请 求数量 管理委派 一个 CLM 管理员可以将批准 AD 用户 登记请求的权利委派给另一个管理员 自助服务 你可以允许用户初始化并完成指定 证书类型的登记, 无须管理员干预 体系及组件 CLM 是一个多层 Web 应用程序, 它利用了不同的微 软体系服务和服务器 CLM 必须安装在 Windows Server 2003 以上版本的服务器平台上 在 Web 服务器端,CLM 图 3: 在 Windows CA 中启用 CLM 的属性设置需要 Microsoft IIS 6.0 以上的应用服务器, 需要安装 Microsoft.NET Framework 1.1 在 Web 客户端,CLM 需要 Microsoft Internet Explorer (IE) 6.0 以上版本 在后端,CLM 应用与 Windows 2000 Server 或 Windows 2003 AD 以及一个 SQL Server 2000 Service Pack 3a (SP3a) 以上版本数据库服务器进行通讯 CLM 使用数据库存储配置和历史数据 当与 CA 集成时,CLM 连接到一个 Windows 2003 企业 CA ( 即 AD 集成的 ) 在 CLM 安装过程中, 一个 CLM 专用的 policy 模块和 exit 模块被安装到 Windows CA 上并被启用 ( 如图 3 所示 ) Policy 模块允许 Windows CA 为颁发的证书添加 CLM 专用的 X.509 属性 Exit 模块允许 Windows CA 与 CLM SQL Server 数据库进行通讯 这些模块在后台工作, 除了图 3 所示的一些例外配置, 你不需要直接处理它们 CLM 安装向导用一系列 CLM 专用对象和属性扩展了 AD 架构 CLM 使用这些 AD 对象存储 CLM 证书和智能卡配置文件信息 CLM 配置文件包含链接到给定证书或智能卡类型的管理策略 这些策略包括登记 恢复 更新 撤销 禁用 解锁 ( 只适用于智能卡 ), 以及复制 ( 只适用于智能卡 ) 等 你可以在 Edit Profile Template 界面定义 CLM 配置文件 它们的属性以及相关的管理策略 ( 如图 4), 你可以通过 CLM 管理界面中的 Administration\Manage profile templates 选项来访问 CLM 也利用 AD 来存储 CLM 用户和管理员数据以及定义 CLM 管理委派 为了以后的目的, CLM 安装向导扩展 13

14 微软安全指南 1 身份和访问管理指南专家专栏 quest Revoke CLMS Request Unblock Smart Card 以及 CLMS Enroll 你可以使用这些 CLM 专用权限来定义用户和组如何与 CLM 系统进行交互 例如, 你可以指定一个特定用户可以向 CLM 系统发起一个证书请求, 或者指定一个特定的管理员可以请求 CLM 系统撤销一个证书 图 4:Edit Profile Template 配置界面 CLM 专用权限可以使用 classic AD management 工具设置到 AD 用户 组和 CLM 配置文件对象上 图 5 显示了如何从 MMC 的 Active Directory Users and Computer 管理单元赋予一个 AD 用户以 CLM 专用的权限 要赋予一个用户登记特定 CLM 证书或智能卡类型的权限, 你必须在相应的 CLM 配置文件对象上设置许可 你可以在 MMC 的 Active Directory Sites and Services 管理单元中的 Services\Public Key Services\Profile Templates 节点来进行操作, 如图 6 所示 CLM 可以与智能卡 智能卡阅读器 不同制造商的 USB 令牌交互 要让 CLM 和 Windows 与一个特定智能卡交互操作, 制造商必须用到一个 Windows CryptoAPIcompliant Cryptographic Service Provider (CSP) 软件模块 这个 CSP 必须部署到所有使用智能卡 USB 令牌以及 CLM 的 Windows 机器上 ( 包括客户端和服务器 ) 你可以在 windowsserver2003/zh-chs/library/serverhelp/6faa74b1-4ef2-45f9-8ef3-3bbad1a45341.mspx?mfr=true 获得相关信息 图 5: 从 Active Directory Users and Computer 管理单元 赋予一个 AD 用户以 CLM 专用的权限 如前所述, 在 AD 环境中智能卡或 USB 令牌的 CLM 集成管理也需要安装 CLM 客户端软件, 它包含在 CLM Server 分发包中 CLM 客户端中的工具允许用户重置他们的智能卡或 USB 令牌的 PIN, 而无须管理员干预 了 AD 授权模式, 增加了以下 CLM 专用的权限 :CLMS Audit CLMS Request Enroll CLMS Enrollment Agent CLMS Request Recover CLMS Request Renew CLMS Re- 聚焦身份验证 CLM 是微软逐步成为一个重要的身份管理方案参与 14

15 身份和访问管理指南专家专栏 者的又一个证明 在过去的几年, 微软 曾经在身份验证领域走过弯路, 即在其操作系统平台中捆绑身份验证管理服务 微软现在提供的身份管理方案可以覆盖非微软平台和应用程序 : 一个好例子是 Microsoft provisioning solution( 前面提到的 MIIS) UNIX integration services (Services for UNIX SFU Windows 2003 R2), 最近的是微软的 PKI 解决方案 ( 捆绑在 Win2K 和 Windows 2003 中 ) 以及 CLM 图 6 : 从活动目录站点和服务管 理控制台中, 设置 CLM 特殊的 AD 权限 你可以在 china/business/security/access/whpaper. mspx 找到更多关于 CLM 的信息 关于作者 Jan De Clercq 是 HP 安全办公室成员之一, 擅长身份管理和微软产品的安全 他是 Mission Critical Active Directory: Architecting a Secure & Scalable Infrastructure (Digital Press) 一书的作者之一 您可以通过 jan.declercq@hp.com 与他联系 15

16 微软安全指南 1 身份和访问管理指南专家专栏 专家专栏 抵御 DOS 攻击的六条军规 作者 /Steve Riley 还记得 2000 年 2 月的 Internet 攻击吗?17 岁的加拿大孩子 Mafiaboy, 使用 52 个国家的 75 台计算机在 10 秒内发送了 个消息, 使得 11 个站点瘫痪, 导致了大约 17 亿美元的损失 为什么那些著名的网站都遭受了攻击, 而 Microsoft 和 MSN 得以幸免? 很简单, 因为他们没有完全遵守抵御 DOS 攻击的 6 条军规! 不久以前我和一个朋友进行过争论 他不同意我关于如何配置边界路由器以及其后 的防火墙的建议 我主张在网络与 ISP 之间的边界路由器上配置 6 个规则, 阻止大部分 拒绝服务攻击传输 ; 而在防火墙上配置包过滤和内容检测 但是他主张在防火墙上同 样重复配置路由器的规则, 并且如果可能, 最好在路由器上也重复配置防火墙规则 这使我感到困惑," 为什么要将同样的工作重复两次呢?" 我问道 " 这样防护层次 更深," 回答不出所料, " 如果黑客突破了路由器, 则防火墙也许可以阻止他 " 不, 这样做并不能增强防护 加强防护深度是指在所有的层做正确的事, 并且 只做适用于该层的事 如果依靠重复规则来加强防御深度, 则说明系统的安全状态很 脆弱, 也更不安全 有 3 种类型的弱点攻击 : Code( 代码 ): 需要通过补丁修复的软件错误 Configuration( 配置 ): 在安装配置时的人为错误 Circumvention( 欺骗 ): 安全策略错误, 使得攻击者可以绕过该策略 到目前为止, 最常发生的类型是第二个 ( 依据 CERT 的一些调查 ): 配置缺陷 对我来 说, 在规则中出错比路由器或防火墙代码错误更有可能 ; 因此攻击者更有可能利用错误 的规则入侵, 而不是利用设备的代码缺陷 复杂性是安全性的大敌 简捷应该总是至上 因此, 要保持网络简单 ( 从而更安全 ), 确保每一层的防御措施都被调整和指定, 而不是重复在其它层已被处理的事情 抵御 DOS 攻击 现在回到主题 在一个边界路由器中, 你应该配置 6 个规则, 它们将阻止几乎所有 的拒绝服务攻击 还记得 2000 年 2 月的 Internet 攻击吗? 17 岁的加拿大孩子 Mafiaboy, 16

17 身份和访问管理指南专家专栏 使用 52 个国家的 75 台计算机在 10 秒内发送了 10,700 个消息, 使得 11 个站点瘫痪, 导致了大约 17 亿美元的损失 ( 由于他在聊天室里炫耀, 加拿大警方才发现了他 2001 年他受到 56 条指控, 被判处在少年监管中心服刑两年 ) 为什么 Yahoo Buy.com ebay CNN Amazon. com ZDNet ETrade Dell 和 Excite 都遭受了攻击? 因为它们缺少 6 个重要规则中的 1 个或多个 MSN 和 Microsoft 也是目标, 但是由于我们的路由器具有这些规则, 我们躲避了这次攻击 这些规则如下 : 阻止所有源地址来自内部网络的入站传输 为什么来自内部的传输会从外部进入呢? 这说明有人正在进行欺骗 阻止所有源地址不是内部网络的出站传输 这与第 1 条相反 : 来自其他网络的传输没有任何理由从你的网络出去 内部的某人正在欺骗其他人 ( 对这些人我们有一个术语 : 雇员 ) 阻止所有源地址或目标地址来自私有地址范围的出站和入站传输 根据 RFC1918 中的定义, 这些地址用于内部网络 ;ISP 不会路由此类传输 当然,ISP 也会出现配置错误 ; 我曾经在 Internet 上看见过这些地址的传输 因此不能完全信任你的 ISP, 你应该自己阻止它们 还要记住阻止 Windows 自动分配私有 IP 地址 这些范围是 : / / /16 和 /16. 阻止所有源路由包 回到 1970 年, 当时 路由器 是一个运行路 5 6 由代理的 UNIX 计算机, 它们没有什么可靠性 因此 IP 在包头部包含了供应者信息, 以便指示将数据包从源路由到目标 源路由在当时是必要的, 但是今天已完全不需要了 : 路由器可以非常可靠地运行 源路由传输标志着一个攻击 : 应该完全丢弃 阻止所有广播包, 包括受控广播 在网络内部广播很有用处, 但是在网络之间几乎毫无用处, 因此不要允许广播进入 ( 或出去 ) 一个伪装的很好得 smurf 攻击, 看起来像是 IRC 通讯, 依赖于受控广播 阻止所有的片断包 Fragrouter 是一个古老但很优秀的工具, 对于躲避入侵检测很实用 攻击者可以利用它创建包片断 缺少 TCP 或 UDP 头的 TCP 或 UDP 包, 可以绘出你的防火墙策略和配置错误 除非一个显著的例外, 碎片一般不会被创建, 因此没有理由允许它们进入你的网络 这个例外是什么? IPsec, 更精确地说是 IPsec 中的 IKE 验证 在验证过程中,IKE 在通讯双方之间执行 6 次反复 在通讯双方协商安全并交换密钥时,IKE 产生碎片 : 很少有密钥能在一个包中放置 因此, 如果你允许 IPsec 在 Internet 和边界路由器之后的网络之间传输, 你应该忽略最后一个规则 这是你要做的, 在边界路由器上配置这 6 个规则, 这 样, 你也可以对 Mafiaboy 这样的人说 : 去沙滩玩吧! 哦, 猜猜会怎样? 由于你自己更安全, 你将更有竞争力! 你曾经想过一个路由器配置具有战略竞争意义吗? 关于作者 Steve Riley 是微软信息安全战略专家, 在安全领域工作了八年, 对于网络和主机的安全 通信协定及网络设计方面有相当丰富的理论和实践经验, 涉足信息安全原则与程序等领域的研究, 同时还负责制定信息安全策略和技术流程 Steve Riley 的客户包括美国众多的 ISP ASP 和传统企业, 他为这些客户进行安全评估和风险分析, 部署相关技术以加强监测及防范, 与此同时还为客户设计极具操作性的网络架构 17

18 微软安全指南 1 解决方案指南 微软身份和访问管理指南 在组织的发展过程中, 往往会累积了多个用于存储 管理和使用数字身份的系统及标准 这些系统可包括目录服务 人力资源 (HR) 数据库 财务系统和自定义应用程序, 以及面向员工 客户和合作伙伴的网站 与使用多个身份系统和标准相伴的复杂性增加了成本和间接管理费用, 而且随着应用程序表面区域的增大, 也带来了更多的安全漏洞隐患 概述 身份和访问管理结合了流程 技术和策略来管理数字身份并指定如何使用它们访问资源 针对组织面临身份与访问管理的难题, 微软推出了多项产品 技术和解决方案, 并且将这些产品 技术和解决方案整合在一起, 形成了基于微软技术的身份和访问管理指南 本指南由系列文章组成, 旨在帮助各组织利用微软的产品 技术与解决方案, 有效控制其环境并降低系统复杂性, 从而较好地解决身份和访问管理问题 本指南通过阐明概念 方法 技术以及可供用于解决身份和访问管理问题的解决方案来实现此目的 本指南同样表明了如何在异类 IT 环境中使用微软技术来获得实质性的业务成果, 重点集中于总体拥有成本 (TCO) 安全性以及对跨组织界限信息访问的日益迫切的需求这些主要问题上 系列文章所提供的解决方案凭借长期的安全和管理策略来平衡对短期业务成果的需求 本指南的每篇文章都结合了处理实际问题的现场经验, 所提供的解决方案均在技术方面得以验证 在适当时候, 本指南中的文章会提供有关实现 测试和操作文中所阐述的每个以场景为前提的解决方案的技术指导 微软工程团队 体系结构设计师 顾问 支持工程师 合作伙伴以及客户都参与了每篇文章的撰写 审阅和批准 微软与 PricewaterhouseCoopers 携手开发了 微软身份和访问管理解决方案, 即本指南系列文章的前身 这种将微软技术和产品专业知识与 PricewaterhouseCoopers 的行业专业经验相结合的方式为您呈献了最卓越的工具, 以供贵组织规划和设计有效的身份和访问管理解决方案 图 1 与图 2 说明了本指南所包含的内容和逻辑划分, 以及内容的结构安排 18

19 身份和访问管理指南解决方案概述 目标读者和基本结构 微软身份和访问管理系列文章主要面向负责规划 设计并实现身份和访问管理解决方案的安全专家 体系结构设计师 技术决策者 IT 专业人员 开发人员及顾问 参与身份和访问管理项目的其他人员也会发现这些文章及资源非常有帮助 本指南可分为三部分, 每部分都包含一篇或多篇文章 : 图 1: 身份和访问管理系列文章 第一部分 : 身份和访问管理基础知识 适用于 不具备身份和访问管理经验的人员, 以及希望 进一步了解微软身份和访问管理产品的人员 此部分将使读者熟悉一些基本概念, 这些概念 将在其余文章中进行详细论述 第二部分 : 平台和基础结构 适用于负责管理 大量身份的体系结构设计师 IT 专业人员和管理 员, 但其中还同样包含决策者所关注的信息 第三部分 : 访问管理和单一登录 适用于负责 将应用程序及平台与企业目录及安全服务相集 成, 并提高对日益增多的客户和合作伙伴的访 问便利性的体系结构设计师 IT 专业人员和开 发人员 其中每篇文章的开头都包含决策者所 关注的信息 本系列中第二部分和第三部分的文章都采用类似的 结构, 以满足不同读者的需要 文章的第一部分会大 概描述一个主题, 余下章节将提供一个或多个详细的解 决方案场景, 并附带实现指南和称为 工具和模板 的可用示例 这些文章的章节结构如下 : 简介 对文章及其每章内容进行概述 方法 介绍可供用于解决文章所涉及问题的多 个方法和技术 问题和需求 分析 Contoso Pharmaceuticals( 多 个组织的一个虚构组织代表 ) 所面临的问题以 及这些问题如何迫使其产生解决方案需求 设计解决方案 呈现 Contoso 所实现的解决方 案, 以及该方案的前提条件 逻辑设计和网络 布局 第一部分 : 身份和访问管理基础知识 本系列文章的第一部分提供了用于了解身份和访问管理的基础知识, 并为第二部分和第三部分的文章提供了背景材料 图 2: 浏览身份和访问 管理系列文章 基本概念 本文介绍了与身份和访问管理直接相关的业务和 IT 难题, 然后概括了克服这些难题可使用的方法和技术 19

20 微软安全指南 1 身份和访问管理指南解决方案概述 其中还论述了适用于身份和访问管理的主要概念及术 语, 如身份验证 授权 信任 联合 安全审核 置备和目录服务 本文回顾了各组织可用来构建身份和访问管理解决 方案的一系列技术 这些技术包括 : Microsoft Active Directory 目录服务 Microsoft Active Directory 应用程序模式 (ADAM) Microsoft Identity Integration Server 2003 with Service Pack 1 (MIIS 2003 SP1) Microsoft Passport Microsoft Internet Information Services (IIS) Microsoft Windows 授权管理器 Microsoft Windows 凭据管理器 Kerberos 版本 5 身份验证协议 公钥基础结构 (PKI) 和 x.509 证书 安全套接字层 (SSL) 传输层安全 (TLS) 轻型目录访问协议 (LDAP) 第二部分 : 平台和基础结构 本文借用虚构公司 Contoso Pharmaceuticals 来描述 一个典型组织会面临的与身份和访问管理相关的业务 技术和安全难题 通过描述一个基于微软身份和访问管 理平台并有助于解决这些难题的企业技术基础结构来延 伸 Contoso Pharmaceuticals 场景 该平台是其他文章所 述的所有解决方案的基础 第三部分 : 访问管理和单一登录 第三部分主要讨论控制资源访问的过程和技术 访 问管理涵盖了身份验证 单一登录 (SSO) 凭据映射 授权 信任和安全审核等主题 Intranet 访问管理 各组织必须经常应对不同供应商提供的操作系统 应用程序和目录服务所带来的问题 难题在于, 要么 将每个操作系统和应用程序集成到贵组织的首选目录和 安全服务中, 要么为替代的 SSO 体验提供凭据映射之类 的方法 Microsoft Windows 操作系统支持数种允许其他多个 操作系统和第三方应用程序实现跨平台集成的标准 将 第三方产品与基于 Windows 的安全和目录服务相集成可 降低管理成本 减少复杂性 改善安全管理, 并可实 现更佳的用户访问体验 本文阐述了几种将应用程序和平台与微软目录和安 全服务相集成的方法 从使用 Kerberos 版本 5 身份验证 协议和 LDAP 等协议进行的目录紧密集成, 到使用 SharePoint Portal Server 2003 BizTalk Server 2004 或 Host Integration Server 2004 实现的凭据映射技术, 都在这些 方法的涵盖范围之内 本文解释了用于实现 Intranet SSO 提供访问管理 和启用平台及应用程序集成的最常见技术 本文还提供 了适用于以下解决方案场景的实现指南 : 用服务器身份验证 获取本指南涉及的工具与模板 微软身份和访问管理下载包中含有 工具和模板 安装文件, 即 Identity and Access Management Tools and Templates.msi 作为此下载包一部分的 工具和模板 中包括基于文本的脚本 代码示例以及与身份和访问管 理有关的配置文件, 但不包括任何可执行程序或已编译 代码 将 UNIX 工作站与 Active Directory 相集成 使用 Kerberos 版本 5 身份验证协议集成 SAP R3 应 这些示例仅作为范例提供 必须对这些工具和模板 进行审核 定制及测试才能在生产环境中应用 在运行安装程序文件时, 最终所得的文件夹结构 ( 取决于您的安装位置 ) 将类似于图 3 本指南假定您将 工具和模板 安装到默认位置 : %UserProfile%\My Documents\Identity and Access Management Tools and Templates 如果您选择了其他安装位 置, 请确保在本文档所有步骤中都使用正确路径 20

21 身份和访问管理指南解决方案概述 咨询服务 目前有许多咨询服务可以协助各组织完成他们的身份和访问管理计划 此部分列出了一些专门致力于身份和访问管理的系统集成商 图 3 : 工具和模板 文件夹结构 在例外情况下, 工具和模板 的 MSI 包可能会 在安装过程中出错 有关详细信息, 请参见 身份和 访问管理系列文章 的 Readme.htm 文件 微软提供的补充解决方案 微软提供了下列解决方案来作为 身份和访问管理 系列文章 内容的补充 微软安全性和法规遵从性解决方案 此系列由 微软安全性和法规遵从性解决方案 (MSSC) 小组编写, 该小组还编写了下列安全指南 : Windows Server 2003 安全性简介与 Windows XP 安全指南 微软身份和访问管理系列文章的编制和测试均基于 使用这些安全指南配置的计算机进行 Windows Server System 参考体系架构 Windows Server Systems 参考体系架构 (WSSRA) 提供了经实验室测试和证明的体系结 构设计图和实现指南 微软身份和访问管理系 列文章的编制和测试均基于 Windows Server System 参考体系架构 ( 英文 ) 进行 微软的 UNIX 迁移解决方案 针对 UNIX 的 Windows 安全和目录服务解决方案 指南下载包使 Microsoft Windows Server 2003 Active Directory Kerberos 和 LDAP 服务可在异类的 Microsoft Windows 和 UNIX 环境中用于身份验证 和授权 Microsoft Services Microsoft Services 的目标是确保微软技术在帮助您最大限度降低复杂实现情况中的固有风险的同时达到您所期望的性能和投资回报率 (ROI) Microsoft Services 可提供多种整套咨询服务, 这些服务都是根据多年来所积累的微软解决方案的实现经验而打造 如果使用来自微软的最佳实践模型,Microsoft Services 可为解决方案开发和正在进行的运作提供框架 微软产品开发组和 IT 组使用的就是这些框架 配合我们的创新技术中心,Microsoft Services 先为您的解决方案制作原型和进行评估, 然后再在 IT 环境中进行部署, 从而帮助您减少风险和缩短上市时间 利用这些中心, Microsoft Services 及其合作伙伴通常在数周 ( 而不是数月 ) 内就可制作出解决方案的原型 微软的顾问们不但在大型组织的身份和访问管理解决方案的实现方面拥有相当丰富的经验, 并且对本系列所涉及的所有微软技术都拥有业界领先经验 Accenture Accenture 公司一直致力于实现创新, 在与其客户的协作过程中帮助他们取得更高绩效 Accenture 拥有深厚的行业和业务流程专业技术背景 广泛的全球资源以及已被证实的成功记录, 能够调动最适合的人员 技能和技术来帮助客户改善他们的绩效 企业集成 ( 使用技术和标准连接及简化业务流程 ) 是客户当今所面临的主要挑战之一 Accenture 的协作方法首先确定一组适合的工具和技术, 然后实现有助于推动企业绩效的集成解决方案 Web 服务技术在该领域中起着关键作用 Avanade Avanade 是微软企业解决方案的首要全球技术集成商 Avanade 利用微软企业技术来设计 构建和部署定制的可靠的体系结构以及可扩展的基础结构以提高收益率 增进上市速度并加快增长, 进而为其客户创造更多价值 Avanade 将重点集中于帮助 Global 2000 客户优化其异类 IT 环境中现有及未来的微软投资 21

22 微软安全指南 1 身份和访问管理指南解决方案概述 Cap Gemini Cap Gemini Group 是全球最大的管理和 IT 咨询公司之一 该公司在全球范围内提供管理和 IT 咨询服务 系统集成以及技术开发 设计和外包能力, 以帮助各企业持续实现增长策略和充分利用技术 Cap Gemini Ernst & Young 通过业界领先的信息安全处理方法 适应性安全 (Adaptive Security) 来提供最前沿的全球安全服务 适应性安全 方法将 身份和权限管理 技术用作集成式安全基础结构的核心组成部分 这种独特的方法将 身份和权限管理 环境划分为不同的流程和技术包 此方法可以进行单步式实现, 也可以实现向新基础结构和业务流程的分阶段迁移 Ernst & Young Ernst & Young Security & Technology Solutions (STS) 集团可为世界上信息密集度最高的组织提供独立的安全解决方案 STS 可对帮助其客户实现业务目标的安全解决方案进行评估 设计 实现和运作 当今的业务环境要求具备跨多个系统和应用程序管理多版本用户身份的能力 对于员工 客户和业务合作伙伴, 提供安全环境的任务成为一项越来越严峻的挑战 Ernst & Young 拥有 400 位专门从事于安全领域的专业人员, 其中有 32 人已通过微软认证, 曾为 财富 500 强企业 联邦政府以及军队提供数字安全问题方面的建议 PricewaterhouseCoopers PricewaterhouseCoopers 的 安全和隐私实践 专供用于帮助 财富 1000 强 企业解决关键性信息问题 该实践提供了多个领域的专业知识和经验, 包括 Web 安全和隐私服务 安全集成服务 信息系统安全和控制服务 网络犯罪响应服务以及全面的身份管理解决方案 安全和隐私实践 可帮助各组织评估 设计 实现和维护一个安全的业务基础结构 Unisys Unisys 在复杂身份管理解决方案的设计 开发和部署方面是全世界公认的领先企业 对于结合 Active Directory MIIS 2003 SSO 和 LDAP 来提供用户 应用程序和网络资源身份信息的统一视图的基于微软的解决方案, 该公司拥有大量的丰富经验 Unisys 的身份和访问管理框架集合了生物测定 智能卡 目录服务 访问控制 置备 工作流和 PKI 技 术以及实现服务 Unisys 中已通过微软技术认证的人员可提供产品知识 IT 专业咨询 设计 规划 产品实现和支持服务, 以满足当今复杂的技术基础结构的要求 Unisys 是微软在安全解决方案领域的黄金级认证合作伙伴 软件和硬件供应商 有数家独立的软件供应商 (ISV) 和独立的硬件供应商 (IHV) 可为基于微软技术实现身份和访问管理解决方案的客户提供所需的补充产品 这里提供了由每位供应商所提供的信息 ActivIdentity ActivIdentity 是双因素身份验证和远程访问安全产品的主要提供商 2005 年,ActivIdentity 收购了 Protocom, 以针对启用 Active Directory 的密码管理解决方案提供支持 ActivIdentity SecureLogin Single Sign-On 允许通过一组凭据来访问大型分布式环境中的异类系统 SecureLogin 还为多个应用程序和企业系统提供密码管理 灵活身份验证以及可定制支持 SecureLogin Single Sign-On Password Management Suite 不但可增强安全性 降低管理成本, 还可提高员工的工作效率 BMC Software BMC Software 已将 OpenNetwork Solutions 收购, 并集成了 OpenNetwork 产品以打造 BMC 身份管理 套件 该 身份管理 套件涵盖了解决方案的五个主要方面 : 目录管理和可视化 访问管理 密码管理 用户管理和置备以及审核和法规遵从性管理 BMC Software 还提供了几种与 MIIS 2003 集成的产品 ( 如 Business Process Manager for MIIS) 和大量适用于 MIIS 的第三方置备模块, 包括 SAP R3 Sun Solaris Oracle 和 Linux 最后,BMC Identity Management for. NET 使各组织可以利用他们在 Active Directory 方面的投资来降低安全管理组织内部和外部的用户及资源的成本 Centrify Centrify 的 DirectControl Suite 3 可将 Microsoft Active Directory 的身份 访问和策略管理服务扩展到 UNIX Linux Java 和 Web 平台 该套件使各组织可以快速集成多个身份, 而无需对 Active Directory 22

23 身份和访问管理指南解决方案概述 或 UNIX Linux 基础结构进行冒昧的更改 该技术使各组织可以利用 Active Directory 来降低管理成本 加强安全性和提高用户的工作效率 Computer Associates Computer Associates 可为不断演化的计算环境 ( 包括遗留体系结构 Web 体系结构和面向服务的体系结构 ) 提供全面的身份和访问管理产品线 CA 提供的身份和访问管理产品包括 etrust Access Control etrust Directory etrust Identity and Access Management Suite and Toolkit CA Identity Manager etrust Single Sign-On etrust SiteMinder etrust TransactionMinder 和 etrust Web Access Control DigitalPersona DigitalPersona 已与微软紧密合作以实现网络 网站和应用程序登录时的指纹身份验证 DigitalPersona 的指纹识别解决方案确保了可对用户进行唯一性明确识别, 从而实现了您的安全系统的自然扩展 降低了安全管理成本, 并进一步增强了 Microsoft Active Directory 和 ADAM 的安全功能 M-Tech Information Technology M-Tech 是身份管理解决方案的领先供应商 M-Tech Identity Management Suite (M-Tech IDM Suite) 是用于管理企业用户及其身份验证因素 ( 包括密码 令牌 生物测定和证书 ) 的一项完全集成的解决方案 该套件中包括 M-Tech 的旗舰产品 :ID-Synch( 用于用户置备 ) 和 P-Synch( 用于密码管理 ) 该套件还包括用于自助式资源访问管理的 ID-Access 以及用于在各目录间查找和调节登录 ID 的 ID-Discover M-Tech IDM Suite 只在 Microsoft Windows 2000 Server 和 Windows Server 2003 上运行 它可以置备 管理和取消激活每个微软产品上的登录帐户 M-Tech IDM Suite 与 MIIS 2003 相集成 各组织可使用通过 M-Tech IDM Suite 汇编的登录 ID 调节数据来加快 MIIS 2003 部署 MIIS 2003 客户还可通过该套件实现有效的密码管理自动化, 并将 MIIS 2003 的作用范围延伸到包含企业中的每一个 IT 平台 Passlogix Passlogix 成立于 1996 年, 其开发的软件产品可通过管理企业客户的用户名及密码来保证业务便利性和安全性 Passlogix 的旗舰产品 v-go Single Sign-On (SSO) 的部署不需要承担通常与 SSO 解决方案相伴的集成成本和重任 v-go SSO 事实上可与任何 Windows Web Java 专有和基于主机的应用程序配合工作, 从而降低 IT 和帮助台成本 v-go SSO 产品是第一个可与所有应用程序共用而无需冗长复杂的实现和部署过程的通用型单一登录解决方案 无论您是在部署强身份验证 实施企业级的身份管理计划, 还是仅关注特定用户组的登录难题,v-GO SSO 产品的灵活体系结构都可支持您的环境 用户要求和财务限制 v-go SSO 产品的客户端智能专利技术与卓越的高级目录集成以及简单却功能强大的管理控制台相结合后, 数天 ( 而不是数月 ) 内便可实现更快 更安全的登录 Proginet Proginet 是身份管理 置备和密码管理软件解决方案的领先提供商 该公司的解决方案针对的是用户生命周期管理的全面要求, 例如密码管理自动化 自助式密码重设 自动化用户置备 委派的帐户管理以及审核控制 Proginet 拥有被广泛认可的成功记录, 曾为遍及所有行业领域的 财富 2000 强 公司 ( 包括许多全球最大的金融机构 ) 提供高度安全 可靠和可扩展的解决方案 凭借在分布式技术平台和大型机遗留环境两个领域的强大核心能力,Proginet 的技术已经获得高级认证并受到业内嘉奖 2005 年 1 月,Proginet 收购了 Blockade Systems, 并将 Blockade Systems ManageID 套件整合到 Proginet 产品范围内 Proginet 产品目前包括用于置备和用户生命周期管理的 SecurForce 用于企业单一登录的 SecurAccess 用于双因素身份验证单一登录的带有 VASCo 令牌的 SecurAccess 和用于密码管理的 SecurPass Quest 2005 年 7 月,Quest Software 收购了 Vintela 这次收购使 Quest 能够为运行 Microsoft Windows UNIX 和 Linux 的混合环境的组织提供增强应用程序和系统的安全性及可管理性的关键基础结构技术 Vintela Authentication Services (VAS) 可扩展 Active Directory, 因此 UNIX 和 Linux 系统管理员可围绕目录服务将其身份验证需求集中化 由于 VAS 与 Linux 和 UNIX 上所用的安全系统集成良好, 因此 VAS 可对许多现有 23

24 微软安全指南 1 身份和访问管理指南解决方案概述 Linux 和 UNIX 服务及应用程序自动提供身份验证 Vintela 使用户可以在 Active Directory 的身份 身份验证 授权和审核的保障下安全连接到主导的 J2EE 应用服务器和 Web 服务 RSA Security RSA Security 的 身份和访问管理 解决方案可提供难以抗拒的机会来赢得胜过竞争对手的优势 提高与合作伙伴合作时的盈利能力并实现可加强客户忠诚度的用户体验 结合在电子安全方面的成功经验 周密制定的策略以及灵活的增量式设计和实现方法,RSA Security 不仅使您能够应对当今最紧迫的身份管理难题, 并且可为未来各种能力奠定牢固基础 RSA 针对法规遵从性 用户管理 单一登录 置备 Web 服务强身份验证 访问管理和联合身份提供了解决方案 Version3 Version3 Simple Sign-On 可提供功能异常强大却十分简单的方式来增强用户安全性和工作效率 Version3 Simple Sign-On 通过 Microsoft Active Directory 以透明方式维护单个应用程序身份, 因此提升了安全级别 Version3 Simple Sign-On 产品独特的安全体系结构 易用性和全面性为该产品构建企业级安全策略并将其应用于最终用户铺平了道路 该产品不仅增强了安全性, 还显著改善了用户工作效率并有助于降低帮助台成本 常见问题解答 Q : 我的组织并未运行 Active Directory 或任何 Microsoft Windows 产品 本指南对我有什么用处? A: 尽管微软身份和访问管理系列文章使用的场景以 Windows Server 2003 Active Directory 和 MIIS 2003 SP1 为基础, 但本指南所强调的原则适用于多种不同的解决方案 本产品支持多种身份存储区, 因此许多未使用其他微软产品的组织已实现了 MIIS 2003 如果您是拥有多个身份存储区的大规模分布式企业, 则会发现 MIIS 2003 可以提供您所需要的集成工具, 而无需使用 Active Directory 或其他任何微软产品 Q: 我们只是一家小公司, 为什么也应重视身份和访问管理? A: 即使是小公司也可能需要运行要求员工重复登录的多个身份应用程序 了解身份和访问管理的原则有助于避免做出需要复杂的身份管理解决方案的糟糕设计决策 Q: 我是一家大型国有企业的 CIO, 我需要能够将身份管理的业务优点向高级管理人员推广 不过, 他们都不是技术人员, 我不想用专业术语蒙蔽他们 在哪部分提供了可帮助我建立有说服力的财务案例的信息? A: 本技术指南第一部分 基本概念 列出了身份管理的重要优点以及可节省的成本, 不会用技术来混淆事实 Q: 我们拥有多种目录服务, 但我们的帮助台人员经常不得不处理用户忘记密码的问题 怎样才能尽量减少在此活动上所花费的时间呢? A : 密码管理 一节 ( 见 48 页 ) 介绍了执行自助式密码重设后再将这些新密码传播到多个身份存储区的过程 本文还介绍了如何使用 Windows 安全性 对话框通过一步操作更改多个密码 Q: 我所在公司的承包商的流动率很高, 我们目前要花大量时间去设置新用户和电子邮件帐户 我们还意识到当承包商停止合作后对用户帐户的禁用不够及时 如何才能实现这种功能? A : 用于置备和工作流的工具及模板 一文介绍了一个与 MIIS 2003 集成的提供高级置备和批准功能的工作流应用程序示例 您可以将用户帐户的置备过程自动化, 并将消息路由给经理以提醒他们需要进行批准 24

25 身份和访问管理指南解决方案基本概念 第一部分 : 基本概念 本文由三个章节组成, 它们解释了基本的数字身份和访问管理概念, 以及微软平台的功 能 这些章节包括以下主题 : 第 1 章 : 简介 本章提供了执行概要 业务挑战和益处 本文的建议读者和文章中各 章节的概述 第 2 章 : 术语和计划 本章回顾了身份和访问管理之后的主要术语和战略问题 同时讨 论了集成数字身份的选项以及处理这些选项的技术和组织方法 第 3 章 : 微软身份和访问管理技术 本章介绍了 Microsoft Windows Server 2003 Microsoft Windows XP 具有 Service Pack 1 的 Microsoft Identity Integration Server 2003 Enterprise Edition (MIIS 2003 SP1) Microsoft Passport 及其他与身份和访问管理相关的产 品的目录和安全服务 其余的章节更加详细地讨论了身份和访问管理方案与技术, 这些 章节所面向的是具有相关技术背景的读者 第 4 章 : 目录服务 本章探讨了 Microsoft Active Directory 目录服务和 Active Directory 应 用程序模式 (ADAM) 如何提供 LDAP X.500 和多主复制服务以构成有效的身份和访问管理基 础结构的基础 第 5 章 : 身份生命周期管理 本章回顾了管理用户 凭据和权限的方法 同时探讨了 实现用户自助 委派管理 身份集成和置备的方法及技术 第 6 章 : 访问管理 本章扩展了几个概念, 并对支持它们的技术进行了描述, 其中包括 : 身份验证 单一登录和凭据映射 使用基于角色的访问控制和访问控制列表的身份验证 信任和联合 安全审核 第 7 章 : 应用程序 组织经常需要开发内部应用程序或购买应用程序以运行业务线流 程 这些应用程序应与组织的所选目录和安全服务较好地集成 本章探讨了应用程序如 何与微软身份和访问管理平台集成, 并回顾了开发人员创建自定义应用程序所需的可用 技术 25

26 微软安全指南 1 身份和访问管理指南解决方案基本概念 第 1 章 : 简介 本文重点介绍与身份和访问管理相关的业务和 IT 挑战, 以及克服这些挑战的可行方法和 技术 本文还介绍了主要概念 术语 典型计划以及与身份和访问管理相关的微软产品及 技术 面向的读者 本文的预期读者包括参与身份和访问管理工作的架构师 IT 专业人员 IT 经理和顾问 次要读者是要为身份和访问管理投资制定业务案例的技术决策者 我们面临的挑战 随着数字身份在指定用户与计算机网络的交互方式中起着越来越重要的作用, 身份和访问管理也变得越来越复杂 组织需要在授予用户对网络资源的访问权限的同时, 对用户进行有效而正确的管理 然而, 组织很少只将身份信息存储在一个位置, 也很少只使用一个位置中的身份信息 多个部门 国家和地区 业务部门和软件选择, 以及合并和收购, 共同导致了目录服务和应用程序特定的身份存储激增, 使成本增加并导致复杂的安全问题 开发一致且有效的身份和访问管理策略, 需要充分了解可用来解决多种数字身份问题的方法和技术 组织和 IT 部门需要实施短期和战略性的方法来控制身份 企业益处 改善对网络资源的访问以及管理身份生命周期可为组织带来大量益处 典型的益处包括 : 通过效率和合并降低总体拥有成本 (TCO) 提高安全性, 降低内部和外部攻击的风险 合作伙伴 员工和客户对信息的访问量增大 提高生产力 满意度和收入 通过实施全面的安全 审核和访问策略提高法规符合性 提高在诸如合并和收购之类的事件期间的业务灵活性 26

27 身份和访问管理指南解决方案基本概念 第 2 章 : 术语和计划 身份和访问管理结合使用了过程 技术和策略来管理数字身份并确定了如何使用数字身 份来访问资源 身份和访问管理计划要比大多数其他 IT 项目复杂得多, 其原因仅仅是因为需要协调工作 的标识存储 协议 加密机制 策略和管理主体等数量繁多且互有差异 通过在加强安 全性时实现标准 减少标识存储的数量 建立信任 委派管理以及改进用户登录体验, 这 种综合策略可大幅度减少在大型网络中管理数字身份所需的工作量 身份和访问管理的组织策略需要对以下问题作出明确回答 : 身份和访问管理计划应该带来什么样的收益? 每项计划都必须克服哪些挑战? 必须解决哪些特定的组织因素? 支持每项计划会需要哪些业务 技术项目和解决方案? 您的组织需要清楚地知道改进后的身份和访问管理计划将会带来什么样的具体好处 缺 乏这种远见, 结果将不会带来实质上的进步, 而可能会导致更加复杂和蹩脚的系统 在您评估潜在的收益时, 请不要忽视实现具体技术解决方案的挑战 在预期的收益与 每个解决方案的规模和复杂性之间应当有一个平衡 身份和访问管理术语 以下术语对身份和访问管理内的一些构成要素或过程进行了描述 本系列文章的其他文 章会使用这些术语并对其进行详细说明 数字身份 人员 组 设备或服务的唯一标识符和说明性属性 其示例包括 Active Directory 中的用户或计算机帐户 Microsoft Exchange Server 2003 中的电子邮件帐户 数据库表中的用户条目, 以及自定义应用程序的登录凭据 凭据 通常是与数字身份具有的保密信息相关或从中派生的一条信息, 尽管这些保 密信息并不适用于所有情况 凭据的示例包括密码 X.509 证书和生物测定信息 安全主体 带有一个或多个可被验证和授权与网络进行交互的凭证的数字身份 身份存储 包含数字身份的存储库 身份存储通常是一些形式的目录或数据库, 这 些目录或数据库是通过提供程序 ( 例如,Active Directory 或 Microsoft SQL Server) 来管理和访问 可以集中 ( 例如集中在大型机上 ) 或分散身份存储 ;Active Directory 27

28 微软安全指南 1 身份和访问管理指南解决方案基本概念 就是分布式身份存储的一个实例 它们通常具 有明确的架构来指明可以存储哪些信息以及以何 种形式记录信息 它们通常整合了某些形式的 加密或散列算法, 以保护数字身份的存储和组 件, 例如凭据 之前的和自定义的身份存储可 能不具有如此严格的安全机制, 且可能会以明 文 ( 没有加密 ) 存储密码 身份同步 确保给定数字身份在多个标识存储 中的数据一致的过程 此过程可使用编程方法 ( 如脚本 ) 或者专门的产品 ( 如 MIIS 2003 SP1) 来实现 身份集成服务 跨越所连接的多个身份存储聚 合 同步以及启用集中置备和取消置备身份信 息的服务 MIIS 2003 SP1 和 Active Directory 的 Identity Integration Feature Pack 1a (IIFP) 可提供身 份集成服务 置备 向身份存储中添加身份并为其建立初始 凭据和权利的过程 取消置备的作用方式与此 相反, 其结果是删除或禁用某个身份 置备和 取消置备通常与身份集成服务相互配合, 以将 添加项 删除项和禁用项传播到所连接的身份 存储中 身份生命周期管理 保持数字身份最新且与管 理策略一致的过程和技术 身份生命周期管理 包括用户属性 凭据和权利的身份同步 置 备 取消置备以及进行中管理 身份验证 对照身份存储中的值检查安全主体 之凭据的过程 身份验证协议例如 Kerberos 版本 5 安全套接字层 (SSL) NTLM 和摘要式身份验 证等保护身份验证过程并防止凭据被拦截 权利 确定通过身份验证的安全主体的访问权 限和特权的属性集 例如,Windows 安全组和 访问权限都是权利 授权 使用在某个资源上配置的权限解析用户 权利以控制访问的过程 Windows 操作系统中 的授权包括文件 文件夹 共享和目录对象的 访问控制列表 (ACL) 一些应用程序 ( 例如 SQL Server SharePoint Portal Server 和 Exchange Server) 对其所控制的资源实施访问控制机制 应用程序开发人员可使用 Windows 授权管理器或 者 ASP.NET 角色实现基于角色的访问控制 息的协议的状态 信任通常用于采取受控制的 方式扩展对资源的访问, 从而消除原本会带来 的要对其他方的安全主体进行的管理 信任机 制包括 Windows Server 2003 中的跨林信任和使用 Kerberos 版本 5 身份验证协议时域间的信任 的一种特殊信任关系 件以及对身份对象变更的过程 各组织对重要 事件的定义可能有不同看法 安全审核记录可 写入到 Windows 安全事件日志 源的过程和技术 访问管理包括身份验证 授 权 信任和安全审核 我们的需求 最近在分布式计算领域 ( 特别是通过 Internet) 的 进展催生了许多访问典型组织中信息的应用程序和其他 机制 组织希望在继续发展 减少访问费用 加强安 全和符合监管要求的同时, 为员工 合作伙伴和客户 提供对信息资产的安全访问 在日益复杂的 IT 环境中必须提供对信息资产的安全 访问 自定义或打包的应用程序通常具有它们自己的身 份验证和授权系统以及用于创建和管理用户帐户的管理 工具, 这些用户帐户未与综合身份和访问管理平台集 成 这样的应用程序常常导致数字身份的孤岛更高的复 杂性 信任 描述不同参与方和系统之间共享身份信 联合 不同组织之间建立的超出内部网络边界 安全审核 记录和概述重要身份验证和授权事 访问管理 控制并监视访问符合管理策略的资 如此复杂和难于管理的系统使 IT 很难提供对信息资 产的访问和满足他们所服务的组织的业务需求 建于稳 定的身份和访问管理平台上的适当执行的身份和访问管 理体系结构可帮助 IT 满足这些业务要求 减少总拥有成本 如果组织未实现设计良好的 自动的以及可审核的 28

29 身份和访问管理指南解决方案基本概念 机制来加强访问管理, 则管理和维护一个综合的访问管 理策略将会是十分昂贵的 下面的数据摘自 PricewaterhouseCoopers/Meta Group Survey 2002, 题为 The Value of Identity Management ( 身份管理的价 值 ), 在该公司的 Web 站点 提供有这些数据 这些数据包含了与管理数字身份相关 的成本的主要示例 登录和身份验证 减少登录到不同系统所花费的 时间可大幅提高知识工人的效率 用户平均每天 花费 16 分钟时间进行身份验证和登录 对于一 个大型组织 ( 在调查报告中界定为拥有 10,000 个 用户的组织 ) 来说, 这就等价于 2,666 小时, 或 者说每天相当于 1.3 个全日制 (FTE) 年 管理身份生命周期 让组织的 IT 职员专注于提供 资源可用性和确保网络安全性这些重要任务是很 关键的 通过低效机制管理身份所花费的时间 如果用来完成更重要的任务将会更好 每年平 均花在管理用户 用户存储和身份验证以及访 问控制上的时间是 54,180 小时 即便是 25% 的 效率提高对于大型组织来说将等于 13,545 小时 ( 或者 6.7 FTE) 密码重设 百分之四十五的帮助台电话都是关 于重设密码 自动密码重设会将这种电话量减 少大约三分之一 对于一个拥有 10,000 个用户的 组织来说, 这就相当于年度成本估计会降低 $648,000 重复数据 消除重复身份数据可以优化管理过程 并减少 TCO 百分之三十八的外部用户和百分之 七十五的内部用户都包含在多个数据存储中 对 于大型组织而言, 采用集中统一的用户存储管理 所节省的平均时间预计每年是 1,236 小时 解决身份和访问管理问题的组织可大幅减少 TCO 即 使是小变化, 例如减少重设密码方面的帮助台电话数量, 也可使最终用户和帮助台接线员大幅度提高工作效率 增强安全性 安全性不仅是您要防范谁或什么的问题 ; 它同时也 是有关您允许谁或什么进入, 以及授予他们何种访问权 限的问题 员工 承包商 客户和业务伙伴对于访问 数据和应用程序有不同的需求 对于组织来说, 确定 并实现仅允许特别授权的用户访问敏感信息的访问管理 策略是十分重要的 安全性还和高效的运营管理有关 涉及代表员工 合作伙伴和客户帐户的不良管理流程可能导致更高的安全 性风险 例如管理成千上万在线客户的帐户可能超出常 规用户帐户管理系统的负载限制 组织同样不能像了解 和控制自身员工帐户那样了解和控制合作伙伴的员工 受控制的身份和访问管理可让组织扩展对他们的信息 系统的访问而不必降低安全性 组织通过精确的管理权 利以及迅速修改或终止访问权限来提供这种扩展的访问 以下安全性活动通常与身份和访问管理相关 : 改善帐户策略强制 可根据预先确定的标准管 理帐户来增强安全性 帐户策略强制定义实施 高级安全措施的规则和过程 示例包括要求管 理员使用智能卡和确保所有的用户都具有复杂密 码并经常更改秘密 删除过期帐户 通过及时删除过期帐户可显著提 高计算机安全 组织必须在不再需要某些帐户时 停用相关员工 承包商 合作伙伴以及客户的帐 户 如果未停用这些帐户, 则原有帐户的所有者 可能会误用它们来获得对系统的未授权访问 过 期帐户是居心叵测的用户和攻击者非常有吸引力 的目标, 因为它们可能具有过时的静态凭据且这 些帐户的误用和潜在危害更不易引起注意 改善应用程序数据保护 为了满足组织的安全 需求, 应用程序必须通过安全机制传送数据 在敏感数据可被访问之前, 必须要有适当的身 份验证和授权, 并且必须在网络上保护敏感数 据, 防止攻击者截取 ( 嗅探 ) 这些数据 实现强力身份验证 常用的身份验证技术和凭 据可能未提供关键应用程序和数据所需的安全级 别 微软建议在可能的情况下使用强力身份验 证机制, 如 Kerbero 版本 5 协议和公钥基础结构 (PKI) 技术, 以提高计算资源的总体安全性 使用目录服务管理凭据 目录服务在组织中有 许多用途, 它们可以提供特定的安全性好处 29

30 微软安全指南 1 身份和访问管理指南解决方案基本概念 例如, 高级身份验证方法 ( 如智能卡和生物测 定 ) 可大大提高组织的安全性级别 遗憾的 是, 这样的系统也同样会带来复杂性, 以及更 多有关必须严格维护和可集中访问的用户数据 在具有强有力的目录基础结构的情况下, 部署 这样的系统将更加简单 完善授权 授权必须足够灵活以便提供对资源 的常规访问和精确访问 例如, 常规访问允许 所有员工访问某个具体的应用程序, 而精确访 问则仅允许销售部门的员工在上午 9 点至下午 5 点时间段在应用程序中执行某些操作 用户应 从逻辑上映射到组织或者应用程序环境内的一些 角色, 例如, 数据库管理员 帮助台接线员或 者应用程序用户 通过置备管理权利 适当实现的置备系统会在申 请和批准权利方面强制执行一致的策略 当所有 的业务单元可轻松地遵循相同的流程时, 强制执 行会变得更加容易 置备系统还会提供审核跟 踪, 记录由何人在何时做出了决策和批准 实现身份生命周期管理 身份生命周期管理流 程有助于在用户的职业历程中保持其权利的更 新 例如, 如果某一名员工从 财务 部门 调到 市场 部门, 则身份生命周期管理流程 可关闭并删除该员工对财务应用程序的访问权 限, 并为其提供对市场应用程序的访问权限 身份生命周期管理流程可手动或自动处理 自 动流程通常通过更加及时地删除和授予访问权限 并根据需要确保这两个操作同时进行, 来增加 组织中的安全性级别 管理组 良好的安全实践要求组织通过有效的 组管理保持对组成员身份进行控制 组成员身 份可给予访问权限和特权, 因此确保每个组仅 包含正确的帐户是很重要的 身份和访问管理 系统可将用户帐户分配到正确的组, 或者创建 依赖某个帐户的属性的动态组, 然后将这些组 置备到目录服务和电子邮件系统中 减小攻击面 如果没有使每个存储都管理到一 个共同的高标准, 则多个身份存储将意味着用 户帐户受危害的风险会更高 同样, 多种身份 完善访问 验证机制通常意味着对整个系统的威胁更难于为 众人所知或者更不易减轻 减少安全系统和机 制总量的涵义是保留那些更便于管理和更安全的 系统及机制 使用户易于做正确的事情 单一登录 (SSO) 使用 户更易于符合组织的密码策略 当面临记忆和 管理多个密码时, 人们很自然地会创建简单的 密码或者记下复杂密码, 这些复杂密码可能会 留在工作区中不受保护 为了改进对信息资产的访问, 身份和访问管理技术 应满足以下要求 : 通过帐户和硬件的有效置备, 使员工能够快速 提高生产效率和访问信息资源 通过提供对组织内部网络环境之外的关键应用程 序的远程访问, 使员工更具生产效率 允许合作伙伴以受管理和受控制的方式直接参与 到业务应用程序中, 从而使跨越组织界限的流 程更加流畅 通过个性化信息和提供在线购买产品及服务的功 能来吸引客户 通过改善用户体验和增加客户 满意度来提高收益 通过实现联合来节约成本, 联合可获得越来越多 的商机, 它直接与合作伙伴协同工作而无需背上 管理合作伙伴参与人员的身份和凭据的包袱 通过满足这些主要的身份和访问管理需求, 组织可 实现更高的员工生产效率 降低成本并完善业务集成 确保监管符合性 身份已迅速成为许多政府和监管政策的焦点 其重 要性是对隐私日益关注的结果, 因为有更多的私人信息 被存储在信息系统上 控制对客户和员工信息的访问不 仅仅是良好的业务实践 ; 在这方面不能做好的组织将受 到重大财务损失和法律责任的公开威胁 符合数据完整性或数据隔离规定现在已是法律要 30

31 身份和访问管理指南解决方案基本概念 求 美国的组织可能需要满足以下的一项或多项要求 : Sarbanes-Oxley 上市公司会计改革与投资人保护 法案 Gramm-Leach-Bliley 金融服务现代化法案 健康保险便利及责任法案 (HIPAA) HIPAA 安全法规对于医疗保健组织如何处理可确认 个人身份的医疗信息具有严格的指导方针, 这便是上述 法规将如何影响组织的一个实例 这些指导方针包括适 当的审核控制 访问管理和授权等方面内容 有效的 身份和访问管理基础结构会正确地将不同信息系统间的 患者病历与正确的患者相关联 另外, 这样的基础结 构会审核对病历的访问, 并对复查病历的人员的身份进 行验证 并非只有美国的组织要面对日益繁琐的法规, 正如 法令 欧盟数据保护指令 1998 和 加拿大私人信息 保护和电子文件法 (PIPEDA) 中规定的那样, 这两者都 规定了有关身份信息的严格指导方针 还有许多地方法 律也规定了如何存储和使用与身份相关的数据 监管符合性可确保组织满足任何适用法规规定的隐 私 身份验证 授权以及审核方面的适用要求 适应兼并和并购 对于已兼并或收购了其他组织的组织而言, 集成其 身份和访问管理系统存在独特的挑战和机遇 要使新组织 的价值最大化,IT 必须使用公用的标准组合新加入组织的 数据和信息, 使员工能够尽快使用这些数据和信息 为了使新组织的所有员工对合并后数据获得适当级 别的访问权限, 集成身份和访问管理系统就非常重要 另外, 还必须合并新组织不再需要的冗余身份存储和管 理流程, 以保证合理的管理支出 在兼并和收购期间 IT 的挑战包括 : 使两个组织的身份存储兼容 将各个系统的帐户组合到一个合并的系统中 通过信任使用联合将多个身份和访问管理系统联 合起来 同步身份存储, 它通常是在兼并或收购期间不 同系统的立即合并不现实时可接受的一种短期解 决方案 更新安全策略, 以整合并符合因兼并或收购带 来的新监管要求 身份和访问管理策略方面的计划 每个组织都有不同的业务驱动因素要求确定并实现 身份和访问管理策略 为了确保成功的最大可能性, 策 略必须与业务目标一致以推动业务开花结果 项目优先 级应考虑以下方面 : 快速见效可促使执行人员主动支持 取得一些 见效快 成本低的成绩以增加动力和加强管理 层的赞同 尽早处理高风险领域 安全问题通常是应尽快 处理的主要业务问题 标准和基础结构通常是实施其他计划的前提条 件 根据过去的投资, 通过策略建立标准并建 立支持它们的基础结构可能会涉及到大量的人力 和物力 然而, 考虑到大多数其他项目的成功 依赖于这些条件的满足, 这种投资是值得的 每个考虑使用身份和访问管理策略的组织都将要考 虑一个唯一的目标与优先级组合 以下部分介绍了一些 更加普通的计划, 其中每个计划都是由一个或多个业务 和技术方案组成的, 包括 : 建立安全和访问策略 建立目录服务和安全标准 实现身份聚合和同步 自动化置备和取消置备 提供有效的组管理 合并身份存储 提供密码管理和同步 实现互操作性以及单一登录 加强身份验证机制 改善员工 客户和合作伙伴的访问 建立安全审核策略 更新软件采购标准 31

32 微软安全指南 1 身份和访问管理指南解决方案基本概念 建立安全和访问策略 许多书面的组织安全策略 ( 涉及人员 流程和技 术元素 ) 都可在目录服务中直接实现, 而其他的策略 将需要由可强制执行安全策略的特定系统和流程来控 制 组织访问策略可在全局级别指定关于访问特定应用 程序或成组应用程序的业务规则 这样的访问策略通常 使用角色 资源 操作以及限制来定义 优点 为身份的使用建立软件开发标准 开发并迁移身份识别应用程序 安全和访问策略以及其中角色的示例包括 : 帐户管理策略 它规定应定期从身份存储中删 除过期帐户 密码策略 它可能说明帐户密码必须定期更 改, 且密码需要达到某个最小长度和复杂性 安全审核策略 它可能定义必须报告哪些操作 隐私策略 它可能定义 独处的权利 ( 免于 受到不希望的通讯干扰, 如垃圾邮件 ) 以及信 息隐私规则 ( 个人控制自己的私人信息使用和 收集的能力 ) 访问管理策略 它可能坚持 : VPN 访问需要智能卡或者其他多因素身份验证 特定应用程序需要生物测定身份验证 对某些系统的 Extranet 访问仅限于通过了身份 验证的用户并且由边界防火墙服务强制执行 域管理员登录需要智能卡 到高价值系统的计算机连接需要使用 IPSec 加密 实施操作限制, 例如 出纳员只可在上午 9 点到下午 5 点时间段内提取客户帐户上的款 项 建立安全和访问策略的潜在优点包括 : 增强了整个组织的安全 增强了特定高价值系统的安全 完善了安全审核 达到监管符合性 挑战 建立安全和访问策略的挑战包括 : 术的全部约束和限制 可能带来的效率降低 建立目录服务和安全标准 无论是使用 Active Directory 还是其他替代应用程 序, 具有标准的目录服务都是身份和访问管理的主要使 能器 然而, 组织经常会发现需要多个目录服务 兼 并 收购以及应用程序选择可能使得在组织中引入两 个 三个甚至更多的目录服务 有效的身份和访问管 理策略会将这些目录服务合并到最少数量的身份存储 中, 这些身份存储将共同成为组织的标准目录服务 各种目录服务都可强制执行安全策略标准, 但是各 家组织可能在他们的内部运营中发现其间存在相当大的 差异 例如, 由于收购包括一个与组织的现有目录服 务不同的单独的目录服务和安全策略, 因此可能会产生 一个部门 因为与身份有关的安全标准通常与目录服务 紧密集成, 因此应将其放在一起来讨论 建立目录服务和安全标准是建立应用程序开发和采 购标准 保持低水平管理成本以及以安全方式扩展访问 所必要的前提条件 优点 挑战 需要为每个访问方案建立适当的安全性要求 使用所选的技术实现策略, 尽管认识到这些技 应对管理开销的增加以及非自动化方式增强安全 运行更复杂的安全机制 管理互相冲突的安全要求 建立标准目录服务和统一安全标准的潜在优点包括 : 减少了管理开销 简化了置备 增强了整个组织的安全 建立标准目录服务和统一安全标准的挑战很多, 其 中可能包括 : 具有特殊目录要求的业务线 (LOB) 应用程序和平台 32

33 身份和访问管理指南解决方案基本概念 构 ( 例如, 使个人银行业务与保险业务分开 ) 用的公用身份验证协议 显示权利 本指南第二部分 平台和基础结构 介绍了有关 建立目录服务和安全标准的详细信息 ( 见 67 页 ) 实现身份聚合和同步 很多情况下, 将多个身份存储和应用程序迁移到一 个标准目录服务并不实际 然而, 通过集成这样的系 统以共享它们的身份信息和通过公用策略创建并维护相 同的权利, 来减少管理成本和最小化生产效率损失通常 是可能的 身份聚合即包含这种从许多身份存储中链接多个数 字身份的链接 如果没有身份聚合, 将无法辨别人力 资源 (HR) 系统的中 Li, George Z. 与 Intranet 上的 George Li 以及电子邮件目录中的 G. Li 是同一 个人 身份聚合和同步使您的组织可通过身份集成服务 ( 例如 MIIS 2003 SP1 所提供的那些服务 ), 创建并维 护完整的数字身份 优点 挑战 无法一致的不兼容安全策略 组织内部问题, 如部门自治 组织内信息和管理边界的监管要求, 例如金融机 寻找一个组织中现有应用程序和身份存储可以使 以组织中不同应用程序和系统可使用的公用格式 身份聚合和同步的优点包括 : 减少了有关链接分布在多个身份存储中身份信息 的管理开销 增加了因组织中所有数字身份的统一呈现而提供 的业务信息 改进了来自单个身份存储的身份管理 与聚合多个身份存储相关的特殊挑战包括 : 发现组织中所有受管理的身份存储 同意聚合身份存储和同步信息 选择由哪些身份存储拥有哪些属性 的跨部门协作 性的权威源 本指南第 93 页的 身份聚合和同步 一节介绍了 有关此主题的详细信息 自动化置备和取消置备 组织希望新员工和承包商能够尽快发挥生产效率 它们无法承受职员花上几小时 几天甚至几星期, 等 待获得对应用程序的访问权限 自动化置备可从一个身份存储中获得新条目, 然后 在每个受管理的身份存储中创建对应的条目 取消置备 以相反的方式起作用, 在注意到某个存储中的更改后, 例如停用帐户, 再将该更改传播到其他的身份存储中 因此, 只要改动了其中一个所连接身份存储中某一个字 段的值 ( 例如, 在 HR 系统中, 将员工状态从 员工 更改为 前员工 ), 就会在几分钟内完成停用或者 删除多个存储中的一系列数字身份 优点 挑战 实现人力资源 IT 法律和其他参与业务部门 确定构成整个组织内所使用的数字身份的各种属 创建组织身份信息的全局视图 通过组织所有身份信息的全局视图审核更改 同步组织内不同身份存储中的身份信息 自动化置备和取消置备的优点包括 : 通过自动创建和删除多个身份存储中的帐户降低 了成本 通过减少为新员工创建帐户 密码和访问权限 所需的时间, 提高了生产效率 自动生成必要的属性, 如邮箱和帐户名称 组成员关系管理更轻松 角色管理更轻松 通过确保立即撤销离开组织的员工的所有访问权 限, 加强了安全 自动化置备和取消置备的挑战包括 : 33

34 微软安全指南 1 身份和访问管理指南解决方案基本概念 动流程 户创建和管理一组一致的权利 提供有效的组管理 组管理实现了自动化置备和取消置备 组织通常使 用通讯组分发电子邮件, 并使用安全组方便地将具有相 似权利的用户进行分组 当员工加入组织时, 他们的用户帐户应自动加入到 那些员工工作时所需的通讯组和安全组 另外, 组织 可能会创建基于公用属性值 ( 如 堪萨斯的所有用 户 ) 的组 手动创建基于属性的组很是耗时且容易 出错, 因此自动组创建和分配是身份和访问管理的理想 组件 优点 挑战 确定引起置备的业务流程 确定置备新帐户所必需的部门和批准 处理影响及时置备和安全取消置备的业务流程延误 将现有的手动任务替换成包含工作流和审核的自 将数字身份置备到多个身份存储中 为跨越包含不同身份存储或授权机制的应用的用 迅速收集必要的信息以确保及时置备 自动化组管理的优点包括 : 由于加强了对组成员关系和权利的控制, 增强 了安全 置备期间可将员工分配到正确的组 当用户离开组织 转换角色或者调动部门时, 从组中删除帐户 创建基于查询的组, 例如, 某个管理人员所有 直接下属的通讯列表 自动化组管理的挑战包括 : 标识适当的安全组和通讯组 标准化属性值, 以避免创建不必要的基于查询 的组 实现适当的审核流程以跟踪组创建和成员关系 符合监管要求 合并身份存储 除了聚合和同步身份数据之外, 就是减少正在使用 的身份存储的数量 例如, 如果组织具有两个应用程 序都使用轻型目录访问协议 (LDAP) 进行身份验证和授 权, 则很可能可以将多个独立的 LDAP 身份存储组合成 一个存储 可通过很大程度上的自动化机制在身份存储之间同 步和管理身份数据 然而, 这些机制的维护以及几乎 一定会发生的异常将会增加管理开销且增大受到安全攻 击的面积 优点 挑战 合并身份存储的优点包括 : 合并身份的挑战包括 : 异 提供密码管理和同步 密码管理和同步进一步推动了身份聚合流程 密码 管理涉及许多领域, 如建立并强制执行密码策略以及更 改或重设密码 然后, 密码同步会将这些密码更改传 播到所连接的所有身份存储中 例如, 密码管理和同 步可让用户执行一个操作, 便可更改他们的网络登录密 码 SAP 帐户凭据 电子邮件凭据以及 Extranet 协作站 点密码 密码同步可实现分组, 即对于关键系统使用 强密码策略, 而对于无法处理现代密码强度标准的其他 系统使用较弱的策略 优点 减少了管理开销 通过削减服务器和许可证降低了 TCO 减少了服务器维护要求 硬件和软件升级的支出费用更低 应用程序部署更容易 在单个的身份存储中创建聚合架构 不同身份存储的 LDAP 或其他协议实现之间的差 应用程序迁移 密码管理和同步的优点包括 : 34

35 身份和访问管理指南解决方案基本概念 挑战 降低了管理和支持成本, 因为帮助台职员不必 为多个身份存储重设用户密码 通过限制用户必须记住的密码个数以及减小用户 将会写下密码的可能性而加强了安全 由于在策略元素 ( 如密码长度和复杂性要求 ) 方面应用一致的密码策略而加强了安全 减少了用户等待帮助台的支持以重设密码的空闲 时间 密码管理和同步的挑战包括 : 处理具有不同长度和复杂性标准的多个密码策略 处理跨多个平台间的密码过期和历史间隔 确定由于存在不安全的身份存储或身份验证技术 以及其他弱点, 而不应向其传播密码的系统 根据需要从多个平台获取密码更改 连接到目标身份存储并将更新后的密码安全地传 输到该身份存储 确保用户在请求密码重设时没有说谎 确保新重设的密码以安全的方式发送给最终用户 处理具有硬编码密码或者本地配置密码的应用程 序和服务 实现互操作性以及单一登录 组织和组织之间的跨平台互操作性情景有很大不 同, 因为每个组织都独具一个要集成的目录服务 数 据库 应用程序和相关身份存储的组合 互操作性以及单一登录 (SSO) 方法包括 : 与服务器操作系统 ( 如 Microsoft Exchange Server 2003 和 SQL Server 2000 等产品使用 ) 集成 使用基于标准的安全身份验证协议, 如 Kerberos 版本 5 身份验证协议 对于不支持 Kerberos 版本 5 协议的应用程序或平 台使用 LDAP 身份验证和授权 使用凭据映射和企业 SSO( 如 Microsoft BizTalk Server 2004 SharePoint Portal Server 2003 和 Host Integration Server 2004 等产品使用 ) 优点 挑战 此方法不支持真正的 SSO, 但可减少用户记忆多 个用户名和密码的要求 ; 它通过改进身份同步 和密码管理来实现 互操作性以及单一登录的优点包括 : 提供身份验证所花的时间 互操作性以及单一登录的挑战包括 : 方式与时机 传播 本指南第三部分第 2 章 Intranet 访问管理的方法 介绍了有关互操作性和 Intranet SSO 的详细信息 ( 见 105 页 ) 加强身份验证机制 选择实现更强身份验证机制的原因有许多 这种举 措可能是加强组织计算资源安全的常规计划的一部分, 也可能是对具体威胁作出的反应, 或者 ( 最坏的情况 下 ) 可能是对一次成功攻击的响应 最后, 它可能需 要满足行业标准或者监管标准以获得认可或与此相似的 结果 跨多个平台和应用程序同步用户名和传播密码 对 Intranet 和 Extranet 方案实现 Web SSO 简化应用程序部署 达到网络上身份验证和数据安全的更高标准 通过 Intranet SSO 减少用户向多个身份存储重复 为组织中的平台选择正确的机制 在 Web 和网络 SSO 机制均可用时选择其中一个 选择使用 LDAP 目录服务进行身份验证和授权的 选择何时重新配置应用程序和平台以实现密码 LDAP 协议或架构实现中的差异 处理实现基于标准的身份验证机制期间的小变更 大部分组织仍使用用户名和密码组合向其应用程序 和资源提供身份验证 基于密码的身份验证机制可能非 常安全, 也可能非常不安全, 具体取决于所实现的应 用程序 协议 身份存储以及密码长度和复杂性 35

36 微软安全指南 1 身份和访问管理指南解决方案基本概念 如今可使用更加安全的不是基于密码的机制和技术, 如 X.509 数字证书 基于时间的硬件令牌 ( 也称为一次 性密码 (OTP) 设备 ), 或者使用生物测定的二次确认 将不同身份验证机制 ( 或者因素 ) 结合起来创建多 因素的身份验证将可实现最高级别的安全 例如, 将智 能卡 ( 您所拥有的 ) 上的 X.509 数字证书与解开与该证 书相关联的私钥的 PIN( 您所了解的 ) 相结合, 可创建 非常强的凭据, 而它反过来也会提供强大的身份验证 优点 挑战 加强身份验证机制的优点包括 : 增强了安全性 符合在访问资源时需要额外确认的监管要求 加强身份验证机制所涉及的挑战包括 : 平衡额外基础结构的成本与加强安全的需要 跨不同的平台和应用程序集成更强的凭据机制和 身份验证协议 避免为最终用户和管理增加复杂性 多因素机 制通常会增加可能出错的问题的数量 ( 例如, 用户丢失智能卡或者忘记了他们的 PIN) 最大程度降低部署硬件以支持凭据 ( 如, 智能 卡和 OTP 令牌 ) 相关的成本和资源 改善员工 客户和合作伙伴的访问 许多组织希望通过放宽访问以包括更多的用户类 型 应用程序和网络, 来优化它们的信息系统, 以期 获得竞争优势 此方法通常被称为 扩展网络边界, 因为组织网络周围的防火墙不再是防止外部用户进入的 一道屏障 例如, 客户访问信息和应用程序可能会带来新的商 机 业务伙伴通过集成库存 运输 财务和产品开发 系统来简化供应链, 从而能够共享机密的价格 产品 和支持信息 员工有更多的机会进行远程协作与沟通, 因为他们与客户和合作伙伴密切合作 优点 挑战 改善访问的主要优点包括 : 为外部用户改善访问的挑战有很多, 其中包括 : 序, 给予他们对适当资源的访问权限 本节介绍了在提供单一登录体验的同时, 让员工 客户和合作伙伴安全访问内部应用程序的设想 建立安全审核策略 典型组织具有需要在平台和应用程序级别都进行审 核的安全策略 执行本节中描述的一些身份和访问管理 计划的一个最大的好处是, 联合了身份存储 平台和 身份验证以及授权机制 这种联合使审核更加容易且更 加可信, 因为会减少出现安全事件的地方和方式 下一步就是组织详细叙述需要何种审核类型以及如 何获取 存储和使用审核信息 优点 迅速的应用程序开发 应用程序部署更快速 加强了对访问资源的控制 最终用户的体验更美好 减少了管理开销 与现有的应用程序集成 选择适当的身份存储 为各级用户选择适当的身份验证机制 选择适当的授权模型 调整身份验证和授权机制 管理许多合作伙伴和客户的身份 根据用户在组织中的角色及其所使用的应用程 在合作伙伴和组织之间建立信任的固有复杂性 建立安全审核策略的优点包括 : 减小了需要通过外部安全审核的影响 提高了发生安全攻击时进行法庭辩论的能力 提高了实时检测攻击的能力, 由此可警告管理 36

37 身份和访问管理指南解决方案基本概念 挑战 员启动紧急情况处理过程 略的能力 建立安全审核策略的挑战包括 : 更新软件采购标准 应用程序通常是身份和访问管理系统很复杂的根本 原因 应用程序通常会引入不同种类的身份存储 不 同的身份验证机制和授权策略 一旦标准化目录服务 安全和访问策略, 就一定要重视建立或者更新组织的软 件采购标准, 使得新的软件能够与组织的其他系统很好 地集成 从独立软件分销商 (ISV) 选择软件时应部分考虑软件 与所选目录服务集成的能力以及满足所建立的安全和访 问策略的能力 优点 挑战 增强了逆向强制执行在发生时难于强制执行的策 平台和应用程序的审核机制不同 具有各种级别特性的不同审核能力 组织不同业务单元的不同审核需求 在中央位置合并审核报告 过滤大量信息 生成有意义的报告 存档大量的审核数据 更新软件采购标准的优点包括 : 新应用程序部署可迅速完成 易于与身份和访问管理基础结构集成 更低的 TCO 增强了安全性 减少了对最终用户的培训 增加了最终用户的生产效率 更新软件采购标准的挑战包括 : 找到有所需功能的正确软件 了解要使用或购买哪些可选组件 为身份的使用建立软件开发标准 由于组织的业务需要发展, 因此会需要新的应用程 序执行新的业务功能 在设置和强制执行描述应用程序 如何与身份和访问管理基础结构交互的开发标准的同 时, 即可设定发展阶段, 以期获得更低的 TCO 和更高 的安全性 优点 挑战 选择使安全性最大化的软件 选择使生产效率最大化的软件 为身份的使用建立软件开发标准的优点包括 : 应用程序不会引起新的身份管理问题 可以更加迅速地开发应用程序 减少了管理成本 通过更小的攻击面加强了安全 建立软件开发标准的挑战包括 : 提供身份信息的权威源以供新应用程序利用 要求并确保应用程序使用现有的身份存储, 以 及现有的身份验证和授权功能 创建并发布清楚的指南, 与软件开发生命周期 (SDLC) 方法集成, 说明应用程序必须与身份和访 问基础结构集成的方法 培训内部和外部开发人员如何遵守这些指南 开发并迁移身份识别应用程序 一旦组织为应用程序开发建立了标准, 就可使用这 些标准开发新的应用程序 现有的应用程序也应具有与 身份和访问管理基础结构的相同级别的集成 为此, 需要清查现有的应用程序并进行分类 考 虑每个应用程序的价值 它们提供的信息以及它们的安 全特性, 以便确定其相对重要性 权衡这些因素与迁 移或变更每个应用程序成本, 以找到应当优先迁移的应 用程序的顺序 37

38 微软安全指南 1 身份和访问管理指南解决方案基本概念 优点 挑战 开发和迁移身份识别应用程序的优点包括 : 降低了管理身份的管理开销 增强了安全性 实现应用程序间的一致性 开发和迁移身份识别应用程序的挑战包括 : 理解应用程序的作用方式以便决定如何最有效地 集成它们 选择迁移应用程序的平台 选择应用程序开发的语言或开发人员环境 选择满足组织和应用程序要求的身份存储 选择满足要求的身份验证和授权技术 38

39 身份和访问管理指南解决方案基本概念 第 3 章 : 身份和访问管理技术 有效的身份和访问管理涉及到多项相互依赖的技术和过程 这些元素结合起来以保持组织中身份的统一形式, 并有效使用它们 在身份和访问管理中讨论的主要题目包括目录服务 身份生命周期管理 访问管理及应用程序应如何与基础结构集成 [ 注意 ] 本章概要介绍这些主题中的每个主题, 其余章节将更为详细地探讨每个主题中的过程和服务 有关这些主题的概述, 请阅读本章内容 其它内容, 请阅读后续章节 许多身份和访问管理技术及解决方案已独立地演变, 以应对特定战术性问题 组织 分析家 供应商及系统集成商已经逐渐认识到这些技术和业务问题都是相互依赖的, 因而可归为一个单独的类别, 该类别可简单描述为 身份和访问管理 为了直观显示这种相互依赖性, 微软创建了身份和访问管理框架, 以图形方式说明了身份和访问管理中涉及的服务和过程 图 1 显示了身份和访问管理框架的主要组成部分 本章确立了这些框架主题中的各个主题, 并介绍了支持这些主题的技术 服务和过程 遍布于身份和访问管理框架中的元素包括管理业务 安全性和隐私策略, 它们将组织的特定要求具体化 这些元素可帮助定义一些业务设想 规则 标准和约束条件, 用以控制如何应用技术和过程才能符合业务目标 例如, 安全策略广泛而深远, 因而会影响身份和访问管理的所有方面 隐私策略受组织 行业及实施的国家 / 地区的影响 这些策略定义合理的步骤, 以保护组织的身份存储库中的个人数据 国家和国际法规 ( 例如, 美国 1996 健康保险可携性与责任法案 (HIPAA) 英国 1998 数据保护法案 欧盟数据保护指令 95/46/EC) 及国际安全港协议和原则在建立隐私策略时都起到重要作用 图 1: 身份和访问管理框架的主要组成部分 39

40 微软安全指南 1 身份和访问管理指南解决方案基本概念 目录服务 目录服务提供了所有身份和访问管理基础结构的 基础 目录服务提供了权威数字身份信息的单一来 源 此类信息可包括安全信息 ( 例如密码和 X.509 证 书映射 ), 也包括用户属性形式的用户配置文件信 息, 其中用户属性包括地址 电话号码 办公场所 称谓和部门名称 微软建议对成为组织受信任数字身份存储库的少量 目录加以标识 此缩减带来了直接收益并提供了用以集 成所有其他组件的坚实基础 采用微软技术的目录服务 早在引入 Windows NT 3.1 时, 微软就开始在 Microsoft Windows 平台上支持目录服务 目前微软的目 录服务包括 : Microsoft Active Directory 目录服务, 它是 Windows 2000 Server 和 Windows Server 2003 不可或 缺的部分 Active Directory 应用程序模式 (ADAM) 有关微软目录服务的详细信息, 请参见后文第 4 章 的 目录服务 身份生命周期管理 存在多个用于管理用户 用户权利及其凭据的相关 过程 这些过程包括 : 身份集成服务, 其中包括聚合和同步 置备, 包括置备发生前 发生期间及发生后对 相关过程的管理 ( 通常称为 工作流 ) 委派管理, 例如由合作方工作人员管理帐户 自助管理, 例如用户发出的权利请求 凭据和密码管理, 包括最终用户密码更改和帮 助台密码重置 取消置备, 包括禁用或删除帐户 管理组 身份集成服务 当组织有多个目录或身份存储库时, 通常需要身份集成服务 由于这些目录中的每个目录都包含关于用户的所有信息的子集, 身份集成服务可通过创建所有身份存储库信息的聚合视图来提供帮助 身份集成服务通过从多种权威来源 ( 例如现有目录 人力资源 (HR) 和会计应用程序 电子邮件目录及各种数据库 ) 提取身份信息来创建此聚合视图 由身份集成服务汇集到一起的所有身份信息构成了单一数据库或虚拟实境, 即从多个连接的数据源中的身份信息所聚合的所有组合对象的一个全局 集成视图 通过此中央信息数据库, 可将规则应用到控制导入和导出操作期间数据流的数据 基于规则导入导出数据流的功能允许实现身份同步和连续置备 由于该同步和设置可通过程序规则 身份集成服务实现自动化, 从而使组织减少了与管理身份数据相关的成本, 并限制了人力管理产生的错误 置备 身份和访问管理的一个重要组成部分是如何创建数字身份 置备过程提供了一个功能强大的工具, 可利用组织目录基础结构中包含的用户信息来加速信息资源的用户帐户和权利的授予和撤销 这些资源可包括电子邮件 电话服务 HR 应用 业务线 (LOB) 和功能应用程序 Intranet 和 Extranet 访问及帮助台服务 实现数字身份创建过程自动化可动态降低成本和提高生产率 例如, 当新员工加入组织时, 置备系统可将获得用户帐户和访问权限所需的时间从一周以上缩减为几个小时 自动置备还节省了管理人员在处理相关文书工作上所花费的大量时间及财务 人力资源和 IT 人员在批准和实现请求上所花费的时间 工作流 工作流是多数置备过程的必备条件 要在线输入资源请求, 然后经由预设路径传送到审阅者和批准者, 最后再到达创建用户帐户的人员或系统 请求和支持材料 40

41 身份和访问管理指南解决方案基本概念 的电子副本会自动发送到过程中的每个参与者 所有部门都一致且完全应用该过程, 所输入的各条信息只使用一次 将提供有关获得批准人员及何时获得批准的完整审核追踪 如果审阅或批准操作没有及时完成, 受到自动监视的工作流会通知高级管理者或管理员 工作流在一些委派管理和自助过程 ( 例如发送请求以获得批准 ) 中也大有用处 委派管理 典型的管理模型包括一小组能够管理身份存储库的所有方面的受信任的个人 这些管理员创建和删除用户 设置和重置密码并设置所有用户属性 但是, 通常有充分的商业理由不让一个单独中央组管理员管理用户身份的所有方面 如果合作伙伴帐户在 Extranet 目录中, 首选方法就是所属组织将帐户管理委派给合作伙伴组织中的管理员 合作伙伴管理员将对其自己雇员的所有帐户负责 这样安排从管理角度来看很合理, 因为合作伙伴可以更好地决定何时需要创建或删除用户以及在本地处理援助请求 委派管理还可发生在组织内, 组织内不同部门中的受信任个人可管理组织的身份存储库的子集 自助管理 典型用户 ( 例如雇员 ) 有许多与安全性无关的用户属性 ; 组织可能考虑允许这些用户修改此类属性 例如, 可允许用户更改其手机号码 但是, 自助管理应有适当的约束条件, 例如强制执行命名约定和有效性检查 凭据管理 由于凭据是身份验证和授权的 密钥, 它们具有特殊的管理需要, 并应具有针对所有相关过程的严格的安全注意事项 凭据需要进行置备和管理 ( 例如撤销证书或重置密码 ), 用户需要自助功能 ( 例如更改其密码 ) 接收凭据的机制应受到严密审查( 例如, 通过显示标识亲自接收智能卡, 或通过加密的直接通道接收重置密码 ) 密码管理 密码管理是凭据管理的一个特殊子集 在目前的网络和应用程序中, 使用用户名和密码这二者的组合进行身份验证仍是最广泛使用的技术 可使用不同的技术管理不同环境的密码信息 密码管理的一个方面包括利用技术手段从一个系统向另一系统自动传播密码信息 这种传播允许用户使用相同密码登录多个系统, 从而可降低忘记密码的可能性及因忘记密码而导致的相关帮助台呼叫 由于平台和应用程序之间的密码一致, 通常要求通过共同界面集中进行密码更改和帮助台密码重置操作 只应在完全了解每个参与方系统的安全性特性之后再考虑密码传播 例如, 在使用 Telnet 并通过网络发送纯文本密码的 UNIX 环境下, 不应使用 Active Directory 帐户所用的同一密码来完成敏感的 对业务关键的事务 取消置备 取消置备是身份生命周期管理的另一个重要功能 取消置备可确保系统化地禁用或删除帐户, 并在雇员离开组织时即取消其权利 良好的安全实践告诉我们, 可快速禁用帐户 ( 防止受到不满离职雇员的攻击 ), 但在一段适当的时间内不要将其删除, 以备重新启用 ( 或重命名和重新分配 ) 该帐户时使用 一些组织需要确保某些身份属性 ( 例如帐户名称 ) 的唯一性, 并且在符合策略要求的时期内不被重新使用, 对于这样的组织, 禁用帐户 ( 而非删除 ) 也很有用 管理组 组管理包括自动和手动为组分配用户帐户, 以及从组中删除帐户 组通常存在于目录服务或电子邮件系统中, 例如 Active Directory 或 Lotus Notes 组分为以下两种类型 : 安全组和通讯组 安全组可用于配置权利, 而通讯组会列出组织电子邮件收件人 用户帐户接收它们所属任意组的权限和许可 组织可能想要实现基于查询的组, 其中的组成员身份取决于目录服务中所选属性的值 例如, 该设施启 41

42 微软安全指南 1 身份和访问管理指南解决方案基本概念 用了身份和访问管理系统, 以生成包含特定城市或办公 室的所有用户的组 只可为各个城市或办公室的独特值 创建组 如果组不再有成员, 则会删除该组 这些组 名称和成员身份稍后会传播到所有连接的目录服务和电 子邮件系统 采用微软技术的身份生命周期管理 用于身份生命周期管理的微软技术包括 : Active Directory, 包括 Active Directory 用户和组 微软管理控制台 (MMC) 及内置管理委派功能 Microsoft Identity Integration Server 2003 Enterprise Edition(MIIS 2003 SP1), 其包括以下特定功能 : 置备 密码同步和用于密码重置和密码更改的 Web 界面 Microsoft Windows Server Active Directory 的 Identity Integration Feature Pack 自助和自动化 X.509 证书注册 Services for UNIX 3.5 (SFU 3.5) Services for NetWare Windows 凭据管理器 IdM 通知服务 组管理 Web 应用程序 身份 和访问管理工具及模板中的组填充工具 有关采用微软技术的身份生命周期管理的详细信 息, 请参见后文中的第 5 章 身份生命周期管理 象的数字身份的过程 经过身份验证之后, 用户可根 据其通过验证过程的权利访问资源 身份验证技术 身份验证技术的范围从基于用户标识和密码信息 ( 您已知道 ) 的简单登录 生物测定 ( 用以将您区分 出来 ) 到更为强大的安全机制, 例如令牌 数字证书 和智能卡 ( 您已具有 ) 高安全性环境可能需要多因 素身份验证过程 例如, 将所了解的信息 ( 例如密码 ) 与区分特性 ( 例如指纹 ) 或某些具备的事务 ( 如智能 卡 ) 相结合 在电子商务环境中, 用户可访问跨越一个站点或多 个站点的许多 Web 服务器的多个应用程序 有效的身份 和访问管理策略会部署身份验证服务, 以简化用户体验 并减少管理开销 因此, 身份验证服务必须支持不同 种类的环境 身份验证技术的示例包括 : 用户名和密码 个人识别码 (PIN) X.509 数字证书 一次性密码 生物测定 ( 例如, 指纹或虹膜扫描 ) 智能卡 电子护照 硬件令牌 访问管理 访问管理涉及控制用户对资源的访问权限, 采用的方法是使用身份验证识别用户, 通过凭据映射将数字身份彼此关联, 或者利用身份验证检查用户对资源的访问权限 其他访问管理主题将讨论实现联合和信任来扩展访问, 及讨论用以跟踪和记录用户行为的审核功能 身份验证 身份验证是为网络 应用程序或资源证明用户或对 强 弱身份验证技术比较 身份验证技术的范围可从简单技术 ( 用户直接向应用程序或主机提供密码 ) 到很复杂的技术 ( 使用高级加密机制保护用户凭据不受潜在恶意应用程序和主机的破坏 ) 使用纯文本形式密码 ( 即不以任何方式加密的密码 ) 保护应用程序或主机被视为最弱的身份验证技术, 因为这样存在中途拦截身份验证序列的危险 此外, 如果用户验证恶意主机, 该主机的所有者将获得在网络上随处冒充该用户的所有必备信息 如果您将密码看作是 42

43 身份和访问管理指南解决方案基本概念 秘密, 那么, 如果用户必须告诉网络上每台计算机这 一秘密的内容, 它就不再是秘密了 较强的身份验证技术会保护身份验证凭据, 这样, 用户所验证的主机或资源就不会了解秘密的实际内容 通常, 这项工作通过使用只有用户和受信任的第三方 ( 例如,Active Directory 域控制器 ) 知道的秘密密码加 密签名数据来完成 计算机通过将签名数据呈现给受信 任的第三方来对用户进行身份验证 然后第三方会将该 签名与它所了解的用户签名相比较, 并通知计算机其是 否相信用户的真实身份与所声称的身份一致 此类机制 有助于保持密码真正的秘密性 单一登录 任何关于身份验证的讨论都包括一个重要概念, 即 单一登录 (SSO) 应用程序级别的 SSO 涉及在客户机与 服务器之间建立 会话, 允许用户一直使用应用程 序, 不必每次在应用程序内执行操作时都提供密码 同类观点可延伸, 形成一套可在网络上使用的应用 程序 为在不同应用程序中实现 SSO, 可在客户机 网 络上受信任的第三方和各种服务器应用程序及网络资源 之间建立会话 该会话在很多实现中都是由票证或 cookie 表示, 通常将此票证或 cookie 视为用户的替代凭 据 身份验证期间不需要用户提供其凭据, 而是将票 证或 cookie 发送到服务器并作为用户身份证明接收 最终结果就是用户在使用许多应用程序之前只需登 录一次, 因而提供了单一登录体验 [ 注意 ] 只有在非常特殊的情况下, 身份验证机制才能强 制用户重复提供身份验证凭据 另一方面, 在执行特别敏感 的操作前, 应用程序可能会提示提供凭据 采用微软技术的身份验证 Microsoft Windows Server 2003 Active Directory 完全 支持一系列身份验证方法, 其中包括 : 基于公钥基础结构 (PKI) 的身份验证 Kerberos 版本 5 身份验证协议 X.509 证书映射 支持使用 X.509 证书的智能卡 6.0 (IIS) 支持所有上述内容, 还支持 : 应用程序可通过应用程序编程接口 (API)[ 例如, 安 全支持提供程序接口 (SSPI), 其中包括安全协议协商 (SPNEGO)] 来调用身份验证方法 Windows XP 包括用于工作站登录和资源访问的集成 身份验证 用于对网站进行集成身份验证的 Internet Explorer 和管理密码 数字证书的凭据管理器及用于身 份验证的 Passport 授权 Microsoft Passport Windows NT LAN Manager (NTLM) 质询 / 响应 可扩展的身份验证协议 (EAP) 安全套接字层 (SSL) 3.0 和传输层安全 (TLS) 1.0 加密 Windows Server 2003 Internet Information Services 授权是指决定是否允许数字身份执行所请求操作的 过程 授权在身份验证之后进行, 它会将与数字身份 ( 例如组成员身份 ) 相关的属性映射到资源的访问权 限, 以确定该数字身份可访问哪些资源 访问控制列表 不同平台用于存储授权信息的机制各不相同 最常 见的授权机制称为访问控制列表 (ACL), 它是数字身份及它 们在资源上可执行的一组操作 ( 也称为权限 ) 的列表 操作通常相对于 ACL 所保护对象的类型进行定义 例如, 打印机可能允许诸如 打印 或 删除作业 的操作, 而文件可能允许诸如 读 或 写 之类 的操作 摘要身份验证 基于表单的身份验证 基本身份验证 安全组 支持大量用户的操作系统通常支持若干安全组, 这 些安全组构成特殊类型的数字身份 使用安全组减少了 在大型网络中处理数千用户的管理复杂性 43

44 微软安全指南 1 身份和访问管理指南解决方案基本概念 安全组简化管理的原因是 ACL 可具有几个条目, 它 们可指定哪些组具有访问对象的特定访问级别 由于组 设计仔细,ACL 应是相对不变的 可通过操作由集中 授权机构 ( 例如目录 ) 维护的组的成员, 一次就可轻 松更改多个对象的授权策略 组之间彼此嵌套可增加用 于管理授权的组模型的灵活性 角色 许多应用程序使用 角色 这一术语来指代用户 分类 例如, Manager 角色可用于指代称为 Finance Managers 的安全组的所有成员, 该组的成 员将自动获得该角色所具备的对网络资源的访问权利 角色还可基于能提供更大灵活性的动态 运行时 决策, 例如费用报告应用程序中的授权 该应用程序 可具有只能由已授权的用户 ( 或主体 ) 以 Approving Manager 角色来验证的批准操作 但是, 在授权批 准一笔费用之前, 系统会查询目录以确定提交者的 Manager 属性是否与批准这笔费用的人员的名称相 符 此类业务驱动逻辑几乎不可能使用 ACL 类型机制来 配置 角色可进行全局定义 ( 例如由目录中的组成员身份 来定义 ), 或使用可根据动态查询结果确定角色成员身 份的应用程序代码来定义 还有两种类型相结合的定义 方式, 例如定义了 Managers 角色的应用程序, 该 基色已在本地定义为包括全局组的 HR Managers 和 Engineering Managers 角色 这些方法各有其优点 精心设计的角色机制会为应 用程序开发人员提供灵活性, 以从众多机制中做出适当 的选择 采用微软技术的授权 Windows Server 2003 对一系列授权方法提供完全支 持 微软授权技术和支持组件包括 : 访问控制列表 (ACL) 通过 Windows 授权管理器进行的基于角色的访问 控制 IIS 6.0 URL 授权 ASP.NET 授权 有关微软授权技术的详细信息, 请参见后文第 6 章 访问管理 的 授权 部分 信任 信任的概念对于持续与其业务合作伙伴共享资源的组织来说越来越重要 在独立管理系统之间建立信任的能力对于 IT 系统支持所需数据交换级别至关重要 信任使用较少的管理开销即可启用自治信息系统之间的安全身份验证和数字身份授权 信任机制复杂化的原因是很多任务必须发生在独立组织之间, 以使身份验证和后续授权过程有用 信任组织需要具有安全机制以与受信任组织通信 在信任组织对外部数字身份进行身份验证之后, 它必须将有关该外部帐户的权利信息并入到信任组织内的授权过程中 联合 联合是在不同组织之间建立的超出内部网络界限的一种特殊信任关系 联合根据信任主体启用自治信息系统之间的安全身份验证和数字身份授权 例如, 公司 A 的用户可使用公司 B 提供的信息, 因为在两个公司之间存在联合信任关系 [ 注意 ] 联合包括不断完善的规范的实现, 例如 WS 联合, 最早由微软和 IBM 确立, 可将公司对跨组织边界分布的分散身份验证和授权系统中的用户和计算机标识的共享方式标准化 有关 WS 联合身份验证的详细信息, 请参见 microsoft.com/china/msdn/library/webservices/webservices/ws- Federation.mspx?mfr=true 联合的用途是解除在多个地方管理的帐户的需要 在联合中, 一个组织的用户可使用其常规网络帐户对另一组织管理的资源直接进行验证 这一点很流行, 因为它解除了管理多个不同帐户的要求 ( 或者至少使要求更容易满足 ) 假设有一个与一百个不同的合作伙伴有业务往来的组织 联合的替代方法是指组织使用委派管理接口在一百个不同合作伙伴的 Extranet 上管理帐户 通过该示例可明显看出, 某些技术 ( 如委派管理 ) 并不适合于连 44

45 身份和访问管理指南解决方案基本概念 接复杂的业务环境 可靠安全地联合数字身份对增加商 机至关重要 支持 : 采用微软技术的信任和联合 Microsoft Windows 通过以下技术为信任和联合提供 安全审核 部信任 Windows Server 2003 R2 中的 Active Directory Federation Service (ADFS) 审核提供了监视访问管理事件及目录对象更改的方 法 安全审核通常用于监视出现问题或违反安全性的事 件 Windows NT 4.0 和 Windows 2000 Server 中的外 Windows Server 2003 中的跨林信任 Kerberos 版本 5 身份验证协议 影子帐户 PKI 信任 采用微软技术的安全审核 Microsoft Windows 提供了安全事件日志用以记录引 人关注的安全事件, 如 : 身份验证事件 授权事件 更改目录对象 Microsoft Operations Manager (MOM) 2005 SP1 可合 并环境中的事件日志并提供有用的审核报告 增加管理成本, 并且常常会产生新的攻击面, 导致出现安全漏洞 集成应用程序集成应用程序需要大量工作, 但此集成过程却会带来高投资回报率 (ROI) 在应用程序本身具有身份验证系统的情况下, 如果组织要将应用程序完全集成到身份验证过程, 则唯一方式就是重新设计该应用程序, 使之与平台一起使用 因此, 为确保应用程序与身份和访问管理框架的兼容性, 组织的软件开发生命周期 (SDLC) 方法必须包括明确标准, 规定应用程序如何使用标准平台的身份验证和授权功能 有关使用微软技术集成应用程序的详细信息, 请参见后文第 7 章 应用程序 总结 图 2 列出了身份和访问管理框架中的所有过程和服务 应用程序 通用的业务应用程序是身份和访问信息的最终使用者 因此, 它们应与身份和访问管理平台相集成 应用程序常常通过 API 与框架的身份验证和授权组件集成 无法集成的应用程序会增加环境的复杂性, 从而 图 2: 身份和访问管理框架中的所有过程和服务 45

46 微软安全指南 1 身份和访问管理指南解决方案基本概念 第 4 章 : 目录服务 目录服务在任何身份和访问管理策略中都是中心组件, 原因有几个, 其中最重要的原因是, 目录服务是存储服务器操作系统身份及身份验证信息的最常用方式 目录服务不仅仅存储用户信息 它还会存储有关资源 计算机和应用程序的身份信息, 因为安全策略也必须应用于这些资产 通过将身份与身份验证和授权功能相结合, 登录身份验证和资源授权便都可以用目录来进行管理 Active Directory Microsoft Active Directory 目录服务是一种安全 高可用的分布式中央身份存储, 它与 Windows 2000 Server 和 Windows Server 2003 紧密集成在一起 Active Directory 在管理和支配用户帐户 身份验证 安全策略和组织资源 ( 如计算机 打印机和服务器 ) 方面起着核心作用 管理用户身份和控制用户对多个系统和平台上各种资源的访问是 Active Directory 独有的功能 利用此功能, 组织能够将 Active Directory 用作可以延伸到其他应用程序 系统 平台的权威身份 身份验证及授权信息存储 在 Active Directory 中管理用户权限 通过将 Active Directory 用作用户身份的目录服务, 组织可以利用业界领先的功能来管理 用户访问权限 此集成解决了先前指明的以下主要身份和访问管理难题 : 安全性 只用一个步骤就可以实现对整个网络上用户访问权限的更改, 从而降低不 经意为敏感信息敞开后门的几率 管理复杂性 对于每位用户, 均有一个可以管理权利和凭据的位置 而且, 此方 法简化了用户访问, 因为只需一个登录名和密码就可以访问网络及其中的所有资源 成本遏制与工作效率 通过采用单个系统来管理组和角色, 可以避免网络管理员在 各个系统及应用程序上授予和监视权限的重复工作 46

47 身份和访问管理指南解决方案基本概念 组策略 可以在 Windows Server 2003 和 Windows 2000 Server 中 使用组策略为多组用户和计算机定义并实施用户及计算机 配置 利用组策略, 组织可以指定以下方面的策略设置 : 基于注册表的 Windows 操作系统及组件策略 本地计算机 域和网络安全设置 ( 如密码及帐 户策略 ) 的安全选项 用于集中管理应用程序的添加 更新和删除的 软件安装及维护选项 组策略提供了组织范围的策略设置控制, 有助于在 降低管理工作强度和支持成本的同时提高安全性 使用目录服务标记语言 通过目录服务标记语言 (DSML), 可以将目录结构信 息和目录操作表示为 XML 文档 DSML 旨在使基于 XML 的应用程序能够在其本机环境中使用目录中的配置文件 和资源信息 DSML 使得 XML 和目录可以配合工作, 并 且为所有基于 XML 的应用程序奠定了共同的基础, 以使 它们都能更好地利用目录 用于 Windows 的 DSML 服务使 Windows Server 2003 操作系统上的 Active Directory 服务变得更为强大 由于 用于 Windows 的 DSML 服务使用开放标准 ( 如 HTTP XML 以及简单对象访问协议 (SOAP)), 因此可以实现更 高级别的互操作性 例如, 除了已成为标准的轻型目 录访问协议 (LDAP), 许多设备和其他平台还有与 Active Directory 通信的备选方案 此方法为 IT 管理员和独立软 件供应商 (ISV) 提供了许多主要好处, 他们现在有更多用 于访问 Active Directory 的开放标准可供选择 用于 Windows 的 DSML 服务支持 DSML 版本 2 (DSMLv2), 它是一个经结构信息标准促进组织 (OASIS) 批准并受到许多目录服务供应商支持的标准 通过支持 DSMLv2 规范可以与同样支持这个标准的其他目录服务供 应商实现更好的互操作性 有关 DSMLv2 规范和架构的 信息, 请参阅 OASIS 网站 要获得用于 Windows 的 DSML 服务, 请参阅 Microsoft.com 上的 Windows Server 2003 功能包下载页面 Active Directory 应用程序模式 诸如 Active Directory 的网络目录是存储相对静态 全局适用数据的合适地方 当组织或开发人员需要存储 应用程序特有的身份相关信息或需要对数据进行本地控 制时, 他们可以受益于一种称为 Active Directory 应用程 序模式 (ADAM) 的新的 Active Directory 模式 在部署需要目录结构但不大适合 Active Directory 环 境的应用程序时, 因以下一个或多个要求而会产生种种 问题,ADAM 解决了其中的许多问题 : 存储个性化数据 存储需要频繁更新的数据 支持启用了目录的应用程序, 它们需要从多个 林结构或另一不同组织 ( 如 OU 结构 ) 聚合配 置文件数据 启用目录迁移 有关这些方案中 ADAM 的详细信息, 请参阅本指南 第三部分第 2 章 Intranet 访问管理的方法 ( 见 105 页 ) 您可以更多地了解 ADAM 并从 Windows Server 2003 Active Directory 应用程序模式页面下载它 参考资源 Windows Server 2003 Active Directory 应用程序模式 Windows Server 2003 功能包 组策略特性集的渐进指南 47

48 微软安全指南 1 身份和访问管理指南解决方案基本概念 第 5 章 : 身份生命周期管理 多数组织都必须处理多个身份存储区 只要网络环境中使用多个位置存储数字身份, 就会随之产生有关如何管理多个身份的问题 身份生命周期管理涉及了在遵守管理策略的前提下置备 取消置备 管理和同步数字身份的过程和技术 身份和访问管理的成功与否主要取决于对数字身份生命周期的管理效率 身份生命周期管理服务是为进行安全主体创建 属性管理 同步 聚合和删除而提供 此外, 您必须通过全面的审核追踪安全地完成这些操作 本章将介绍微软产品如何满足这些要求 身份集成 身份集成 (IdI) 服务可链接多个目录 数据库以及其他身份存储区中的身份信息 这些服 务为用户提供了统一的视图, 并且可以跨多个存储区实现身份的置备和取消置备 置备 管理数字身份生命周期的中心问题是, 要确保可以在 Active Directory 维护的中央身份存储区以及没有与 Active Directory 完全集成的应用程序的其他身份存储区中添加和删除安全主体 此场景通常称为 雇用 / 解雇 场景 向置备过程添加工作流 身份置备经常需要与组织的运营过程联系到一起 例如, 如果雇用了一名新员工, 该员工的经理可能需要对身份置备过程进行批准 有三种主要方法可将工作流添加到置备机制中 MIIS 2003 SP1 规则扩展 可使用 MIIS 2003 SP1 规则扩展实现简单的由工作流驱动的 置备过程 然后, 所连接数据库中的状态变更 ( 如在人力资源 (HR) 应用程序中 ) 可以启动一个自动化的置备序列 MIIS 2003 SP1 中的规则扩展可控制相应身份存储区中数字身份的创建过程 不过, 此机制不允许任何的手动批准过程 48

49 身份和访问管理指南解决方案基本概念 简单工作流 还可以选择实现一个简单的工作 流应用程序, 它可能使用一个基于 Web 的界 面, 该界面允许在自动置备过程中执行手动的 工作流步骤 该选项可能包括新员工需要经理 批准这种场景, 不过, 经理只能批准他们自己 管辖的新员工 当 HR 部门创建新员工帐户时, 他们会输入经理的详细信息, 以便向相关经理 发送一封通知电子邮件 当该经理登录到网站 时, 他们就会看到待批准的新员工名单 进行 批准后, 将在所有相关的身份存储区中创建新 用户帐户 Microsoft BizTalk 2004 编排 BizTalk 2004 编排 针对复杂的异类环境提供了高级工作流功能 置备影子帐户 第 6 章 ( 访问管理, 见 50 页 ) 中介绍了如何 将影子帐户用作在两个其他情况下不信任的领域之间创 建信任度的替代方案 要维护此机制并保证其稳健性, 最好将不同领域间影子帐户的创建和删除过程自动化 MIIS 2003 SP1 是用于影子帐户置备和同步的卓越工具 自助服务 普通用户能够管理其自身目录属性的某些子集是降低身份管理成本的关健因素 微软产品通过在 Active Directory 中对属性级别的详细授权间接提供此功能 许多微软客户都使用 Visual Studio.NET 开发了自己的界面 ( 通常为网页 ) 以供用于自助式属性修改 对于想要购买现有产品的客户, 微软合作伙伴提供了允许用户自我管理某些属性信息的易于使用的 Web 界面 凭据管理 不同的身份验证机制通常使用不同的凭据 ( 例如 x. 509 证书 Kerberos 身份验证协议密码和 Microsoft Passport 密码 ), 因此任何提供多种身份验证机制的平台都应该为用户提供管理其多种凭据的功能 在 Windows 中, 此功能称为 Windows 凭据管理器 Windows 凭据管理器为最终用户提供了对凭据进行缓存处理并将其与特定位置相关联的能力 例如, 可在不同的网站使用不同的 Microsoft Passport 帐户, 并且可标识用于不同 Web 应用程序的不同证书 委派管理 身份生命周期管理包括委派对 Active Directory 中维 护的数字身份某些方面的管理能力 可通过选择的界面 使用 Active Directory 中内置的精确访问控制来实现 如果该架构具有一个针对 Active Directory 对象访问控制列表 (ACL) 的正确配置的授权策略, 微软管理控制台 (MMC) 管理单元将提供一种方法以用于委派对 Active Directory 中任何对象的管理, 包括代表数字身份的用户帐户 另一种受欢迎的管理界面选择是创建一个可实现帐户和属性管理的与 Active Directory 集成的 Web 应用程序 专门致力于访问管理的微软合作伙伴通常会在其产品中加入此功能 密码管理 许多环境中所包含的系统和应用程序都无法与 Windows Server 2003 和 Active Directory 中的安全功能轻松集成 这些系统通常依赖于不同的身份验证协议或使用单独的身份存储区进行身份验证 然而, 其中许多系统都使用密码进行身份验证 通过置备和同步帐户以及管理与其他系统中所用的帐户和密码共同用于登录 Active Directory 的凭据 ( 密码 ), 有可能改善用户体验 ( 尽管也可能随之增加受到攻击的可能性 ) 借助 MIIS 2003 SP1, 您可管理其他系统的帐户和 参考资源 Identity Integration Feature Pack 1a for Microsoft Windows Server Active Directory 功能包 49

50 微软安全指南 1 身份和访问管理指南解决方案基本概念 密码, 尤其是其他目录系统和身份存储数据库 该产 品提供了与最常用目录和数据库相集成的连接器, 简化 了密码管理机制的部署过程 MIIS 2003 SP1 以下列方式 支持密码管理 : 帮助台重设 帮助台人员通过随 MIIS 提供的 Web 界面重新设置用户密码 可以将密码变更 配置为流向 Active Directory 和 MIIS 2003 SP1 支持 的其他目录以进行密码管理 通过 Web 进行更改 用户通过一个基于 Web 的 共用的密码更改应用程序更改密码 然后, 密 码被分发到所有受 MIIS 支持的目录和系统, 包 括 Active Directory 通过 Windows 进行更改 用户通过基于 Windows 的客户端计算机上的 更改密码 对话框来更 改密码 Active Directory 密码通知筛选器获取更改的密码后, 再通过 MIIS 2003 SP1 将其分发到其他系统 此工具目前还未内置于 MIIS 2003 SP1 中, 但可使用 Visual Studio.NET 通过自定义编码实现它, 如本指南第 93 页 密码管理 一节中附带的示例所示 通过其他系统进行更改 用户通过非 Windows 操作系统更改密码 通过受操作系统支持的机制获得密码, 然后通过 MIIS 2003 SP1 将其分发 只有使用与 Active Directory 或 MIIS 2003 SP1 相集成的非微软应用程序时才支持此功能 无论采用哪种密码管理系统, 只有该系统易于使用并且用户了解如何访问它, 您才能从中受益 50

51 身份和访问管理指南解决方案基本概念 第 6 章 : 访问管理 访问管理由一些进程和技术组成, 这些进程和技术用于控制并监视符合管理策略的资源 的访问 访问管理包括 : 身份验证 授权 信任和配合 安全审核 身份验证 在微软身份和访问管理平台中,Microsoft Active Directory 目录服务是建议用来存储身份信息的技术, 其中包括在身份验证进程中用来验证用户凭据的加密密钥 与 Microsoft Windows Server 2003 Microsoft Windows XP Professional 及 Windows 安全服务相集成的应用程序使用操作系统的内置功能来执行身份验证 Windows 身份验证服务 逐个应用程序地实现身份验证协议不仅效率非常低, 而且有可能会将安全漏洞引入组织 一个更为有效的办法是使用 Windows 平台中的身份验证机制来构建应用程序 为取得最佳效果, 在开始设计应用程序之前, 开发人员需要了解不同的身份验证类型 使用不同协议的结果以及这些协议所支持的接口 Windows 身份验证服务体系结构 Windows Server 2003 和 Microsoft Windows XP 具有一套完整的身份验证方法和安全协议, 可满足许多应用程序身份验证需求 Microsoft.NET Passport 通过证书或智能卡进行的公钥身份验证及用户名 / 密码组合都根据不同的凭据需求提供了不同的用户体验, 并且各自都有着不同的安全特征 数据传输机制还可以定义您能够使用的身份验证协议 51

52 微软安全指南 1 身份和访问管理指南解决方案基本概念 身份和访问管理平台中用于身份验证服务的安全系统的层级结构如下 : 从提供较高灵活性和控制能力的较低级别接口向具有较低灵活性但应用程序编程接口 (API) 更为简单的高级别接口扩展 图 1 显示了身份验证协议和应用程序 API 的层级结构 在图 1 中身份验证堆栈的顶部, 高级别 API 和服务提供进程间通信 (IPC) 机制, 这种机制用于为传输应用程序数据提供经过验证的安全通道 这种服务和 API 包括分布式组件对象模型 (DCOM) 远程过程调用(RPC) Microsoft ASP.NET ASP WinInet 等等 Microsoft RPC 是一种强大 高效而又安全的 IPC 机制, 这种机制支持进行数据交换及调用驻留于另一进程中的功能 该进程可以位于同一台计算机上 局域网上或 Internet 中 WinInet 是用于支持 Internet 安全协议 [ 例如 Internet 协议上的安全套接字层 (SSL)] 的一种应用程序协议接口 实现 WinInet 安全支持时, 面向安全通道 (SSL 的 Windows NT 实现 ) 安全提供程序采用安全支持提供程序接口 (SSPI) 有时, 应用程序开发人员可利用这些服务所面临的 API 来全面控制身份验证的执行和数据的保护 例如, DCOM API 允许开发人员选择特定的身份验证协议, 如 Kerberos 协议或 NT LAN Manager (NTLM) 质询 / 响应 它图 1: 身份验证协议和应用程序 API 的层级结构 也会指定是否应将数据签名 ( 防止攻击者更改数据 ) 或加密 ( 防止窃取者查看数据 ) 而其他服务和 API 只受系统配置影响 最能说明这一点的是 ASP.NET, 它被托管于运行 Microsoft Internet Information Services (IIS) 6.0 的服务器上, 而后者可配置为针对特定情况使用合适的身份验证机制 安全支持提供程序接口用于身份验证的最低级别应用程序接口是 SSPI, 它是微软版本的通用安全服务 API (GSS-API) 有关 GSS- API 的详细信息, 请参见 因特网工程工作组 (ITEF) 请求注解网站上的 RFC 1508 和 1509 有关 SSPI 的详细信息, 请参考 com/china/windows2000/library/howitworks/security/ sspi2000.asp SSPI 和 GSS-API 所暗含的理念是两方的网络身份验证通常遵循共同的模式 各方需要按一定的顺序交换一条或多条信息 既然它们可以从众多不同网络协议 [ 超文本传输协议 (HTTP) RPC 服务器消息块(SMB) Internet Inter-ORB 协议 (IIOP) DCOM Java 远程方法调用 (RMI) 等 ] 中选择一种进行通信, 因此最好不要将单一的身份验证握手进程硬编码到网络协议自身之中 更好的办法是提供产生 身份验证令牌 的通用接口, 这些验证令牌其实只是代表身份验证序列某个方面的二进制数据结构 这些令牌会通过任何所使用的应用程序协议进行交换 例如, 在 RPC 中, 已使用握手进程来同步客户端和服务器之间的协议 RPC 只是在此握手进程中为任意大小的不透明身份验证令牌提供空间 SSPI 和 GSS-API 所执行的大部分工作是生成和评估这些令牌 如前面所述,Windows Server 和客户端操作系统实现了许多种身份验证协议 这些协议是由本地安全授权服务所加载的 DLL 文件组成的 安全数据包 ( 有时称为身份验证数据包 ) SSPI 是随附于 Windows Server 和客户端操作系统的所有安全数据包的接口 这些安全数据包通常实现一项网络身份验证协议, 如 52

53 身份和访问管理指南解决方案基本概念 Kerberos 版本 5 身份验证协议 NTLM 质询 / 响应 摘 要身份验证 安全套接字层 (SSL) 或传输层安全 (TLS) 应 用程序可以使用这些协议与用于身份验证的 Active Directory 进行安全无缝的集成, 还可以使用协议的功能来保 证应用程序数据的安全 安全协议协商 (SPNEGO) 是根据需要在身份验证协议 之间进行协商的特殊安全数据包 对于使用 SSPI 和 Kerberos 版本 5 协议或 NTLM 的应用程序而言, 最好使 用 SPNEGO 数据包而不要直接使用这些协议 有关 SPNEGO 的详细信息, 请参见 MSDN 上的 Windows Security( 英文 ) 页面 Kerberos 身份验证 Kerberos 版本 5 身份验证协议的说明请参见 请求 注解 网站的 IETF RFC 1510 页面 此协议具有极大的 安全性和可伸缩性, 因此非常适合于在集成的网络环境 中进行身份验证 在运行 Microsoft Windows 2000 Server 或其更高版 本的 Windows 服务器和客户端中,Kerberos 版本 5 身份 验证协议是 Active Directory 身份验证的基础 在 SMB HTTP 和 RPC 以及使用这些协议的客户端和服务器应用程 序中也集成了此协议 Windows 平台为用户提供了对此 强大的安全工具的无缝集成体验 Kerberos 版本 5 协议对于微软身份和访问管理平台 非常重要, 因为它基于一个开放的标准 许多其他供 应商也已在麻省理工学院 (MIT) 实现 Kerberos 版本 5 协议 的基础上实现了该协议, 从而使微软和非微软平台及应 用程序之间实现身份验证的互操作性成为可能 Windows 有两种配置 Kerberos 版本 5 协议实现互操 作性的方法 : 可以在 Windows 域和基于 MIT 的 Kerberos 版本 5 协议领域之间建立信任关系 这种关系可以让 此领域中的客户端通过信任机制验证到 Windows 域中的网络资源 非 Windows 客户端和服务器可以使用 Active Directory 帐户从域控制器获得身份验证 在 Intranet 中, 在 Windows 平台上实现 Kerberos 版 本 5 协议可以使用户获得 SSO 功能, 这是由身份验证协 议的基本特征和协议在 Windows 客户端及服务器操作系 统中实现方式的具体特性而决定的 阻碍 Kerberos 版本 5 协议成为应用程序身份验证和 安全的通用解决方案的一个最主要限制是, 无法将 Kerberos 身份验证配置为在 Internet 上使用 个中原因 将在 55 页的 Web 单一登录 一节详细探讨 有关 Kerberos 版本 5 身份验证协议的详细信息, 请 参见 Microsoft TechNet 上的 Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability( 英文 ) 页面 安全套接字层 3.0 和传输层安全 1.0 SSL 3.0 和 TLS 1.0 协议紧密相关, 可用来解决两个 应用程序之间通信通道的一般安全性问题 SSL 3.0 是一 个专利的 Netscape 通信协议, 而 TLS 1.0 是 请求注解 网站上的 IETF 标准 RFC 2246 定义 两个协议很相似, 但 TLS 有一些重要的改进, 因此微软建议尽可能使用此 协议 TLS 和 SSL 均支持在建立安全数据通道期间进行服 务器身份验证, 也允许选择进行客户端身份验证 SSL 和 TLS 协议常用于在 HTTP 协议上提供数据保护 和集成 ( 加密 ) 其他协议也支持 SSL 或 TLS 例如, 轻型目录访问协议 (LDAP) 与 SSL 合并后产生了 SSL 上的 LDAP, 即 LDAPS 此外, 自定义或第三方应用程序可 以通过 SSPI 直接使用 SSL 或 TLS, 并指定 SChannel 安全 数据包 SSL 和 TLS 采用对称加密密钥基于证书和安全数据传 输进行身份验证 在 Internet 上, 组织通常使用 SSL 和 TLS 进行服务器身份验证 客户端在 SSL 和 TLS 中通过核 对下列条件来验证服务器 : 服务器证书有效 经证实, 服务器拥有与服务器的 X.509 证书相关 的相应私钥 所验证的服务器即为证书中所指定的服务器 SSL 和 TLS 也支持客户端身份验证并通过 X.509 客户 端证书将其集成于 Windows Server 2003 平台 同时进 行客户端和服务器身份验证通常称为相互身份验证 为 完成客户端身份验证, 客户端会出示有效的客户端证 书, 服务器会根据与服务器身份验证相同的条件进行衡 53

54 微软安全指南 1 身份和访问管理指南解决方案基本概念 量 Windows Server 在确认客户端证书有效后, 会将其映射至 Active Directory 帐户 对于证书的映射方式, Active Directory 有着很大的灵活性, 既允许一对一映射, 也允许多对一映射 在使用 X.509 数字证书进行身份验证时,SSL 和 TLS 比其他身份验证协议有着更高的安全性 [ 注意 ] SSL 和 TLS 在 Windows XP 客户端上通过 Windows 凭据管理器为用户提供 Web SSO, 这一点将在本章稍后部分介绍 Passport 身份验证 Microsoft Passport 是一种 Web 服务, 它基于庞大的数字身份数据库来验证用户 个人可通过某个安全网站来维护其 Passport 身份 Passport 在许多网站启用了身份验证和 Web SSO 功能, 许多微软网站和一些不属于微软的站点都在使用 Passport 开发人员可以创建链接到 Passport 的应用程序, 使应用程序仅接受来自已注册 Passport 用户的连接 如果 Passport 确定用户的凭据有效, 就会返回一个身份验证票证, 应用程序可以通过将其解密来确定用户的身份 为保护隐私, 典型的 Passport 身份验证只将一个 Passport 唯一 ID (PUID) 传送给相关的应用程序 通常, 应用程序随后会将此 PUID 映射至本地维护的用户帐户, 以派生在组织中有效的数字身份 若选择 IIS 6.0 中的 Passport 身份验证配置选项,Windows Server 2003 则与 Passport 完全集成 此外, 还可将 Passport 用户映射至 Active Directory 帐户, 使 Passport 身份验证能与 Windows 安全模型完全集成 对于面对 Internet 的应用程序,Passport 身份验证为用户提供了 SSO 体验 这是通过提供在 HTTP cookie 中编码的身份验证票证实现的 引入 Cookie( 在浏览器会话的生命周期内维护 ) 后, 用户不必重复登录至 Passport 身份验证服务即可验证到多个应用程序 有关 Passport 的详细信息, 请参加 MSDN 上的 Passport 身份验证提供程序 ( com/library/chs/default.asp?url=/library/chs/cpguide/html/ cpconthepassportauthenticationprovider.asp) 一文 摘要身份验证摘要身份验证是 请求注解 网站上 RFC 2617 中介绍的另一个基于标准的身份验证协议, 它作为一个验证数据包而包含于 Windows Server 2003 之中 摘要身份验证主要用来在 Windows 和非 Windows 平台之间实现 Internet 身份验证的互操作性 Windows Server 2003 也将摘要身份验证作为一个简单的身份验证和安全层 (SASL) 机制来实现 ( 如 请求注解 网站的 RFC 2831 中所述 ) SASL 是应用程序和底层协议之间的另一个抽象层, 通过它可以在不更改应用程序的情况下轻松引入不同的身份验证机制 在某些方面, 它与前面所讲的 SPNEGO 机制很相似 SASL 主要用于 LDAP 身份验证中 摘要身份验证与 NTLM 专利协议有着相似的安全特征 摘要身份验证与 NTLM 均为质询 / 响应协议, 需要验证服务器来生成包含一些不可预知数据的质询 随后客户端使用派生自用户密码的密钥将质询加密, 从而形成响应 服务器或者受信任的第三方服务 ( 例如 Active Directory) 可将客户端的响应与根据身份存储中用户的相关凭据所计算出的值进行比较, 来检查用户是否拥有正确的密码 如果响应与算出的值相符, 则认为用户知道安全密码并通过身份验证 一般而言, 摘要身份验证不如 Kerberos 版本 5 协议那么安全, 因为它依靠强密码来阻止对质询 / 响应机制的攻击 但由于明文密码在身份验证期间不会出示给服务器, 因此摘要身份验证要比基于表单的身份验证或基本身份验证更可靠 SSL 和 TLS 经常用来保护摘要身份验证免遭攻击 大多数情况下, 摘要身份验证的可伸缩性不如 Kerberos 版本 5 协议, 但它可以用在无法应用 Kerberos 协议的场合, 例如验证到面向外部的网站 摘要身份验证提供 SSO 只是为了保护通过一个 Web URL 得到的信息 如果用户导航至另一个站点, 或者导航至同一站点中不同的服务器, 通常必须要再次输入他们的凭据 54

55 身份和访问管理指南解决方案基本概念 基于表单的身份验证基于表单的身份验证依靠 Web 页面中的登录表单来收集用户凭据, 其形式基本只有明文用户名与密码这一种 因此, 这类身份验证与我们前面介绍的 Kerberos 版本 5 协议和摘要身份验证不同, 它并不是客户端和服务器之间的身份验证协议 基于表单的身份验证需要万分小心, 才能有力地保护支持它的应用程序, 因此微软建议在没有 SSL 的情况下不要使用这种身份验证方式 在使用基于表单身份验证的应用程序中存在着一个很大的漏洞, 攻击者会利用它来搜集明文密码数据, 这将严重威胁整个组织的应用程序数据及网络自身的安全 因为执行基于表单身份验证的应用程序以明文形式接收用户凭据, 所以应用程序可以选择根据用户存储而不是 Active Directory 进行身份验证 微软建议在大多数情形下不要使用这种方法, 因为附加的身份存储会使身份和访问管理解决方案复杂化 实现基于表单身份验证的应用程序开发人员在以 Active Directory 方式验证用户时, 最好使用 LDAP 绑定或 LogonUser() 这样的 Windows API 来确认用户凭据, 也可以生成一个安全上下文 ( 将在下节 基本身份验证 部分加以说明 ) 实现基于表单的身份验证的应用程序通常会使用 HTTP cookie 或 URL 修改来为用户提供 SSO ASP.NET 提供了保护 cookie 的功能, 利用加密技术防止有人未经授权读取 cookie, 利用数字签名防止有人对 cookie 进行更改 在本指南的 开发可识别身份的 ASP.NET 应用程序 一节中 ( 见 94 页 ), 详细介绍了开发人员应如何在 Windows 平台上使用基于表单的身份验证 基本身份验证与基于表单的身份验证一样, 基本身份验证并非真正的网络身份验证协议, 因为在验证到网络资源时它并不以加密的方式来保护用户的凭据 与基于表单的身份验证一样, 执行此类身份验证的服务器以明文形式接收用户凭据, 然后使用 Windows API 验证用户 与基于表单的身份验证的另一点相同之处是, 部署此类身份验证技术的开发人员和系统管理员必须付出巨大的努力来 保护应用程序或服务器免遭危害 因此, 微软强烈建 议在没有 SSL 的情况下不要使用基本身份验证 基本身 份验证与摘要身份验证具有相同的 SSO 特征 单一登录 任何关于身份验证的探讨都少不了一个概念, 即单 一登录 (SSO) 在身份验证进程中实施 SSO 的方式有多种 : 桌面集成的 SSO Web SSO 凭据映射和企业 SSO SSO 完全省去了额外输入用户凭据的过程, 也意味 着不必再去判断其中所涉及的身份验证安全级别 出于 安全性考虑, 有一些 SSO 类型可能比其他的更好一些 此外,Extranet SSO 和 Intranet SSO 这两个术语是 指在 Extranet 或 Intranet 情况下实现 SSO 时所采用的技 术 Extranet SSO 通常基于 Web, 而 Intranet SSO 可以 涉及许多类型的应用程序和服务, 其中包括 Web 应用程 序 胖客户端应用程序和终端会话 桌面集成的单一登录 安全登录要求用户向网络提供他们身份的证明, 但 是以反复键入密码的方式访问多个资源会令用户感到厌 烦 Microsoft Windows 平台利用单一登录功能, 在整 个网络中使用单一用户身份 ( 在 Active Directory 中维 护 ) 由于用来登录到工作站的凭据往往就是用来访问 网络资源的凭据, 因此用户的登录凭据 ( 用户名和密码 组合 ) 会被缓存到客户端操作系统的 本地安全授权 (LSA) 中 用户登录到域中后, 在验证到网络资源时, Windows 身份验证会使用所缓存的凭据来提供 SSO 为保证良好的安全性, 需要用户提供一个经过验证 的身份来访问网络资源 通过 SSO, 用户只需经过一次 系统身份验证即可访问他们有权使用的所有应用程序和 数据源, 而不必再输入另一个帐户 ID 或密码 Kerberos 版本 5 身份验证协议 NTLM 和智能卡身 份验证技术均与微软客户端及服务器操作系统中的桌面 登录进程相集成, 从而为组织 Intranet 中 Windows 域或 Windows 林内的用户提供 SSO 体验 Active Directory 提 55

56 微软安全指南 1 身份和访问管理指南解决方案基本概念 供了受信任的第三方, 使服务器无需本地存储每个用户 的相关信息即可验证用户 Windows Server 2003 中的高级信任机制 ( 例如跨 林信任 ) 允许某个林结构中的身份在访问其他林结构中 的资源时享用 SSO Web 单一登录 由于越来越多的公司都在部署由员工 合作伙伴和 客户所使用的基于 Extranet 和 Intranet 的 Web 应用程序, 因此为用户提供 SSO 体验的能力就变得非常重要 Web 应用程序与传统的 胖 客户端 / 服务器应 用程序不同, 它们通常依靠 Web 服务器实现身份验证 这种依赖性既使得人们可以通过常用的方法将身份验证 机制添加到单一应用程序 (Web 服务器 ) 中, 同时又 解决了众多服务器托管的应用程序的身份验证问题 在 Intranet 环境中, 微软的服务器和客户端产品通过在 Internet Explorer 和 IIS 6.0 中实现 Kerberos 版本 5 身份验 证协议来提供 Web 单一登录或 Web SSO( 如本指南第 三部分第 2 章 Intranet 访问管理的方法 所述 ) 不幸的是, 在 Intranet 环境中行之有效的 Kerberos 实现对于组织 Extranet 中用于面向 Internet 的应用程序却 束手无策 Intranet 和 Extranet Web SSO 之间的差异是 由以下三个因素的综合作用造成的 : 部署面向 Internet 的 密钥分发中心 (KDC)( 例 如 Active Directory 域控制器 ) 时一直以来所面临 的困难 许多浏览器在 HTTP 上不支持 Kerberos 身份验证 KDC 协议中固有的漏洞 详细讨论部署面向 Internet 的 KDC 时所一直面临的 困难并不属于本文的研究范围, 然而对部署而言这一问 题的确是一个很大障碍 第二个问题对 Extranet 部署的影响通常更为明显 与内部部署不同, 软件标准在内部是强制执行的, 然而 没有组织能够规定外部客户和业务合作伙伴在访问外部应 用程序时使用哪个类型和版本的浏览器软件 Microsoft Internet Explorer 6.0 及更高版本是市面上唯一能够买到的 支持在 HTTP 上进行 Kerberos 身份验证的浏览器 解决多个 Web 应用程序 SSO 问题的标准方法是利用会话 cookie ( 在 HTTP 状态管理机制中介绍 在 请求注解 网站上由 IETF RFC 2109 定义 ) 一些独立软件供应商 (ISV) 提供了用于跨 Extranet Web 应用程序实现 Web SSO 的解决方案 对于支持 Passport 身份验证的站点, 前面部分详细介绍的 Microsoft Passport 服务也为用户提供了 SSO 体验 Web SSO 技术与企业 SSO 技术可以结合使用, 以包括 Web 组件的 SharePoint Portal Server 网站为例, 两者结合之后可以在唯一身份验证目录内访问旧版应用程序遗留的数据 在此例中,Web SSO 技术提供对网站的访问, 企业 SSO 技术则提供对旧版应用程序遗留数据的访问 凭据映射和企业单一登录 企业 SSO 是指采用凭据映射形式提供 SSO 体验的任何技术 其中, 凭据映射是一个要件, 因为身份验证中会涉及到各种不同的身份存储和目录 某项服务 ( 运行于客户端或服务器 ) 会代表帐户登录到目标应用程序, 模拟 SSO 体验 此服务必须从凭据映射存储库或数据库中查找合适的凭据 ( 帐户 密码等等 ) Microsoft BizTalk Server Host Integration Server SharePoint Portal Server Windows 凭据管理器以及来自 PassLogix Protocom 和 Version3 等 ISV 的产品都采用各种企业 SSO 技术来针对遗留系统和使用自身目录进行身份验证的应用程序实现 SSO, 甚至实现对不受信任的 Windows 域中资源的访问 许多组织都存在拥有多个非信任身份存储却没有实现 SSO 的现象, 与之相比 企业 SSO 能够提供更好的用户体验 企业 SSO 方法应与置备和密码管理方法相集成, 从而确保无缝的体验并最大程度减少帮助台的呼叫次数 这种方法也会在最大程度降低总拥有成本的同时提供最佳的用户体验 [ 注意 ] 桌面集成的 SSO 与选项目录紧密集成, 而且不需要置备和管理冗余目录和凭据映射数据库, 因此要优于企业 SSO 有关通过 企业 SSO 实现凭据映射的详细信息, 请参见 Intranet 访问管理的方法 ( 见 105 页 ) 56

57 身份和访问管理指南解决方案基本概念 安全配置进行比较来确定资源访问权的过程 例如, 用 户可以验证到文件服务器, 然后服务器可以确定用户是 否具有读 写或删除文件的能力 与 Windows Server 2003 操作系统及 Active Directory 相集成的应用程序使用操作系统的内置功能来执行授权 Windows Server 2003 支持两种授权机制 : 基于 Windows 访问控制列表 (ACL) 的模拟模型, 和基于角色的新授权管理器 此外,Microsoft ASP.NET 应用程序还可以使用 ASP.NET 角色进行授权 下面将详细讨论这两种机制 图 2: 存储的用户名和密码 支持多组凭据的 SSO Windows 凭据管理器 Windows XP Professional 和 Windows Server 2003 中 包括一项 存储的用户名和密码 功能, 它也提供凭 据管理功能 此组件可以根据所尝试的身份验证类型, 来保存用户凭据并在以后的访问尝试期间重新使用它们 如果应用程序不允许用户保存凭据, 用户则必须手 动访问 存储的用户名和密码 来设置该资源的凭据 凭据管理器支持以下类型的凭据 : Kerberos 版本 5 协议和 NTLM 身份验证的用户名 / 密码组合 使用 SSL/TLS 进行客户端身份验证的 X.509 数字证书 用于 Web 身份验证的 Microsoft Passport 凭据 [ 注意 ] 可以使用 Windows 凭据管理器在 SSL/TLS X.509 客户端 证书身份验证中提供 Web SSO 体验 默认情况下, 只要用 户拥有一个以上的有效证书, 就会看到提示选择身份验证证 书的消息 凭据管理器可确保在验证到特定资源时自动出示 适当的证书 有关 Windows 凭证管理器的详细信息, 请参见 Intranet 访问管理的方法 ( 见 105 页 ) 授权 授权是应用程序或平台通过将用户的权限与资源的 Windows 模拟和访问控制列表 Microsoft Windows NT 3.1 引入了模拟和 ACL 模型来为服务和应用程序提供授权 模拟是为实现无缝用户体验和便于管理而将身份验证和授权机制紧耦合的产物 身份验证数据包首先验证用户, 然后为该用户构建 安全上下文 安全上下文代表用户所属的身份和组以及用户的权限 一旦身份验证数据包生成安全上下文, 应用程序或服务即获得允许访问资源的安全上下文 换句话说, 服务在尝试访问资源时使用用户的安全上下文 ( 而非服务自身的上下文 ) 来获得访问权, 从而在本地模拟用户 这是一个很重要的概念, 因为大多数服务在计算机中都拥有广泛的权限 例如, 在运行 Windows 的服务器上提供文件和打印服务的服务器消息块 (SMB) 服务作为本地系统运行, 可以访问任何资源 要根据文件所有者或系统管理员所建立的规则来限制用户对文件的访问权,SMB 服务应模拟远程用户 Windows 授权模型的另一部分是基于对象的 ACL 对象的 ACL 用于定义对象的访问级别安全主体 ( 用户或组 ) 例如, 文件的 ACL 可以定义一个用户拥有读取某文件的权利而另一个用户拥有读取和删除该文件的权利 操作系统 ( 具体来说, 就是 NT 对象管理器 ) 是使用此模型访问对象时的最终仲裁者 NT 对象管理器 将用户的安全上下文与对象的 ACL 加以比较, 即可完成仲裁 由于操作系统是最终的仲裁者, 因此模 57

58 微软安全指南 1 身份和访问管理指南解决方案基本概念 拟 /ACL 模型在多个应用程序可以访问一个系统资源的场 合有着良好的安全性 然而, 模拟 /ACL 模型的某些方面还可以进一步改 进, 其中包括 : 性能 对于同时将内容传送给多个不同用户的 服务, 使用模拟来切换上下文会增加服务器的 负荷, 影响应用程序的可伸缩性 灵活性 使用模拟模型时, 应用程序开发人员 或服务管理员必须在域级别更改组成员身份才能 为用户创建新的组或角色 域管理员反对为一 个应用程序创建许多组供使用, 结果应用程序 开发人员只能利用目前现有的组进行工作 业务规则 模拟 /ACL 模型充分表现了对象的授 权, 却很难描述业务规则逻辑, 例如日期时间 或其他运行时逻辑 例如, 您可能希望实行一 种仅允许特定的人在特定时间执行特定动作的授 权策略 为克服这些问题,Windows Server 2003 中为系统管 理员和应用程序开发人员加入了 授权管理器 Windows 2000 版本的 授权管理器 可从 Microsoft.com 的 授权管理器概念 prodtechnol/windowsserver2003/zh-chs/library/serverhelp/ 1b4de9c6-4df9-4b5a-83e9-fb8d mspx?mfr=true 下载页面获得 Windows Server 2003 授权管理器 Windows Server 2003 中的 授权管理器 是新的 基于角色的访问控制 (RBAC) 接口 开发人员利 用 授权管理器 可以实现以下目标 : 简化应用程序访问控制管理 提供简化的自然开发模型 实现灵活而动态的授权决策 授权管理器 接口会针对特定的任务, 在应用程序内将用户通过各种角色组织在一起, 并在模拟这些角色的同时给予他们访问权 图 3 显示了访问某个应用程序的三个不同用户 授权管理器 将这些用户都映射到授权策略 存储库中所定义的角色 授权管理器 允许根据每个应用程序的需求来定义和维护逻辑角色及任务 这种根据组织结构表现安全模型的方式简化了访问控制管理 此外, 任务和角色的定义有助于为应用程序工作流建模, 并通过 授权管理器 为开发人员提供了一个自然的以应用程序为中心的环境 授权管理器 还动态地限定运行时所赋予的权限 这一功能解决了业务线 (LOB) Web 应用程序 ( 例如开支报告应用程序或基于 Web 的购物应用程序 ) 所存在的特殊授权问题 对于这样的应用程序, 根据既定永久对象的访问权往往不能做出授权决策, 而是要检查一个工作流程或一组多个不同的操作, 例如查询数据库和发送电子邮件消息 这样的访问决策不仅基于令牌组成员身份, 还基于业务逻辑, 例如在支出应用程序或工作流完成验证中提交的数量 这些没有既定永久对象的应用程序中没有放置 ACL 位置 这些动态访问决策采用 授权管理器 所提供的动态业务规则 ( 称为 BizRule) 形式, 易于使用 BizRule 通常使用在应用程序运行期间检查访问权时所执行的 Microsoft Visual Basic Scripting Edition 脚本或 JScript 例程来实现 如果 BizRule 成功, 应用程序将执行所请求的操作 用来定义应用程序所用逻辑角色和任务的授权管理器策略可以存储在 Active Directory 或 Active Directory 应用程序模式的应用程序分区中, 或者也可以存储在服务器或网络上的 XML 文件中 图 3: 授权管理器定义并应用角色的方式 58

59 身份和访问管理指南解决方案基本概念 有关使用 Windows Server 2003 授权管理器的 RBAC 的详细信息, 请参见 TechNet 上的 Authorization Manager Concepts( 英文 ) 页面 IIS 6.0 中提供了一个用于说明应用程序如何使用授权管理器基于角色的框架的示例 IIS 6.0 随附于 Windows Server 2003, 与 授权管理器 集成来实现 IIS 6.0 URL 授权 实现这一集成后,Web 应用程序管理员可以基于自定义用户角色 LDAP 查询和 BizRule 来控制 URL 的访问 采用在 IIS 6.0 中为用户访问 Web 页面进行授权的这种方式时, 可能需要在 Web 应用程序所用资源上管理许多自由访问控制列表 (DACL) Web 应用程序的资源可能包括 Web 页面文件 数据库记录和注册表项 要维护 DACL, 管理员必须确切地知道每个对象都需要哪些后端权限要求才能执行 Web 应用程序中的针对性任务 采用 IIS 6.0 URL 授权时, 管理员可以授予用户访问构成 Web 应用程序的 URL 的权限, 从而简化了访问管理 客户端请求某个 URL 时,IIS 6.0 URL 授权会根据用户的角色来验证用户的访问 必要时,Web 应用程序会使用授权管理器基于角色的框架来进一步限定对资源和操作的访问 ASP.NET 授权 ASP.NET 提供使用 Active Directory 组和应用程序派生角色的 基于角色的授权模型 授权管理器 RBAC 和 ASP.NET 基于角色的授权有着一些相似之处, 但它们通过不同的机制来实现 ASP.NET 角色对于不能归属到更大应用程序组中的独立应用程序最为有用 信任关系存在于定义了安全边界的不同领域之间 在 Windows NT 和 Active Directory 环境中, 可以在域之间建立信任 在 Windows Server 2003 中, 可以在林结构之间建立更高的信任级别 但林结构内部域之间的信任关系是隐含的 与 Windows Server 2003 及 Active Directory 相集成的应用程序使用操作系统的内置功能来建立和维护信任关系 管理信任关系 在较高级别, 信任关系只是提供了一种在领域之间进行身份验证的方法 但由于要使身份验证和后续的授权真正有意义就必须在领域之间执行许多任务, 所以信任机制会变得很复杂 本节的其余部分将介绍 Windows 平台中可以使用的信任类型, 以及如何使用它们来解决身份和访问管理问题 外部信任 Microsoft Windows NT Server 中引入了域信任的概念 Windows NT 域信任 ( 现称外部信任 ) 允许一个 Windows NT 域信任另一个 Windows NT 域, 将其视为一种特权来使属于该域的用户通过验证 外部信任既可以是单向的也可以是双向的, 信任的方向决定着身份验证和访问可以发生的方向, 如图 4 所示 Windows NT Server 4.0 模型非常灵活, 它允许各部门根据需要采用由下而上的基层部署模式来实现 Windows NT 4.0 域 其问题在于, 随着各大型公司引入越来越多的域, 管理外部信任关系逐渐成为一个严重的问 信任和联合 有时您可能需要链接两个或更多的不同身份存储库, 例如在您需要实现合作关系安排或使用不同的外部和内部目录结构时 这样链接后, 如果用户可以验证到一个身份存储, 那么即使他们在另一个身份存储中没有数字身份, 也能够验证到其中 这种安排称为 信任关系 图 4: 信任域和被信任域之间的关系 59

60 微软安全指南 1 身份和访问管理指南解决方案基本概念 题 因为每个部署的域都可能拥有众多的信任关系, 因此要管理的信任关系总数随着域数量的增加而迅速增加 拥有 4 个域的小型公司可能只需管理 12 个不同的信任关系, 而拥有 10 个域的较大型公司则可能需要管理 90 个信任关系 拥有 100 个域的公司要管理的信任关系可能要庞大得多 Windows 2000 Server 林为简化大型组织中的信任管理,Microsoft Windows 2000 Server 引入了 Active Directory 林的概念 Active Directory 林保留了 Windows NT Server 4.0 随需式由下而上信任模型的灵活性, 但却解决了执行自上而下信任管理的问题, 如图 5 所示 此图形表示一个拥有单一 Windows 2000 Server 林的组织 林结构内部的信任关系是隐含的, 其功能相当于双向外部信任, 但这些信任关系却是在域 ( 可看作图 5: 一个 Windows 2000 Server 林图 6:Windows Server 2003 林信任关系 林中的树 ) 被添加到同一个林时自动创建的 林结构内部的域是有层次的, 使组织的网络能够反映出组织的业务状况 遗憾的是,Windows 2000 Server 并没有最终解决信任关系问题 它基于大多数公司将在其整个网络和资源范围内部署单一林结构这种假设 然而, 众多原因决定了这种假设并不成立 例如, 一些庞大的组织并没有集中的信任管理小组来负责管理所有的组织资源 因此在这样的组织中, 必须实现目录服务体系架构的不同部分之间存在天然的安全边界 另一个常见的例子就是, 需要区分 Intranet 林和 Extranet 林 尽管开发人员可以将 Extranet 设计为 Intranet 林的一个域, 但是出于安全考虑, 许多组织还是希望 Extranet 和 Intranet 之间有更大程度的隔离 有关 Windows 域和林安全边界特征的详细信息, 请参见 Microsoft.com 上的 Windows Server 2003 安全性指南介绍 ( 对于 Windows 2000 Active Directory 有多个林却又希望在不同林的域之间使用信任关系的组织来说, 必须在不同林的各域之间建立显式信任关系 与在每个 Windows NT Server 4.0 域之间建立信任关系相比, 这种配置的实现只是稍微简单了一点点而已, 所以必须找到一种更好的解决方案 Windows Server 2003 林信任为简化多个林的部署,Windows Server 2003 建立了林信任的概念 林信任允许管理员通过单一信任关系将两个 Active Directory 林联合在一起, 在它们之间提供无缝的身份验证和授权体验 林信任是两个林的根域之间的单一信任链接 ; 它在每个林中的所有域之间建立起一种可传递的信任关系 例如, 如果 林 A 信任 林 B, 则通过 60

61 身份和访问管理指南解决方案基本概念 林信任, 林 A 中的所有域会信任 林 B 中的所有 域 图 6 说明了这一概念 但是, 林信任不会跨林传递 也就是说, 如果 林 A 信任 林 B 而 林 B 又信任 林 C, 林 A 并不会自动信任 林 C 使用林信任 林信任使 Windows Server 2003 中的联合林概念成为 可能 前面提过, 林信任允许在两个林中所有域之间 传递信任关系 ; 这种信任建立于两个林的根域之间 林信任既可以是单向信任, 也可以是双向信任 在图 6 中, 林 A 和 林 B 之间的信任关系是双 向的 因此, 林 A 中的用户可以验证到 林 B 中的资源, 林 B 中的用户也可以验证到 林 A 中的资源 除身份验证外, 林信任还启用了授权, 每 个林中的资源所有者可以将主体从另一个林添加到 DACL 和组中, 或者基于这些组创建角色 使用影子帐户代替信任 有时, 一些安全性要求会阻止在林之间使用 Windows 信任机制 这时, 可以在一个目录中创建影子帐 户来镜像另一个目录中的帐户 影子帐户通常只从源领 域镜像特定应用程序或应用场合所需要的身份信息 为 满足安全性要求, 特别敏感的身份属性不会出现 敏 感信息包括身份的社会保障号或用户密码 尽管使用员工影子帐户这一概念可能不太直观, 但 却能顺应使用 Active Directory 的 Intranet 实例进行员工身 份验证的组织对 Extranet 的要求 在 Extranet 上验证员 工身份有以下两个选择 : 将林或域信任从外围网络 ( 也称 DMZ 外围安 全区或屏蔽子网 ) 应用到 Intranet 在外围网络中创建影子帐户 第一种方式需要开放许多端口, 从而找出一条路径 能够通过分隔外围网络和 Intranet 的防火墙 这种方式 适用于许多组织, 但其他组织要求其外围网络和 Intranet 之间彻底隔离 对于需要严格网络隔离的组织而言, 使用影子帐户 可能是最好的选择 微软建议通过自动机制来创建影子帐户, 例如 Microsoft Identity Integration Server 2003 Enterprise Edition (MIIS 2003 SP1) 中提供的机制 在某些允许安全性较低的服务器 ( 比如 Extranet 中的服务器 ) 采用非密码身份验证机制的场合, 影子帐户甚至能增加网络安全性 这样的例子包括基于安全套接字层 (SSL) 3.0 的身份验证和传输层安全 (TLS) 1.0 客户端证书身份验证, 或一次性密码身份验证机制 ( 例如 RSA Security Inc. 的 SecurID 双因素身份验证产品 ) 公钥基础结构信任 公钥基础结构 (PKI) 是由数字证书 认证机构 (CA) 和其他用于通过公钥加密来检查和验证电子事务中每一方有效性的注册机构组成的一套体系 但要检查和验证有效性, 每一方都必须信任证书的颁发者 ( 通常是 CA) 对于 Windows 用户 计算机和服务, 当受信根认证机构的存储库中存在根证书副本且存在有效认证路径时, 说明对认证机构的信任已经建立 有效的认证路径意味着认证路径中没有任何被吊销或已过期的证书 认证路径中包含颁发给认证层次结构中每个 CA( 从从属 CA 至根 CA) 的所有证书 例如, 对于根 CA, 认证路径就是一个证书, 是其自签名的证书 对于从属 CA( 在认证层次结构中根 CA 下紧跟的 CA), 其认证路径使用两个证书 : 其自己的证书和根 CA 的证书 将根证书导入受信根认证机构存储库的过程是为计算机和托管应用程序建立 PKI 信任的最简单方法 例如, 如果 Contoso Pharmaceuticals( 一个虚构的组织 ) 的 Web 服务器将 Fabrikam Inc.( 另一个虚构的组织 ) 的根证书 CA 安装到根认证机构的存储库中,Contoso Web 服务器就会信任由 Fabrikam CA 所颁发的任何有效证书 但这一过程只是建立事务的信任部分, 而不会在 Web 服务器上建立身份或上下文 要创建从身份到上下文的映射, 还需要执行一些其他操作, 例如将证书中的某些信息映射到 Active Directory 中的安全主体 尽管受信认证机构的存储机制相当容易部署, 但它 61

62 微软安全指南 1 身份和访问管理指南解决方案基本概念 不能满足在建立两个组织 ( 如 Contoso 和 Fabrikam) 间联合信任这类复杂场合下的安全性要求 假定 Contoso 和 Fabrikam 用户都可以出示有效的证书来访问 Contoso 网站, 这时, 外部 Active Directory 中将包含来自 Contoso 和 Fabrikam CA 的证书映射 可以采用基于证书主题建立映射的方法, 例如 : E=fred@fabrikam.com 这种方法的问题是信任没有被绑定, 这意味着 Contoso 愿意完全信任 Fabrikam, 不会颁发主题为 E=fred@contoso.com 的证书, 此处 fred@contoso.com 是 Contoso 组织中的用户, 而不是 Fabrikam 组织中的用户 这种情况下, 证书持有者可能会获得 Contoso 站点上敏感信息的访问权 出现这个问题并不是因为 PKI 信任本身脆弱, 而是因为证书定义过于宽泛 解决这一问题的办法是建立可控性更高的 PKI 信任机制, 使 Fabrikam 域颁发证书, 域颁发证书 限定从属 在 Windows 2000 网络中, 根本无法实现真正的 CA 层次结构交叉认证 唯一可替代的方法是定义信任特定 CA 和限定证书用途的证书信任列表 (CTL) Windows Server 2003 中所引入的限定从属是交叉认证 CA 层次结构的过程, 这一过程中使用基本策略 命名和应用程序约束条件来限制从合作伙伴 CA 层次结构或同一组织内的辅助层次结构中接受哪些证书 通过限定从属,CA 管理员可以明确地定义其组织信任合作伙伴 PKI 所颁发的哪些证书 限定从属还提供了根据策略原则在组织内划分和控制证书颁发的方法 限定从属还允许在不同信任层次结构中的 CA 之间建立信任 这种类型的信任关系也称交叉认证 通过这样的信任关系, 限定从属不再限定于从属 CA 在一个层次结构的从属 CA 与另一个层次中的根 CA 之间也可以建立信任 限定从属允许在 PKI 中为域内部和域之间设置额外的信任条件, 来扩展信任层次结构 通过限定从属, 在信任层次结构中的每个限定从属 CA 可以有不同的规则, 来控制其证书颁发方式及证书使用方式 有一个示例可以说明如何使用信任条件来解决先前所提到的证书定义过于宽泛的问题, 那就是在 Contoso 和 Fabrikam 层次结构之间建立交叉认证时使用命名空间约束条件 这样,Contoso 将只接受来自指定了 fabrikam.com 域的 Fabrikam CA 的证书 本部分略有删节, 完整内容请查看 : /security/topics/identitymanagement/idmanage 62

63 身份和访问管理指南解决方案平台和基础结构 第二部分 : 平台和基础结构 文章概述 本文探讨的业务挑战是许多组织在处理身份和访问管理时遇到的相同问题 组织 需要技术平台提供 : 与轻型目录访问协议 (LDAP) 标准的符合性 强大的身份验证服务, 如 Kerberos 版本 5 身份验证协议 整体开发支持和各种开发人员应用程序编程接口 (API) 基于角色的访问控制 (RBAC) 对 Intranet 和 Extranet 方案的支持 对分布式目录环境中的身份验证 授权和审计的支持 使组织能够与合作伙伴 客户和员工合作, 从而提供获取额外收入的可能性, 并 增强组织的灵活性 但是, 未经授权对数据进行的访问尝试 法规要求和数据保护法 规 ( 以及大量的病毒 蠕虫和垃圾邮件 ), 使得网络安全性需要计划 监视 分析 与持续警惕的强大结合 本文由四个章节组成, 分别介绍了以下主题 : 第 1 章 : 简介 该简介提供了执行概要 本文的建议读者和文章中各章节的概述 第 2 章 : 选择平台的方法 本章重点介绍了为身份和访问管理建立平台, 并包 括做出一些影响组织 IT 能力的重大决定 其中包括是选择单一供应商解决方 案, 还是选择可集成的多个最佳产品来形成一个完整的解决方案 本章其余部分讨论了与选择单一平台或最佳产品相关的选择, 以及每个方法对目 录服务 访问管理 信任服务 身份生命周期管理工具和应用程序平台的技术 领域的影响 第 3 章 : 问题和要求 本章介绍了虚构的组织 Contoso Pharmaceuticals, Contoso Pharmaceuticals 可用来描述许多常见的 组织对身份和访问管理平台 的企业 技术和安全性要求 本章还讨论了 Contoso Pharmaceuticals 中的安全 漏洞, 这些漏洞推动了以上的许多要求 第 4 章 : 设计基础结构 本章根据其使用微软身份和访问管理平台的决定, 讨 论了 Contoso Pharmaceuticals 技术体系结构 该平台体系结构提供了一组核心 的操作系统 目录服务 安全性服务和技术, 各种解决方案 应用程序和业 务流程都要依赖它们作为企业的身份和访问管理解决方案基础 63

64 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 第 1 章 : 简介 本指南探讨了许多组织可能面临的几个典型的身份和访问管理问题 通过使用一个名为 Contoso Pharmaceuticals 的虚构组织, 描述了一个可为身份和访问管理解决方案提供基础的技术平台 并研究了一些有效的身份和访问管理技术必须解决的问题和解决这些问题的机会, 以及相关威胁和对策 本指南的预期读者包括参与身份和访问管理工作的架构师 IT 专业人员和经理 技术决策制定者和顾问 我们的挑战 随着数字身份在指定用户参与计算机网络的方式中起着越来越重要的作用, 身份和访问管理也变得越来越复杂 组织在授予用户对本地计算机或网络上的资源的访问权限之前, 需要有效地标识用户 但是, 甚至运行小型网络的企业也很少将其身份信息存储在一个地方 多个部门 不同国家和地区中的位置 业务部门 软件选择 ( 以及合并和收购 ) 导致了数据库 目录服务和应用程序特定的身份存储激增 开发一致且有效的身份和访问管理策略, 需要充分了解可用来解决激增的数字身份问题的方法和技术 组织和 IT 部门需要实施短期和战略性的方法来控制和使用身份 身份和访问管理的另一个挑战是, 安全问题不得妨碍企业运转 在组织的安全级别和功能之间, 总会存在折衷的办法 本指南通过研究如何在不影响用户执行工作的能力的情况下解决安全问题, 来处理这些挑战 企业益处 利用适当的身份和访问管理平台来面对这些挑战, 将会为贵组织提供下列益处 : 使用户对资源的访问有所改善且更具成本效益 集中管理数字身份 通过需要数量更少的 实施和维护数字身份及执行访问管理的管理员, 来降低开销 为公司资源提供更完善保护措施的安全配置文件要求一致 增加了与业务合作伙伴 客户和远程工作员工的稳定合作机会 64

65 身份和访问管理指南解决方案平台和基础结构 第 2 章 : 选择平台的方法 建立身份和访问管理平台包括进行一些会对组织的 IT 能力产生显著影响的重大决策 组 织必须做出的第一个决策是选择单一供应商解决方案还是选择可集成的多个 单项优势 产品以形成完整的解决方案 单一供应商解决方案的优势可能包括 : 更易于集成 全面的单源支持 折扣或程序包许可 单项优势 解决方案的优点可能包括 ( 但要强调的是, 并不是始终都包括 ): 能够根据要求选择单个产品 能够仅许可和部署需要的产品 很多组织都通过为基础结构的重要部分选择单一供应商 ( 通常是平台供应商 ), 然后 使用不同供应商的其他产品扩大此产品的基准以填补特定的功能空缺, 从而获得了这两种模 型的优势所带来的好处 如果组织选择此方法, 则对于平台供应商而言, 证明其技术可与 许多其他供应商在不同技术领域进行互操作便十分重要 本章其余部分讨论在以下技术领域选择单平台或单项优势产品时需进行的选择 : 目录服务 访问管理服务 信任机制 身份生命周期管理工具 应用程序平台 选择目录服务 身份和访问管理平台的成功运作需要合适的位置存储应用程序和身份信息 虽然还有其 他方法可存储用户信息, 但行业已对目录技术迅速进行了标准化以实现此功能 当今多数 可在市场上买到的目录均支持一组常用的功能, 包括 : 支持基于国际电信联盟 (ITU) X.500 标准的轻型目录访问协议 (LDAP) 或目录访问协议 (DAP) 或同时支持这两者 基于 X.520 标准的标准化属性类型 基于 X.521 标准的标准化对象类别 65

66 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 因为目录对象存储和目录访问机制在大多数目录上 均相当一致, 所以通常通过一些功能来区分各种目录服 务产品, 例如 : 搜索性能 向上扩展的存储和多处理器效率 向外扩展的数据复制性能 强大的故障转移和恢复功能 与不同类型的安全服务集成 与不同类型的应用程序和系统管理服务集成 发布技术 对象和属性级的精确访问控制 许可 支持 目录要求也可能取决于要求目录执行的角色 一种 角色中所需的功能可能与另一角色中所需的功能不同 例如, 许多组织需要部署目录服务以执行以下角色 : Intranet( 企业 ) 目录 Extranet( 外部 ) 目录 应用程序目录 本章以下部分将介绍这些角色目录的注意事项 Intranet 目录 多数组织当前在其 Intranet 中具有一个或多个目录 服务 Intranet 目录服务必须提供以下功能 : 用户帐户的中央存储库 用于身份验证的凭据的集中 安全存储 用于授权的属性信息的集中存储 用于查找网络资源的信息 用于查找人员和组的信息 除这些功能外, 如果 Intranet 目录服务还可与通常可 在 Intranet 上找到的安全服务紧密集成, 也有很高的价值 Extranet 目录 Extranet 目录与多数组织中 Intranet 目录的基本要求 相同 其他针对选择必须支持伙伴 客户和员工所用 应用程序的目录的要求包括 : 能够扩展至上百万用户 节省成本的许可 支持 Internet 兼容的身份验证机制 能够在一个目录内提供多个截然不同的社区或组 织 ( 如伙伴和客户 ) 应用程序目录 如果目录服务技术符合方案要求, 但存储在目录中 的数据对大型用户或应用程序集没有用, 则会在组织中 部署应用程序目录 应用程序目录通常具有在组织级使 用的目录的子集, 并对可管理性和可操作性有附加要 求 应用程序目录应具有以下特性 : 存储应用程序特定的信息 易于建立和部署 简单的管理模型 合理的向上扩展和故障转移功能 低成本许可 选择访问管理服务 访问管理服务为组织的应用程序提供了对用户进行 安全身份验证并执行稳定授权的功能 考虑选择访问管 理时, 请选择与目录服务产品集成良好的技术 选择身份验证方法 身份验证机制的要求和注意事项可能会因方案的不同 而有很大差异 区别身份验证执行方式的典型要求包括 : 组织可对用户施加什么要求? 可建立和维护什么样的基础结构来支持用户? 用户应具有单一登录 (SSO) 体验吗? 用户需要访问何种应用程序? 尽管方案可能会有所变化, 但 Intranet 和 Extranet 身份验证提供了一种将用户和适用的身份验证机制进行 分类的方法 66

67 身份和访问管理指南解决方案平台和基础结构 Intranet 身份验证 Intranet 身份验证具有以下特点, 会影响选择的身 份验证机制 : 管理计算机用户 ( 雇员 ) 使用网络的方式的高 级别控制 ( 通过策略 ) 完全控制网络环境和服务的可用性 控制用户工作站的配置 多种应用程序类型, 例如客户端 / 服务器 基于 Web 或基于 Microsoft Windows 表单 因为这些特点, 可为 Intranet 选择提供高安全性的 身份验证机制, 同时提供 SSO 体验 不过, 这些同样 需要将复杂的基础结构 配置和某些用户行为相结合 符合此描述的身份验证技术的示例包括 : Kerberos 版本 5 身份验证协议 智能卡上的 X.509 数字证书 硬件令牌, 例如 RSA SecurID 有关这些技术的详细信息, 请参阅本指南第三部分 第 2 章 Intranet 访问管理的方法 ( 见 105 页 ) Extranet 身份验证 除员工 ( 少数情况中为伙伴 ) 使用 VPN 技术通过 Internet 访问 Extranet 资源的个别例外情况外, 基于 Web 的 Extranet 访问具有一组完全不同的特点 : 管理计算机用户 ( 客户 伙伴 ) 使用网络方式 的低级别控制 ( 通过策略 ) 对超出您外围网络范围的网络环境和服务可用 性, 几乎没有控制权 对用户工作站的配置没有控制权 访问大部分需要基于 Web 的应用程序 因为这些特点, 应为 Extranet 选择提供足够安全而 不会对用户强加不切实际要求的身份验证机制 符合此 描述的身份验证技术的示例包括 : 基于表单的身份验证 用于雇员的 X.509 数字证书 用于客户和伙伴的 Microsoft Passport 服务 即使 Extranet 环境规定了很明确的限制,Extranet 用户也期望与 Intranet 用户一样, 享受相同的跨多个应用程序的 SSO 体验 此外, 许多组织要求提供跨越在不同平台上运行的不同应用程序的 SSO 用户体验 强大的独立软件供应商 (ISV) 市场已逐渐成熟, 可解决提供跨异型平台 Web SSO 这一问题, 并可从大量供应商那里获得许多合适的解决方案 实现授权 多数平台支持用于对静态对象 ( 例如文件和打印机 ) 授权的某种形式的访问控制列表 (ACL) 机制 成为明确允许访问对象的用户或组的成员, 即可获得访问这些对象的权限 此外, 多数组织将会仔细考虑是否使用某一种形式的基于角色的访问控制 (RBAC) RBAC 往往更直观, 因此更易于管理, 也更为灵活 RBAC 机制应能实现业务规则, 以定义授权策略 例如,RBAC 机制应能强制执行以下类型的业务规则 : 只有银行出纳员才能在上午 9 点和下午 4 点之间处理储蓄帐户存款 组织应选择一个可提供有效的基于 ACL 的静态对象访问控制的平台, 以及可进行直观管理并能够将复杂业务规则表示为访问策略的稳定 灵活的 RBAC 机制 实现信任机制 在目前已经讨论的所有技术当中, 信任的实现可能是区分各种平台的最大技术领域 在最高层级, 信任是指一台计算机信赖另一台计算机或一组计算机, 以声明用户身份 信任机制之间的差别主要在于计算机和用户如何成为信任环的一部分 例如, 基于主机的系统就其本质而言既是自治的又是封闭的 很少组织具有一台以上的大型机, 如果有, 除通过显式共享密码外, 这些计算机不太可能相互信任 UNIX 和 Linux 操作系统通常是独立系统 ( 不是任何 信任环 的成员 ), 或者是网络信息服务 (NIS) 或 NIS+ 分组的一部分 也可配置 UNIX 和 Linux 工作站以使 67

68 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 用 LDAP 进行身份验证和授权 发生这种情况时, 所有 此类经配置使用同一目录实例的工作站将成为此信任环 的一部分 要成为可进行有效身份和访问管理的真正有价值的 工具, 平台应提供可在整个组织范围 ( 甚至组织间 ) 扩展的信任机制 建立信任环应形成可组织成层次分组 的基本组分, 以简化在适当级别对信任关系的管理 选择身份生命周期管理工具 身份生命周期管理工具提供管理以下与身份相关的 基本任务的方法 : 用户管理 凭据管理 权利管理 所有平台均附有管理员可用来执行这些基本任务的 工具和界面, 不过这也是强大的 ISV 市场为提供用户友 好的 跨平台管理功能而已经涉足的另一领域 许多 情况下, 这些工具是基于 Web 的, 这非常适于 Extranet 身份管理方案, 例如委派伙伴管理 ( 其中伙伴组织负 责管理其用户 ) 如果本指南论述的针对 Intranet 方案设计的平台所 提供的工具不符合贵组织的要求, 则应考虑在贵组织的 方案中使用具有单项优势的身份管理工具 实现身份集成 身份集成工具就其本身的功能而言通常是尖端 复 杂的产品 这些工具可聚合和同步描述已建立组织中很 多现有身份存储之间的数字身份 ( 属性 ) 的信息 其 中的一些产品中也被描述为元目录产品 评估身份集成产品时, 应考虑以下特性 : 它与多少不同类型的身份存储连接? 每个 连接者 都需要在已连接系统上占有一 席之地 ( 用户帐户或附加表 ) 吗? 管理身份存储之间属性流的规则的稳健程度如何? 扩展产品所附带的规则时使用何种开发环境? 该产品可在存储库之间同步或传播用户密码吗? 该产品支持基于状态 ( 基于对象的当前状态 ) 和基 于事件处理 ( 基于连接的身份存储中的更改 ) 吗? 该产品是否能与组织所选的平台目录服务良好 集成? 置备和取消置备 能够置备和取消置备多个身份存储中的用户帐户可 能是身份集成产品功能的一部分, 也可在单独产品中实 现这些功能 评估置备产品时应考虑的功能与评估身份 集成产品相类似 能够支持不同级别的工作流也是区分 置备产品的一个重要方面 选择应用程序平台 应用程序开发环境历来可与其自身平台良好集成, 但不能与其他平台良好集成 因此, 贵组织对应用程 序平台的选择很可能取决于针对您环境中的应用程序服 务器而选择的基础结构平台 许多组织选择在两个或多个平台上开发或维护应用 程序 对于此类组织, 了解不同种类的应用程序如何 通过使用公共协议和利用公共基础结构服务进行互操作 至关重要 不应选择不能与其他平台良好集成或互操作 的应用程序平台 应用程序平台供应商应对互操作性有 明确的承诺, 并且支持为实现互操作性所进行的相关标 准制订工作 微软身份和访问管理平台 本章的以下部分介绍构成微软身份和访问管理平台 的核心产品和技术, 以及它为组织带来的益处 目录服务 Microsoft Windows Server 2003 包含对 Microsoft Active Directory 目录服务和称为 Active Directory 应用程序模 式 (ADAM) 的应用程序目录服务的支持 图 1 显示 Active Directory 所起到的中心作用, 以及它如何与其他微软和 ISV 技术结合 68

69 身份和访问管理指南解决方案平台和基础结构 Active Directory Active Directory 具有以下功能, 使其可适用于 Intranet 和 Extranet 目录服务角色 : 网络管理和管理授权委派的 中央位置 管理员有权访问代表所有网络用户 设备和资源的对象, 以及能够将对象分组以易于管理, 并应用安全性和组策略 用户访问网络资源的信息安 全性和 SSO 与安全性的紧 密集成消除了在系统间跟踪 帐户以进行身份验证和授权 的成本 单一的用户名和密码组合便可对每个网 络用户进行身份标识, 并且用户在整个网络中将 一直使用此身份 可扩展性 Active Directory 包括一个或多个域, 每个域带有一个或多个域控制器, 可用来扩展 目录以满足任何网络要求 灵活的全局搜索 用户和管理员可使用桌面工 具搜索 Active Directory 默认情况下, 搜索将 针对全局目录, 这可提供全林范围搜索功能 存储应用程序数据 Active Directory 提供了一个 中央位置来存储应用程序之间共享的数据, 以 及需要在全部基于 Windows 的网络之间分发其数 据的应用程序的数据 目录更新的系统同步 在整个网络中, 更新内 容的分发是通过在域控制器之间进行安全而经济 的复制完成的 远程管理 可从任何已安装管理工具的基于 Windows 的计算机远程连接任何域控制器 也 可以使用远程桌面功能从远程计算机登录到域控 制器 单一 可修改和可扩展方案 此方案是一组对象 和规则, 提供了 Active Directory 对象的结构要求 可修改此方案以实现新类型对象或对象属性 对象名称与域名系统 (DNS) Internet 标准的计 图 1:Active Directory 与其他网络组件的集成 算机定位系统的集成 Active Directory 使用 DNS 实现基于 IP 的命名系统, 这样可通过标准 IP 在 Intranet 和 Internet 上查找 Active Directory 服务和 域控制器 LDAP 支持 轻型目录访问协议 (LDAP) 是行业标 准的目录访问协议, 使管理和查询应用程序普 遍可通过该协议访问 Active Directory Active Directory 支持 LDAPv3 和 LDAPv2 Active Directory 应用程序模式 Active Directory 应用程序模式 (ADAM) 具有以下功 能, 使其可适用于应用程序目录服务角色 : 易于部署 开发人员 终端用户和 ISV 很容易便 可在多数 Windows Server 2003 平台以及运行 Microsoft Windows XP Professional 的客户端上将 ADAM 作为轻型目录服务部署 您可很容易地安 装 重新安装或删除 ADAM 应用程序目录, 使 其成为可与应用程序一起部署的理想目录服务 基础结构成本降低 通过使用单一的目录技术 满足网络操作系统 (NOS) 和应用程序目录的需要, 69

70 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 可降低整体基础结构的成本 无需针对培训 管理或应用程序目录的管理进行额外投资 标准化的应用程序编程接口 (API) 在 ADAM 和 Active Directory 中实现了 LDAP Active Directory 服务接口 (ADSI) 和目录服务标记语言 (DSML) 可 使用这些功能在 ADAM 上构建应用程序, 然后 根据需要, 只进行最小改动便可将它们迁移到 Active Directory 安全性增强 由于 ADAM 与 Windows 安全模型 集成, 任何使用 ADAM 的应用程序都可在整个 企业范围验证对 Active Directory 的访问权 灵活性增强 应用程序所有者可以很容易地部 署启用目录的应用程序, 而不会影响整个组织 的目录方案, 同时可继续使用存储在组织的 NOS 目录中的身份信息和凭据 可靠性和可扩展性 使用 ADAM 的应用程序的 可靠性 可扩展性和性能与在 NOS 环境中部署 Active Directory 时相同 有关 ADAM 的详细信息, 请下载白皮书 Windows Server 2003 Active Directory 应用程序模式 ( microsoft.com/china/windowsserver2003/techinfo/overview/ adam.mspx) 安全服务 以下安全服务与 Windows 应用服务器 Windows 客户端操作系统和作为域控制器的运行 Windows 2000 Server 和 Windows Server 2003 的计算机紧密集成 : Kerberos 版本 5 协议支持身份验证, 包括客户端 / 服务器应用程序所用的 API, 以及与 Active Directory 集成的 Kerberos 密钥分发中心 (KDC) 微软安全支持提供程序接口 (SSPI) 是一个既定的公 共 API, 用于获取身份验证的集成安全服务 消 息完整性 消息隐私性和任何分布式应用程序 协议的安全服务质量 组织可通过内置于 Windows Server 中的基于 X.509 的公钥证书服务器向其用户颁发用于身份验证的 公钥证书, 而不依赖商业认证机构 (CA) 服务 安全套接字层 (SSL) 和传输层安全性 (TLS) 使用客户 端 / 服务器 X.509 数字证书支持强大的 相互身 份验证和安全通讯 智能卡提供了防止篡改的存储空间以保护私钥 帐号 密码和其他形式的个人信息, 并且是微 软集成到 Windows 平台中的公钥基础结构 (PKI) 的 关键组件 Microsoft Passport 为组织的 Extranet 应用程序提 供针对客户身份验证的 SSO 用户体验 有关静态资源的访问控制列表 (ACL) Microsoft Windows Server 基于对象的安全模型允许管理员 为用户或组授予访问权限, 这些权限用于管理 哪些用户可访问特定对象 授权管理器支持自定义应用程序中的 RBAC 安全审核允许更改要通过安全事件日志报告的目 录对象和访问事件 身份集成服务 Microsoft Identity Integration Server 2003 Enterprise Edition Service Pack 1 (MIIS 2003 SP1) 包括以下功能, 可 用于简化整个组织的身份和访问管理 : 跨不同种类身份存储的身份聚合 同步和置备 与多个身份存储连接的管理代理, 包括目录服 务 数据库和电子邮件系统 密码管理和同步, 包括用于密码重置的自助式 Web 应用程序 在连接的身份存储上没有连接方所需的位置 基于事件或状态的同步处理 通过 Microsoft Visual Studio.NET 编程环境很容易 实现可扩展性 称为 Active Directory Identity Integration Feature Pack 的简化功能集版本提供 : Active Directory ADAM 和全局地址列表 (GAL) 同步的管理代理 70

71 身份和访问管理指南解决方案平台和基础结构 客户端操作系统 实现 Windows XP Professional 标准化的组织将会获 得以下好处 : 通过平台服务支持 Windows 集成身份验证, 以 开发平台 实现文件 打印和 Web 应用程序服务的 SSO 强制提高安全性的域级组策略 通过 Windows 凭据管理器使用密码 X.509 数字 证书和 Microsoft Passport 帐户的不同组织间的附 加 SSO 功能 Microsoft Visual Studio.NET 和.NET Framework 提供 的功能可用于 : 使用微软身份和访问管理平台功能开发可识别身 平台优点 份的应用程序 降低应用程序开发成本 使用本指南以下章节中所述的解决方案实现微软身 份和访问管理平台可使 Contoso 获得以下好处 : 单一 安全 受信任的身份信息源 管理员掌 握所有应用程序和系统以及所有用户及其权利的 可靠 最新信息 无缝应用程序集成 微软开发平台提供了安全 标准化的身份验证 授权和数据保护机制 织的关系结束时, 其在组织中跨多个系统的身 份即被删除 置快速而方便地添加 更改和删除数字证书和 权利 可访问的资源 可对这些资源采取的操作以及 如何详细地对用户和资源应用安全策略 为方便地访问应用程序, 并且帮助台人员将花 费更少的时间管理密码问题 通过标准化的访问和身份验证机制提供互操作 性, 这降低了集成和管理多个系统所花的时间 索来解释通过网络访问资源的人员 访问对 象 时间 地点以及方式 地存储的密码凭据进行强大保护 平台提供身份和访问管理所需的核心服务时, 需 要在平台上实现多个解决方案才能获得所有这些优点 第 4 章 设计基础结构 中对这些解决方案进行了讨 论 改进的安全性和置备 员工 客户或伙伴与组 简化管理并降低管理成本 管理员可在中央位 精细访问控制 管理员可更为精确地控制用户 使用更少的密码和更好的密码管理 用户可更 身份系统和操作系统间的互操作性 此解决方案 安全 可靠的审核 审核提供了必要的跟踪线 本地凭据管理 使用 Windows 凭据管理器对本 71

72 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 第 3 章 : 问题和要求 要在组织内实现有效的身份和访问管理基础结构, 您需要根据技术能力准确分析组织需求来选择技术平台 这种功能分析会确保解决方案满足您的业务目标, 同时保持平台安全和可管理 本章借助虚构的公司 Contoso Pharmaceuticals 来阐述这些问题 Contoso Pharmaceuticals 方案旨在为典型组织在解决身份和访问管理的常见问题时可能面临的问题提供见解 Contoso Pharmaceuticals 简介 Contoso Pharmaceuticals 是一家虚构的美国公司, 其总部和主要制造机构均位于佛罗里达州奥兰多市 Contoso 目前拥有 5,300 位员工, 年收益 38 亿美元 该公司的成功主要依赖于其专注于开拓性研发的公司文化 因致力于客户服务及其低成本生产设施,Contoso Pharmaceuticals 广受赞誉 过去两年中,Contoso 增长势头强劲, 在收购英国的一家小型药品供应公司 Fabrikam Ltd.( 另一家虚构的公司 ) 后, 已经日趋丰满 现着手策划再进行几次类似收购以巩固母公司的市场地位 信息技术部 Contoso IT 部由几百名技术和管理人员组成 22 名专职系统管理员管理着 500 多台各式的服务器, 其中包括运行基于 Microsoft Windows 的服务器操作系统 Sun ONE Directory Server 5.1( 以前是 iplanet Directory Server) 的计算机和运行第三方及自定义应用程序的大型机 这些管理员还管理着公司的 Microsoft Exchange Server 基础结构和提供给员工的内部 Contoso 门户网站 其余的服务器专用于文件和打印服务以及数据库功能 管理公司的 Microsoft Windows Server 2003 域控制器和 Microsoft Active Directory 目录服务是日常工作的重要部分 域管理员所执行的许多任务之一就是在 Active Directory 中置备帐户 Contoso 拥有一支帮助台操作队伍, 这支队伍规模庞大 训练有素, 并提供一周 7 天, 每天 24 小时的操作支持 帮助台操作员为电子邮件 字处理 业务应用程序等应用程序以及将员工挡在公司系统之外的密码重置助手提供支持 Contoso 还有几名基础结构和安全方 72

73 身份和访问管理指南解决方案平台和基础结构 面的架构师, 他们评审企业范围和部门的 IT 需求, 从而产生 IT 战略 投资和标准方面的建议 操作系统 广泛的系统平台和应用程序构成了 Contoso Pharmaceuticals 的 IT 基础结构 尽管基于 Windows 的服务器和客户端构成了 Contoso 系统的主要部分, 但 Contoso 还有关键业务系统, 包括运行 Sun ONE Directory Server 5.1 的服务器和运行 Sun Solaris 9 的工作站 当前使用网络信息系统 (NIS) 管理运行 Sun Solaris 9 的系统 Contoso Intranet Active Directory 设计的特点是具有单个目录林, 它包含一个空的根域和单个子域 所有的原始 Contoso 用户 服务和计算机帐户都从 Microsoft Windows NT 4.0 域迁移到 Active Directory 中 公司还运行用于为 Contoso.com Internet 域提供服务的外部域名系统 (DNS) 服务器 这些 DNS 服务器与用于为 Intranet Active Directory 目录林提供服务的内部服务器分离开来 其他身份存储 在最近收购 Fabrikam Ltd. 时,Contoso 还获得了多个基础结构产品, 如 Lotus Notes Release 和运行 Sun ONE Directory Server 5.1 的服务器, 前者用于消息传递, 后者用于为自定义开发的 Web 应用程序提供身份验证和目录服务 短期内, 仍需要这些系统为先前的 Fabrikam 员工的业务活动提供支持 从长期规划来看, 要求将 Fabrikam 基础结构迁移到现有的 Contoso 环境中 业务和技术问题 Contoso 在竞争激烈的环境下运营, 抓住上市时机是关键的行业驱动因素 临床试验投资巨大, 为获得美国食品药品管理局 (FDA) 批准而上报结果或提交产品时, 延迟一天就能花掉公司近一百万美元 因此, 与用户及合作伙伴的交互成为公司运营的关键部分 规章制度是另一主要的考虑因素, 因为监管罚金和处罚的范围可从数百万到上千万美元不等 Contoso 面临的主要业务挑战是就组织与客户 合 作伙伴及远程工作的员工之间的交互而言, 如何提升质 量以及如何扩大范围 这种从客户处获得反馈, 然后 就组织的产品优点进行沟通的新型交互方式已经收获了 许多改进 这些改进涉及产品开发流程, 以生产更符 合客户需求的产品, 从而增加公司的市场份额 不过, 先期管理投入已经使得这一流程成本不菲且难以维持 Contoso 相信, 如果改进与合作伙伴相互协作所使 用的技术解决方案, 必将大大提高产品开发流程的效 率 与此同时, 员工会提高积极性并需要通过公司网 络和 Internet 更方便地访问各自工作所需的数据 Contoso 认为身份和访问管理平台必须提高基础结 构的易于管理性和安全性, 尤其是在数字身份管理方 面 作为长期目标, 该公司计划将用于独立应用程序 的重复身份存储合并到中央身份存储中, 这将提高管理 效率, 降低总拥有成本 (TCO), 从而减少管理错误, 大 大增加安全性 不过,Contoso 的架构师和管理员认识到, 他们必 须先解决存在的短期到中期问题才能实现这些目标, 尤 其是在安全性方面 本章稍后介绍的 威胁和对策 部 分总结了这些安全顾虑以及能够减少或消除威胁的对策 Contoso Pharmaceuticals 在其为期两年的改进身份 和访问管理的规划中已经确定了下列主要要求 : 为公司产品的快速开发 评估和营销提供尽可 能最好的技术基础结构 提高公司 IT 基础结构的效率和安全级别 ( 特别是 管理数字身份方面 ), 在无需增加额外管理开 销和 IT 复杂性的情况下, 为其他方面的增长铺平 道路 将安全性和隐私机制与相关技术合并, 以符合 政府监管要求, 如 FDA 21 联邦代码规则 (CFR) 第 11 部分 (Part 11) 以及 1996 年颁布的健康保险流通 与责任法案 (HIPAA) 为了实现这些要求,Contoso 已经对其最关键的应 用程序和流程进行了全面评审 接下来的部分对这些关 键资产进行逐一确定 73

74 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 关键 IT 资产 Contoso Pharmaceuticals 已经确定了对公司而言极 为重要的许多 IT 资产 下列资产在解决主要的业务和技 术问题时发挥了关键作用 : 可通过 Extranet 访问的 销售和联系人 应用 程序与销售员工用户帐户 可通过 Extranet 访问的 合作伙伴研究 应用 程序与外联网合作伙伴身份存储 可通过 Extranet 访问的 客户试用反馈 应用 程序与外联网客户身份存储 SAP 应用程序数据与 SAP 用户帐户 Microsoft Exchange 电子邮件基础结构与帐户 Lotus Notes 电子邮件基础结构与帐户 使用 Sun ONE Directory Server 5.1 的应用程序与 UNIX 用户帐户 图 1 汇总了这些关键资产 图 1:Contoso 关键 IT 资产 可通过 Extranet 访问的销售和联系人应用程序 Contoso 销售人员花大量时间在外面拜访客户, 建立新业务 这些职员需要跟踪各自的销售和销售联系人, 这通过驻留在 Contoso 外围网络 ( 也称为外围安全区域 (DMZ)) 中的 Web 应用程序和数据库来实现 此应用程序维护的信息不是关键的敏感信息 不过, 泄露这些数据可能导致 Contoso 及其商业合作伙伴出现问题, 并会对 Contoso 在公众心中的信任程度产生更坏的影响 应用程序无效是最大问题, 因为这会严重妨碍销售人员的效率 销售员工用户帐户各销售员工用户帐户可通过 Extranet 访问特定范围内的敏感材料 这些帐户也可能遭到滥用, 对 Contoso 组织的较大范围及其 IT 资源发动攻击 可通过 Extranet 访问的合作伙伴研究应用程序与研究合作伙伴的协作对于新产品的开发而言至关重要,Contoso 依赖这种方式来实现其未来的发展 很多此类协作需要通过驻留在 Contoso 外围网络中的单个应用程序来进行 虽然应用程序中的数据经常备份, 但对该应用程序的一次成功攻击就可能对 Contoso 造成严重的问题 所泄露的研究数据可能导致竞争处于不利地位以及可能的监管行动 Extranet 合作伙伴帐户存储对于 Contoso IT 资源的访问, 合作伙伴帐户所拥有的权限要比员工帐户少 合作伙伴帐户仅可以访问 合作伙伴研究 应用程序 不过, 破坏单个帐户或整个帐户存储将很可能造成至少部分应用程序受到破坏 这也会导致竞争处于不利地位以及可能的监管行动 可通过 Extranet 访问的客户试用应用程序 Contoso 产品的成功取决于在产品开发周期过程中的早期客户反馈 Contoso 利用技术的方式之一就是提供一个 Web 应用程序, 借此, 客户能够方便地针对试验阶段的产品提供反馈 74

75 身份和访问管理指南解决方案平台和基础结构 通过 客户试用反馈 应用程序,Contoso 会收集到大约 50% 的客户反馈 破坏此应用程序将严重影响公司完成试验及向 FDA 提交结果的能力, 如果 FDA 有理由相信该应用程序的安全性已被破坏, 可能导致监管行动 Extranet 客户帐户存储对于 Contoso IT 资源的访问, 客户帐户所拥有的权限要比员工帐户少 客户帐户仅可以访问 客户试用反馈 应用程序 不过, 破坏单个帐户或整个帐户存储将很可能造成至少部分应用程序受到破坏 另一个起作用的因素是, 由于察觉到 Contoso 安全性实践较差, 可能会泄露客户隐私信息, 从而对客户关系造成的破坏 这会再次导致针对公司实施监管行动 SAP 应用程序数据与 SAP 用户帐户 Contoso 已经实现了多个基于 SAP 的企业资源计划 (ERP) 应用程序 其中的一些应用程序提供关键的业务功能并将机密数据分配给用户 破坏这些数据会使公司失去市场竞争力, 或因违反监管要求而导致巨额罚金 可使用各用户帐户来访问 SAP 应用程序范围内的敏感材料 这可能会将财务信息泄露给投资者, 从而可能对 Contoso 造成损害 Microsoft Exchange 电子邮件 Contoso 使用 Microsoft Exchange Server 和 Microsoft Outlook 收发内部和外部的电子邮件 破坏这些数据可能导致竞争对手获得商业敏感信息, 还可能造成监管行动 Lotus Notes 电子邮件 Fabrikam Ltd. 使用 Lotus Notes 收发内部和外部的电子邮件, 在与 Contoso 合并期间已迁移了此环境 破坏这些数据可能导致竞争对手获得商业敏感信息, 还可能造成监管行动 Sun ONE Directory Server 5.1 与 UNIX 用户帐户 Sun ONE Directory Server 5.1 为 Fabrikam 使用的自定义 Web 应用程序提供目录服务和身份验证支持 破坏此应用程序及其数据会导致竞争处于不利地位以及可能的监管行动 各 UNIX 用户帐户可访问 Contoso 特定范围内的敏感 材料 这些帐户也可能遭到滥用, 对 Contoso 组织的 较大范围及其 IT 资源发动攻击 完成分析 在完成 IT 资产分析后,Contoso 确定当前身份和访 问管理平台具有下列问题 : 在 Contoso 环境中, 没有用于降低管理数字身份 的成本和复杂性的明确战略 客户应用程序的置备和取消置备用户未标准化 开发中的应用程序在添加更多身份存储时使 IT 基 础结构复杂化 身份验证机制常常是针对每个应用程序自定义开 发的, 或者是以旧版系统为标准的过时机制 无论哪种情况, 实现这些机制都需要很高的成 本, 而且常常不足以阻挡在当今计算环境中所 发现的大量威胁 应用程序授权是值得关注的问题, 因为应用程 序开发人员常常实现自定义机制, 这会增加开 发和维护的时间和成本 威胁和对策 实际上, 许多身份和访问管理安全问题都是安全漏 洞 漏洞是信息系统或其组件中的薄弱环节, 可能会 被他人利用产生安全缺口 漏洞可能因人员 流程或 技术方面的问题所引起 示例可包括系统安全过程 硬 件设计或内部控制 网络防御内的任何一点都可能产生 漏洞, 评估通常是总体安全性评审的一部分 当前威胁 Contoso Pharmaceuticals 刚好完成了对其网络的主 要安全性评审工作 其中一部分评审工作包括对网络威 胁的分类 在确立其身份和访问管理项目的范围时, Contoso 决定将来自内部源和外部源的潜在攻击列为首 位 内部威胁包括那些以 Intranet 为目标的威胁, 而外 部威胁处理那些特定于 Extranet 的威胁 75

76 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 安全问题和漏洞 Contoso 环境存在大量漏洞, 它们与本章前面介绍 的商业和技术问题有关 从安全性角度看,Contoso 的 身份和访问管理解决方案必须解决下列问题 : 多的商业信息, 但是内部网络上实现的安全性 机制既不坚固, 也不稳定, 不能将对此网络的 访问普及化 杂乱且分散, 因而,Contoso 的安全缺口难以 查明 发生针对它们所控制的用户帐户的攻击 可能发生针对身份验证机制的攻击 能发生针对这些机制的攻击 第一个漏洞强调的是身份和访问管理的恒久难题 : 只有客户 合作伙伴或员工能够访问系统, 才能从与 他们连接的系统中受益 不过, 也正是授予访问权限 的操作增加了安全风险 将这些类别进一步细分,Contoso 安全性评审确定 了下列流程和帐户漏洞, 可从内部源和外部源对其加以 公开利用 : 员工 合作伙伴和客户帐户漏洞很相似, 但员工 帐户漏洞有更强的隐蔽性 帐户置备 Contoso 必须通过面向 Internet 的应用程序提供更 由于安全审核日志中仅有的合法证据残缺不全 现有的应用程序身份存储很不安全, 极有可能 现有的应用程序身份验证机制很不安全, 极有 现有的应用程序授权机制设计得较差, 极有可 帐户置备 帐户取消置备 UNIX 工作站帐户 SAP 身份验证 SAP 应用程序数据保护 员工帐户 合作伙伴帐户 客户帐户 无效或不完整的置备不会对安全造成直接威胁, 因 为这只是在名义上为不能访问应用程序和网络资源做了准备 然而, 不当的帐户置备机制却能够导致对安全造成直接威胁的其他做法, 如, 帐户共享或允许匿名访问重要资产 帐户共享是与帐户置备漏洞相关的主要风险 据 Contoso 帮助台的最新报告所述, 这一普遍做法引起了大量的因登录尝试失败而引发的支持事件, 造成帐户被锁定以及多位用户同时使用相同的身份访问资源 Contoso IT 部发起的匿名跟踪调查表明, 造成用户共享帐户的首要原因是没能够及时置备新员工, 以使其能够访问应用程序和网络资源 这种身份共享尤其适用于合同制员工, 他们常常在完成工作几个月后才收到进行工作所需的正确访问权限 主管解决这一问题的方法是, 将为其他用户 ( 他们也许在 Contoso 工作, 也许已不在 Contoso 工作 ) 建立的用户名和密码提供给临时职员 这一非标准做法使得应用程序或网络管理员无法审核是哪位员工或哪个部门在使用网络资源或访问应用程序数据 一些主管甚至承认将自己的帐户和密码信息提供给下属, 从而允许员工访问高权利级别的资源和数据 帐户取消置备帐户取消置备漏洞是更为严重的问题 以前的员工或外部黑客会利用应用程序身份存储或目录中所遗留的旧帐户来获得对机密数据和重要数据的未授权访问, 甚至破坏这些数据 过期帐户是与帐户取消置备漏洞相关的主要风险 对基于应用程序的身份存储的最近一次审核显示, 对于已经离开公司三年多的员工, 其帐户仍然有效 过期帐户提供了一个后门, 以前的用户或攻击者可用来攻击应用程序数据 尽管来自帐户先前所有者的这一漏洞显而易见, 但三年前的帐户在这段时期内未曾更改过密码也是重点考虑的问题 过期帐户增加了攻击者对这些静态密码成功发动强行攻击的机会, 特别是如果没有强制密码更改和帐户锁定的适当策略, 情况会更糟 于是, 这些帐户被用来破坏或销毁对 Contoso 业务流程而言至关重要的应用程序数据 76

77 身份和访问管理指南解决方案平台和基础结构 UNIX 工作站帐户 Contoso 有 40 台运行 Sun Solaris 9 的工作站, 会计部的员工使用这些工作站执行日常工作 通过单一网络信息服务 (NIS) 域对 Solaris 工作站进行管理 Sun Microsystems 开发了 NIS 来集中管理 UNIX 系统 NIS 的常规功能类似于 Windows NT 4.0 域 由于 NIS 对知识丰富的 UNIX 管理员来说容易设置和管理, 它的扩展能力相当强, 几乎受到所有形式的 UNIX 的支持, 因此很受欢迎 遗憾的是,NIS 没有良好的安全特征 NIS 的最大安全问题之一就是, 它没有提供强制密码过期或密码复杂化的功能 此外,NIS 域中的所有成员服务器都会收到一份密码文件的副本, 其中包含域中每位用户的加密密码 UNIX 的弱密码或旧密码会威胁网络的安全, 因为攻击者会通过它们迅速获得用户帐户和密码组合 在破坏了用户帐户和密码后, 可利用用户帐户来加剧对那些只能防止匿名攻击的系统的攻击 Internet 上提供了很多针对密码文件采用强行攻击和字典攻击的工具 Contoso 的 UNIX 用户帐户不受强制密码策略的限制, 而且 NIS 密码策略文件分布广泛 SAP 身份验证 SAP 是众所周知且部署广泛的 ERP 应用程序服务器,Contoso 已经实现了几个类似的应用程序 其中的一些应用程序提供关键的业务功能并将机密数据分配给用户 因此, 这些数据对公司的业务而言至关重要 应用程序可用性中断 数据破坏 丢失或泄露数据都可能造成 Contoso 数百万美元的损失 在使用 SAP 提供的传统身份验证机制和数据访问协议访问该应用程序时, 它们没有保护身份验证机密 ( 密码 ) 的功能 只要在用户的网段上加上一个网络分接头, 任何人都可以截取 SAP 用户密码 SAP 应用程序数据保护默认情况下, 通过网络发送的客户端 / 服务器 SAP 应用程序数据未加保护 能够查看 SAP 用户网段上的网络通信量的任何攻击者都可以破坏 SAP 应用程序数据, 方法是窃取这些数据或者引入可能会对 SAP 系统中所维护的数据一致性造成严重影响的不正确数据 在用户和 SAP 应用程序服务器之间交换的数据对公司的业务而言至关重要 在这种情况下, 应用程序可用性中断 数据破坏 丢失或泄露数据也会造成 Contoso 数百万美元的损失 员工帐户员工帐户漏洞涉及两大风险 使用明文密码进行身份验证以及在不安全的服务器上存储明文密码 这些漏洞同时适用于内部和外部网络 当 Contoso 销售部员工进行身份验证以访问外部的 销售和联系人 应用程序时, 他们通常的做法是使用其企业帐户凭据 这会通过破坏位于外围网络中的 Web 服务器将这些凭据泄露给外部威胁, 或泄露给可能不会保守此类信息的应用程序管理员 使用明文密码进行身份验证对在 Contoso 方案中所用密码的分析显示,Contoso 销售组织的员工使用其企业帐户密码来访问驻留在外围网络服务器上的 Web 应用程序 销售应用程序通过安全套接字层 (SSL) 使用基本身份验证以授权对应用程序的访问 虽然 SSL 对于保护网络上的用户密码起到了非常重要的作用, 但明文密码仍会显示在 Web 应用程序服务器上 如果 Web 应用程序服务器遭到破坏, 那么就会取得明文用户密码 而且, 对于此应用程序的密码是否应该与用户的企业帐户密码相同, 并没有正式的公司或部门策略 ; 由于记住另一个密码不太容易, 因此许多员工使用相同的密码 通过使用有效的帐户密码, 攻击者不经授权就可以访问用其他方式无法获得的文件和服务 如果用户的 Extranet 帐户密码与其企业帐户密码相同, 那么甚至还可以获得更多的信息 在不安全的服务器上存储明文密码要对 销售和联系人 应用程序的用户进行身份验证, 销售和联系人 应用程序会将通过基本身份验证获得的明文密码与位于外围网络的 Microsoft SQL Server 数据库中的密码值进行比较 通过使用有效的帐户密码, 攻击者不经授权就可以访问用其他方式无法获得的文件和服务 77

78 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 IP 协议安全 (IPSec) 策略和物理网络设计会保护运行 SQL Server 的计算机, 以免通过 Internet 对它们进行直接访问 对 SQL Server 的外部攻击一定是通过面向外部的 Web 服务器的多层攻击 然而, 由于没有适当的策略或技术防止应用程序管理员访问员工密码, 因此更容易发动内部攻击, 且只需应用程序管理员在应用程序运行时浏览所需的信息即可 合作伙伴帐户 Contoso 拥有针对其研究合作伙伴的应用程序, 它使用基于密码的身份验证 该应用程序有一个包含用户名和密码的本地身份存储, 它保存在驻留于另一计算机上的数据库中, 此计算机不同于托管该应用程序的 Web 服务器 这种设计不仅带来了许多身份可管理性问题, 而且还带来了安全漏洞 其中, 最主要的漏洞是帐户数据库的安全漏洞 帐户数据库在一个单独位置上, 以明文形式为使用该应用程序的所有帐户存储密码 如果未经授权的用户获得了该数据库的访问权限, 则可能会破坏所有的帐户 此外, 在身份验证期间, 每个 Web 服务器都会对该数据库做出未经授权的请求以提取用户的密码, 将其与用户提供的凭据进行比较 这个过程意味着在物理外围网络上可以看见该明文密码, 这将构成巨大风险 客户帐户 Contoso 还拥有针对其客户的应用程序, 它使用基于密码的身份验证 关于此漏洞, 其注意事项和风险与合作伙伴帐户漏洞的注意事项和风险相同 安全对策 在充分了解自己组织中存在的漏洞后, 您可以选择用以解决漏洞的对策 如何选择适当的安全对策要视需要解决的漏洞 每个被利用漏洞的危险程度因素以及可能性而定 正确选择合适的对策非常重要, 因为每个对策可以解决多个漏洞 此外, 实现对策还可对解决其他不属于初始威胁评估的次要漏洞产生有利影响 这些对策推动了对平台选择及其使用方式的要求 Contoso Pharmaceuticals 行动规划的安全要求包括 使用下列内容 : 自动置备和取消置备用户帐户 Kerberos 版本 5 身份验证协议 通用安全服务应用程序编程接口 (GSS API) 与 Kerberos 协议相集成 加密的客户端证书身份验证 Active Directory 的密码身份验证 Active Directory 的 Microsoft Passport 身份验证 在每个对策的结尾部分, 均详细列出了它们所能解 决的漏洞 除实现这些身份和访问管理对策外,Contoso 还采 取了其他一些措施, 包括 : 针对病毒威胁实施大规模防御, 如拦截列表和附 件过滤, 以及服务器和工作站病毒扫描程序 改进用以减少偶然系统滥用威胁的操作过程和培 训策略 改进物理网络和服务设计, 以减少机械方面的 威胁, 如停电 硬件故障及网络故障 定义明确的应对计划, 以防出现自然灾害 ( 如, 火灾 洪水和地震 ) 自动置备和取消置备 自动帐户置备和取消置备不但会大大提高生产效 率, 而且还能封杀多个安全漏洞 最重要的是, 即使 在员工离开公司时, 组织也无法取消激活其帐户 如果员工状况的来源可靠且存在一组管理员可集中 管理的已知应用程序身份存储, 则会自动进行帐户置 备 例如, 您可以编写 人力资源 (HR) 应用程序, 以生成每日员工状况表 然后可使用身份集成产品, 将 HR 应用程序员工状况与存储 ( 如目录和应用程序 ) 中 的数字身份状态合并在一起 部署注意事项 身份集成产品通常附带许多连接器或管理代理, 它 们提供允许身份信息同步的通信通道 此外, 还需要 一个或多个数字身份的可靠来源 通常, 来源可以是 78

79 身份和访问管理指南解决方案平台和基础结构 单一 ( 或集合形式 ) 的 HR 系统 承包商数据库及其他, 但每个组织的方案在某种程度上各有不同 Contoso 方案 Contoso 已经将其 HR 应用程序确定为身份状况信息的可靠来源 公司已经选择部署身份集成和置备产品, 以在不同存储 ( 如 Active Directory Lotus Notes Release 和 Sun ONE Directory Server 5.1) 中管理身份数据 当 HR 应用程序指出应置备新员工时, 该系统将会添加帐户或激活其他系统中的匹配帐户 当 HR 应用程序将某员工状况报告为终止时, 该系统将会删除相应帐户或取消激活其他系统中的匹配帐户 所解决的安全问题实现身份集成产品可以解决与帐户置备和取消置备相关的安全问题 在本指南 93 页 身份聚合和同步 一节中, 介绍了如何实现带 Service Pack 1 的 Microsoft Identity Integration Server 2003 Enterprise Edition( 带 SP1 的 MIIS 2003), 它是一款身份集成产品, 用于提供自动置备和取消置备员工帐户功能 使用 Kerberos 版本 5 身份验证协议在 Microsoft Windows 2000 中为微软平台引入的 Kerberos 版本 5 身份验证协议为网络身份验证协议提供了许多所需的安全特征 Kerberos 版本 5 协议具有很高的安全性, 它利用了最新的密码技术和协议设计 由于 Kerberos 协议的设计采纳了集中身份验证功能 ( 即 Kerberos 协议密钥分配中心 (KDC)) 的优点, 因此在通过使用相对寿命较长的票证卸载 KDC 工作时,Kerberos 协议还提供了更佳性能 部署注意事项在 Contoso 方案中,KDC 位于运行 Windows Server 2003 目录和安全服务的每个域控制器上 Kerberos 互操作性为基于 Windows 的操作系统 ( 甚至可能包括 UNIX 客户端 ) 提供了单一登录 (SSO) 体验的又一好处 Contoso 方案 Contoso 管理员计划将 UNIX 工作站配置为使用 Kerberos 版本 5 协议向 Active Directory 域控制器进行身份 验证 他们还计划配置 SAP R/3, 要求将安全网络通信 (SNC) 身份验证与 Kerberos 版本 5 协议相结合 所解决的安全问题 实现 Kerberos 版本 5 身份验证协议有助于解决以下 方面存在的安全问题 : UNIX 工作站帐户 SAP 身份验证 SAP 应用程序数据保护 在本指南第 104 页 Intranet 访问管理的方法 一 章中, 介绍了如何实现 Kerberos 版本 5 协议, 包括如 何在 SAP R/3 上配置 SNC 身份验证以及如何使用 Kerberos 和 Active Directory 配置 UNIX 工作站进行身份验证 将 GSS-API 和 Kerberos 的集成与 SAP 配合使用 SAP R/3 版本 4.0 提供对 SNC 的支持 一种 SNC 模 式允许与 GSS-API 集成, 通过 GSS-API, 您可以使用 Kerberos 版本 5 协议 一种 SNC 模式允许与 GSS-API 集成, 如 IETF RFC 中所述 在 GSS-API 与同样支持数据保密性和完整 性的安全协议配合使用时,GSS-API 将同时提供数据保 密性和完整性 Kerberos 版本 5 就是这样的协议 将 SAP 应用程序服务器和 SAP 图形用户界面 (GUI) 客户端配 置为同时使用 SAP SNC 和 Kerberos 版本 5 协议能够完全 保护 SAP 应用程序数据不被拦截 部署注意事项 SAP R/3 不实现 KDC, 而是使用已安装在网络环境 中的 KDC 在 Contoso 方案中,KDC 位于运行带有 Active Directory 的 Windows 2000 Server 或 Windows Server 2003 的 每个域控制器上 必须将 SAP 配置为使用 Kerberos 版本 5 身份验证协议 不过, 在配置了这项内容后,Kerberos 互操作性有了另一个好处, 就是为基于 Windows 和 UNIX 的客户端操作系统的 SSO 提供基础 79

80 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 Contoso 方案在 Contoso 方案中, 管理员已将 SAP R/3 配置为使用 SNC 身份验证, 并针对基于 Windows 的客户端工作站, 实现了 GSS API 以使用 Kerberos 版本 5 协议, 从而能够提供端到端的应用程序数据安全性 所解决的安全问题实现 GSS-API 和 Kerberos 版本 5 协议有助于解决以下方面存在的安全问题 : SAP 身份验证 因为客户端证书不需要密码, 所以, 需要通过工作站安全策略安全保管这些证书 Contoso 方案 Contoso 架构师配置了 销售和联系人 应用程序, 需要 TLS 和客户端证书身份验证 这包括设置认证机构 (CA) 以及将证书分配给销售部员工 所解决的安全问题实现加密的客户端证书身份验证有助于解决以下方面存在的安全问题 : SAP 应用程序数据保护 在本指南第 105 页 Intranet 访问管理的方法 一章中, 介绍了如何配置 SAP R/3 客户端, 以使用 SNC 将 GSS-API 和 Kerberos 协议集成在一起 使用明文密码进行身份验证 在不安全的服务器上存储明文密码 在本指南第 94 页 Extranet 访问管理 一节中, 介绍了如何配置加密的客户端证书身份验证 使用加密的客户端证书身份验证传输层安全 (TLS) 是安全套接字层 (SSL) 的互联网工程工作组 (IETF) 标准版本, 由 Netscape Communications 开发, 参见 IETF RFC 2246 通过使用数字证书,TLS 具有执行基于公钥客户端身份验证的功能 由于已经配置公钥基础结构 (PKI) 信任, 因此这个功能非常强大, 您在进行身份验证时可以使用 X.509 数字证书和相应的私钥来代替相对较弱的密码 为启用此解决方案, 您应创建一个影子帐户, 以代表在外围网络计算机中驻留的外部 Active Directory 中的用户 因为此帐户从不使用自身密码进行身份验证, 因此您可以设置一个不易破解的密码, 如使用随机生成的 24 位字符加密值 部署注意事项因为外部帐户只能通过使用有效的 X.509 证书进行访问, 所以, 如果员工没有 X.509 数字证书和相应私钥的访问权限, 则他们可能无法访问重要的业务应用程序 在这种情况下, 组织应考虑是否向员工授予临时访问外部应用程序的权限, 方法是通过重置帐户密码并将密码内容告诉给员工, 或者通过创建经由 Extranet 发行新证书的机制, 或者建立到内部网络的虚拟专用网络 (VPN) 连接 Active Directory 的密码身份验证 Active Directory 专门用于以安全方式存储极为敏感的信息 ( 如帐户密码 ) 在大多数情况下, 密码实际上并不以能够确定的原始密码形式进行存储 Active Directory 采用密码的加密散列 ( 单向加密 ) 方式, 通过使用 Windows Server 2003 提供的协议, 它足以提供身份验证 加密散列本身使用只有操作系统才能访问的加密密钥加以保护, 从而进一步防止极为敏感的密码遭到破坏 Active Directory 还提供了以安全方式执行基于密码的身份验证机制 换句话说, 在应用程序服务器和身份存储之间的网络上, 不必一定发送明文密码信息 例如, 安全身份验证机制可以是安全绑定 SSL 或 TLS 上的轻型目录访问协议 (LDAPS) 部署注意事项使用不同的帐户存储进行身份验证通常需要在应用程序中更改代码 使用数据库表进行身份验证的应用程序需要更新才能使用 Active Directory Contoso 方案 Contoso 为合作伙伴更新了 合作伙伴研究 应用程序, 以便将 Active Directory 用作合作伙伴帐户的身份存储以及用作访问管理的机制 80

81 身份和访问管理指南解决方案平台和基础结构 所解决的安全问题 实现 Active Directory 的密码身份验证有助于解决以 下方面存在的安全问题 : 使用明文密码进行身份验证 在不安全的服务器上存储明文密码 在本指南第 94 页 开发可识别身份的 ASP.NET 应 用程序 一节中, 介绍了应用程序如何通过使用 Active Directory 执行身份验证和授权 Active Directory 的 Microsoft Passport 身份验证 一项单独的使用性研究向 Contoso 架构师表明, 客户 正在受到试图管理不同 Web 站点的用户名和密码这一难题 的困扰 研究表明, 身份代理 ( 如 Microsoft Passport) 可以为客户提供身份验证, 使他们访问 Contoso Web 站 点的同时, 不需要维护额外的身份 这一方法还满足了 Contoso 的 客户试用反馈 应 用程序的安全要求, 因为客户帐户完全可以不再使用密 码 验证 Passport 凭据, 然后将 Passport 唯一 ID (PUID) 映射到外部 Active Directory 中的帐户, 从而对 Contoso 站点的用户进行身份验证 部署注意事项 使用服务 ( 如 Microsoft Passport) 进行身份验证时 通常需要在应用程序中更改代码 此外, 为支持特定授 权, 您必须通过可扩展和可管理机制在 Active Directory 中 置备大量的 Passport 映射帐户 ( 通过自动方式 ) Contoso 方案 Contoso 为客户重新编写了应用程序, 以便将 Microsoft Passport 和 Active Directory 用作客户帐户的身 份验证机制和身份存储 所解决的安全问题 实现 Active Directory 的 Microsoft Passport 身份验证 可解决下列问题 : 使用明文密码进行身份验证 在不安全的服务器上存储明文密码 在本指南第 94 页 Extranet 访问管理 一节中, 介绍了如何配置 Active Directory 的 Microsoft Passport 身 份验证 平台要求 Contoso 的业务和安全要求的分析结果产生了这样 的要求, 即身份和访问管理平台必须实现公司的要求 在以下各部分中介绍了平台必须解决的关键方面 访问管理 选定平台的访问管理服务必须提供用以实现以下要 求的身份验证 授权和信任服务 : 无论是客户端 / 服务器应用程序的客户端和服务 器操作系统, 还是文件和打印服务, 必须可以 交互操作, 以便执行无缝的身份验证并提供 SSO 用户体验 尽管全局身份信息仅在特定范围内 ( 如 intranet 或外围网络 ) 是全局的, 但全局授权权利必须 来自于此类信息 基础结构必须实现强大且可管理的授权机制 在组织内外, 平台必须提供灵活的信任机制 这 些信任可以是通过公钥基础结构 (PKI) 配置的显式信 任, 也可以是通过操作系统机制的隐式信任 基础结构必须实现可管理且安全的信任配置机 制, 以便为将来收购集成多个身份存储 目录和安全服务 选定平台的目录和安全服务必须支持 : 身份凭据的安全存储, 以便能够与安全且基于 标准的身份验证机制交互操作 LDAP, 以便与某些应用程序和服务交互操作 用户凭据和服务的强加密, 不得在服务之外分 发凭据信息 ( 即使以加密形式 ) 用以满足众多身份验证协议 ( 如,Kerberos 版 本 5 协议 生物测定 SSL 和 TLS) 要求的不同 类型的凭据 双因素身份验证机制, 包括 PKI 和智能卡 ( 用于 未来部署 ) 81

82 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 通过一组已知的应用程序和安全协议, 客户端 / 服务器操作系统之间的无缝互操作性 身份生命周期管理 选定平台的身份生命周期管理应实现下列要求 : 身份和访问管理基础结构应使用一组通用 基 于标准的协议来管理公司的身份存储 单一的目录应能够作为中央 Intranet 身份存储 在 出现硬件或网络故障时, 它必须提供冗余服务 在外围网络中隔离的 Extranet 目录将存储客户和 合作伙伴的用户帐户 应用程序平台 选定平台必须支持 Contoso 的应用程序要求 : 现有和规划的应用程序必须使用数字身份的基础 安全审核 结构, 它们必须能够通过通用 基于标准的协 议进行访问 应用程序服务器必须对强大的身份验证协议 ( 如 Kerberos 版本 5 协议 ) 提供内置支持, 以 及对使用 SSL 和 TLS 的客户端证书身份验证提供 支持 应用程序服务器必须能实现传统的访问控制列表 (ACL) 授权和基于角色的访问控制 选定平台必须支持 Contoso 的安全审核要求 : 平台必须为所有身份验证 信任 授权和配置 操作提供详细的审核功能 平台必须为服务器和应用程序基础结构的各个方 面提供可管理且特定的审核服务 82

83 身份和访问管理指南解决方案平台和基础结构 第 4 章 : 设计基础结构 Contoso 对多个供应商的身份和访问管理平台进行了评估, 其中也包括微软 根据公 司的要求,Contoso 选择在微软身份和访问管理平台上实现标准化 本章将讨论由这一决 策决定引发的基础结构设计 解决方案概念 Contoso 所需的各项主要功能通过微软身份和访问管理平台的以下特征实现 : Microsoft Active Directory 目录服务符合 因特网工程工作组 (IETF) RFC 3377 LDAP ( 版本 3.0) 规范 存有客户和合作伙伴帐户信息的 Extranet Active Directory 可以驻留在外围网络中, 支 持在与内部目录没有信任关系的情况下进行员工身份验证 Active Directory 提供了几种用户凭据强加密选项 由于此目录与强大的网络身份验证 协议 [ 例如 Kerberos 版本 5 身份验证协议 安全套接字层 (SSL) 或 传输层安全性 (TLS) 客户端身份验证 ] 集成在一起, 所以凭据绝不会分发到目录以外 Microsoft Windows Server 2003 中的 Active Directory 通过 Kerberos 版本 5 协议和摘要身 份验证协议支持基于密码的凭据 Active Directory 还通过 Kerberos 版本 5 协议 SSL 或 TLS 协议支持用于客户端身份验证的公钥基础结构 (PKI) 凭据 Active Directory 使用 Kerberos 版本 5 协议 SSL 和 TLS 协议来提供无缝的身份验证 桌面客户端操作系统 ( 例如 Microsoft Windows 2000 Professional Windows XP Professional 和运行 UNIX 或 Linux 的工作站 ) 通过 Kerberos 版本 5 轻型目录访问协议 (LDAP) 和其他基于标准的协议与服务器操作系统进行无缝交互操作以进行身份验证和 授权 Windows Server 2003 与许多客户端操作系统交互操作, 通过登录过程中计算或检索到 的一组默认凭据验证用户身份 这种身份验证对用户是透明的, 满足了用户的 SSO 体 验需求 Windows Server 2003 实现了访问控制列表 (ACL) 和基于角色的授权 Active Directory 拥有强大而灵活的机制来通过组成员身份表达权限 83

84 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 Windows Server 2003 目录和安全服务实现了多个 信任级别, 其中包括跨林信任 外部信任 PKI 信任和 UNIX Kerberos 领域的跨领域信任 带有 Active Directory 的 Windows Server 2003 为系 统中所执行的所有身份验证 信任 授权和配 置操作提供了详细的审核功能 解决方案体系结构 解决方案体系结构包含以下组件 : 目录服务 身份验证方法 授权方法 信任机制 身份生命周期管理 可识别身份的应用程序 目录服务 要想成功运作 Contoso 身份和访问管理平台,Contoso 团队需要确定用于创建身份信息的权威源和用于存储应 用程序和身份信息的权威位置 团队还需要在目录间实 现适当的属性信息流 该组织基础结构目前的目录服务配置情况如下 : 一个 Intranet Active Directory 林 一个 Extranet Active Directory 林 Sun One Directory Server 5.1( 以前称为 iplanet Directory Server) Extranet Active Directory 林不能用作权威的目录服 务, 因为它只包含员工的影子帐户 Sun One Directory Server 5.1 会在依赖它的应用程序被重写后将其淘汰, 以 便使用 Active Directory Intranet Active Directory 林提供了当前 Contoso 内用 户帐户的中央存储库 因此, 公司选择 Intranet Active Directory 作为所有目录和应用程序特定信息的权威源 Contoso 团队将使用身份集成产品来复制某些目录 对象, 以实现以下目标 : 在 Extranet 林中为销售部门的所有成员创建帐户 使用 Active Directory 中的某个属性来识别哪些员 工是从最近收购的公司加入到 Contoso 的 将这些帐户复制到 Lotus Notes Release 和 Sun ONE Directory Server 5.1 中 Intranet Active Directory 林 Intranet 林由空的根域 corp.contoso.com 和单一子域 na.corp.contoso.com 组成 na.corp.contoso.com 域包 含以下组织单位 (OU): 员工 Solaris 工作站 Windows 客户端 组 禁用 联系人 在 Windows Server 2003 上安装 Active Directory 和创 建 OU 的详细步骤将在产品文档中介绍 Extranet Active Directory 林 外部林只包含一个域 perimeter.contoso.com perimeter.contoso.com 域运行于 Windows Server 2003 功 能级, 并包含以下 OU: 员工 试用用户 组 内部林和外部林之间不存在信任关系 个中原因将 在本章后面有关 信任 的部分介绍 有关 Active Directory 的详细信息, 请参阅 Windows Server 2003 活动目录技术概述 ( com/china/windowsserver2003/techinfo/overview/ activedirectory.mspx) 有关其他指南, 请参阅 Active Directory 设计和 部署最佳实践 ( technet/community/columns/profwin/pw0302.mspx) 84

85 身份和访问管理指南解决方案平台和基础结构 库, 尤其是各种版本的 UNIX, 其中包括 Linux Contoso 将尽可能地使用 Kerberos 版本 5 协议, 因为它是一种基于标准的 高度安全的网络协议 许多平台都实施 Kerberos 版本 5 协议身份验证, 因此该协议能为实现互操作性奠定良好的基础 图 1:Contoso 的 Active Directory 结构 内部网络中所有受管的客户机 ( 包括运行 Windows XP Professional 和 Sun Solaris 操作系统的计算机 ) 都可使用 Kerberos 版本 5 协议登录到内部林中的帐户 登录后, 用户再次使用 Kerberos 版本 5 协议验证到特定资源 验证到 Extranet 目录外部网络采用多种不同类型的身份验证, 因为 Contoso 环境中面向 Internet 的应用程序目前并不支持 web 客户端的 Kerberos 版本 5 身份验证协议 Contoso 外围网络中托管的三个面向 Internet 的外部应用程序使用以下不同的身份验证方法 : 图 2:Contoso 基础结构中 Intranet 的身份 验证和授权机制 身份验证方法 Contoso 基于各种身份验证方法的特征及其运作环境选择了几种身份验证方法 如图 2 图 3 所示, 这一选择过程决定 Intranet 目录采用一种身份验证方法, Extranet 目录采用三种方法 验证到 Intranet 目录内部网络的主要身份验证机制是 Kerberos 版本 5 协议, 这是 Windows Server 2003 和 Windows XP Professional 本身所支持的协议 许多其他平台都包含 Kerberos 协议 图 3:Contoso 基础结构中 Extranet 的身份验证和 授权机制 85

86 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 书身份验证 所有这三种身份验证机制都使用 Extranet Active Directory 林作为身份存储 Extranet 域包含用于 Passport 和客户端证书身份验证的带有映射的用户帐户, 以及用 于基于 Windows 表单身份验证的秘密密码凭据 授权方法 Contoso 将使用的主要授权方法是在文件和打印服 务器上采用访问控制列表 (ACL)( 未显示在图 3 中 ) 但 Contoso 也会通过 Windows Server 2003 中的授权管理器 采用基于角色的访问控制 授权管理器与 Internet Information Services (IIS) 6.0 行交互, 来为 Web 应用程序访 问提供 URL 级授权和详细的应用程序级权限 Contoso 将使用安全组将用户组织起来 ( 例如按部 门或角色 ) 这些安全组会简化用户授权过程, 减少 组织内用户工作变动时所涉及到的管理工作 信任 在外部目录和内部基础结构目录之间实现联合时, Contoso 团队考虑了以下一组选择 : 跨林信任 Microsoft Passport Microsoft Windows 基于表单的身份验证 安全套接字层 (SSL) 和传输层安全性 (TLS) 客户端证 跨林信任 PKI 限定从属 影子帐户 Windows Server 2003 允许在林结构间使用信任关 系 Contoso 环境中考虑了这一选项, 这样使用外部应 用程序的员工可以通过信任关系验证到内部目录 公司的长远规划是创建和部署利用端到端身份验证 的应用程序 实现这一目标之前必须对内部网络安全性 进行彻底的分析, 然后根据需要采取纠正措施来修复发 现的所有问题 最后,Contoso 团队决定在组织环境中不建立这种 信任 之所以做出这样的决定有两个原因, 一个是 Contoso 环境的安全性问题, 另一个就是公司的应用环境目前不需要这种信任关系 就 Contoso 的情况而言, 主要问题是内部网络的安全性, 而不是由外部和内部林之间信任关系引起的其他应用程序功能的安全性 相反, 您所在组织的环境可能需要实现跨林信任 例如, 外部用户可能需要基于外部服务器进行身份验证, 并访问组织的 Intranet 中的信息 这种情况下, 可能需要用户身份随着应用程序请求从 Web 服务器传递到应用程序数据源 这可以使用新的 Kerberos 版本 5 协议委派功能和 Windows Server 2003 中的跨林信任机制来实现 PKI 限定从属公钥基础结构 (PKI) 为组织提供了使用公钥加密通过公共网络安全地交换数据的能力 PKI 由颁发数字证书的认证机构 (CA) 存储证书的目录( 包括 Windows 2000 Server 和 Windows Server 2003 中的 Active Directory) 及颁发给网络上安全实体的 X.509 证书组成 PKI 提供了对基于证书的凭据的验证, 并确保凭据不被吊销 损坏或修改 限定从属是交叉认证 CA 层次结构的过程, 这一过程中使用基本 策略 命名和应用程序约束条件来限制从合作伙伴 CA 层次结构或同一组织内的辅助层次结构中接受哪些证书 可以使用限定从属来定义组织信任由合作伙伴的 PKI 颁发的哪些证书 限定从属还提供了根据策略原则在组织内划分和控制证书颁发的方法 根据微软的最佳实践方法,Contoso 实现了三层 PKI 基础结构, 其中包括发证 CA 脱机中间颁发机构和脱机根 CA 然后,Contoso IIS 管理员向证书颁发机构申请服务器证书, 以在 IIS 上的 Internet Web 应用程序中启用 SSL 加密 Contoso 还在 Active Directory 中为员工启用了用户证书自动注册策略, 并在 IIS 中启用了 Active Directory Mapper 和客户端证书映射 有关跨林信任和 PKI 限定从属的详细信息, 请参阅 Microsoft.com 上的下列页面 : 使用 Windows Server 2003 规划和实现交叉认证和 限定从属 86

87 身份和访问管理指南解决方案平台和基础结构 有关部署微软证书服务的详细信息, 请阅读 设 计公钥基础结构 ( technet/security/guidance/secmod170.mspx) 影子帐户 公钥策略概念 公钥策略如何工作 Contoso 选择实现的联合设计通过在外部 Active Directory 中创建影子帐户, 来对外围网络应用程序中的内 部用户 ( 员工 ) 进行身份验证 这些影子帐户仅用于 进行基于证书的身份验证 影子帐户中包含有限数量的 与 Extranet 应用程序相关的授权信息, 例如名称和组成 员身份, 但不包括用户的帐户密码 销售部门的员工使用这些影子帐户访问外围网络中 所托管的应用程序 由于影子帐户对外部应用程序有足 够的访问权限, 所以并不需要外部和内部林之间存在任何信任关系 身份生命周期管理 为管理数字身份的生命周期,Contoso 选择了 Microsoft Identity Integration Server 2003 Enterprise Edition Service Pack 1 (MIIS 2003 SP1) 此产品为数字身份的有效同步 置备和取消置备提供了必要的身份集成支持 此外, 它还提供了允许与 Contoso 环境中的各种身份存储相连接的管理代理 Contoso 实现将使用微软证书服务和策略配置启用用户证书自动注册 自动注册功能使用户证书管理成为可能, 并提高了成本效益 在微软身份和访问管理框架中, 使用客户端证书进行用户身份验证最适合于能够明显增加安全性的环境 例如, 通过客户端证书身份验证, 可以避免使用密码验证到外围网络中托管销售和合同应用程序的服务器时所面临的安全风险 Contoso 只在其内部网络中部署证书服务和配置自动注册, 因为所有应用程序场合都不需要对外部客户和合作伙伴进行基于证书的身份验证 可识别身份的应用程序 为支持开发可识别身份的应用程序,Contoso 实现了尽可能将 Kerberos 版本 5 身份验证协议与 Active Directory 域控制器一起使用的策略 而不能使用 Kerberos 协议进行身份验证的应用程序 ( 例如,Extranet 应用程序 ) 将使用三种身份验证方式 : 在企业对企业 (B2B) 模式中使用基于 Windows 表单的身份验证, 在企业对客户 (B2C) 模式中采用 Microsoft Passport, 在企业对员工 (B2E) 模式中使用证书或智能卡 ( 将来 ) 永久对象 ( 例如目录中的文件和项 ) 的授权由访问控制列表 (ACL) 提供 基于 Web 的应用程序将采用使用授权管理器的 基于角色的访问 图 4:Contoso 身份和访问管理基础结构的网络布局 Contoso 网络 图 4 说明了 Contoso 完整的身份和访问管理体系结 87

88 微软安全指南 1 身份和访问管理指南解决方案平台和基础结构 构的实现 Contoso 身份和访问管理技术体系结构的实现包括 以下几个方面 : 将外部 Active Directory 与内部网络隔离的防火墙 Internet 与内部网络之间无直接连接 Internet 与外部 Active Directory 之间无直接连接 独立的 Extranet 林 Extranet 中运行 IIS 6.0 的两台 Web 服务器, 其上 托管了公司销售员工和客户的应用程序 一个外围网络 Web 服务器, 它还托管着证书吊 销列表 (CRL) 分配点来检查员工在验证到外部应 用程序时所使用的证书 将服务作为内部网络的一部分提供的 Lotus Notes Release 应用程序和 Sun ONE Directory Server 5.1 内部网络上的证书服务 Contoso 身份和访问管理平台基于微软和许多前沿 硬件和软件供应商所开发的 Windows Server System 参考 体系结构 (WSSRA) WSSRA( 以前的 Microsoft Systems Architecture 2.0 或 MSA) 提供了经测试过的步进指令来 基于微软技术实现大规模 IT 基础结构 有关 WSSRA 的详细信息, 请参阅 Microsoft Windows 服务器系统参考架构 ( com/china/windowsserver2003/wssra/default.mspx) 启用的解决方案 微软平台基础结构启用了以下解决方案 : 跨多个目录的身份聚合和同步 密码管理, 包括将密码传播到多个目录 Intranet 访问管理, 包括 UNIX 和 SAP 与 Active Directory 的集成 Extranet 访问管理, 包括对 B2B B2C 和 B2E 环 境的支持 开发可识别身份的 ASP.NET 应用程序, 包括对 Intranet 和 Extranet 应用程序开发的支持 公司的基本策略是在数字身份的管理中引入自动而 高效的管理过程, 来替代手动而低效的管理过程 本指 南后续部分将非常详细地介绍下面概括的所有目标领域 身份聚合和同步 为在组织内提供身份聚合和同步,Contoso 选择使 用 MIIS 2003 SP1 作为身份集成产品, 它将与公司的所 有目录服务和其他身份存储集成, 其中包括 : Intranet Active Directory 林 Extranet Active Directory 林 ( 包括客户 合作伙 密码管理 伴和员工影子帐户 ) SunOne Directory Server 5.1( 以前的 iplanet Directory Server) Lotus Notes Release 为实现有效的密码管理,Contoso 选择了以下组件 : Active Directory 中的组策略, 用于实施密码强 度 复杂性和过期时间 自定义的密码筛选器和通知动态链接库 (DLL), 使 用户能够更改其在 Active Directory 中的密码, 然 后将更改后的密码传播到其他目录和身份存储 带有管理代理 (MA) 的 MIIS 2003, 用于管理所有 连接目录的密码变更 使用 Windows 管理规范 (WMI) 的自定义 Windows 服务, 在 Active Directory 域控制器和 MIIS 2003 MA 之间提供了桥梁 这两者的组合会将密码变 更传播到 Lotus Notes Release 和 Sun One Directory Server 5.1 MIIS 2003 所附带的自定义 Web 应用程序, 使 帮 助台 操作员可以在一个位置重置用户密码 然 后,MIIS 2003 将密码更改传播到所连接的目录 Intranet 访问管理 针对 Intranet 访问管理,Contoso 对以下配置进行 了标准化 : 88

89 身份和访问管理指南解决方案平台和基础结构 使用 Kerberos 版本 5 身份验证协议进行身份验证 和数据保护 针对使用 Kerberos 版本 5 协议进行的身份验证, 使用 Active Directory 域控制器作为密钥分发中心 (KDC) 针对使用 Kerberos 版本 5 协议进行的身份验证, 在 SAP R/3 和 UNIX 工作站上启用应用程序支持 Extranet 访问管理 针对 Extranet 访问管理,Contoso 选择了以下体系 结构来为合作伙伴 客户和员工授予访问 Web 应用程序 的权限 : 一个外部 Active Directory 林, 用于管理所有外部 用户的帐户 自我注册, 用于在 Active Directory 中建立客户帐户 Microsoft Passport 服务, 用于客户身份验证和 SSO 带有 SSL 加密的基于表单的身份验证, 用于保护 合作伙伴身份验证顺序 MIIS 2003, 用于向外部 Active Directory 林置备员 工影子帐户 Microsoft Windows 授权管理器, 用于基于角色 的授权 用于 PKI 的微软证书服务 IIS 6.0, 用于托管 Web 应用程序 Microsoft Internet Security and Acceleration Server (ISA), 用于在内部网络和外部网络之间提供外围 网络及访问控制 开发可识别身份的 ASP.NET 应用程序 为确保开发可识别身份的应用程序时的一致性, Contoso 对以下方法进行了标准化 : 对 Intranet 应用程序使用 Kerberos 版本 5 协议 在应用程序 Web 服务器和后端资源之间使用 Kerberos 身份验证 执行与 Active Directory 的身份验证和授权集成, 这将为应用程序提供唯一的目录服务 在 Web 应用程序内使用基于角色的访问控制, 在后端服务器资源上使用 ACL 本部分略有删节, 完整内容请查看 : /security/topics/identitymanagement/idmanage 89

90 微软安全指南 1 身份和访问管理指南解决方案访问管理和单一登录 第三部分 : 访问管理和单一登录 文章概述 本部分阐述了通过与 Windows Server 2003 目录和安全服务进行集成来改进 Intranet 访 问管理的业务挑战 安全问题 工具和协议 本部分由以下四章组成 : 第 1 章 : 简介 介绍文章中的材料涵盖的两种主要应用场景 第 2 章 :Intranet 访问管理的方法 本章阐述了改进 Intranet 访问管理的不同方法, 其中包括 : 直接与基于 Microsoft Windows 的服务器和客户端操作系统集成 与基于 Windows 的目录和安全服务进行自定义集成 通过轻型目录访问协议 (LDAP) 进行集成 使用企业单一登录 (ESSO) 产品的凭据映射技术 跨多个系统同步用户帐户和密码 本章列出了每种方法的优缺点并重点介绍了每种方法最适用的情况 第 3 章 : 问题和要求 本章对 Contoso Pharmaceuticals 应用场景进行研究, 重点 介绍了在 Contoso 环境中改进 Intranet 访问管理的技术问题和要求 第 4 章 : 设计解决方案 本章说明两种 Contoso 解决方案应用场景的设计 它使用 上一章中的信息来描述每种应用场景的 Intranet 访问管理组件及它们交互操作的方式 解决方案应用场景 第 3 章到第 7 章介绍了以下两种解决方案应用场景的设计和实施细节 : 集成 UNIX 工作站和 Active Directory 通过使用 Kerberos 集成 SAP R/3 应用服务器身份验证 编制这些应用场景的目的是体现希望提供 Intranet 访问管理服务的组织所面临的典型挑 战 提供了有关微软技术如何能够解决此类挑战的详细规定性指导 90

91 身份和访问管理指南解决方案访问管理和单一登录 虚构的公司 Contoso Pharmaceuticals( 在本指南第 二部分 平台和基础结构 中做过详细的介绍 ) 将作 为规定性指导示例中的组织 将 UNIX 工作站与 Active Directory 相集成 将 UNIX 工作站与 Active Directory 相集成可使组织具 有以下重要优点 : 无论用户的工作站是运行 Windows 还是 UNIX 操 作系统, 只使用一组凭据就可从该工作站登录 到 Active Directory 用于 UNIX 工作站的帐户可从应用于基于 Windows 的工作站用户的相同用户帐户安全策略中受益 集成了 Active Directory 的 Kerberos 版本 5 协议密 钥分发中心 (KDC) 可为 UNIX 工作站用户提供基于 Kerberos 的凭据, 使他们能够以安全的方式无缝 地访问网络资源 IT 管理员集中精力在 Active Directory 中管理一组 工作站用户即可 该解决方案应用场景演示如何将运行 Sun Solaris 版 本 9 操作系统的 UNIX 工作站配置为 Microsoft Windows Server 2003 域的一部分, 然后通过使用 Kerberos 版本 5 协议来验证 Active Directory 用户的身份 有关如何将 UNIX 服务器和基于 UNIX 服务器的应用 程序与 Active Directory 集成的指导和应用场景的详细信 息, 请参阅针对 UNIX 的 Microsoft Windows 目录和安全 服务解决方案指南 使用 Kerberos 协议集成 SAP R/3 应用服务器 身份验证 包括 SAP 之类的企业资源计划 (ERP) 应用程序在内的 关键任务应用程序通常部署在具有自己的身份存储和身 份验证机制的企业环境中 实施应用程序特定的身份存 储会带来管理 可用性问题以及往往会出现的安全性问 题, 这些问题是您的组织应予解决的 解决这些问题的方法之一是将应用程序与 Active Directory 这样基于标准的身份存储进行集成 SAP R/3 应用服务器便是一个第三方通用平台产品的示例, 它通 过 Kerberos 版本 5 协议与 Active Directory 集成 使用 Kerberos 版本 5 协议将应用程序与 Active Directory 集成具有以下优点 : 用户在使用其桌面登录凭据访问应用程序时可获 得 SSO 的益处 您可以使用 Kerberos 版本 5 协议来提供一个安全 的客户端 / 服务器应用程序数据通道 可减少管理应用程序特定的身份存储的需要, 有时甚至可以不必进行管理 在此应用场景中,SAP R/3 应用服务器将 Active Directory 体映射到 SAP 身份存储中的某个帐户 虽然这并 没有完全免除在 SAP 内置备及管理用户权限的工作 ( 出 于 SAP 授权目的, 仍然需要进行这些工作 ), 但由于 不再需要不同的用户密码, 因此减少了管理负荷 同 样, 取消用户对多个资源 ( 包括 SAP) 的访问权限变 得更简单, 因为在 Active Directory 中禁用用户帐户也会 防止用户通过接受身份验证访问 SAP 有关其他在 SAP R/3 应用服务器和 Active Directory 之间进行集成的备选方案, 请下载 SAP 和 Active Directory 身份管理 白皮书 有关 SAP 与 Active Directory 集成的更全面信息, SAP 客户可以通过使用其 SAP extranet 凭据登录 SAP 服务 市场的微软部分来获得 91

92 微软安全指南 1 身份和访问管理指南解决方案访问管理和单一登录 第 1 章 : 简介 集成应用程序和平台的公共 Intranet 访问管理基础结构可使试图改进数字身份使用和管理的组织显著受益 例如, 使用一组标准的安全协议和取消冗余身份存储可以简化基础结构 减少管理工作 实现单一登录 (SSO) 以及简化安全审核 这些益处主要体现在财务上, 其中包括管理成本 许可费用和应用程序开发成本的降低 其他益处包括安全性得到提高 ( 由于减小了攻击面 ) 和在保护对敏感组织数据的访问上有了更好的选择 从技术层面上讲, 通过与常见目录和安全服务紧密集成来改进 Intranet 访问管理非常具有挑战性 这种挑战的很大一部分源自一个事实, 即目前几乎没有有关如何配置平台和应用程序以实现互操作性的简明指南 本指南就旨在解决这一问题, 并对所涉及的业务挑战 安全问题 工具以及协议做了阐述 本指南所面向的读者 本指南的预期读者包括参与身份和访问管理工作的架构师 IT 专业人员和经理 技术 决策制定者和顾问 我们的挑战 在过去十年中, 各组织在技术基础结构上进行了巨额投资, 但在许多情况下, 基础结 构的作用没有得到充分发挥 几乎每个组织都在不经意间部署了具有竞争关系并且重叠的技 术解决方案来解决常见的 Intranet 访问管理问题 大多数组织会遇到与 Intranet 访问管理有关的下列常见业务挑战 : 应用程序之间没有 SSO 功能, 导致用户混乱 生产力降低及帮助台和管理成本增加 由于存在多个身份存储, 导致出现大量密码重置请求 由于采用多种不一致的安全服务方法 ( 如身份验证和授权 ), 对重要业务数据实施 全面保护变得困难 许多组织的员工每天要花费超过一刻钟的时间登录不同的操作系统 目录服务和应用程 序 对于一个拥有 10,000 名计算机用户的组织来说, 采用多种身份验证机制意味着这些用 户每天要耗费 2,666 小时 ( 资料来源 :2002 年 6 月代表 PricewaterhouseCoopers 进行的 META Group 研究 ) 92

93 身份和访问管理指南解决方案访问管理和单一登录 多个具有不同身份存储的应用程序通常要求提供不 同的用户名和密码, 这会直接导致帮助台密码重置请求 响应成本的增加 数据保护是现今组织关注的中心 对许多公司来 说, 产品 客户和财务状况方面的数据是它们很大的 一部分资本, 因此知识工人访问及操作这些数据时对其 提供保护至关重要 除了由数据泄露而导致的竞争性威 胁外, 在许多业务领域监管机构对数据保护的要求也有 显著增加 如果不能达到此类要求, 可能会导致组织 受到经济处罚或失去客户信任或在这两方面都受损 企业益处 在组织内部实施有效力的 Intranet 访问管理可给企 业带来诸多益处, 其中包括 : 提高用户生产力 如果计算机用户每天在身份验 证上花费的时间可以从 16 分钟降低到 2 分钟, 拥 有 10,000 名用户的组织每天可节省 2,300 多个小时 的时间, 这大致相当于一名全职员工一年的工 时 SSO 可以简化该过程, 因为它使知识工人 的生产力提高了 15%, 将登录效率提高了 18% 降低帮助台成本 由于用户需要记忆的登录凭 据数量减少了, 因此他们遵守安全策略的能力 得到了提高, 而且帮助台收到的用户密码重置 请求数量也减少了 提高网络安全性 登录凭据数量的减少还有助 于提高网络的安全性, 因为它减少了用户使用 不适当的技术来管理多个密码 ( 如将它们记录 下来 ) 的可能性 改进数据保护 最佳基础结构产品的安全功能 可增强数据保护并使组织能够达到监管要求 基础结构整合 创建以平台和应用程序集成为 目的的环境使组织可以整合多个身份存储, 使 管理成本和许可成本都得到降低 减少管理 对组织的大部分应用程序实施跨平 台访问管理可帮助组织从身份存储整合投资上获 得更大的回报 存在这种可能性是因为管理开 销的降低会节约相关成本 要实施本章概述的两种解决方案, 读者应能理解本 指南第二部分 平台和基础结构 中描述的基础结构及 执行此类基础结构的方法 不同的解决方案应用场景会 有以下附加要求 : 第一种解决方案应用场景要求您熟悉 UNIX 管理 和配置 第二种解决方案应用场景要求您熟悉 SAP 管理和 配置 93

94 微软安全指南 1 身份和访问管理指南解决方案访问管理和单一登录 第 2 章 :Intranet 访问管理的方法 对于采用微软技术的组织而言, 存在许多可以改善组织内部 Intranet 访问管理的途径 通过迁移平台和应用程序以使用公用的身份验证和授权安全服务, 可以实现用户的单一登录 (SSO) 改善安全审核 充分利用现有的信任关系 合并基础结构 减少管理开销 提 高网络安全性 本文还包含指向英文网页的链接 然而, 并非所有的方法都具有高效 易实施或安全性这些特点 这些方法包括 ( 按 优先级别排列 ): 应用程序与 Windows 安全服务集成 这种方法通过开发并迁移应用程序, 使用包括 身份验证和授权在内的 Microsoft Windows 平台安全服务 与 Windows 安全服务的 集成可以降低应用程序的开发成本, 并使应用程序易于使用 Windows 操作系统的 SSO 信任和安全审核功能 平台与 Windows 目录和安全服务集成 这种方法将其他平台配置为使用由 Microsoft Active Directory 目录服务支持的目录和安全服务, 实现了跨平台互操作性, 并降低 了管理强度 应用程序与 Windows 目录服务集成 开发并迁移应用程序, 让其使用 Active Directory 所支持的标准目录协议进行身份验证和授权, 从而实现了身份存储的整合 通过凭据映射间接集成 当应用程序和平台不能直接集成时, 凭据映射 ( 也称企业 单一登录或 ESSO) 可以为用户提供 SSO 体验 同步的帐户和密码 当其他选项均不可用并且预计存在安全性风险时, 在不同应用 程序和平台间使用公用的凭据可以减少用户的困扰 根据主机系统的能力 更改应用程序的能力或实施解决方案的预期投资回报率 (ROI), 可以选择优先级较低的方法 应用程序与 Windows 安全服务集成 将应用程序与 Windows 安全服务集成 ( 也称为 Windows 集成应用程序 ) 的益处如下 : 对基于 Windows 的客户端实现 SSO 通过网络传输的应用程序数据具有更高的安全性 对 Active Directory 中数字身份的管理更有效 94

95 身份和访问管理指南解决方案访问管理和单一登录 能够跨多个应用程序建立企业级安全组和基于角 色的访问控制 利用有限的管理开销, 通过信任关系扩展了身 份验证和授权服务的范围 集成的安全事件记录 此部分通过探讨下列主题, 介绍了许多 Windows 集成应用程序的益处 : Windows SSO 和访问管理 Windows 集成应用程序的示例 Windows 单一登录和访问管理 在运行 Microsoft Windows XP Professional 和 Windows 2000 Professional 等基于 Microsoft Windows 的操作 系统 ( 以及 Windows Server 2003 等充当客户端的任何 服务器产品 ) 的客户端计算机中, 包括一些允许在客 户端和服务器连接到 Windows 域或林后实现 SSO 的内置 功能 如本指南第一部分 基本概念 所述, 在域或 林之间建立信任即可实现跨域 SSO 随 Windows 安全服务实现的下列特征提供了 SSO 能力 : 由本地安全授权 (LSA) 管理的凭据缓存 一套与 LSA 集成的身份验证数据包 图 1:Windows 集成的桌面登录身份验证过程 若要了解 Windows 安全服务如何支持 SSO, 需要了解 Windows 登录过程 以下几部分概括介绍在这一过程中如何实现 SSO 登录过程 Windows 操作系统中, 用户登录机制是客户端计算机和网络不可分割的组成部分 用户只需用其域凭据向网络验证一次 用户通过这次单一的登录, 登录到工作站并访问拥有访问权限的任何本地或远程资源 登录过程见图 1 在登录过程中, 用户通过按 CTRL+ALT+DEL 调用 图形识别与身份验证 DLL (GINA) 这就是安全身份验证序列 (SAS), 它将 Windows 登录对话框展示给用户 ( 第 1 步 ) 然后, 用户将其凭据输入到登录对话框中 接着, 本地安全授权 (LSA) 向运行 Active Directory 的域控制器发出 票证授予票证 (TGT) 请求, 也称 TGT-REQ( 第 2 步 ) 在域控制器的 LSA 服务中运行的 Kerberos 版本 5 协议密钥分发中心 (KDC) 通过调用域控制器上的服务帐户管理器 (SAM) 验证用户名和密码 ( 第 3 步 ) 如果凭据正确, 又没有其他策略元素 ( 如时间或工作站限制 ) 阻止用户登录, 域控制器上的 LSA 会将 Kerberos 版本 5 身份验证协议票证 ( 第 4 步 ) 或 NT LAN 管理器 (NTLM) 授权数据 ( 未显示 ) 传递回客户端的 LSA [ 注意 ] Windows 客户端和服务器的身份验证数据包 ( 也称身份验证提供程序 ) 中还实现了一些其他身份验证协议, 但本文主要讲述 Kerberos 版本 5 身份验证协议, 只在适当的情况下提及了 NTLM 构建授权上下文在 Kerberos 票证中, 有一个称为 特权属性证书 (PAC) 的部分, 其中包含着用户及用户所属组的安全标识符 (SID) 信息 此结构如图 2 所示 工作站从 Kerberos 票证 ( 图 1 中的第 5 步 ) 或 NTLM 授权数据构造一个访问令牌 ( 这有时也称为安全上下文, 但在讨论本地 95

96 微软安全指南 1 身份和访问管理指南解决方案访问管理和单一登录 份验证协议提供程序与工作站上 LSA 的集成, 为基于 Windows 的用户创造了 SSO 体验 图 3 说明了这一过 程 在本例中, 假定工作站的登录是通过 Kerberos 协议完成的,Kerberos 协议是 Microsoft Windows 2000 和 Windows Server 2003 中的默认身份验证机制 如果初始登录是通过 NTLM 协议完成的, 这一序列会有所不同 授权而非网络身份验证时, 称之为访问令牌更为准确 ) Windows 访问令牌中包含 : 用户的主 SID 户域不同 ) 客户端计算机的登录序列会启动一个 shell 实例 ( 通常是 Explorer.exe 文件 ) 并将用户的 访问令牌附加到 shell( 图 1 中的第 6 步 ) 图 2:Kerberos 票证包含 PAC, 而 PAC 包含用户 和组的 SID 来自用户帐户 域或林的全局组 SID 和通用组 SID 来自工作站域的域本地 SID( 如果工作站域与用 明确分配给用户或派生自组成员身份的权限 用户尝试访问运行 Windows Server 2003 的远程计算机上的文件 ( 第 1 步 ) 服务器要求进行身份验证并对用户发出 质询 ( 第 2 步 ) 然后, 客户端上的 LSA 调用 Kerberos 身份验证数据包来请求必要的身份验证凭据 ( 第 3 步 ) Kerberos 身份验证数据包通过从客户端的票证缓存中检索先前发出的有效票证 ( 第 4 步 ) 或从 KDC 中为服务器请求新票证 (TKT)( 未显示 ), 来满足请求 最后, 客户端通过将票证发送到服务器来回应服务器的质询 ( 第 5 步 ) 在票证验证完毕后 ( 第 6 步 ),Kerberos 身份验证提供程序构建一个如之前所述的访问令牌 ( 第 7 步 ) 通过此令牌, 服务器可以模拟 ( 第 8 步 ) 客户端用户 有了这种模拟, 服务器可以将在访问令牌中获取的用户权限与资源上的 ACL 进行比较, 从而依靠操 访问本地资源在工作站上, 所有从 shell 启动的应用程序将从 shell 进程中继承访问令牌 因此, 在用户登录之后, 任何访问本地资源的尝试 ( 如从 shell 或任何 shell 所启动进程打开文件或打印文档 ) 都会使工作站将用户的访问令牌与被访问对象上的安全访问控制列表 (ACL) 进行比较 访问远程资源用户每次尝试对远程资源执行操作 ( 如打开网络文件共享位置的文件或在网络打印机上打印文档 ) 时, 客户端和服务器都会执行身份验证序列 默认情况下, 身份验证序列与工作站登录使用相同的凭据 Kerberos 和 NTLM 身 图 3: 远程资源登录的身份验证过程 96