

03.产品设计

作者：Pa55w0rd

协作：

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

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

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

自身结构中各组件之间通讯过程的安全机制
组件之间的通讯包括命令级的和数据级的，应充分考虑：
- 传输命令和数据所采用的协议的安全性。应根据组件之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；
- 考虑程序的模块之间的安全通讯机制；
- 不应使用标准的服务端口或者常见病毒、蠕虫等使用的服务端口。
认证与访问控制机制，应考虑：
- 组件之间的信任机制；
- 用户的身份认证机制；
- 对于组件资源的访问控制机制；
- 不通用户对资源的权限控制机制。
组件内重要文件和数据的安全防护机制：
存在于组件内部的重要数据资源应当考虑其相应的安全防护机制，这些重要的数据资源包括：
- 配置文件；
- 用户数据，包括文件数据及数据库中的数据；
- 临时文件和数据；
- 与外系统或者系统内部其他组件接口用的数据文件。
对这些重要数据的存取安全性设计，包括: - 文件和数据存放是否加密及采用的加密方式。

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

应用系统与外系统的接口安全设计，主要应考虑以下几个要素： 1. 与外系统的之间通讯中的安全机制。应充分考虑： - 传输命令和数据所采用的协议的安全性。应根据系统之间通讯内容安全性要求程度的不同选择不同安全性要求的协议； - 建议不使用默认的服务端口或者常见病毒、蠕虫等使用的服务端口。

与外系统的认证与访问控制机制，应考虑：
系统之间的信任机制；
对于系统之间资源的访问控制机制。
对外系统安全机制的符合性，应考虑：
如果外系统采用的接口方式经评估认为是安全的，本系统应当沿用其接口规范进行设计开发；
如果外系统采用的接口方式经评估认为存在安全缺陷，应商定采用更加安全的接口方式；
在考虑接口安全性的同时，也应当注意接口方式对双方系统性能、磁盘、连接数等各种性能指标和资源的影响。

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

除了上述基本的安全架构设计内容外，针对不同的应用，以及应用系统的重要程度，可以补充考虑以下几种安全机制： 1. 针对Web应用的页面保护与恢复机制。
利用专用的安全产品，或者系统自身设计时就考虑到了对于Web页面进行静态保护和监控问题，当监控到网页被篡改时能够实时恢复页面。 2. 针对特殊数据的完整性检查和监控机制。
应用系统自身的审计机制。这一点也可算作是应用系统的安全功能设计的一部分，参见相关章节的要求。 3. 应用系统安全性分析。
任何系统都会存在一定的安全缺陷，关键在于风险和缺陷是否可以被容忍，因此，在应用系统设计完成后，应当就其安全性问题进行自我分析和评价。

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

除了在架构上考虑的安全机制外，这些安全机制及相关的安全功能也应当分配在应用系统软件的各部件中。应用系统在开发中应该考虑如下五个方面的安全功能： - 安全审计； - 通讯安全（此部分内容在架构中进行了设计）； - 数据保护； - 认证与授权； - 资源保障。

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

应用软件应包含用户身份认证体系的强度设计,重要系统应使用双因素认证措施，加强系统安全性：
用户名、口令认证；
一次性口令、动态口令认证；
证书认证；（可选）
生物特征的认证（签名、声音、指纹、虹膜、视网膜等）。（可选）
应用软件应包含认证失败后的处理方式设计
连续失败3次，将锁定登录账号一个小时。账号锁定后可以由系统管理员解锁，也可以在一段时间后自动解锁；
通知用户认证失败，防止黑客暴力猜测；
验证码的功能；
账号复杂度提醒功能。
应用软件应包含用户权限分配和管理功能设计。
系统编码中要实现读、写、执行三个权限的分离设计；
系统查看、配置、修改、删除、登录、运行等权限设计；
数据访问范围的权限设计；
应用功能模块使用权限的设计。
应用软件应包含接口设计，应明确系统的内部结构和外部接口，对于每一个对外接口应详细说明：
需要通信的对方系统的安全状况和可信程度；
需传送的数据的保密性和完整性要求；
对传送数据的合法性检验规则；
对通信可靠性的要求；
与外部系统的互相认证方面的需求。

2.2.数据安全功能

应用系统的数据安全功能，应当根据安全需求进行功能设计，内容涉及：数据库的安全、数据采集、数据传输、数据处理、数据存储、数据备份和恢复的安全。对重要的敏感数据应进行加密和完整性保护。
应用软件应包含输入的安全性设计，主要指对错误输入、恶意输入进行处理。
应用软件应包含输出的安全性设计。

2.3.安全审计功能

应用系统具备如下安全审计功能：
审计功能的启动和关闭；
变更审计功能的配置信息；
至少应进行审计的事件：进入和退出的时间(登录、退出系统)、异常的系统使用行为(失败登录)、系统维护行为、敏感行为和其它安全功能要求的审计内容；
每个审计记录中至少记录如下信息：事件的日期和时间、事件的类型、主题标识、事件的结果(成功、失败)和事件相关信息。
应用系统应支持数据查阅审计功能：按照主题、事件查阅；应用系统应明确用户能够查阅审计数据用户。
在意外情况出现时，应有措施保证审计数据的可用性，当审计记录溢出时采取保护行动。

2.4.容错功能设计

应用软件应包含各模块的出错处理设计。
应用软件应包含可能出现的各种异常情况的安全处理设计。
应用软件应包含抗网络攻击的能力的设计及系统脆弱性分析。4、对于应用软件本身的资源及服务的优先保障设计。

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

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

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

应依据对于应用数据的测算，估算应用系统的存储容量，建议在存储容量估算时应考虑以下要求： - 在实际估算值上预留20%的存储余量，并考虑未来的应用存储量的增长需求。 - 考虑到应用系统自身的审计数据的容量、保存期限以配置相应的存储设备。 - 对于应用系统中的临时数据和过渡数据，应当设计其保存的时间，并以此考虑这部分的存储容量要求。

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

应用系统的存储介质主要包括但不限于：磁带、纸带、闪存、软盘、光盘、磁盘和磁盘阵列。具体存储介质的选择应依据应用系统的业务种类及存储周期的要求，采用不同的介质。 1. 对于应用系统的交易数据，应采用高性能、高可靠的存储介质，如磁盘、磁盘阵列等进行存储； 2. 对于应用系统的历史数据，应采用可靠、稳定的存储介质，如磁带、光盘等进行存储。

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

应用系统对于其储存备份的对象设计，应包括如下内容： 1. 系统数据的备份：应包括Web服务器的网站内容、Mail服务器的邮件实时备份、数据库、文件服务器中的文件以及其他数据； 2. 系统的完全备份：应包括关键的、需要快速恢复的设备，通过磁带机的完全备份，应实现快速的灾难恢复； 3. 系统的冗余主机备份：对于关键并且不能停止的服务设备（如计费服务、Web、Mail服务器），应考虑使用多台主机进行冗余备份，以保证当任何一台主机发生故障时，服务器仍可提供服务； 4. 系统配置的备份：应包括关键路由器的配置、防火墙的配置、各类服务器操作系统的安全配置以及各类服务器（如Web、Mail、文件服务器等）中服务器软件（如Apache、Sendmail）的配置。

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

应用系统应当根据不同的阶段，系统数据不同的重要程度，对数据采取不同的备份方式： 1. 完全备份
使用备份介质对整个系统进行完全备份，包括系统和数据。这种备份方式的优点是直观，容易被人理解，而且当数据丢失时，可以快速恢复丢失的数据。它也有不足之处，即： - 定期对系统进行完全备份，因此在备份数据中有大量的重复信息，占用了大量的存贮空间，增加了备份成本； - 需要备份的数据量大，因此备份所需要的时间较长。
建议在关键性应用系统的实施前、实施后、变更以及升级等重要操作时，对操作系统进行完全备份。针对信息较小的不断变化的，且变化的内容大于 50％的，定期进行完全备份。 2. 增量备份
每次备份的数据只是相当于上一次备份后增加和修改过的数据。没有重复的备份数据，节省备份介质的空间，缩短了备份时间。这种备份的优点很明显，同时也存在某些不足之处，即当发生灾难时，恢复数据比较麻烦。建议在关键性应用系统正常运行维护阶段，针对变化的、不断增加的信息，定期进行增量备份。 3. 差异备份
每次备份的数据只是相当于上一次完全备份后新增加和修改过的数据，即采用完全备份和差异备份相结合备份策略。如每周日进行一次完全备份，而周一至周六进行差异备份。其优点为：没有重复的备份数据，即节省备份介质的空间，缩短了备份时间；缺点为：当发生灾难时，恢复数据比较麻烦。建议应用系统的正常运行维护阶段，针对不断变化的（变化的内容小于 50％）系统，定期进行差异备份。 4. 按需备份
按需备份是指在正常的备份安排之外，额外进行的备份操作，这种备份方式可以弥补冗余管理以及长期转存的日常备份的不足。因此它是一种非常灵活、重要的备份方式，在应用系统的各个阶段，如果备份的内容较少，可以采用按需备份。
建议应用系统在下列情况下采取按需备份： - 只需要备份很少的几个文件、目录、数据库或数据库中的表； - 备份服务器上必要的配置文件。 5. 排除备份
排除备份是指排除不需要的文件后再进行备份。从本质上讲，排除备份不是一种备份方法，只是减少备份冗余的一种方法。
建议应用系统在下列情况下考虑排除备份： - 有些文件非常大，但并不重要； - 某些文件总是导致备份异常或出错。

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

应用系统存储设备的功能要求应包括如下内容： 1. 存储设备应保证数据的高可用性和完整性要求； 2. 存储设备应具有在多主机环境下工作的能力； 3. 存储设备应能方便地做到快速备份和恢复，重要系统应做到双机备份、支持热插拔； 4. 存储设备应有简便的、功能强大的管理工具，做到对整个存储系统的监视与控制。

4.应用系统通讯安全设计要求

应采用安全通信协议对重要数据进行安全传输（尤其是账号、口令信息），如使用SSL/TLS、HTTPS、SFTP和IPSec等安全协议进行通信：
终端与服务器端之间的WWW服务，建议使用HTTPS安全通信协议；
终端与服务器端之间的FTP服务，建议使SFTP安全通信协议；
终端与服务器端之间的Telnet服务，建议使SSH安全通信协议。
终端应用程序采用加密传输机制对重要信息进行传输。
终端应用程序采用完整性检查对业务的重要数据或敏感数据进行检查。
终端应用程序应采用抗抵赖攻击技术对重要的交互信息进行保护。
终端应用程序使用固定的通信端口。

5.应用系统数据库安全设计要求

应从以下方面进行数据库的选型：
数据库、应用系统的运行环境；
数据库的稳定性、安全性（多级安全）；
数据库的容量（最多支持的库的数目、表的数目、记录数目）；
数据库的存取速度；
是否支持多种备份方式；
是否支持数据库的导入和导出。
应明确数据库相关的用户管理、资源管理、特权管理和角色管理，明确各种用户的资源权限，并建立规范的权限文档。
数据库原则上应及时更新重要补丁。在安装补丁前应先在测试环境进行，提前进行数据备份，充分准备回退方案和应急预案。
数据库的配置应符合相应的基线配置要求。
应及时修改数据库的默认密码或将默认账号锁定、删除。
数据库的账号应根据业务和维护需要进行合理分配，避免账号共用。

6.应用系统数据安全设计要求

6.1.数据采集安全

应根据数据采集的内容、采集的频率、数据精确度要求、时间特性等来进行数据采集的安全要求设计，数据采集服务器和采集主机应考虑30%的系统开销及冗余。

6.2.数据传输安全

应按照数据的类型、数据的重要程度、网络的安全状况等综合因素，对数据的传输采取不同的安全保护，包括但不限于防火墙、IDS、VPN、病毒防护等安全措施。
应了解数据传输存在安全隐患的网络或设备，对存在安全隐患的网络采取必要的安全技术，包括但不限于安全通信协议、加密算法、完整性检查算法以及抗抵赖攻击方法等。
应制定数据传输安全的检查方式，包括但不限于数据传输安全抗主动攻击能力检查、被动抗攻击的能力检查。
应保障“数据传输安全”有关的重要配置参数安全，包括但不限于口令、加/解密算法、加/解密密钥等。
应采用安全通信协议对数据进行安全传输，如使用SSL/TLS、HTTPS、 SFTP和IPSec等安全协议进行通信。
对传输的信息进行不同等级的加密保护，即根据网络或设备的风险、传输内容安全要求的不同，选择不同安全强度的加密算法对信息进行加密传输。建议使用RSA等高强度的密码算法对非常重要的信息（如口令、加密密钥）进行加密传输；对于普通数据的传输，可以采用DES、3DES 等加密算法进行加密传输。
应防止对所传输数据进行未经授权的任何形式的修改，即对业务的重要数据或敏感数据，建议使用MD5、SHA等算法对数据完整性进行保护。
对重要的交互信息，建议采取抗抵赖技术，包括但不限于数字签名技术。
为了配合网络其它安全设备，建议采用基于用户名/口令的认证技术、 VLAN技术、MPLS技术等安全技术手段。

6.3.数据处理安全

应根据数据的类型、数据的处理方式、数据的安全性要求、与其它接口有关的敏感等级、数据相关业务应用的重要性程度来进行数据处理过程的安全性设计。
应对原始数据进行检错和校验操作，保证原始数据的正确性和完整性。
数据在转换过程中，应采用通用的标准格式，应考虑相关的不同系统和不同应用的格式需求。
数据处理过程应提供处理数据的状态信息和数据处理过程的动态信息。
数据处理过程应具备异常处理功能，在任一环节发现问题，均应能及时回退，必要时可以人工处理。
数据处理的中间过程和中间结果不能暴露给第三方。