文档信息

修订记录

审批发布

一总则

目的。为规范自有软件研发以及外包软件的管理工作，依据《信息安全管理办法》制定本管理制度。

对象。本制度中软件开发指新系统开发和现有系统重大改造。

范围。本制度适用于软件研发与管理。

要求。信息系统的软件开发安全管理要求统一遵循《GB/T 22239-2019信息安全技术 信息系统安全等级保护基本要求》。

二软件开发管理制度

1 通用规范

1.系统开发总体原则：

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

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

（3）确保系统开发环境与业务环境相隔离，内部测试由开发人员自行搭建环境，模拟测试必须在专用的测试环境中进行测试。

（4）确保开发进度和开发质量。

（5）系统开发必须具有一定的前瞻性，符合主流系统的发展方向。

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

（7）充分利用现有的资源。

2.系统开发人员职责分配管理规范：

在系统开发的过程中，应明确不同人员的角色和职责。通常在系统开发过程中具体划分以下四种角色：

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

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

（3）系统审计人员：对整个开发的过程进行审核和监督，确保开发的质量和开发的安全，建议由单位相关人员承担。

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

3.开发人员授权管理规范：

（1）开发人员授权由单位安全管理员协调相关管理员进行授权。

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

（3）开发人员必须负责其开发内容的保密性，不得私自将开发的相关信息泄漏出去。

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

（5）在日常工作中记录员工的开发相关的日志信息。

（6）员工一旦离职或调动岗位应立即收回或调整其相应的权限。

4.系统开发变更管理：

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

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

（3）在正式的实施之前，更改的方案必须经过评审并通过正式的批准。

（4）确保授权的用户在实施之前确认并接受更改的内容。

（5）确保在实施的过程中，尽量减少对现行系统的影响。

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

（7）保证对所有系统升级的版本的控制。

（8）确保用户使用手册作相应的必要的更改。

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

2 系统需求分析阶段规范

1.技术可行性分析：

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

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

计算机软件和硬件分析：指学校现有的软件和硬件的性能或配置是否足够满足系统开发的要求。

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

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

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

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

2.在技术可行性分析阶段，同样必须从身份鉴别、访问控制、软件容错、数据加密和安全审计等方面进行系统安全需求分析，并且提供相关安全需求分析报告，报告应包括以下内容：

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

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

（3）安全开发需求分析计划应由开发项目负责人和学校内部安全管理员共同商议决定。

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

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

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

（1）系统的预期存储容量和在给定的周期内获取生成和存储的数据量。

（2）在线进程的数量和估计可能的占用资源。

（3）对于系统和网络的相应时间和性能的要求。

（4）系统弹性要求和设计使用率、峰值、槽值和平均值等。

（5）安全措施（如加密解密数据）对系统的影响。

（6）24x7运作要求和可接受的系统宕机次数。

3 系统开发阶段安全规范

1.开发人员技术要求：

（1）开发人员应有能力防止开发过程中的缓冲器溢出错误。

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

（3）错误问题报告应越通俗越好，不应在其中包含任何系统细节问题。

（4）应对重要的敏感信息进行加密的保护。

（5）应使用一些相对复杂的加密和密钥生成机制。

（6）应单独编写安全性设计说明概要。

2.程序库管理规范：

（1）程序库的修改、更新由开发人员提出申请，由学校信息系统项目管理人员进行审批，并由开发人员进行汇总登记。

（2）管理开发工具：

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

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

（3）访问控制：

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

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

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

（4）源代码管理：

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

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

n 各项应用应指定相应的管理员。

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

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

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

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

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

3.开发版本管理规范：

（1）版本程序管理：

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

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

（2）版本升级管理：

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

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

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

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

（3）版本控制管理：

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

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

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

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

n 开发人员记录所有版本变更的日志并由单位信息系统项目管理人员进行审核，记录应包括更改日期、更改前版本号、更改后版本号、更改人等信息。

4.开发检查管理规范：

（1）开发日志定期检查，系统开发中的相关日志文件根据开发周期定期审核。

（2）开发人员权限应定期检查。

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

5.按照第三方管理规定对开发外包安全进行管理。

4 系统测试阶段安全规范

1.应用系统的安全性测试规范：

（1）必须有详细的测试计划，包括测试范围、测试方法和测试工具。

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

（3）应用系统上线前必须经过安全性测试。

2.测试数据通用要求：

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

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

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

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

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

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

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

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

5 培训与文档管理规范

1.新系统的培训要求：

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

（2）培训同样应包括安全性方面的培训。

2.撰写新系统和系统改进的文档：

（1）新系统和系统改进都必须有充分的最新的文档支持。

（2）必须保证新系统和系统改进有详实的文档。

3.项目组应将整理后的文档交由单位存档。

6 系统交付管理规范

1.服务质量要求：

（1）开发方必须依据合同或独立的服务协议中的关键指标提供服务；

（2）在服务提供期间，单位信息系统项目管理部门或人员应经常对开发方的人员资质进行确认，保证服务期间服务人员的稳定性；

（3）制定对开发方服务的评价指标和测量体系，以确保开发方服务提供的质量。

2.服务的改进：

（1）开发方在服务提供过程中，发现与服务的需求有较大差距时，双方必须对服务进行评估，如果是未达到服务合同或服务协议的要求，则责成开发方对服务进行改进；

（2）如果开发方服务达到合同或服务协议的要求，但是还不能满足服务的实际需求，则双方可以协商对合同或服务协议进行变更，提高关键指标以适应服务的实际需求。

7 系统验收与试运行安全规范

1.安全性测试：

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

（1）配置管理：建议使用配置管理系统，并提供配置管理文档；

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

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

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

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

（6）安全功能强度评估：功能强度分析应说明安全机制（如口令字或哈希函数）实现的系统安全功能强度。

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

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

2.安全试运行：

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

（1）监测系统的安全性能，包括事故报告；

（2）进行用户安全培训，并对培训进行总结；

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

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

（5）评估系统改动对安全造成的影响；

（6）监测系统物理和功能配置。

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

3.系统验收：

系统试运行过程结束后，可以由单位与开发单位相关人员对项目进行验收，验收应包括以下内容：

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

（2）采用技术是否符合国家、行业有关安全技术标准及规范。

（3）是否实现验收测评的安全性测试。

（4）项目实施过程中的各种文档资料是否规范、齐全。

（5）应由安全管理员对验收在安全性方面进行评价。

4.投入运行后的监控与跟踪，项目投入运行后还应进行一段时间的监控和跟踪，系统的管理人员负责监控和跟踪工作，具体应包括以下要求：

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

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

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

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

（5）监控并跟踪系统相关的备份情况；

（6）监控运行程序的变化，并记录其对系统安全的影响；

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

（8）监控安全配置的变化，并记录其对系统安全的影响。

三自行软件开发

1 申报

本阶段主要是项目审批单位对项目申报内容进行审批，对项目进行安全性论证，必要时可以聘请外单位的专家参与论证工作。

2 安全性论证和审批

安全性论证应着重对项目的安全需求分析、安全对策以及总体安全方案进行成本-效益、合理性、可行性和有效性分析，并在《信息化项目立项审批表》上给出明确的结论：

（1）适当

（2）不合适（否决）

（3）需作复议

3复议

对论证结论为“需作复议”的项目，通知申报单位对有关内容进行必要的补充或者修改后，再次提交复审。

4 项目安全立项

审批后，项目审批单位将对项目进行立项，在《信息系统项目任务书》的以下条目中应增加相应的计算机安全方面的内容：

（1）项目的管理模式、组织结构和责任：增加项目建设中的安全管理模式、安全组织结构以及五、人员的安全职责；

（2）项目实施的基本程序和相应的管理要求：增加项目建设实施中的安全操作程序和相应安全管理要求；

（3）项目设计目标、主要内容和关键技术：增加总体安全目标、安全对策以及用于实现安全对策的总体安全方案；

（4）项目实现功能和性能指标：增加描述系统拥有的具体安全功能以及安全功能的强度；

（5）项目验收考核指标：增加安全性测试和考核指标。

立项的项目，如采用引进、合作开发或者外包开发等形式，则需与第三方签订安全保密协议

5 项目管理

5.1 概要

5.1.1 目的

为了规范项目的文档管理工作，特制定本规范。

5.1.2 范围

本规范仅适用与项目的文档管理工作。

5.1.3 编制及修订

本规范由项目实施小组负责编制及修订。

5.1.4 发布

本规范由保密科负责发布，发布后项目组成员可通过OA系统查阅。

5.2正文

5.2.1 文档架构的构成

项目的文档（下简称文档）将由电子版本和纸介质共同组成，二者必须一致（应用系统源代码只以电子文档形式提交）。

文档按项目启动、项目计划、项目执行与控制、项目收尾四个阶段进行管理，对于这四个阶段的文档分类简写分别为：项目启动（PS）、项目计划（PP）、项目执行与控制（PE）、项目收尾（PC）。

5.2.2 文档编码规则

5.2.3文档管理职责

项目文档由项目实施小组负责管理，信息资料科派出一位同事兼任项目文档管理员。

项目小组的成员应按要求及时将审定过的文档交付给项目文档管理员，项目文档管理员应该及时对文档编码并归档。

项目文档管理员负责项目文档的管理，及时更新项目文档目录。

项目文档管理员每周对归档或变更的文档出一份简报呈交实施组组长和保密科科长。

5.2.4文档架构的变更

文档体系的结构需要变更时，需经以下的程序才能执行：

项目组成员提出申请、实施组组长批准、保密科科长批准、项目文档管理员变更。

5.2.5文档的授权

经项目文档管理员发布的文档默认为全体项目组成员有读取权限，需要特殊指定权限的文档由项目组成员交付文档时特别说明。

四外包软件管理制度

1 组织职责

甲方职责

(以下称“甲方”)一般为外包项目管理部门，其主要职责是：

（1）负责为外包项目指派甲方项目负责人作为甲方的代表参与外包项目的管理、技术审核和协调工作，必要时成立甲方工作组；

（2）负责对乙方的管理体系进行审定，并确定乙方项目组使用的管理标准。如乙方已通过ISO9000、CMM或CMMI等标准，经审核同意后，项目可以按照乙方的管理规范实施；如果审核未通过，则需要按照甲方的管理规范、流程执行，并对相关文档模版进行裁剪后，提供乙方项目组使用，必要时为乙方项目组提供管理相关的培训。

乙方职责

（1）负责对外包开发进行管理，成立项目组，并指派乙方项目负责人代表乙方与甲方沟通，负责乙方的项目管理工作。

（2）乙方项目组使用的技术规范、文档标准、管理过程应符合合同规定的要求，或符合甲乙双方达成的一致要求。

（3）乙方应履行合同中规定的其它条款要求，如知识产权、保密、技术支持和产品售后维护等，这些要求应在合同中明确。

（4）按计划向甲方交付相关工作产品和文档，并按合同要求提供后期的服务和维护工作。

2 外包开发人员管理

（1）人员登记：外包开发人员进入学校进行项目实施的，乙方项目负责人应填写《外包软件开发人员登记表》,并提交甲方项目负责人，同时乙方应遵守甲方相关规章制度和管理条例。

（2）资源申请：乙方项目负责人对于乙方在甲方开发工作期间需要使用的资源须填写《资源使用申请表》并提交甲方项目负责人,其中资源包括设备、网络、开发环境等。

（3）资源分配：甲方项目负责人对于乙方的资源申请进行审核确认,并负责协调解决。乙方在获取资源后专人专用并不得随意借用于他人。

（4）实行考勤制度，乙方人员在学校项目开发期间必须遵守学校的作息制度。

（5）外包开发人员应遵守学校开发环境管理相关规定，不能随意更改网络配置，一台设备不能同时连接外网和内网。如果由于乙方外包开发人员不遵守学校规定造成的损失,甲方有权要求乙方赔偿。

3 进度管理

（1）甲方项目负责人应要求乙方项目负责人按季度提供外包开发实施计划

（2）甲方项目负责人应要求乙方项目负责人每周编制工作周报,总结本周工作情况和计划下周工作,并反馈工作中遇到的问题。

（3）对于开发中遇到的问题,甲方项目负责人和乙方项目负责人应根据各自职责协调解决。

（4）甲方项目负责人应对乙方开发工作进行检查和监督。

4 文档管理

如果外包开发在甲方现场实施,则乙方必须遵守学校的文档管理规范，使用学校统一的版本管理工具，并及时更新。甲方项目负责人负责监督，且验收时以文档管理工具上的内容为准。

5知识转移

（1）在外包开发结束之后或开发过程中,乙方负责将开发相关文档和产品提交给甲方项目负责人,甲方项目负责人填写《开发成果交接登记表》。

（2）乙方有义务制定培训计划，并提交培训计划至甲方项目负责人,甲方项目负责人在培训实施过程中填写《项目培训记录表》。

6 代码检查

甲方项目负责人依据相关开发代码检查规则对外包软件关键代码进行恶意代码和后门检查。

五附则

对违反本制度的人员，将按照有关规定进行处罚。

本制度由信息安全工作小组负责制定、解释和修改。

本制度自发布之日起执行。

信息安全工作小组

2020年10月18日