ImageVerifierCode 换一换
格式:DOCX , 页数:13 ,大小:31.02KB ,
资源ID:13007037      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/13007037.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(应用软件开发安全规范Word格式文档下载.docx)为本站会员(b****9)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

应用软件开发安全规范Word格式文档下载.docx

1、l 对应用系统的维护操作,包括参数修改 日志应该至少记录以下信息:l 事件的发起源 l 用户标识(终端用户实体或系统内部调用用户) l 事件类型 l 事件的日期和时间 l 事件的结果:成功或失败 l 受影响的数据或资源 5明确应用系统所处理的业务数据范围和内容,针对不同安全级别的数据在应用系统不同处理过程中对机密性、完整性和可用性的要求,定义其对安全保护的具体需求。6针对不同数据对安全保护的要求,评估应用系统相关的硬件平台、操作系统、基础架构、网络通信、中间件和服务是否能够满足要求。7针对应用中对数据处理的整个过程,明确其对监控和检查的要求,包括日志审计、完整性检查、出错检查等。设计阶段为了保

2、证应用系统的安全性,外部系统的安全应当包括如下几个方面:l 应用系统服务器硬件物理安全 l 应用系统服务器操作系统安全 l 应用系统数据库的安全 l 应用系统的存储安全 l 应用系统用户终端安全 l 应用系统网络通信安全身份识别和认证不同安全级别的系统对用户身份识别和认证体系的强度要求也不同, 按照强度由低到高分别有以下几种方式:l 用户名、口令认证 l 一次性口令、动态口令认证 l 证书认证 l 生物特征的认证(指纹、掌纹、视网膜等)认证失败后的处理方式:l 连续失败的登录尝试后锁定帐号,并把事件内容记录到审计日志中。l 以电子邮件或短信等方式通知用户认证失败。帐号的管理l 帐号生命周期管理

3、:帐号的生成、变更、挂起和删除等建议由集中的身份管理平台完成。如果在应用系统内部实现账号生命周期管理,要充分考虑各个阶段对安全的要求。l 帐号存储模式:应用系统的帐号要求使用支持 LDAP 目录的存储方式。如果应用系统因为某种原因不能使用企业级 LDAP 目录存储帐号(或者企业级 LDAP 尚未建立),对于同一类型的应用,要尽量使用同一个 LDAP 目录存储帐号信息,这一目录要求定期与企业级LDAP 目录进行同步。l 帐号的命名规范:应用系统的帐号命名规则和结构要符合企业统一的帐号命名规范和结构定义。应用系统的口令规则需要符合企业统一的账号口令管理规范的要求。对密码本身的保护:l 避免存储实际

4、密码:验证密码可以通过存储密码的单向哈希值,然后使用用户所提交的密码重新计算哈希值进行比对来实现。l 不在网络上以明文方式传输密码:以明文方式在网络上传输的密码容易被窃听,为了解决这一问题,应确保通信通道的安全,例如,使用 SSL 对数据流加密。l 保护身份认证的凭据:身份认证的凭据(如 Cookie)被窃取意味着登录被窃取。可以通过加密和安全的通信通道来保护认证的凭据。此外,还应限制认证凭据的有效期,以减少攻击的威胁。访问控制和授权应用系统的认证、授权尽量使用统一的认证、授权平台来进行。如果因为某种原因需要建立应用系统自己的认证、授权体系,整个认证过程需要进行加密,密钥长度不能低于 128

5、位。8应用系统的设计应包含用户权限分配和管理功能:l 系统读、写、执行权限设计l 系统查看、配置、修改、删除、登录、运行等权限设计 l 数据访问范围的权限设计 l 应用功能模块使用权限的设计 9限制用户的权限:l 限制用户对系统级资源的访问,包括文件、文件夹、注册表项、LDAP 对象、数据库对象、日志文件等;l 应用系统使用的数据库帐号必须是普通权限帐号,只能访问允许的数据库;l 应用系统启动进程的权限尽可能小;l 合理设计用户权限的颗粒度,满足授权最小原则。10输入数据验证采用输入复核或其他输入检查方式,例如边界检查、限制数据输入字段的范围和类型等,检验是否有以下输入错误:l 输入过长 l

6、输入数据字段中有非法字符 l 输入为空或者不完整 l 输入值超过上限或下限11l 在服务器端进行验证:应使用服务器端代码执行其数据的输入验证。如果使用客户端验证方式,有可能发生攻击者绕过客户端验证或关闭客户端验证脚本进程的情况。l 输入标准化:标准化是指将输入数据转化为标准形式的过程。在接受文件名输入、URL 或用户名输入时必须先进行标准化。l 限制、拒绝和净化输入:输入验证的首选方法是从一开始就限制l 允许输入的内容,并按照已知的有效类型、模式和范围验证数据。l 清晰定义数据输入处理流程中涉及人员的责任。12数据处理控制 l 要有措施保证应用程序按照正确的运行次序执行,如果出错就中断执行,后

7、续处理过程将暂停运行直到错误排除,防止在前一流程出错的基础上继续运行。l 应根据数据的类型、数据的处理方式、数据的安全性要求、与其它接口有关的敏感等级、数据相关业务应用的重要性程度来进行数据处理过程的安全性设计。l 应对原始数据需要进行检错和校验操作,保证原始数据的正确性和完整性。l 数据在转换过程中,应采用通用的标准格式,应考虑相关的不同系统和不同应用的格式要求。l 数据处理过程应保留处理数据的状态信息(日志)。l 数据处理过程应具备异常处理功能,在任一环节发现问题,均能及时回退,必要时可以人工处理。13数据输出验证 l 验证输出的数据是否准确、合理。l 要保证所有的数据都被处理了。l 数据

8、输出验证过程应保留验证过程的相关信息(日志)。14配置管理 应用系统配置管理安全设计要求:l 应用系统配置管理功能只能由经过授权的操作员和管理员进行,建议使用强身份认证手段,如使用双因素认证。避免使用远程配置管理。l 建议使用基于角色的授权策略分别为操作员、管理员授权。l 针对进程帐号、服务帐号等系统内部帐号,其权限配置应遵循权限最小原则15配置管理确保配置信息本身的安全:基于文本的配置文件、注册表和数据库是存储应用程序配置信息的常用方法。应避免在应用程序的Web空间使用配置文件,以防止可能出现的因服务器漏洞而导致配置文件被下载或篡改。应避免以明文形式存储加密配置信息,如数据库连接字符串或认证

9、凭据,应该通过加密确保这些信息的安全。同时必须限制对包含加密数据的注册表项、文件或表的访问权限。16敏感数据的保护l 处理诸如信用卡卡号、持卡人个人信息、账户信息、密码、证书等敏感信息的应用程序应该采取专门的处理流程,以确保这些数据的保密性和完整性,包括使用足够强度的加密算法保护其保密性和使用哈希算法进行完整性校验。l 尽量避免存储机密信息:存储在系统中的机密信息即使经过加密也无法保证完全安全,可以接触到服务器的系统管理员就可以访问这些数据。替代的方法可以用哈希值比对的方式。l 不要在代码中包含敏感信息:不要在代码中对敏感信息进行硬编码,例如 IP 地址、口令等。即使源代码不会泄漏,但从编译过

10、的可执行文件中仍然可以提取字符串常量。配置漏洞可能会允许攻击者检索可执行文件,从而获取敏感信息。l 不要以明文形式存储数据库连接字符串或密码等敏感信息,应该进行加密,并存储经过加密的字符串。l 如果通过网络传输敏感数据,禁止明文传输,应对数据进行加密。同时确保通信通道的安全,通常的做法是使用SSL/TLS、HTTPS、SFTP 和 IPSec 等安全协议进行通信。异常处理 l 不要向客户端泄漏应用程序内部信息:发生故障时,不要在出错消息中暴露应用系统内部的敏感信息。例如,不要暴露包括函数名以及调试信息(出问题的行数,堆栈信息等)。应向客户端返回一般性错误消息。l 记录详细的错误信息:向错误事件

11、日志发送详细的错误消息,同时确保没有记录密码或其他敏感数据。开发阶段 应用开发环境的安全要求l 开发环境应划定专门的安全区域,如非必需,禁止或限制与生产网和互联网的互联。l 存储项目文档、代码的服务器必须有严格的访问控制管理、备份制度。l 对项目文档和代码的访问应严格受控。l 对项目文档和代码要采取版本管理和控制。l 开发终端的安全要求至少要和办公用终端有同样的安全要求。应用开发文档的安全要求l 开发各阶段输出的文档应有相应的安全方面的内容。l 需求说明书中应明确描述用户的安全需求。l 设计中应有针对安全需求的设计,并需要经过评审。l 在测试计划或者测试方案中应有安全性测试方案,并据此进行安全

12、性测试,保留测试记录。l 文档应参照安全分类要求设定安全级别,读者范围,并有相应的授权机制,以控制对文档访问。l 文档作为应用软件开发中的配置项,应遵循软件配置管理要求。l 文档应有专用的服务器(或文件柜)进行保存和备份(复制),对于电子文档应有版本控制。应用开发的代码安全要求l 应对函数入口参数的合法性和准确性进行检查。l 代码设计尽量简单清晰,如果设计过于复杂,就会给相应的安全设计带来很大的难度,而最终导致安全性的下降。l 必须严格遵循 Fail-Safe 原则,即当发生问题时,必须能自动切换到最安全的保护模式。举例来说,当软件的登录验证机制不可正常运作时,软件必须自动拒绝所有登录请求,而

13、不是接受所有登录请求。l 禁止开发人员为普通的软件进程分配系统特权帐号软件(例如系统管理员、root 等)。l 禁止接受不满足安全标准的登录密码。l 所有缺省安全设置必须能同时满足系统正常运行和系统安全两方面的要求。l 在所有警告或提示对话窗口中所使用准确、明了的描述性语言,并提供有关帮助链接。l 在接受用户输入时,必须有数据合法性检查,并严格规定输入数据的字符长度。l 隐藏所有敏感的信息。l 在输入密码等敏感信息时,使用星号来代替输入的字符。l 在设计基于Web 的软件时,必须确保当用户注销会话进程后,包含敏感信息的页面不能通过使用浏览器的回退(Back)按钮来显示。l 禁止使用未经授权和验证的代码。l 如果密码由软件生成,则必须保证有足够的长度和随机性;如果密码由用户生成,则软件必须有“密码安全过滤”设计来拒绝接受不满足安全要求的密码。l 禁止以明文方式传递和存储用户密码。l 使用第三方代码,应对代码安全性进行评估和测试。l 应注释代码中无用的语句。l 对代码进行版本控制,确保代码的可用性。l 防止程序员非授权修改代码禁止在程序中添加隐藏“恶意”的代码,防止与应用系统相关的程序员对系统的非授权修改。规范代码的格式:l 规范变量、函数的命名 l 规范程序的书写格式,确保程序的易读性 应用系统的安全测试:应用系统的安全性测试

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1