第1章 概述

第1条  为完善九州注册信息资产的管理，明确相关人员的职责和权限，保障信息资产管理相关措施的贯彻实施，特制定本制度。

第2条  适用范围：适用于九州注册所有部门。

第2章 资产识别与分类

第3条  对所有已识别的信息资产必须建立信息资产目录，填写《九州注册信息资产清单》（样本见附件一）；

第4条  资产分类方法参见附件二；

第5条  资产等级划分参见附件三；

第6条  对所有识别出并进行分类的信息资产，必须进行标识，标识可以采用标签、数据库标识等方法；

第7条  对信息资产进行标识时，均应同时标识该信息资产的名称、分类、资产编号、资产管理员、安全级别等信息。信息资产分类和标识时的编号应该和统计与国有资产管理处对资产的编号保持一致，便于统一管理；

第8条  信息资产状态变更：信息资产的维护人、物理位置、安全等级等重要变更行为，须由信息资产的责任人进行批准，改变资产分类标签时，须通知与资产相关的人员；

第9条  数据分类标签的对象包括各种存储介质、磁带、软盘以及其他介质，所有印刷的、手写的敏感信息都必须放置标签；

第3章 资产管理责任

第10条  “谁主管，谁负责”。图书信息管理中心拥有的每项网络与信息资产，必须根据资产归属确定“责任人”，分配其相应的安全管理职权，并由其承担相应的安全责任。资产“责任人”可以将具体的安全职责委派给“维护人”，但“责任人”仍须承担资产安全的最终责任。

第11条  信息资产的责任人是指负责管理网络与信息资产并落实相应安全措施的个人或部门。责任人的职责权限包括：

a) 所有网络与信息资产都必须指定责任人。

b) 责任人及其领导负责进行风险分析，根据信息保密标准分类确定、鉴别并记录其所拥有的网络与信息资产的安全级别。该级别至少每年评审一次。

c) 责任人必须贯彻、落实恰当的安全控制措施，确保只有在工作必须的情况下才能使用相关资产。

d) 责任人可以为由其负责的资产指派维护人，或自己担当此任。

e) 责任人可基于工作相关性分配访问权，并与维护人共同负责保证网络与信息资产的可用性。

f) 责任人必须至少每年审查一次其资产的访问权限。评审流程必须记录在案，并保留到下一次审查结束之前。

第12条  信息资产的维护人是指支持并维护网络与信息资产的人员。维护人的职责权限包括：

a) 维护人可以根据所保管的信息的保密类别来确定相应的实物资产的安全管理流程，以确保网络与信息资产责任人所要求的机密性、完整性和可用性。

b) 责任人应确保适当的安全措施到位，并可以适度向下委派。如若需要，可以确定备用联络人。维护人必须保留责任人的名单。

c) 责任人必须通知维护人其所应承担的安全职责。

d) 未经责任人许可，维护人不得重新划分信息的类别。

第4章 软件变更管理制度

第一节       总  则

第13条  为规范软件变更与维护管理，提高软件管理水平，优化软件变更与维护管理流程，特制定本制度。

第14条  本制度适用于应用系统已开发或采购完毕并正式上线、且由软件开发组织移交给应用管理组织之后，所发生的业务应用系统（以下简称应用系统）运行支持及系统变更工作。

第二节       变更流程

第15条  系统变更工作可分为下面三类类型：功能完善维护、系统缺陷修改、统计报表生成。功能完善维护指根据业务部门的需求，对系统进行的功能完善性或适应性维护；系统缺陷修改指对一些系统功能或使用上的问题所进行的修复，这些问题是由于系统设计和实现上的缺陷而引发的；统计报表生成指为了满足业务部门统计报表数据生成的需要，而进行的不包含在应用系统功能之内的数据处理工作。

第16条  系统变更工作以任务形式由需求方（一般为业务部门）和维护方（一般为信息部门的应用维护组织和软件开发组织，还包括合作厂商）协作完成。系统变更过程类似软件开发，大致可分为四个阶段：任务提交和接受、任务实现、任务验收和程序下发上线。

第17条  需求部门提出系统变更需求，并将变更需求整理成《系统变更申请表》（附件四），由部门负责人审批后提交给系统管理员。

第18条  系统管理员负责接受需求并上报给IT主管。IT主管分析需求，并提出系统变更建议。IT经理根据变更建议审批《系统变更申请表》。

第19条  系统管理员根据自行开发、合作开发和外包开发的不同要求组织实现系统变更需求，将需求提交至内部开发人员、合作开发商或外包开发商，产生供发布的程序。

第20条  实现过程应按照软件开发过程规定进行。系统变更过程应遵循软件开发过程相同的正式、统一的编码标准，并经过测试和正式验收才能下发和上线。

第21条  系统管理员组织业务部门的系统最终用户对系统程序变更进行测试，并撰写《用户测试报告》（附件五），提交业务部门负责人和IT主管领导签字确认通过。

第22条  在系统变更完成后，系统管理员和业务部门的最终用户共同撰写《程序变更验收报告》（附件六），经业务部门负责人签字验收后，报送IT经理审批。

第23条  培训管理员负责对系统变更过程的文档进行归档管理，变更过程中涉及的所有文档应至少保存两年。

第三节      紧急变更流程

第24条  对于紧急变更，需求部门可以通过电子邮件或传真等书面形式提出申请。

第25条  图书信息管理中心根据重要性和紧迫性做判断，确定其优先级和影响程度，并进行相应处理。

第26条  紧急变更过程中应使用专设的系统用户账号，由专责部门或人员启动紧急修改变更程序。图书信息管理中心应对紧急变更的处理进行规范的文档记录。

第27条  在紧急事件处理完成后，必须在一周内补办正式、完整的文档，其中包括问题发现人填写的紧急变更申请、问题发现人所在部门负责人对该申请的审批、需求部门/信息技术部测试记录（包括签字确认测试结果）。

第四节      系统变更的权责分离

第28条  系统变更过程中，应采取各种措施保证维护环境程序代码访问权限受到良好控制。这些措施包括：

a) 通过系统用户的授权管理，确保只有特定人员能进行系统维护工作；

b) 如果使用专用程序开发工具，只有授权人员才能使用程序开发工具（通常只有特定开发人员拥有程序开发工具）；

c) 通过对源代码的访问控制，限制只有授权人员才能获得源代码以进行系统维护；

d) 在进行自有系统的程序变更时，应建立版本控制制度确保每次在最新的代码基础上进行更改，当多名程序员同时进行更改工作时，能够进行适当协调；

e) 通过对系统日志的审阅，监督系统维护人员在系统中的操作，确认维护工作的授权；

f) 在进行自有系统的程序变更时，应防止源代码在完成测试到正式上线之间的非授权修改。

第29条  系统变更过程中，采取各种措施保证生产系统应用程序访问权限受到良好控制。这些措施包括：

a) 通过生产环境的访问控制，限制对生产环境的访问；

b) 通过物理隔离的手段，限制对生产环境的访问；

c) 通过逻辑隔离的手段，限制对生产环境的访问；

d) 对授权访问生产环境的人员进行详细记录，使用该记录对生产环境访问权限进行检查，确保只有经授权人员才能访问生产环境；

e) 普通用户只能通过前台登录系统，不能通过后台（如使用生产环境操作系统的命令行）进行操作；

f) 信息技术人员不应该拥有前台应用程序的业务操作访问权限，更不应该在前台应用程序中担任实际的业务操作任务；

g) 从技术角度限制开发人员对生产环境中应用程序文件夹的访问权限，只有经过授权的人员对程序拥有读、写和执行的权限；

h) 禁止信息技术人员共享操作系统级别的账号。