您的当前位置:首页正文

银行新一代核心业务系统应用安全方案-V1.

2021-09-29 来源:钮旅网
WORD完美格式

..整理分享..

华夏银行新一代核心业务系统

应用安全方案

WORD完美格式

版本记录

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

WORD完美格式

目 录 1. 整体安全方案概论 .......................................................................................................................................... 6 1.1. 1.2. 2.

此分文档的目的 ................................................................................................................................... 6 整体安全方案概论 ............................................................................................................................... 7

目前核心系统安全现况及新一代核心业务系统应用安全需求 ......................................................................... 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.

授权控制 ....................................................................................................................................................... 21 4.1.

授权管理架构 ..................................................................................................................................... 22

4.1.1. 授权组织架构方案 ............................................................................................................................. 22 4.1.2. 授权管理流程 ..................................................................................................................................... 23

4.2.

授权系统架构方案 ............................................................................................................................. 26

4.2.1. SSO系统架构方案 .............................................................................................................................. 26 4.2.2. 独立授权服务器架构方案................................................................................................................... 27

5.

传输安全 ....................................................................................................................................................... 29

..整理分享..

WORD完美格式

5.1.

网络安全 ............................................................................................................................................ 29

5.1.1. 链路加密机加密处理 .......................................................................................................................... 29 5.1.2. 目前所了解BANCS系统的处理方式 ................................................................................................... 29 5.1.3. 终端用户与BANCS Link间网络安全 ................................................................................................... 30 5.1.4. BANCS Link与BANCS间网络安全 ..................................................................................................... 31 5.1.5. BANCS Link与综合前置间网络安全(组合交易) ................................................................................. 32 5.1.6. 外围系统与综合前置间网络安全 ........................................................................................................ 32 5.1.7. 综合前置与BANCS间网络安全 .......................................................................................................... 33

5.2.

应用安全 ............................................................................................................................................ 34

5.2.1. 应用安全方案 ..................................................................................................................................... 34 5.2.2. 点对点的加密方案 ............................................................................................................................. 34 5.2.3. 选择性的金融交易加密方案 ............................................................................................................... 35 5.2.4. 交易信息敏感性数据加密方案 ........................................................................................................... 35 5.2.5. 交易数据完整性方案 .......................................................................................................................... 39 5.2.6. 服务器间验证方案 ............................................................................................................................. 39

6.

存储安全 ....................................................................................................................................................... 42 6.1.

交易数据安全存储方案 ...................................................................................................................... 42

6.1.1. 交易敏感性数据加密存储方案 ........................................................................................................... 42

6.2.

密码安全存储方案 ............................................................................................................................. 43

6.2.1. 动态口令登入密码存储方案 ............................................................................................................... 43 6.2.2. USB-Key登入密码存储方案................................................................................................................ 44 6.2.3. 客户口令加密存储方案 ...................................................................................................................... 44 6.2.4. 客户口令不可逆存储方案................................................................................................................... 45

6.3.

新旧系统密码移转方案 ...................................................................................................................... 46

6.3.1. 用户登入口令的移转 .......................................................................................................................... 46 6.3.2. 客户支付口令的移转 .......................................................................................................................... 46

7.

安全管理 ....................................................................................................................................................... 49 7.1.

密钥管理方案 ..................................................................................................................................... 49

7.1.1. 密钥生命周期管理方案 ...................................................................................................................... 49 7.1.2. 密钥更换管理方案 ............................................................................................................................. 58

7.2.

防病毒管理 ........................................................................................................................................ 60

7.2.1. 病毒传播路径 ..................................................................................................................................... 60 7.2.2. 防堵病毒传播方法 ............................................................................................................................. 60 7.2.3. 防治病毒的解决方案 .......................................................................................................................... 61

8.

推荐方案 ....................................................................................................................................................... 63

..整理分享..

WORD完美格式

8.1.

身份验证方案建议 ............................................................................................................................. 63

8.1.1. 建议方案的优/缺点分析 ..................................................................................................................... 63 8.1.2. 建议实施方案 ..................................................................................................................................... 64

8.2.

授权控制方案建议 ............................................................................................................................. 66

8.2.1. 建议方案的优/缺点分析 ..................................................................................................................... 66 8.2.2. 建议实施方案 ..................................................................................................................................... 66

8.3.

传输安全方案建议 ............................................................................................................................. 68

8.3.1. 建议方案的优/缺点分析 ..................................................................................................................... 68 8.3.2. 建议实施方案 ..................................................................................................................................... 68

8.4.

存储安全方案建议 ............................................................................................................................. 70

8.4.1. 建议方案的优/缺点分析 ..................................................................................................................... 70 8.4.2. 建议实施方案 ..................................................................................................................................... 70

附件一:第二级信息系统安全等级....................................................................................................................... 71 附件二:第三级信息系统安全等级....................................................................................................................... 78

..整理分享..

WORD完美格式

1. 整体安全方案概论

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

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

1.1.

此分文档的目的

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

 文档读者

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

 涵盖范围

本文档用于描述华夏银行新一代核心业务系统(NGCBS)项目中有关核心系统应用安全,由总体架构组(OSA)依华夏银行新核心系统应用安全需求,整理后的整体设计方案。

新一代核心业务系统(NGCBS)项目应用安全的范围包含:    

交易数据的安全需求

数据传输的安全需求(广域网及局域网) 数据库中数据的安全需求 柜员的登录方式与授权管理

..整理分享..

WORD完美格式

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应用安全 在本方案的最后,针对各章所提出的各种方案,依据各个方案的优劣点,提出建议实施的内容,作为新一代核心系统安全方案实施上的考量。

..整理分享..

WORD完美格式

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版核心系统,交易处理上是除了客户密码是以软件加密方式处理外,其他的交易数据是没经过加密处理,完全是以明码方式传送。

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

..整理分享..

WORD完美格式

2.2.

新一代核心业务系统应用安全需求

2.2.1. 遵循华夏安全准则需求

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

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

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

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

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

2.2.2. 业务范围

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

2.2.3. 系统架构

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

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

..整理分享..

WORD完美格式

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

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

应用安全需求及处理

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

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

..整理分享..

WORD完美格式

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. 安全需求

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

 私密/真实性:确认数据输入的私密/真实性

..整理分享..

WORD完美格式

..整理分享..

主要是保证数据是由发送方所发送的原始数据。

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

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

完整/唯一性:确认数据在传输的过程中不至於被篡改

主要是保证数据於传输过程中,不会被内部/外部人员篡改,保证原来的数据值。

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

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

机密性/身份确认:确认数据发送者的身份正确性

主要是确认数据发送者的身份是正确的,不是由其他人发送或有人假冒身份发送数据。

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

不可否認/不可抵赖性:确认数据的正确及完整性

主要是确认整个数据的完整性及正确性与由发送者发送的数据是相同的,发送者无法否定此份数据不是由发送者所发送。

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

网络传输的安全需求

➢ 网络传输的内部安全需求

由於新一代核心系统才集中式作业处理,从华夏银行的支行/分行所发送的交易,全部经由网络传送到总行处理。除了上述的四点安全上的需求外,尚需要加入内部

WORD完美格式

网络的传输安全布置(内部系统安全控制管理,如VPN/SSL/加密处理)才能完整的防护数据的安全。

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

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

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

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

..整理分享..

WORD完美格式

3. 3.1.

身份验证 身份验证方式

新一代核心系统的用户包含了分行或支行的行员。分行与支行的行员都是透过BANCS Link登入到核心系统(BANCS)或是其他的外围系统。因此,不论核心系统(BANCS)或是外围系统都需要对登入的用户进行身份的核验工作,确认登入者的身份,以利控管系统操作存取的权限。

本建议书中,对于身份验证的机制,提供两个方案的选择,分别是动态口令验证与USB-Key验证方案。

3.1.1. 动态口令验证方案

动态口令验证的方式是设置并发放给每一个用户一个动态口令盘。用户登入系统时,采用以下的步骤:

(a) 用户利用动态口令盘产生动态口令。

(b) 用户再将动态口令输入登入页面的口令空格。

(c) 应用系统服务端透过动态口令服务系统验证动态口令是否正确,均定是否允许用户登入。

..整理分享..

WORD完美格式

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

(d) 引进并建置动态密码服务器系统。

(e) 规划用户基本信息与动态口令数据间的关系结构。

(f) 规划动态口令盘的设置﹑发放﹑回收等作业程序与管理措施。

(g) 依据动态口令盘的作业程序与管理措施,开发或客户化修改动态口令盘的管理应用系统。

(h) 应用系统配合动态口令服务系统的登入验证程序修改。

动态口令验证方案有下列的优点:

(a) 使用方便。用户只需使用动态口令盘在每次登入时产生口令即可。 (b) 用户终端设备无需安装任何的控制软件与提供任何额外的接口。

(c) 应用系统整合容易。应用系统只需于登入时调用动态口令系统提供的接口。

动态口令验证方案有下列的缺点:

(a) 一般的动态口令无法使用于交易数据的签名。

(b) 由于动态口令盘大多是采用离线作业方式,因此无法以连线侦测方式,侦测用户是否离席。

3.1.2. USB-Key验证方案

..整理分享..

WORD完美格式

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) 或 外

围系统。

..整理分享..

WORD完美格式

(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),有实施上的极大困难。

..整理分享..

WORD完美格式

(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) 可提供用户统一的业务权限管理。

..整理分享..

WORD完美格式

单一入口服务系统方案也有下列的缺点:

(a) 系统复杂度高,需要详细的规划。

(b) 现有系统(包含核心系统与外围系统)的配合实施难度高。

(c) 由于新一代核心系统的BANCS与BANCS Link间采用自有的协定,对于单一入口服务协定标准的配合可行性有待商榷。

..整理分享..

WORD完美格式

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

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

此种方案的实施必须有下列的步骤:

(a) 开发建置一套独立的身份验证服务系统。

(b) 独立身份验证服务系统搭配选定的身份验证机制(动态口令或USB-Key),实现身份验证功能。

(c) BANCS以及外围系统的登入功能依照独立身份验证服务系统提供的身份验证接口,修改登入验证程序。

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

此方案有以下的优点:

(a) 系统架构较为单纯,实施较为容易﹑省时。

(b) 可提供统一的用户身份验证,用户不需针对不同的应用系统使用不同的登入代码﹑密码,甚至登入方式。

(c) 应用系统(包含核心系统与外围系统)的修改幅度较小,容易整合。

此方案也有以下的缺点:

(a) 无法达到单一登入入口的服务水平,用户仍要在各个应用系统(包含核心系统与外围系统)执行登入动作。

..整理分享..

WORD完美格式

4.

授权控制

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

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

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

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

..整理分享..

WORD完美格式

4.1.

授权管理架构

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

4.1.1. 授权组织架构方案

✓ 授权组织架构

授权管理建议依业务别与工作职责的划分,分别建立个别的群组授权,例如:

 依工作职责划分的群组权限,将每个员工分为不同的群组,每个群组的授权

依其工作职责给与不同的权限;每个员工可能属於一个以上的群组。  主管有核准的权限,但没有执行交易的权限

 经办/柜员有执行交易的权限,但没有核准的权限  每个单位皆有自己职责的不同权限

 建立安全管理群组经办,负责建立每个员工/主管代号及授权  建立安全管理群组主管,负责核准新建立的员工/主管及授权

..整理分享..

WORD完美格式

4.1.2. 授权管理流程

✓ 系统建置安全控制流程管  系统建置时,由厂商或华夏银行安全人员建立两位系统原始安全控管人员

(一位为经办,一位为主管).  此两位原始安全控管人员,只限制在新增本系统所需要使用的安全控管人员  安全控管人员

➢ 先建立每个群组的交易权限(登录/核准) ➢ 再建立每个使用者数据(信息)

➢ 定义每个使用者所属分行代号及群组权限,并付予密码初始值(登录/核

准)

 使用者

➢ 使用者於前端柜面登入系统 (使用者第一次登入系统时,需要更改初始

密码)

 登入系统

➢ 检查使用者状态及使用者密码无误后,即可进入xxxxxxxxxxx系统. (此时会依使用者的交易权限显示交易功能清单画面)

..整理分享..

WORD完美格式

✓ 安全管理流程

 安全管理群组的经办员,依其权限能够登录使用者数据维护及群组数据维护  安全管理群组的主管,依其权限能够放行登录使用者数据异动及群组数据异

 各项参数维护、使用者数据查询、群组数据查询、使用者/群组数据明细

表、使用者异动报表等,皆由安全管理群组人员负责维护

..整理分享..

WORD完美格式

✓ 使用者数据管理流程

 使用者数据的建立及维护由安全管理人员负责。

 使用者数据包含使用者所属的分行/支行数据、所属权限群组、使用者名称

及密码等,同时使用者的登录记录及密码错误次数等数据,皆保留/存放,

..整理分享..

作为安控稽核凭证。

WORD完美格式

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)

获得使用者所属的群组於每个系统中的授权

✓ 使用者於一次登入后,可进入不同系统执行被授权的交易处理

..整理分享..

WORD完美格式

✓ 授权服务器(Authority Control Server)中有使用者於每个系统的授权数据,达

到单一(SSO)授权目的;授权服务器(Authority Control Server)需先建立与每个系统的授权信任机制。

使用SSO系统架构方案的优点:

✓ 单一/统一的授权管理方式,对未来新增业务系统或新增业务交易处理,依循此

标准授权方式,建设非常方便/迅速 ✓ 方便/简化系统授权管理 ✓ 简化系统的交易处理流程

使用SSO系统架构方案的缺点:

✓ 初期系统建置非常复杂,相关系统必需配合更改交易登入及交易授权 ✓ 建置成本较高

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

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

独立授权系统架构

..整理分享..

WORD完美格式

独立授权服务器授权流程如下:

✓ 独立授权服务器建立使用者的群组授权权限,与每个系统建立信任机制

✓ 使用者登入系统完成后,由业务交易系统向独立授权服务器发送验证信息,经

独立授权服务器确认后,使用者得进行业务交易处理

使用独立授权服务器架构方案的优点: ✓ 建置成本较低

✓ 初期系统建置复杂性小,相关应用系统更改幅度较小

使用独立授权服务器架构方案的缺点: ✓ 只能简化一部分系统授权管理

✓ 对未来新增业务系统或新增业务交易处理,各个业务系统的改动量较大 ✓ 无法简化系统的交易处理流程

..整理分享..

WORD完美格式

5.

传输安全

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

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

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

5.1.1. 链路加密机加密处理

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

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

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

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

 前端柜面机与BANCS Link间(BANCS传输安全示意图中红色线条部分)

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

..整理分享..

WORD完美格式

BANCS Link与BANCS间(BANCS传输安全示意图中红色线条部分)

BANCS系统中有关BANCS Link与BANCS间,数据传输时,没有对数据进行加密处理。新核心系统厂商建议由华夏订定安全策略及处理方式办理。

BANCS传输安全示意图

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

由於华夏银行28个分行分布广阔,每个分行下约有10~12个支行,每个支行不配置BANCS Link柜面服务器,每个支行的柜面终端机需直接连结到分行的BANCS Link柜面服务器,经由BANCS Link柜面服务器连接到总行核心系统。

目前华夏银行已经启动网络建设项目,网络安全上,已经将总行与分行间的网络安全采用VPN方式处理,保护总行与分行间的网络安全。分行与支行间尚未建置网络安全处理。

..整理分享..

WORD完美格式

分行与支行间网络传输安全示意图

5.1.4. BANCS Link与BANCS间网络安全

由於BANCS系统中有关BANCS Link与BANCS间,数据传输时,没有对数据进行加密处理,必须完善分行与总行间的网络(数据传输)安全。

网络传输安全处理:

✓ 於分行服务器(BANCS Link Server)将数据传输到总行前,采用链路加密机

来对网络传输数据进行加密处理后,传送到总行。

✓ 总行交易处理完成后,透过链路加密机进行网络层的加密处理,送回分行服务

✓ 分行服务器先由链路加密机将数据进行网络层的解密,再由加密机进行交易数

据3DES解密处理后,传送到柜员端显现於柜面终端机页面上

✓ 链路加密机的接入对应用系统来讲是透明的,即与应用系统无关,不需要更改

任何应用系统程序。

..整理分享..

WORD完美格式

分行与总行间网络传输安全示意图

5.1.5. BANCS Link与综合前置间网络安全(组合交易)

综合前置系统主要负责进出总行后台业务应用软件系统的桥梁,处理的交易数量众多及对处理的效率需求要能良好,若要考量安全上的需要,可能会对综合前置系统处理交易量及效率会有影响;要兼顾安全需要,同时要确保处理效率,不是件容易的事,可能无法两者兼顾。

考量综合前置系统的交易处理类型及方式,除了组合型交易及中间特色业务外,其余的业务处理对综合前置系统来说都只是过路财神---左近右出或右近左出,对於此类的交易,不需要在综合前置系统进行解密后再加密送出,直接直转送出即可;即进出皆由链路加密机处理。

网络传输安全处理:

✓ 於分行服务器(BANCS Link Server)将数据传输到综合前置系统前,采用链路

加密机来对网络传输数据进行加密处理后传送

✓ 综合前置系统收到其他系统送到分行服务器(BANCS Link Server)的交易,透

过链路加密机进行网络层的加密处理,送回分行服务器

5.1.6. 外围系统与综合前置间网络安全

网络传输安全处理:

..整理分享..

WORD完美格式

✓ 於外围系统将数据传输到综合前置系统前,采用链路加密机来对网络传输数据

进行加密处理后传送

✓ 综合前置系统收到其他系统送到外围系统的交易,透过链路加密机进行网络层

的加密处理,送回外围系统

5.1.7. 综合前置与BANCS间网络安全

网络传输安全处理:

✓ 於综合前置系统将数据传输到核心系统(BANCS)前,采用链路加密机来对网络

传输数据进行加密处理后传送

✓ 核心系统(BANCS)透过链路加密机进行网络层的加密处理,送到综合前置系统

..整理分享..

WORD完美格式

5.2.

应用安全

5.2.1. 应用安全方案

在网络安全方案中对于网络层均提供了链路加密机制。所以基本上,交易信息在网络传输过程中均属据加密状态。 5.2.2. 点对点的加密方案

因此,在这里要考虑的应用信息加密主要是针对点对点的交易数据加密需求。这些点对点包含:

(a) 用户对 BANCS Link。 (b) 用户对BANCS。 (c) 用户对外围系统。 (d) 外围系统对BANCS。

点对点间的交易数据加密需求,着重在核心系统(BANCS)、综合前置系统及分行服务器(BANCS Link)间的应用加密处理,此三个系统前需要增加一套应用加密机来处理交易数据加密;对於外围系统不建议采用应用加密处理。

点对点应用加密架构图

..整理分享..

WORD完美格式

在整个新一代核心系统的交易信息需求分析上,发现并无需要整个信息执行点对点的信息加密需求。只有针对部分敏感性的交易数据需要点对点的加密需求。敏感性数据的加密需求将在下一个章节提供具体方案。

5.2.3. 选择性的金融交易加密方案

考虑交易的风险性及网络交易便利性,建议华夏银行对所有的金融交易皆进行应用加密处理;华夏银行可考虑实际上交易处理效率的需要,选取某些类别的金融交易进行应用加密处理。例如:跨银行/跨分行的取款交易、跨银行/跨分行的汇款交易、跨分行的通存交易、变更密码交易、变更客户名称/ID/地址交易等。

国外的经验一般采用所有的金融交易都需要做应用加密处理;虽然有些金融机构采用选择性的金融交易做应用加密处理,未来产生的风险要由建议单位/人负责承担。

核心系统开发商的建置客户中,台新银行选择了四种金融交易进行应用数据加密处理:

20017 –先进汇款 remittance by cash

21016 –汇出汇款(专帐交易) remittance by transfer

55032 –汇出登录 remittance data entry (supplementary data entry) 55040 –汇出放行 remittance approval

5.2.4. 交易信息敏感性数据加密方案

交易敏感性数据加密需求是针对部分的交易数据,必须从交易发动源头进行加密,直到交易终点处理是方可解开或是进行验证。这部分的方案主要是针对客户支付口令的绝对私密性,不得在交易过程中有任何泄漏的风险。

对于客户口令加密的方案可以分成几种情形说明:

(1) 大前置系统与核心系统(BANCS)

大前置系统与核心系统间交易数据的加密,建议采用Triple-DES加密方式,以下列的原则实施:

..整理分享..

WORD完美格式

(a) 由交易发起端对客户口令,以核心系统产生的「口令加密密钥」加密后(加密方

式建议遵循ANS X9.8规范),再放入交易信息内发送。

(b) 交易接受端接收到交易信息后,将信息内以「口令加密密钥」加密的客户口令

与数据库内加密的客户口令直接提交给加密机进行比对,确认是否符合。 (c) 客户口令的加密比对必须在加密机内一次完成,不得语应用系统中解开。 (d) 「口令加密密钥」由核心系统透过加密机产生,再利用密钥同步信息交换机

制,与外围系统进行同步。

(2) 用户与核心系统(BANCS) – 点对点加密

由于用户终端设备并无任何的加密设备。因此用户终端的加密必须考虑采用加密密钥可公开的加密方式。此方案是利用非对称密钥的公钥可公开的技术,直接在用户终端备上一软件方式加密,再与核心系统端解开比对。此种方法采用以下的实施原则:

..整理分享..

WORD完美格式

(3)..整理分享..

(e) 核心系统透过加密机产生加密用的交易加密的非对称密钥(RSA key pair),并取出公钥(Public key),称为「交易加密公钥」。

(f) 核心系统将「交易加密公钥」发布给所有的 BANCS Links。

(g) 用户在BANCS Links上提交交易数据时,交易页面动态产生对称(Triple-DES)的「动态口令加密密钥」,对客户口令进行加密。(口令加密建议遵循ANS X9.8原则)。

(h) 交易页面在将「动态口令加密密钥」以「交易加密公钥」加密后,连同交易数据提交 BANCS Link。

(i) BANCS Links将加密后的交易数据,以及加密后的「动态口令加密密钥」一并以交易信息送交核心系统(BANCS)。

(j) 核心系统(BANCS)受到交易信息后,先利用「交易加密私钥」(Private key)解开「动态口令加密密钥」,再以「动态口令加密密钥」比对客户口令。 (k) 核心系统(BANCS)对于「动态口令加密密钥」的解开,以及客户口令加密比对的动作,应该透过加密机一次性完成。

用户与核心系统(BANCS) – BANCS Link加密

另一种方案是基于用户终端与BANCS Link间采用SSL或VPN网络加密方式,认定其交易信息泄露几率极小的前提下。只在BANCS Links与BANCS间对口令加密。采用以下的实施原则:

WORD完美格式

(4)..整理分享..

(a) 核心系统透过加密机产生加密用的「口令加密密钥」(Triple-DES keys) ,并利用密钥同步信息交换机制,与BANCS Links进行同步。 (b) 用户与安全页面上提交交易数据,包含客户口令。

(c) 交易数据透过安全网络(VPN或是SSL),送到BANCS Link。

(d) BANCS Link 收到用户提交的交易数据后,利用「口令加密密钥」对客户口令加密后,放入交易信息内送交核心系统(BANCS)。

(e) 核心系统(BANCS)受到交易信息后,利用「口令加密密钥」解开并比对客户支付口令。

(f) 核心系统(BANCS)对于以「口令加密密钥」解开并比对客户支付口令的动作,应该透过加密机一次性完成。

用户终端与外围系统

用户与外围系统间对于客户口令的加密沿用各外围系统目前的做法,建议不予改变。

WORD完美格式

5.2.5. 交易数据完整性方案

由于本建议方案中对于服务器间的网络,均以网络层加密机制保护。交易信息在网络上传输时,保持加密状态。因此就整体安全需求上,比较没有交易数据完整性上的需求。

5.2.6. 服务器间验证方案

各服务器间的验证目的是在防止内部人员利用假服务器发动假交易,造成交易的纠纷以及金额上的损失。服务器间的验证依据连线模式不同而必须有不同的设计方案。在这里,我们假设服务器间的交易连接方式是采用非固定连接方式(Connectionless)。在此总连接方式下,服务器必须对每一笔交易信息均验证该交易发送方是否为合法的服务器。验证方式有下列两种:

(1) IP验证法

IP验证法是针对没每一个交易信息验证信息发送方的IP是否为对应的合法IP。

此种验证法必须采用下列的实施步骤:

(a) 每一部服务器必须设置一个固定的对外IP。

(b) 应用系统中须设置每一个交易方服务器的正确IP。

..整理分享..

WORD完美格式

(2)..整理分享..

(c) 当应用系统收到交易信息时,透过网络层取得发送方的IP,再验证发送方的IP与设置中合法交易信息发送方的IP是否一致。

此种验证法有以下的优点:

(a) 不须改变交易信息的格式与交易流程。

(b) 透过交易信息收发的网络层信息即可取得验证数据。

此种验证法有以下的缺点:

(a) 每一个服务器在网络层必须有固定的IP,对于使用VPN或是虚拟IP交换器的网络并不适用。

(b) 只用IP的验证方法在安全上比较薄弱。有可能假服务器暂时取代合法服务器的IP而不会被察觉。

(c) 当服务器因为网络位置变更,而更改IP 时,必须更该其他应用系统上的IP设置。

信息押码验证法

信息押码验证法是在交易信息中,将部分的交易数据以密钥加密的方式,产生验证码,再将验证法放入交易信息中一起发送。交易接收方再以同样的方法﹑同样的密钥检核验证码是否正确。产生验证码的密钥通常使用Triple-DES的密钥以及加密算法(建议采用CBC加密模式)。

此种验证法必须采用下列的步骤:

(a) 交易信息必须增设交易验证码的字段。

WORD完美格式

..整理分享..

(b) 定义每一个交易信息内,用以产生验证码的交易数据字段。 (c) 规划验证码密钥的产生规则与变更的同步交换规则。

(d) 依照规划的验证码产生/验证规则,修改应用系统信息收送的机制。 (e) 开发个服务系统间的密钥变更同步交换功能。

此种验证法有以下的优点:

(a) 此种验证方式,可使用与任何的网络环境。

(b) 不锁定服务器的网络地址与实体位置,服务器的网络位置变更不影响任何设置。

(c) 较高的安全强度,必须有存取密钥的权限才能产生验证码。

此种验证法有以下的缺点:

(a) 此种方法必须配合加密机使用,成本较高。

(b) 次种方法必须变更交易信息格式,增加验证码字段。 (c) 应用系统配合修改的幅度较大。 WORD完美格式

6.

存储安全

数据安全方案,主要以保护数据不被任意更改/篡改,确保数据的完整性为主。交易的数据中包含许多种信息,无法对所有的交易及将整个交易报文数据加/解密,可能会影响交易处理效率,建议只对报文的敏感性数据进行加/解密处理,同时要考量交易数据存储的安全。

6.1.

交易数据安全存储方案

6.1.1. 交易敏感性数据加密存储方案

(1) 敏感性交易数据

由於核心系统是整体系统交易的重心,对於交易数据的安全处理特别重要,尤其是客户的交易数据安全。交易的报文中,包含许多敏感性数据,如:

 客户帐号/卡号  客户密码  交易金额

 交易时间(含:年月日时分秒)

(2) 敏感性交易数据的加密处理方式

对於敏感性的交易数据,必须要加密处理,以确保数据的完整性、正确性及不可否认性。敏感性交易数据的加密方式,建议采用以3DES密钥加密处理外,同时视需要,对整个报文/关键字段以MAC生成校验值。(不建议采用PKI加密方式,主要是PKI加密速度较费时。)

 敏感性交易数据交易传输流程中,需经硬件应用及链路加密处理,尤其是客户

密码需全程以乱码方式传输

 加密/解密处理,需经由硬件加密/解密机处理;禁止使用软件加/解密处理

对於上述的敏感性交易数据,由应用软件系统透过API呼叫方式,连接外接的加密机进行加密处理,采用以3DES密钥方式加密处理,同时生成MAC校验值,透过网络传送后台应用软件。

(3) 核心系统对敏感性交易数据的处理流程

..整理分享..

WORD完美格式

为了减少核心系统的复杂性及减少核心系统的更改量,以免影响项目进度及时程,建议核心系统对交易数据的安全处理如下:

 BANCS Link於收到支行/分行的交易数据时,发送到核心系统前,先呼叫应用

加密机对报文数据中的敏感性交易数据加密处理,同时要求加密机对整个报文/关键字段以MAC生成校验值。

 核心系统收到敏感性交易数据时,先呼叫应用加密机对报文数据中的敏感性交

易数据解密处理,同时要求加密机对整个报文/关键字段的MAC校验值验证正确性后,才进行相关交易程序处理。

(4) 敏感性交易数据存储

除了加密处理外,对於敏感性交易数据的存储安全,也非常需要加以特别重视,以免敏感性交易数据被有心人窃取、窥视。

有关敏感性交易数据的存储安全,建议处理方式如下:

 客户密码於柜员终端输入时,以乱码呈现;

 关敏感性交易数据输入后,传送前,需经硬件加密机进行应用加密处理;  传输过程中,全程以乱码传送;

 应用软件系统后台以API呼叫方式,呼叫硬件加密机验证客户密码的正确性及

将其他的敏感性交易数据解密处理

 客户密码存储於数据库时,是以乱码方式存放。 6.2.

密码安全存储方案

密码包含用户登入密码﹑客户密码两种。两种密码的存储各有不同的建议方案。

6.2.1. 动态口令登入密码存储方案

采用动态口令盘的身份验证方式,用户的动态口令是依着时间不停的演变。而密码的验证方式是由动态口令服务系统于系统内部自行验证。因此用户的密码存储是由动态口令服务系统本身具备的密码保护的安全机制负责。

因此,用户的登入密码(口令)不需要另行存储。

..整理分享..

WORD完美格式

6.2.2. USB-Key登入密码存储方案

采用USB-Key的身份验证方式,用户的口令是打开USB-Key存储的口令,直接存储于USB-Key中,以USB-Key本身的安全机制保护。

USB-Key内的登入验证密钥,是由加密机依据用户代码以验证主密码利用多样化演算法(Diverse)产生。而验证主密钥直接存储于加密机中。

因此,用户的USB-Key口令与USB-Key内的验证密钥均不需要另行存储。

6.2.3. 客户口令加密存储方案

客户口令是随着交易信息传送与服务期间。因此透过交易信息的客户口令的点对点加密机制,所有的交易信息内的客户口令均为加密状态。

唯一会存储客户口令的系统应该是新核心系统(BANCS)。由于客户数量庞大,一般不可能直接存储于加密机中,而存储于数据库中。为了避免客户口令泄漏,必须以加密方式存储于数据库中。建议采用以下的方式:

(a) 利用加密机产生或是采用指定方式产生客户口令。

(b) 客户口令产生后,直接以加密机的客户口令存储加密密钥加密后(建议采用ANS X9.8规范),存储与数据库内。

(c) 客户口令存储加密密钥建议使用Triple-DES。

..整理分享..

WORD完美格式

(d) 客户口令比对时,直接将交易信息内加密的客户口令与数据库的加密客户口令提交给加密机,由加密机解密比对后,送回结果。

(e) 当加密机内的客户口令加密密钥变更时,必须对数据库内所有用户的客户密钥进行重行加密处理(解密再加密)后再存储。

此种客户口令加密存储方法有下列的优点: (a) 加密强度较强,不易泄漏。

但此种客户口令加密存储方法也有下了的缺点:

(a) 加密密钥更换时,必须重行加密所有的口令,处理费时繁复。

(b) 如果加密密钥遗失,所有的客户口令皆失效,必须请客户从刑设置,可能造成重大损失。

6.2.4. 客户口令不可逆存储方案

另一种存储客户口令的方法是采用不可逆运算,将客户口令转换成不可还原的数字,直接存储于数据库中。此种方法采用下了的方式:

(a) 利用加密机产生或是采用指定方式产生客户口令。

(b) 客户口令产生后,直接以不可逆运算将客户口令转换成一组不可还原的口令数字存储与数据库内。

(c) 客户口令不可逆运算,建议可使用SHA-256。

..整理分享..

WORD完美格式

(d) 客户口令比对时,直接将交易信息内加密的客户口令与数据库的口令数字提交给加密机,由加密机解密比对后,送回结果。

此种客户口令不可逆存储方法有下列的优点: (a) 理论上无法利用口令数字还原正确的口令。

(b) 不需使用密钥,维护上比较简单,依不需考虑密钥变更的问题。

但此种客户口令不可逆存储方法也有下了的缺点:

(a) 不可逆运算理论上造成重复的几率不等于零,有可能不同的口令会产生相同的口令数字。因此猜中的几率并非完全没有。 6.3.

新旧系统密码移转方案

于本建议方案中,对于新旧系统间的密码已转问题,可从下列几方面说明:

6.3.1. 用户登入口令的移转

由于新系统于旧系统间使用的身份验证方式不同。不论新系统采用动态口令盘或是USB-Key的那一种方案,用户的登入口令都必须换新。因此,建议采用下列的步骤:

(a) 预先制作所有用户登入使用的动态口令盘或是USB-Key。

(b) 先行发放动态口令盘或是USB-Key给用户,并于新系统上设置每一个用户使用的动态口令盘编号或是USB-Key编号。

(c) 当业务由旧系统切换为新系统时,要求所有用户开始使用动态口令或USB-Key登入系统。

(d) 原有旧系统上的登入口令立即作废。

6.3.2. 客户支付口令的移转

对于客户的口令,基于客户的方便性,不能因系统转换而更换客户的口令。若新系统采用客户口令加密存储的方案,则建议采用下列的步骤:

..整理分享..

WORD完美格式

..整理分享..

(a) 利用加密机产生新的客户口令加密密钥。

(b) 将原有旧系统的客户口令加密密钥,汇入/输入加密机内。

(c) 开发一个程序,将原有旧系统的所有客户口令利用加密机重新加密(用旧密钥解密再用新密钥加密)。

(d) 将新密钥加密后的客户口令存储到新系统数据库内的客户信息表内。

若新系统采用客户口令不可逆存储的方案,则建议采用下列的步骤:

WORD完美格式

(a) 将原有旧系统的客户口令加密密钥,汇入/输入加密机内。

(b) 开发一个程序,将原有旧系统的所有客户口令利用加密机解密并产生口令数字(用旧密钥解密再用不可逆运算产生口令数字)。

(c) 将客户口令数字存储到新系统数据库内的客户信息表内。

..整理分享..

WORD完美格式

7.

安全管理

安全管理包含两个部分,分别是密钥管理及防病毒管理,分别於下列章节中说明。 7.1.

密钥管理方案

密钥管理方案影响整个系统的安全作业,华夏银行必须订定相关密钥管理策略,由安全设备厂商依照华夏的密钥管理策略,实施密钥的安全管理及运行。

7.1.1. 密钥生命周期管理方案

密钥区分为三种,分为本地主密钥、区域主密钥及数据密钥。此三种密钥的层次、级别和管理方法(遵循ANSI X9.17标准),其密钥层次如下图:

三种密钥的层次图

 各种密钥在密钥层次中的作用

(1) 本地主密钥(Local Master Key)又称主机主密钥(Master Key),主要用来保护它下一级的区域主密钥(Zone Master Key)(银行主密钥(Bank Master Key)、终端主密钥(Terminal Master Key))。

当区域主密钥需要导出或保存到加密机以外时,通常需要用本地主密钥(或衍生的密钥对)加密区域主密钥。

..整理分享..

WORD完美格式

(2) 区域主密钥中主要有两种,一种是金卡中心与成员行之间的传输密钥(通常称为银行主密钥),另一种是成员行主机与ATM或POS之间的传输密钥(通常称为终端主密钥)。它主要用来加密下一层次的数据密钥(如:PIK、MAK)。

(3) 数据加密密钥(Date Encrypt Key)又称工作密钥(Working Key),是最终用于加密传输数据的密钥,其上层两种密钥可以称为密钥加密/交换密钥(Key

Encrypt/Exchange Key,简称KEK)。数据密钥一般分为两种,一种是用来加密PIN的密钥称为PIK(Pin Key),另一种是用来计算MAC的密钥称为MAK(Mac Key)。

1. 密钥产生

(1) 本地主密钥通常由各成员行(或下属机构)采用加密机前面板上的键盘或直接通过IC卡注入到加密机中,各成员行的本地主密钥各不相同。一般本地主密钥的注入都由成员行的三位高层领导注入,三人分别保存一部分密钥(密钥分量,

Component),三部分密钥可以在加密机中以一定的算法(异或)合成为最终的本地主密钥(或通过衍生(Derive)生成密钥对)。

(2) 区域主密钥(银行主密钥)一般由上级机构(金卡中心)产生并分发。上级机构(金卡中心)产生并保存下属机构(各成员行)的区域主密钥(银行主密钥),同时将密码分量的明文或IC卡的形式将区域主密钥(银行主密钥)下发给下属机构(各成员行)。

下属机构(成员行)将密钥分量注入到加密机内,如果区域主密钥(银行主密钥)是保存到本机构的主机数据库中,则将区域主密钥(银行主密钥)注入到加密机后,加密机显示本地主密钥加密的区域主密钥(银行主密钥)密文,由银行工作人员将其录入主机数据库。银行主密钥通常由两人注入,各自保存一部分。

区域主密钥中的终端主密钥由各成员行自己注入到加密机中,同时下装到ATM和POS中,由于各成员行的ATM和POS数量都较大,一般是所有ATM和POS共用一个终端主密钥或是一组ATM和POS共用一个终端主密钥。

(3) 数据密钥分为两种,一般不在加密机中保存。一种是金卡中心与成员行之间的数据密钥,一种是成员行主机与ATM或POS之间的数据密钥。

前一种数据密钥可以由金卡中心主动向下分发,也可以由成员行主动向上申请。数据密钥在传输过程中由金卡中心与成员行之间共享的银行主密钥加密,成员行接收到数据密钥后都需要验证其正确性后才会启用新的数据密钥。

后一种数据密钥每天由ATM或POS签到申请,由加密机随机产生,并由终端主密钥加密传送。

..整理分享..

WORD完美格式

金卡中心与成员行及其终端(ATM、POS)之间的密钥关系如下图:

金卡中心与成员行及其终端(ATM、POS)之间的密钥关系图

上图中各个符号的含义如下:

1. BMK:银行主密钥 2. TMK:终端主密钥

3. PIK1:金卡中心与成员行之间的PIK 4. MAK1:金卡中心与成员行之间的MAK

5. PIK2:成员行与终端(ATM、POS)之间的PIK 6. MAK2:成员行与终端(ATM、POS)之间的MAK 7. DATA:传输的数据

8. (PIK1)BMK:被BMK加密的PIK1

说明:

 本地主密钥

LMK:Local Master Key,本地主密钥,又称为文件主密钥(MDS)、加密机主密钥、主机主密钥,在密钥体系中处于最上层,以明文存储在加密机中,加密保护存储在加密机外的其它密钥。LMK一般为双长度密钥,也有三倍长度密钥。

 区域主密钥

..整理分享..

WORD完美格式

ZMK:Zone Master Key,区域主密钥,在RACAL加密机中,指主机与主机间的传输主密钥。在密钥体系中处于中间层,可以通过LMK加密后存储在主机数据库中,也可直接存储在加密机中,一般为双长度,也有单长度和三倍长度密钥。用于主机间动态分发工作密钥时对其进行加密保护

BMK:Bank Master Key,银行主密钥,同ZMK,多用于金卡联网,在金卡联网中,有时POS和银行主机之间也使用BMK。

MMK:Member Master Key,成员行主密钥,同ZMK。多用于金卡联网 SMK:Shared Master Key,共享主密钥,同ZMK.

 数据加密密钥

TMK:Terminal Master Key,终端主密钥,在RACAL加密机中,指主机与终端ATM/POS间的传输主密钥,在密钥体系中处于中间层,可以通过LMK加密后存储在主机数据库中,也可直接存储在加密机中,现在一般为单长度,也有双长度和三倍长度。

PIK:PIn Key,PIN密钥,专用于加密保护PIN的工作密钥,在密钥体系中处于最下层,一般通过LMK和ZMK/TMK加密后存储在数据库中,也有直接存储在加密机中的,密钥长度有单长度、双倍长度和三倍长度。在MDS中,当采用动态密钥时,PIK每12小时或每2500笔交易就必须更换一次(两个条件满足任何一个时更换)

PEK:Pin Encrypt Key,PIN加密密钥,同PIK。

ZPK:Zone Pin Key,区域PIN密钥,PIK的一种,专指主机与主机间的PIK。 TPK:Terminal Pin Key,终端PIN密钥,PIK的一种,专指主机与终端间的PIK。

MAK:Mac Key,Mac密钥,专用于计算MAC的工作密钥,在密钥体系中处于最下层,一般通过LMK和ZMK/TMK加密后存储在数据库中,也有直接存储在加密机中的,密钥长度有单长度、双倍长度和三倍长度。在MDS中,当采用动态密钥时,PIK每12小时或每2500笔交易就必须更换一次(两个条件满足任何一个时更换)

DEK:Data Encrypt Key,数据加密密钥,专用于加密数据的密钥,在密钥体系中处于最下层,一般通过LMK和ZMK/TMK加密后存储在数据库中,也有直接存储在加密机中的,密钥长度有单长度、双倍长度和三倍长度。在MDS中,当采用动态密钥时,PIK每12小时或每2500笔交易就必须更换一次(两个条件满足任何一个时更换)

..整理分享..

WORD完美格式

为了保证密钥的安全分发,根据国际金融界惯例,银行新一代核心业务系统的密钥管理应遵循ANSI X9.17标准,采用三层密钥体系结构。其体系结构如图4所示。

核心业务系统的密钥体系结构图

在上图中,密钥由上自下逐级提供保护,其中,主机主密钥(Master Key,简称MK)和区域主密钥(ZMK:Zoom Master Key),属于密钥保护密钥。

第一级是主机主密钥(MK),它用来保护区域主密钥(ZMK)。

第二级是区域主密钥(ZMK),它用来保护总行和省分行之间的数据加密密钥;在第二级,还可以引入终端主密钥(Terminal Master Key,简称TMK),用来保护本中心管理的终端设备(如POS或ATM等)的数据加密密钥。

第三级为数据加密密钥DTK,也称工作密钥WK,用来对数据进行加密。

..整理分享..

WORD完美格式

2. 密钥存储

(1) 总行密钥存放方式

总行的加密机中存放有自身主密钥MK、各分行区域主密钥(包括总行大前置区域主密钥)ZMK,以及PIN加密存储在主机数据库中的PIN保存密钥。

(2) 综合前置密钥存放方式

总行大前置的加密机中存放有自身主密钥MK、与总行之间的ZMK、与分行大前置之间的ZMK、下属所有终端主密钥TMK,以及与外部机构(如中国银联)进行信息交换所需的密钥。

(3) 分行密钥存放方式

分行加密机中存放有自身主密钥MK、与总行之间的ZMK、与总行大前置之间的ZMK、下属所有终端主密钥TMK,以及与外部机构(如中国银联)进行信息交换所需的密钥。

前端硬件加密设备中存放有终端与前置间PINKEY 、MACKEY 以及PINKEY、MACKEY更换过程中的保护密钥。

总行以及所有分行配置的加密机都有独立的主机主密钥(MK),MK以明文形式存放在硬件加密机中,用来加密ZMK和TMK等第二层的密钥,MK本身不能以任何形式输出到加密机以外。MK一般由本地决定其生存周期。

总行与各分行、总行大前置与各分行之间各共享一个区域主密钥(ZMK),ZMK既可以以密文形式(通过本地MK加密保护)保存在本地的主机数据库中,也可以以明文形式保存在本地的硬件加密机中。以确保ZMK不会在硬件加密机之外的地方出现明文。ZMK用来保护数据加密密钥DTK,保证各分行与总行之间、各分行与总行大前置之间进行数据交换时安全地分发数据密钥,不同分行与总行、不同分行与总行大前置之间的区域主密钥(ZMK)各不相同。ZMK的生存周期相对较长,在使用一段时间后可通过人工方式更新。

在全行所有的自助终端都有各自独立的终端主密钥(TMK),尤其是ATM柜员机,按照外卡国际组织的要求,所有的ATM机都必须有独立的终端主密钥,TMK既可以以密文形式保存在本地的主机数据库中,也可以明文形式保存在本地的硬件加密机中。TMK用来保证终端设备(ATM/POS)与其直连的管理机构(分行/支行)之间安全地分发数据加密密钥DTK或工作密钥WK,TMK一般由本地决定其生存周期。

DTK由硬件加密机随机产生,主要有用于对PIN提供加密保护的PinKey和MAC数据生成/验证的MacKey,DTK可以采用一次一密的方式进行分发(通过TMK保护),

..整理分享..

WORD完美格式

即一个DTK只参与一次交易,也可以通过一定量的交易笔数(如2000笔)或一定的时间间隔周期(如2小时)后更新。

(4) 应用系统需开发的功能

在整个应用系统中,加密机除了自身提供主机主密钥MK以及区域主密钥ZMK输入外,对应用系统来讲主要是提供经主密钥(包括主机主密钥、区域主密钥以及终端主密钥)加密函数接口,用于将加密后的密文保存在本地主机中。涉及的主要函数有:

..整理分享..

➢ 经主机主密钥MK加密区域主密钥ZMK后,将密文保存在本地主机中; ➢ 经主机主密钥MK加密终端主密钥TMK后,将密文保存在本地主机中; ➢ 经区域主密钥ZMK加密工作密钥WK后,将密文保存在本地主机中; ➢ 经终端主密钥TMK加密工作密钥WK后,将密文保存在本地主机中; ➢ 保存经过ZMK加密的工作密钥PinKey和MacKey; ➢ 保存经过TMK加密的工作密钥PinKey和MacKey; ➢ 在ATM/POS终端上存储PinKey以及MacKey;

➢ H、主密钥的产生,如ZMK和TMK,并且通过加密机提供的串口,连接串口打印机直接打印成密码黑信封;

➢ 按照指定要求产生工作密钥,如PinKey和MacKey。

➢ 以上主要是加密机向应用系统提供的有关密钥保存的函数接口,也即是应用系统所需要开发的功能。 WORD完美格式

3. 密钥发布和同步

(1) 密钥发布和同步

总行及各分行的主机主密钥MK各地自行产生并保存在加密机中,全行不采用相同的MK,主要是为了降低整个系统的风险,如果全行采用一个相同的主机主密钥,一旦某个地方的主机主密钥发生泄露,则整个系统的主机主密钥都要全部重新更换,代价太大。

区域主密钥ZMK一般由上级机构产生,并通过人工方式分发,并保存在本地加密机中,如总行有各个分行的ZMK,各个分行只有自己的ZMK,主要用于加密分发工作密钥PinKey和MacKey。

终端主密钥TMK一般由分行自行产生,分行保存有所管辖的所有ATM/POS的终端主密钥,各个终端仅由自己的终端主密钥,主要用于分发和保存工作密钥PinKey和MacKey。

工作密钥WK(PinKey和MacKey)全部通过相邻上级机构产生并分发,主要用于对交易数据提供加密保护和交易数据完整性保护。

(2) 应用系统需开发的功能

加密机提供了所有相关的密钥函数接口,应用系统仅需调用加密机的接口就可以实现密钥同步的功能。涉及到的主要函数只有两大类,即密钥的产生以及密钥存储。

密钥产生主要有终端主密钥的产生、工作密钥PinKey和MacKey的产生; 密钥存储主要有终端主密钥的存储、工作密钥PinKey和MacKey的存储。

4. 密钥注销

密钥注销主要是通过产生新的密钥来取代旧的密钥,同时将新的密钥通过密钥传输流程,传送到相关往来机构及加密服务器,验证后,依照约定的日期/时间启用新的密钥。

数据密钥在传输过程中由金卡中心与成员行之间共享的银行主密钥加密,成员行接收到数据密钥后都需要验证其正确性后才会启用新的数据密钥。

成员行主机与ATM或POS之间的数据密钥,每天由ATM或POS签到申请,由加密机随机产生,并由终端主密钥加密传送。

5. 密钥备份

..整理分享..

WORD完美格式

本地主密钥在注入加密机时通过IC卡进行备份,当加密机密钥丢失时可用IC卡来恢复。

区域主密钥中的银行主密钥及终端主密钥,也可通过IC卡进行备份,当密钥丢失时可用IC卡来恢复。

..整理分享..

WORD完美格式

7.1.2. 密钥更换管理方案

(1) 服务器密钥同步

密钥同步是指服务器间共用的密钥(尤其是同步型密钥)如何有效而且安全的交换。一般来说,可以使用密钥同步信息交换的方式进行密钥交换。以BANCS与BANCS Link间的共用密钥(口令加密密钥)的更换同步为例,做法如下:

(a) 首先产生区域主密钥,并存储于密钥IC卡内。

(b) 再将密钥IC卡内的区域主密钥分别汇入BANCS系统的加密机以及BANCS Link系统的加密机内,作为密钥交换时交换密钥的加密密钥。

(c) 由BANCS系统定时产生新的共用密钥(服务器间信息应用加密的密钥),并发送密钥更换通知信息给BANCS Link系统。此信息中存放以区域主密钥加密过的共用密钥。

(d) BANCS Link系统收到密钥更换通知信息后,将信息内的共用密钥以加密机内的区域主密钥解开,并同时存储与加密机内。再发回密钥更换确认信息给BANCS系统。

(e) BANCS系统收到密钥更换确认信息后,确认双方密钥更换同步完成,即可开始使用新的共用密钥加密。

(2) 加密存储数据移转方案

..整理分享..

WORD完美格式

当用户加密存储于数据库内敏感性数据的密钥需要变更时,除了变更密钥外,尚必须对数据库内的密钥加以转换,才能维持数据库内的加密数据的可读性。一般做法如下:

(a) 首先在加密机内产生新的密钥。

(b) 利用密钥更换移转程序,将数据库内的加密数据以旧的加密密钥解开,再以新的加密密钥加密。此解密再加密的动作,必须在加密机上一次完成。 (c) 将新密钥加密后的加密数据更新到数据库中。

(d) 确认完成所有加密数据的移转后,将加密机内的旧密钥删除。

..整理分享..

WORD完美格式

7.2.

防病毒管理

网络发达的便利性,数据传输已无国界与时间的分别;拜网络迅速的便利,病毒的传播非常迅速,非常容易因为文档交换或收发邮件而感染病毒,造成重大的损害,防病毒管理变为安全上的重要环节。

7.2.1. 病毒传播路径

应用服务器、分行服务器、柜员终端机及笔记本等电脑设备的微软Windows操作系统经常因收送邮件、交换/复印文档、上网查询或上未知的网站,导致被病毒感染硬盘,破坏文档数据,传播病毒到其他人的电脑,造成重大损害;病毒感染造成的破坏,对金融机构的影响深远,对银行及客户的损害可能无法估计。

7.2.2. 防堵病毒传播方法

为了防止病毒的感染及传播,必须对病毒的传播方式与路径进行防堵,减少感染病毒的机会;柜员终端机及笔记本电脑是最容易被病毒感染及传播病毒的设备,主要是上网及交换/复印文档造成;为了防堵最容易感染病毒的设备,建议对柜员终端机及笔记本电脑的防堵病毒方法如下:

1. 柜员终端机

 柜员终端机不配置硬盘及操作系统,柜员终端机共用分行服务器的营盘及操作系

 U盘、光盘及USB埠设定成无法使用(Disable)  改造操作系统,设定无法连接外部网络(上网)  设定无法使用无线上网  只能收发内部邮件

2. 笔记本电脑

 办公室内设定为无法连接外部网络(上网)  办公室内设定为无法使用无线上网  办公室内只能收发内部邮件

3. 分行服务器

 网段设定与外部隔离

..整理分享..

WORD完美格式

7.2.3. 防治病毒的解决方案

为了减少因病毒所带来的风险及损害,建议华夏银行建设企业级的安全防护中心;安全防护中心主要的任务为:

 防范病毒入侵及病毒感染与扩散  防堵/隔离垃圾邮件造成系统瘫痪  侦测/扫描邮件病毒

 建设企业防病毒管理中心,即时线上扫毒/隔离/清除病毒  强制安装扫毒套件於用户电脑,定时/定期自动启动扫毒  线上病毒定义裆即时更新/解毒

 强制/自动更新病毒定义裆(签入系统时)

目前市场上有多家厂商提供企业级的安全防护中心服务,主要功能为:

流程 解决方案 监控 解决方案 ➢ 实时检测已知和未知的威胁 ➢ 启发式检测: ➢ 识别威胁来源 保护单个用户免受未知的威胁 ➢ 准确实时的检测: 准确并实时检测潜在威胁 精确的确认出未知威胁的确切来源 ➢ 主动的检测威胁: 远程控制企业威胁,24x7持续运转 强制 网络病毒墙 ➢ 网络准入控制设备 ✓ 安全策略强制执行 ➢ 网络准入控制框架 支持预定义128条安全策略 可针对设定条件定义安全策略的检查内容 支持超过20种品牌的防毒软件安装,更新情况进行检查和管理 支持对网络接入设备的补丁程序安装情况进行检查和管理 ✓ 风险隔离以及自动修复 对违反安全策略的设备,隔离至预定义的VLAN中 对发现恶意代码和间谍软件设备,自动分发工具和启动修复操作 当设备可以满足安全策略的要求时,允许其正常接入网络 ..整理分享..

WORD完美格式

流程 解决方案 ✓ 网络蠕虫防护 在网络层分析数据包,阻止网络蠕虫(Worm)和僵尸(Bot)的传播 防护 ➢ 针对应用层的科技安全体系 ✓ 桌面防护,服务器防护,网关防护,存储安 全等 ➢ 保护网络 ✓ 集成的网络安全策略 1. 通过HTTP和FTP的扫描,来阻止间谍软 件和灰色软件的下载 2. 拦截对恶意间谍软件网站的访问,防止 把数据发送给已知的和网络钓鱼相关的 网站 3. 封堵间谍软件的”Phone-home”企 图,提供损害清除服务,对含有间谍软 件的客户端和服务器进行主动清除 4. 可以验证ActiveX和Java小程序的数 字认证/签名,并对其进行深层次的威胁 分析,避免潜在的风险 ➢ 易於管理和部署 ✓ 支持SNMP,LDAP以及Active Directory,实现与企业现有系统更紧密的集成,降低总体拥有成本 恢复 ✓ ➢ 损害清除服务 ✓ 客户端自动修复 ✓ 针对Windows系统的远程调用 ➢ 在线扫毒服务器版 ✓ 按需保护,无需预先安装 ✓ 支持Windows, Linux, 和Solaris

透过建设企业级的安全防护中心来时时侦测线上对内部及外部的安全威胁,从避免病毒/垃圾邮件入侵到主动防治病毒/垃圾邮件,建立整体的安全防护机制,来解决对华夏银行及客户的损害,降低风险(冲击)及影响。

..整理分享..

WORD完美格式

8.

推荐方案

本章针对上述各章提出的方案说明,分析其优劣点,进一步提出建议实施的方案。

8.1. 身份验证方案建议 8.1.1. 建议方案的优/缺点分析

针对第3章所提的动态口令、USB-Key两种身份验证方式的比较如下: 安全需求 动态口令 USB-Key 私密/真实性 符合 符合 完整/唯一性 符合 符合 机密性/身份确认 符合 符合 不可否認/不可抵赖性 不符合 符合 网络传输的安全需求 符合(外加 VPN/SSL) 符合(外加 VPN/SSL) 数字签名 一般的动态口令无法使用于USB-Key可扩充加载数字证书,提交易数据的签名 供重要交易的数字签名功能 安全扩展性 无法随着安全等级提升的要可随安全上的要求,扩展应用范求扩展 围,包含数字证书的扩充 安全等级 安全级别较低 采用双因素强验证 (包含USB-Key以及USB-Key的开启口令),安全级别较高 方便性 使用方便。用户只需使用动用户终端设备上需提供USB接口态口令盘在每次登入时产生(采用USB-Key)或是IC读卡机(采口令即可 用IC卡),并须安装控制 随时验证 由于动态口令盘大多是采用USB-Key与终端设备采用连线方离线作业方式,因此无法以式,可随时验证用户是否离席 连线侦测方式,侦测用户是否离席 开发建置 可采用市场上的成熟产品快市场上无统一标准的产品,需要开速建置 发建置 应用系统修改/整合性 应用系统只需于登入时调用应用系统登入界面需要修改,配合动态口令系统提供的接口,身份验证;更动较大。 修改整合容易。 扩展性 扩展性较差 可随安全上的要求,扩展应用范围 成本 产品成本较高 产品成本较低 与其它应用系统扩展 无法与其他应用系统整合 USB-Key可采用双芯片(有线与无..整理分享..

WORD完美格式

安全需求 动态口令 更新/年费 无 针对第3章所提的单一入口服务系统(Portal)、独立身份验证服务器两种身份验证系统架构的比较如下: 安全需求 单一入口服务系统 独立身份验证服务器 系统完整性 考虑完整的统一系统入口,较只考虑登入的身份验证统一为完整 性,未完整考量入口的统一性 系统扩展性 可扩展至其他符合单一入口标仅就身份验证的统一性具有扩准的应用系统 展性 应用系统配合性 应用系统必须遵循单一入口标现有应用系统只需修改用户登准,对现有系统的改造修改极入的验证程序,修改幅度相对大 较小 建置成本 必须针对针体系统的架构进行只有建置身份验证服务器与现改造,成本相当高 有系统的少量修改,成本较低 8.1.2. 建议实施方案

USB-Key 线)设计,与门禁系统结合 无 1. 推荐方案 项目 身分验证方式 网络交易安全 身分验证架构 建议方案 USB-Key(+数字证书(Certificate)) 动态口令 独立身份验证服务器 2. 身分验证方式

从安全等级及未来应用扩充性,USB-Key方案是比较好的选择。从时间及方便性,动态口令方案是比较快速建设需求的选择。

从金融机构的长远发展性、环境快速变化因素、安全性挑战越来越高及业务需求变化越来越复杂的几个方向来考虑,建议采用USB-Key解决方案,尤其USB-Key解决方案可加载数字证书(Certificate)提供重要交易的数字签名功能,并能与其他应用结合。考虑网络交易的便利性要求,建议有关网络业务交易使用者的交易安全采用动态口令解决方案。

上述的建议是将安全方案分为对内与对外两种;对内部采用USB-Key解决方案应用於业务系统交易安全处理,对外部采用动态口令解决方案应用於网络交易的使用者安全处理。

..整理分享..

WORD完美格式

3. 身分验证架构

对于身份验证的系统架构方案建议上,基于目前的应用环境的复杂,以及实施时间与成本考量,建议采用独立身份验证服务器的方案。

..整理分享..

WORD完美格式

8.2.

授权控制方案建议

8.2.1. 建议方案的优/缺点分析

针对第4章所提的授权控制方案的比较如下: 安全需求 各个系统各自授权控制方案 系统完整性 各自零散处理 系统扩展性 各自处理,无规则可循,无法扩展 应用系统配合性 应用系统各自处理 建置成本 无法估计 整体性的授权控制方案 完整性的解决方案 一套完整的授权控制管理,未来有系统扩充弹性 有一套完整的规则,应用系统配合杏佳 统一的规则与流程,各个系统的建置成本低 针对第4章所提的SSO系统架构、独立授权服务器架构的比较如下: 安全需求 SSO系统架构 独立授权服务器架构 方便性 方便/简化系统授权管理 只能简化一部分系统授权管理 未来性 单一/统一的授权管理方式,对对未来新增业务系统或新增业未来新增业务系统或新增业务务交易处理,各个业务系统的交易处理,依循此标准授权方改动量较大 式,建设非常方便/迅速 简化流程 简化系统的交易处理流程 无法简化系统的交易处理流程 复杂性 初期系统建置非常复杂,相关初期系统建置复杂性小,相关系统必需配合更改交易登入及应用系统更改幅度较小 交易授权 建置成本 建置成本较高 建置成本较低 8.2.2. 建议实施方案

1. 推荐方案 项目 授权控制方案 授权架构 2. 说明

建议方案 整体性的授权控制方案 独立授权服务器架构 ..整理分享..

WORD完美格式

考量现实的状态及未来的发展性,建议建设一套独立授权服务器,同时於此服务器上建设一套整体性的授全控制管理流程;於此推荐方案下,各个系统必需放弃原有的授权控制管理。

..整理分享..

WORD完美格式

8.3.

传输安全方案建议

8.3.1. 建议方案的优/缺点分析

针对第5章所提得传输安全方案的建议如下: 安全需求 建议方案 网络传输安全 每个路由器前,皆采用链路加密机 应用安全 核心系统、综合前置系统及分行服务器三个系统采用应用加密机;外围系统不考虑 应用系统配合 核心系统、综合前置系统及分行柜面系统需配合更改应用系统 针对第5章所提的IP验证法、信息押码验证法的比较如下: 安全需求 IP验证法 信息押码验证法 方便性 不须改变交易信息的格式与交易次种方法必须变更交易信息格式,流程,透过交易信息收发的网络增加验证码字段 层信息即可取得验证数据 IP 每一个服务器在网络层必须有固此种验证方式,可使用於任何的网定的IP,对于使用VPN或是虚络环境 拟IP交换器的网络并不适用 IP更改 当服务器因为网络位置变更,而不锁定服务器的网络地址与实体位更改IP 时,必须更该其他应用系置,服务器的网络位置变更不影响统上的IP设置 任何设置 安全性 只用IP的验证方法在安全上比较较高的安全强度,必须有存取密钥薄弱。有可能假服务器暂时取代的权限才能产生验证码 合法服务器的IP而不会被察觉 应用系统修改 应用系统不需要修改 应用系统配合修改的幅度较大 成本 建置成本较高 此种方法必须配合加密机使用,成本较高 8.3.2. 建议实施方案

1. 推荐方案 项目 网络传输安全方案 应用安全方案 建议方案 支行/分行/总行及服务器间,皆采用链路加密机 新核心系统、综合前置系统及分行服务器三个系统,采用应用加密机;外围系统不建议采用 ..整理分享..

WORD完美格式

服务器间验证方案 信息押码验证法 ..整理分享..

WORD完美格式

8.4.

存储安全方案建议

8.4.1. 建议方案的优/缺点分析

针对第6章所提得存储安全方案的建议如下: 安全需求 建议方案 敏感性数据加密 3DES密钥加密处理,必要时对关键字段以MAC生成校验值 客户密码 由应用(硬件)加密机加密,储存於数据库; 验证由应用(硬件)加密机验证 应用系统配合 核心系统、综合前置系统及分行柜面系统需配合更改应用系统 用户登入密码 内部采用USB-Key登入密码; 外部采用动态口令登入密码 针对第6章所提的客户口令加密存储方案、客户口令不可逆存储方案的比较如下: 安全需求 客户口令加密存储方案 客户口令不可逆存储方案 密码泄漏/还原 加密强度较强,不易泄漏 理论上无法利用口令数字还原正确的口令 密钥更换 加密密钥更换时,必须重行加密不需使用密钥,维护上比较简单,所有的口令,处理费时繁复 依不需考虑密钥变更的问题 口令遗失风险 如果加密密钥遗失,所有的客户不使用密钥,除数据库数据遗失口令皆失效,必须请客户从新设外,没有遗失风险 置,可能造成重大损失 8.4.2. 建议实施方案

1. 推荐方案 项目 敏感性数据加密 客户密码 用户登入密码 客户口令密码存储 建议方案 3DES密钥加密处理,必要时对关键字段以MAC生成校验值 由应用(硬件)加密机加密,储存於数据库; 验证由应用(硬件)加密机验证 内部采用USB-Key登入密码; 外部采用动态口令登入密码 客户口令不可逆存储方案 ..整理分享..

WORD完美格式

附件一:第二级信息系统安全等级

安全事项 第二级信息系统应实现的目标 1.技术目标 O2-1. 应具有抵抗一般强度地震、台风等自然灾难造成破坏的能力 O2-2. 应具有防止雷击事件导致重要设备被破坏的能力 O2-3. 应具有防水和防潮的能力 O2-4. 应具有灭火的能力 O2-5. 应具有检测火灾和报警的能力 O2-6. 应具有温湿度自动检测和控制的能力 O2-7. 应具有防止电压波动的能力 O2-8. 应具有对抗短时间断电的能力 O2-9. 应具有防止静电导致重要设备被破坏的能力 O2-10. 具有基本的抗电磁干扰能力 O2-11. 应具有对传输和存储数据进行完整性检测的能力 O2-12. 应具有对硬件故障产品进行替换的能力 O2-13. 应具有系统软件、应用软件容错的能力 O2-14. 应具有软件故障分析的能力 O2-15. 应具有合理使用和控制系统资源的能力 O2-16. 应具有记录用户操作行为的能力 O2-17. 应具有对用户的误操作行为进行检测和报警的能力 O2-18. 应具有控制机房进出的能力 O2-19. 应具有防止设备、介质等丢失的能力 O2-20. 应具有控制机房内人员活动的能力 O2-21. 应具有控制接触重要设备、介质的能力 O2-22. 应具有对传输和存储中的信息进行保密性保护的能力 O2-23. 应具有对通信线路进行物理保护的能力 O2-24. 应具有限制网络、操作系统和应用系统资源使用的能力 O2-25. 应具有能够检测对网络的各种攻击并记录其活动的能力 O2-26. 应具有发现所有已知漏洞并及时修补的能力 O2-27. 应具有对网络、系统和应用的访问进行控制的能力 O2-28. 应具有对数据、文件或其他资源的访问进行控制..整理分享..

符合 备注 是 是 是 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 安全硬/软件实施 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 华夏机房管理办法 华夏机房管理办法 华夏机房管理办法 华夏机房管理办法 安全硬/软件实施 华夏机房管理办法 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 应用软件负责应用 主机厂商提供数据 WORD完美格式

安全事项 的能力 O2-29. 应具有对资源访问的行为进行记录的能力 O2-30. 应具有对用户进行唯一标识的能力 O2-31. 应具有对用户产生复杂鉴别信息并进行鉴别的能力 O2-32. 应具有对恶意代码的检测、阻止和清除能力 O2-33. 应具有防止恶意代码在网络中扩散的能力 O2-34. 应具有对恶意代码库和搜索引擎及时更新的能力 O2-35. 应具有保证鉴别数据传输和存储保密性的能力 O2-36. 应具有对存储介质中的残余信息进行删除的能力 O2-37. 应具有非活动状态一段时间后自动切断连接的能力 O2-38. 应具有网络边界完整性检测能力 O2-39. 应具有重要数据恢复的能力 2.管理目标 O2-40. 应确保建立了安全职能部门,配备了安全管理人员,支持信息安全管理工作 O2-41. 应确保配备了足够数量的管理人员,对系统进行运行维护 O2-42. 应确保对主要的管理活动进行了制度化管理 O2-43. 应确保建立并不断完善、健全安全管理制度 O2-44. 应确保能协调信息安全工作在各功能部门的实施 O2-45. 应确保能控制信息安全相关事件的授权与审批 O2-46. 应确保建立恰当可靠的联络渠道,以便安全事件发生时能得到支持 O2-47. 应确保对人员的行为进行控制 O2-48. 应确保对人员的管理活动进行了指导 O2-49. 应确保安全策略的正确性和安全措施的合理性 O2-50. 应确保对信息系统进行合理定级 O2-51. 应确保安全产品的可信度和产品质量 O2-52. 应确保自行开发过程和工程实施过程中的安全 O2-53. 应确保能顺利地接管和维护信息系统 O2-54. 应确保安全工程的实施质量和安全功能的准确实现 O2-55. 应确保机房具有良好的运行环境 O2-56. 应确保对信息资产进行标识管理 O2-57. 应确保对各种软硬件设备的选型、采购、发放、使用和保管等过程进行控制 O2-58. 应确保各种网络设备、服务器正确使用和维护 ..整理分享..

符合 是 备注 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 安全硬/软件实施 主机厂商提供数据 主机厂商提供数据 网络硬/软件功能 数据库软件功能 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 WORD完美格式

安全事项 O2-59. 应确保对网络、操作系统、数据库管理系统和应用系统进行安全管理 O2-60. 应确保用户具有鉴别信息使用的安全意识 O2-61. 应确保定期地对通信线路进行检查和维护 O2-62. 应确保硬件设备、存储介质存放环境安全,并对其的使用进行控制和保护 O2-63. 应确保对支撑设施、硬件设备、存储介质进行日常维护和管理 O2-64. 应确保系统中使用的硬件、软件产品的质量 O2-65. 应确保各类人员具有与其岗位相适应的技术能力 O2-66. 应确保对各类人员进行相关的技术培训 O2-67. 应确保提供的足够的使用手册、维护指南等资料 O2-68. 应确保内部人员具有安全方面的常识和意识 O2-69. 应确保具有设计合理、安全网络结构的能力 O2-70. 应确保密码算法和密钥的使用符合国家有关法律、法规的规定 O2-71. 应确保任何变更控制和设备重用要申报和审批,并对其实行制度化的管理 O2-72. 应确保在事件发生后能采取积极、有效的应急策略和措施 O2-73. 应确保信息安全事件实行分等级响应、处置 2. 第二级技术要求的物理安全 安全事项 1.主机系统安全 1.身份鉴别(S2) a) 操作系统和数据库系统用户的身份标识应具有唯一性; b) 应对登录操作系统和数据库系统的用户进行身份标识和鉴别; c) 操作系统和数据库系统身份鉴别信息应具有不易被冒用的特点,例如口令长度、复杂性和定期的更新等; d) 应具有登录失败处理功能,如:结束会话、限制非法登录次数,当登录连接超时,自动退出。 2. 自主访问控制(S2) a) 应依据安全策略控制主体对客体的访问; b) 自主访问控制的覆盖范围应包括与信息安全直接相关的主体、客体及它们之间的操作; c) 自主访问控制的粒度应达到主体为用户级,客体为文..整理分享..

符合 备注 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 符合 备注 主机厂商提供数据 WORD完美格式

安全事项 件、数据库表级; d) 应由授权主体设置对客体访问和操作的权限; e) 应严格限制默认用户的访问权限。 3. 安全审计(G2) a) 安全审计应覆盖到服务器上的每个操作系统用户和数据库用户; b) 安全审计应记录系统内重要的安全相关事件,包括重要用户行为和重要系统命令的使用等; c) 安全相关事件的记录应包括日期和时间、类型、主体标识、客体标识、事件的结果等; d) 审计记录应受到保护避免受到未预期的删除、修改或覆盖等。 2.应用安全 1. 身份鉴别(S2) a) 应用系统用户的身份标识应具有唯一性; b) 应对登录的用户进行身份标识和鉴别; c) 系统用户身份鉴别信息应具有不易被冒用的特点,例如口令长度、复杂性和定期的更新等; d) 应具有登录失败处理功能,如:结束会话、限制非法登录次数,当登录连接超时,自动退出。 2. 访问控制(S2) a) 应依据安全策略控制用户对客体的访问; b) 自主访问控制的覆盖范围应包括与信息安全直接相关的主体、客体及它们之间的操作; c) 自主访问控制的粒度应达到主体为用户级,客体为文件、数据库表级; d) 应由授权主体设置用户对系统功能操作和对数据访问的权限; e) 应实现应用系统特权用户的权限分离,例如将管理与审计的权限分配给不同的应用系统用户; f) 权限分离应采用最小授权原则,分别授予不同用户各自为完成自己承担任务所需的最小权限,并在它们之间形成相互制约的关系; g) 应严格限制默认用户的访问权限。 3. 安全审计(G2) a) 安全审计应覆盖到应用系统的每个用户; b) 安全审计应记录应用系统重要的安全相关事件,包括重要用户行为和重要系统功能的执行等; c) 安全相关事件的记录应包括日期和时间、类型、主体标识、客体标识、事件的结果等; ..整理分享..

符合 备注 是 是 是 请详如3.身份验证 请详如4.授权控制 核心系统产品的内部审计功能 WORD完美格式

安全事项 d) 审计记录应受到保护避免受到未预期的删除、修改或覆盖等。 4. 剩余信息保护(S2) a) 应保证用户的鉴别信息所在的存储空间,被释放或再分配给其他用户前得到完全清除,无论这些信息是存放在硬盘上还是在内存中; b) 应确保系统内的文件、目录和数据库记录等资源所在的存储空间,被释放或重新分配给其他用户前得到完全清除。 5. 通信完整性(S2) a) 通信双方应约定单向的校验码算法,计算通信数据报文的校验码,在进行通信时,双方根据校验码判断对方报文的有效性。 6. 通信保密性(S2) a) 当通信双方中的一方在一段时间内未作任何响应,另一方应能够自动结束会话; b) 在通信双方建立连接之前,利用密码技术进行会话初始化验证; c) 在通信过程中,应对敏感信息字段进行加密。 3. 数据安全 1. 数据完整性(S2) a) 应能够检测到系统管理数据、鉴别信息和用户数据在传输过程中完整性受到破坏; b) 应能够检测到系统管理数据、鉴别信息和用户数据在存储过程中完整性受到破坏。 2. 数据保密性(S2) a) 网络设备、操作系统、数据库系统和应用系统的鉴别信息、敏感的系统管理数据和敏感的用户数据应采用加密或其他有效措施实现传输保密性; b) 网络设备、操作系统、数据库系统和应用系统的鉴别信息、敏感的系统管理数据和敏感的用户数据应采用加密或其他保护措施实现存储保密性; c) 当使用便携式和移动式设备时,应加密或者采用可移动磁盘存储敏感信息。 3. 数据备份和恢复(A2) a) 应提供自动机制对重要信息进行有选择的数据备份; b) 应提供恢复重要信息的功能; c) 应提供重要网络设备、通信线路和服务器的硬件冗余。 ..整理分享..

符合 是 是 是 是 是 是 是 是 备注 核心系统产品的内部审计功能 请详如5.2.2交易数据完整性 主机系统 请详如5.2.4服务器间验证 请详如5.2.1交易敏感性数据加密 请详如5.2.2交易数据完整性 请详如5.1网络安全及5.2.1交易敏感性数据加密 请详如OSA的IT架构规划 WORD完美格式

..整理分享..

WORD完美格式

..整理分享..

WORD完美格式

附件二:第三级信息系统安全等级

安全事项 第三级信息系统应实现的目标 1.技术目标 O3-1. 应具有对抗中等强度地震、台风等自然灾难造成破坏的能力 O3-2. 应具有防止雷击事件导致大面积设备被破坏的能力 O3-3. 应具有防水和防潮的能力 O3-4. 应具有对水患检测和报警的能力 O3-5. 应具有自动灭火的能力 O3-6. 应具有检测火灾和报警的能力 O3-7. 应具有防止火灾蔓延的能力 O3-8. 应具有温湿度自动检测和控制的能力 O3-9. 应具有防止电压波动的能力 O3-10. 应具有对抗较长时间断电的能力 O3-11. 应具有防止静电导致大面积设备被破坏的能力 O3-12. 应具有对重要设备和介质进行电磁屏蔽的能力 O3-13. 应具有防止强电磁场、强震动源和强噪声源等污染影响系统正常运行的能力 O3-14. 应具有监测通信线路传输状况的能力 O3-15. 应具有及时恢复正常通信的能力 O3-16. 应具有对传输和存储数据进行完整性检测和纠错的能力 O3-17. 应具有系统软件、应用软件容错的能力 O3-18. 应具有软件故障分析的能力 O3-19. 应具有软件状态监测和报警的能力 O3-20. 应具有自动保护当前工作状态的能力 O3-21. 应具有合理使用和控制系统资源的能力 O3-22. 应具有按优先级自动分配系统资源的能力 O3-23. 应具有对软件缺陷进行检查的能力 O3-24. 应具有记录用户操作行为和分析记录结果的能力 O3-25. 应具有对用户的误操作行为进行检测、报警和恢复的能力 O3-26. 应具有严格控制机房进出的能力 O3-27. 应具有防止设备、介质等丢失的能力 O3-28. 应具有严格控制机房内人员活动的能力 O3-29. 应具有实时监控机房内部活动的能力 O3-30. 应具有对物理入侵事件进行报警的能力 ..整理分享..

符合 备注 是 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 安全硬/软件实施 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 华夏机房管理办法 华夏机房管理办法 华夏机房管理办法 华夏机房管理办法 华夏机房管理办法 WORD完美格式

安全事项 O3-31. 应具有控制接触重要设备、介质的能力 O3-32. 应具有对通信线路进行物理保护的能力 O3-33. 应具有使重要通信线路及时恢复的能力 O3-34. 应具有限制网络、操作系统和应用系统资源使用的能力 O3-35. 应具有合理分配、控制网络、操作系统和应用系统资源的能力 O3-36. 应具有能够检测、分析、响应对网络和重要主机的各种攻击的能力 O3-37. 应具有发现所有已知漏洞并及时修补的能力 O3-38. 应具有对网络、系统和应用的访问进行严格控制的能力 O3-39. 应具有对数据、文件或其他资源的访问进行严格控制的能力 O3-40. 应具有对资源访问的行为进行记录、分析并响应的能力 O3-41. 应具有对恶意代码的检测、阻止和清除能力 O3-42. 应具有防止恶意代码等在网络中扩散的能力 O3-43. 应具有对恶意代码库和搜索引擎及时更新的能力 O3-44. 应具有保证鉴别数据传输和存储保密性的能力 O3-45. 应具有对用户进行唯一标识的能力 O3-46. 应具有对同一个用户产生多重鉴别信息并进行多重鉴别的能力 O3-47. 应具有对硬件设备进行唯一标识的能力 O3-48. 应具有对硬件设备进行合法身份确定的能力 O3-49. 应具有检测非法接入设备的能力 O3-50. 应具有对存储介质中的残余信息进行删除的能力 O3-51. 应具有对传输和存储中的信息进行保密性保护的能力 O3-52. 应具有防止加密数据被破解的能力 O3-53. 应具有路由选择和控制的能力 O3-54. 应具有信息源发的鉴别能力 O3-55. 应具有通信数据完整性检测和纠错能力 O3-56. 应具有对关键区域进行电磁屏蔽的能力 O3-57. 应具有持续非活动状态一段时间后自动切断连接的能力 O3-58. 应具有基于密码技术的抗抵赖能力 O3-59. 应具有防止未授权下载、拷贝软件或者文件的能力 ..整理分享..

符合 是 是 是 是 是 备注 华夏机房管理办法 华夏机房管理办法 华夏机房管理办法 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 应用软件负责应用 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 安全硬/软件实施 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 安全硬/软件实施 安全硬/软件实施 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 主机厂商提供数据 安全硬/软件实施 主机厂商提供数据 WORD完美格式

安全事项 O3-60. 应具有网络边界完整性检测能力 O3-61. 应具有切断非法连接的能力 O3-62. 应具有重要数据和程序进行完整性检测和纠错能力 O3-63. 应具有对敏感信息进行标识的能力 O3-64. 应具有对敏感信息的流向进行控制的能力 O3-65. 应具有及时恢复重要数据的能力 O3-66. 应具有保证重要业务系统及时恢复运行的能力 2.管理目标 O3-67. 应确保建立了安全职能部门,配备了安全管理人员,支持信息安全管理工作 O3-68. 应确保配备了足够数量的管理人员,对系统进行运行维护 O3-69. 应确保对管理活动进行了制度化管理 O3-70. 应确保建立并不断完善、健全安全管理制度 O3-71. 应确保能协调信息安全工作在各功能部门的实施 O3-72. 应确保能控制信息安全相关事件的授权与审批 O3-73. 应确保建立恰当可靠的联络渠道,以便安全事件发生时能得到支持 O3-74. 应确保对人员的行为进行控制和规范 O3-75. 应确保对人员的管理活动进行了指导 O3-76. 应确保安全策略的正确性和安全措施的合理性 O3-77. 应确保对信息系统进行合理定级,,并进行备案管理 O3-78. 应确保安全产品的可信度和产品质量 O3-79. 应确保自行开发过程和工程实施过程中的安全 O3-80. 应确保能顺利地接管和维护信息系统 O3-81. 应确保安全工程的实施质量和安全功能的准确实现 O3-82. 应确保机房具有良好的运行环境 O3-83. 应确保对信息资产进行分类标识管理 O3-84. 应确保对各种软硬件设备的选型、采购、发放、使用和保管等过程进行控制 O3-85. 应确保各种网络设备、服务器正确使用和维护 O3-86. 应确保对网络、操作系统、数据库系统和应用系统进行安全管理 O3-87. 应确保用户具有鉴别信息使用的安全意识 O3-88. 应确保定期地对通信线路进行检查和维护 O3-89. 应确保硬件设备、存储介质存放环境安全,并对..整理分享..

符合 是 备注 网络硬/软件功能 主机厂商提供数据 安全硬/软件实施 主机厂商提供数据 主机厂商提供数据 数据库软件功能 主机厂商提供数据 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 WORD完美格式

安全事项 其进行控制和保护 O3-90. 应确保对支撑设施、硬件设备、存储介质进行日常维护和管理 O3-91. 应确保系统中使用的硬件、软件产品的质量 O3-92. 应确保各类人员具有与其岗位相适应的技术能力 O3-93. 应确保对各类人员进行相关的技术培训 O3-94. 应确保提供的足够的使用手册、维护指南等资料 O3-95. 应确保内部人员具有安全方面的常识和意识 O3-96. 应确保具有设计合理、安全网络结构的能力 O3-97. 应确保对软硬件的分发过程进行控制 O3-98. 应确保软硬件中没有后门程序 O3-99. 应确保密码算法和密钥的使用符合国家有关法律、法规的规定 O3-100. 应确保任何变更控制和设备重用要申报和审批,并对其实行制度化的管理 O3-101. 应确保在事件发生后能采取积极、有效的应急策略和措施 O3-102. 应确保信息安全事件实行分等级响应、处置 3. 第三级技术要求的物理安全 安全事项 1.主机系统安全 1. 身份鉴别(S3) a) 操作系统和数据库系统用户的身份标识应具有唯一性; b) 应对登录操作系统和数据库系统的用户进行身份标识和鉴别; c) 应对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别; d) 操作系统和数据库系统用户的身份鉴别信息应具有不易被冒用的特点,例如口令长度、复杂性和定期的更新等; e) 应具有登录失败处理功能,如:结束会话、限制非法登录次数,当登录连接超时,自动退出; f) 应具有鉴别警示功能; g) 重要的主机系统应对与之相连的服务器或终端设备进行身份标识和鉴别。 2. 自主访问控制(S3) a) 应依据安全策略控制主体对客体的访问; ..整理分享..

符合 备注 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 华夏安全管理办法 符合 备注 主机厂商提供数据 WORD完美格式

安全事项 b) 自主访问控制的覆盖范围应包括与信息安全直接相关的主体、客体及它们之间的操作; c) 自主访问控制的粒度应达到主体为用户级,客体为文件、数据库表级; d) 应由授权主体设置对客体访问和操作的权限; e) 权限分离应采用最小授权原则,分别授予不同用户各自为完成自己承担任务所需的最小权限,并在他们之间形成相互制约的关系; f) 应实现操作系统和数据库系统特权用户的权限分离; g) 应严格限制默认用户的访问权限。 3. 强制访问控制(S3) a) 应对重要信息资源和访问重要信息资源的所有主体设置敏感标记; b) 强制访问控制的覆盖范围应包括与重要信息资源直接相关的所有主体、客体及它们之间的操作; c) 强制访问控制的粒度应达到主体为用户级,客体为文件、数据库表级。 4. 安全审计(G3) a) 安全审计应覆盖到服务器和客户端上的每个操作系统用户和数据库用户; b) 安全审计应记录系统内重要的安全相关事件,包括重要用户行为、系统资源的异常使用和重要系统命令的使用; c) 安全相关事件的记录应包括日期和时间、类型、主体标识、客体标识、事件的结果等; d) 安全审计应可以根据记录数据进行分析,并生成审计报表; e) 安全审计应可以对特定事件,提供指定方式的实时报警; f) 审计进程应受到保护避免受到未预期的中断; g) 审计记录应受到保护避免受到未预期的删除、修改或覆盖等。 5. 系统保护(G3) a) 系统因故障或其他原因中断后,应能够以手动或自动方式恢复运行。 6. 剩余信息保护(S3) a) 应保证操作系统和数据库管理系统用户的鉴别信息所在的存储空间,被释放或再分配给其他用户前得到完全清除,无论这些信息是存放在硬盘上还是在内存中; ..整理分享..

符合 备注 WORD完美格式

安全事项 b) 应确保系统内的文件、目录和数据库记录等资源所在的存储空间,被释放或重新分配给其他用户前得到完全清除。 7. 入侵防范(G3) a) 应进行主机运行监视,包括监视主机的CPU、硬盘、内存、网络等资源的使用情况; b) 应设定资源报警域值,以便在资源使用超过规定数值时发出报警; c) 应进行特定进程监控,限制操作人员运行非法进程; d) 应进行主机账户监控,限制对重要账户的添加和更改; e) 应检测各种已知的入侵行为,记录入侵的源IP、攻击的类型、攻击的目的、攻击的时间,并在发生严重入侵事件时提供报警; f) 应能够检测重要程序完整性受到破坏,并在检测到完整性错误时采取必要的恢复措施。 8. 恶意代码防范(G3) a) 服务器和终端设备(包括移动设备)均应安装实时检测和查杀恶意代码的软件产品; b) 主机系统防恶意代码产品应具有与网络防恶意代码产品不同的恶意代码库; c) 应支持恶意代码防范的统一管理。 9. 资源控制(A3) a) 应限制单个用户的多重并发会话; b) 应对最大并发会话连接数进行限制; c) 应对一个时间段内可能的并发会话连接数进行限制; d) 应通过设定终端接入方式、网络地址范围等条件限制终端登录; e) 应根据安全策略设置登录终端的操作超时锁定和鉴别失败锁定,并规定解锁或终止方式; f) 应禁止同一用户账号在同一时间内并发登录; g) 应限制单个用户对系统资源的最大或最小使用限度; h) 当系统的服务水平降低到预先规定的最小值时,应能检测和报警; i) 应根据安全策略设定主体的服务优先级,根据优先级分配系统资源,保证优先级低的主体处理能力不会影响到优先级高的主体的处理能力。 2.应用安全 1. 身份鉴别(S3) a) 系统用户的身份标识应具有唯一性; ..整理分享..

符合 备注 是 请详如3.身份验证 WORD完美格式

安全事项 b) 应对登录的用户进行身份标识和鉴别; c) 系统用户的身份鉴别信息应具有不易被冒用的特点,例如口令长度、复杂性和定期的更新等; d) 应对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别; e) 应具有登录失败处理功能,如:结束会话、限制非法登录次数,当登录连接超时,自动退出; f) 应具有鉴别警示功能; g) 应用系统应及时清除存储空间中动态使用的鉴别信息。 2. 访问控制(S3) a) 应依据安全策略控制用户对客体的访问; b) 自主访问控制的覆盖范围应包括与信息安全直接相关的主体、客体及它们之间的操作; c) 自主访问控制的粒度应达到主体为用户级,客体为文件、数据库表级; d) 应由授权主体设置用户对系统功能操作和对数据访问的权限; e) 应实现应用系统特权用户的权限分离,例如将管理与审计的权限分配给不同的应用系统用户; f) 权限分离应采用最小授权原则,分别授予不同用户各自为完成自己承担任务所需的最小权限,并在它们之间形成相互制约的关系; g) 应严格限制默认用户的访问权限。 3. 安全审计(G3) a) 安全审计应覆盖到应用系统的每个用户; b) 安全审计应记录应用系统重要的安全相关事件,包括重要用户行为、系统资源的异常使用和重要系统功能的执行等; c) 安全相关事件的记录应包括日期和时间、类型、主体标识、客体标识、事件的结果等; d) 安全审计应可以根据记录数据进行分析,并生成审计报表; e) 安全审计应可以对特定事件,提供指定方式的实时报警; f) 审计进程应受到保护避免受到未预期的中断; g) 审计记录应受到保护避免受到未预期的删除、修改或覆盖等。 4. 剩余信息保护(S3) a) 应保证用户的鉴别信息所在的存储空间,被释放或再..整理分享..

符合 是 是 是 备注 请详如4.授权控制 核心系统产品的内部审计功能 核心系统产品的内部审计功能 WORD完美格式

安全事项 分配给其他用户前得到完全清除,无论这些信息是存放在硬盘上还是在内存中; b) 应确保系统内的文件、目录和数据库记录等资源所在的存储空间,被释放或重新分配给其他用户前得到完全清除。 5. 通信完整性(S3) a) 通信双方应约定密码算法,计算通信数据报文的报文验证码,在进行通信时,双方根据校验码判断对方报文的有效性。 6. 通信保密性(S3) a) 当通信双方中的一方在一段时间内未作任何响应,另一方应能够自动结束会话; b) 在通信双方建立连接之前,利用密码技术进行会话初始化验证; c) 在通信过程中,应对整个报文或会话过程进行加密; d) 应选用符合国家有关部门要求的密码算法。 7. 抗抵赖(G3) a) 应具有在请求的情况下为数据原发者或接收者提供数据原发证据的功能; b) 应具有在请求的情况下为数据原发者或接收者提供数据接收证据的功能。 3. 数据安全 1. 数据完整性(S3) a) 应能够检测到系统管理数据、鉴别信息和用户数据在传输过程中完整性受到破坏,并在检测到完整性错误时采取必要的恢复措施; b) 应能够检测到系统管理数据、鉴别信息和用户数据在存储过程中完整性受到破坏,并在检测到完整性错误时采取必要的恢复措施; c) 应能够检测到重要程序的完整性受到破坏,并在检测到完整性错误时采取必要的恢复措施。 2. 数据保密性(S3) a) 网络设备、操作系统、数据库系统和应用系统的鉴别信息、敏感的系统管理数据和敏感的用户数据应采用加密或其他有效措施实现传输保密性; b) 网络设备、操作系统、数据库系统和应用系统的鉴别信息、敏感的系统管理数据和敏感的用户数据应采用加密或其他保护措施实现存储保密性; ..整理分享..

符合 是 是 是 是 是 是 备注 请详如5.2.2交易数据完整性 主机系统 请详如5.2.4服务器间验证 请详如5.2.1交易敏感性数据加密 加密器的密码演算法符合国家要求 主机及核心系统的日志文档提供 是 是 请详如5.2.2交易数据完整性 请详如5.1网络安全及5.2.1交易敏感性数据加密 WORD完美格式

安全事项 c) 当使用便携式和移动式设备时,应加密或者采用可移动磁盘存储敏感信息; d) 用于特定业务通信的通信信道应符合相关的国家规定。 3. 数据备份和恢复(A3) a) 应提供自动机制对重要信息进行本地和异地备份; b) 应提供恢复重要信息的功能; c) 应提供重要网络设备、通信线路和服务器的硬件冗余; d) 应提供重要业务系统的本地系统级热备份。

符合 是 备注 请详如OSA的IT架构规划 ..整理分享..

因篇幅问题不能全部显示,请点此查看更多更全内容