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

1、XXXX商业银行应用系统开发安全管理办法1范围本标准规定了信息系统开发阶段、测试阶段、试运行阶段和上线 阶段的管理内容与要求。本标准适用于XXXX商业银行（以下简称：本行）自主开发及委 外开发信息系统的管理。2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是 注明日期的引用文件，其随后所有的修改单（不包括勘误的内容）或 修订版均不适用于本标准。凡是不注明日期的引用文件，其最新版本 适用于本标准。国务院令（第339号）计算机软件保护条例国务院令（第147号）中华人民共和国计算机信息系统安全保护 条例Q/JYG/GL-SB -16-2013.a投资项目管理办法3术语和定义信息系统：是指由计算机及其相关的配套设备、设施（含网络） 构成的，按照一定的应用目标和规则对信息进行采集、加工、存储、 传输、检索等处理的人机系统。信息系统一般由三部分组成：硬件系统（计算机硬件系统和网络 硬件系统）、系统软件（计算机系统软件和网络系统软件）应用软件 （包括由其处理、存储的信息）。4职责4.1科技信息部门4.1.1负责本行信息系统开发各阶段文档的审批工作；4.1.2负责组织本行新开发信

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）技术可行性分析根据业务上提出的需求，信息系统归口管理部门应从技术开发的 角度分析是否现有的技术手段和技术能力是否可以达到业务上要求 的系统功能，主要包括：人员技术能力分析（指本行内的系统开发队 伍是否有足够的软件开发的技术能力来完成系统开发的任务，或第三 方外包的开发公司是否具有开发应用系统的技术能力）、计算机软件 和硬件分析（指本行现有的软件和硬件的性能是否足够满足开

3、发相应 的系统的要求）、管理能力分析（指现有的技术开发管理制度和管理 流程是否成熟且标准化，是否足够系统开发的要求）。b）需求可行性分析：信息系统归口管理部门应对该申请部门所提需 求进行可行性分析，以判断需求是否明确，是否符合实际，是否能在 一定的时间范围实现。c）经济可行性分析：信息系统归口管理部门应根据业务需求和技术 手段的分析，确认投资的数额在可控制和可承受的范围内。d）安全可行性分析：信息系统归口管理部门应明确该系统的安全建 设范围和内容，设定安全性指标要求，合理判定该信息系统是否符合 公司的网络及信息安全要求。5.2.2设计阶段安全管理a）单点访问：任何用户如果希望访问应用系统中的某一个部分，则 必须通过统一且唯一的认证授权方式以及流程。b）人员职责和权限的划分：系统必须具有基于人员职责的用户授权 管理以确保每个用户可以访问到其权利范围内的应用系统部分，也要 确保每个用户无法访问其权限范围以外的应用系统部分。c）保护敏感系统的安全性：通过将应用系统中敏感信息保存在服务 器端以进行集中的加密安全管理，确保客户端系统本身并不能存储任 何信息敏感的数据。d）确保访问层的安全性：系统

4、在要确保系统模块本身安全性的同时， 还需考虑模块与模块之间的通讯的安全性。模块与模块之间的安全性 包括：应用系统内部模块之间的安全、应用系统内部模块和外部模块 之间的安全性，如主机和客户端之间通讯的安全性，服务器和服务器 间通讯的安全性，本地系统和异地系统之间通讯的安全性。e）确保日志管理机制健全：要求建立可以根据情况自由设置的日志 管理机制，即日志纪录的范围和详细程度可以根据需求自行定制，且 可实现在应用系统使用过程中进行日志的定制和记录，并保留所有系 统开发相关程序库的更新审核纪录。f）新系统的容量规划:容量规划是指确定系统的总体规模，性能和系 统弹性。容量规划应充分考虑：系统的预期存储容量和在给定的周期 里面获取生成和存储的数据量；在线进程的数量和估计可能的占用资 料；系统和网络的相应时间和性能，即端对端系统；系统弹性要求和 设计使用率、峰值、槽值和平均值等；安全措施如加密解密数据对系 统的影响等；7*24小时运作要求和可接受的系统宕机次数（维护或 者设备更新导致的必须性宕机）。5.2.3开发阶段安全管理a） 通用要求1）输入验证：在客户机/服务器环境下，系统需进行服务端的验 证

5、而禁止客户端的验证（如基于Javascript的验证），并在字符有 效性检查之前设置边界检查验证以及环境变量提取数据验证。2）命名规范：规范变量、函数的命名；规范程序的书写格式等。3）SQL语句：如果应用程序需要连接后端数据库，使用存储过程 而不能在代码中使用SQL语句。4）注释代码：当应用程序在实际环境中开始应用时，应该删除所 有的注释代码。5）错误信息：所有为用户显示的错误信息不应暴露任何关于系 统、网络或应用程序的敏感信息。6）URL内容：对于web应用，不能在URL上暴露任何重要信息，如 密码、服务器名称、IP地址或者文件系统路径等。b）变更要求1）信息系统归口管理部门应对更改进行严格的控制，在系统开发 的每一个阶段（可行性研究、需求分析、设计、编码、测试、培 训等）的每一个更改实施前经过评审与授权。2）信息系统归口管理部门应当建立更改控制审批程序，对更改的 申请、评审、测试、批准、更改的计划的提出和实施提出明确要 求并严格的实施，确保安全性与控制程序不被损害，确保任何的 改动都是经过审批的。3）更改的程序应考虑以下方面：清晰确认所有的需要更改的应用 系统、信息、数据库和相关的

6、硬件设备;清晰的确认更改的原因（业 务上的具体流程和具体的需求或开发上的需求）；由授权的用户 提交更改的申请；保留相关的授权登记记录；在正式的实施之前， 更改的方案必须经过评审并通过正式的批准；确保授权的用户在 实施之前确认并接受更改的内容；确保在实施的过程中，尽量的 减少对现行的商务运作系统的影响；确保建立的文件系统在完成 各项更改时得到修改，旧文件被很好的归档或处置；保证所有的 应用系统升级的版本的控制；确保所有的更改情求的审核跟踪； 确保用户使用手册作相应的必要的更改；确保更改的实施选择了 适当的时机以确保更改的实施不会干扰正常的商务运作。c）版本控制要求1）程序清单：信息系统归口管理部门应在任何时候对于程序清单 必须进行严格的控制并且及时地进行更新；对应用系统开发源程 序的打印的资料、电子版本或者是相关的报告都必须进行控制， 纸质的文件应当保存在一个安全的环境下，如保险柜等，电子文 档则应进行一定的加密；2）版本升级控制：当软件的版本由于更新，修改等操作需要升级 时，必须先向相关负责人员提交申请；信息系统归口管理部门应 对升级的应用系统进行测试，确认系统的各种安全特性；信息系

7、统归口管理部门应确认对应用系统的版本升级，即确认当前的版 本为最新版本，旧的版本需进行归档，不得随意丢弃或删除；信 息系统归口管理部门应制定相关的升级计划，确保将系统升级对 业务的影响降至最低。d）开发审计：信息系统归口管理部门应对开发日志及开发人员权限 进行每月审核。5.2.4测试阶段安全管理a）测试前安全检测：信息系统归口管理部门应组织开发人员进行代 码审核，检查、消除程序代码潜在的安全漏洞。b）信息系统归口管理部门应设计详细的测试计划，测试范围，测试 方法和测试工具，应充分考虑与其他系统的互操作性测试中对其他系 统的影响，选择适当的时间、方法。并对应用系统存在的弱点威胁进 行安全检查，如：假冒身份、恶意篡改、信息泄露、拒绝服务、特权 提升等。c）信息系统归口管理部门应在测试系统功能正常运行的基础上，还 需测试系统的模块和模块之间、功能和功能之间的接口的正确性、负 载能力及水平、系统承受压力及峰值、测试环境等。5.3开发、测试及验收过程安全指导规范5.3.1开发环境安全a）信息系统归口管理部门应对项目文档、代码的存储进行备份，以 确保在发生意外时，可有效恢复；b）信息系统归口管理部

8、门应对项目文档和代码版本管理和访问控 制；c）信息系统归口管理部门应对用于开发的服务器、个人电脑的配置 做好严格的安全防护措施。5.3.2 文档安全a）文档内容的安全：信息系统归口管理部门应对文档内容进行以下 几个的规范：需求说明书中应明确描述应用系统的安全需求；设计说 明书中应有针对安全需求的设计，并进行评审；在测试大纲或者测试 方案中应有安全性测试方案，并以此进行安全性测试；开发各阶段输 出的文档应对安全要求的执行情况进行描述。b）文档自身的安全：信息系统归口管理部门应对文档设定密级及读 者范围，以限定其访问范围，文档的访问控制应有相应的授权机制。 5.3.3源代码管理a）信息系统归口管理部门应根据协议执行源代码的管理，源代码管 理应保存所有的历史版本，以便查阅。b）信息系统归口管理部门应对所有的程序源代码及设置支持文件等 打包进行安全检查并存档。c）对于委托第三方开发的应用系统（或功能、模块等）的代码文件 或设置文件，在需要对其进行修改时，必须经过投资装备部批准后， 才能交给修改人进行修改。修改完毕需通过安全检查才可以提交，通 过检查后的源代码（或设置文件）提交至科技信息部，由专

9、人进行更 新和归档。d）其他源代码规范：应用系统需对函数入口参数的合法性和准确性 进行检查；应严格遵循Fail-Safe原则，即当发生意夕卜事故时，必须 能自动切换到安全的保护模式。（当应用系统的登录验证机制不能正 常运行时，系统必须自动拒绝所有登录请求，而非接受所有登录请 求）；应禁止接受不安全的登录密码，并允许系统管理员强制密码设 定规则；所有缺省安全设置必须能同时满足系统正常运行和系统安全 两方面的要求；在所有警告或提示对话窗口中应使用准确、明了的描 述性语言，并提供有关帮助链接；在接受用户输入时，必须有数据合 法性检查，并严格规定输入数据的字符长度；在输入密码等敏感信息 时，使用特殊符号来代替输入的字符；应禁止使用未经授权和验证的 代码，在使用第三方代码时，应对代码安全性进行评估和测试；如密 码由应用系统生成，则必须保证有足够的长度和随机性，如密码由用 户生成，则应用系统应有密码安全策略来拒绝接受“不安全的”密码； 应禁止以明文方式传递用户密码；应测试用的“后门”，应在发布版 中去除；应注释代码中无用的代码；应规范代码的格式，并对代码进 行版本控制，确保代码的可用性；应禁止在程序中添加隐藏“恶意” 的代码，防止与应用系统相关的程序员对系统的非授权修改。5.3.4需求分析a）信息系统归口管理部门应在需求分析阶段确定应用系统的安全要 求，并对其进行详细描述，制定项目安全需求说明书，并指导整个项 目设计、实现、测试环节。b）在需求分析阶段应明确以下与安全相关的需求：用户数、终端数、 在线并发数；用户角色的划分和权限的分配；应用系统性能要求；应 用系统可用性要求；现有网络现状和网络性能要求；数据量估计、数 据存储方式和周期；系统安全级别和数据保密性要求；其他对网络、 存储、服务器、终端、操作系统、数据库、数据等方面的安全需求。5.3.5应用安全功能设计a）认证失败处理：连续失败登录后锁定该帐号，帐

《XXXX商业银行应用系统开发安全管理办法》由会员夏**分享，可在线阅读，更多相关《XXXX商业银行应用系统开发安全管理办法》请在金锄头文库上搜索。