应用开发安全指南文档格式.docx
- 文档编号:15018206
- 上传时间:2022-10-26
- 格式:DOCX
- 页数:30
- 大小:40.06KB
应用开发安全指南文档格式.docx
《应用开发安全指南文档格式.docx》由会员分享,可在线阅读,更多相关《应用开发安全指南文档格式.docx(30页珍藏版)》请在冰豆网上搜索。
组件之间的通讯包括命令级的和数据级的,应充分考虑:
●传输命令和数据所采用的协议的安全性。
应根据组件之间通讯内容安全性要求程度的不同选择不同安全性要求的协议;
●考虑程序的模块之间的安全通讯机制;
●不应使用标准的服务端口或者常见病毒、蠕虫等使用的服务端口。
2、认证与访问控制机制,应考虑:
●组件之间的信任机制;
●用户的身份认证机制;
●对于组件资源的访问控制机制;
●不通用户对资源的权限控制机制。
3、组件内重要文件和数据的安全防护机制:
存在于组件内部的重要数据资源应当考虑其相应的安全防护机制,这些重要的数据资源包括:
●配置文件;
●用户数据,包括文件数据及数据库中的数据;
●临时文件和数据;
●与外系统或者系统内部其他组件接口用的数据文件。
对这些重要数据的存取安全性设计,包括:
●文件和数据存放是否加密及采用的加密方式。
2.1.2应用系统与外系统接口的安全
应用系统与外系统的接口安全设计,主要应考虑以下几个要素:
1、与外系统的之间通讯中的安全机制。
应充分考虑:
应根据系统之间通讯内容安全性要求程度的不同选择不同安全性要求的协议;
●建议不使用默认的服务端口或者常见病毒、蠕虫等使用的服务端口,传输过程使用加密传输。
2、与外系统的认证与访问控制机制,应考虑:
●系统之间的信任机制;
●会话凭据的有效时间;
●可以访问资源的权限控制;
●对于系统之间资源的访问控制机制。
3、对外系统安全机制的符合性,应考虑:
●如果外系统采用的接口方式经评估认为是安全的,本系统应当沿用其接口规范进行设计开发;
●如果外系统采用的接口方式经评估认为存在安全缺陷,应商定采用更加安全的接口方式;
●在考虑接口安全性的同时,也应当注意接口方式对双方系统性能、磁盘、连接数等各种性能指标和资源的影响。
2.1.3应用系统其他的安全机制
除了上述基本的安全架构设计内容外,针对不同的应用,以及应用系统的重要程度,可以补充考虑以下几种安全机制:
1、针对应用的页面保护与恢复机制。
利用专用的安全产品,或者系统自身设计时就考虑到了对于页面进行静态保护和监控问题,当监控到网页被篡改时能够实时恢复页面。
2、针对特殊数据的完整性检查和监控机制。
应用系统自身的审计机制。
这一点也可算作是应用系统的安全功能设计的一部分,参见相关章节的要求。
3、针对重要系统的攻击的解决方案。
4、应用系统安全性分析。
5、除了使用技术手段保证接口安全的同时,也需要保证接口相关代码和文件不被上传到互联网或泄漏给非必要人员。
任何系统都会存在一定的安全缺陷,关键在于风险和缺陷是否可以被容忍,因此,在应用系统设计完成后,应当就其安全性问题进行自我分析和评价。
2.2应用系统软件功能安全设计要求
除了在架构上考虑的安全机制外,这些安全机制及相关的安全功能也应当分配在应用系统软件的各部件中。
应用系统在开发中应该考虑如下几个方面的安全功能:
●安全审计;
●通讯安全(此部分内容在架构中进行了设计);
●数据保护;
●认证与授权;
●资源保障;
●最小权限。
2.2.1认证与授权功能的设计
1、应用软件应包含用户身份认证体系的强度设计,重要系统应使用双因素或多因素认证措施,加强系统安全性:
●用户名、口令认证;
●一次性口令、动态口令认证;
●证书认证;
(可选)
●生物特征的认证(签名、声音、指纹、虹膜、视网膜等)。
2、应用软件应包含认证失败后的处理方式设计
●连续失败3次,将锁定登录账号一个小时。
账号锁定后可以由系统管理员解锁,也可以在一段时间后自动解锁;
●通知用户认证失败,防止黑客暴力猜测;
●验证码的功能,需要一定复杂度,防止被机器识别;
●账号复杂度提醒功能。
3、应用软件应包含用户权限分配和管理功能设计。
●系统编码中要实现读、写、执行三个权限的分离设计;
●系统查看、配置、修改、删除、登录、运行等权限设计;
●数据访问范围的权限设计;
●针对不同用户的数据库表权限隔离;
●应用功能模块使用权限的设计。
4、应用软件应包含接口设计,应明确系统的内部结构和外部接口,对于每一个对外接口应详细说明:
●需要通信的对方系统的安全状况和可信程度;
●需传送的数据的保密性和完整性要求;
●对传送数据的合法性检验规则;
●对通信可靠性的要求;
●与外部系统的互相认证方面的需求;
●信息传输过程的加密需求。
2.2.2数据安全功能
1、应用系统的数据安全功能,应当根据安全需求进行功能设计,内容涉及:
数据库的安全、数据采集、数据传输、数据处理、数据存储、数据备份和恢复的安全。
对重要的敏感数据应进行加密和完整性保护。
2、应用软件应包含输入的安全性设计,主要指对错误输入、恶意输入进行处理。
3、应用软件应包含输出的安全性设计。
2.2.3安全审计功能
1、应用系统具备如下安全审计功能:
●审计功能的启动和关闭;
●变更审计功能的配置信息;
●至少应进行审计的事件:
进入和退出的时间(登录、退出系统)、异常的系统使用行为(失败登录)、系统维护行为、敏感行为和其它安全功能要求的审计内容;
●每个审计记录中至少记录如下信息:
事件的日期和时间、事件的类型、主题标识、事件的结果(成功、失败)和事件相关信息。
2、应用系统应支持数据查阅审计功能:
按照主题、事件查阅;
应用系统应明确用户能够查阅审计数据用户。
3、在意外情况出现时,应有措施保证审计数据的可用性,当审计记录溢出时采取保护行动。
2.2.4容错功能设计
1、应用软件应包含各模块的出错处理设计。
2、应用软件应包含可能出现的各种异常情况的安全处理设计,如:
错误信息不回显给用户。
3、应用软件应包含抗网络攻击的能力的设计及系统脆弱性分析。
4、对于应用软件本身的资源及服务的优先保障设计。
2.3应用系统存储安全设计要求
在应用系统存储安全设计时,应对系统的存储容量、存储介质、存储备份内容、存储备份方式、存储设备功能要求及相关的存储技术统筹进行考虑。
2.3.1应用系统的存储容量设计
应依据对于应用数据的测算,估算应用系统的存储容量,建议在存储容量估算时应考虑以下要求:
●在实际估算值上预留30%的存储余量,并考虑未来的应用存储量的增长需求。
●考虑到应用系统自身的审计数据的容量、保存期限以配置相应的存储设备。
●对于应用系统中的临时数据和过渡数据,应当设计其保存的时间,并以此考虑这部分的存储容量要求。
2.3.2应用系统的存储介质选择
应用系统的存储介质主要包括但不限于:
磁带、光盘、磁盘、磁盘阵列和云存储。
具体存储介质的选择应依据应用系统的业务种类及存储周期的要求,采用不同的介质。
1、对于应用系统的交易数据,应采用高性能、高可靠的存储介质,如磁盘、磁盘阵列、云存储等进行存储;
2、对于应用系统的历史数据,应采用可靠、稳定的存储介质,如磁带、光盘等进行存储。
2.3.3应用系统存储备份对象
应用系统对于其储存备份的对象设计,应包括如下内容:
1、系统数据的备份:
应包括服务器的网站内容、服务器的邮件实时备份、数据库、文件服务器中的文件以及其他数据;
2、系统的完全备份:
应包括关键的、需要快速恢复的设备,通过磁带机的完全备份,应实现快速的灾难恢复;
3、系统的冗余主机备份:
对于关键并且不能停止的服务设备(如计费服务、、服务器),应考虑使用多台主机进行冗余备份,以保证当任何一台主机发生故障时,服务器仍可提供服务;
4、系统配置的备份:
应包括关键路由器的配置、防火墙的配置、各类服务器操作系统的安全配置以及各类服务器(如、、文件服务器等)中间件和容器(如、、、等)的配置。
2.3.4应用系统存储备份方式
应用系统应当根据不同的阶段,系统数据不同的重要程度,对数据采取不同的备份方式:
1、完全备份
使用备份介质对整个系统进行完全备份,包括系统和数据。
这种备份方
式的优点是直观,容易被人理解,而且当数据丢失时,可以快速恢复丢失的数据。
它也有不足之处:
●定期对系统进行完全备份,因此在备份数据中有大量的重复信息,占用了大量的存贮空间,增加了备份成本;
●需要备份的数据量大,因此备份所需要的时间较长。
●建议在关键性应用系统的实施前、实施后、变更以及升级等重要操作时,对操作系统进行完全备份。
针对信息较小的不断变化的,且变化的内容大于50%的,定期进行完全备份。
2、增量备份
每次备份的数据只是相当于上一次备份后增加和修改过的数据。
没有重复的备份数据,节省备份介质的空间,缩短了备份时间。
这种备份的优点很明显,同时也存在某些不足之处,即当发生灾难时,恢复数据比较麻烦。
建议在关键性应用系统正常运行维护阶段,针对变化的、不断增加的信息,定期进行增量备份。
3、差异备份
每次备份的数据只是相当于上一次完全备份后新增加和修改过的数据,即采用完全备份和差异备份相结合备份策略。
如:
每周日进行一次完全备份,而周一至周六进行差异备份。
其优点为:
没有重复的备份数据,即节省备份介质的空间,缩短了备份时间;
缺点为:
当发生灾难时,恢复数据比较麻烦。
建议应用系统的正常运行维护阶段,针对不断变化的(变化的内容小于
50%)系统,定期进行差异备份。
4、按需备份
按需备份是指在正常的备份安排之外,额外进行的备份操作,这种备份方式可以弥补冗余管理以及长期转存的日常备份的不足。
因此它是一种非常灵活、重要的备份方式,在应用系统的各个阶段,如果备份的内容较少,可以采用按需备份。
建议应用系统在下列情况下采取按需备份:
●只需要备份很少的几个文件、目录、数据库或数据库中的表;
●备份服务器上必要的配置文件。
5、排除备份
排除备份是指排除不需要的文件后再进行备份。
从本质上讲,排除备份不是一种备份方法,只是减少备份冗余的一种方法。
建议应用系统在下列情况下考虑排除备份:
●有些文件非常大,但并不重要;
●某些文件总是导致备份异常或出错。
6、备份恢复测试
不管是全备、增备、差异、按需还是排除备份,都应该定期对已被分的数据进行恢复测试,保证备份数据的可用性,在关键时刻可以及时并快速的恢复系统。
2.3.5应用系统的存储设备功能要求
应用系统存
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 应用 开发 安全 指南
![提示](https://static.bdocx.com/images/bang_tan.gif)