软件开发 安全管理-软件安全实现安全编程技术

PAGE \* MERGEFORMAT 1 鄂尔多斯电力局企业规章制度 OEP-IRM.2-103-2011 软件开发安全管理办法 2011-5-27 发布 2011-6-1 实施 鄂尔多斯电力局发布 软件开发安全管理办法 总则目的为提高鄂尔多斯电力局软件开发安全管理水平，特制定本管理办法。 适用范围 本管理办法适用于应用系统软件开发从规划、需求、设计、开发、测试和部署过程中的安全管理。 规范性引用文件 内蒙古电力（集团）有限责任公司软件开发安全管理规定（内电生[2009]24号） 术语和定义 CMM认证 CMM是Capability Maturity Model的简称，用于评价软件承包能力. 并帮助他们提高软件质量，着重于软件开发过程的管理和工程能力的提升与评估。 CMM分为五个层次：第一层次为初始层次，第二层次为可重复层次，第三层次为定义层次，第四层次为管理层次，第五层次为优化层次。 职责 生产技术部职责如下： 归口办公室负责软件开发安全管理工作的监督检查和考核； 开发环境应设置独立的工作区，并根据应用系统的开发需求，对该区进行网络访问控制和监控。 物理访问控制，确保开发数据的安全。 项目文件和代码的存储应进行备份，以确保在发生事故时能够有效恢复。 在开发环境中，应该提供版本管理和对项目文档和代码的访问控制。

用于开发的服务器和个人电脑必须采取严格的安全措施，包括但不限于更新系统补丁、安装杀毒软件（防火墙）、设置密码策略等。 文档 安全应用系统开发过程的每个阶段都应该有开发文档的输出。 为文档的安全方面做出了规定。 内容包括文档内容的安全性和文档本身的安全性： 文档内容的安全性：每个开发阶段输出的文档都应该描述安全内容。 应用系统的安全需求应在需求说明书中明确描述。 安全要求的设计规范应包含在设计规范中，并应进行审查。 测试大纲或测试计划中应有安全测试计划，用于安全测试。 文档本身的安全性：文档应设置机密级别和阅读范围以限制其访问。 文件访问控制应有相应的授权机制。 文档应在专用服务器或文件柜中保存和备份，电子文档应进行版本控制。 源代码管理 为第三方开发应用系统时，按照协议进行源代码管理。 建立专用的源代码管理服务器，有效管理程序源代码。 源代码管理应保留所有历史版本，以便于参考。 开发完成并通过测试后，开发者必须提交源代码归档申请，并将所有程序源代码和设置等配套文件打包，交由归档室。 代码在提交前必须通过安全检查。 源码审核通过后，档案馆将进行信息登记，并将源码上传至管理服务器。

对于已有系统（或功能、模块等）的代码文件或设置文件，需要修改时，修改者必须提交源代码修改申请软件开发 安全管理，源代码修改后方可上传存档。生产技术部的批准。 （或设置文件）提取并交给编辑修改。 修改后提交前需要通过安全检查，防止代码中隐藏通道和木马。 检查过的源代码（或配置文件）被返回到档案库以上传到源代码控制服务器。 重新上传后，必须给出新的版本号。 定期（每年）对源代码修改记录进行审计，对所有修改记录进行抽查，检查是否存在未经批准的源代码修改，源代码修改内容与申请内容是否一致。 需求阶段 需求阶段是整个应用生命周期的起点，这个阶段决定了整个应用系统的安全目标和实现方式。 在需求阶段确定安全功能，识别和区分软件需求的安全程度，描述每个需求项的安全性，从而在软件需求中生成各阶段的安全措施。 讨论所有确定的安全需求并形成项目安全文档，用于整个项目的设计、实施和测试，并确保主要开发人员持有该文档。 在需求分析阶段，需要明确以下与安全相关的需求：用户数、终端数、并发在线人数； 用户角色划分和权限分配； 应用系统性能要求； 现有网络状况和网络性能要求； 数据量估算、数据存储方式和周期； 系统安全级别和数据保密要求； 网络、存储、服务器、终端、操作系统、数据库、数据等的其他安全要求。

在需求阶段，应确定应用系统的安全功能需求：应用系统应包含认证功能，明确用户身份认证系统的强度和认证失败后的处理方法。 应用系统应包括用户权限的分配和管理功能。 根据系统处理的业务数据的保密性和完整性要求，确定系统采用的用户权限访问控制模型和权限划分，避免权限过度集中和分散。 应用系统应包括与数据安全和冗余恢复相关的功能。 应用系统应包含安全审计功能，并明确日志内容要求，包括但不限于：应用系统审计的事件应包括：审计功能的启动和关闭； 修改审计功能的配置信息； 事件：进入和退出时间（登录、注销系统）； 异常的系统使用行为（登录失败）； 系统维护行为； 敏感的操作行为； 审计其他安全功能所需的内容。 每份审计记录中至少应记录以下信息： 事件的日期和时间； 活动类型； 主题识别； 事件的结果（成功、失败）和事件相关的信息。 应用系统应支持按主题和事件进行数据查询、审计等功能； 应用系统应控制用户对审计数据的访问； 在发生意外情况（数据丢失、损坏等）时，应采取措施确保审计数据的可用性，并在审计记录溢出时及时采取应急措施。 在需求阶段，确定以下应用系统数据需求：定义系统中的敏感数据，并划定这些敏感数据的安全级别。

定义应用系统数据的机密性、完整性和可用性要求，检查其基本运行环境（网络、主机等）是否满足这些要求。 规划划分数据用户，明确用户（权限）的级别和类别，划定权限的粒度（单用户权限模式或组用户权限模式等），最终形成权限部署视图。 设计应用系统中数据的类型和分布方式，检查数据传输和分布过程中涉及的基础环境和软件架构是否满足安全要求。 （账户数据和实际业务数据的安全要求有不同的侧重点，前者侧重于机密性，而后者更侧重于完整性）。 当应用系统中的数据发生变化时，需要对哪些类型的数据进行审计和跟踪，以及采取措施的粒度（完整性检查、错误检测和相应的恢复机制等）一目了然。 应用安全功能设计身份认证用户身份认证系统可以采用以下类型：用户名、密码认证； 一次性密码、动态密码认证； 证书认证； 生物特征认证（签名、语音、指纹、虹膜、视网膜等） 根据应用系统的重要程度合理使用认证方式。 例如，资金管理系统可以使用数字签名认证。 认证失败后的处理应该设计成：连续登录失败后锁定账号。 账户被锁定后，可由系统管理员解锁，也可在一段时间后自动解锁。 通知用户认证失败，防止黑客暴力破解。 账户的创建、修改、变更、删除都需要通过一个集中的身份管理平台来完成。

将应用系统划分为公共访问区和限制访问区。 禁区只接受特定用户的访问软件开发 安全管理，用户必须通过身份认证。 当未经身份验证的用户试图访问受限资源时，应用系统应自动提示用户进行身份验证。 内部系统密码规则应符合密码管理规则，设置密码强度。 如果系统受到威胁，凭证可能会失效或帐户会被禁用。 支持密码有效期。 密码不应是固定的，而应通过设置密码有效期作为定期密码维护的一部分进行更改。 不要通过网络以纯文本形式发送密码。 身份验证 cookie 被盗意味着登录被盗，身份验证凭据受到加密和安全通信通道的保护。 同时，限制认证凭证的有效期，以防止因重复攻击而造成的欺骗威胁。 登录时使用随机验证码验证机制，防止恶意用户暴力破解。 授权应用系统应包括用户权限分配和管理功能设计系​​统读、写、执行权限设计； 系统查看、配置、修改、删除、登录、操作等权限设计； 数据访问范围的权限设计； 设计;