银行数据中心系统信息安全体系安全架构部分.docx
《银行数据中心系统信息安全体系安全架构部分.docx》由会员分享，可在线阅读，更多相关《银行数据中心系统信息安全体系安全架构部分.docx（33页珍藏版）》请在冰豆网上搜索。
银行数据中心系统信息安全体系安全架构部分
数据中心项目（一期）
技术体系架构设计方案
安全架构部分
版本V0.9
二〇二二年三月
本文档及其里面所包含的信息为机密材料
并且由/共同拥有。
本文档中的任何部分都不得以任何手段任何形式进行复制及传播。
未经/书面授权，不得将材料泄露给第三方。
Copyright©2005/版权
保留所有的权利。
文档信息
编写者
编写日期
审核者
审核日期
批准人
批准日期
变更历史
日期
变更描述
批准
1.前言
1.1安全体系的设计目标
在本文中，所谓的安全体系是指在此体系框架下，系统能够使正确的用户在正确的时间访问到正确的数据，主要包括用户安全和数据安全两部分。
数据中心安全体系的设计目标是要保证系统的机密性、完整性和可用性。
具体描述如下：
⏹机密性Confidentiality
保护信息，防止XX的访问
⏹完整性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
内容安全
建立集中的防病毒体系和完善的内容过滤机制
10
应用安全
通用应用和应用开发的安全
11
PKI
公用密钥体系提供了完整的认证和加密机制，可以嵌入到各个应用系统，保证机密性、完整性和不可抵赖性
12
安全集中管理
对分布在全网各处的安全子系统通过统一的管理界面，实施统一的监控和日志、事件的收集和分析。
1.5术语定义
LDAP：
轻量级目录访问协议
SSO：
单点登陆
CA：
certificateauthority
PKI：
公钥基础结构
SSL：
安全套接层
CSR：
证书签名申请文件
SSH：
DES：
数据加密标准
DSA：
数字签名算法
SIT：
系统集成测试
UAT：
用户应用测试
2.用户安全策略
2.1统一身份管理和访问控制
为了适应大量用户使用多种数据集市应用、满足复杂的权限控制的需求，数据中心需要建立全网统一的身份认证、管理手段及访问控制系统。
统一身份认证、管理及访问控制涉及到数据中心所有数据集市应用和用户，涉及面相当大，不建议在数据中心系统中实施，而是将来通过及UAAP集成来实现。
但从安全角度来看，数据中心一期需要在此方面进行规划。
在传统的应用中，用户身份信息一般都放置在本地目录或数据库中（即“身份岛”），而这些目录或数据库都只是被单独应用程序所使用，由此产生了大量孤立、分散的身份和访问管理系统，从而带来了繁重的管理负担和高昂的成本。
在数据中心系统中随着数据集市的增加，管理和维护多个身份库及其相关访问权限的成本将会增加，而确保数据中心系统被安全访问的能力却会下降。
目录服务
验证
授权
私密
应用程序
管理
目录服务
认证
授权
私密
数据集市
管理
数据集市
数据集市
图2统一身份管理框架图
为此，在数据中心系统中需要有统一的身份认证、管理及访问控制系统。
其中，身份认证子系统支持包括动态口令和证书等多种认证手段的统一的身份认证服务，正确地识别访问操作的主体的身份，提供合适身份信息；身份管理子系统管理用户的身份信息，提供自动的基于工作流管理的用户身份信息更新和同步，实现用户的自服务功能和分级用户管理功能；访问控制子系统定义访问控制的规则，通过策略服务器进行统一的规则定义管理和实时的执行引擎。
在cognos中，身份认证是通过第三方的认证提供者来完成的，每个第三方的认证提供者被称为名空间。
第三方的认证提供者定义了用于认证的用户、用户组及角色。
在cognos中用户、用户组及角色三者之间的关系如上图所示。
其中用户组及角色的主要差别在于用户组是用户的基本标识的一部分，而角色却不是。
角色主要用于运行报表和作业。
在cognos名空间是缺省的名空间，它不能被修改。
在一期中，建议不使用这个缺省的名空间，而是建立一个dwmis名空间，以方便将来的管理。
Cognos在默认安装配置下没有启用任何安全设置，因为Cognos的设计思想是要及企业现有的身份认证基础设施相集成。
对于数据中心项目，我们将实现SunOneLDAP来集成数据中心目前的用户身份管理设施。
因此，Cognos的用户信息和数据中心的用户信息共享同一份数据，并使用SunOneLDAP来实现
Cognos使用组和角色来进行授权管理和访问控制。
组和角色信息定义在Cognos内部，又称为CognosGroup和CognosRole。
组和角色都代表了执行一系列相同任务，拥有相同的权限的用户。
组成员关系是用户身份的一部分，每次登陆时都是用户从属组中获得全部权限。
角色成员关系是不属于用户身份的一部分，用户可以选择每次登陆时使用的角色列表。
Cognos包括下列内建的（无法删除）安全条目：
⏹Anonymous用户，这是所有不需要身份认证的用户的共享帐号；
⏹AllAuthenticatedUsers组，代表所有非Anonymous用户；
⏹Everyone组，代表所有Anonynmous用户和AllAuthenticedUsers组的用户；
⏹SystemAdministrators角色，代表具有Cognos服务器全部管理权限的超级用户。
Cognos默认还设置了下列六个预定义的（可以删除）安全条目：
⏹Consumers角色，具有查看和执行公共内容的权限；
⏹QueryUsers角色，具有Consumers角色的权限，并且可以使用QueryStudio；
⏹Authors角色，具有QueryUsers角色的权限，并且可以使用ReportStudio来发布公共内容；
⏹ReportAdministrators角色，具有管理公共内容和访问QueryStudio及ReportStudio的权限；
⏹ServerAdministrators角色，具有管理服务器、调度器、作业的权限；
⏹DirectoryAdministrators角色，具有管理命名空间，包括组、角色数据源等对象的权限。
⏹对Cognos安装的默认配置进行下列修改提高安全性：
⏹配置数据中心项目的SunOneLDAP，并且禁用内建的Anonymous用户帐号；
⏹Everyone组是SystemAdministrators，Consumers，QueryUsers，和Authors角色的成员，必须立即删除，并根据需要设置Cognos的SystemAdministratiors角色的成员。
2.1.1身份管理系统
身份管理系统负责对用户身份的管理、验证、授权和私密性保护。
⏹管理涉及到如何创建、修改和取消身份。
好的管理能够显著降低成本和提高生产力。
它还可以大大缩短业务经理填写相关文件的时间，并可减少财务、人力资源以及IT人员审批和实施访问请求的时间。
⏹验证是证实访问网络、应用程序或资源的身份的操作。
验证技术包括基于用户ID的简单登录、密码，以及令牌、公匙证书和指纹验证等更为强大的机制。
在Web环境中，用户可以在一个站点甚至多个站点内跨多个Web服务器访问多个应用程序。
有效的身份管理和访问管理策略可以部署集中的验证框架，以便简化用户体验和降低管理工作量。
⏹授权是确定是否允许数字身份执行所请求操作的流程。
授权过程出现在验证之后，它可以使用及数字身份相关的属性或权限，以确定数字身份可以访问的资源。
例如，一旦用户通过验证，即可授权获得及其数字身份权利对应的限制信息访问权限。
⏹身份和访问管理技术可以使组织降低因扩大对其信息系统的访问而产生的风险。
由于可以对访问权限及特权进行精确控制，从而可以确保数字信息的私密性。
修改权限和/或终止访问的能力可以进一步增强这种保护的灵活性和一致性。
在本设计中，我们采用SunOneLDAP作为第三方认证提供着，用于存储不同来源的用户信息、资源信息和策略信息，实现统一的用户身份管理，统一的访问资源各类和统一的访问策略信息管理；
目录服务构成了身份和访问管理框架的核心，该目录服务将多个数据源（如目录、文本文件、数据库）结合在一起，从而为数字身份信息提供单一来源。
在SunOneLDAP的实现中可以有多个管理服务器和多个目录服务器，及多种组织形态。
在数据中心一期实现中，应用相对简单，建议使用单一的管理服务器和目录服务器来完成对用户目录和配置目录的管理。
具体实现方式详见《实施工艺手册》。
2.1.2应用安全
作为数字身份的最终使用者以及该身份权限的强制执行者，应用程序在所有身份管理解决方案中都扮演着重要角色。
应用程序必须及组织的身份管理基础结构兼容，对于应用程序开发而言，最重要的一点在于应用程序不应建立和实施其自身的身份库、安全协议或数据保护机制，而应依赖身份管理基础结构所提供的解决方案。
对于应用访问的安全，其主要设计体现在统一单点登录入口即Portal门户入口以及统一的用户安全认证及权限分配管理。
在数据中心一期实现中，典型的前端应用程序包括：
⏹元数据管理应用程序
⏹监管报表应用程序
⏹ALM应用程序
⏹多维立方体生成应用程序
⏹报表生成应用程序
2.1.3身份管理的技术架构
下图是一个典型的身份管理的技术架构：
PolicyServer
SecureAuditServer
Plug
-
In
AdminServer
DirectoryServer
WebServer
Portal
JavaAppServer
Application
WebServices
图3身份管理技术架构图
其中，Plug-in安装在Web服务器端，接到前端用户对安全内容的请求之后，它会将请求送到PolicyServer进行用户身份认证，PolicyServer则到目录服务器检索用户信息。
认证成功后，PolicyServer向Plug-in返回用户的授权信息，使该用户可以访问授权范围之内的内容。
PolicyServer返回的用户信息（包括用户的角色）可以以环境变量的形式通过Plug-in传递给应用程序，以完成页面的个性化，给不同的用户显示不同的操作界面。
AdminServer负责管理访问控制策略的制定，使不同的用户对不同的资源有不同的访问权限。
在本设计中，通过CognosSeries7利用SunOneLDAP服务实现了ReportNet和PowerPlay的统一用户、安全管理，SSO模块的主要作用是实现CognosCustomAuthenticationProvider，以支持UAAP安全认证服务。
下面以系统管理员维护为例，说明整个用户安全子系统的运行流程：
CognosContentManager
Oracle9iRepository
WebServer
Apache
2.0.53
ReportServer
Cognos
ReportNet
OLAPServer
.Cognos
PPES
CognosConnect
PortalServer
SunOne
Directory
Server
LDAP
JDBC
JSPI
JDBC
JDBC
TCP/IP
1
2
3
4
5
a
5
b
6
a
6
b
Administrator
RepositoryServer
Oracle9i
Teradata
ODBC
5
b
用户安全子系统运行流程
：
数据仓库系统管理员登录数据中心门户系统（CognosConnect）。
：
门户系统通过目录服务（SunOneDirectoryServer）认证管理员。
：
门户系统认证成功后将用户名、口令和TokenID写入Oracle9i数据库供CognosReportNet透明登录使用。
：
数据仓库系统管理员登录成功后点击CRN链接。
此链接指向WebServer（Apache2.0.53）。
：
用户组管理、模块授权管理均须操纵CognosContentManager。
由于CognosReportNet提供了JavaSDK，因此这个模块使用JSP开发，运行在WeblogicApplicationServer上。
：
数据安全管理是在Teradata中建立用户组和机构的对应关系，并在多维数据库的机构维建立过滤定义。
这个模块使用J2EE开发，程序分为两部分，一部分在WebServer上运行，访问Teradata数据库，建立用户组和机构的对应关系，同时作为客户端提交建立维度过滤的请求到OLAPServer上的CognosReportNet；另一部分在OLAPServer上运行，接受客户端（运行在WebServer上的JSP应用）请求，调用DSO建立维度过滤。
：
CognosReportNet通过JDBC将用户组、模块授权信息写入Oracle9i000上的ContentManager中。
：
OLAPServer通过JDBC将维度过滤信息写入CognosPPES上的Oracle9iRepository中。
2.2用户、用户组及角色
前端用户管理包括两个部分，用户（User）和用户组（Group）信息管理。
⏹用户（User）管理
用户（User）管理包括用户信息的维护、用户组的分配以及用户特殊功能的权限分配等。
一般来讲，在创建一个Portal用户的信息时，将同时要在Cognos服务器、Weblogic服务器、以及其他需要集成在Portal内的子系统中建立相应的用户信息；即在本系统中，用户信息时进行统一维护的。
⏹角色（Role）管理
在对用户进行权限分配时，将引入角色（Role）的概念，所谓角色，就是一个权限集合的定义，一个Portal用户可以赋予多个Portal角色，每个Portal角色都及之对应的Weblogic角色、Cognos用户类，用于定义对应用和数据的访问权限。
⏹用户组（Group）管理
用户组管理包括用户组创建、用户组修改、用户组权限分配等。
用户组是一组具有使用相同角色的用户群。
用户和用户组的关系是一个用户组可以包括多个用户，一个用户只可以属于一个用户组。
在cognos中用户可以拥有的权限如下：
⏹读（read）
浏览一个条目的所有属性；为一个条目创建快捷方式。
⏹写（write）
修改一个条目的属性；删除一个条目；在包或文件夹等容器中建立一个条目；修改一个报表的定义；为一个报表创建新的输出。
⏹执行（excute）
运行报表；在数据源中检索数据。
⏹设置策略（setpolicy）
读或修改一个条目的安全设置。
⏹遍历（traverse）
浏览包或容器中一个条目的内容；浏览容器本身的一般属性。
在Teradata数据库中用户可以拥有的权限Teradata数据库可以针对不同的用户，在不同级别的TeradataObjects（如Database、User、Table、View和Macro等）上进行多种类型的权限设定。
可以设定的权限包括：
Select,Update,执行权,所有权等等。
2.3用户、用户组划分
在本系统中，用户层包括各种最终用户。
主要分为技术用户、业务用户及管理用户三类：
Ø技术用户
技术用户主要是数据中心系统的管理者以及信息的管理者，他们的主要职责是完成数据中心系统的管理和信息的组织。
首先为业务用户提供最便捷的数据访问途经，其次为业务用户访问数据的正确性作出保障。
●应用开发人员（Applicationdevelopers）：
对数据转换和信息访问层都需要应用开发人员。
●TeradataDBA：
管理数据仓库的RDBMS引擎，维护物理数据模型，开发和维护备份及恢复过程，承担性能调整和负载管理工作以及容量的规划。
●ETL管理员（ETLAdministrator）：
监控数据加载流程。
●数据建模员（DataModeler）：
开发和维护数据仓库的逻辑数据模型。
Ø业务用户
按照用户使用数据中心系统的方式和特点，可以划分为业务人员、业务分析人员、决策人员和知识工作者。
●业务人员主要指总行各业务部门、各分行的业务用户，包括客户经理。
该类人员直接使用模块化的应用界面访问数据中心系统，访问预定义报表，进行相对固定的查询和较为简单的分析。
●业务分析人员是指总行各业务部门、各分行的较为高级的用户。
除能够执行一般业务人员进行的操作外，可以对指定的主题、指标进行自定义的灵活分析和比较。
分析的方式包括自定义查询、自定义报表、多维旋转和钻取等等。
●决策人员主要包括各部门的领导和行领导。
数据中心系统为决策人员分配专门的系统资源，建立最为直观和方便的存取界面，为决策人员赋予最大的信息访问权限，实现决策人员对信息的自由访问。
同时，信息资源系统将决策人员最为关心的信息主动发布到决策人员的访问界面上，简化信息访问的方式，使得决策人员在第一时间获得经营管理的各种重要信息和指标。
●知识工作者：
是最为高级的分析人员。
该类人员能够自由使用各种报表、查询、分析和挖掘工具，对银行业务和数据都由较为深刻的认识，特别是理解数据中心系统的数据模型，能够回答各种突发和复杂的业务问题，使用复杂的工具进行业务模型的建立和验证。
在进行复杂的业务分析或者进行数据挖掘的过程中，可能使用一些专业的工具，这类工具通常需要数据仓库系统导出大量数据供它们分析，这会耗费数据仓库系统大量资源，因此我们不建议知识工作者自己提交SQL请求给数据库，而是应首先经过管控的审批流程，提交请求给系统的DBA，DBA根据用户请求下载数据并提交到指定的目标位置。
对于普通用户来说，在经过数据管控流程的审批之后，通过相关的工具分析DBA导出的数据完成处理。
Ø管理用户
为每个业务单位（总行、分行）建立管理角色，管理角色具有Cognos的组织管理员和内容发布者角色，负责维护组织机构、发布文档。
如：
管理角色BJ（北京分行管理员），应被授予组织管理员和内容发布者双重角色，以便维护本行用户、组和发布文档。
●总行管理员将各业务单位管理员授予第一步设定的管理角色。
●总行管理员授予本分行用户访问数据中心系统的权限。
●分行管理员授予本分行用户访问数据中心系统的权限。
2.3.1用户/用户组分配
⏹前端用户分配：
使用浏览器访问数据仓库的前端用户是通过WebServer访问数据库的。
共有四种类型的用户：
用户类型
登录webserver用户
数据库用户名
前端管理员用户
Frontadm
Frontadm（不可以访问业务数据）
部门管理员用户
Department缩写+adm
不可以访问数据仓库
监管报表访问用户
由各个部门管理员设定
dmBuser
ALM访问用户
由各个部门管理员设定
dmBuser
Powe
升级会员 