信息系统开发安全管控办法

Q/JYG XXXX单位或公司企业标准

Q/JYG/GL-XX-21-2013a 信息系统开发安全管控办法

2014-10-25发布2014-11-01实施

Q/JYGGL-XX-21-2013a

前言

本标准由XXXX单位或公司标准化管理委员会提出。

本标准由XXXX单位或公司XXXX部门起草并归口管理。

本标准主要起草人：

本标准由批准。

本标准首次发布于2013年8月25号，本次修订为第一次修订。

信息系统开发安全管控办法

1 范围

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

本标准适用于公司自主开发及委外开发信息系统的管理。

2 规范性引用文件

下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注明日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准。凡是不注明日期的引用文件，其最新版本适用于本标准。

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

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

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

3 术语和定义

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

信息系统一般由三部分组成：硬件系统（计算机硬件系统和网络硬件系统）、系统软件（计算机系统软件和网络系统软件）、应用软件（包括由其处理、存储的信息）。

4 职责

4.1 XXXX部门

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

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

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

4.2 卷烟厂计算机中心

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

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

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

4.3 各实施部门或单位

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

5 管理内容与要求

5.1 总体要求

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

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

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

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)更改的程序应考虑以下方面：清晰确认所有的需要更改的应用系统、信息、数据库和相关

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