数据仓库中权限的设计

这是我们在做数据仓库项目时考虑的权限设计方案,供各位参考,请提宝贵意见,这里我们把数据仓库作为企业的数据中心. 1 权限控制数据中心是一个面向整个企业开放的共享的数据及应用平台，开放性和共享性是它所必须具备的特征。正因为如此，数据中心的安全性才显得更加重要。如何做到开放的同时又保持安全是数据中心必须解决的重要技术问题，也是实现数据中心的技术难点之一。实现数据中心的权限控制可能有很多不同的方法，本节中我们将提出我们认为最合适的解决方案。在该方案中，我们追求的目标是开放、安全和统一。 1.1 数据中心的用户、用户组和角色在真正开始介绍数据中心的权限控制方案之前，我们首先需要介绍在该方案中出现的三个关键概念，它们分别是： 数据中心用户 数据中心用户组 数据中心角色 1.1 数据中心用户数据中心的一个重要技术特征就是它的集成性。在数据中心中，可能集成了众多不同种类的软件产品，如关系型数据库、多维数据库、报表工具、应用服务器等。每一个产品都有一套完全独立的安全管理机制，让用户直接面对这些安全控制机制是很不合理的。对数据中心的使用者来说，数据中心是一个整体，应该拥有统一的用户和身份控制机制，我们把这种身份称之为 “数据中心用户”。在我们建议的数据中心权限控制方案中，数据中心用户具有如下特征： 2 数据中心用户既不是数据库用户，也不是OLAP　SERVER用户，更不是某一个产品的用户，而是一个全局的概念。 2 数据中心管理系统可以对数据中心用户进行统一的管理，并赋予各种不同的权限。这种的权限不仅包括数据库权限，也同时包括多维数据库以及其它类型的权限（如报表制作、应用模块访问、管理功能等等）。有关数据中心用户的所有信息以及权限范围都被记录在数据中心元数据中。 1.1.2 数据中心用户组在有了数据中心用户以后，还应该有数据中心用户组的概念。数据中心用户组实际上是一组数据中心用户的集合，在同一个组内的用户往往具有相同或者相似的权限组合。一般来说，用户组本身是一个虚拟的概念，它的主要作用是对组内用户作批量的权限控制操作。例如，当我们把某个权限赋予或者剥离某个组时，该组所属的所有用户也被自动地赋予或者剥离该权限。此外，管理员可以忽略组权限的信息，直接对某个用户的权限范围进行修改，并使该用户的最终的权限和其所在的组权限不一致。用户可以不属于任何一个用户组。上面描述的是用户和用户组的一般关系。考虑到数据中心的用户数量可能很多，在实际操作中我们并不建议过多地对单独用户进行权限操作，而是建议采用下面的简化方式：一般情况下，每个用户都属于一个用户组，但可以同时拥有多个身份（即数据中心角色）。管理员只对用户组进行权限分配，分配的结果将自动地被赋予到该组的所有用户中去。同一个组内的用户所拥有的权限相同。一些特殊的用户也可以不属于任何一个组。只有对这样的用户，管理员才直接对用户进行权限分配。 1.1.3 数据中心角色除了用户和组以外，在数据中心中还应该有角色的概念。角色是数据中心中各种权限的组合，它的存在主要是为了方便权限管理。比如说，我们把角色A赋给用户组B，就意味着我们把角色A所包括的所有权限都赋予了用户组B内的所有用户。角色所包含的权限范围可以单独定义，一旦定义完成就可以重复使用，从而大大减少了数据中心权限管理过程中的重复劳动。一个数据中心角色可能是以下几个方面权限的组合： 关系型数据库的访问权限 OLAP数据库的访问权限 数据中心中采用的其它工具软件（如报表工具等）的权限 应用系统访问的权限 管理权限上述五种权限的前三种和具体的产品相关，第四种和应用系统的统一管理相关，而最后一种则规定了该角色是否具有管理者的权限。一个数据中心用户可以同时被赋予多个数据中心角色。在数据中心登录时，用户必须指明本次登录所使用的身份（角色），这样该用户在登出以前所享用的权限就是指定角色包含的权限组合。 1.2 数据中心的权限控制系统数据中心的权限控制系统是整个数据中心中一个复杂而且关键的技术问题。正因为其复杂，因此在现实生活中我们看到很多数据中心在这方面都采用了折中的方案，例如仅仅在应用层（如在PORTAL中）实现一个“假的”统一安全管理（或者称为单点登录，SSO）机制。考虑到权限控制在数据中心中的重要地位，我们并不建议企业采用上述的不完整方案。事实上，在数据中心中实现一个真正的统一权限管理机制是完全可行的，在本节中我们将提出一个我们认为是完整的和可实现的数据中心权限控制系统，并在下节中讨论该系统的实现方法。 1.2.1 权限分配机制在有了数据中心的用户、用户组和角色的概念以后，还必须规定整个数据中心的权限分配机制。事实上不同的数据中心可以采用不同的权限分配方案。根据实际经验，我们认为下面的这种方案比较合理和方便，并且将在后面的章节中介绍它的实现方法。为每一个数据中心的使用者开设一个数据中心用户，以便管理和审计。开设若干个用户组（例如可以为每个部门开设两个用户组：一般组和高级组），并把尽可能多的用户分配到这些组中。一般情况下一个用户只能是一个组的成员。除了一些对权限有特殊组合要求的用户，一般用户都应该处于某一个组中。在数据中心中设立若干个角色，并为每一个角色定义其拥有的权限，包括数据库权限、OLAP权限、工具权限、应用权限、管理权限等。在数据中心中，每个角色代表一种权限组合，因此有多少种不同的权限组合就应该定义多少个不同的角色。为每个数据中心用户规定权限。这一过程往往是通过将数据中心角色赋予数据中心用户组来完成的，一旦角色被赋予某一个组，该角色实际上就被赋予了该组中的所有用户。对于那些特殊的用户（即不属于任何用户组的用户），管理员也可以直接把角色赋予他们，而不需要通过用户组。所有的权限定义工作都必须通过角色来进行。一个用户或者用户组可以同时被赋予多个角色。在数据中心登录时，用户必须指明本次登录所使用的身份（角色），这样用户在登出数据中心以前所享用的权限就是该角色包含的权限组合。 1.2.2 权限控制的信息记录在数据中心中，很显然所有的权限控制信息都应该被记入数据中心的元数据中，这些元数据的数据模型被称为SECURITY MODEL，是整个数据中心元模型的众多子模型中比较重要的一个。由于数据中心是元数据驱动的，因此仅从元数据的内容就可以看出数据中心的权限控制功能。 1.2.3 数据中心权限控制系统的技术要求从技术上讲，利用上述的权限控制信息记录来实现数据中心权限分配机制有多种方法，但要真正做到可行和安全却并不容易。我们认为无论采用什么方式，数据中心的权限控制应该符合下列要求： 整个数据中心的权限控制机制是统一的，而不是被割裂在不同的产品或系统中。任何用户只要拥有数据中心用户的身份就可以使用和查询相应的数据资源；同样，任何人想访问任何数据中心资源，都必须首先以数据中心用户的身份登录并通过身份检验。原则上不应该再直接使用诸如数据库用户的身份来查询数据。 每个用户可以拥有多个身份（角色），但在登录时必须指明。一旦登录成功以后，该用户在登出以前所享用的数据中心权限就是管理员为该角色定义的权限，并且无论在什么环境下使用都应该是一样的。 在数据的组织结构方面，应该可以定义每个角色所能够访问到的数据范围，包括ODS中的主题、子主题和表；DDS中的主题、子主题和数据单元；以及OLAP数据中的CUBE。 在数据的权限控制粒度方面，应该对DDS和OLAP数据有较细粒度的控制。具体地说，应该可以指定该角色可以或者不可以访问的维度值、维度属性以及测量值（分析变量）。例如，某角色只能访问华东区的数据；又例如，某角色只能查看计划数而不能查看实际执行数等等。 在应用系统的功能方面，应该可以定义每个角色所能够使用的应用模块。 如果数据中心使用了报表工具，那么还应该可以定义每个角色所能够使用的报表等信息，具体内容可能和产品相关。 在安全管理方面，应该可以定义每个角色所能够进行的管理工作，如用户的增加和删除，角色权限的修改，角色的赋予，密码的修改等等。 1.3 数据中心权限控制系统的实现 1.3.1 统一的数据中心服务数据中心权限控制的复杂之处，就是在于数据中心往往使用了很多不同厂家的产品，而这些产品又各有一套权限控制机制，并且互不相干。想要在开发的层面而不是应用系统的层面来实现一套统一的权限控制机制，就必须在这些产品和用户之间设立一个统一的服务代理层，并由这个服务代理层来统一代理所有的服务。数据中心中通常需要用到的产品有：关系型数据库（DBMS）、多维数据库（MDDB）、商业智能工具（如报表工具）等。为此，我们设计了的服务代理层，其逻辑结构如下图所示： 图4.14：典型的服务代理层上述的服务代理层也被称为数据中心服务层，是整个数据中心框架结构中的核心部件之一。在该服务层建成以后，所有的用户和应用系统都应该尽量通过数据中心服务层来访问数据中心，而避免直接登录到具体的产品。我们用一个例子来说明数据中心服务层如何实现数据中心的权限控制机制。假设企业某用户需要用SQL来访问数据中心中的数据库，他并不能够直接登录到数据库进行查询，因为该用户并不拥有数据库的用户和密码，而只是拥有数据中心的用户和密码。因此该用户只能使用数据中心的用户和密码登录到数据中心服务层，并向服务层递交SQL查询请求。服务层收到用户的SQL请求以后，自动地以内部的数据库用户（关于这个数据库用户，后面还有详细讨论）登录到数据库并递交SQL，然后将所得到的结果再返回给用户。其它类型服务的处理过程也是类似的。上例中讨论的过程只是简单地实现了数据库查询的代理，其本质仅仅是一个用户身份的转换工作，并没有实现任何附加的功能。事实上，在数据中心中实现一个统一的数据中心服务层意义重大，其作用远不止实现简单的功能代理。总而言之，只有利用数据中心服务层这样的数据中心统一接口才能够实现真正意义上的数据中心统一权限控制系统。在有了数据中心服务层以后，再公布一套在该服务层上进行应用开发的规范和接口。一般情况下，数据中心不再对外公布其物理数据结构，并且除了数据中心用户以外，也不再向用户提供数据库以及其它产品的用户身份。 1.3.2 身份转换数据中心用户所拥有的权限实际上是由角色决定的，一个角色代表了一种数据中心的权限组合。正因为如此，具体产品（如数据库）的用户并不能和数据中心用户一一对应，但却可以和数据中心角色构成一一对应的关系。考虑到上述因素，我们在每次创建一个数据中心角色时在各产品中都创建一个新的用户，该用户和数据中心角色之间有着一一对应的关系。这样，每当数据中心用户向数据服务层递交服务请求时，数据服务层就能够用和该用户身份（角色）对应的产品用户及密码去登录具体的产品，从而达到身份转换的目的。必须注意的是，根据上述方案，角色与具体产品用户的对应关系以及用户密码都将被存储在数据中心安全控制系统的元数据中，供数据服务层使用。为了保证这些用户名和密码的安全，存放上述数据的相关库表应该只向数据服务层开放，并且还有附加的严格加密措施。每次启动数据服务层时，管理员必须输入解密的密钥，数据服务层才能够正常工作。这样除非解密算法和密钥同时泄漏，系统才会有泄密的危险。 1.3.3 权限设置如前所述，数据中心的每一个角色都代表了一种数据中心的权限组合，其中包含了数据中心所使用的各种不同产品（如数据库、OLAP SERVER、报表工具等）的权限。毫无疑问所有的权限控制信息都应该被记录在元数据中，并有相应的管理软件来提供对这些权限的增加、删除和修改。问题是如何使元数据中记录的权限控制要求得到实现？对于上述问题的回答，可以分以下两种情况： 如果产品的安全机制能够支持数据中心的权限粒度要求，可以通过手工（使用具体产品的权限控制管理器）或自动（使用产品提供的API编写权限控制同步程序）的方式在每一个产品中为每一个角色的对应用户设置相关的权限，以实现META DATA中要求的权限控制机制。如果产品的安全机制不能支持数据中心的权限粒度要求，可以通过手工（使用具体产品的权限控制管理器）或自动（使用产品提供的API编写权限控制同步程序）的方式在每一个产品中为每一个角色的对应用户设置比META DATA要求粗一级的权限，然后再在数据服务层的输出中将用户无权访问的信息虑除。

TAG: 数据仓库
10秒注册会员 结交数据仓库朋友 分享你的精彩