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

信息系统开发安全管控办法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)

修改的程序应当考量以下方面：准确证实所有的须要修改的应用领域系统、信息、数据库和有关的硬件设备；准确的证实修改的原因(业务上的具体内容流程和具体内容的市场需求或研发上的市场需求)；由许可的用户递交修改的提出申请；留存有关的许可备案记录；在正式宣布的实行之前，修改的方案必须经过评审并通过正式宣布的核准；保证许可的用户在实行之前证实并拒绝接受修改的内容；保证在实行的过程中，尽量的增加对现行的商务运作系统的影响；保证创建的文件系统在顺利完成各项修改时获得修正，旧有文件被较好的档案或处理；确保所有的应用领域系统升级的版本的掌控；保证所有的修改情求的审查追踪；保证用户使用手册并作适当的必要的修改；保证修改的实行挑选了适度的时机以保证修改的实行不能阻碍正常的商务运作。

c)

版本控制建议

1)

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

2)

版本升级掌控：当软件的版本由于更新，修正等操作方式须要升级时，必须先向有关负责管理人员递交提出申请