应用开发安全控制程序.docx
- 文档编号:1322699
- 上传时间:2022-10-20
- 格式:DOCX
- 页数:18
- 大小:29.13KB
应用开发安全控制程序.docx
《应用开发安全控制程序.docx》由会员分享,可在线阅读,更多相关《应用开发安全控制程序.docx(18页珍藏版)》请在冰豆网上搜索。
应用开发安全控制程序
1.目的:
随着信息化的发展,应用系统也面临诸多的安全威胁。
身份认证的欺骗、用户权限的滥用、输入数据校验的异常、跨站点的代码攻击、源码泄漏等,都对我司的应用开发提出了新的安全设计和防护要求。
为规范我司在应用系统开发过程的安全性,特制定本文档。
2.适用范围:
本文档适用于我司及子公司的应用系统开发。
3.定义:
无
4.职责
无
5.程序内容
5.1应用系统安全管理基本需求
应用系统的安全管理基本需求应包括如下方面:
应用系统应满足系统对于身份认证的需求,应明确提出用户身份认证体系的强度,认证失败后的处置方式。
应用系统应包含用户权限分配和管理功能,应根据系统所处理的业务数据的保密性和完整性要求,确定系统采用的用户权限访问控制模型和权限的划分,避免权限的过分集中与分散。
应用系统应从数据的可用性角度出发,明确考虑数据安全和冗余恢复相关功能。
应用系统应包括安全审计功能,应明确对于日志内容的要求。
应用系统应当设计基本的数据安全保护功能,包括以下内容:
包括数据采集、数据传输、数据处理、数据存储、数据备份和恢复的安全。
对重要的、敏感数据应当进行加密和完整性保护;
应用系统所在的终端与服务器端之间的、或程序模块之间的通信应有明确而严格的安全保密机制。
5.2应用系统的系统安全管理要求
5.2.1认证
(1)应用系统应该根据应用程序采用合适的认证方式,对于安全要求较低的系统可以采取传统的用户名、密码认证方式,对于安全要求较高的应用系统应该采取安全性更高的认证方式,例如:
指纹认证、智能卡、双因子认证等。
(2)应用系统采用基于口令的身份鉴别机制
实际使用的口令应达到不低于8位字母数字特殊字符组合的口令强度。
用户口令不能明文存放。
必须采用较强的密码算法对用户口令进行加密。
比如类似MD5+Salt这样的不可逆算法。
用户的登录名和口令等是灵活可变的,不应写死在程序中的,可以根据要求随时修改。
限制对用户口令或其它与用户身份认证有关的信息的存取,限制尽可能少的人和应用系统(模块)能存取这些信息。
尽可能避免用户名和口令在非可信网络上以明文方式进行传送。
特别是当这样的传送要通过不安全的网络,比如Internet。
可以考虑采用无需在网上传送用户名和口令的身份认证方式。
如果企业有数量较多的应用系统,为简化对用户的管理,可以考虑采用集中的用户管理系统。
比如使用目录服务器存放用户信息。
使用CA和数字证书进行用户身份认证。
认证失败后的处理方式设计:
连续失败登录后锁定帐号。
帐号锁定后可以由系统管理员解锁,也可以在一段时间后自动解锁;
通知用户认证失败,防止黑客暴力猜测。
(3)根据应用系统对身份认证可靠性的管理策略需求,考虑采用比简单的用户名-口令更强的身份认证方式。
强身份认证方式:
一次性口令、动态口令认证;
证书认证;
生物特征的认证(签名、声音、指纹、虹膜、视网膜等)。
应用系统实现并强制使用了基于密码技术和生物特征识别等的强身份鉴别机制,书面材料能表明使用的密码技术和生物特征识别技术等符合国家的有关政策和标准的规定。
(4)统一认证
a)向用户端提供相应的应用服务模块,面向第三方系统提供相应的身份认证集成接口模块、单点登录集成接口模块、应用服务模块、后台管理模块。
b)统一认证在应用系统里采用模块化的设计,通过功能模块、任务分发器模块、会话管理模块、会话密匙模块、平台管理模块等多模块的设计
c)统一认证应采用安全通信协议对数据进行安全传输,如使用SSL/TLS、HTTPS、SFTP和IPSec等安全协议进行通信。
d)应防止对所传输数据进行XX的任何形式的修改,即对统一认证的重要数据或敏感数据,建议使用MD5、SHA等算法对数据完整性进行保护。
e)应用系统的整个统一认证必须为统一认证中心的设计提供上述接口。
(5)对重要的交互信息,应采取抗抵赖技术,包括但不限于数字签名技术。
(6)数据处理的中间过程和中间结果不能暴露给第三方。
5.2.2授权
(1)应用系统应该包括正式的注册、登录认证和注销模块,并且能够对不同用户的访问权限进行严格的访问控制。
应用系统应提供功能,使得能对用户进行灵活的功能授权,支持用户授权方面的安全管理策略能获得实现。
采用“用户-角色-权限”的权限管理模式应是最起码的要求,用户的权限要求应包括以下方面:
系统读、写、执行权限设计;
系统查看、配置、修改、删除、登录、运行等权限设计;
数据访问范围的权限设计;
应用功能模块使用权限的设计。
(2)对于重要的功能和敏感的数据,能提供数据敏感的授权,限制用户只能在限定的数据集上执行被授权的操作。
(3)很多应用系统采用了多个用户共同使用同一个数据库帐号的方式。
比如应用服务器中的连接池机制。
在这种情况下要避免给这些数据库用户授予过多的权限。
更绝对不能把类似DBA,SchemaOwner,或开发人员使用的帐号这样的数据库帐号用于此类用途。
(4)应用系统中的所有角色、权限、处理的数据对象和操作类型有明确的描述、敏感度标识和分配策略。
(5)应用系统实现了严格的分级授权机制,特定权限的用户只能看到和使用特定的界面和相应的功能。
(6)对业务相关的受理、收费、管理和系统维护等操作人员,根据其岗位和职责设置其操作级别和使用权限,并通过应用系统对其操作日志进行记录。
(7)应用系统开发工作与审计工作应由不同人员承担,同一系统的操作系统管理工作与应用系统管理工作应由不同人员承担。
5.2.3审计
(1)应用系统应该具有完善的日志功能,能够记录系统异常情况及其他安全事件。
审计日志应保留规定的时长,以便支持日后的事件调查和访问控制监控。
审计日志应包括以下内容:
用户创建、删除等操作。
登录和退出的日期和具体时间。
终端的身份或位置(如果可能的话)。
成功的和被拒绝的系统访问活动的记录。
成功的和被拒绝的数据与其他资源的访问记录。
成功的和被拒绝的管理操作记录。
应对系统数据库的直接访问修改留有系统记录。
如果日志记录的操作过多,和记录的信息过多,有可能对系统的性能产生不利影响。
因此应用系统应该提供对于日志的定制功能。
比如允许系统管理员按级别设定需记录日志的操作种类和日志信息的详细程度;或者设定为日志记录设定过滤条件。
不过需注意的是,过于复杂的过滤条件可能会影响日志记录功能的性能。
应用系统应提供对日志的查看功能。
在查看中至少要能按时间、操作人、所做的操作对日志进行过滤查询。
在应用系统的设计和实现中必须考虑对日志的备份。
同时日志记录可能会消耗大量硬盘存储空间,因此需要考虑对日志的清理。
应用系统的登录记录、访问记录,尤其是不成功的登录、访问记录,必须向集中审计系统报告,或由集中审计系统主动查询,保证管理员能够及时发现问题。
(2)应用系统提供了记录安全危害事件并实时报警的安全审计功能以及违例终止功能。
(3)应用系统实现了完备的安全审计,对各级权限用户的所有操作进行审计,审计功能一直有效且不可更改,并只允许授权人员访问审计记录,对审计系统的功能和抗篡改机制有明确的描述和论证。
5.2.4异常处理
1、应用系统不能只依赖对用户输入数据的检查。
在业务逻辑的实现程序入口仍要对调用参数进行检查。
一方面是避免用户界面部分的实现错误,另一方面避免前面的检查被绕过。
2、对于两层的Client/Server应用,可以考虑用存储过程实现业务逻辑,同时限制用户对数据库的写操作,而只能通过存储过程执行业务逻辑。
3、提供功能处理用户的误操作引起的错误。
应用系统必须充分考虑到例外流程的处理。
可以考虑采用“留痕迹的修改”的方式,类似会计制度中的红冲凭证。
4、如果必须提供违反业务流程、业务规则修改数据的功能,对这类功能的使用必须限制在最小范围内。
同时对这类功能的使用必须详细记录在日志中,并且这类操作的日志不能被关掉。
5、应尽可能避免直接修改数据库来修改用户错误的情况。
6、应用软件应包含各模块的出错处理设计。
7、应用软件应包含可能出现的各种异常情况的安全处理设计。
5.2.5系统冗余
(1)在应用系统总体结构的设计或部署中,必须考虑重要子系统、部件的备份,避免单故障点。
(2)应根据业务连续性的要求,采用热备份或冷备份的方式。
5.3应用系统的数据安全管理要求
5.3.1数据输入安全
为了保证系统的安全性,必须在开发过程中对输入到应用系统中的数据进行严格的检查,以确保其正确性及适用性,避免无效数据对系统造成危害,如在JSP应用中,应过滤用户通过WEB提交的输入数据中的特殊字符。
对输入数据的验证一般通过应用系统本身来实现,并应在系统开发中实现输入数据验证功能。
已被正确输入的数据可能受到错误处理或者故意破坏,系统应采取有效的验证检查措施来检测此类破坏,并在应用系统设计时引入数据处理控制,尽可能地减小破坏数据完整性处理故障的几率。
可以采用的控制措施如下:
█应用系统不应在程序或进程中固化账户和口令。
█系统应具备对口令猜测的防范机制和监控手段。
█避免应用程序以错误的顺序运行,或者防止出现故障时后续程序以不正常的流程运行。
█采用正确的故障恢复程序,确保正确处理数据。
█采取会话控制或批次控制,确保更新前后数据文件的一致性,例如:
检查操作前后文件打开和关闭的数目是否一致。
█检查执行操作前后对象的差额是否正常,如:
句柄处理,堆栈等系统资源的占用与释放等。
█严格验证系统生成的数据。
█在中央计算机和远程计算机之间,检查下载/上传的数据或软件的完整性。
█检查文件与记录是否被篡改。
例如通过计算哈希值(HASH)进行对比。
5.3.2数据传输安全
1、应按照数据的类型、数据的重要程度、网络的安全状况等综合因素,对数据的传输采取不同的安全保护,安全措施包括但不限于加密传输、VPN等。
2、应了解数据传输存在安全隐患的网络或设备,对存在安全隐患的网络采取必要的安全技术,包括但不限于安全通信协议、加密算法、完整性检查算法以及抗抵赖攻击。
3、应制定数据传输安全的检查方式,包括但不限于数据传输安全、抗主动攻击能力检查、被动攻击的能力检查。
4、应保障“数据传输安全”有关的重要配置参数安全,包括但不限于口令、加/解密算法、加/解密密钥。
5、应采用安全通信协议对数据进行安全传输,如使用SSL/TLS、HTTPS、SFTP和IPSec等安全协议进行通信。
6、对传输的数据进行不同等级的加密保护,即根据网络或设备的风险、传输内容安全要求的不同,选择不同安全强度的加密算法对信息进行加密传输。
建议使用RSA等高强度的密码算法对非常重要的信息(如口令、加密密钥)进行加密传输;对于普通数据的传输,可以采用DES、3DES等加密算法进行加密传输。
7、应防止对所传输数据进行XX的任何形式的修改,即对业务的重要数据或敏感数据,建议使用MD5、SHA等算法对数据完整性进行保护。
8、对重要的交互信息,建议采取抗抵赖技术,包括但不限于数字签名技术。
9、为了配合网络其它安全设备,建议采用基于用户名/口令的认证技术、VLAN技术、MPLS技术等安全技术手段。
5.3.3数据输出安全
尽管数据的输入和处理是正确的,输出仍然可能包含错误或有害的修改。
因此,应用系统的输出数据应当被验证,以确保数据处理的正确性与合理性。
输出验证包括:
█用以测试输出数据是否合理的似真性检查;例如:
输出数据应在规定的范围内。
█为用户或后续处理系统提供充足的信息,以确定信息的准确性、完整性、精确性和分类级别;例
如:
在输出数据时提供帮助信息。
█可以用来验证输出数据的测试程序。
█规定数据输出过程中相关人员的职责。
5.3.4数据存储、备份和恢复安全
1、对于重要而敏感的数据,在存储和
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 应用 开发 安全 控制程序