原文地址：
http://www-01.ibm.com/software/cn/tivoli/solution/security/access_manager.html



如何运用 Tivoli Access Manager 和 Tivoli Privacy Manager 满足客户的“数据级授权”需求

本文的目的是澄清“数据级授权”的使用情况，在数据级授权中，Tivoli Privacy Manager (TPM) 增加了Tivoli Access Manager (TAM) 电子商务软件的价值。
客户的痛苦
随着企业收集和共享敏感信息的能力不断提升，他们管理和执行“适当使用”公司策略或传统安全策略的能力却严重下降了。外部动因提高了企业对这个问题的认识，如遵守隐私保护法规及解决以前的隐私保护（和安全）违规等。业务（收入）动因主要包括：通过始终尊重个人选择提供更加丰富的用户体验、更快地部署应用程序以及通过自动化（如集中管理策略和在企业范围执行它们）降低安全管理成本。

有些客户将他们无法实现或管理数据的“适当使用”概括为“数据级授权”问题，并且正在从企业、规章和法律角度考虑这个问题。安全管理工具的出现使企业范围的“数据级授权”成为更加合理的目标，但是必须了解这种需求背后的动因是什么。

传统上，客户采用以下方法来解决“数据级授权”问题：

1. 什么都不做！
2. 依靠基本数据引擎的安全性。例如，Oracle 或 DB2 等解决方案都在数据级植入了安全机制。
3. 使用自定义 API 使数据级安全性内在化的应用程序
4. 利用 IBM Tivoli Access Manager 等工具，使用自定义 API 提供数据级安全性的应用程序
5. 运用硬编码的安全控件，向不同的用户组部署同一应用程序的多个版本。

客户已开始认识到这些方法根本不能长期使用，因为它们不能扩展，过于依赖特定技术或应用程序，而且无法解决上述企业痛苦。好消息！IBM 现有的解决方案可以解决这些问题。

解决方案

凭借 Tivoli Access Manager (TAM) 电子商务软件，IBM 提供了一个集成的安全管理平台，不仅能够集中安全策略管理，还能执行用户身份验证和应用程序授权。这减少了应用程序开发和部署以及安全管理的成本。

Tivoli Privacy Manager (TPM) 电子商务软件融合了数据主体隐私保护选择，并能对可标识个人身份的信息的特定请求进行业务用途验证，从而增强了 TAM 的价值。它还能通过核查记录和报告帮助客户遵循安全策略。必须区分 Privacy Manager 使用的策略是信息处理策略，而不是访问控制策略。隐私保护主要解决收集信息的企业与被收集信息的所有者（或数据主体）之间的关系。

TPM 主要针对需要遵循隐私保护方面的法律或法规要求的客户，特别是企业如何融合不同客户的数据使用选择以及在他们的业务过程中使用这些数据的适当业务用途。理想的 TPM 潜在客户不仅从遵守法规的角度来看待这种能力，而且还将它视为一种战略竞争特色 — 由于能够一致地应用各个隐私保护选择，通过数据仓库或服务器和应用程序整合来降低成本，因此可实现多种类型的数据共享。
传统方法
作为一个功能丰富的安全平台，TAM 支持应用程序能够借以确保数据访问安全性的自定义授权接口。TAM 的 C 和 Java API 集成了主体标识和一个制定访问控制决策的对象或资源。数据本身一般存储在关系型数据库或专有数据储存库中。数据级访问控制决策通过比较数据权利和主体凭证做出（主体凭证可以动态维护，也可以根据业务环境动态更改）。访问控制可以在应用程序方法级也可以在数据元素级进行，因而据此允许或拒绝访问。

以下示例描述了可以利用 Tivoli Access Manager 做出的这些访问控制决策。

    * 某个供应链组织内的一个提供商仅有权提交低于 10 万美元的采购单。
    * 如果客户从某个信用评估机构获得的信用分数达到 3，则可以注册由金融服务机构管理的 401K。
    * 金牌或铂金客户有权在 12 月获得其在线购买的免费发运
    * 客户的信用卡数据可供客户以及信用卡发卡公司的客户关系部门访问。
    * 只有主治医师有关提供患者治疗安排。

规则严格按照应用程序或应用程序的资源管理器进行描述。

例如，假设股票经纪人访问股票交易应用程序来下单交易。根据 SEC 规则，未通过其 Series 7s 的股票经纪人的交易限额为 1000 美元，而对于通过的经纪人，交易限额最高可达 50,000 美元。由于这种环境是数据用户的一个属性，因此可以向执行交易的方法附加一个单一规则，这个规则使用交易限额（或通过 Series 7）环境来制定其访问决策。随着时间推移，股票经纪人还需要重新认证，因此该属性可以由应用程序动态生成，但是单一规则仍然适用。

现在假设还有另一个决定某个类型股票可以交易的最大批量的业务规则。在这种情况下，该批量是制定允许或拒绝决策所需的环境，而且与通过用户的属性和/或方法级访问控制相比，可以更加简单地定义每个数据事例的访问控制规则。这要求预先进行某种数据分类，但是由于您的努力，可以更加简单地执行规则，因为您拥有不受特定方法限制而受数据事例限制的额外环境。另外，通过执行核查来确保符合 Series 7 规定，可以减少所用的时间，因为您可以指向您基于某个数据事例的规则（或者更有可能指向表明符合规定的报告）。有些情形下，特别是涉及隐私保护的情形，在方法级执行是不切实际或不可能的，因为管理数据的规则随数据事例而异。此外，隐私保护还具有集成个人数据使用选择的额外复杂性。

“隐私保护”的使用情形

为建立和管理信息收集者（数据用户）与被收集信息的所有者（数据主体）之间的关系，TPM 提供了一个模型，可用来创建由隐私保护语句组成的高级隐私保护策略。隐私保护策略语句定义了：
1. 收集和访问的信息的类型
2. 能够访问所收集信息的人员
3. 围绕这些信息的个人参加或退出选择
4. 访问信息的用途

因此，TPM 能够将数据分类为可标识个人身份的信息 (PII)，利用用户对 TAM 的映象进行分组，收集和集成数据主体选择，将请求的高级用途映象为特定的应用程序任务。用途用作应用程序任务、API 调用或事务的分类。结合这些概念可提供“基于用途的授权”；并能授权使用已被分类为 PII 并链接到隐私保护策略中定义的更高级用途的数据。换句话说，它为企业提供了根据（业务）用途和个人赞成来控制或核查访问的能力。

TPM 为那些寻求（在某些情况下必须具有）以下能力的客户提供了独特的价值主张：(1) 在他们的安全基础架构中附加或使用更高级别的隐私保护策略，(2) 对他们的 PII 数据进行分类，以及 (3) 为与 (1) 和 (2) 有关的数据使用提供核查报表。使用业务条款定义隐私保护语句、提供执行功能以及利用相同业务条款生成报表的能力是一种表明符合广大用户（客户、管理者、核查人员或内部管理委员会）需要的强大机制。企业希望在每天下班时回答访问敏感数据的特定请求是否 (1) 符合业务策略， (2) 符合受影响人员的希望。这些问题的回答超越了“数据级授权”的传统看法，而 TPM 可以给 TAM 增加这些独特的功能。

以下为隐私保护语句的示例：

1. “只有个人提供了明确授权，市场部的人员才能观看个人的信用得分来开发贷款产品。”
2. “血液病调查员不能观看标识数据，但可以观看‘验血’类别的医疗数据（患者 ID 和邮编除外），而且只有患者和提供者都同意提供该记录才行”
3. 只有对方允许，配偶才能观看对方的健康保险索赔记录。

“机密”的使用情形

显然，当客户需要在他们的应用程序内解决隐私保护策略的执行问题时，TPM 可以解决这个问题。尽管 TPM 是能够对数据分类和将用户偏好融合到访问请求中的唯一产品，但实际上也可以使用 TAM。如前面的股票经纪人示例中所述，通过进行适当配置，TAM 可提供“数据级授权”。
但是，当客户希望针对没有隐私保护要求的特定数据事例（例如，不是 PII）执行授权时，将会出现问题。

例如，一家制造公司希望与其业务合作协作，共享设计和业务提案以赢得项目竞标。在一些项目竞标中，该制造商可能与某个既定的业务伙伴合作，而在其它项目中，他们可能是竞争对手；有时，不同的业务伙伴会相互竞争。该制造公司希望对特定文件应用数据级控制，以便与业务伙伴一起保持机密。这可以视为一个与“隐私保护”问题相反的“机密”问题，而且具有更广泛的影响。

另一个使用情形是一家连锁饭店，它要维护全球不同特许店入住率的实时信息。该连锁饭店希望与其特许店共享这些信息，但是，有些特许店拥有自己的直接与其它特许店竞争的产业；连锁店希望根据特许店的标识、数据类型以及与其它特许店的业务关系执行数据级授权，从而尊重公司的机密。

在上述情形中，所有客户要求都需要在提供解决方案之前适当地确定范围，包括部署简便性、数据环境的复杂性或核查需求等。如前所述，TAM 提供的 XML 规则引擎能够解决对“容器”的有条件访问控制，容器可能是 URL、文件，也可能是对象，包括数据对象。TAM 规则引擎为在访问控制决策中附加业务逻辑提供了一种快速方法；但是，逻辑附加的粒度由应用程序容器定义。换句话说，如果所有数据都与容器相关联或结合在一起，则 TAM 规则引擎是这种情形的理想技术（可回忆以下股票经纪人示例）。

但是，如果业务规则的范围受数据事例的约束（换句话说，并非所有数据都在一个容器内相关联），则根据数据事例设置规则的能力提供了一种备用机制。如果需要在并非通过一个层次描述的多个保护资源中共享一个策略，或者如果资源已通过授权机制而不是 TAM 进行保护，则上述能力特别有用。这也促进了企业角度的策略应用。

需要澄清的是，TPM 提供的框架要求客户 (1) 对他们的数据进行分类，(2) 将高级策略映象到低级应用程序任务中；从部署传统安全机制的角度看，这两者都不是微不足道或费用不高的活动。但是，从建立企业范围信息处理策略的角度看，这种方法使客户能够根据他们分类被保护数据的意愿程度应用粒度级别。有些受到严厉管制的行业，比如保健和金融服务或者与政府达成合同的私营公司，对这个问题几乎没有选择权，因为他们需要证明他们在法律上符合这些规定。为公平起见，大多数企业都以其感觉需要的级别进行数据分类（可能象两个类型一样简单），因而减轻了负担。一般情况下，他们会响应隐私保护要求，但是也适用“机密”使用情形。

在“机密”使用情形中推荐 TAM 或 TPM 的关键在于数据模型的复杂性（数据分类会减轻这种复杂程度，但是在执行分类时客户必须看到一个开始执行的值）、控制点的数量（控制点具有能够共享的策略，可促进管理）以及部署时间和应用程序性能方面的策略考虑。

总结

TAM 和 TAM + TPM 是两个互补的解决方案。每个解决方案都具有特定的价值，TAM 提供访问控制，TPM 提供信息处理控制。如上所述，哪一个产品最好取决于客户的特定要求、应用程序以及他们必须遵守的规则和法规。