信息系统采购、开发和维护制度
11.1 系统安全需求
11.1.1 系统的安全需求分析与范围
第 243 条
在系统开发的整个过程（特别是在系统需求阶段）都必须考虑安全需求，包括但不限于：
1)系统架构
2)用户认证
3)访问控制和授权
4)事务处理的机密性和完整性
5)日志记录功能
6)系统配臵
7)法律法规和兼容性要求
8)系统恢复
第 244 条
在系统的需求和设计阶段，需要对系统进行安全方面的评审。
第 245 条
应该在开发的整个周期对安全需求实施的正确性进行阶段性检查，以确保其对应的安全措施按照要求被定义、设计、部署和测试。
第 246 条
在使用商业软件或软件包前，必须按照上述安全需求进行评估。对于软件的安全控制要求应该在评估之前定义好。
第 247 条
软件必须通过用户的正式验收后才能投入生产。软件在正式使用前必须经过安全方面的测试，测试内容必须包括所有设计文档中的安全要求。
第 248 条
为了对用户的操作进行检查和审计，系统必须提供日志记录功能。系统应提供只有日志审计人员可以访问的用来查看日志记录的审计接口。日志文件必须设臵严格的访问控制，包括系统管理员、日志审核员在内所有角色都只能有查看权限。
11.2 应用系统中的安全
11.2.1
数据输入的验证
第 249 条
所有接受数据输入的入口必须有相应的验证处理，包括但不限于：
1)数据的长度
2)数据的类型
3)数据的范围
4)字符的限制
第 250 条
根据业务需要，对于按照纸面信息输入的数据，系统应该提供“数据在输入被确认”之后才能提交的功能。
第 251 条
系统应该对错误的输入数据提供有帮助的提示信息。必须对数据输入验证功能进行全面的测试，以保证其正确性和有效性。系统在使用过程中，应该明确定义参与数据输入各环节所有相关人员的职责。
11.2.2 内部处理的控制
第 252 条
应用系统的设计应该考虑以下因素，防止正确输入的数据因错误处理或人为因素等遭到破坏：
1)程序应该有处理的校验机制
2)程序应该有相应的例外处理机制
3)对于有先后执行顺序的程序或程序模块，内部必须有执行顺序的限制机制
第 253 条
控制措施的选择应根据应用的性质和数据受损对业务造成的影响而定，可选择的措施包括但不限于：
1)会话或批处理控制措施，在事务更新后协调相关数据文件的一致性
2)验证系统生成数据的正确性
3)检查数据完整性，特别是在计算机之间传输的数据
4)计算记录和文件的哈希值以便验证
5)确保程序以正确的顺序运行，在出现故障时终止，在问题解决前暂停处理
11.2.3 消息验证
第 254 条
对需要确保消息内容完整性的应用（例如电子交易）应该使用消息验证。
第 255 条
在采用消息验证之前，应该通过安全风险评估，以确定其是否能满足需要或采取其他更适合的解决方式。
11.2.4 数据输出的验证
第 256 条
应该使用检查输出数据合理性的机制。应该使用确保数据被全部处理的机制。
第 257 条
输出的数据应该含有相关标志，以便判断数据的状态（例如是否准确、是否完整等）。必须对数据输出验证功能进行全面
的测试，以保证其正确性和有效性。
第 258 条
系统在使用过程中，应该明确定义参与数据输出各环节所有相关人员的职责。
11.3 加密控制
11.3.1 加密的使用管理办法
第 259 条
敏感信息应该根据信息分类的要求采用加密措施进行保护。
第 260 条
加密措施的采用不但要考虑到信息存储，也应该考虑到信息传输的要求。应该使用被公司认可的标准加密算法。
第 261 条
未经安全管理委员会的同意，用户不能安装任何未经授权的加密软件。
第 262 条
加密算法应该根据算法强度和密钥长度进行选择，以符合信息保护的要求。
第 263 条
数字签名的使用必须符合国家电子签名法的相关规定。
11.3.2 密钥管理
第 264 条
密钥管理系统应该包括以下活动：
1)密钥产生
2)密钥变更
3)密钥存储
4)密钥交换和分发
5)密钥注销
6)密钥恢复和备份
7)密钥销毁
11.4 系统文件的安全
11.4.1 生产系统的应用软件控制
第 265 条
生产系统的应用软件更新必须由获得授权的管理员来执行。
第 266 条
严禁在生产系统中保留应用软件的源代码。必须建立程序库统一保管和维护应用程序的可执行代码。
第 267 条
在测试成功、用户验收完成或相关的程序库被更新前，严禁更新生产系统中的可执行代码。
第 268 条
必须对程序库做好访问控制，并对程序库的更新进行日志记录。
第 269 条
应用软件必须做好版本控制管理，每一个版本都必须有相应的备份。源代码的所有版本都必须保留，并标识版本号，每个版本之间的差异描述要文档化。
11.4.2 测试数据的保护
第 270 条
测试系统应该参照生产系统的访问控制规则进行访问控制。
第 271 条
每次从生产系统中复制数据到测试系统中必须获得授权，并做好记录。从生产系统中复制的数据必须经过处理，去掉有关财务和个人隐私的信息。
11.4.3 对程序源代码库的访问控制
第 272 条
应该建立程序源代码库，并由指定人员进行统一管理。正在开发或修改的程序不应该保存在程序源代码库中。
第 273 条
更新程序源代码库和向程序员提供程序源代码，应通过指定的程序源代码库管理员来执行，并且获得管理层的授权。程序源代码必须保存在安全的环境中。
第 274 条
必须控制程序源代码库的访问，只提供工作需要的最小权限。程序源代码的访问必须做好相关记录。
第 275 条
程序源代码必须做好版本控制管理，每一个版本都必须有相应的备份。
11.5 开发和维护过程中的安全
11.5.1
变更控制流程
第 276 条
所有应用软件的变更必须获得批准。
第 277 条
应用软件的变更需求应该由业务部门授权的资深人员提出。应用软件的变更不应破坏软件本身的可靠性和已有的控制措施。
第 278 条
变更需求中应该包括对运行环境的要求（如硬件资源、软件资源等）。
第 279 条
变更的设计方案必须通过正式的批准才能开始编码。变更在部署之前必须通过验收。
第 280 条
变更的部署必须尽量减少对业务正常运行的影响。
第 281 条
变更完成后，相关的文档（如系统需求文档、设计文档、操作手册、用户手册等）必须得到更新，旧的文档必须进行备份。
第 282 条
必须维护所有软件更新的版本控制。必须维护所有变更需求的记录。
11.5.2 操作系统变更的技术检查
第 283 条
操作系统变更之前必须进行评估，以确保应用程序的完整性和控制措施不会受到破坏。操作系统变更之前必须通知相关人员，以便他们有足够的时间去做相关的评估。
第 284 条
操作系统变更之后必须对业务连续性计划作相应修正。
11.5.3 商业软件的修改限制
第 285 条
由厂家提供的商业软件不应该被修改。如果需要修改商业软件，必须评估下列影响：
1)软件功能和内部的控制措施是否会受到破坏
2)是否会导致厂家的升级包不能使用
3)原厂商对修改过的软件是否不提供维护支持
第 286 条
在进行任何修改之前，必须得到厂家的允许，以保证不侵犯其知识产权。
11.5.4
信息泄漏
第 287 条
软件的开发、采购和使用都应该受到控制和检查，以防范可能的隐秘通道、逻辑炸弹、木马等。以下几点必须被考虑到：
1)只从信誉良好的厂家购买软件
2)关键系统上的工作必须由值得信任的员工担任
3)购买获得国家有关机构认可的软件
4)所有开发的代码都必须进行安全检查，确定无问题后才可以部署在生产环境。
第 288 条
所有源代码应该进行恰当的注释，以方便检查。
11.5.5 软件开发的外包
第 289 条
所有外包开发的软件，必须签定正式的合同，合同内容包括但不限于：
1)确定软件许可证的范围和数量
2)明确代码所有权和知识产权的归属
3)对代码质量的要求
4)有权对软件开发过程进行审计
5)软件维护要求
第 290 条
外包软件在正式使用前，必须经过病毒检测和充分测试。对于提供源代码的外包软件，必须对源代码进行充分的安全检查。
11.6 技术漏洞管理
11.6.1 控制技术漏洞
第 291 条
根据漏洞的严重程度制定漏洞的风险等级评估标准和处理时间要求。
第 292 条
必须建立技术漏洞的监控机制，及时发现漏洞，修补漏洞。定义公司员工在漏洞管理流程中的角色和职责。
第 293 条
补丁在安装之前必须进行测试和评估，确保补丁不会影响系统的正常运行并可以正常回退后才能安装。如果补丁不能安装，必须采取其他的控制措施，控制措施包括但不限于：
1)停止漏洞利用的相关服务或功能
2)增加访问控制阻挡漏洞或缩小漏洞的来源
3)增加监控和检测机制
4)升级防病毒代码库到可以查杀利用漏洞的病毒的版本
5）重要系统必须优先进行漏洞处理。
第 294 条
内部开发的系统在发现漏洞后必须立即开发补丁程序，并在补丁发布前采取其他控制措施，避免漏洞被利用。
