XXXX商业银行应用系统开发安全管理办法.doc

XXXX商业银行应用系统开发安全管理办法.doc

《XXXX商业银行应用系统开发安全管理办法.doc》由会员分享，可在线阅读，更多相关《XXXX商业银行应用系统开发安全管理办法.doc（9页珍藏版）》请在冰点文库上搜索。

XXXX商业银行应用系统开发安全管理办法

1　范围

本标准规定了信息系统开发阶段、测试阶段、试运行阶段和上线阶段的管理内容与要求。

本标准适用于XXXX商业银行（以下简称：

本行）自主开发及委外开发信息系统的管理。

2　规范性引用文件

下列文件中的条款通过本标准的引用而成为本标准的条款。

凡是注明日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准。

凡是不注明日期的引用文件，其最新版本适用于本标准。

国务院令（第339号）计算机软件保护条例

国务院令（第147号）中华人民共和国计算机信息系统安全保护条例

Q/JYG/GL-SB-16-2013.a《投资项目管理办法》

3　术语和定义

信息系统：

是指由计算机及其相关的配套设备、设施（含网络）构成的，按照一定的应用目标和规则对信息进行采集、加工、存储、传输、检索等处理的人机系统。

信息系统一般由三部分组成：

硬件系统（计算机硬件系统和网络硬件系统）、系统软件（计算机系统软件和网络系统软件）、应用软件（包括由其处理、存储的信息）。

4　职责

4.1　科技信息部门

4.1.1　负责本行信息系统开发各阶段文档的审批工作；

4.1.2　负责组织本行新开发信息系统的测试工作；

4.1.3　负责本行信息系统上线与终止的验收工作。

4.2　各实施部门或单位

4.2.1　负责本行信息系统开发过程中的需求提出、测试及验收等工作。

5　管理内容与要求

5.1　总体要求

5.1.1　信息系统开发须遵循《计算机软件保护条例》、《中华人民共和国计算机信息系统安全保护条例》。

5.1.2　信息系统开发过程中项目单位（承接信息系统开发的单位）须提交相应的安全需求、安全设计、安全测试等资料并经过科技信息部审批，否则不予立项或验收。

5.1.3　信息系统开发范围的变更（增加或缩减）、新技术的使用、新产品或新版本的采用、新的开发工具和环境须经过科技信息部审批。

5.2　信息系统开发生命周期管理要求

5.2.1　系统需求收集和分析阶段

a）技术可行性分析

根据业务上提出的需求，信息系统归口管理部门应从技术开发的角度分析是否现有的技术手段和技术能力是否可以达到业务上要求的系统功能，主要包括：

人员技术能力分析（指本行内的系统开发队伍是否有足够的软件开发的技术能力来完成系统开发的任务，或第三方外包的开发公司是否具有开发应用系统的技术能力）、计算机软件和硬件分析（指本行现有的软件和硬件的性能是否足够满足开发相应的系统的要求）、管理能力分析（指现有的技术开发管理制度和管理流程是否成熟且标准化，是否足够系统开发的要求）。

b）需求可行性分析：

信息系统归口管理部门应对该申请部门所提需求进行可行性分析，以判断需求是否明确，是否符合实际，是否能在一定的时间范围实现。

c）经济可行性分析：

信息系统归口管理部门应根据业务需求和技术手段的分析，确认投资的数额在可控制和可承受的范围内。

d）安全可行性分析：

信息系统归口管理部门应明确该系统的安全建设范围和内容，设定安全性指标要求，合理判定该信息系统是否符合公司的网络及信息安全要求。

5.2.2　设计阶段安全管理

a）单点访问：

任何用户如果希望访问应用系统中的某一个部分，则必须通过统一且唯一的认证授权方式以及流程。

b）人员职责和权限的划分：

系统必须具有基于人员职责的用户授权管理以确保每个用户可以访问到其权利范围内的应用系统部分，也要确保每个用户无法访问其权限范围以外的应用系统部分。

c）保护敏感系统的安全性：

通过将应用系统中敏感信息保存在服务器端以进行集中的加密安全管理，确保客户端系统本身并不能存储任何信息敏感的数据。

d）确保访问层的安全性：

系统在要确保系统模块本身安全性的同时，还需考虑模块与模块之间的通讯的安全性。

模块与模块之间的安全性包括：

应用系统内部模块之间的安全、应用系统内部模块和外部模块之间的安全性，如主机和客户端之间通讯的安全性，服务器和服务器间通讯的安全性，本地系统和异地系统之间通讯的安全性。

e）确保日志管理机制健全：

要求建立可以根据情况自由设置的日志管理机制，即日志纪录的范围和详细程度可以根据需求自行定制，且可实现在应用系统使用过程中进行日志的定制和记录，并保留所有系统开发相关程序库的更新审核纪录。

f）新系统的容量规划:

容量规划是指确定系统的总体规模，性能和系统弹性。

容量规划应充分考虑：

系统的预期存储容量和在给定的周期里面获取生成和存储的数据量；在线进程的数量和估计可能的占用资料；系统和网络的相应时间和性能，即端对端系统；系统弹性要求和设计使用率、峰值、槽值和平均值等；安全措施如加密解密数据对系统的影响等；7*24小时运作要求和可接受的系统宕机次数（维护或者设备更新导致的必须性宕机）。

5.2.3　开发阶段安全管理

a）通用要求

1）输入验证：

在客户机/服务器环境下，系统需进行服务端的验证而禁止客户端的验证（如基于Javascript的验证），并在字符有效性检查之前设置边界检查验证以及环境变量提取数据验证。

2）命名规范：

规范变量、函数的命名；规范程序的书写格式等。

3）SQL语句：

如果应用程序需要连接后端数据库，使用存储过程而不能在代码中使用SQL语句。

4）注释代码：

当应用程序在实际环境中开始应用时，应该删除所有的注释代码。

5）错误信息：

所有为用户显示的错误信息不应暴露任何关于系统、网络或应用程序的敏感信息。

6）URL内容：

对于web应用，不能在URL上暴露任何重要信息，如密码、服务器名称、IP地址或者文件系统路径等。

b）变更要求

1）信息系统归口管理部门应对更改进行严格的控制，在系统开发的每一个阶段（可行性研究、需求分析、设计、编码、测试、培训等）的每一个更改实施前经过评审与授权。

2）信息系统归口管理部门应当建立更改控制审批程序，对更改的申请、评审、测试、批准、更改的计划的提出和实施提出明确要求并严格的实施，确保安全性与控制程序不被损害，确保任何的改动都是经过审批的。

3）更改的程序应考虑以下方面：

清晰确认所有的需要更改的应用系统、信息、数据库和相关的硬件设备；清晰的确认更改的原因（业务上的具体流程和具体的需求或开发上的需求）；由授权的用户提交更改的申请；保留相关的授权登记记录；在正式的实施之前，更改的方案必须经过评审并通过正式的批准；确保授权的用户在实施之前确认并接受更改的内容；确保在实施的过程中，尽量的减少对现行的商务运作系统的影响；确保建立的文件系统在完成各项更改时得到修改，旧文件被很好的归档或处置；保证所有的应用系统升级的版本的控制；确保所有的更改情求的审核跟踪；确保用户使用手册作相应的必要的更改；确保更改的实施选择了适当的时机以确保更改的实施不会干扰正常的商务运作。

c）版本控制要求

1）程序清单：

信息系统归口管理部门应在任何时候对于程序清单必须进行严格的控制并且及时地进行更新；对应用系统开发源程序的打印的资料、电子版本或者是相关的报告都必须进行控制，纸质的文件应当保存在一个安全的环境下，如保险柜等，电子文档则应进行一定的加密；

2）版本升级控制：

当软件的版本由于更新，修改等操作需要升级时，必须先向相关负责人员提交申请；信息系统归口管理部门应对升级的应用系统进行测试，确认系统的各种安全特性；信息系统归口管理部门应确认对应用系统的版本升级，即确认当前的版本为最新版本，旧的版本需进行归档，不得随意丢弃或删除；信息系统归口管理部门应制定相关的升级计划，确保将系统升级对业务的影响降至最低。

d）开发审计：

信息系统归口管理部门应对开发日志及开发人员权限进行每月审核。

5.2.4　测试阶段安全管理

a）测试前安全检测：

信息系统归口管理部门应组织开发人员进行代码审核，检查、消除程序代码潜在的安全漏洞。

b）信息系统归口管理部门应设计详细的测试计划，测试范围，测试方法和测试工具，应充分考虑与其他系统的互操作性测试中对其他系统的影响，选择适当的时间、方法。

并对应用系统存在的弱点威胁进行安全检查，如：

假冒身份、恶意篡改、信息泄露、拒绝服务、特权提升等。

c）信息系统归口管理部门应在测试系统功能正常运行的基础上，还需测试系统的模块和模块之间、功能和功能之间的接口的正确性、负载能力及水平、系统承受压力及峰值、测试环境等。

5.3　开发、测试及验收过程安全指导规范

5.3.1　开发环境安全

a）信息系统归口管理部门应对项目文档、代码的存储进行备份，以确保在发生意外时，可有效恢复；

b）信息系统归口管理部门应对项目文档和代码版本管理和访问控制；

c）信息系统归口管理部门应对用于开发的服务器、个人电脑的配置做好严格的安全防护措施。

5.3.2　文档安全

a）文档内容的安全：

信息系统归口管理部门应对文档内容进行以下几个的规范：

需求说明书中应明确描述应用系统的安全需求；设计说明书中应有针对安全需求的设计，并进行评审；在测试大纲或者测试方案中应有安全性测试方案，并以此进行安全性测试；开发各阶段输出的文档应对安全要求的执行情况进行描述。

b）文档自身的安全：

信息系统归口管理部门应对文档设定密级及读者范围，以限定其访问范围，文档的访问控制应有相应的授权机制。

5.3.3　源代码管理

a）信息系统归口管理部门应根据协议执行源代码的管理，源代码管理应保存所有的历史版本，以便查阅。

b）信息系统归口管理部门应对所有的程序源代码及设置支持文件等打包进行安全检查并存档。

c）对于委托第三方开发的应用系统（或功能、模块等）的代码文件或设置文件，在需要对其进行修改时，必须经过投资装备部批准后，才能交给修改人进行修改。

修改完毕需通过安全检查才可以提交，通过检查后的源代码（或设置文件）提交至科技信息部，由专人进行更新和归档。

d）其他源代码规范：

应用系统需对函数入口参数的合法性和准确性进行检查；应严格遵循Fail-Safe原则，即当发生意外事故时，必须能自动切换到安全的保护模式。

（当应用系统的登录验证机制不能正常运行时，系统必须自动拒绝所有登录请求，而非接受所有登录请求）；应禁止接受不安全的登录密码，并允许系统管理员强制密码设定规则；所有缺省安全设置必须能同时满足系统正常运行和系统安全两方面的要求；在所有警告或提示对话窗口中应使用准确、明了的描述性语言，并提供有关帮助链接；在接受用户输入时，必须有数据合法性检查，并严格规定输入数据的字符长度；在输入密码等敏感信息时，使用特殊符号来代替输入的字符；应禁止使用未经授权和验证的代码，在使用第三方代码时，应对代码安全性进行评估和测试；如密码由应用系统生成，则必须保证有足够的长度和随机性，如密码由用户生成，则应用系统应有密码安全策略来拒绝接受“不安全的”密码；应禁止以明文方式传递用户密码；应测试用的“后门”，应在发布版中去除；应注释代码中无用的代码；应规范代码的格式，并对代码进行版本控制，确保代码的可用性；应禁止在程序中添加隐藏“恶意”的代码，防止与应用系统相关的程序员对系统的非授权修改。

5.3.4　需求分析

a）信息系统归口管理部门应在需求分析阶段确定应用系统的安全要求，并对其进行详细描述，制定项目安全需求说明书，并指导整个项目设计、实现、测试环节。

b）在需求分析阶段应明确以下与安全相关的需求：

用户数、终端数、在线并发数；用户角色的划分和权限的分配；应用系统性能要求；应用系统可用性要求；现有网络现状和网络性能要求；数据量估计、数据存储方式和周期；系统安全级别和数据保密性要求；其他对网络、存储、服务器、终端、操作系统、数据库、数据等方面的安全需求。

5.3.5　应用安全功能设计

a）认证失败处理：

连续失败登录后锁定该帐号，帐号锁定后可由系统管理员解锁，也可以在一段时间后自动解锁，并通知用户认证失败。

b）授权：

应用系统应包含用户权限分配和管理功能设计。

如：

系统读、写、执行权限设计；系统查看、配置、修改、删除、登录、运行等权限设计；数据访问范围的角色设计；应用功能模块使用权限的设计；限制用户对系统级资源的访问，系统级的资源包括：

文件、文件夹、注册表项、ActiveDirectory对象、数据库对象、事件日志的系统资源；程序应使用尽可能小的权限；数据库访问应该使用低权限数据库账号（如选择，删除，更新，插入等）通过参数化的存储过程来访问；应用启动进程的权限尽可能小；应用使用的系统账号（运行环境中的）应该有尽可能低的权限。

应避免“Administrator”,“root”,“sa”,“sysman”,“Supervisor”或其它所有的特权用户被用来运行应用系统或连接到网站服务器，数据库或中间件。

c）输入输出验证：

为了防止攻击者绕过客户端直接验证，在服务器端进行验证时，必须使用服务器端代码执行验证；按照已知的有效类型、模式和范围验证数据；应限制用户输入并验证数据的类型、长度、格式和范围。

d）数据加密：

应用系统应使用公开并且经过验证和测试的加密方法；应避免向算法传递明文数据，并避免修改存储该数据；应确保所使用的密钥长度和密钥空间能提供足够的安全级别；对于大量数据加密，应使用对称的加密，提高加密的速度并减少资源消耗；对于少量存储的敏感数据使用非对称加密，确保数据的安全性；应对密钥的存储进行严格保护。

5.3.6　测试安全

a）信息系统测试人员需明确记录测试目的、安全要点、测试参与人员、测试流程，并编写测试大纲，包括对应用系统的帐号、口令的安全测试；

b）信息系统测试人员需对应用系统的安全功能点进行测试，确保安全功能的有效性、正确性；

c）信息系统测试人员需对对应用系统抵抗攻击的能力进行测试；

d）信息系统测试人员需对数据传输的安全性、物理环境等进行测试，测试数据如选择真实数据，应限定测试的人员，并在测试完成后全部删除和详细记录测试过程中发现的问题。

5.3.7　系统部署安全

a）信息系统归口管理部门应规划应用系统部署需要的资源需求：

应用系统部署的软件、硬件的资源要求；应用系统部署的网络要求；物理链路（光纤、五类线）资源；网络设备资源（HUB、Switch）、上联网络节点端口；IP地址；上联网络带宽；应用系统部署的有关部门、人员要求；其它资源的详细清单。

b）信息系统归口管理部门应确保应用系统部署的环境安全：

确保应用系统部署的硬件安全、操作系统安全；确保应用系统部署的帐号、口令安全；确保符合应用系统部署的安全策略要求（如访问控制）；确保应用系统部署的物理环境安全（如电力）；应了解脆弱的网络或者主机的配置缺陷。

c）信息系统归口管理部门应确保应用系统部署的过程安全：

确保应用系统部署过程的操作安全；对应用系统部署所在的系统进行安全备份；只对部署所需要的帐号提供最小的访问权限，防止进行其它与部署无关的活动；部署的过程应有业务人员在场，对部署的操作需要经业务人员的确认；对部署的操作过程应进行记录；应确保应用系统部署过程的安装安全。

d）应用系统部署的其它安全问题：

记录应用系统部署的详细过程；应用系统部署的时间进度安排；分析应用系统部署可能存在的风险，并制定风险规避方案；明确所有参与人员的工作职责；与所有参与人员签订保密协议，禁止泄漏部署有关的重要内容。

e）信息系统归口管理部门需明确应用系统部署后的升级验收标准，并在验收之前做系统测试（如系统联通性测试），管理员应确保应用系统的验收标准和要求得到清楚地定义、记录和测试。

管理员还应考虑以下的管理措施：

性能和计算机容量需求；错误恢复和重新启动程序及意外事故的处理计划；有效的人工操作程序；业务连续性安排；证明新应用系统的安装不会对现有系统有负面影响，尤其是在高峰处理时段；证明已经考虑到新系统对该组织整体安全性的影响；应用系统的操作使用手册；安排人员培训。

5.3.8　日志设计

a）日志的内容应尽可能详细、准确，但应平衡性能要求。

应为日志文件设计不同的详细程度供系统管理员或用户选择。

b）为日志文件设计输出界面，允许以不同的格式输出日志文件或允许直接输出日志文件到数据库。

c）日志文件中的每条数据记录应要求有日期和时间（精确到秒）。

d）应利用操作系统或其他监控系统的日志文件对应用系统在发生异常时提供日志记录。

6.其他

6.1本管理办法由科技信息部负责解释和修订。

6.2本管理办法自发布之日起施行。