银行新一代核心业务系统应用安全方案_V1.0.doc

华夏银行新一代核心业务系统
应用安全方案

华夏银行
新一代核心业务系统应用安全方案

版本记录
版本
版本日期
修改者
说明
V0.1
2006/9/5
中国惠普公司
初稿
V0.5
2006/10/20
中国惠普公司
依照华夏银行的建议，更改交易信息安全方案
V1.0
2006/11/11
中国惠普公司
依照华夏银行的建议，更改文档章节结构

目 录
1. 整体安全方案概论 6
1.1. 此分文档的目的 6
1.2. 整体安全方案概论 7
2. 目前核心系统安全现况及新一代核心业务系统应用安全需求 8
2.1. 目前核心系统安全现况 8
2.1.1. 业务范围 8
2.1.2. 系统架构 8
2.1.3. 系统应用安全现况 8
2.2. 新一代核心业务系统应用安全需求 9
2.2.1. 遵循华夏安全准则需求 9
2.2.2. 业务范围 9
2.2.3. 系统架构 9
2.2.4. 应用安全需求及处理 10
2.2.5. 安全标准、原则及需求 11
2.2.5.1. 安全标准 11
2.2.5.2. 安全原则 11
2.2.5.3. 安全需求 11
3. 身份验证 14
3.1. 身份验证方式 14
3.1.1. 动态口令验证方案 14
3.1.2. USB-Key验证方案 15
3.1.3. 身份验证方案建议实施方式与实施阶段 16
3.2. 身份验证系统架构方案 17
3.2.1. 单一入口服务系统(Portal)架构方案 17
4. 授权控制 20
4.1. 授权管理架构 21
4.1.1. 授权组织架构方案 21
4.1.2. 授权管理流程 22
4.2. 授权系统架构方案 25
4.2.1. SSO系统架构方案 25
4.2.2. 独立授权服务器架构方案 26
5. 传输安全 28
5.1. 网络安全 28
5.1.1. 链路加密机加密处理 28
5.1.2. 目前所了解BANCS系统的处理方式 28
5.1.3. 终端用户与BANCS Link间网络安全 29
5.1.4. BANCS Link与BANCS间网络安全 30
5.1.5. BANCS Link与综合前置间网络安全(组合交易) 30
5.1.6. 外围系统与综合前置间网络安全 31
5.1.7. 综合前置与BANCS间网络安全 31
5.2. 应用安全 32
5.2.1. 应用安全方案 32
5.2.2. 点对点的加密方案 32
5.2.3. 选择性的金融交易加密方案 33
5.2.4. 交易信息敏感性数据加密方案 33
5.2.5. 交易数据完整性方案 37
5.2.6. 服务器间验证方案 37
6. 存储安全 40
6.1. 交易数据安全存储方案 40
6.1.1. 交易敏感性数据加密存储方案 40
6.2. 密码安全存储方案 41
6.2.1. 动态口令登入密码存储方案 41
6.2.2. USB-Key登入密码存储方案 41
6.2.3. 客户口令加密存储方案 42
6.2.4. 客户口令不可逆存储方案 43
6.3. 新旧系统密码移转方案 43
6.3.1. 用户登入口令的移转 44
6.3.2. 客户支付口令的移转 44
7. 安全管理 46
7.1. 密钥管理方案 46
7.1.1. 密钥生命周期管理方案 46
7.1.2. 密钥更换管理方案 55
7.2. 防病毒管理 57
7.2.1. 病毒传播路径 57
7.2.2. 防堵病毒传播方法 57
7.2.3. 防治病毒的解决方案 58
8. 推荐方案 60
8.1. 身份验证方案建议 60
8.1.1. 建议方案的优/缺点分析 60
8.1.2. 建议实施方案 61
8.2. 授权控制方案建议 62
8.2.1. 建议方案的优/缺点分析 62
8.2.2. 建议实施方案 62
8.3. 传输安全方案建议 63
8.3.1. 建议方案的优/缺点分析 63
8.3.2. 建议实施方案 63
8.4. 存储安全方案建议 64
8.4.1. 建议方案的优/缺点分析 64
8.4.2. 建议实施方案 64
附件一：第二级信息系统安全等级 65
附件二：第三级信息系统安全等级 71

1. 整体安全方案概论

在目前网络发达、网上交易盛行、网络诈欺事件及智慧型网络盗窃犯罪层出不绝的状态下，银行业务处理面临前所未有的挑战；既要维护银行的信誉与保障客户数据不外泄，同时又要能即时无误的处理客户业务需求，让客户无安全上的顾虑(无论是柜面交易或是从渠道进来的交易)，业务交易处理安全上的考量变得非常重要。

规划一套业务应用安全机制及建设交易应用安全系统是当务之急的重要工作，尤其是对新一代核心业务系统更是重要。建设这种交易安全机制并不影响现行系统的运作，透过应用安全机制的建设，保护客户及银行的数据与资产，让业务交易处理的安全性及信息的保护更加完善，更是时时刻不容缓的工作。

1.1. 此分文档的目的

信息安全是金融机构处理日常工作的最重要的指标，保护客户的资产及银行的资本重要性，是银行业务处理的重心，核心系统应用安全是此文档要说明/表达的目的。

Ÿ 文档读者

华夏银行大集中办管理层领导、华夏银行信息技术部领导、华夏银行大集中办项目管理办公室人员、华夏银行信息技术部项目管理办公室人员、华夏银行大集中项目监督委员会成员、华夏银行大集中项目管理委员会成员、华夏银行大集中工程在建项目经理、组长等。

Ÿ 涵盖范围

本文档用于描述华夏银行新一代核心业务系统（NGCBS）项目中有关核心系统应用安全，由总体架构组(OSA)依华夏银行新核心系统应用安全需求，整理后的整体设计方案。
新一代核心业务系统(NGCBS)项目应用安全的范围包含：
Ÿ 交易数据的安全需求
Ÿ 数据传输的安全需求（广域网及局域网）
Ÿ 数据库中数据的安全需求
Ÿ 柜员的登录方式与授权管理

1.2. 整体安全方案概论

本方案的内容包含了以下几个面向：
Ÿ 身份验证的安全方案
身份验证的安全方案描述新一代核心系统应采用何种方案，确保终端用户登入系统的身份，避免使用假冒的身份。新一代核心系统的终端用户包含支行用户﹑分行用户﹑系统管理用户。此方案的详细内容请参考第3章。
Ÿ 授权控制(访问控制)的安全方案
授权控制的安全方案描述新一代核心系统应采用何种方案，确保每一位用户在系统上执行的作业或是系统功能均为合法的。避免因用户非法的操作造成业务上的损失。此方案的详细内容请参考第4章。
Ÿ 传输上的安全方案
传输上的安全方案分为网络层的安全与应用层的安全。网络层的安全是确保数据在网络上传输时，确保数据的私密性与完整性。应用层的安全是确保数据在输入终端至处理终端间的传输过程中，确保数据对中间处理系统的私密性与完整性。此方案的详细内容请参考第5章。
Ÿ 存储数据的安全方案
存储数据的安全方案描述新一代核心系统应采用何种方案，确保数据存储于数据库中的安全，包含数据的私密性安全与完整性安全。此方案的详细内容请参考第6章。
Ÿ 安全管理的方案
安全管理的方案包含两个部分，分别为密钥的安全管理与防病毒的安全管理。密钥的安全管理是描述密钥在生成﹑发布﹑备份﹑删除上的安全管理措施。防病毒安全管理是描述服务器与终端设备上防止病毒感染与病毒散步的安全管理措施。此方案的详细内容请参考第7章。

本方案所涵盖的安区方案对应于OSA的安全架构，可用下表说明：

安全标准
对应章节1
对应章节2
对应章节3
身份验证
3.身份验证

访问控制
4.授权控制

私密性
5.1网络安全
5.2.1.交易信息敏感性数据加密
6.存储安全
完整性

5.2.2.交易数据完整性

辨识性
5.2.4服务器间验证

不可否认性
5.2应用安全

在本方案的最后，针对各章所提出的各种方案，依据各个方案的优劣点，提出建议实施的内容，作为新一代核心系统安全方案实施上的考量。

2. 目前核心系统安全现况及新一代核心业务系统应用安全需求
2.1. 目前核心系统安全现况
2.1.1. 业务范围

目前华夏银行的2K版核心系统是采用各个分行分散式作业方式，华夏银行有28个分行，下辖大约总共300个支行；28个分行分布于全国各地，北从沈阳分行，南到深圳分行，西起乌鲁木齐分行，东达上海分行，幅员分布广阔。

2K版核心系统业务包含存款、放款等业务系统；其他的相关业务系统与管理系统皆各自建设在不同的外围系统上；每个分行有各自的外围系统，透过分行前置系统与2K版核心系统连接；各个分行有各自的中间特色业务系统，分行间的中间特色业务不尽全部相同；各个分行有各自的分行前置系统负责分行/支行间的业务交易处理。

2.1.2. 系统架构

华夏银行目前正进行大前置系统项目，要将所有分行前置系统整合为一个集中式的总行综合前置系统及分行前置系统；同时将中间特色业务系统全部整合在总行综合前置系统与分行前置系统上。

现有2K版核心系统后台的操作系统是AIX，前台VOST柜面系统服务器的操作系统是SCO Unix，前台柜面终端机的操作系统是SCO Unix。前台VOST柜面系统服务器放置在支行负责连接支行柜面交易与分行间的处理；有部分分行将前台VOST柜面系统服务器上收到分行端，有分行统一管理前端柜面系统。

2.1.3. 系统应用安全现况

目前2K系统的交易处理是由各个支行的柜面服务器到分行2K版核心系统，交易处理上是除了客户密码是以软件加密方式处理外，其他的交易数据是没经过加密处理，完全是以明码方式传送。

这种处理方式，对於交易信息的安全是无任何的保障；不安全影响所及的范围涵盖分行及下辖的支行员工与客户，对於客户资产及银行数据是完全没有任何的保护。

2.2. 新一代核心业务系统应用安全需求
2.2.1. 遵循华夏安全准则需求

依” 华夏银行大集中项目信息系统信息安全等级保护要求1103.doc”文档的规范，主要是着重在安全基本要求上的技术类安全要求，对於管理类安全要求，需依照华夏银行的安全管理规范或安全管理办法等条款办理。

新一代核心业务系统应用安全需求，是以基本技术要求中的应用安全和数据安全等两方面的安全要求来规划。技术类安全上，则是侧重在业务信息安全类，主要是保护数据在存储、传输、处理过程中不被泄漏、破坏和免受未授权的修改。业务服务保证类与通用安全保护类的安全需求，对保护系统连续正常的运行及保护系统的连续可用性需由新一代核心业务系统主机厂商对硬件及操作系统相关的建设与实施，同时华夏银行负责运行部门需订定相关的安全管理规范来保证系统的正常连续运作。

有关主机系统安全的规范，需由新一代核心业务系统主机厂商来提供硬件及操作系统相关的安全数据；数据库系统的安全需由数据库厂商提供相关的安全数据。

网络安全需由相关的路由器、交换机、通信线路等在内的厂商提供相关的信息系统网络环境的安全数据。

详细有关安全需求等级的规范对照，请详如本文档的附件章节。

2.2.2. 业务范围

新一代核心系统业务范围包含：存款、放款、华夏卡、支付结算等，所有的银行客户业务交易信息，皆与核心系统息息相关，是银行业务处理中最重要的部分。

2.2.3. 系统架构

新一代核心系统是采用集中式的作业方式处理，全国各地分行所有的交易全部都经由全行网络送到总行的新核心系统处理。

新一代核心业务系统，除了新一代核心系统外，尚有总帐系统、总行综合前置系统、55个(与新一代核心系统有接口关系的)外围系统、核心配套外围系统(从2K系统独立出来的系统，如:人行大/小额系统、理财系统、卡记点积分系统等)及其他系统等(与新一代核心系统无接口关系，如:人力资源系统、稽核系统等)。

新一代核心系统负责面向客户管理的交易处理作业；总帐系统负责面向华夏内部管理的后勤处理作业；综合前置系统负责华夏银行总行面向外部的交易处理(如对分行/支行交易处理、外围系统交易处理、中间特色业务系统交易处理、面向各种渠道交易处理、银联中心/银关通/银证通/财税库行/人民银行等外围金融机构的交易处理)，是华夏银行业务处理的重要把关门户。

新一代核心系统(BANCS)、前端柜面系统(BANCS Link)及柜员终端机的交易处理是采用集中式的作业方式，新一代核心系统产品并未有应用信息安全处理机制；目前华夏银行使用对客户密码采用软件加密的方式，对於最重要的新一代核心业务系统是无法满足应用信息安全的需要；加上目前外在环境的变化与智慧型网络犯罪的盛行，无法防范这些种种的威胁，对华夏银行及所有客户的整体影响更是深远。

2.2.4. 应用安全需求及处理

应用安全的规划，将从国际上的应用数据的安全标准(应用安全及传输安全)、安全原则(数据的真实性(私密性)、完整性(唯一性)、机密性(身份认证)和不可抵赖性(不可否认性))及安全需求，来逐步说明。

同时，在应用安全上需要搭配相关的硬件/软件加密设备来进行敏感性数据加密；在网络上需要采用链路加密设备，来处理网络层的传输安全需求。

2.2.5. 安全标准、原则及需求
2.2.5.1. 安全标准

Ÿ 应用的安全标准
安全上的标准主要有两种：数据加密标准(DES: Data Encryption Standard)与公开密钥法则(PKI: Public Key Algorithm)。

数据加密标准(DES):需要产生一对密钥，必须要将自己产生的另一个密钥发送给对方，本身端用自己的密钥加密，对方端用所送的密钥去解密。一般应用在数据的端对端的加密/解密使用，普遍用於金融机构的数据加密/解密。另外对数据加密的强化，采用Triple DES的加密方式。

公开密钥法则(PKI):需要产生一对钥值，分为公钥及密钥，自己保留密钥，公钥发送给对方。本身用密钥对数据加密，对方用所送的公钥验证数据的正确性。一般应用在网络电子交易的加密/解密处理。

Ÿ 传输的安全标准

网络层传输的安全标准，主要有几种，如：SSL (Secure Socket Layer)、VPN (Virtual Private Network)等来防护数据传输的安全。一般应用在网络层的数据传输加密/解密使用。业界一般常用的方式是SSL，但VPN的安全性较SSL的安全性高。

2.2.5.2. 安全原则

参考国际的安全准则要求及目前相关的安全解决方案，无论是动态口令、USB-Key或数字证书(Certificate)方案，应用上的安全或是传输过程中的安全要求，皆能实现数据的真实性(私密性)、完整性(唯一性)、机密性(身份认证)和不可抵赖性(不可否认性)。

2.2.5.3. 安全需求

安全需求，无论是应用的安全需求或是传输的安全需求，从安全要求的四大要素---真实性(私密性)、完整性(唯一性)、机密性(身份认证)和不可抵赖性(不可否认性)，来进行应用安全的处理。

Ÿ 私密/真实性：确认数据输入的私密/真实性
主要是保证数据是由发送方所发送的原始数据。

为了达到真实性的需求，必须对输入的数据进行加工，保持原始数据於传输过程中与原来是一样的。数据加工的方法之一既是对数据进行加密处理，保证送达的是原始数据。

加密处理可采用DES或PKI方式加密，对於数据量大或是加密频繁的交易，采用DES加密方式会比用PKI加密方式效率较好。PKI加密方式较适合於数据量小或是加密频繁性低的交易。

Ÿ 完整/唯一性：确认数据在传输的过程中不至於被篡改
主要是保证数据於传输过程中，不会被内部/外部人员篡改，保证原来的数据值。

为了达到完整性的需求，必须保障数据的完整性及不会於传输过程中被人篡改。

做法上是采用发送者的密钥对整个数据验算出一个MAC值，连同数据一起发送给收信方；若数据於传输过程中被篡改，受信方於受到数据后，用发送方所给予的密钥(DES)/公钥(PKI)对整个数据验算出一个MAC值，进行验证时，所验算出来的MAC值与发送者发送时所产生的MAC值不相同，即可确定数据被篡改。

Ÿ 机密性/身份确认：确认数据发送者的身份正确性
主要是确认数据发送者的身份是正确的，不是由其他人发送或有人假冒身份发送数据。

机密性的确认，做法上采用发送者所提供的密钥(DES)/公钥(PKI)对整个数据进行验算出一个MAC值，所验算出来的MAC值与发送者发送时所产生的MAC值相同，即可确认数据发送者的身份正确性。

Ÿ 不可否認/不可抵赖性：确认数据的正确及完整性
主要是确认整个数据的完整性及正确性与由发送者发送的数据是相同的，发送者无法否定此份数据不是由发送者所发送。

不可否認性的确认，做法上采用发送者所提供的密钥(DES)/公钥(PKI)对整个数据进行验算一个MAC值，所验算出来的MAC值与发送者发送时所产生的MAC值相同，即可确认数据的正确及完整性。

Ÿ 网络传输的安全需求
Ø 网络传输的内部安全需求

由於新一代核心系统才集中式作业处理，从华夏银行的支行/分行所发送的交易，全部经由网络传送到总行处理。除了上述的四点安全上的需求外，尚需要加入内部网络的传输安全布置(内部系统安全控制管理，如VPN/SSL/加密处理)才能完整的防护数据的安全。

支行/分行的网络传输应用安全需求，是华夏银行内部网络的交易，是固定/静态的交易处理；安全需求及防护上处理需要与外部不同。尤其内部的安全威胁及安全被破坏性大於外部。(内贼难防)

Ø 网络传输的外部安全需求

由於新一代核心系统才集中式作业处理，从不同渠道的交易也会经由网络传送到总行处理。除了上述的四点安全上的需求外，尚需要加入外部的网络传输安全布置(如动态口令)才能完整的防护数据的安全。

渠道的网络交易安全需求，是华夏银行外部网络的交易，是不固定/动态的交易处理；安全需求及防护上处理需要与内部不同。外部的安全威胁及安全被破坏性小於内部，但若是内部连同外部进行安全破坏，更是难防护。(外贼难防，内贼更难防)

3. 身份验证
3.1. 身份验证方式

新一代核心系统的用户包含了分行或支行的行员。分行与支行的行员都是透过BANCS Link登入到核心系统(BANCS)或是其他的外围系统。因此，不论核心系统(BANCS)或是外围系统都需要对登入的用户进行身份的核验工作，确认登入者的身份，以利控管系统操作存取的权限。
本建议书中，对于身份验证的机制，提供两个方案的选择，分别是动态口令验证与USB-Key验证方案。

3.1.1. 动态口令验证方案

动态口令验证的方式是设置并发放给每一个用户一个动态口令盘。用户登入系统时，采用以下的步骤：
(a) 用户利用动态口令盘产生动态口令。
(b) 用户再将动态口令输入登入页面的口令空格。
(c) 应用系统服务端透过动态口令服务系统验证动态口令是否正确，均定是否允许用户登入。

动态口令验证方案建议采用市面上成熟的动态口令系统，整合现有的应用系统实现用户统一的登入身份验证方法。动态口令系统建置一般包含下列的步骤：

(d) 引进并建置动态密码服务器系统。
(e) 规划用户基本信息与动态口令数据间的关系结构。
(f) 规划动态口令盘的设置﹑发放﹑回收等作业程序与管理措施。
(g) 依据动态口令盘的作业程序与管理措施，开发或客户化修改动态口令盘的管理应用系统。
(h) 应用系统配合动态口令服务系统的登入验证程序修改。

动态口令验证方案有下列的优点：
(a) 使用方便。用户只需使用动态口令盘在每次登入时产生口令即可。
(b) 用户终端设备无需安装任何的控制软件与提供任何额外的接口。
(c) 应用系统整合容易。应用系统只需于登入时调用动态口令系统提供的接口。

动态口令验证方案有下列的缺点：
(a) 一般的动态口令无法使用于交易数据的签名。
(b) 由于动态口令盘大多是采用离线作业方式，因此无法以连线侦测方式，侦测用户是否离席。

3.1.2. USB-Key验证方案

USB-Key验证方式是在USB-Key或IC卡上设置用户基本信息以及登入密钥，并发放给用户使用。用户登入系统时，采用以下的步骤：
(a) 将USB-Key插入终端设备或是将IC卡插入IC读卡机内。
(b) 用户输入USB-Key或IC卡的开启口令后，由登入页面自动读取USB-Key内的用户识别信息，并以登入密钥产生登入验证码。
(c) 应用服务端利用密钥验证技术验证用户的识别信息与验证码是否相符，决定是否允许登入系统。

USB-Key验证方案建议由有经验的安全系统开发商，依银行的需求规划建制一套符合需求的验证系统。USB-Key验证系统建置一般包含下列的步骤：

(a) 规划USB-Key内的用户验证信息与验证密钥结构与产生方法。
(b) 规划USB-Key的设置﹑发放﹑回收等作业程序与管理措施。
(c) 依据USB-Key的作业程序与管理措施，开发USB-Key的管理应用系统，与验证服务系统。
(d) 应用系统配合USB-Key验证服务系统的登入验证程序修改。以及登入页面配合USB-Key登入验证控件验证程序修改。

USB-Key验证方案有以下的优点：
(a) 采用双因素强验证 (包含USB-Key以及USB-Key的开启口令)。
(b) USB-Key与终端设备采用连线方式，可随时验证用户是否离席。
(c) USB-Key可采用双芯片(有线与无线)设计，于门禁系统结合。
(d) USB-Key可扩充加载数字证书，提供重要交易的数字签名功能。

USB-Key验证方式有以下的缺点：
(a) 市场上无统一标准的产品，需要开发建置。
(b) 用户终端设备上需提供USB接口(采用USB-Key)或是IC读卡机(采用IC卡)。
(c) 用户终端设备上需安装USB-Key的相关控件(可由登入页面自动下载安装)。
(d) 应用系统整合较为复杂，登入页面需依照USB-Key登入验证程序修改。

3.1.3. 身份验证方案建议实施方式与实施阶段

由于新一代核心系统的整体系统架构复杂，而且有许多的外围系统。因此实施方案上，建议分为初期实施范围与后续阶段实施范围。

在实施方式上，建议采用以下的实施方式：
(a) 由 BANCS Link 提供统一的登入页面，让用户登入。
(b) BANCS Link 将用户提交的身份验证数据，转发给核心服务系统(BANCS) 或 外围系统。
(c) 核心服务系统与外围系统，各自透过统一的身份验证服务系统验证用户提交的身份验证数据是否符合，决定是否允许登入系统。

在实施阶段范围上，建议采用以下的方式：
(a) 在初期阶段的实施范围，建议只有核心服务系统(BANCS)。其它各外围系统仍保留原有的身份验证方式。
(b) 后续阶段再逐一修给各个外围系统，将身份验证机制转移至统一的身份验证服务系统上。

3.2. 身份验证系统架构方案

3.2.1. 单一入口服务系统(Portal)架构方案

为了让用户有一个统一的入口与统一的身份验证机制，可以采用的方案之一是建置一套单一入口服务系统（Portal Server），负责提供用户的单一入口验证与用户权限管理机制。由单一入口系统提供所有系统，包含新核心系统﹑外围系统，统一的服务入口。单一入口系统所提供的功能不仅只是单一的登入入口(Single-Sign-On)，还包含整合用户与应用系统间的Session控管，以及用户对业务功能的权限管理等。

单一入口系统方案的实施，必须经过下列的步骤：
(a) 引进并建置一套单一入口服务系统。
(b) 规划单一入口系统的身份验证方案与业务权限控管方案。
(c) 规划各业务系统，包含核心系统﹑外围系统与单一入口系统间的Session控制流程。
(d) 规划单一入口系统上，各业务系统的业务与功能架构。
(e) 依照规划方案客户化单一入口系统。
(f) 依照规划方案修改或改造应用系统的Session控管机制与业务权限控管机制。
(g) 依照规划方案修改或改造应用系统的业务与功能架构。

单一入口系统方案虽然可提供全面的用户单一服务入口，但是在实施上会面临下列的问题：
(a) 单一入口系统的架构所考虑的不仅是统一登入入口的实施，更应该考虑所有业务架构的统一性与整合性。
(b) 单一入口系统对于各应用系统将的整合有一定的规范与标准(如JSR 168)。各应用系统必须依照规范与标准进行大幅度的修改或是改造。
(c) BANCS 与 BANCS Link 间的协定是采用新一代核心系统自有的协定，对采用单一入口的标准(如JSR 168)，有实施上的极大困难。
(d) 各分行的入口实际上是透过各分行所配置的BANCS Link服务器登入，并非直接的在单一入口系统(Portal)上登入。因此在系统架构上的配置会有困难度。

在面临以上困难的状况下，对于单一服务入口系统的实现，建议采用下列的方案：

(a) 系统架构

(b) BANCS与BANCS Link间仍采用原有架构与协定。
(c) BANCS Link 透过单一入口服务系统验证用户身份，并登入。
(d) BANCS Link 以单一入口服务系统回应的登入识别码，发送登入信息给 BANCS，由BANCS在透过单一入口服务系统的登入识别码验证机制进行虚拟身份验证。
(e) BANCS提供的业务功能，不透过单一入口服务系统，由BANCS自行管理用户的权限。
(f) 其它的外围系统，均必须依据 JSR 168 标准，修改或改造应用系统，与单一入口服务系统整合，透过但一入口服务系统调用业务应用服务。

单一入口服务系统方案有以下列的优点：
(a) 可达到用户单一的服务入口。
(b) 可提供用户统一的业务权限管理。

单一入口服务系统方案也有下列的缺点：
(a) 系统复杂度高，需要详细的规划。
(b) 现有系统(包含核心系统与外围系统)的配合实施难度高。
(c) 由于新一代核心系统的BANCS与BANCS Link间采用自有的协定，对于单一入口服务协定标准的配合可行性有待商榷。

· 独立身份验证服务器架构方案

另一种比较单纯的方案是建立一套独立的身份验证服务系统，提供新核心系统(BANCS)以及外围系统统一的身份验证机制。

此种方案的实施必须有下列的步骤：
(a) 开发建置一套独立的身份验证服务系统。
(b) 独立身份验证服务系统搭配选定的身份验证机制(动态口令或USB-Key)，实现身份验证功能。
(c) BANCS以及外围系统的登入功能依照独立身份验证服务系统提供的身份验证接口，修改登入验证程序。

此方案的系统架构图如下图：

此方案有以下的优点：
(a) 系统架构较为单纯，实施较为容易﹑省时。
(b) 可提供统一的用户身份验证，用户不需针对不同的应用系统使用不同的登入代码﹑密码，甚至登入方式。
(c) 应用系统(包含核心系统与外围系统)的修改幅度较小，容易整合。

此方案也有以下的缺点：
(a) 无法达到单一登入入口的服务水平，用户仍要在各个应用系统(包含核心系统与外围系统)执行登入动作。

4. 授权控制

目前华夏银行新一代核心系统项目，除了新核心系统、总帐系统及综合前置系统外，与新核心系统相关的外围系统约有55个系统。

於目前的时空环境下，也无法将所有的外围系统前台柜面界面全部转换为 BANCS Link前台柜面界面；部分的外围系统前台柜面环境将使用原来的前台柜面系统处理交易。同时，外围系统后台应用处理也是与新一代核心系统分开，各自处理各自的交易；核心系统及各个外围系统各自处理各个系统的交易授权。

於此情况下，对於柜员的业务处理授权可能无一致性的授权方式，每个系统必须自行处理交易授权。

考虑现实的状态及可行性的做法，有关授权控制将从建立一套完整的安全管理流程开始，再依目前状态，建立一个授权系统架构，来建设整体的授权控制管理。

4.1. 授权管理架构

授权控制从系统建设时开始，订定一套完整的安全管理流程；从系统安全组织建立开始，先建立系统原始安全控管人员，再由原始安全控管人员建立系统安全控制人员，再由系统安全控制人员建立业务交易的授权安全管理。授权控制说明如下：

4.1.1. 授权组织架构方案

ü 授权组织架构
授权管理建议依业务别与工作职责的划分，分别建立个别的群组授权，例如：

Ÿ 依工作职责划分的群组权限，将每个员工分为不同的群组，每个群组的授权依其工作职责给与不同的权限；每个员工可能属於一个以上的群组。
Ÿ 主管有核准的权限，但没有执行交易的权限
Ÿ 经办/柜员有执行交易的权限，但没有核准的权限
Ÿ 每个单位皆有自己职责的不同权限
Ÿ 建立安全管理群组经办，负责建立每个员工/主管代号及授权
Ÿ 建立安全管理群组主管，负责核准新建立的员工/主管及授权

4.1.2. 授权管理流程

ü 系统建置安全控制流程管

Ÿ 系统建置时，由厂商或华夏银行安全人员建立两位系统原始安全控管人员(一位为经办，一位为主管).
Ÿ 此两位原始安全控管人员，只限制在新增本系统所需要使用的安全控管人员
Ÿ 安全控管人员
Ø 先建立每个群组的交易权限(登录/核准)
Ø 再建立每个使用者数据（信息）
Ø 定义每个使用者所属分行代号及群组权限，并付予密码初始值(登录/核准)
Ÿ 使用者
Ø 使用者於前端柜面登入系统 (使用者第一次登入系统时，需要更改初始密码)
Ÿ 登入系统
Ø 检查使用者状态及使用者密码无误后，即可进入xxxxxxxxxxx系统.
(此时会依使用者的交易权限显示交易功能清单画面)

ü 安全管理流程

Ÿ 安全管理群组的经办员，依其权限能够登录使用者数据维护及群组数据维护
Ÿ 安全管理群组的主管，依其权限能够放行登录使用者数据异动及群组数据异动
Ÿ 各项参数维护、使用者数据查询、群组数据查询、使用者/群组数据明细表、使用者异动报表等，皆由安全管理群组人员负责维护

ü 使用者数据管理流程

Ÿ 使用者数据的建立及维护由安全管理人员负责。
Ÿ 使用者数据包含使用者所属的分行/支行数据、所属权限群组、使用者名称及密码等，同时使用者的登录记录及密码错误次数等数据，皆保留/存放，作为安控稽核凭证。

4.2. 授权系统架构方案

4.2.1. SSO系统架构方案

SSO授权系统架构是采用单一授权方式，经由对使用者的一次授权，使用者可依授权於各个业务系统进行业务操作处理。

SSO授权系统架构

SSO系统授权流程如下：
ü 使用者登入时，经由单一登入(SSO)登入单一登入网页(Portal Service)
ü 由单一登入网页(Portal Service)经由登入服务器(Access Control Server)，对使用者的代号与密码进行单一控管及验证，
ü 登入服务器(Access Control Server)会将使用者的代号及密码，一一转换为后台每个系统的使用者对应代号及密码，建立信任机制，登入每个系统；对使用者只要登入系统一次
ü 单一登入网页(Portal Service)会经由授权服务器(Authority Control Server)获得使用者所属的群组於每个系统中的授权
ü 使用者於一次登入后，可进入不同系统执行被授权的交易处理
ü 授权服务器(Authority Control Server)中有使用者於每个系统的授权数据，达到单一(SSO)授权目的；授权服务器(Authority Control Server)需先建立与每个系统的授权信任机制。

使用SSO系统架构方案的优点：
ü 单一/统一的授权管理方式，对未来新增业务系统或新增业务交易处理，依循此标准授权方式，建设非常方便/迅速
ü 方便/简化系统授权管理
ü 简化系统的交易处理流程

使用SSO系统架构方案的缺点：
ü 初期系统建置非常复杂，相关系统必需配合更改交易登入及交易授权
ü 建置成本较高

4.2.2. 独立授权服务器架构方案

独立授权服务器的授权方式，是在没有建立单一签入(SSO)的架构下，建置一套独立的授权机制，处理使用者的业务交易授权。

独立授权系统架构

独立授权服务器授权流程如下：
ü 独立授权服务器建立使用者的群组授权权限，与每个系统建立信任机制
ü 使用者登入系统完成后，由业务交易系统向独立授权服务器发送验证信息，经独立授权服务器确认后，使用者得进行业务交易处理

使用独立授权服务器架构方案的优点：
ü 建置成本较低
ü 初期系统建置复杂性小，相关应用系统更改幅度较小

使用独立授权服务器架构方案的缺点：
ü 只能简化一部分系统授权管理
ü 对未来新增业务系统或新增业务交易处理，各个业务系统的改动量较大
ü 无法简化系统的交易处理流程

5. 传输安全

传输安全包含两个部分，网络安全及应用安全；网络安全卓重在数据於网络中传输时的安全防护，应用安全注重於数据的加密处理，以防止数据被篡改。

5.1. 网络安全

应用数据於广域网络或局网中传输时，若采用明码传输方式会有安全上的顾虑，容易引起外部或内部有意人的数据截取与篡改，造成安全上的问题。

数据传输安全性的考量，从整体的网络及地理区域上分为下列几项：
Ÿ 支行到分行传输
Ÿ 分行到总行传输
Ÿ 总行服务器间传输
Ÿ 外部网络渠道传输
Ÿ 对外机构的传输

5.1.1. 链路加密机加密处理

对於上述数据传输的安全需求，第一个考虑的重点是在网络层加上网络传输加密处理，建议於每个路由器前皆需要加一套链路加密机，负责网络层的加密/解密处理。

从支行的路由器开始到分行/总行的路由器，皆需增加一套链路加密机。外围系统间的网络传输、外围系统与核心系统间的网络传输等，皆需要加一套链路加密机。

以下分为目前BANCS系统的处理方式及从地理区域考量说明如下：
5.1.2. 目前所了解BANCS系统的处理方式

新核心系统产品(BANCS 及 BANCS Link)的后台/前台的安全处理方式为：

Ÿ 前端柜面机与BANCS Link间(BANCS传输安全示意图中红色线条部分)
BANCS系统中有关前台柜面终端机与BANCS Link间，数据传输时，没有对数据进行加密处理。新核心系统厂商建议前端柜面终端机与BANCS Link间的数据传输，采用SSL加密处理；由於SSL加密只负责通信层在网络传输时的加密，对於重要数据/报文并未加密处理，安全上仍然有漏洞，需要有完善的补强措施。

Ÿ BANCS Link与BANCS间(BANCS传输安全示意图中红色线条部分)
BANCS系统中有关BANCS Link与BANCS间，数据传输时，没有对数据进行加密处理。新核心系统厂商建议由华夏订定安全策略及处理方式办理。

BANCS传输安全示意图

5.1.3. 终端用户与BANCS Link间网络安全

由於