软件开发安全管理办法.docx

软件开发安全管理办法.docx

《软件开发安全管理办法.docx》由会员分享，可在线阅读，更多相关《软件开发安全管理办法.docx（18页珍藏版）》请在冰豆网上搜索。

鄂尔多斯电业局企业规章制度

OEP-IRM.2-103-2011

软件开发安全管理办法

2011-5-27发布 2011-6-1实施

鄂尔多斯电业局 发布

18

软件开发安全管理办法

第一章 总则

第一条目的

为了提高鄂尔多斯电业局软件开发安全管理水平，特制定本管理办法。

第二条适用范围

本管理办法适用于应用系统软件开发从计划、需求、设计、开发、测试、部署过程中的安全管理。

第三条规范性引用文件

内蒙古电力（集团）有限责任公司软件开发安全管理规定（内电生[2009]24号）

第四条术语和定义

（一）CMM认证

CMM是能力成熟度模型的缩写，是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。

CMM分为五个等级：

一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。

第五条职责

（一）生产技术处的职责如下：

1. 归口负责软件开发安全管理工作的监督、检查和考核；

第二章 开发环境安全

第六条开发环境应设置独立的工作区域，并根据应用系统的开发要求，对该区域进行网络访问控制和物理访问控制，确保开发数据的安全性。

第七条项目文档、代码的存储应进行备份，以确保在发生意外时，可有效恢复。

第八条在开发环境中，应提供对项目文档和代码版本管理和访问控制。

第九条用于开发的服务器、个人电脑必须做好严格的安全防护措施，包括但不仅限于更新系统补丁、安装防病毒软件（防火墙）、设置密码策略。

第三章 文档安全

第十条应用系统开发过程的各阶段都应有开发文档的输出。

第十一条 对文档的安全性方面的内容给予规定。

内容包括对于文档内容的安全和文档自身的安全：

（一）文档内容的安全：

1.开发各阶段输出的文档应对安全性方面的内容进行描述。

2.需求说明书中应明确描述应用系统的安全需求。

3.设计说明书中应有针对安全需求的设计，并进行评审。

4.在测试大纲或者测试方案中应有安全性测试方案，并以此进行安全性测试。

（二）文档自身的安全：

1.文档应设定密级及读者范围，以限定其访问范围。

2.文档的访问控制应有相应的授权机制。

3.文档应有专用的服务器或文件柜进行保存和备份，对于电子文档应有版本控制。

第四章 源代码管理

第十二条当应用系统为第三方开发时，根据协议执行源代码的管理。

第十三条建立专门的源代码管理服务器，用于对程序源代码实施有效管理。

第十四条源代码管理应保存所有的历史版本，以便查阅。

第十五条在开发完成并通过测试后，开发人员必须提出源代码归档申请，并将所有的程序源代码以及设置等支持文件打包，交付档案室，代码在提交前必须通过安全检查。

通过检查后的源代码由档案室进行信息的登记并将源代码上传到管理服务器。

第十六条 对于已有系统（或功能、模块等）的代码文件或设置文件，在需要对其进行修改时，

必须由修改人提出源代码修改申请，并且经过生产技术处批准后，档案室才能将源代码（或设置文件）提取出来，交给修改人进行修改。

修改完毕需通过安全检查才可以提交，防止代码中存在隐蔽通道和木马。

通过检查后的源代码（或设置文件）交还档案室，由其上传到源代码管理服务器。

重新上传后，必须给予新的版本号。

第十七条 定期（每年）对源代码的修改记录进行审计，对所有修改记录进行抽查，检查是否存在未经审批的源代码修改情况以及源代码修改内容是否与申请内容相符。

第五章 需求阶段

第十八条需求阶段是整个应用生命周期的起始点，这个阶段决定了整个应用系统的安全目标和实现方法。

应在需求阶段确定安全功能，对软件需求的安全程度进行识别和区分，对各需求项的安全性进行描述，以便在软件需求中生成各阶段的安全措施。

第十九条 讨论确定的所有安全需求，形成项目安全保障文件，该文件将用于整个项目的设计、实现、测试环节，并保证主要开发人员持有该文件。

第二十条在需求分析阶段应明确以下与安全相关的需求:

（一）用户数、终端数、在线并发数；

（二）用户角色的划分和权限的分配；

（三）应用系统性能要求；

（四）现有网络现状和网络性能要求；

（五）数据量估计、数据存储方式和周期；

（六）系统安全级别和数据保密性要求；

（七）其他对网络、存储、服务器、终端、操作系统、数据库、数据等方面的安全需求。

第二十一条在需求阶段应确定应用系统安全功能需求：

（一）应用系统应包含认证功能，应明确提出用户身份认证体系的强度以及认证失败后的处理方式。

（二）应用系统应包含用户权限的分配和管理功能，应根据系统处理的业务数据的保密性和完整性要求，确定系统采用的用户权限访问控制模型和权限的划分，避免权限的过分集中与分散。

（三）应用系统应包括数据安全和冗余恢复相关功能。

（四）应用系统应包括安全审计功能，应明确对于日志内容的要求，包括但不限于以下内容：

1.应用系统审计的事件应包括：

（1）审计功能的启动和关闭；

（2）变更审计功能的配置信息；

（3）至少应进行审计的事件：

a.进入和退出的时间（登录、退出系统）；

b.异常的系统使用行为（登录失败）；

c.系统维护行为；

d.敏感的操作行为；

e.其它安全功能要求的审计内容。

（4）每个审计记录中应至少记录如下信息：

a.事件的日期和时间；

b.事件的类型；

c.主题标识；

d.事件的结果（成功、失败）和事件相关信息。

2.应用系统应支持数据查阅、审计等功能

（1）按照主题、事件查阅；

（2）应用系统应控制用户查阅审计数据的权限；

（3）在意外情况（数据丢失、损坏等）出现时，应有措施保证审计数据的可用性及当审计记录溢出时的应急措施。

第二十二条 在需求阶段确定以下应用系统数据的需求：

（一）定义系统中的敏感数据，为这些敏感数据的安全级别进行划定。

（二）定义应用系统的数据的机密性、完整性和可用性要求，根据这个要求检查运行的基础环境

（网络、主机等）是否符合。

（三）规划并划分数据的使用者，明确使用者（权限）的层次和类别，对权限的颗粒度进行划定

（单个用户权限模式还是组用户权限模式等），最终形成权限部署视图。

（四）设计应用系统中数据的类型和分发方式，检查在数据的传输和分发过程中所涉及的基础环境和软件架构是否满足安全性要求。

（帐号数据和实际业务数据的安全性要求的侧重点不一样，前者侧重于机密性，而后者更侧重于完整性）。

（五）当应用系统中的数据进行变更的时候，明确何种类型的数据需要进行审计和追踪，以及所采取的措施的精细程度（完整性检查、错误检测和相应的恢复机制等）。

第六章 应用安全功能设计

第二十三条 身份认证

（一）用户身份认证体系可以采用以下几种：

1.用户名、口令认证；

2.一次性口令、动态口令认证；

3.证书认证；

4.生物特征的认证（签名、声音、指纹、虹膜、视网膜等）

5.应根据应用系统的重要程度合理使用认证方式，如资金管理系统可以采用数字签名认证。

（二）认证失败后的处理应采用以下方式设计：

1.连续失败登录后锁定帐号。

帐号锁定后可以由系统管理员解锁，也可以在一段时间后自动解锁。

2.通知用户认证失败，防止黑客暴力破解。

（三）帐号的创建、修改、变更、删除需要由集中的身份管理平台完成。

（四）将应用系统分割为公共访问区域和受限访问区域，受限区域只接受特定用户的访问，而且用户必须通过身份认证。

当未经认证的用户试图访问受限资源时，应用系统应自动提示用户认证。

（五）内部系统的口令规则应符合口令管理规则，应设置密码强度。

（六）在系统受到威胁时可以使凭证失效或禁用帐户。

（七）支持密码有效期，密码不应固定不变，而应作为常规密码维护的一部分，通过设置密码有效期对密码进行更改。

（八）在网络中禁止以纯文本形式发送密码。

（九）身份验证cookie被窃取意味着登录被窃取，通过加密和安全的通信通道保护验证凭证。

另外，还应限制验证凭证的有效期，以防止因重复攻击导致的欺骗威胁。

（十）在登录时使用随机验证码校验机制，防止恶意用户的暴力破解。

第二十四条 授权

（一）应用系统应包含用户权限分配和管理功能设计

1.系统读、写、执行权限设计；

2.系统查看、配置、修改、删除、登录、运行等权限设计；

3.数据访问范围的权限设计；

4.应用功能模块使用权限的设计；

（二）限制用户对系统级资源的访问，系统级的资源包括：

文件、文件夹、注册表项、Active

Directory对象、数据库对象、事件日志的系统资源。

（三）程序应使用尽可能小的权限

1.应用系统使用的数据库帐号必须是普通权限帐户，只限访问允许的数据库；

2.数据库访问应该使用低权限数据库账号（如选择，删除，更新，插入等）通过参数化的存储过程来访问；

3.应用启动进程的权限尽可能小；

4.应用使用的系统账号（运行环境中的）应该有尽可能低的权限。

应避免“Administrator”,“root”,“sa”,“sysman”,“Supervisor”或其它所有的特权用户被用来运行应用系统或连接到网站服务器，数据库或中间件。

（四）授权颗粒度要尽可能小。

第二十五条 输入输出验证

（一）对所有的输入进行安全验证，无论输入是来自服务、共享。

（二）文件、用户或是数据库，只要来源不在可信任的范围之内，就应对输入进行验证。

（三）采用集中验证方法，输入验证策略作为应用系统设计的核心元素。

考虑集中验证方法。

通过使用共享库中的公共验证和筛选代码。

这可确保验证规则应用的一致性。

（四）为了防止攻击者绕过客户端直接验证，在服务器端进行验证时，必须使用服务器端代码执行验证。

（五）按照已知的有效类型、模式和范围验证数据。

应限制用户输入并验证数据的类型、长度、格式和范围。

（六）进行数据库操作时，对用户提交的数据必须过滤特殊字符或使用中间件调用数据库。

（七）当使用XML文件格式存储数据时，若使用Xpath和XSLT功能，必须过滤用户提交数据中的<>

/'="等字符。

第二十六条 配置管理

（一）配置管理功能应禁止未授权访问。

在管理界面上实施强身份验证，如使用证书，应限制或避免使用远程管理，并要求管理员在本地登录。

如需要支持远程管理，应使用加密通道，如SSL或

VPN技术。

（二）避免在应用系统的 Web 空间使用配置文件，以防止出现的服务器配置漏洞而导致配置文件被非法下载。

（三）应避免以明文的形式存储机密，如数据库连接字符串或帐户凭据。

应通过加密确保这些数据的安全，并限制对包含加密数据的注册表项、文件或表的访问权限。

（四）如应用系统的配置管理功能会因管理员角色而变化，则应使用基于角色的授权策略分别为每个角色授权。

第二十七条 敏感数据

（一）应用系统中应尽量避免存储机密。

（二）禁止在代码中对机密进行硬编码。

即使未将源代码暴露在 Web 服务器上，但从编译过的可执行文件中仍然可以提取字符串常量。

配置