9A文应用开发安全指南.docx

9A文应用开发安全指南.docx

《9A文应用开发安全指南.docx》由会员分享，可在线阅读，更多相关《9A文应用开发安全指南.docx（27页珍藏版）》请在冰豆网上搜索。

9A文应用开发安全指南

应用开发安全指南

1.概述

本指南的编制是在《CTG-MBOSSIT总体规范V1.0》的总体框架体系指导下，参考了《中国电信CTG-MBOSSIT安全规范V1.0》及近年来发布的其他安全政策和指导意见相关内容，继承和吸收了原有安全管理实践的经验成果，并充分考虑了各省电信公司的现状和行业最佳实践与安全新技术的引入。

本指南是IT安全保障体系建设规范的一个组成部分，全面阐述了IT系统应用开发整个软件生命周期所必须遵照的设计、编码、测试方面的安全要求，阐述了不同开发环境和编码语言条件下安全开发的相关规范要求。

1.1.目的

本指南针对中国电信IT应用系统应当遵循的应用开发安全标准进行了规范性说明，旨在指导应用系统设计人员、代码开发人员和安全检查管理人员进行应用安全开发的安全配置，以提高应用系统的安全防护能力。

1.2.适用范围

本指南适用于中国电信IT系统代码开发项目，作为中国电信集团公司、各省公司在IT系统开发、设计环节中所遵照执行的依据。

1.3.适用对象

本配置指南的适用人员包括：

中国电信IT系统应用开发人员及安全检查管理人员。

1.4.规范文档

《应用开发安全指南》在中国电信集团公司IT安全保障体系建设规范中

的位置如下图所示：

策略

规范

指南

管理分册技术分册

中国电信IT安全保障

体系建设规范

要求

规范

指南

规范总册

2.应用系统设计安全

2.1.应用系统架构安全设计要求

在应用系统设计阶段，应充分考虑该架构的安全性,包括B/S、C/S等形式的安全，主要体现在应用数据和用户会话的安全，还应当考虑应用系统自身体系架构内部的安全，以及与外系统接口的安全。

针对某些特殊应用，还需考虑恢复、抗攻击等安全机制。

2.1.1.应用系统自身架构安全

1、自身结构中各组件之间通讯过程的安全机制

组件之间的通讯包括命令级的和数据级的，应充分考虑：

●传输命令和数据所采用的协议的安全性。

应根据组件之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；

●考虑程序的模块之间的安全通讯机制；

●不应使用标准的服务端口或者常见病毒、蠕虫等使用的服务端口。

2、认证与访问控制机制，应考虑：

●组件之间的信任机制；

●用户的身份认证机制；

●对于组件资源的访问控制机制。

3、组件内重要文件和数据的安全防护机制：

●存在于组件内部的重要数据资源应当考虑其相应的安全防护机制，这些重要的数据资源包括：

⏹配置文件；

⏹用户数据，包括文件数据及数据库中的数据；

⏹临时文件和数据；

⏹与外系统或者系统内部其他组件接口用的数据文件。

●对这些重要数据的存取安全性设计，包括:

⏹文件和数据存放是否加密及采用的加密方式。

2.1.2.应用系统与外系统接口的安全

应用系统与外系统的接口安全设计，主要应考虑以下几个要素：

1、与外系统的之间通讯中的安全机制。

应充分考虑：

●传输命令和数据所采用的协议的安全性。

应根据系统之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；

●建议不使用默认的服务端口或者常见病毒、蠕虫等使用的服务端口。

2、与外系统的认证与访问控制机制，应考虑：

●系统之间的信任机制；

●对于系统之间资源的访问控制机制。

3、对外系统安全机制的符合性，应考虑：

●如果外系统采用的接口方式经评估认为是安全的，本系统应当沿用其接口规范进行设计开发；

●如果外系统采用的接口方式经评估认为存在安全缺陷，应商定采用更加安全的接口方式；

●在考虑接口安全性的同时，也应当注意接口方式对双方系统性能、磁盘、连接数等各种性能指标和资源的影响。

2.1.3.应用系统其他的安全机制

除了上述基本的安全架构设计内容外，针对不同的应用，以及应用系统的重要程度，可以补充考虑以下几种安全机制：

1、针对Web应用的页面保护与恢复机制。

利用专用的安全产品，或者系统自身设计时就考虑到了对于Web页面进行静态保护和监控问题，当监控到网页被篡改时能够实时恢复页面。

2、针对特殊数据的完整性检查和监控机制。

应用系统自身的审计机制。

这一点也可算作是应用系统的安全功能设计的一部分，参见相关章节的要求。

3、应用系统安全性分析。

任何系统都会存在一定的安全缺陷，关键在于风险和缺陷是否可以被容忍，因此，在应用系统设计完成后，应当就其安全性问题进行自我分析和评价。

2.2.应用系统软件功能安全设计要求

除了在架构上考虑的安全机制外，这些安全机制及相关的安全功能也应当分配在应用系统软件的各部件中。

应用系统在开发中应该考虑如下五个方面的安全功能：

●安全审计；

●通讯安全（此部分内容在架构中进行了设计）；

●数据保护；

●认证与授权；

●资源保障。

2.2.1.认证与授权功能的设计

1、应用软件应包含用户身份认证体系的强度设计,重要系统（例如2.2级别以上系统）应使用双因素认证措施，加强系统安全性：

●用户名、口令认证；

●一次性口令、动态口令认证；

●证书认证；（可选）

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

（可选）

2、应用软件应包含认证失败后的处理方式设计

●连续失败3次，将锁定登录账号一个小时。

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

●通知用户认证失败，防止黑客暴力猜测；

●验证码的功能；

●账号复杂度提醒功能。

3、应用软件应包含用户权限分配和管理功能设计。

●系统编码中要实现读、写、执行三个权限的分离设计；

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

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

●应用功能模块使用权限的设计。

4、应用软件应包含接口设计，应明确系统的内部结构和外部接口，对于每

一个对外接口应详细说明：

●需要通信的对方系统的安全状况和可信程度；

●需传送的数据的保密性和完整性要求；

●对传送数据的合法性检验规则；

●对通信可靠性的要求；

●与外部系统的互相认证方面的需求。

5、应用系统认证与授权功能除满足上述要求外，具体要求请参考《IT安全管控平台建设规范》中安全支撑平台建设对应用系统的集中认证授权改造要求。

2.2.2.数据安全功能

1、应用系统的数据安全功能，应当根据安全需求进行功能设计，内容涉及：

数据库的安全、数据采集、数据传输、数据处理、数据存储、数据备份和恢复的安全。

对重要的敏感数据应进行加密和完整性保护。

2、应用软件应包含输入的安全性设计，主要指对错误输入、恶意输入进行处理。

3、应用软件应包含输出的安全性设计。

2.2.3.安全审计功能

1、应用系统具备如下安全审计功能：

●审计功能的启动和关闭；

●变更审计功能的配置信息；

●至少应进行审计的事件：

进入和退出的时间（登录、退出系统）、异常的系统使用行为（失败登录）、系统维护行为、敏感行为和其它安全功能要求的审计内容；

●每个审计记录中至少记录如下信息：

事件的日期和时间、事件的类型、主题标识、事件的结果（成功、失败）和事件相关信息。

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

按照主题、事件查阅；应用系统应明确用户能够查阅审计数据用户。

3、在意外情况出现时，应有措施保证审计数据的可用性，当审计记录溢出时采取保护行动。

2.2.4.容错功能设计

1、应用软件应包含各模块的出错处理设计。

2、应用软件应包含可能出现的各种异常情况的安全处理设计。

3、应用软件应包含抗网络攻击的能力的设计及系统脆弱性分析。

4、对于应用软件本身的资源及服务的优先保障设计。

2.3.应用系统存储安全设计要求

在应用系统存储安全设计时，应对系统的存储容量、存储介质、存储备份内容、存储备份方式、存储设备功能要求及相关的存储技术统筹进行考虑。

2.3.1.应用系统的存储容量设计

应依据对于应用数据的测算，估算应用系统的存储容量，建议在存储容量估算时应考虑以下要求：

在实际估算值上预留20%的存储余量，并考虑未来的应用存储量的增长需求。

考虑到应用系统自身的审计数据的容量、保存期限以配置相应的存储设备。

对于应用系统中的临时数据和过渡数据，应当设计其保存的时间，并以此考虑这部分的存储容量要求。

2.3.2.应用系统的存储介质选择

应用系统的存储介质主要包括但不限于：

磁带、纸带、闪存、软盘、光盘、磁盘和磁盘阵列。

具体存储介质的选择应依据应用系统的业务种类及存储周期的要求，采用不同的介质。

1、对于应用系统的交易数据，应采用高性能、高可靠的存储介质，如磁盘、磁盘阵列等进行存储；

2、对于应用系统的历史数据，应采用可靠、稳定的存储介质，如磁带、光盘等进行存储。

2.3.3.应用系统存储备份对象

应用系统对于其储存备份的对象设计，应包括如下内容：

1、系统数据的备份：

应包括Web服务器的网站内容、Mail服务器的邮件实时备份、数据库、文件服务器中的文件以及其他数据；

2、系统的完全备份：

应包括关键的、需要快速恢复的设备，通过磁带机的完全备份，应实现快速的灾难恢复；

3、系统的冗余主机备份：

对于关键并且不能停止的服务设备（如计费服务、Web、Mail服务器），应考虑使用多台主机进行冗余备份，以保证当任何一台主机发生故障时，服务器仍可提供服务；

4、系统配置的备份：

应包括关键路由器的配置、防火墙的配置、各类服务器操作系统的安全配置以及各类服务器（如Web、Mail、文件服务器等）中服务器软件（如Apache、Sendmail）的配置。

2.3.4.应用系统存储备份方式

应用系统应当根据不同的阶段，系统数据不同的重要程度，对数据采取不同的备份方式：

1、完全备份

使用备份介质对整个系统进行完全备份，包括系统和数据。

这种备份方式的优点是直观，容易被人理解，而且当数据丢失时，可以快速恢复丢失的数据。

它也有不足之处，即：

●定期对系统进行完全备份，因此在备份数据中有大量的重复信息，占用了大量的存贮空间，增加了备份成本；

●需要备份的数据量大，因此备份所需要的时间较长。

建议在关键性应用系统的实施前、实施后、变更以及升级等重要操作时，对操作系统进行完全备份。

针对信息较小的不断变化的，且变化的内容大于50％的，定期进行完全备份。

2、增量备份

每次备份的数据只是相当于上一次备份后增加和修改过的数据。

没有重复的备份数据，节省备份介质的空间，缩短了备份时间。

这种备份的优点很明显，同时也存在某些不足之处，即当发生灾难时，恢复数据比较麻烦。

建议在关键性应用系统正常运行维护阶段，针对变化的、不断增加的信息，定期进行增量备份。

3、差异备份

每次备份的数据只是相当于上一次完全备份后新增加和修改过的数据，即采用完全备份和差异备份相结合备份策略。

如每周日进行一次完全备份，而周一至周六进行差异备份。

其优点为：

没有重复的备份数据，即节省备份介质的空间，缩短了备份时间；缺点为：

当发生灾难时，恢复数据比较麻烦。

建议应用系统的正常运行维护阶段，针对不断变化的（变化的内容小于50％）系统，定期进行差异备份。

4、按需备份

按需备份是指在正常的备份安排之外，额外进行的备份操作，这种备份方式可以弥补冗余管理以及长期转存的日常备份的不足。

因此它是一种非常灵活、重要的备份方式，在应用系统的各个阶段，如果备份的内容较少，可以采用按需备份。

建议应用系统在下列情况下采取按需备份：

●只需要备份很少的几个文件、目录、数据库或数据库中的表；

●备份服务器上必要的配置文件。

5、排除备份

排除备份是指排除不需要的文件后再进行备份。

从本质上讲，排除备份不是一种备份方法，只是减少备份冗余的一种方法。

建议应用系统在下列情况下考虑排除备份：

●有些文件非常大，但并不重要；

●某些文件总是导致备份异常或出错。

2.3.5.应用系统的存储设备功能要求

应用系统存储设备的功能要求应