马来西亚信息科技监管分析报告

1、目录一.二.三.四.五.六.概述3业监管机构介绍4主要 IT 监管要求分析4监管报批报备要求30监管分析31监管处罚及案例分析31附件一：附件二： 附件三：监监度详细内容分析32度汇总32监管报批报备要求32一.概述的信息科技监管要求出发，按照监管机构介绍、主要 IT 监管要求分从析、监管报备报批要求、监管分析、监管处罚及案例分析等六个方面分别进行分析需要考虑的重要 IT和阐述，以提示在推广海外系统的过，中国监管领域和需遵守的重点监管要求，以保证海外系统投产的合规性。报告各方面的内容介绍如下：(1)概述：描述报告的组成形式和各章节的主要内容。(2)监管机构介绍：描述该业的主要监管机构，以及该些

2、监管机构的主要职能。(3)主要 IT 监管要求分析：逐条分析该国发布的重点监管要求，并分别对应到信息科技治理、管理、流程管理、技术管理和合规与审计管理五个 IT 一级领域以及细分的若干领域和三级领域当中，将重点的 IT监管要求在报告正文进行阐述，而在报告附件中展现所有的主要 IT 监管要求。信息科技治理管理流程管理技术管理内部管理业务IT一致性/IT计划主机外来管理开发/外购/部署网络客户管理交付/服务/支持数据/评估/核定终端物理应用合规与审计管理审计管理图 1：信息科技管理的一级领域和领域(4)监管报批报备要求：详细说明金融机构从事信息科技活动时，需要向监管机构报批或者报备的场景和具体的要

3、求。(5)监管分析：阐述监管机构在信息科技监管方面采用的监管以及监管特点，如进驻企业、现场检查、非现场检查、定期/不定期报告等。(6)监管处罚案例：阐述监管机构对监管采用的处罚形式和部分处罚案例。合规管理组织管理管理架构管理制度管理外包管理风险管理管理知识产权二.业监管机构介绍的业信息科技监管机构主要为。（BANK NEGARA MALAYSIA）。在于 1959 年 1 月 26 日正式成立。该法案的下，有，并定期向完全由所财政部报告货币与金融政策的相关事项。的主要职能为对国内货币政策进行管理，同时还兼负维持货币体系及金融体系的稳定性、建立更加健全的金融系统、提高金融体系的包容性等责任，另外

4、，还在担任着财政与金融咨询的。下设监管架构组、发展组、对外与货币政策组、投资与运营组、合规监督组、投资系统组、组等七个大职能组，七大职能组又细分为 39 个职能部门/。其中监管架构组负责确定金融机构的监管架构并将其投入使用。合规监督组负责制定金融机构的安全政策和，并对金融机构的合规情检查，以维持并提升金融机构的运行稳定性和可靠性。主要通过发布信息科技相关的监管条例来对业信息科技治理和运维进行规范，目前发布的监管条例已经能够覆盖基本的信息科技领域。同时，马来西亚还根据当前不断变化的信息科技环境对现有的信息科技监管框架进行持续的完善和补充。三.主要 IT 监管要求分析在 2004 年 4 月颁布的

5、IT 环境管理指引，已覆盖了基本的信息科技治理领域，能够对以下方面：金融机构信息科技实现较为全面的监管，该指引主要包括 IT 治理组织架构 信息系统安全 系统开发 系统运行维护 通讯网络管理 业务恢复与连续性计划此外，还近年来迅速发展的电子业务制定了金融机构电子措施、金融机构的法律及声安全服务指引，该指引从管理层监管责任、安全誉风险、客户保护及安全意识教育和其他合规事项等方面出发，对电子业务管理与操作流程进行了全面的规范，旨在降低 IT 技术快速为电子业务带来的风险外包活动对于金融机构普遍有着较高的风险，为此颁布了运营外包，对外包活动中的高风险事项和报备事项做了较详细的规定，以保证金融机构的安

6、全运营。通过分析和梳理的主要 IT 监管要求，我们从以下五个 IT 一级领域对的重点 IT 监管要求进行详细阐述：在信息科技治理方面提出了较为广泛的原则性要求，包括组织管理管理、架构管理、制度管理、风险管理、外包管理、出了比较详细具体的监管要求。方面。尤其外包管理，提该领域的重点监管要求列举如下：1.1 组织管理1.1.1董事会需要承担 IT 管理的责任，包括但不限于为下述内容负责：1)为 IT 战略的建立提供指引，确保 IT 战略与业务战略的一致性2)审阅及批准机构的关键 IT 政策，确保内控系统和管理信息系统的有效性3)确保层采用了严谨而有效的政策及流程4)确保对交付或接受的 IT 服务建

7、立了关键业绩指标及服务水平协议5)定期审阅管理层报告，对发现的 IT 缺陷提出合理的战略解决方案6)对机构 IT 政策、流程及发布的指引、通告的合规性评估7)监督内外部审计报告，以及检查报告中的审计缺陷情况8)审阅并批准 IT预算1.1.2董事会有责任确保审计师以合理的频率及范围对金融机构进行必要的审计，以保证机构的活动符合监管要求。同时有责任保证审计师的采取必要的跟进及补偿措施。性，对审计发现1.1.3层应对日常 IT 活动进行，其责任包括但不限于以下：1)审阅 IT 政策、计划及预算，并实施 IT 政策和计划2)确保 IT 政策及流程的合理性与有效性，建立风险管理架构3)确保对新建立的或变

8、更后的 IT 系统进行了适当的4)定期向董事会提供管理层报告，并对关键 IT 发现提出意见5)建立并审阅业绩指标，对机构的 IT 服务效果进行评估，确保最终用户部门与 IT 部门，或 IT 部门与外部第提供商间签订了服务水平协议6)确保 IT 运维的效率及有效性，合规性1. 信息科技治理7)确保对审计报告或检查报告中的缺陷采取合理行动1.1.4金融机构应建立由层、IT 部门及最终用户代表组成的 IT 指导委员会，内审代表仅在委员会内承担被咨询的控。委员会应对 IT 计划的开发及实施进行监1.1.5IT 组织架构应实现合理的职责分离，以防止雇员的职责（如开发、运维及安全管理的职责分离），应个人拥

9、有变更、规避及禁用系统安全属性的，应通过其他的补偿措施实施权限。对不能通过职责分离解决的潜在职责管理，并对该措施进行。1.1.6IT 指导委员会应审阅来自不同部门的管理信息，以对 IT进行有效的协调与发生的 IT 活动及，IT 计划的合理进行。委员会应举行定期会议决策，并将重要的决策通知董事会。1.1.7IT 指导委员会应为其成员制定应履行的相关职责，包括但不限于以下方面：1)制定短期及长期 IT 计划并分配预算；2)确保 IT 计划能够支持机构的整体业务战略或整体战略；3)为 IT 项目制定优先级并其与服务水平协议的符合程度；4)制定关键 IT 政策及流程，如 IT 安全政策及 IT 风险管

10、理框架；5)关键 IT 政策的实施有效性；6)IT 服务的整体效率、服务表现、有效性和使用率，识别过时的 IT 服务；7)为 IT 部门及最终用户提供联络；8)在额度内审阅及批准重要 IT 预算及开支；9)审阅时间、人力、培训及设备等分配是否合理1.1.8金融机构应建立 IT 管理组织架构及政策，明确定义各个 IT 功能的职权归属、报告流程及责任划分。理想情况下，IT 部门告。应直接向机构的最理层报1.1.9金融机构应成立正式的项目委员会保证开发在良好的结构下进行，委员会至少以下各方代表组成：1)金融机构层，提供战略方向并对项目全力支持；2)终端用户部门，确保设计的应用满足终端用户的需求；3)

11、内审部门，作为履行职能；方确保安全的实施。但是内审部门只应以咨询者的4)IT 部门，提供技术知识技能1.1.10层应负责制定强的内控系统，应保证其有效性、可操控性以及与业务战略的一致性。同时保证被合理的部署并有效用于维持内控系统的有效性。层还应确认机构已实施了适当的预防性及检测性，保证已包含所有的信息科技活动并能有效支持运维及报告需求。1.1.11安全管理员及系统管理员不应参与系统开发及运维活动，以达到职责分离的目的。若IT 活动实施必要的职责分离，应实施补偿并指定专业的第机构对审阅，确保所有活动被合理并合乎相关的安全标准。1.1.12建立业务连续性计划委员会，并明确该委员会的行为准则。该委员

12、会负责对业务恢复与连续性计划进行、实施和维护。委员会协调人（整个业务连续性项目）和下列部门代表（包括但不限于）组成：1)机构主要业务部门2)IT 部3)内审部（只作为被咨询者）4)质量保证/合规部门5)法务部6)人力部7)安全部8)物业服务部门9)行政服务部门1.2管理1.2.1金融机构应制定 IT 战略计划以提供业务战略所需的 IT 需求。该计划应为支持业务发展的 IT 需求提供实施路线图，并概括出所需的 IT价值。及计划实现后的预期1.3 架构管理1.3.1金融机构应为所有的应用系统制定管理流程并实施此流程，该管理流程应与金融机构的 IT 安全政策保持一致。1.4 制度管理1.4.1政策及

13、流程进行适当的 IT 管理，金融机构应通过制定或降低内部及外部的 IT 风险。悉。层应确保上述政策及流程能被整个金融机构及预期的知1.4.2金融机构应建立正式的系统开发标准、流程以及用户使用手册，确在使用过的连续性。对上述文档实施，确保只有经过的才能以上信息。开发标准及流程包括但不限于以下领域：1)系统设计2)软件分析及选择3)代码编写4)测试5)实施6)变更1.4.3IT 系统安全及管理程，应囊括对所有在用系统的管理，并与 IT 安全政策相一致。、政策及管理实践发生变更该流程。1.4.4董事会及层应确保金融机构建立了电子安全政策及流程，对安全进行预防和应对，以排除内部和外部的安全威胁。1.5

14、 风险管理1.5.1董事会及层应明确金融机构的电子风险偏好并确保电子风险管理流程与金融机构整体风险管理实践的一致性。定期审阅现有政策及流程，确保上述政策与流程能够覆盖电子业务的新型风险。1.5.2董事会及层应识别电子服务的风险因素，并采取风险措施确保电或应用外包子给第或服务的安全性、完整性和可用性，若机构将关，应确保供应商采取了与金融机构类似的保护措施。1.5.3在 ATM 机上的金融机构应根据自身的风险度限制个人额，如：1)设置最大取款额2)设置最大转账额1.6 外包管理1.6.1对于经由第机构获得、实施或外包的重要项目，董事会或委员会在综合分、风险及财务影响等因素后对其进行审批。同时项目应

15、受 IT 指导，包括但不限于以下方面：析成本、委员会的1)所有项目应符合机构的业务战略；2)识别并协调项目的附属活动；3)指定机员或第咨询顾问作为项目经理；4)在执行合同前向具有法律资质的咨询相关法律事宜；5)识别技术与业务风险，并对其进行管理；6)确定分配的优先级，协调分配事项；7)告知利益相关方项目进展情况，并向其征询建议。1.6.2层应完全掌握外包相关的风险。开展适当的尽职，审阅及评估外包活动的可行性、外包商能力、可靠性、专业知识及业绩。对于关键活动，层应考虑备用外包商的可用性以及切换外包商所需的成本和。1.6.3若外包活动需要与供应商敏感信息，金融机构层应评估供应商对敏感信息的保护能力

16、，并对外包活动进行严格，确保上述信息已经被保护。确保外包活动过敏感信息的性、完整性及可用性。1.6.4层应确保正式合同中合理定义了所有相关方的、关系、义务及责任，同时还括（但不限于）外包表现预期、服务水平、可用性、可靠性、可伸缩性、合规性、安全及性、回归流程实施便捷性、连续性计划、审计权责、服务中断事项及机构信息返还事项等。另外，供应商的服务能力、运维表现及财务状况（评估合同中明确此条款）。1.6.5金融机构应与供应商签订具有法律效力的合同，确保合同中定义了金融机构预期中的服务水平。确保对供应商技术及咨询实施了与机构内部员工一致（或更严格）的安全政策与。与雇员签订有效的合同。1.6.6当代码由

17、供应商开发，而未对金融机构公布源代码时，金融机构应通过签订正式的合同进行自我保护。该合同应金融机构在特定情况下源代码，包机构保括但不限于以下情况：供应商中断服务或，此情况下应指定第存程序及相关文档。金融机构应定期确定保存在第新的。机构的源代码是及时更1.6.7金融机构与供应商应签订并执行具有法律效力的合同以保护机构的利益。合同应规定供应商的活动符合最佳业务实践信息的性和完整性、定期提交网络性能表现报告、保证中的网络系统连续性，同时其活动被审计。实施了与机构内若外包运维活动在金融机构处进行，应确保对供应商技术部员工一致（或更严格）的安全政策与。1.6.8层对 IT 运维的管理责任不得因 IT 运

18、维活动的外包而减小或解除，同时层应对 IT 运维的监管及负全部责任。1.6.9层有责任通过运用成本效益方法评估外包活动是否有效支持了机构的业务战略级业务活动。1.6.10若由供应商对系统进行技术支持或运行维护，选择软件时进行需求分析，确保用户及业务需求得到满足。金融机构应对供应商的技术支持能力和财务情评估，确保供应商能顺利执行合同条款。若供应商的财务状况出现异常，应有替代措施减小为金融机构带来的影响。1.6.11若通讯设备从外部服务供应商获得，金融机构应确保与供应商签订正式合同，合同中应明确规定各方与职责和预期服务水平，并包含服务连续性条款（如服务中断的检测及恢复）。合同中的所有条款应被强制执

19、行并定期审阅。1.6.12若网络运维由第制，保护信息的机构执行，金融机构层有责任实施了适当的流程及控性和完整性。在选择供应商时进行适当的分析，保证供应商的财务稳健性和服务水平。1.6.13当由第机构管理灾备设施签订具有法律效力的合同。合同中应明确灾备设施的使用条件，并明确若第机构发生受影响时，第机构应机构客金融机户的安置措施。在金融机构的系统功能完全恢复前，第构使用其灾备设施。1.6.14外包合同中应规定供应商在外包活动中应遵守相关的职业规范，还应明确外包商的和职责。1.6.15外包合同中应规定，若外包商无法按照合同中的强制条款履行合约，终止外包合同。1.6.16应采取适当的报告和措施，确保外

20、包商服务的质量和完整性。1.6.17应定期测试并审阅外包商已完成的工作，外包商应定期向管理层报告外包活动进展。1.6.18的连续性计划中必须具有应对供应商服务终止的措施。应定期审阅该计划，以确保其时效性并能应对供应商突然中止服务的情况。该计划还应经过董事会的批准。1.6.19与外包商签订外包合同前，应至少提前两周向报告(供应提交外包活动满足应至少在与新外包商签订合商名称、地址及所外包的功能）。应向本制度条款的承诺书。若外包商有任何变动，同两向报告。1.7管理1.7.1层有责任为机构所有的信息资产指定其所有者，并清晰界定信息资产的所有关系及责任归属。1.8 知识产权管理暂无明确要求。在管理方面有

21、着较详细的管理要求，包括内部管理及客户管理两方2.管理面，其中电子业务的客户管理是其监管的重点领域。该领域的重点监管要求列举如下：2.1 内部管理2.1.1层有责任确保机构 IT 人力IT的充足性，具有适当的资质、经验及知识技能。同建立适当的轮换计划。2.1.2层有责任确保对 IT完成工作。为所有级别的实施了适当的培训，帮助更有效率的培训计划。制的培训计划，并2.1.3层应确保员工在行使工作职责时保持职业态度，不工作中获取的信息并对上述信息进行。确保员工在工作过遵守全部使用的。2.1.4金融机构应定期举行安全意识培训，提高员工对于责任的理解。政策、流程及安全2.1.5金融机构应委派安全管理员及

22、系统管理员负责安全职能的执行及安全政策标准的实施。2.1.6金融机构应审阅并实施适当级别的职责分离安全，确保：1)没有个人或供应商能够同时开启、和完成一个2)对静态数据的初始化和有效性验证实施职责分离3)对电子系统的开发者和管理者实施职责分离2.1.7任何个人不应独自具有关键安全离：的物理权限或逻辑权限，下列职责应被分1)2)管理3)与核对2.1.8网络运维应理解机构的，并具有处理错误、异常和紧急情况的必要技能。金融机构应具有可理解的流程文档，帮助上述网络管理工作。更有效的进行2.1.9系统中的用户分组及配置应与用户岗位分配及职责相适应。IT 部门及非 IT 部门的员工不应处于类似的系统分组中

23、。2.2 外来管理暂无明确要求。2.3 客户管理2.3.1金融机构应采取积极的措施和有效的方法及时通知客户以下事项：1)电子服务以及用的潜在风险2)客户在电子施安动中的，以及防止盗用应采取的安全措3)账号、认证码、多因素认证信息及其他认证工具信息防泄漏的重要性，包括不向金融机构员工及监管方透露上述信息4)、邮件、或互联网上个人信息防泄漏的重要性，客户在提供上述信息签订合同或了解对手5)客户收到假称来自或其他可疑金融机构的邮件或采取的措施6)客户的权利和责任7)阅读金融机构以及相关第机构隐私政策的重要性8)定期阅读金融机构发布的信息及安全警告的重要性2.3.2金融机构应采取积极的措施对客户进行电

24、子安全培训。同采取必要的措施对非电子客户（电子潜在客户）进行培训。2.3.3金融机构应确保所有向客户提供有效的咨询服务。了解盗取的潜在风险，并在发生时能够2.3.4金融机构有责任采取所有可能的措施告知客户必要的电子相关事项。2.3.5金融机构应尽可能向客户提供透明、清晰的电子用、违约处理办法和相关利益率信息。客户应能够与服务特性，以及费、打印并保留所有合同。2.3.6金融机构在对电子条款进行增加客户费用或责任的调整，以及在进行其他关键性变更给予客户足够的时间令客户是否继续使用该服务。2.3.7电子服务条款中应明确金融机构和客户的责任、的责任认定、条款更改通知程序、投诉处理信息以及与解决流程。2

25、.3.8金融机构与客户签订的合同中应明确双承担的风险责任，客户不应为非自身产生的损失负责。2.3.9只有在客户要求的情况下，金融机构才能为客户开通会增加客户花销的电子银行新或服务。2.3.10金融机构应具有指引中的原则。问题的争议解决办法，争议解决应遵循投诉处理2.3.11金融机构不应向客户转嫁风险管理和内控水平提升过的任何成本。2.3.12金融机构应确保客户知悉机构的隐私保护政策及电子私事项。和服务的相关隐2.3.13客户应拥有客户接受电子金融机构向第服务的权限。机构提供其信息的选择权，该选择不应影响2.3.14金融机构应将会话超时时所做的重复金额偿还给客户。2.3.15在登录系统显示误用系

26、统信息或设备的警告。在流程管理方面对 IT 系统开发测试、运维服务、各个方面都进行了比较详细的规定。尤其是对于系统运维中的业务连续性管理、灾备管理、应急管理、口令管理、密钥对业务运营安全有着影响的领域，有着较详细的监管条款。该领域的重点监管要求列举如下：3.1 开发/外购/部署管理3.1.1金融机构开发前进行可行性研究，确开发预期成本及，并决定选择内部开发或从供应商处获取。若决定将应用开发外包，金融机构层对应用设计水平所负有的责任不应有任何减少。层应确保软件开发外包活动已采取了必须的以满足金融机构的相关标准。3.1.2在开发或外购新系统前，金融机构应定义清晰的安全需求。并对新系统进行审阅，保证

27、其安全性与易用性的平衡。3.1.3层有责任确保开发或外购的 IT 系统合乎机构的最低标准，建立权限级别、异常报告和控。保管等领域的 IT 运维指引，并对该指引实行常态化监3.1.4金融机构应制定项目计划，确保项目目标的达成。应用项目系统对项目完成度进行，比与预订时间表进行对比。定期向管理层报告项目优先级、资源分配、与目标的偏差及预算等信息，以评估项目有效性。3.1.5金融机构应按照正式的测试计划，对预定的数据或系统处理问题及业务场景进试。3.1.6金融机构应对电子系统进试，确保职责分离被绕过3.1.7金融机构应对所有应用实施版本更新。保存旧版本代码及其相关信息（包括日期、时间等信息），同时对存

28、有旧版本源代码的数据库实施严格的保护。版本也可用于确保只有经过的代码才能移植到区和生产环境。3.1.8金融机构应对源代码到目标代码的转换过程进行，确保代码结果的准确性和完整性，减小未变更的风险。3.1.9只有指定的个实施严格的能进行代码转换操作。当使用编译程序或其他系统开发工具并对所有操作进行严密。3. 流程管理3.1.10金融机构应对应用进行上线前审阅，评估应用上线后的运维表现。通过比较计划与实际的成本、没有实现，应确认阅。及开发时间对项目并在上线前评估报告中与否进行评测。若项目计划目标，该报告应提交给层审3.1.11电子系统在设计确保尽量减少客户无意识误操作的可能性，并确保客户完全了解风险

29、。3.1.12终端用户开发的代码、据的完整性、可靠性。及宏在使用前应经过批准和测试，以保证应用和数3.2 交付/服务/支持管理变更管理3.2.1建立正式的程序变更管理流程，执行该流程并做适当的。对变更进行和审批，明确定义程序迁移过的签字确认，以供事后问责需要。的个人责任。在正式过应进行必要3.2.2接受变更申请前，确定变更方法、变更成本及代码编写所需时间。系统分析分析变更的影响及变更有效性，并确定所有重要变更的优先级。3.2.3金融机构应确定并变更状态跟进报告。申请变更的。定期向管理层提交正式的问题分析及3.2.4变更实施前，金融机构应适当的制定并过最终用户的签字确认。测试计划，测试结果需在上

30、线前经3.2.5金融机构应实施适当的网络变更管理措施，确保网络变更中信息的可用性、保密性和完整性。对于影响网络系统和通讯设备的变更，应执行正式的、记录及批准流程。在执行变更前，应对变更进试并评估其影响。3.2.6对电子服务进行升级前，金融机构应最晚在实施两向银行报告相关情况，并提交以下信息：1)升级及描述2)影响分析及风险管理实践3.2.7金融机构对电子服务进行升级遵循以下准则：1)在通知符合央行的所有要求；之后的 21 天内向央行提交了所有所需的信息，并2)若央行认为服务升级提高了客户的风险，且机构未采用满足央行要求的风险管理方法，则对电子服务进行升级。3.2.8金融机构应具有适当的变更政策

31、，防止错误或无意识的变更对安全或数据完整性与可靠性产生影响。管理3.2.9机构应具备有效识别与解决网络的流程，最小化对业务的影响并减小类似发生的风险。3.2.10金融机构应建立相关风险。响应机制，对与进行识别及评估，同时声誉3.2.11金融机构应不同场景、业务和地理位置制定应急响应计划，确保电子系统及服务能够在发生后及时恢复。场景分析括发生的可能性和的影响。应急计划中应综合考虑将电子外包给第供应商的注意事项。金融机构应定期审阅并完善响应计划。3.2.12金融机构响应计划中包含业界认可的响应流程，包括及时向马来西亚相关监管机构报告的流程。3.2.13金融机构应具备经过良好培训的响应团队，该团队紧

32、急中享有决，并对内部和外部机构有着清晰的指挥路径。3.2.14金融机构响应过应具备相关的法务团队，该团队应与机构和其他响应团队保持良好，遏制虚假的发生并消除其不利影响。3.2.15金融机构应具有以下响应流程或措施：1)应对外部市场与的策略2)及时将告知股东的通报流程3)及信息收集流程，用于进行损失审阅。用户管理3.2.16金融机构应建立适当的用户账号废弃流程，当用户离开机构或调转到不需要现限的岗位应提前设置好该用户的过期时点，同时按照指定的时间表将离职用户目录下的所有文件删除。3.2.17当用户账号 30 天未进行活动时，金融机构应暂时冻结或删除上述账号。以减少未个人的带来的风险。3.2.18

33、金融机构应确保令牌只用于站点，且用户了解使用令牌时负有的安全责任，包括使用、保护及替换的规则。对用户持有的令牌实施正式的过期、更新及废弃流程。3.2.19金融机构系统运维环境中实施不相容职责分离流程，并实施安全，限制操作员过高的程序权限，未的操作发生。3.2.20金融机构应创建并维护电子系统的安全设置，为所有用户（包括客户、金融机构内部用户及供应户）分配权限必须经过批准。设计适当的，确保不相容职责已被分离。3.2.21金融机构应确保对电子以外的活动进行，如密钥权限3.2.22金融机构应采取适当的用进行保护，检测并防止未措施，对电子的发生。关、服务器、数据库和应3.2.23金融机构应确保没有个人

34、拥有更改权限的能力。电子数据库中任对该过程进何用户的增加和权限的变更应被指定的者适当的，同行合理的并保存审计痕迹。3.2.24金融机构应定期审阅否必要。用户并对其重新。重新评估所限是性能和容量管理3.2.25层应确及其他运维性能及的高可用性以维持公众对金融机构的信息，保证硬件、软件能够持续交付可靠的服务。口令管理3.2.26金融机构应使用管理系统确保加密适量，当用户创建动检查长度，长度不应少于 6 位。3.2.27应对复杂度做出要求，可由数字、符号、大小写字母或记忆术（短语、诗句或歌曲中每个词的首字母）组成。3.2.28在键入以其他符号隐藏真实的，对的或传输中的。实施高度保护措施（如进行加密）

35、并防止对未3.2.29为安全管理员创建的账户分配（初次登陆后过期），计算机或通信设备的默认初始化后立即修改。3.2.30系统应能够在使用 90 天后强制用户修改，或有用的可能时，用户应及时修改码。系统应限制用户重复使用指定期间内使用过的密3.2.31超级用户应分为两部分并由不同的保管，应尽量减少超级用户的使用，且使用必须经过适当的，并在指定区域的终端上进行。采取措施保证超级用户封的安全保存。密钥管理3.2.32 可应用公共密钥设施（PKI）对雇员及合作伙伴进行认证，并对客户的电子进行。当应用 PKI 认证但不限于）：，机构应确保满足以下安全需求（包括1)在安全生效前检查数字和密钥的合理性；2)

36、为设置合理的有效期，在过期后应评估密钥长度和加密算法的有效性，在再次生效前根据需要对密钥长度和加密算法进行变更；3)在进行前检查撤销列表，确保数字的有效性；4)定义撤销的情景，如客户密钥用或用户账号已注销；5)在数据库中对已被撤销的进行定时状态更新，最好可以实；6)确保对根密钥实施了严格的安全保护措施；7)定期进行审计，确保已实施了合理的安全、公钥与私钥长度合理、模块的设计符合业界标准，并已对认证中心的系统进行了保护；8)保存认证中心系统所有安全的审计日志，包括对根密钥的使用；9)定期审阅认证中心的异常报告及其雇员的系统活动，防止的发生；破坏和未10)确保机构的数字及认证系统符合被广泛接受的

37、PKI 技术标准，确保机构的安全与其他认证中心的兼容性。3.2.33密钥的使用应经过密钥。，以防止员工在加密文件或删除密钥的可读版本后丢失3.2.34在设计密钥系统分离及双人密钥保证没有个人能够掌握密钥的全部信息，这可以通过职责实现。应定期修改密钥。3.2.35使用密钥确保雇员删除密钥的唯一可读版本（除非已确认能够再次恢复可读性版本），防止密钥丢失导致的敏感信息丢失。业务连续性管理3.2.36层应确保定义了业务恢复优先级、采取了风险减缓措施，且连续性流程已经过测试及演练。另外，应定期评估、更新及测试恢复计划和响应流程。3.2.37层有责任确保机构有正式的业务恢复及连续性计划，当测试。该计划已被

38、适3.2.38董事会及层应直接参与到业务恢复与连续性计划（BRCP）中。层应了解系统中断对财务及运维造成的致命影响，并尽力支持及执行业务恢复及连续性计划。BRCP 应经过董事会审批并被金融机构正式实施。3.2.39根据金融机构的业务风险及解决方案制定业务连续性策略并提交给管理层，该策略括 BRCP 项目结构、报告需求、初始成本及后续成本预计。同制定连续性计划，确保机构关键业务及 IT 人力满足需求。3.2.40当 BRCP减小。任务外包给外部咨询师时，层确保计划设计质量的责任不应3.2.41BRCP 应确定关键业务流程并支持关任务的运行。应对关键信息系统失效的影响及由供应商、业务伙伴提出的机构

39、关键业务风险进行评估。3.2.42对各关进行业务风险及影响分析。根据各业务风险发生概率及影响程度，识别并确定业务风险等级。BRCP 应集中关注最大风险或关键业务可能出现的最坏场景。3.2.43对已识别出的所有可能中断采取适当连续性及恢复测试，该策略的制定应依据关键业务的恢复优先级并与业务影响分析的结果想一致。应考虑可实践性、成本效益等因素选择最适合金融机构的连续性及恢复策略，并将其在文件中。3.2.44业务连续性计划应明确启动条件，宣布人及计划启动审批管理，包括：备份站点启动条件及通知流程、计划团队成员、供应商、服务提供商及合作机构（包括母公司）。该计划还划的具体行动。括团队成员职责、人计划、

40、应急流程和计3.2.45应对 BRCP 进试，评估该计划能否有效支持金融机构的关键业务，并在明确的时间内完成。以确保恢复团队成员及其他相关身的职责且熟悉 BRCP 中的流程。被适当的培训，了解自3.2.46对 BRCP 至少每年进行一次测试，IT 连续性计划至少每年进行两次测试，并至少进行一次实际演练。3.2.47为业务连续性计划制定正式的、文档化的测试计划和测试标准，使用实际模拟及一系列活动进试。测试之前确定测试目标，所有测试应使用恢复设施、备份系统和离线数据备份文件。3.2.48内审部门应观察整个业务连续性测试过程，并报告测试中发现的缺陷。3.2.49金融机构应通过检查测试结果的准确性和一

41、致性，确认对每个连续性计划的有效性。金融机构每个连续性计划满足以下条件：1)能够通过备用业务流程管理、和跟踪2)系统失效时个别的人工活动和备用业务流程可满足业务的最低需求3)对备用业务流程的关键部分实施质量性，确保备用数据库的完整性和稳定4)保证备用数据提取系统及其所提取数据的安全5)定义备用数据库需求，以及数据库从灾备环境切换到正常生产环境的措施6)在数据库层面调整灾备环境与正常生产环境的所有差异，确保一致性3.2.50建立业务连续性计划测试结果分析报告、反馈及审阅流程，将测试结果与预订结果对比，以确保测试的完整性、识别测试过正措施。发现的问题及采取相应的更3.2.51业务连续性计划测试结果

42、分析报告应提交给管理层，并向报备，报备内容参见附录或报备要求。3.2.52BRCP 不应被视为一个静态的文档，应持续对其进行审阅、更新并使其生效。金融机构应执行正式的 BRCP 审阅、再评估及更新流程，确保其有效性。3.2.53业务连续性计划测试过发现的缺陷和问题应被解决与更新，恢复更新周期括系统、软件、应用、通讯和运维变更。必要，金融机构应执行重复测试，保证问题再次发生以及更新的计划满足业务连续性需要。3.2.54更新的业务连续性计划副本应上报至相关机构，并被离线储存，确保在发生时该计划能被灾备及时。3.2.55金融机构在制定全部业务的连续性和应急计划和覆盖电子系统和服务，包括适当的备份设备

43、、定期测试和处理性能审阅，以保证电子银能够适应不同的量。系统性能与容量应与机构未来电子长相一致。增3.2.56金融机构应确保电子系统的业务连续性与应急计划被定期测试（根据系统关键性和停机度确定频率），并明确系统恢复过对第供应商或其他外部机构的依赖。灾备管理3.2.57为应对整个数据中心或数据中心部分区域功能的失效，金融机构应具备备用的运维。可建立异地灾备站点、将恢复职能外包给第机构或使用前两者综合的解决方案。3.2.58不论采用异地灾备站点或将外包准则：恢复职能外包，金融机构至少应遵循以下1)恢复系统与机构关键应用兼容2)灾备设施应与数据中心保持适当距离，以防相同。在确定灾备中心地点时还应考虑

44、设施及应用及恢复时间。建议灾备中心与数据中心使用不同的供电和通讯网络3)根据数据中心系统配置和金融机设置。RCP 的要求及灾备中心设施的3.2.59当由第机构管理灾备设施签订具有法律效力的合同。合同中应明确灾备设施的使用条件，并明确若第机构发生受影响时，第机构应机构客金融机户的安置措施。在金融机构的系统功能完全恢复前，第构使用其灾备设施。备份与恢复管理3.2.60 金融机构应确保备份介质的创建及管理符合IT 环境指引性计划部分的最低要求。务恢复及连续3.2.61金融机构应确保对业务信息、软件和相关纸质文档进行了充分的备份，确保在关键运维恢复过能够及时获得上述信息。同对上述信息或文档进行适备份文

45、件。当的离线备份，并根据生产环境中的变更及3.2.62金融机构应对备份介质环境进行，强度应与主站点一致，并符合制造商的安全建议。备份站点应与主站点保持一定距离，以防被同一影响，同时还应保持合理的应用恢复时间。3.2.63金融机构应定期进序、系统工具和备份，包括但不限于：最新版操作系统、生成程文件。根据重要性确定各系统的备份频率，但发生变更和修改时必须进行备份。3.2.64所有的备份介质应被清晰标识，标识括（但不限于）：用途、日期和保存期限。定期清点所有备份介质，并进行恢复测试，下数据恢复的可靠性。条件，还应测试紧急情况3.2.65金融机构应及时对所有离线备份介质进行体系化的更新。在备份介质的过

46、保护介质的安全，介质的应被和。实施备份介质流程。生产环境管理3.2.66金融机构应对生产环境实施严格，防止未。供应商或程序员需要生产环境时，为其分配临时账户，当任务完成时立即将临时账户作废。对供应商或程序员的所有活动应被适当并。3.2.67当生产环境的日常维护由供应商进行时，金融机构应确保与供应商签订了具有法律效力的合同。所有的维护活动经过的供应商实施，供应商活动应被并被合理，该应定期向管理层汇报，并用于未来供应商选择、设备基准管理、设备更换决策及设备性能计划。3.2.68开发环境、测试环境和生产环境进行物理将程序路径或程序库分离，并执行严格的。当无条件进行物理。3.2.69对生产环境实施严格

47、，防止未。供应商或程序员需要生产环境时，为其分配临时账户，当任务完成时立即将临时账户作废。对供应商或程序员的所有活动应被适当并。3.3/评估/核定管理3.3.1层应确保有效性以及状况被目标的有效完成。并定期被再评估，以保证政策和流程的持续3.3.2层有责任确保实施了适当的务器进程、使用率）。流程以连续关键活动（系统性能、服3.3.3金融机构应适当所有操作台及系统的活动，并定期由指定的审阅，以确保操作员的操作符合制定的流程，检测未的程序运行或异常操作，确定补偿措施。金融机构应开发或用以生成异常报告的系统。上述异常报告应被定期审阅，并对其实施相应的根据措施。3.3.4金融机构应使用适当的系统对数据

48、中心的括但不限于：进行和管理。活动1)处理器、硬盘和内存的使用率2)问题报告及升级流程3)设备故障4)系统失效的频率及时间跨度5)网络活动，检测可疑趋势及系统尝试上述信息应用于报告层、设备更新及未来性能计划决策。层在影响金融机构的安全问题、系统失效及性能下降等情况出现时，应立即向报告，并两天内向提供正式的报告（参见该制度附录或报备要求）。3.3.5金融机构应确保没有个人拥有更改何用户的增加和权限的变更应被指定的权限的能力。电子者适当的数据库中任对该过程进，同行合理的并保存审计痕迹。在技术管理的数据、应用、终端和网络层面都提出了比较具体的监管要求，尤其是对网络防护、数据防泄漏及数据保护、应用方面

49、的技术要求比较严格。该领域的重点监管要求列举如下：4.1 数据4.1.1金融机构应使用数据字典、规范及数据命名习惯及数据的使用。4.1.2所有连接数据库的请求应被正式批准，限制并维护工具。能够绕过安全的数据库4.1.3使用数据完整性验证技术（如信息认证码和散列码技术）确保数据完整性。4.1.4金融机构应为或在网络中传输的敏感/关键信息制定加密政策，进行风险评估以确定加密保护等级，包括但不限于以下：实施成本、风险偏好、加密算法影响/类型/质量以及密钥长度。4.1.5根据电子如加密、系统和数据的敏感性和重要性，对其进行分类。实施合理的方法，及数据恢复计划，对高风险系统、服务器、数据库及应用进4. 技术管理行保护。4.1.6保护金融数据不受未的更改，同时任何数据更改应是可检测的。4.1.7电子数据库应能够防篡改，实施相应的流程检测该类篡改，同时保存足够的审计痕迹，据库替代前不应投入使用。上述篡改。任何