某银行数据中心系统-信息安全体系-安全架构部分

数据中心项目（一期）数据中心项目（一期） 技术体系架构设计方案技术体系架构设计方案 安全架构部分安全架构部分 版本版本 V0.9V0.9 二二二二二二二二年六月年六月 本文档及其里面所包含的信息为机密材料 并且由/共同拥有。 本文档中的任何部分都不得以任何手段任何形式进行复制与传播。 未经/书面授权，不得将材料泄露给第三方。 Copyright 2005 /版权 保留所有的权利。 文档信息文档信息 编写者编写日期 审核者审核日期 批准人批准日期 变更历史变更历史 日期日期变更描述变更描述批准批准 目目 录录 1.前言前言.3 1.1安全体系的设计目标.3 1.2需求与风险分析.3 1.3安全体系总体架构.4 1.4安全体系框架模型设计.4 1.5术语定义.6 2.用户安全策略用户安全策略.8 2.1统一身份管理和访问控制.8 2.1.1身份管理系统.10 2.1.2应用安全.11 2.1.3身份管理的技术架构.12 2.2用户、用户组及角色.14 2.3用户、用户组划分.15 2.3.1用户/用户组分配.17 2.4用户的授权管理.21 2.4.1用户授权.22 2.4.2功能授权.22 2.4.3数据授权.23 3.数据安全策略数据安全策略.24 3.1系统安全.24 3.1.1高可用结构.24 3.1.2系统加固.24 3.1.3操作系统安全.25 3.2网络安全.25 3.2.1网络结构安全.25 3.2.2端口安全.26 3.2.3加强访问控制.28 3.2.4防火墙.28 3.2.5入侵检测.28 3.2.6漏洞扫描.29 3.2.7病毒防护.29 3.3数据存储安全.29 3.3.1元数据存储安全.30 3.3.2Teradata 数据存储安全.30 3.3.3Weblogic 应用服务器存储安全.31 3.3.4报表及多维立方体存储安全.33 3.4系统的备份与恢复.34 3.4.1数据保护和恢复技术.34 3.4.2备份与恢复的范围.34 3.4.3备份工具说明.35 3.4.4备份策略.36 3.4.5恢复处理.36 1. 前言前言 1.1 安全体系的设计目标安全体系的设计目标 在本文中，所谓的安全体系是指在此体系框架下，系统能够使正确的用户在正 确的时间访问到正确的数据，主要包括用户安全和数据安全两部分。 数据中心安全体系的设计目标是要保证系统的机密性、完整性和可用性。 具体描述如下： 机密性 Confidentiality 保护信息，防止未经授权的访问 完整性 Integrity 保护信息不会被有意或无意地修改和破坏 可用性.Availability 确保系统性能与可靠性，保证授权用户在需要的时候可以访问到信息和相 关的资产。 1.2 需求与风险分析需求与风险分析 根据我们对总行信息管理系统项目的了解，结合银行业务的多种信息种类、不 同开放程度和安全级别等情况，数据中心系统在安全方面面临的主要威胁有以下几 个方面： 需要建立统一的、完整的安全策略，以符合政府和行业规范的要求、满足 自身业务发展的需要。 银行业务信息量大，应用复杂，不同种类、不同级别的信息对不同的用户 有不同程度的保密需求（无密级、秘密、机密、绝密） 。 来自内部或外部的黑客针对网络基础设施、主机系统和应用服务的各种攻 击，造成网络或系统服务不可用、信息泄密、数据被篡改等破坏。 内部人员（合法用户）滥用权力，有意犯罪，越权访问机密信息，或者恶 意篡改数据。 恶意软件和数据（如病毒等）的传播。 系统软硬件故障造成的服务不可用或者数据丢失。 自然灾害或恐怖事件的物理破坏。 1.3 安全体系总体架构安全体系总体架构 数据中心系统的信息安全建设包括三个方面安全策略、安全技术和安全管 理。 安全策略：包括各种策略、法律法规、规章制度、技术标准、管理标准等， 是信息安全的最核心问题，是整个信息安全建设的依据； 安全技术：包含工具、产品和服务等，是实现信息安全的有力保证。 安全管理：主要是人员、组织和流程的管理，是实现信息安全的落实手段； 根据上述三个方面，安全解决方案不仅仅包含各种安全产品和技术，而是要建 立一个策略、技术和管理三位一体、目标一致的信息安全体系。 信息安全体系的建立，可以对数据中心系统中的所有信息资产进行安全管理并 从安全技术层面进行保护，通过多层次、多角度的安全服务和产品，覆盖从物理环 境、网络层、系统层、数据库层、应用层和组织管理信息安全的所有方面。 需要指出的是，完整的信息安全体系的建设是无法在数据中心系统项目中完成 的，因为它所涉及的范围要比数据中心 系统大得多；而这一信息安全体系的建立对 保障数据中心 系统的顺利运行意义重大，建议在条件成熟的情况下，与总行专门的 信息安全项目 UAAP 集成在一起，进行数据中心信息安全体系的建设。 1.4 安全体系框架模型设计安全体系框架模型设计 根据安全领域的最佳实践和银行业务的需求，我们设计出如下数据中心安全体 系框架模型。 安全管理制度、安全策略和安全管理机构安全管理制度、安全策略和安全管理机构安全管理制度、安全策略和安全管理机构安全管理制度、安全策略和安全管理机构 安全评估安全评估安全评估安全评估 业务连续性计划业务连续性计划业务连续性计划业务连续性计划 物理层安全物理层安全 网络层安全网络层安全 操作系统安全操作系统安全 内容安全内容安全 应用安全应用安全 P K I 体体 系系 安安 全全 集集 中中 管管 理理 税务税务 业务业务 行政行政 管理管理 外部外部 系统系统 决策决策 支持支持 安全运行中心安全运行中心安全运行中心安全运行中心 安全管理制度、安全策略和安全管理机构安全管理制度、安全策略和安全管理机构安全管理制度、安全策略和安全管理机构安全管理制度、安全策略和安全管理机构 安全评估安全评估安全评估安全评估 业务连续性计划业务连续性计划业务连续性计划业务连续性计划 安全管理制度、安全策略和安全管理机构安全管理制度、安全策略和安全管理机构安全管理制度、安全策略和安全管理机构安全管理制度、安全策略和安全管理机构 安全评估安全评估安全评估安全评估 业务连续性计划业务连续性计划业务连续性计划业务连续性计划 物理层安全物理层安全 网络层安全网络层安全 操作系统安全操作系统安全 内容安全内容安全 应用安全应用安全 P K I 体体 系系 安安 全全 集集 中中 管管 理理 税务税务 业务业务 行政行政 管理管理 外部外部 系统系统 决策决策 支持支持 安全运行中心安全运行中心安全运行中心安全运行中心 监管 报表 ALM管理 会计 . 图图 1 安全体系框架模型图安全体系框架模型图 建设安全管理框架，包括安全管理机构、安全管理规定和制度，制定安全策略； 建立安全运行中心，对全网进行全面管理、分析和故障支持响应；进行全网安全评 估，建立内部评估规范，形成安全评估体系；有针对性地制定业务连续性计划策略， 建设数据备份中心和灾难恢复中心；建立覆盖全网的安全技术体系，包括：物理层 安全、网络层安全、操作系统安全、应用安全、内容安全。 整个体系框架的构成如下： 安全管理框架 1安全管理制度和安 全策略 制定一系列安全策略和规范，指导安全建设， 保障安全规范的执行 2安全管理机构必须有专业安全人员，关注安全建设，将各相 关部门的人结合在一起，形成完整的安全管理机构 3安全评估在外部专家帮助下，建立安全的风险评估体系， 定期对系统进行安全评估 4业务连续性计划考虑事故、灾害对业务可用性的冲击和影响， 选择投资和容灾的最佳结合点 5安全运行中心建立专门的安全运行中心专注安全状况，收集 资料并提供决策支持 安全技术框架 6物理层安全保证设备放置环境、电源、物理访问控制均符 合统一规范 7网络层安全提供网络访问控制和入侵检测，在系统边界和 核心全面实施保护 8操作系统安全通过对安全操作系统的选择、扫描和加固保证 基本的主机操作系统安全 9内容安全建立集中的防病毒体系和完善的内容过滤机制 1 0 应用安全通用应用和应用开发的安全 1 1 PKI公用密钥体系提供了完整的认证和加密机制， 可以嵌入到各个应用系统，保证机密性、完整性和 不可抵赖性 1 2 安全集中管理对分布在全网各处的安全子系统通过统一的管 理界面，实施统一的监控和日志、事件的收集和分 析。 1.5 术语定义术语定义 LDAP：轻量级目录访问协议 SSO：单点登陆 CA：certificate authority PKI：公钥基础结构 SSL：安全套接层 CSR：证书签名申请文件 SSH： DES：数据加密标准 DSA：数字签名算法 SIT：系统集成测试 UAT：用户应用测试 2. 用户安全策略用户安全策略 2.1 统一身份管理和访问控制统一身份管理和访问控制 为了适应大量用户使用多种数据集市应用、满足复杂的权限控制的需求，数据 中心需要建立全网统一的身份认证、管理手段及访问控制系统。统一身份认证、管 理及访问控制涉及到数据中心所有数据集市应用和用户，涉及面相当大，不建议在 数据中心系统中实施，而是将来通过与 UAAP 集成来实现。但从安全角度来看，数 据中心一期需要在此方面进行规划。 在传统的应用中，用户身份信息一般都放置在本地目录或数据库中（即“身份岛”） ，而这些目录或数据库都只是被单独应用程序所使用，由此产生了大量孤立、分散 的身份和访问管理系统，从而带来了繁重的管理负担和高昂的成本。在数据中心系 统中随着数据集市的增加，管理和维护多个身份库及其相关访问权限的成本将会增 加，而确保数据中心系统被安全访问的能力却会下降。 目录服务目录服务 验证验证授权授权私密私密 应用程序应用程序 管理管理 目录服务目录服务 认证认证授权授权私密私密 数据集市数据集市 管理管理 数据集市数据集市数据集市数据集市 图图 1 统一身份管理框架图统一身份管理框架图 为此，在数据中心系统中需要有统一的身份认证、管理及访问控制系统。其中， 身份认证子系统支持包括动态口令和证书等多种认证手段的统一的身份认证服务， 正确地识别访问操作的主体的身份，提供合适身份信息；身份管理子系统管理用户 的身份信息，提供自动的基于工作流管理的用户身份信息更新和同步，实现用户的 自服务功能和分级用户管理功能；访问控制子系统定义访问控制的规则，通过策略 服务器进行统一的规则定义管理和实时的执行引擎。 在 cognos 中，身份认证是通过第三方的认证提供者来完成的，每个第三方 的认证提供者被称为名空间。第三方的认证提供者定义了用于认证的用户、用户组 及角色。 用户组角色 用户用户组用户用户组角色 在 cognos 中用户、用户组及角色三者之间的关系如上图所示。其中用户组与角 色的主要差别在于用户组是用户的基本标识的一部分，而角色却不是。角色主要用 于运行报表和作业。 在 cognos 名空间是缺省的名空间，它不能被修改。在一期中，建议不使用这个 缺省的名空间，而是建立一个 dwmis 名空间，以方便将来的管理。 Cognos 在默认安装配置下没有启用任何安全设置，因为 Cognos 的设计思想是 要与企业现有的身份认证基础设施相集成。对于数据中心项目，我们将实现 SunOne LDAP 来集成数据中心目前的用户身份管理设施。因此，Cognos 的用户信 息和数据中心的用户信息共享同一份数据，并使用 SunOne LDAP 来实现 Cognos 使用组和角色来进行授权管理和访问控制。组和角色信息定义在 Cognos 内部，又称为 Cognos Group 和 Cognos Role。组和角色都代表了执行一 系列相同任务，拥有相同的权限的用户。组成员关系是用户身份的一部分，每次登 陆时都是用户从属组中获得全部权限。角色成员关系是不属于用户身份的一部分， 用户可以选择每次登陆时使用的角色列表。 Cognos 包括下列内建的（无法删除）安全条目： Anonymous 用户，这是所有不需要身份认证的用户的共享帐号； All Authenticated Users 组，代表所有非 Anonymous 用户； Everyone 组，代表所有 Anonynmous 用户和 All Authenticed Users 组的 用户； System Administrators 角色，代表具有 Cognos 服务器全部管理权限的超 级用户。 Cognos 默认还设置了下列六个预定义的（可以删除）安全条目： Consumers 角色，具有查看和执行公共内容的权限； Query Users 角色，具有 Consumers 角色的权限，并且可以使用 Query Studio； Authors 角色，具有 Query Users 角色的权限，并且可以使用 Report Studio 来发布公共内容； Report Administrators 角色，具有管理公共内容和访问 Query Studio 及 Report Studio 的权限； Server Administrators 角色，具有管理服务器、调度器、作业的权限； Directory Administrators 角色，具有管理命名空间，包括组、角色数据源 等对象的权限。 对 Cognos 安装的默认配置进行下列修改提高安全性： 配置数据中心项目的 SunOne LDAP，并且禁用内建的 Anonymous 用户帐 号； Everyone 组是 System Administrators，Consumers，QueryUsers，和 Authors 角色的成员，必须立即删除，并根据需要设置 Cognos 的 System Administratiors 角色的成员。 2.1.1 身份管理系统身份管理系统 身份管理系统负责对用户身份的管理、验证、授权和私密性保护。 管理涉及到如何创建、修改和取消身份。好的管理能够显著降低成本和提 高生产力。它还可以大大缩短业务经理填写相关文件的时间，并可减少财 务、人力资源以及 IT 人员审批和实施访问请求的时间。 验证是证实访问网络、应用程序或资源的身份的操作。验证技术包括基于 用户 ID 的简单登录、密码，以及令牌、公匙证书和指纹验证等更为强大 的机制。在 Web 环境中，用户可以在一个站点甚至多个站点内跨多个 Web 服务器访问多个应用程序。有效的身份管理和访问管理策略可以部署 集中的验证框架，以便简化用户体验和降低管理工作量。 授权是确定是否允许数字身份执行所请求操作的流程。授权过程出现在验 证之后，它可以使用与数字身份相关的属性或权限，以确定数字身份可以 访问的资源。例如，一旦用户通过验证，即可授权获得与其数字身份权利 对应的限制信息访问权限。 身份和访问管理技术可以使组织降低因扩大对其信息系统的访问而产生的 风险。由于可以对访问权限及特权进行精确控制，从而可以确保数字信息 的私密性。修改权限和/或终止访问的能力可以进一步增强这种保护的灵活 性和一致性。 在本设计中，我们采用 SunOne LDAP 作为第三方认证提供着，用于存储不同 来源的用户信息、资源信息和策略信息，实现统一的用户身份管理，统一的访问资 源各类和统一的访问策略信息管理； 目录服务构成了身份和访问管理框架的核心，该目录服务将多个数据源（如目 录、文本文件、数据库）结合在一起，从而为数字身份信息提供单一来源。 在 SunOne LDAP 的实现中可以有多个管理服务器和多个目录服务器，及多种 组织形态。在数据中心一期实现中，应用相对简单，建议使用单一的管理服务器和 目录服务器来完成对用户目录和配置目录的管理。具体实现方式详见实施工艺手 册 。 2.1.2 应用安全应用安全 作为数字身份的最终使用者以及该身份权限的强制执行者，应用程序在所有身 份管理解决方案中都扮演着重要角色。应用程序必须与组织的身份管理基础结构兼 容，对于应用程序开发而言，最重要的一点在于应用程序不应建立和实施其自身的 身份库、安全协议或数据保护机制，而应依赖身份管理基础结构所提供的解决方案。 对于应用访问的安全，其主要设计体现在统一单点登录入口即 Portal 门户入口 以及统一的用户安全认证与权限分配管理。 在数据中心一期实现中，典型的前端应用程序包括： 元数据管理应用程序 监管报表应用程序 ALM 应用程序 多维立方体生成应用程序 报表生成应用程序 2.1.3 身份管理的技术架构身份管理的技术架构 下图是一个典型的身份管理的技术架构： Policy ServerSecure Audit ServerPlug -In Admin Server Directory Server Web Server Portal Java App Server Application Web Services 图图 32 身份管理技术架构图身份管理技术架构图 其中，Plug-in 安装在 Web 服务器端，接到前端用户对安全内容的请求之后， 它会将请求送到 Policy Server 进行用户身份认证，Policy Server 则到目录服务器检 索用户信息。认证成功后，Policy Server 向 Plug-in 返回用户的授权信息，使该用 户可以访问授权范围之内的内容。 Policy Server 返回的用户信息（包括用户的角色）可以以环境变量的形式通过 Plug-in 传递给应用程序，以完成页面的个性化，给不同的用户显示不同的操作界面。 Admin Server 负责管理访问控制策略的制定，使不同的用户对不同的资源有不 同的访问权限。 在本设计中，通过 Cognos Series 7 利用 SunOne LDAP 服务实现了 ReportNet 和 PowerPlay 的统一用户、安全管理，SSO 模块的主要作用是实现 Cognos Custom Authentication Provider，以支持 UAAP 安全认证服务。下面以系统管理员维护为 例，说明整个用户安全子系统的运行流程： Cognos Content Manager Oracle 9i Repository Web Server Apache 2.0.53 Report Server Cognos ReportNet OLAP Server .Cognos PPES Cognos Connect Portal Server Sun One Directory Server LDAP JDBC JSPI JDBCJDBC TCP/IP 1 23 4 5a5b 6a6b Administrator Repository Server Oracle 9i Teradata ODBC 5b 用户安全子系统运行流程 ：数据仓库系统管理员登录数据中心门户系统（Cognos Connect） 。 1 1 ：门户系统通过目录服务（Sun One Directory Server）认证管理员。 2 2 ：门户系统认证成功后将用户名、口令和 TokenID 写入 Oracle 9i 数据 3 3 库供 Cognos ReportNet 透明登录使用。 ：数据仓库系统管理员登录成功后点击 CRN 链接。此链接指向 Web 4 4 Server（Apache 2.0.53） 。 ：用户组管理、模块授权管理均须操纵 Cognos Content Manager。由于 5 5a a Cognos ReportNet 提供了 Java SDK，因此这个模块使用 JSP 开发，运 行在 Weblogic Application Server 上。 ：数据安全管理是在 Teradata 中建立用户组和机构的对应关系，并在多 5 5b b 维数据库的机构维建立过滤定义。这个模块使用 J2EE 开发，程序分 为两部分，一部分在 Web Server 上运行，访问 Teradata 数据库，建立 用户组和机构的对应关系，同时作为客户端提交建立维度过滤的请求 到 OLAP Server 上的 Cognos ReportNet；另一部分在 OLAP Server 上 运行，接受客户端（运行在 Web Server 上的 JSP 应用）请求，调用 DSO 建立维度过滤。 ：Cognos ReportNet 通过 JDBC 将用户组、模块授权信息写入 Oracle 6 6a a 9i000 上的 Content Manager 中。 ：OLAP Server 通过 JDBC 将维度过滤信息写入 Cognos PPES 上的 6 6b b Oracle 9i Repository 中。 2.2 用户、用户组及角色用户、用户组及角色 前端用户管理包括两个部分，用户(User)和用户组(Group)信息管理。 用户(User)管理 用户(User)管理包括用户信息的维护、用户组的分配以及用户特殊功能的权限分 配等。一般来讲，在创建一个 Portal 用户的信息时，将同时要在 Cognos 服务器、 Weblogic 服务器、以及其他需要集成在 Portal 内的子系统中建立相应的用户信息； 即在本系统中，用户信息时进行统一维护的。 角色(Role)管理 在对用户进行权限分配时，将引入角色(Role)的概念，所谓角色，就是一个权限 集合的定义，一个 Portal 用户可以赋予多个 Portal 角色，每个 Portal 角色都与之对 应的 Weblogic 角色、Cognos 用户类，用于定义对应用和数据的访问权限。 用户组(Group)管理 用户组管理包括用户组创建、用户组修改、用户组权限分配等。用户组是一组 具有使用相同角色的用户群。用户和用户组的关系是一个用户组可以包括多个用户， 一个用户只可以属于一个用户组。 在 cognos 中用户可以拥有的权限如下： 读(read) 浏览一个条目的所有属性；为一个条目创建快捷方式。 写(write) 修改一个条目的属性；删除一个条目；在包或文件夹等容器中建立一个条 目；修改一个报表的定义；为一个报表创建新的输出。 执行(excute) 运行报表；在数据源中检索数据。 设置策略(set policy) 读或修改一个条目的安全设置。 遍历(traverse) 浏览包或容器中一个条目的内容；浏览容器本身的一般属性。 在 Teradata 数据库中用户可以拥有的权限 Teradata 数据库可以针对不同的用户， 在不同级别的 Teradata Objects(如 Database、User、Table、View 和 Macro 等)上进行 多种类型的权限设定。可以设定的权限包括：Select, Update, 执行权, 所有权等等。 2.3 用户、用户组划分用户、用户组划分 在本系统中，用户层包括各种最终用户。主要分为技术用户、业务用户及管理 用户三类： 技术用户 技术用户主要是数据中心系统的管理者以及信息的管理者，他们的主要职责 是完成数据中心系统的管理和信息的组织。首先为业务用户提供最便捷的数据访 问途经，其次为业务用户访问数据的正确性作出保障。 应用开发人员(Application developers)：对数据转换和信息访问层都需 要应用开发人员。 Teradata DBA：管理数据仓库的 RDBMS 引擎，维护物理数据模型，开发和 维护备份与恢复过程，承担性能调整和负载管理工作以及容量的规划。 ETL 管理员(ETL Administrator)：监控数据加载流程。 数据建模员(Data Modeler)：开发和维护数据仓库的逻辑数据模型。 业务用户 按照用户使用数据中心系统的方式和特点，可以划分为业务人员、业务分析人 员、决策人员和知识工作者。 业务人员主要指总行各业务部门、各分行的业务用户，包括客户经理。该 类人员直接使用模块化的应用界面访问数据中心系统，访问预定义报表， 进行相对固定的查询和较为简单的分析。 业务分析人员是指总行各业务部门、各分行的较为高级的用户。除能够执 行一般业务人员进行的操作外，可以对指定的主题、指标进行自定义的 灵活分析和比较。分析的方式包括自定义查询、自定义报表、多维旋转 和钻取等等。 决策人员主要包括各部门的领导和行领导。数据中心系统为决策人员分配 专门的系统资源，建立最为直观和方便的存取界面，为决策人员赋予最 大的信息访问权限，实现决策人员对信息的自由访问。同时，信息资源 系统将决策人员最为关心的信息主动发布到决策人员的访问界面上，简 化信息访问的方式，使得决策人员在第一时间获得经营管理的各种重要 信息和指标。 知识工作者：是最为高级的分析人员。该类人员能够自由使用各种报表、 查询、分析和挖掘工具，对银行业务和数据都由较为深刻的认识，特别 是理解数据中心系统的数据模型，能够回答各种突发和复杂的业务问题， 使用复杂的工具进行业务模型的建立和验证。在进行复杂的业务分析或 者进行数据挖掘的过程中，可能使用一些专业的工具，这类工具通常需 要数据仓库系统导出大量数据供它们分析，这会耗费数据仓库系统大量 资源，因此我们不建议知识工作者自己提交 SQL 请求给数据库，而是应 首先经过管控的审批流程，提交请求给系统的 DBA，DBA 根据用户请求 下载数据并提交到指定的目标位置。对于普通用户来说，在经过数据管 控流程的审批之后，通过相关的工具分析 DBA 导出的数据完成处理。 管理用户 为每个业务单位（总行、分行）建立管理角色，管理角色具有 Cognos 的 组织管理员和内容发布者角色，负责维护组织机构、发布文档。如：管理角色 BJ（北京分行管理员） ，应被授予组织管理员和内容发布者双重角色，以便维 护本行用户、组和发布文档。 总行管理员将各业务单位管理员授予第一步设定的管理角色。 总行管理员授予本分行用户访问数据中心系统的权限。 分行管理员授予本分行用户访问数据中心系统的权限。 2.3.1 用户用户/用户组分配用户组分配 前端用户分配： 使用浏览器访问数据仓库的前端用户是通过 Web Server 访问数据库的。共有 四种类型的用户： 用户类型用户类型登录登录 webserver 用户用户数据库用户名数据库用户名 前端管理员用户FrontadmFrontadm（不可以访问业务数据） 部门管理员用户Department 缩写+adm不可以访问数据仓库 监管报表访问用户由各个部门管理员设定dmBuser ALM 访问用户由各个部门管理员设定dmBuser Power User由数据仓库管理员设定（每人一个） 前端管理员用户和各个部门管理员用户不可以访问数据仓库业务数据，他们的 权利是通过前端安全管理页面设定各个部门的查询功能分配以及建立用户、岗位并 进行用户的岗位分配和岗位功能指定。部门管理员用户需要访问数据仓库时，必须 重新建立前端用户，并接受审计。 数据库用户分配： 用户用户 ID描述描述权限定义权限定义数据库类型数据库类型 dwDBA 数据库管理员 系统管理员，是 dwAdm 的备份用户。 Teradata dwITUser IT 技术人员，包括所有参 加到数据转换，前端应用 的用户. 一般而言，他们 有权存取执行开发工作所 在的测试环境 IT 部门用户组。对 dwTData、dwttemp、dwT Macro 有创建、修改和 删除权限。没有 dwPDATA,dw PVIEW, dwBVIEW, dwPMACRO 和 dwBMACRO 的任何存取权 限。 Teradata dwJOB dwSDATAdwPDATA 的 ETL 加载任务的执行用户 批处理作业用户组。 DWJob 对 DWPLog 有全部 权限(ALL)DWJob 对 DWTLog 有全部权限 (ALL)。DWJob 对 DWPData 有创建表和 Select, Update, Insert 和 Delete 权限。 DWJob 对 DWTData 有创 建表和 Select, Update, Insert 和 Delete 权限。DWJob 对 DWTemp 有全部权限 (ALL)DWJob 对 DWPView 有 Select, Update, Insert 和 Delete 权限。 DWJob 对 DWTView 有 Select, Update, Teradata Insert 和 Delete 权限。 DWJob 对 DWBView 有 Select, Update, Insert 和 Delete 权限。 DWJob 对 DWPMacro 有创 建宏、删除宏、执行宏 以及创建存储过程、删 除存储过程、执行存储 过程的权限。DWJob 对 DWTMacro 有创建宏、删 除宏、执行宏以及创建 存储过程、删除存储过 程、执行存储过程的权 限。DWJob 对 DWBMacro 有创建宏、删除宏、执 行宏以及创建存储过程、 删除存储过程、执行存 储过程的权限 dwJobOlap dwPDATAdwPMart 的 ETL 加载任务的执行用户 IT 用户，该组用户只对 dwPDATA 有 SELECT 权限。 该组用户只对 dwPMart 有 select、update 权限。 对存储过程有执行权限 Teradata dwJobAlm dwPDATAdwPAlm 的 ETL 加载任务的执行用户 IT 用户，该组用户只对 dwPDATA 有 SELECT 权限。 该组用户只对 dwPAlm 有 select、update 权限。 对存储过程有执行权限 Teradata dwJobCm dwSDATAdwPCMart 的 ETL 加载任务的执行用户 IT 用户，该组用户只对 dwSDATA 有 SELECT 权限。 该组用户只对 dwPCMart 有 select、update 权限。 对存储过程有执行权限 Teradata dwARC 备份用户Teradata dwDQUser 定义数据质量稽核规则的 用户 Teradata dmAdmin Oracle 数据库管理员AllOracle dmContent Cognos 内容管理用户 对 Cognos 元数据具有 delete、insert、update、s elect 权限 Oracle dmBuser 监管报表应用管理用户 对 Cognos 元数据具有 delete、insert、update、s elect 权限 Oracle dmBuser ALM 应用管理用户 对 Cognos 元数据具有 delete、insert、update、s elect 权限 Oracle 系统级用户 用户用户 ID描述描述属组属组操作系统类型操作系统类型 admin主机管理员DwmisMP-RAS EtladminETL 服务器管理员EtlgrpHP-Unix Appadmin应用服务器管理员AppgrpHP-Unix AppacheWeb 服务器管理员Administrator Windows 2003 Advanced Server Metaadmin元数据管理用户Administrator Windows 2003 Advanced Server CrnadminCognosReportNet 管理用户CognosHP-Unix OlapadminCognos 立方体生成用户CognosHP-Unix HausrHA 系统用户UsrHP-Unix Bakusr备份用户UsrHP-Unix ALM_usrALM 数据交付用户AlmHP-Unix cmoraCognos 内容存储用户Oracle9iHP-Unix Oracle9iOracle 数据库管理用户CognosHP-Unix wliadminWeblogic 管理员WeblogicHP-Unix ldapadminLDAP 管理员CognosHP-Unix crndev报表生成用户CognosHP-Unix 2.4 用户的授权管理用户的授权管理 统一授权是数据中心安全体系需要实现的业务目标之一，是将统一的授权管理 和规范与分权、分级的授权委托管理相结合的管理方式，在满足统一、规范的原则 下，使授权管理更灵活高效。 分权、分级管理实际上是数据中心系统管理员将管理权委托给分支机构和业务 部门在其辖内完成数据中心系统的授权管理。 为了保证在分权、分级管理的方式下，满足统一授权的规范化，以及资源信息、 用户信息的安全性，需要建立一个完整的授权管理流程和管理模型。一方面在授权 管理流程上确定各级管理员的职责，另一方面对被授权管理的用户和资源采用授权 委托管理域和访问控制安全管理域的形式进行委托管理。 委托授权的形式包括以下类型： 分级委托 指数据中心系统管理员遵循企业的组织结构，按照总行、分行、二级分行、支 行、储蓄所，将授权权限逐级委托到下级管理员。下级管理员可以进一步进行委托 授权。 分权委托 指数据中心系统管理员按照数据中心数据集市系统的划分，将各个数据集市系 统的授权权限分别委托到对应的数据集市系统管理员。数据集市系统管理员可以进 一步进行委托授权。 上述委托的类型将同时存在数据中心系统的日常管理中，数据中心系统中各级、 各系统用户管理员应当根据具体业务需求制订委托授权的规划，灵活采用平台提供 的各种委托授权方式将拥有的权限委托到最贴近用户的管理员手中。通过工作流管 理，数据中心系统管理员可以保留对委托下去的授权的控制，并跟踪授权情况。 另外，从授权内容上看主要包括用户授权、功能授权、及数据授权三个方面。 2.4.1 用户授权用户授权 数据中心系统包含了目前所有有效用户（可以登录到门户、且有有效岗位的用 户） ，缺省状态下用户没有权限登录系统，用户授权就是机构管理员授予本机构用户 相应的角色，以允许他们登录本系统。 2.4.2 功能授权功能授权 各机构管理员使用“模块授权管