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

华夏银行新一代核心业务系统应用平安方案华夏银行新一代核心业务系统应用平安方案第3页版本记录版本版本日期修改者说明V0.12024/9/5中国惠普公司初稿V0.52024/10/20中国惠普公司依照华夏银行的建议，更改交易信息平安方案V1.02024/11/11中国惠普公司依照华夏银行的建议，更改文档章节结构

目录TOC\o"1-4"\h\z\u1. 整体平安方案概论 61.1. 此分文档的目的 61.2. 整体平安方案概论 72. 目前核心系统平安现况及新一代核心业务系统应用平安需求 82.1. 目前核心系统平安现况 82.1.1. 业务范围 82.1.2. 系统架构 82.1.3. 系统应用平安现况 82.2. 新一代核心业务系统应用平安需求 92.2.1. 遵循华夏平安准那么需求 92.2.2. 业务范围 92.2.3. 系统架构 92.2.4. 应用平安需求及处理 102.2.5. 平安标准、原那么及需求 11. 平安标准 11. 平安原那么 11. 平安需求 113. 身份验证 143.1. 身份验证方式 143.1.1. 动态口令验证方案 143.1.2. USB-Key验证方案 153.1.3. 身份验证方案建议实施方式与实施阶段 163.2. 身份验证系统架构方案 173.2.1. 单一入口效劳系统(Portal)架构方案 174. 授权控制 204.1. 授权管理架构 214.1.1. 授权组织架构方案 214.1.2. 授权管理流程 224.2. 授权系统架构方案 254.2.1. SSO系统架构方案 254.2.2. 独立授权效劳器架构方案 265. 传输平安 285.1. 网络平安 285.1.1. 链路加密机加密处理 285.1.2. 目前所了解BANCS系统的处理方式 285.1.3. 终端用户与BANCSLink间网络平安 295.1.4. BANCSLink与BANCS间网络平安 305.1.5. BANCSLink与综合前置间网络平安(组合交易) 305.1.6. 外围系统与综合前置间网络平安 315.1.7. 综合前置与BANCS间网络平安 315.2. 应用平安 325.2.1. 应用平安方案 325.2.2. 点对点的加密方案 325.2.3. 选择性的金融交易加密方案 335.2.4. 交易信息敏感性数据加密方案 335.2.5. 交易数据完整性方案 375.2.6. 效劳器间验证方案 376. 存储平安 406.1. 交易数据平安存储方案 406.1.1. 交易敏感性数据加密存储方案 406.2. 密码平安存储方案 416.2.1. 动态口令登入密码存储方案 416.2.2. USB-Key登入密码存储方案 416.2.3. 客户口令加密存储方案 426.2.4. 客户口令不可逆存储方案 436.3. 新旧系统密码移转方案 436.3.1. 用户登入口令的移转 446.3.2. 客户支付口令的移转 447. 平安管理 467.1. 密钥管理方案 467.1.1. 密钥生命周期管理方案 467.1.2. 密钥更换管理方案 557.2. 防病毒管理 577.2.1. 病毒传播路径 577.2.2. 防堵病毒传播方法 577.2.3. 防治病毒的解决方案 588. 推荐方案 608.1. 身份验证方案建议 608.1.1. 建议方案的优/缺点分析 608.1.2. 建议实施方案 618.2. 授权控制方案建议 628.2.1. 建议方案的优/缺点分析 628.2.2. 建议实施方案 628.3. 传输平安方案建议 638.3.1. 建议方案的优/缺点分析 638.3.2. 建议实施方案 638.4. 存储平安方案建议 648.4.1. 建议方案的优/缺点分析 648.4.2. 建议实施方案 64附件一：第二级信息系统平安等级 65附件二：第三级信息系统平安等级 71

整体平安方案概论在目前网络兴旺、网上交易盛行、网络诈欺事件及智慧型网络盗窃犯罪层出不绝的状态下，银行业务处理面临前所未有的挑战；既要维护银行的信誉与保障客户数据不外泄，同时又要能即时无误的处理客户业务需求，让客户无平安上的顾虑(无论是柜面交易或是从渠道进来的交易)，业务交易处理平安上的考量变得非常重要。规划一套业务应用平安机制及建设交易应用平安系统是当务之急的重要工作，尤其是对新一代核心业务系统更是重要。建设这种交易平安机制并不影响现行系统的运作，透过应用平安机制的建设，保护客户及银行的数据与资产，让业务交易处理的平安性及信息的保护更加完善，更是时时刻不容缓的工作。此分文档的目的信息平安是金融机构处理日常工作的最重要的指标，保护客户的资产及银行的资本重要性，是银行业务处理的重心，核心系统应用平安是此文档要说明/表达的目的。文档读者华夏银行大集中办管理层领导、华夏银行信息技术部领导、华夏银行大集中办工程管理办公室人员、华夏银行信息技术部工程管理办公室人员、华夏银行大集中工程监督委员会成员、华夏银行大集中工程管理委员会成员、华夏银行大集中工程在建工程经理、组长等。涵盖范围本文档用于描述华夏银行新一代核心业务系统〔NGCBS〕工程中有关核心系统应用平安，由总体架构组(OSA)依华夏银行新核心系统应用平安需求，整理后的整体设计方案。新一代核心业务系统(NGCBS)工程应用平安的范围包含：交易数据的平安需求数据传输的平安需求〔广域网及局域网〕数据库中数据的平安需求柜员的登录方式与授权管理

整体平安方案概论本方案的内容包含了以下几个面向：身份验证的平安方案身份验证的平安方案描述新一代核心系统应采用何种方案，确保终端用户登入系统的身份，防止使用假冒的身份。新一代核心系统的终端用户包含支行用户﹑分行用户﹑系统管理用户。此方案的详细内容请参考第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应用平安在本方案的最后，针对各章所提出的各种方案，依据各个方案的优劣点，提出建议实施的内容，作为新一代核心系统平安方案实施上的考量。

目前核心系统平安现况及新一代核心业务系统应用平安需求目前核心系统平安现况业务范围目前华夏银行的2K版核心系统是采用各个分行分散式作业方式，华夏银行有28个分行，下辖大约总共300个支行；28个分行分布于全国各地，北从沈阳分行，南到深圳分行，西起乌鲁木齐分行，东达上海分行，幅员分布广阔。2K版核心系统业务包含存款、放款等业务系统；其他的相关业务系统与管理系统皆各自建设在不同的外围系统上；每个分行有各自的外围系统，透过分行前置系统与2K版核心系统连接；各个分行有各自的中间特色业务系统，分行间的中间特色业务不尽全部相同；各个分行有各自的分行前置系统负责分行/支行间的业务交易处理。系统架构华夏银行目前正进行大前置系统工程，要将所有分行前置系统整合为一个集中式的总行综合前置系统及分行前置系统；同时将中间特色业务系统全部整合在总行综合前置系统与分行前置系统上。现有2K版核心系统后台的操作系统是AIX，前台VOST柜面系统效劳器的操作系统是SCOUnix，前台柜面终端机的操作系统是SCOUnix。前台VOST柜面系统效劳器放置在支行负责连接支行柜面交易与分行间的处理；有局部分行将前台VOST柜面系统效劳器上收到分行端，有分行统一管理前端柜面系统。系统应用平安现况目前2K系统的交易处理是由各个支行的柜面效劳器到分行2K版核心系统，交易处理上是除了客户密码是以软件加密方式处理外，其他的交易数据是没经过加密处理，完全是以明码方式传送。这种处理方式，对於交易信息的平安是无任何的保障；不平安影响所及的范围涵盖分行及下辖的支行员工与客户，对於客户资产及银行数据是完全没有任何的保护。

新一代核心业务系统应用平安需求遵循华夏平安准那么需求依〞华夏银行大集中工程信息系统信息平安等级保护要求1103.doc〞文档的标准，主要是着重在平安根本要求上的技术类平安要求，对於管理类平安要求，需依照华夏银行的平安管理标准或平安管理方法等条款办理。新一代核心业务系统应用平安需求，是以根本技术要求中的应用平安和数据平安等两方面的平安要求来规划。技术类平安上，那么是侧重在业务信息平安类，主要是保护数据在存储、传输、处理过程中不被泄漏、破坏和免受未授权的修改。业务效劳保证类与通用平安保护类的平安需求，对保护系统连续正常的运行及保护系统的连续可用性需由新一代核心业务系统主机厂商对硬件及操作系统相关的建设与实施，同时华夏银行负责运行部门需订定相关的平安管理标准来保证系统的正常连续运作。有关主机系统平安的标准，需由新一代核心业务系统主机厂商来提供硬件及操作系统相关的平安数据；数据库系统的平安需由数据库厂商提供相关的平安数据。网络平安需由相关的路由器、交换机、通信线路等在内的厂商提供相关的信息系统网络环境的平安数据。详细有关平安需求等级的标准对照，请详如本文档的附件章节。业务范围新一代核心系统业务范围包含：存款、放款、华夏卡、支付结算等，所有的银行客户业务交易信息，皆与核心系统息息相关，是银行业务处理中最重要的局部。系统架构新一代核心系统是采用集中式的作业方式处理，全国各地分行所有的交易全部都经由全行网络送到总行的新核心系统处理。新一代核心业务系统，除了新一代核心系统外，尚有总帐系统、总行综合前置系统、55个(与新一代核心系统有接口关系的)外围系统、核心配套外围系统(从2K系统独立出来的系统，如:人行大/小额系统、理财系统、卡记点积分系统等)及其他系统等(与新一代核心系统无接口关系，如:人力资源系统、稽核系统等)。新一代核心系统负责面向客户管理的交易处理作业；总帐系统负责面向华夏内部管理的后勤处理作业；综合前置系统负责华夏银行总行面向外部的交易处理(如对分行/支行交易处理、外围系统交易处理、中间特色业务系统交易处理、面向各种渠道交易处理、银联中心/银关通/银证通/财税库行/人民银行等外围金融机构的交易处理)，是华夏银行业务处理的重要把关门户。新一代核心系统(BANCS)、前端柜面系统(BANCSLink)及柜员终端机的交易处理是采用集中式的作业方式，新一代核心系统产品并未有应用信息平安处理机制；目前华夏银行使用对客户密码采用软件加密的方式，对於最重要的新一代核心业务系统是无法满足应用信息平安的需要；加上目前外在环境的变化与智慧型网络犯罪的盛行，无法防范这些种种的威胁，对华夏银行及所有客户的整体影响更是深远。应用平安需求及处理应用平安的规划，将从国际上的应用数据的平安标准(应用平安及传输平安)、平安原那么(数据的真实性(私密性)、完整性(唯一性)、机密性(身份认证)和不可抵赖性(不可否认性))及平安需求，来逐步说明。同时，在应用平安上需要搭配相关的硬件/软件加密设备来进行敏感性数据加密；在网络上需要采用链路加密设备，来处理网络层的传输平安需求。

平安标准、原那么及需求平安标准应用的平安标准平安上的标准主要有两种：数据加密标准(DES:DataEncryptionStandard)与公开密钥法那么(PKI:PublicKeyAlgorithm)。数据加密标准(DES):需要产生一对密钥，必须要将自己产生的另一个密钥发送给对方，本身端用自己的密钥加密，对方端用所送的密钥去解密。一般应用在数据的端对端的加密/解密使用，普遍用於金融机构的数据加密/解密。另外对数据加密的强化，采用TripleDES的加密方式。公开密钥法那么(PKI):需要产生一对钥值，分为公钥及密钥，自己保存密钥，公钥发送给对方。本身用密钥对数据加密，对方用所送的公钥验证数据的正确性。一般应用在网络电子交易的加密/解密处理。传输的平安标准网络层传输的平安标准，主要有几种，如：SSL(SecureSocketLayer)、VPN(VirtualPrivateNetwork)等来防护数据传输的平安。一般应用在网络层的数据传输加密/解密使用。业界一般常用的方式是SSL，但VPN的平安性较SSL的平安性高。平安原那么参考国际的平安准那么要求及目前相关的平安解决方案，无论是动态口令、USB-Key或数字证书(Certificate)方案，应用上的平安或是传输过程中的平安要求，皆能实现数据的真实性(私密性)、完整性(唯一性)、机密性(身份认证)和不可抵赖性(不可否认性)。平安需求平安需求，无论是应用的平安需求或是传输的平安需求，从平安要求的四大要素真实性(私密性)、完整性(唯一性)、机密性(身份认证)和不可抵赖性(不可否认性)，来进行应用平安的处理。私密/真实性：确认数据输入的私密/真实性主要是保证数据是由发送方所发送的原始数据。为了到达真实性的需求，必须对输入的数据进行加工，保持原始数据於传输过程中与原来是一样的。数据加工的方法之一既是对数据进行加密处理，保证送达的是原始数据。加密处理可采用DES或PKI方式加密，对於数据量大或是加密频繁的交易，采用DES加密方式会比用PKI加密方式效率较好。PKI加密方式较适合於数据量小或是加密频繁性低的交易。完整/唯一性：确认数据在传输的过程中不至於被篡改主要是保证数据於传输过程中，不会被内部/外部人员篡改，保证原来的数据值。为了到达完整性的需求，必须保障数据的完整性及不会於传输过程中被人篡改。做法上是采用发送者的密钥对整个数据验算出一个MAC值，连同数据一起发送给收信方；假设数据於传输过程中被篡改，受信方於受到数据后，用发送方所给予的密钥(DES)/公钥(PKI)对整个数据验算出一个MAC值，进行验证时，所验算出来的MAC值与发送者发送时所产生的MAC值不相同，即可确定数据被篡改。机密性/身份确认：确认数据发送者的身份正确性主要是确认数据发送者的身份是正确的，不是由其他人发送或有人假冒身份发送数据。机密性确实认，做法上采用发送者所提供的密钥(DES)/公钥(PKI)对整个数据进行验算出一个MAC值，所验算出来的MAC值与发送者发送时所产生的MAC值相同，即可确认数据发送者的身份正确性。不可否認/不可抵赖性：确认数据的正确及完整性主要是确认整个数据的完整性及正确性与由发送者发送的数据是相同的，发送者无法否认此份数据不是由发送者所发送。不可否認性确实认，做法上采用发送者所提供的密钥(DES)/公钥(PKI)对整个数据进行验算一个MAC值，所验算出来的MAC值与发送者发送时所产生的MAC值相同，即可确认数据的正确及完整性。网络传输的平安需求网络传输的内部平安需求由於新一代核心系统才集中式作业处理，从华夏银行的支行/分行所发送的交易，全部经由网络传送到总行处理。除了上述的四点平安上的需求外，尚需要参加内部网络的传输平安布置(内部系统平安控制管理，如VPN/SSL/加密处理)才能完整的防护数据的平安。支行/分行的网络传输应用平安需求，是华夏银行内部网络的交易，是固定/静态的交易处理；平安需求及防护上处理需要与外部不同。尤其内部的平安威胁及平安被破坏性大於外部。(内贼难防)网络传输的外部平安需求由於新一代核心系统才集中式作业处理，从不同渠道的交易也会经由网络传送到总行处理。除了上述的四点平安上的需求外，尚需要参加外部的网络传输平安布置(如动态口令)才能完整的防护数据的平安。渠道的网络交易平安需求，是华夏银行外部网络的交易，是不固定/动态的交易处理；平安需求及防护上处理需要与内部不同。外部的平安威胁及平安被破坏性小於内部，但假设是内部连同外部进行平安破坏，更是难防护。(外贼难防，内贼更难防)

身份验证身份验证方式新一代核心系统的用户包含了分行或支行的行员。分行与支行的行员都是透过BANCSLink登入到核心系统(BANCS)或是其他的外围系统。因此，不管核心系统(BANCS)或是外围系统都需要对登入的用户进行身份的核验工作，确认登入者的身份，以利控管系统操作存取的权限。本建议书中，对于身份验证的机制，提供两个方案的选择，分别是动态口令验证与USB-Key验证方案。动态口令验证方案动态口令验证的方式是设置并发放给每一个用户一个动态口令盘。用户登入系统时，采用以下的步骤：用户利用动态口令盘产生动态口令。用户再将动态口令输入登入页面的口令空格。应用系统效劳端透过动态口令效劳系统验证动态口令是否正确，均定是否允许用户登入。动态口令验证方案建议采用市面上成熟的动态口令系统，整合现有的应用系统实现用户统一的登入身份验证方法。动态口令系统建置一般包含以下的步骤：引进并建置动态密码效劳器系统。规划用户根本信息与动态口令数据间的关系结构。规划动态口令盘的设置﹑发放﹑回收等作业程序与管理措施。依据动态口令盘的作业程序与管理措施，开发或客户化修改动态口令盘的管理应用系统。应用系统配合动态口令效劳系统的登入验证程序修改。动态口令验证方案有以下的优点：使用方便。用户只需使用动态口令盘在每次登入时产生口令即可。用户终端设备无需安装任何的控制软件与提供任何额外的接口。应用系统整合容易。应用系统只需于登入时调用动态口令系统提供的接口。动态口令验证方案有以下的缺点：一般的动态口令无法使用于交易数据的签名。由于动态口令盘大多是采用离线作业方式，因此无法以连线侦测方式，侦测用户是否离席。USB-Key验证方案USB-Key验证方式是在USB-Key或IC卡上设置用户根本信息以及登入密钥，并发放给用户使用。用户登入系统时，采用以下的步骤：将USB-Key插入终端设备或是将IC卡插入IC读卡机内。用户输入USB-Key或IC卡的开启口令后，由登入页面自动读取USB-Key内的用户识别信息，并以登入密钥产生登入验证码。应用效劳端利用密钥验证技术验证用户的识别信息与验证码是否相符，决定是否允许登入系统。USB-Key验证方案建议由有经验的平安系统开发商，依银行的需求规划建制一套符合需求的验证系统。USB-Key验证系统建置一般包含以下的步骤：规划USB-Key内的用户验证信息与验证密钥结构与产生方法。规划USB-Key的设置﹑发放﹑回收等作业程序与管理措施。依据USB-Key的作业程序与管理措施，开发USB-Key的管理应用系统，与验证效劳系统。应用系统配合USB-Key验证效劳系统的登入验证程序修改。以及登入页面配合USB-Key登入验证控件验证程序修改。USB-Key验证方案有以下的优点：采用双因素强验证(包含USB-Key以及USB-Key的开启口令)。USB-Key与终端设备采用连线方式，可随时验证用户是否离席。USB-Key可采用双芯片(有线与无线)设计，于门禁系统结合。USB-Key可扩充加载数字证书，提供重要交易的数字签名功能。USB-Key验证方式有以下的缺点：市场上无统一标准的产品，需要开发建置。用户终端设备上需提供USB接口(采用USB-Key)或是IC读卡机(采用IC卡)。用户终端设备上需安装USB-Key的相关控件(可由登入页面自动下载安装)。应用系统整合较为复杂，登入页面需依照USB-Key登入验证程序修改。身份验证方案建议实施方式与实施阶段由于新一代核心系统的整体系统架构复杂，而且有许多的外围系统。因此实施方案上，建议分为初期实施范围与后续阶段实施范围。在实施方式上，建议采用以下的实施方式：由BANCSLink提供统一的登入页面，让用户登入。BANCSLink将用户提交的身份验证数据，转发给核心效劳系统(BANCS)或外围系统。核心效劳系统与外围系统，各自透过统一的身份验证效劳系统验证用户提交的身份验证数据是否符合，决定是否允许登入系统。在实施阶段范围上，建议采用以下的方式：在初期阶段的实施范围，建议只有核心效劳系统(BANCS)。其它各外围系统仍保存原有的身份验证方式。后续阶段再逐一修给各个外围系统，将身份验证机制转移至统一的身份验证效劳系统上。身份验证系统架构方案单一入口效劳系统(Portal)架构方案为了让用户有一个统一的入口与统一的身份验证机制，可以采用的方案之一是建置一套单一入口效劳系统〔PortalServer〕，负责提供用户的单一入口验证与用户权限管理机制。由单一入口系统提供所有系统，包含新核心系统﹑外围系统，统一的效劳入口。单一入口系统所提供的功能不仅只是单一的登入入口(Single-Sign-On)，还包含整合用户与应用系统间的Session控管，以及用户对业务功能的权限管理等。单一入口系统方案的实施，必须经过以下的步骤：引进并建置一套单一入口效劳系统。规划单一入口系统的身份验证方案与业务权限控管方案。规划各业务系统，包含核心系统﹑外围系统与单一入口系统间的Session控制流程。规划单一入口系统上，各业务系统的业务与功能架构。依照规划方案客户化单一入口系统。依照规划方案修改或改造应用系统的Session控管机制与业务权限控管机制。依照规划方案修改或改造应用系统的业务与功能架构。单一入口系统方案虽然可提供全面的用户单一效劳入口，但是在实施上会面临以下的问题：单一入口系统的架构所考虑的不仅是统一登入入口的实施，更应该考虑所有业务架构的统一性与整合性。单一入口系统对于各应用系统将的整合有一定的标准与标准(如JSR168)。各应用系统必须依照标准与标准进行大幅度的修改或是改造。BANCS与BANCSLink间的协定是采用新一代核心系统自有的协定，对采用单一入口的标准(如JSR168)，有实施上的极大困难。各分行的入口实际上是透过各分行所配置的BANCSLink效劳器登入，并非直接的在单一入口系统(Portal)上登入。因此在系统架构上的配置会有困难度。在面临以上困难的状况下，对于单一效劳入口系统的实现，建议采用以下的方案：系统架构BANCS与BANCSLink间仍采用原有架构与协定。BANCSLink透过单一入口效劳系统验证用户身份，并登入。BANCSLink以单一入口效劳系统回应的登入识别码，发送登入信息给BANCS，由BANCS在透过单一入口效劳系统的登入识别码验证机制进行虚拟身份验证。BANCS提供的业务功能，不透过单一入口效劳系统，由BANCS自行管理用户的权限。其它的外围系统，均必须依据JSR168标准，修改或改造应用系统，与单一入口效劳系统整合，透过但一入口效劳系统调用业务应用效劳。单一入口效劳系统方案有以以下的优点：可到达用户单一的效劳入口。可提供用户统一的业务权限管理。单一入口效劳系统方案也有以下的缺点：系统复杂度高，需要详细的规划。现有系统(包含核心系统与外围系统)的配合实施难度高。由于新一代核心系统的BANCS与BANCSLink间采用自有的协定，对于单一入口效劳协定标准的配合可行性有待商榷。

独立身份验证效劳器架构方案另一种比拟单纯的方案是建立一套独立的身份验证效劳系统，提供新核心系统(BANCS)以及外围系统统一的身份验证机制。此种方案的实施必须有以下的步骤：开发建置一套独立的身份验证效劳系统。独立身份验证效劳系统搭配选定的身份验证机制(动态口令或USB-Key)，实现身份验证功能。BANCS以及外围系统的登入功能依照独立身份验证效劳系统提供的身份验证接口，修改登入验证程序。此方案的系统架构图如以下图：此方案有以下的优点：系统架构较为单纯，实施较为容易﹑省时。可提供统一的用户身份验证，用户不需针对不同的应用系统使用不同的登入代码﹑密码，甚至登入方式。应用系统(包含核心系统与外围系统)的修改幅度较小，容易整合。此方案也有以下的缺点：无法到达单一登入入口的效劳水平，用户仍要在各个应用系统(包含核心系统与外围系统)执行登入动作。授权控制目前华夏银行新一代核心系统工程，除了新核心系统、总帐系统及综合前置系统外，与新核心系统相关的外围系统约有55个系统。於目前的时空环境下，也无法将所有的外围系统前台柜面界面全部转换为BANCSLink前台柜面界面；局部的外围系统前台柜面环境将使用原来的前台柜面系统处理交易。同时，外围系统后台应用处理也是与新一代核心系统分开，各自处理各自的交易；核心系统及各个外围系统各自处理各个系统的交易授权。於此情况下，对於柜员的业务处理授权可能无一致性的授权方式，每个系统必须自行处理交易授权。考虑现实的状态及可行性的做法，有关授权控制将从建立一套完整的平安管理流程开始，再依目前状态，建立一个授权系统架构，来建设整体的授权控制管理。

授权管理架构授权控制从系统建设时开始，订定一套完整的平安管理流程；从系统平安组织建立开始，先建立系统原始平安控管人员，再由原始平安控管人员建立系统平安控制人员，再由系统平安控制人员建立业务交易的授权平安管理。授权控制说明如下：授权组织架构方案授权组织架构授权管理建议依业务别与工作职责的划分，分别建立个别的群组授权，例如：依工作职责划分的群组权限，将每个员工分为不同的群组，每个群组的授权依其工作职责给与不同的权限；每个员工可能属於一个以上的群组。主管有核准的权限，但没有执行交易的权限经办/柜员有执行交易的权限，但没有核准的权限每个单位皆有自己职责的不同权限建立平安管理群组经办，负责建立每个员工/主管代号及授权建立平安管理群组主管，负责核准新建立的员工/主管及授权

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

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

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

授权系统架构方案SSO系统架构方案SSO授权系统架构是采用单一授权方式，经由对使用者的一次授权，使用者可依授权於各个业务系统进行业务操作处理。SSO授权系统架构SSO系统授权流程如下：使用者登入时，经由单一登入(SSO)登入单一登入网页(PortalService)由单一登入网页(PortalService)经由登入效劳器(AccessControlServer)，对使用者的代号与密码进行单一控管及验证，登入效劳器(AccessControlServer)会将使用者的代号及密码，一一转换为后台每个系统的使用者对应代号及密码，建立信任机制，登入每个系统；对使用者只要登入系统一次单一登入网页(PortalService)会经由授权效劳器(AuthorityControlServer)获得使用者所属的群组於每个系统中的授权使用者於一次登入后，可进入不同系统执行被授权的交易处理授权效劳器(AuthorityControlServer)中有使用者於每个系统的授权数据，到达单一(SSO)授权目的；授权效劳器(AuthorityControlServer)需先建立与每个系统的授权信任机制。使用SSO系统架构方案的优点：单一/统一的授权管理方式，对未来新增业务系统或新增业务交易处理，依循此标准授权方式，建设非常方便/迅速方便/简化系统授权管理简化系统的交易处理流程使用SSO系统架构方案的缺点：初期系统建置非常复杂，相关系统必需配合更改交易登入及交易授权建置本钱较高独立授权效劳器架构方案独立授权效劳器的授权方式，是在没有建立单一签入(SSO)的架构下，建置一套独立的授权机制，处理使用者的业务交易授权。独立授权系统架构独立授权效劳器授权流程如下：独立授权效劳器建立使用者的群组授权权限，与每个系统建立信任机制使用者登入系统完成后，由业务交易系统向独立授权效劳器发送验证信息，经独立授权效劳器确认后，使用者得进行业务交易处理使用独立授权效劳器架构方案的优点：建置本钱较低初期系统建置复杂性小，相关应用系统更改幅度较小使用独立授权效劳器架构方案的缺点：只能简化一局部系统授权管理对未来新增业务系统或新增业务交易处理，各个业务系统的改动量较大无法简化系统的交易处理流程

传输平安传输平安包含两个局部，网络平安及应用平安；网络平安卓重在数据於网络中传输时的平安防护，应用平安注重於数据的加密处理，以防止数据被篡改。网络平安应用数据於广域网络或局网中传输时，假设采用明码传输方式会有平安上的顾虑，容易引起外部或内部有意人的数据截取与篡改，造成平安上的问题。数据传输平安性的考量，从整体的网络及地理区域上分为以下几项：支行到分行传输分行到总行传输总行效劳器间传输外部网络渠道传输对外机构的传输链路加密机加密处理对於上述数据传输的平安需求，第一个考虑的重点是在网络层加上网络传输加密处理，建议於每个路由器前皆需要加一套链路加密机，负责网络层的加密/解密处理。从支行的路由器开始到分行/总行的路由器，皆需增加一套链路加密机。外围系统间的网络传输、外围系统与核心系统间的网络传输等，皆需要加一套链路加密机。以下分为目前BANCS系统的处理方式及从地理区域考量说明如下：目前所了解BANCS系统的处理方式新核心系统产品(BANCS及BANCSLink)的后台/前台的平安处理方式为：前端柜面机与BANCSLink间(BANCS传输平安示意图中红色线条局部)BANCS系统中有关前台柜面终端机与BANCSLink间，数据传输时，没有对数据进行加密处理。新核心系统厂商建议前端柜面终端机与BANCSLink间的数据传输，采用SSL加密处理；由於SSL加密只负责通信层在网络传输时的加密，对於重要数据/报文并未加密处理，平安上仍然有漏洞，需要有完善的补强措施。BANCSLink与BANCS间(BANCS传输平安示意图中红色线条局部)BANCS系统中有关BANCSLink与BANCS间，数据传输时，没有对数据进行加密处理。新核心系统厂商建议由华夏订定平安策略及处理方式办理。BANCS传输平安示意图终端用户与BANCSLink间网络平安由於华夏银行28个分行分布广阔，每个分行下约有10~12个支行，每个支行不配置BANCSLink柜面效劳器，每个支行的柜面终端机需直接连结到分行的BANCSLink柜面效劳器，经由BANCSLink柜面效劳器连接到总行核心系统。目前华夏银行已经启动网络建设工程，网络平安上，已经将总行与分行间的网络平安采用VPN方式处理，保护总行与分行间的网络平安。分行与支行间尚未建置网络平安处理。分行与支行间网络传输平安示意图BANCSLink与BANCS间网络平安由於BANCS系统中有关BANCSLink与BANCS间，数据传输时，没有对数据进行加密处理，必须完善分行与总行间的网络(数据传输)平安。网络传输平安处理：於分行效劳器〔BANCSLinkServer〕将数据传输到总行前，采用链路加密机来对网络传输数据进行加密处理后，传送到总行。总行交易处理完成后，透过链路加密机进行网络层的加密处理，送回分行效劳器分行效劳器先由链路加密机将数据进行网络层的解密，再由加密机进行交易数据3DES解密处理后，传送到柜员端显现於柜面终端机页面上链路加密机的接入对应用系统来讲是透明的，即与应用系统无关，不需要更改任何应用系统程序。分行与总行间网络传输平安示意图BANCSLink与综合前置间网络平安(组合交易)综合前置系统主要负责进出总行后台业务应用软件系统的桥梁，处理的交易数量众多及对处理的效率需求要能良好，假设要考量平安上的需要，可能会对综合前置系统处理交易量及效率会有影响；要兼顾平安需要，同时要确保处理效率，不是件容易的事，可能无法两者兼顾。考量综合前置系统的交易处理类型及方式，除了组合型交易及中间特色业务外，其余的业务处理对综合前置系统来说都只是过路财神左近右出或右近左出，对於此类的交易，不需要在综合前置系统进行解密后再加密送出，直接直转送出即可；即进出皆由链路加密机处理。网络传输平安处理：於分行效劳器(BANCSLinkServer)将数据传输到综合前置系统前，采用链路加密机来对网络传输数据进行加密处理后传送综合前置系统收到其他系统送到分行效劳器(BANCSLinkServer)的交易，透过链路加密机进行网络层的加密处理，送回分行效劳器外围系统与综合前置间网络平安网络传输平安处理：於外围系统将数据传输到综合前置系统前，采用链路加密机来对网络传输数据进行加密处理后传送综合前置系统收到其他系统送到外围系统的交易，透过链路加密机进行网络层的加密处理，送回外围系统综合前置与BANCS间网络平安网络传输平安处理：於综合前置系统将数据传输到核心系统(BANCS)前，采用链路加密机来对网络传输数据进行加密处理后传送核心系统(BANCS)透过链路加密机进行网络层的加密处理，送到综合前置系统

应用平安应用平安方案在网络平安方案中对于网络层均提供了链路加密机制。所以根本上，交易信息在网络传输过程中均属据加密状态。点对点的加密方案因此，在这里要考虑的应用信息加密主要是针对点对点的交易数据加密需求。这些点对点包含：用户对BANCSLink。用户对BANCS。用户对外围系统。外围系统对BANCS。点对点间的交易数据加密需求，着重在核心系统(BANCS)、综合前置系统及分行效劳器(BANCSLink)间的应用加密处理，此三个系统前需要增加一套应用加密机来处理交易数据加密；对於外围系统不建议采用应用加密处理。点对点应用加密架构图在整个新一代核心系统的交易信息需求分析上，发现并无需要整个信息执行点对点的信息加密需求。只有针对局部敏感性的交易数据需要点对点的加密需求。敏感性数据的加密需求将在下一个章节提供具体方案。选择性的金融交易加密方案考虑交易的风险性及网络交易便利性，建议华夏银行对所有的金融交易皆进行应用加密处理；华夏银行可考虑实际上交易处理效率的需要，选取某些类别的金融交易进行应用加密处理。例如：跨银行/跨分行的取款交易、跨银行/跨分行的汇款交易、跨分行的通存交易、变更密码交易、变更客户名称/ID/地址交易等。国外的经验一般采用所有的金融交易都需要做应用加密处理；虽然有些金融机构采用选择性的金融交易做应用加密处理，未来产生的风险要由建议单位/人负责承当。核心系统开发商的建置客户中，台新银行选择了四种金融交易进行应用数据加密处理： 20017–先进汇款remittancebycash21016–汇出汇款(专帐交易)remittancebytransfer55032–汇出登录remittancedataentry(supplementarydataentry)55040–汇出放行remittanceapproval交易信息敏感性数据加密方案交易敏感性数据加密需求是针对局部的交易数据，必须从交易发动源头进行加密，直到交易终点处理是方可解开或是进行验证。这局部的方案主要是针对客户支付口令的绝对私密性，不得在交易过程中有任何泄漏的风险。对于客户口令加密的方案可以分成几种情形说明：大前置系统与核心系统(BANCS)大前置系统与核心系统间交易数据的加密，建议采用Triple-DES加密方式，以以下的原那么实施：由交易发起端对客户口令，以核心系统产生的「口令加密密钥」加密后(加密方式建议遵循ANSX9.8标准)，再放入交易信息内发送。交易接受端接收到交易信息后，将信息内以「口令加密密钥」加密的客户口令与数据库内加密的客户口令直接提交给加密机进行比对，确认是否符合。客户口令的加密比对必须在加密机内一次完成，不得语应用系统中解开。「口令加密密钥」由核心系统透过加密机产生，再利用密钥同时信息交换机制，与外围系统进行同时。用户与核心系统(BANCS)–点对点加密由于用户终端设备并无任何的加密设备。因此用户终端的加密必须考虑采用加密密钥可公开的加密方式。此方案是利用非对称密钥的公钥可公开的技术，直接在用户终端备上一软件方式加密，再与核心系统端解开比对。此种方法采用以下的实施原那么：核心系统透过加密机产生加密用的交易加密的非对称密钥(RSAkeypair)，并取出公钥(Publickey)，称为「交易加密公钥」。核心系统将「交易加密公钥」发布给所有的BANCSLinks。用户在BANCSLinks上提交交易数据时，交易页面动态产生对称(Triple-DES)的「动态口令加密密钥」，对客户口令进行加密。(口令加密建议遵循ANSX9.8原那么)。交易页面在将「动态口令加密密钥」以「交易加密公钥」加密后，连同交易数据提交BANCSLink。BANCSLinks将加密后的交易数据，以及加密后的「动态口令加密密钥」一并以交易信息送交核心系统(BANCS)。核心系统(BANCS)受到交易信息后，先利用「交易加密私钥」(Privatekey)解开「动态口令加密密钥」，再以「动态口令加密密钥」比对客户口令。核心系统(BANCS)对于「动态口令加密密钥」的解开，以及客户口令加密比对的动作，应该透过加密机一次性完成。用户与核心系统(BANCS)–BANCSLink加密另一种方案是基于用户终端与BANCSLink间采用SSL或VPN网络加密方式，认定其交易信息泄露几率极小的前提下。只在BANCSLinks与BANCS间对口令加密。采用以下的实施原那么：核心系统透过加密机产生加密用的「口令加密密钥」(Triple-DESkeys)，并利用密钥同时信息交换机制，与BANCSLinks进行同时。用户与平安页面上提交交易数据，包含客户口令。交易数据透过平安网络(VPN或是SSL)，送到BANCSLink。BANCSLink收到用户提交的交易数据后，利用「口令加密密钥」对客户口令加密后，放入交易信息内送交核心系统(BANCS)。核心系统(BANCS)受到交易信息后，利用「口令加密密钥」解开并比对客户支付口令。核心系统(BANCS)对于以「口令加密密钥」解开并比对客户支付口令的动作，应该透过加密机一次性完成。用户终端与外围系统用户与外围系统间对于客户口令的加密沿用各外围系统目前的做法，建议不予改变。

交易数据完整性方案由于本建议方案中对于效劳器间的网络，均以网络层加密机制保护。交易信息在网络上传输时，保持加密状态。因此就整体平安需求上，比拟没有交易数据完整性上的需求。效劳器间验证方案各效劳器间的验证目的是在防止内部人员利用假效劳器发动假交易，造成交易的纠纷以及金额上的损失。效劳器间的验证依据连线模式不同而必须有不同的设计方案。在这里，我们假设效劳器间的交易连接方式是采用非固定连接方式(Connectionless)。在此总连接方式下，效劳器必须对每一笔交易信息均验证该交易发送方是否为合法的效劳器。验证方式有以下两种：IP验证法IP验证法是针对没每一个交易信息验证信息发送方的IP是否为对应的合法IP。此种验证法必须采用以下的实施步骤:每一部效劳器必须设置一个固定的对外IP。应用系统中须设置每一个交易方效劳器的正确IP。当应用系统收到交易信息时，透过网络层取得发送方的IP，再验证发送方的IP与设置中合法交易信息发送方的IP是否一致。此种验证法有以下的优点：不须改变交易信息的格式与交易流程。透过交易信息收发的网络层信息即可取得验证数据。此种验证法有以下的缺点：每一个效劳器在网络层必须有固定的IP，对于使用VPN或是虚拟IP交换器的网络并不适用。只用IP的验证方法在平安上比拟薄弱。有可能假效劳器暂时取代合法效劳器的IP而不会被发觉。当效劳器因为网络位置变更，而更改IP时，必须更该其他应用系统上的IP设置。信息押码验证法信息押码验证法是在交易信息中，将局部的交易数据以密钥加密的方式，产生验证码，再将验证法放入交易信息中一起发送。交易接收方再以同样的方法﹑同样的密钥检核验证码是否正确。产生验证码的密钥通常使用Triple-DES的密钥以及加密算法(建议采用CBC加密模式)。此种验证法必须采用以下的步骤：交易信息必须增设交易验证码的字段。定义每一个交易信息内，用以产生验证码的交易数据字段。规划验证码密钥的产生规那么与变更的同时交换规那么。依照规划的验证码产生/验证规那么，修改应用系统信息收送的机制。开发个效劳系统间的密钥变更同时交换功能。此种验证法有以下的优点:此种验证方式，可使用与任何的网络环境。不锁定效劳器的网络地址与实体位置，效劳器的网络位置变更不影响任何设置。较高的平安强度，必须有存取密钥的权限才能产生验证码。此种验证法有以下的缺点：此种方法必须配合加密机使用，本钱较高。次种方法必须变更交易信息格式，增加验证码字段。应用系统配合修改的幅度较大。

存储平安数据平安方案，主要以保护数据不被任意更改/篡改，确保数据的完整性为主。交易的数据中包含许多种信息，无法对所有的交易及将整个交易报文数据加/解密，可能会影响交易处理效率，建议只对报文的敏感性数据进行加/解密处理，同时要考量交易数据存储的平安。交易数据平安存储方案交易敏感性数据加密存储方案敏感性交易数据由於核心系统是整体系统交易的重心，对於交易数据的平安处理特别重要，尤其是客户的交易数据平安。交易的报文中，包含许多敏感性数据，如：客户帐号/卡号客户密码交易金额交易时间(含:年月日时分秒)敏感性交易数据的加密处理方式对於敏感性的交易数据，必须要加密处理，以确保数据的完整性、正确性及不可否认性。敏感性交易数据的加密方式，建议采用以3DES密钥加密处理外，同时视需要，对整个报文/关键字段以MAC生成校验值。(不建议采用PKI加密方式，主要是PKI加密速度较费时。)敏感性交易数据交易传输流程中，需经硬件应用及链路加密处理，尤其是客户密码需全程以乱码方式传输加密/解密处理，需经由硬件加密/解密机处理；禁止使用软件加/解密处理对於上述的敏感性交易数据，由应用软件系统透过API呼叫方式，连接外接的加密机进行加密处理，采用以3DES密钥方式加密处理，同时生成MAC校验值，透过网络传送后台应用软件。核心系统对敏感性交易数据的处理流程为了减少核心系统的复杂性及减少核心系统的更改量，以免影响工程进度及时程，建议核心系统对交易数据的平安处理如下：BANCSLink於收到支行/分行的交易数据时，发送到核心系统前，先呼叫应用加密机对报文数据中的敏感性交易数据加密处理，同时要求加密机对整个报文/关键字段以MAC生成校验值。核心系统收到敏感性交易数据时，先呼叫应用加密机对报文数据中的敏感性交易数据解密处理，同时要求加密机对整个报文/关键字段的MAC校验值验证正确性后，才进行相关交易程序处理。敏感性交易数据存储除了加密处理外，对於敏感性交易数据的存储平安，也非常需要加以特别重视，以免敏感性交易数据被有心人窃取、窥视。有关敏感性交易数据的存储平安，建议处理方式如下：客户密码於柜员终端输入时，以乱码呈现；关敏感性交易数据输入后，传送前，需经硬件加密机进行应用加密处理；传输过程中，全程以乱码传送；应用软件系统后台以API呼叫方式，呼叫硬件加密机验证客户密码的正确性及将其他的敏感性交易数据解密处理客户密码存储於数据库时，是以乱码方式存放。密码平安存储方案密码包含用户登入密码﹑客户密码两种。两种密码的存储各有不同的建议方案。动态口令登入密码存储方案采用动态口令盘的身份验证方式，用户的动态口令是依着时间不停的演变。而密码的验证方式是由动态口令效劳系统于系统内部自行验证。因此用户的密码存储是由动态口令效劳系统本身具备的密码保护的平安机制负责。因此，用户的登入密码(口令)不需要另行存储。USB-Key登入密码存储方案采用USB-Key的身份验证方式，用户的口令是翻开USB-Key存储的口令，直接存储于USB-Key中，以USB-Key本身的平安机制保护。USB-Key内的登入验证密钥，是由加密机依据用户代码以验证主密码利用多样化演算法(Diverse)产生。而验证主密钥直接存储于加密机中。因此，用户的USB-Key口令与USB-Key内的验证密钥均不需要另行存储。客户口令加密存储方案客户口令是随着交易信息传送与效劳期间。因此透过交易信息的客户口令的点对点加密机制，所有的交易信息内的客户口令均为加密状态。唯一会存储客户口令的系统应该是新核心系统(BANCS)。由于客户数量庞大，一般不可能直接存储于加密机中，而存储于数据库中。为了防止客户口令泄漏，必须以加密方式存储于数据库中。建议采用以下的方式：利用加密机产生或是采用指定方式产生客户口令。客户口令产生后，直接以加密机的客户口令存储加密密钥加密后(建议采用ANSX9.8标准)，存储与数据库内。客户口令存储加密密钥建议使用Triple-DES。客户口令比对时，直接将交易信息内加密的客户口令与数据库的加密客户口令提交给加密机，由加密机解密比对后，送回结果。当加密机内的客户口令加密密钥变更时，必须对数据库内所有用户的客户密钥进行重行加密处理(解密再加密)后再存储。此种客户口令加密存储方法有以下的优点：加密强度较强，不易泄漏。但此种客户口令加密存储方法也有下了的缺点：加密密钥更换时，必须重行加密所有的口令，处理费时繁复。如果加密密钥遗失，所有的客户口令皆失效，必须请客户从刑设置，可能造成重大损失。客户口令不可逆存储方案另一种存储客户口令的方法是采用不可逆运算，将客户口令转换成不可复原的数字，直接存储于数据库中。此种方法采用下了的方式：利用加密机产生或是采用指定方式产生客户口令。客户口令产生后，直接以不可逆运算将客户口令转换成一组不可复原的口令数字存储与数据库内。客户口令不可逆运算，建议可使用SHA-256。客户口令比对时，直接将交易信息内加密的客户口令与数据库的口令数字提交给加密机，由加密机解密比对后，送回结果。此种客户口令不可逆存储方法有以下的优点：理论上无法利用口令数字复原正确的口令。不需使用密钥，维护上比拟简单，依不需考虑密钥变更的问题。但此种客户口令不可逆存储方法也有下了的缺点：不可逆运算理论上造成重复的几率不等于零，有可能不同的口令会产生相同的口令数字。因此猜中的几率并非完全没有。新旧系统密码移转方案于本建议方案中，对于新旧系统间的密码已转问题，可从以下几方面说明：用户登入口令的移转由于新系统于旧系统间使用的身份验证方式不同。不管新系统采用动态口令盘或是USB-Key的那一种方案，用户的登入口令都必须换新。因此，建议采用以下的步骤：预先制作所有用户登入使用的动态口令盘或是USB-Key。先行发放动态口令盘或是USB-Key给用户，并于新系统上设置每一个用户使用的动态口令盘编号或是USB-Key编号。当业务由旧系统切换为新系统时，要求所有用户开始使用动态口令或USB-Key登入系统。原有旧系统上的登入口令立即作废。客户支付口令的移转对于客户的口令，基于客户的方便性，不能因系统转换而更换客户的口令。假设新系统采用客户口令加密存储的方案，那么建议采用以下的步骤：利用加密机产生新的客户口令加密密钥。将原有旧系统的客户口令加密密钥，汇入/输入加密机内。开发一个程序，将原有旧系统的所有客户口令利用加密机重新加密(用旧密钥解密再用新密钥加密)。将新密钥加密后的客户口令存储到新系统数据库内的客户信息表内。假设新系统采用客户口令不可逆存储的方案，那么建议采用以下的步骤：将原有旧系统的客户口令加密密钥，汇入/输入加密机内。开发一个程序，将原有旧系统的所有客户口令利用加密机解密并产生口令数字(用旧密钥解密再用不可逆运算产生口令数字)。将客户口令数字存储到新系统数据库内的客户信息表内。

平安管理平安管理包含两个局部，分别是密钥管理及防病毒管理，分别於以下章节中说明。密钥管理方案密钥管理方案影响整个系统的平安作业，华夏银行必须订定相关密钥管理策略，由平安设备厂商依照华夏的密钥管理策略，实施密钥的平安管理及运行。密钥生命周期管理方案密钥区分为三种，分为本地主密钥、区域主密钥及数据密钥。此三种密钥的层次、级别和管理方法(遵循ANSIX9.17标准)，其密钥层次如以下图：三种密钥的层次图各种密钥在密钥层次中的作用本地主密钥(LocalMasterKey)又称主机主密钥(MasterKey)，主要用来保护它下一级的区域主密钥(ZoneMasterKey)(银行主密钥(BankMasterKey)、终端主密钥(TerminalMasterKey))。当区域主密钥需要导出或保存到加密机以外时，通常需要用本地主密钥(或衍生的密钥对)加密区域主密钥。区域主密钥中主要有两种，一种是金卡中心与成员行之间的传输密钥(通常称为银行主密钥)，另一种是成员行主机与ATM或POS之间的传输密钥(通常称为终端主密钥)。它主要用来加密下一层次的数据密钥(如：PIK、MAK)。数据加密密钥(DateEncryptKey)又称工作密钥(WorkingKey)，是最终用于加密传输数据的密钥，其上层两种密钥可以称为密钥加密/交换密钥(KeyEncrypt/ExchangeKey，简称KEK)。数据密钥一般分为两种，一种是用来加密PIN的密钥称为PIK(PinKey)，另一种是用来计算MAC的密钥称为MAK(MacKey)。密钥产生本地主密钥通常由各成员行(或下属机构)采用加密机前面板上的键盘或直接通过IC卡注入到加密机中，各成员行的本地主密钥各不相同。一般本地主密钥的注入都由成员行的三位高层领导注入，三人分别保存一局部密钥(密钥分量,Component)，三局部密钥可以在加密机中以一定的算法(异或)合成为最终的本地主密钥(或通过衍生(Derive)生成密钥对)。区域主密钥(银行主密钥)一般由上级机构(金卡中心)产生并分发。上级机构(金卡中心)产生并保存下属机构(各成员行)的区域主密钥(银行主密钥)，同时将密码分量的明文或IC卡的形式将区域主密钥(银行主密钥)下发给下属机构(各成员行)。下属机构〔成员行〕将密钥分量注入到加密机内，如果区域主密钥〔银行主密钥〕是保存到本机构的主机数据库中，那么将区域主密钥〔银行主密钥〕注入到加密机后，加密机显示本地主密钥加密的区域主密钥〔银行主密钥〕密文，由银行工作人员将其录入主机数据库。银行主密钥通常由两人注入，各自保存一局部。区域主密钥中的终端主密钥由各成员行自己注入到加密机中，同时下装到ATM和POS中，由于各成员行的ATM和POS数量都较大，一般是所有ATM和POS共用一个终端主密钥或是一组ATM和POS共用一个终端主密钥。数据密钥分为两种，一般不在加密机中保存。一种是金卡中心与成员行之间的数据密钥，一种是成员行主机与ATM或POS之间的数据密钥。前一种数据密钥可以由金卡中心主动向下分发，也可以由成员行主动向上申请。数据密钥在传输过程中由金卡中心与成员行之间共享的银行主密钥加密，成员行接收到数据密钥后都需要验证其正确性后才会启用新的数据密钥。后一种数据密钥每天由ATM或POS签到申请，由加密机随机产生，并由终端主密钥加密传送。

金卡中心与成员行及其终端(ATM、POS)之间的密钥关系如以下图：金卡中心与成员行及其终端(ATM、POS)之间的密钥关系图上图中各个符号的含义如下：BMK:银行主密钥TMK:终端主密钥PIK1:金卡中心与成员行之间的PIKMAK1:金卡中心与成员行之间的MAKPIK2:成员行与终端(ATM、POS)之间的PIKMAK2:成员行与终端(ATM、POS)之间的MAKDATA:传输的数据〔PIK1〕BMK:被BMK加密的PIK1说明:本地主密钥LMK：LocalMasterKey，本地主密钥，又称为文件主密钥(MDS)、加密机主密钥、主机主密钥，在密钥体系中处于最上层，以明文存储在加密机中，加密保护存储在加密机外的其它密钥。LMK一般为双长度密钥，也有三倍长度密钥。区域主密钥ZMK：ZoneMasterKey，区域主密钥，在RACAL加密机中，指主机与主机间的传输主密钥。在密钥体系中处于中间层，可以通过LMK加密后存储在主机数据库中，也可直接存储在加密机中，一般为双长度，也有单长度和三倍长度密钥。用于主机间动态分发工作密钥时对其进行加密保护BMK：BankMasterKey，银行主密钥，同ZMK，多用于金卡联网，在金卡联网中，有时POS和银行主机之间也使用BMK。MMK：MemberMasterKey，成员行主密钥，同ZMK。多用于金卡联网SMK：SharedMasterKey，共享主密钥，同ZMK.数据加密密钥TMK：TerminalMasterKey，终端主密钥，在RACAL加密机中，指主机与终端ATM/POS间的传输主密钥，在密钥体系中处于中间层，可以通过LMK加密后存储在主机数据库中，也可直接存储在加密机中，现在一般为单长度，也有双长度和三倍长度。PIK：PInKey，PIN密钥，专用于加密保护PIN的工作密钥，在密钥体系中处于最下层，一般通过LMK和ZMK/TMK加密后存储在数据库中，也有直接存储在加密机中的，密钥长度有单长度、双倍长度和三倍长度。在MDS中，当采用动态密钥时，PIK每12小时或每2500笔交易就必须更换一次〔两个条件满足任何一个时更换〕PEK：PinEncryptKey，PIN加密密钥，同PIK。ZPK：ZonePinKey，区域PIN密钥，PIK的一种，专指主机与主机间的PIK。TPK：TerminalPinKey，终端PIN密钥，PIK的一种，专指主机与终端间的PIK。MAK：MacKey，Mac密钥，专用于计算MAC的工作密钥，在密钥体系中处于最下层，一般通过LMK和ZMK/TMK加密后存储在数据库中，也有直接存储在加密机中的，密钥长度有单长度、双倍长度和三倍长度。在MDS中，当采用动态密钥时，PIK每12小时或每2500笔交易就必须更换一次〔两个条件满足任何一个时更换〕DEK：DataEncryptKey，数据加密密钥，专用于加密数据的密钥，在密钥体系中处于最下层，一般通过LMK和ZMK/TMK加密后存储在数据库中，也有直接存储在加密机中的，密钥长度有单长度、双倍长度和三倍长度。在MDS中，当采用动态密钥时，PIK每12小时或每2500笔交易就必须更换一次〔两个条件满足任何一个时更换〕

为了保证密钥的平安分发，根据国际金融界惯例，银行新一代核心业务系统的密钥管理应遵循ANSIX9.17标准，采用三层密钥体系结构。其体系结构如图4所示。核心业务系统的密钥体系结构图在上图中，密钥由上自下逐级提供保护，其中，主机主密钥〔MasterKey，简称MK〕和区域主密钥〔ZMK：ZoomMasterKey〕，属于密钥保护密钥。第一级是主机主密钥〔MK〕，它用来保护区域主密钥〔ZMK〕。第二级是区域主密钥〔ZMK〕，它用来保护总行和省分行之间的数据加密密钥；在第二级，还可以引入终端主密钥〔TerminalMasterKey，简称TMK〕，用来保护本中心管理的终端设备〔如POS或ATM等〕的数据加密密钥。第三级为数据加密密钥DTK，也称工作密钥WK，用来对数据进行加密。

密钥存储总行密钥存放方式总行的加密机中存放有自身主密钥MK、各分行区域主密钥〔包括总行大前置区域主密钥〕ZMK，以及PIN加密存储在主机数据库中的PIN保存密钥。综合前置密钥存放方式总行大前置的加密机中存放有自身主密钥MK、与总行之间的ZMK、与分行大前置之间的ZMK、下属所有终端主密钥TMK，以及与外部机构〔如中国银联〕进行信息交换所需的密钥。分行密钥存放方式分行加密机中存放有自身主密钥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保护〕，即一个DTK只参与一次交易，也可以通过一定量的交易笔数〔如2000笔〕或一定的时间间隔周期〔如2小时〕后更新。应用系统需开发的功能在整个应用系统中，加密机除了自身提供主机主密钥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。以上主要是加密机向应用系统提供的有关密钥保存的函数接口，也即是应用系统所需要开发的功能。

密钥发布和同时密钥发布和同时总行及各分行的主机主密钥MK各地自行产生并保存在加密机中，全行不采用相同的MK，主要是为了降低整个系统的风险，如果全行采用一个相同的主机主密钥，一旦某个地方的主机主密钥发生泄露，那么整个系统的主机主密钥都要全部重新更换，代价太大。区域主密钥ZMK一般由上级机构产生，并通过人工方式分发，并保存在本地加密机中，如总行有各个分行的ZMK，各个分行只有自己的ZMK，主要用于加密分发工作密钥PinKey和MacKey。终端主密钥TMK一般由分行自行产生，分行保存有所管辖的所有ATM/POS的终端主密钥，各个终端仅由自己的终端主密钥，主要用于分发和保存工作密钥PinKey和MacKey。工作密钥WK〔PinKey和MacKey〕全部通过相邻上级机构产生并分发，主要用于对交易数据提供加密保护和交易数据完整性保护。应用系统需开发的功能加密机提供了所有相关的密钥函数接口，应用系统仅需调用加密机的接口就可以实现密钥同时的功能。涉及到的主要函数只有两大类，即密钥的产生以及密钥存储。密钥产生主要有终端主密钥的产生、工作密钥PinKey和MacKey的产生；密钥存储主要有终端主密钥的存储、工作密钥PinKey和MacKey的存储。密钥注销密钥注销主要是通过产生新的密钥来取代旧的密钥，同时将新的密钥通过密钥传输流程，传送到相关往来机构及加密效劳器，验证后，依照约定的日期/时间启用新的密钥。数据密钥在传输过程中由金卡中心与成员行之间共享的银行主密钥加密，成员行接收到数据密钥后都需要验证其正确性后才会启用新的数据密钥。成员行主机与ATM或POS之间的数据密钥，每天由ATM或POS签到申请，由加密机随机产生，并由终端主密钥加密传送。密钥备份本地主密钥在注入加密机时通过IC卡进行备份，当加密机密钥丧失时可用IC卡来恢复。区域主密钥中的银行主密钥及终端主密钥，也可通过IC卡进行备份，当密钥丧失时可用IC卡来恢复。

密钥更换管理方案效劳器密钥同时密钥同时是指效劳器间共用的密钥(尤其是同时型密钥)如何有效而且平安的交换。一般来说，可以使用密钥同时信息交换的方式进行密钥交换。以BANCS与BANCSLink间的共用密钥(口令加密密钥)的更换同时为例，做法如下：首先产生区域主密钥，并存储于密钥IC卡内。再将密钥IC卡内的区域主密钥分别汇入BANCS系统的加密机以及BANCSLink系统的加密机内，作为密钥交换时交换密钥的加密密钥。由BANCS系统定时产生新的共用密钥(效劳器间信息应用加密的密钥)，并发送密钥更换通知信息给BANCSLink系统。此信息中存放以区域主密钥加密过的共用密钥。BANCSLink系统收到密钥更换通知信息后，将信息内的共用密钥以加密机内的区域主密钥解开，并同时存储与加密机内。再发回密钥更换确认信息给BANCS系统。BANCS系统收到密钥更换确认信息后，确认双方密钥更换同时完成，即可开始使用新的共用密钥加密。加密存储数据移转方案当用户加密存储于数据库内敏感性数据的密钥需要变更时，除了变更密钥外，尚必须对数据库内的密钥加以转换，才能维持数据库内的加密数据的可读性。一般做法如下：首先在加密机内产生新的密钥。利用密钥更换移转程序，将数据库内的加密数据以旧的加密密钥解开，再以新的加密密钥加密。此解密再加密的动作，必须在加密机上一次完成。将新密钥加密后的加密数据更新到数据库中。确认完成所有加密数据的移转后，将加密机内的旧密钥删除。

防病毒管理网络兴旺的便利性，数据传输已无国界与时间的分别；拜网络迅速的便利，病毒的传播非常迅速，非常容易因为文档交换或收发邮件而感染病毒，造成重大的损害，防病毒管理变为平安上的重要环节。病毒传播路径应用效劳器、分行效劳器、柜员终端机及笔记本等电脑设备的微软Windows操作系统经常因收送邮件、交换/复印文档、上网查询或上未知的网站，导致被病毒感染硬盘，破坏文档数据，传播病毒到其他人的电脑，造成重大损害；病毒感染造成的破坏，对金融机构的影响深远，对银行及客户的损害可能无法估计。防堵病毒传播方法为了防止病毒的感染及传播，必须对病毒的传播方式与路径进行防堵，减少感染病毒的时机；柜员终端机及笔记本电脑是最容易被病毒感染及传播病毒的设备，主要是上网及交换/复印文档造成；为了防堵最容易感染病毒的设备，