第一章 总则

第一条 为了规范系统开发过程，明确定义系统开发过程必须遵守的安全管理规定，保障信息系统符合规定的安全要求，防止系统中重要数据丢失、修改或滥用，确保信息系统安全、持续地运行，特制定本文件。

第二章 适用范围

第二条 本文件适用于武汉学院信息系统开发过程，包括内部开发或者委托外部公司开发。

第三章 通用规范

第三条 系统开发总体原则：

(一) 系统开发应当从业务需求的角度出发，不得盲目追求系统先进性而忽略了系统的实用性。

(二) 开发的方法和管理必须规范化、合理化、制度化。只有采用了规范化、合理化、制度化的开发管理方法，才能确保开发的质量和进度。

(三) 确保系统开发环境与生产环境相隔离，内部测试由开发人员自行搭建环境，模拟测试必须到专用的测试环境进行测试。

(四) 确保开发进度和开发质量。

(五) 系统开发必须具有一定的前瞻性，符合主流系统的发展方向。

(六) 开发人员安全意识的提高和加强，确保机密信息和关键技术不会泄漏。

(七) 充分利用现有的资源。

第四条 系统开发人员职责分配管理规范：

在系统开发的过程中，应当明确不同的人员的身份、职责。建议在系统开发过程中具体分以下四种角色：

(一) 项目负责人员：确保在整个系统开发的各个阶段都实施了相关的安全措施，同时在整个系统开发的过程中负责整个项目的开发安全管理。

(二) 系统开发人员：根据业务需求确保开发的系统能够满足业务上的需求和相应的安全上的需求，同时满足系统质量上和进度上的要求。

(三) 系统审计人员：对整个开发的过程进行审核和监督，确保开发的质量和开发的安全，建议由信息系统安全管理员承担。

(四) 文档管理员：负责对整个开发过程产生的系统软件设计类相关文档、系统培训和操作等用户手册进行管理和使用控制。

第五条 开发人员授权管理规范：

(一) 开发人员授权由信息系统负责人协调相关管理员进行授权。

(二) 根据该员工在整个开发项目中所负责的开发内容授予其相应的权限和承担的责任。

(三) 开发人员必须负责其开发内容的保密性，不得私自将开发的相关信息泄露出去。

(四) 根据员工权限和责任的大小确认是否需要签署相关的保密协议。

(五) 在日常工作中记录员工的开发相关的日志信息。

(六) 员工一旦离职或调动岗位应立即收回或调整其相应的权限。

第六条 系统开发变更管理：

(一) 开发人员必须确认所有的需要更改的应用系统、信息、数据库和相关的硬件设备。

(二) 确认更改的原因(业务上的具体流程和具体的需求或开发上的需求)

(三) 在正式的实施之前，更改的方案必须经过评审并通过正式的批准

(四) 确保授权的用户在实施之前确认并接受更改的内容。

(五) 确保在实施的过程中，尽量的减少对现行的系统的影响。

(六) 确保建立的文件系统在完成各项更改时得到修改，旧文件被很好的归档或处置。

(七) 保证所有系统升级的版本的控制。

(八) 确保用户使用手册作相应的必要的更改。

(九) 确保更改的实施选择了适当的时机以确保更改的实施不会干扰正常的系统运行。

第四章 系统需求分析阶段规范

第七条 技术可行性分析：

(一) 根据业务上提出的需求，从技术开发的角度分析是否现有的技术手段和技术能力是否可以达到业务上要求的系统功能，通常可以从三个方面进行分析：

a) 技术能力分析，指单位内的系统开发队伍是否有足够的软件开发的技术能力来完成系统开发的任务，或第三方外包的开发公司是否具有开发应用系统的技术能力。

b) 计算机软件和硬件分析，指单位现有的软件和硬件的性能或配置是否足够满足系统开发的要求。

c) 管理能力分析，指现有的技术开发管理制度和管理流程是否成熟且标准化，是否足够系统开发的要求。

(二) 需求可行性分析：系统的开发来源于业务上的需求，因此需要对该需求进行可行性分析，以判断需求是否明确，是否符合实际，是否在一定的时间范围内可实现的。

(三) 投资可行性分析：根据业务需求和技术手段的分析，确认根据业务需求和技术手段需要多少的投资才可以实现，确认投资的数额是不是在可控制和可承受的范围内。

(四) 影响可行性分析：新系统开发和投入运营会不会造成社会影响，以及造成的社会影响有多少等；新系统开发和投入运营是否会对现有的系统造成不良影响。

第八条 在技术可行性分析阶段，同样必须从身份认证、系统权限、数据加密和系统审计等几个方面进行系统安全需求分析，并且有相关安全需求分析报告，报告应该包括以下内容：

(一) 安全需求计划应该能够达到期望的安全水平。其中包括了成本的预估，完成各个安全相关流程所需的时间。

(二) 所有的有关应用系统的更新或改进都必须是基于业务需求的，并且是有业务事件支持的。这里的业务需求不仅仅包括了系统的功能、性能、开发费用、开发周期等内容，还要明确系统的安全要求。

(三) 安全开发需求分析计划应该由开发项目经理和单位内部安全管理员共同商议决定。

(四) 系统的更新或改进都必须进行详细的需求定义、需求分析以及测试评估以保证不会对业务造成任何的影响。

(五) 业务需求是系统更新和改动的基础，因此必须清晰明确的定义业务的需求，绝对不允许在业务需求未经过业务部门领导和主要负责人员的认可的情况下进行开发。

第九条 在技术可行性分析阶段，同样建议考虑系统的容量规划，容量规划是指确定系统的总体规模，性能和系统弹性。容量规划的具体内容可能有所不同，但一般需要考虑以下方面：

(一) 系统的预期存储容量和在给定的周期里面获取生成和存储的数据量。

(二) 在线进程的数量和估计可能的占用资源。

(三) 对于系统和网络的相应时间和性能的要求。

(四) 系统弹性要求和设计使用率、峰值、槽值和平均值等。

(五) 安全措施例如加密解密数据对系统的影响。

(六) 24x7运作要求和可接受的系统宕机次数。

第五章 系统开发阶段安全规范

第十条 开发人员技术要求：

(一) 开发人员应该有能力防止开发过程中的缓冲器溢出错误。

(二) 在整个开发的过程中必须完整的持续的进行代码错误处理所规定的流程。

(三) 错误问题报告应该越通俗越好，不应该在其中包含任何系统细节问题。

(四) 应该对重要的敏感信息进行加密的保护。

(五) 应该使用一些相对复杂的加密和密钥生成机制。

(六) 应该单独编写安全性设计说明概要。

第十一条 程序库管理规范：

(一) 程序库的修改、更新由开发人员提出申请，由单位信息系统项目管理人员进行审批，并由开发人员进行汇总登记（附录一、信息系统开发程序库变更记录表）。

(二) 管理开发工具：

a) 严格管理在开发设备上的存放开发工具的目录。

b) 只有指定的人员经过适当的管理授权后才可以访问开发工具服务器。

(三) 访问控制：

a) 严格管理开发环境的安全管理，防止未经授权的人进入开发环境。

b) 严格管理开发用途的计算机，只有指定的人员才可以访问开发用的计算机设备。

c) 严格管理开发系统的认证管理，建立严格的基于人员职责的授权等级制度，用口令或其他身份识别技术确认访问者身份。

(四) 源代码管理：

a) 必须严格管理在开发系统上的存放源代码的目录。

b) 只有指定的人员如程序库管理员经过适当的管理授权后才可以访问源代码库，对源代码库的访问必须结合进行严格的访问控制技术手段和双重访问控制机制。

c) 各项应用应当指定相应的管理员。

d) 非开发人员不应当自由的访问源代码库。

e) 源代码库和开发工具服务器尽量分开存放并且分开管理。

f) 源代码库和运行的应用系统尽量分开存放且分开管理。

g) 源代码库的更新和向开发人员发布的源代码应当由指定的管理员根据一定的授权进行，不得私自自行更新或发放。

h) 应当保存所有对源代码库进行访问读取或修改的日志纪录，以便于日后审计。

第十二条 开发版本管理规范：

(一) 版本程序管理：

a) 对于程序清单必须进行严格的控制并且及时地进行更新。

b) 对应用系统开发源代码的打印的资料、电子版本或者是相关的报告都必须进行控制，纸质的文件应当保存在一个安全的环境下，如保险柜等。电子文档则应有一定的加密措施。

(二) 版本升级管理：

a) 当软件的版本由于更新，修改等操作需要升级时必须先向XXXX相关负责人员提交申请。

b) 应用系统软件版本升级测试，对升级的应用系统进行测试，确认系统的各种安全特性。

c) 需确认当前的版本为最新的版本，旧的版本需进行归档，不得随意丢弃或删除。

d) 制定相关的升级计划，确保将系统升级对业务的影响降至最低。

(三) 版本控制管理：

a) 开发人员必须对版本变更进行管理，符合相关变更管理规定。

b) 防止不同版本的覆盖的情况。

c) 版本变更时需要在更新的版本中记录变更的详细描述。

d) 版本的更改只允许指定的人员进行操作。

e) 开发人员纪录所有的版本变更的日志并由项目管理人员进行审核，记录包括了更改日期，更改前版本号，更改后版本号，更改人等信息（附录二、信息系统开发版本变更记录表）。

第十三条 开发检查管理规范：

(一) 开发日志定期检查，系统开发中的相关日志文件根据开发周期定期审核。

(二) 开发人员权限应定期检查。

(三) 应有防御后门代码或隐藏通道控制措施，如对源代码进行检查，安装相关检查工具等。

第十四条 按照第三方管理规定对开发外包安全进行管理。

第六章 系统测试阶段安全规范

第十五条 应用系统的安全性测试规范：

(一) 必须有详细的测试计划，包括测试范围，测试方法和测试工具。

(二) 在测试的过程中详细的描述每个和测试方案相关的测试步骤和测试数据，将所有的测试数据进行整理归档，将出错的纪录进行分析，确认问题产生的原因并编写问题报告。

(三) 应用系统上线前必须经过安全性测试。

第十六条 测试数据通用要求：

(一) 任何测试数据必须妥善保管理和处理，不得随意丢弃和泄露。

(二) 为了防止数据泄漏和敏感系统的滥用，一般情况下要求使用虚构数据进行测试。

(三) 当处于测试目的而使用真实的敏感的数据时，可以采用以下措施保护测试数据的安全：

a) 对测试的系统进行严格的访问控制。只允许小部分的测试人员进行测试。且对于测试的人员按需要签订保密协议。

b) 将真实的运行信息复制到测试系统时间应有单独授权过程。

c) 测试完成后，应当立即将相关数据从测试的应用系统中删除。

d) 纪录下测试数据的复制、使用和删除的情况，以便于审查追踪。

第十七条 质量认证：目前国际上公认的开发质量验证标准主要有两种，可以根据这两种标准确认系统是否已经达到一定的质量要求，如ISO 9000认证体系，软件开发能力成熟度模型(CMM)。

第七章 系统培训及文档阶段管理规范

第十八条 新系统的培训要求：

(一) 对所有的用户和技术人员提供关于新系统功能和操作方面的培训。必须保证所有的技术和业务用户接受足够的关于新系统或者系统改进的培训。

(二) 培训同样应包括安全性方面的培训。

第十九条 撰写新系统和系统改进的文档：

(一) 所有新系统和系统改进都必须有充分的最新的文档支持。

(二) 必须保证新系统和系统改进有详实的文档。

第二十条 项目组应将整理后的文档交由信息系统管理部门存档。

第八章 系统验收与投产安全管理规范

第二十一条 安全性测试：

(一) 应制定研发、投产与验收等过程中的安全测试与验收大纲，在项目实施完成后，由武汉学院及开发人员共同组织测试小组进行测试。在测试大纲中应至少包括以下安全性测试和评估要求：

a) 配置管理：建议使用配置管理系统，并提供配置管理文档；

b) 交付程序：应将把系统及其部分交付给用户的程序文档化；

c) 安全功能测试：对系统的安全功能进行测试，以保证其符合详细设计并对详细设计进行检查，保证其符合概要设计以及总体安全方案；

d) 系统管理员指南：应提供如何安全地管理系统和如何高效地利用系统安全功能的优点和保护功能等详细准确的信息；

e) 系统用户指南：必须包含两方面的内容：首先，它必须解释那些用户可见的安全功能的用途以及如何使用它们，这样用户可以持续有效地保护他们的信息；其次，它必须解释在维护系统的安全时用户所能起的作用；

f) 安全功能强度评估：功能强度分析应说明以概率或排列机制（如，口令字或哈希函数）实现的系统安全功能。

g) 脆弱性分析：应对新系统进行脆弱性测试，包括工具或人工测试。

(二) 测试完成后，测试小组应提交测试报告，其中应包括安全性测试和评估的结果。

第二十二条 安全试运行：

(一) 试运行阶段应有安全措施来维护系统安全，包括但不限于：

a) 监测系统的安全性能，包括事故报告；

b) 进行用户安全培训，并对培训进行总结；

c) 监测新发现的对系统安全的攻击、系统所受威胁的变化以及其它与安全风险有关的因素；

d) 监测系统的备份支持，支持与系统安全有关的维护培训；

e) 评估系统改动对安全造成的影响；

f) 监测系统物理和功能配置。

(二) 在试运行情况报告中应对上述工作做总结性描述。

第二十三条 系统验收，系统试运行过程结束后，可以组织由单位与开发公司相关人员参加对项目进行验收，验收应包括以下安全内容：

(一) 项目是否已达到项目任务书中制定的总体安全目标和安全指标，实现全部安全功能；

(二) 采用技术是否符合国家、教育行业有关安全技术标准及规范。

(三) 是否实现验收测评的安全性测试。

(四) 项目实施过程中的各种文档资料是否规范、齐全。

(五) 应由安全管理员对验收在安全性方面进行评价。

第二十四条 投产后的监控与跟踪，项目投产后还应进行一段时间的监控和跟踪，系统的管理人员负责监控和跟踪工作，具体应包括以下要求：

(一) 应对系统关键安全性能的变化情况进行监控，了解其变化的原因；

(二) 对系统安全事故的发生、应急、处理、恢复、总结进行全程跟踪，并有详细的记录；

(三) 对新发现的对系统安全的攻击进行监控，记录其发生的频率以及对系统的影响；

(四) 监控系统所受威胁的变化，评估其发生的可能性以及可能造成的影响；

(五) 监控并跟踪系统相关的备份情况；

(六) 监控运行程序的变化，并记录这些变化对系统安全的影响；

(七) 监控系统物理环境的变化情况，并记录这些变化对系统安全的影响；

(八) 监控安全配置的变化情况，并记录这些变化对系统安全的影响；

第九章 持续改进

第二十五条 为了保证本文件的时效性、可行性，必须根据相关审核规定进行评审和修订，修订后重新发布。

第十章 附则

第二十六条 本文件由武汉学院负责制定、解释和修改。

第二十七条 本文件自发布之日起执行。