应用系统安全规范制定建议.doc
《应用系统安全规范制定建议.doc》由会员分享,可在线阅读,更多相关《应用系统安全规范制定建议.doc(14页珍藏版)》请在咨信网上搜索。
1、应用系统安全规范制定建议 应用系统安全是当前众多大型企业要重点关注的问题,但这块有好多工作要做,现状是现在很多做安全的人,不怎么太做开发,做开发的人懂安全的人又少之又少,这里我从应用系统安全,提出几点自己的建议,当然不足之处还请大家讨论和指正。1 应用系统安全类别划分具体划分准则,需要根据自己单位实际规模和业务特征去定位,我这里把具体的分类细则隐去了,有兴趣的可以讨论.2.1 网络安全性2.1.1 网络接入控制未经批准严禁通过电话线、各类专线接到外网;如确有需求,必须申请备案后先进行与内网完全隔离,才可以实施。2.1.2 网络安全域隔离如果有需要与公司外部通讯的服务器,应在保证自身安全的情况下
2、放入公司防火墙DMZ区,该应用服务器与公司内部系统通讯时,应采用内部读取数据的方式。其他类应用系统 服务器放置在公司内部网中。2.2 系统平台安全性2.2.1 病毒对系统的威胁各应用系统 WINDOWS平台应关闭掉服务器的完全共享,并安装防毒客户端软件,启用实时防护与接受管理,进行周期性对系统全机病毒扫描。2.2.2 黑客破坏和侵入对各应用系统 应及时进行系统补丁的升级和安全配置,并配合进行入侵检测和漏洞扫描等安全检查工作。对于重点系统可以考虑部署主机入侵检测系统来保证主机的安全性。2.3 应用程序安全性2.3.1 在应用系统的生命周期中保证安全应用系统的设计和管理者要在不同的阶段采用相应的工
3、作方法和工作步骤,设计出一个把安全贯穿始终、切实可行的安全方案。对应用系统应能提供书面可行的安全方案。2.3.2 在应用系统启始设计阶段实施安全计划在应用系统启始设计阶段进行充分的安全可行性分析,对应用系统应该进行专门的安全可行性分析。启始设计阶段同时还要进行风险的最初评估,在被选方案之间权衡效费比关系时,应该参照这个估计值,尤其在重点应用系统项目中应特别注重这方面的考虑。2.3.3 在应用系统开发阶段建立安全机制安全需求定义:在软件开发之前,需要了解相关的安全规定和软件运行的环境要求,并对此产生的安全需求做出定义。安全设计:安全设计不能简单依附于系统设计的控制而了事,安全的内容必须渗透到整个
4、设计阶段。当然,也不必对每项设计决定都采取安全方法。通常,有各种方法使其达到必要的安全级别,需要考虑的是如何选择一种折衷方案给安全以适当的地位。良好的安全设计能明显的减少应用系统的脆弱性并减少在系统运行时安全的强制性。对于重点类系统应能够提供这方面的细节说明,以证实安全性设计的有效性。安全的编程方法:(1)所有应用系统 都应正确选择程序设计语言和其它程序设计工具,从而提高最终产品的可靠性和正确性;为提高整个系统的安全性,要恰当地选择并利用这些工具帮助防止程序错误进入源编码。(2)对于重点应用系统 应该严格采用软件工程的方法编制程序,对编码至少由一名未参与程序设计的程序员检查程序编码,全面了解它
5、的安全要点,他与原设计者对程序遗留问题应负有同样的责任。(3)对于重点应用系统 程序库应有仅允许授权人存取程序模块功能,以及记录所有对程序模块存取的安全控制功能。软件安全性的检测和评估: 公司 所有类应用系统综合运用静态和动态检测技术,进行全面认真的检测和评估,发现在应用系统设计和编码中的错误、疏忽和其它缺陷。2.3.4 在操作运行中保障安全数据控制:重点 应用系统应从输入准备、数据媒介存储、输出传播各个阶段所需的控制入手,保证数据安全成功处理。对安全变异的响应: 重点应用系统中,一切与现行安全规定抵触的每一件事或不能解释的结果以及其它异常事件都应视为安全变异现象,应该给予足够的重视,并尽快报
6、告管理员或其他负责人采取必要措施,以减少或消除不安全隐患。报告方式要保密、过程要简单。安全记账与审计:重点应用系统中,应利用应用系统审计日志进行监控,并作为一种主动的监督管理形式和一种检测触犯安全规定事件的手段。同时必须加强对应用系统的审计日志类信息的保护,对审计日志和监控功能的使用也必须做审计记录。2.4 接口安全性2.4.1 接口安全性要求职责分隔:应用系统接口是易受攻击的脆弱点,重点应用系统中,应从职责管理上加强,将责任实现最佳分离。明确敏感客体和操作规定:重点应用系统中,应能够根据可靠性、保密性和可用性三者定义每个数据客体(数据输入、数据存储和数据输出等)的安全需求,并通过系统实施时的
7、培训来落实。错误容限规定:公司各类应用系统 对错误的容限度和在可接受的限度内维护错误级别的需求必须被定义在安全需求中。可用性需求:公司各类应用系统 为避免因为系统不能有效使用而产生的严重危害,必须制定可用性需求,然后根据需求采取措施来保证系统的可用性。2.4.2 接口扩展性要求接口标准性要求:对于各类应用系统 应该能够尽量接口标准化,从而利于应用系统间信息的互通。对于应用系统建设、改造等有代表性的,需要制定相关接口标准,作为将来工作的参照。接口规范细化程度:对于各类应用系统 接口规范应该尽量细化,减少接口描述不清出现新的安全隐患。对于重点 应用系统应该有明确的接口类文档说明部分。2.5 数据安
8、全性2.5.1 数据传输的机密性重点应用系统 中传输关键、敏感数据时要采用传输加密技术,实现数据机密性要求;其他类应用系统应根据具体情况来考虑。密码算法选择: (1) 密码算法必须具有较高的保密强度和抗攻击能力。(2) 加密信息量大时应使用对称加密算法,加密重要信息时应使用非对称加密算法。(3) 要根据所保护信息的敏感程度与攻击者破解所要花的代价值不值得和系统所要求的反应时间来综合考虑决定要采用的密码算法。加解密实现方式:(1) 如果要求全通信业务流机密性,那么应选取物理层加密,或传输安全手段(例如,适当的扩频技术)。(2) 如果要求高粒度保护(即对每个应用联系可能提供不同的密钥)和防抵赖或选
9、择字段保护,应选取表示层加密。(3) 如果希望的是所有端系统到端系统通信的简单块保护,或希望有一个外部的加密设备(例如为了给算法和密钥以物理保护,或防止错误软件),那么应选取网络层加密。这能够提供机密性与不带恢复的完整性。(4) 如果要求带恢复的完整性,同时又具有高粒度保护,那么将选取传输层加密。这能提供机密性、带恢复的完整性或不带恢复的完整性。(5) 不推荐在数据链路层上加密。 当关系到以上问题中的两项或多项时,加密可能需要在多个层上提供。2.5.2 数据传输的完整性数据完整性:对于重点 应用系统,因数据在INTERNET上传播或至关重要,应该保障数据的完整性,针对应用系统信息的重要程度,可
10、以采用不同的数据完整性验证手段。实现完整性方式选择:(1) 由加密提供的数据完整性机制;(2) 基于非对称加密的数据完整性机制,重点类系统应该尽量采用这种方式;(3) 其它数据完整性机制。2.6 用户安全性2.6.1 用户身份认证对身份认证的需求: 对用户身份认证的需求取决于应用系统的性质,对于重点类系统要采用强身份认证方式。身份认证的实现:(1) 弱身份认证方式加强:对口令长度、复杂度、更新周期、保密性等进行严格管理。(2) 强身份认证方式有效保障:对重要应用系统应逐渐倾向于加强的身份认证方式来保证用户身份安全,强身份认证方式可采用证书方式或动态口令方式等来实现。从管理角度考虑:没有一项身份
11、认证技术是绝对可靠的,须依靠严格的强化管理和用户合作来提高认证技术的可靠性,并根据每个系统的实际需要部署,避免造成不必要的负担而影响应用系统的使用。2.6.2 不可否认性对核心系统必须考虑不可否认性的功能,重点系统 应该逐渐考虑系统操作的不可否认性,不可否认性可以用数字签名等来实现。2.6.3授权清晰的授权方案:对重点系统需要有清晰的授权方案,有时不仅要指明应用哪些系统模块,还要明确使用哪台终端。其他应用系统 应能够满足系统功能、角色划分,满足用户需求。授权委托时效性:所有类应用系统 的授权机制应该能够处理、识别、取消或修改授权操作的最终结果。授权数据的保护:(1) 所有类应用系统 的授权系统
12、维护应简单易行,避免发生错误。(2) 重点应用系统 的授权机制应具有自我保护能力。异常情况或不兼容的授权数据应及早发现并报告。授权数据必须认真加以保护,以防任何非授权修改和恶意破坏。2.7 应急计划所有应用系统 应制定相应的应急计划,它是重要的应用系统安全防卫措施。应急计划应该包括操作系统中断、数据库和物理设备被破坏等情况的应急措施,这个计划也应该包括自动或人工过程所需设备的使用步骤。2.7.1 关键功能的鉴别对于重点应用系统 不仅应明确其关键功能的关键作用,而且也应该明确其它功能转变为关键功能之后的那段时间它的作用。2.7.2 替换场所操作对于重点应用系统 要设法在其它部门找到相同或兼容的设
13、备,当紧急情况发生时,这些作为备份的设备有可能分配时间给运行失效的应用系统,这样的替换安排应该是相互的。此外,针对替换场所的通信要设计出一种方法提供足够的传输设备;对配备的人员要进行有针对性的培训。2.7.3 有限的人工替换处理必要时,将某些关键功能恢复成人工处理也是一种补偿办法。对于重点应用系统 如果对应用系统运行的持续性要求较高时,人工操作所需的一切必须事前准备妥当,如要考虑工作场所、实时数据的可用性、书面的原始数据、人工使用的特殊设备、报告格式、通信、传送、人员的选择和培训以及及时记录所有人工传递的处理过程等。2.7.4 数据备份对于重点应用系统 应该根据系统的重要程度制定相应的数据备份
14、策略,并加以落实实施,并能熟练实现在发生数据灾难时的数据快速恢复工作。2.8 安全管理2.8.1 建立管理体制建立管理体制包括建立防范组织、健全规章制度和明确职责任务三部分。管理体制是进行管理的基础,规章制度应在权限的分配过程中建立,并可根据需要参照执行。重点应用系统 应建立良好的管理体制并归档,对于其他类 应用系统应逐步完善管理体制。2.8.2 实施管理措施实施管理措施应以实施存取控制和监督设备运行为主要内容。管理措施是对管理辅之以技术手段,达到强化管理的目的。重点类应用系统 应建立起管理措施对应的规范化流程,其他类应用系统也应该明确其管理措施细节,落实到位。2.8.3 加强教育培训重点类应
15、用系统 安全培训应该以普及安全知识、教授安全措施的具体操作为重点。其他类应用系统应在系统帮助里面注明有关操作条目。应该是个立体的 从网络层-系统层-应用层-后台数据库层面. 都应该考虑 网络层主要考虑数据传输的可靠行和保密性(数据嗅探,监听,劫持) 系统层主要考虑系统自身安全(权限 补丁等等) 应用层考虑代码的强壮性 (开发初期就要注意安全的编码习惯)后期上线的白盒(源代码安全评估阅读-主要靠经验),黑盒测试(web的渗透测试安全检测-应用安全典型十大风险,及目前主流的发展变形技术) 数据库层面 考虑数据库本身安全补丁 端口 权限设置(帐户,服务权限二次设置)等 其他还有很多小的方面 需要有个
16、总体的列表归纳下 需要注意的点 产品方面现在有很多了 国内国外都有ips(国内绿盟,启明的)效果还是不错的(针对应用层说) 慢慢会比较多了 ps-我们公司就在做要上线了 呵呵 总之 应用针对网站的说 需要考虑的因素还是比较多的,需要一个有经验的人把握方方面面 即便一个地方小的疏忽 都很有可能威胁到网站安全设备已经很多了。 除了楼主说的外,我认为应该精力更应该放到细节上,比如 系统安全不只是补丁和漏洞。 1、服务器权限。尽量使用低权限账号,日常登陆服务器及维护站点都用低权限。-防止误操作降低被攻击风险。 2、服务器密码存放。-本地存放和密码策略,密码变更管理等。 3、管理服务器用户的IP限制等
17、4、防DDOS,ARP等大家都说了这么多了:我根据自己的经验。也来说两句。 网络层面:严格的网络防火墙是必要的。抗DDOS也是需要考虑的。同时NIDS可以有效的监控可能带来危害的行为。网络安全本身也是非常重要的。【被嗅探这些也是高危险性的。】 系统层面:对系统的补丁管理,反病毒,单机防火墙,HIPS,IPSEC,防篡改都能有一些帮助。但也有些问题。 1,补丁不及时,不全面。还是被溢出了? 2,杀毒软件杀不了毒。 3,由于应用的复杂性,防火墙设置时候往往不能达到权限最小化。 。 要解决所有这些问题。一是每个方面都要加强,同时不要忽略任意一方面。安全在这里可以说是木桶原理的最好体现了。 应用层面:
18、主要就是代码本身了。代码本身若不安全,做太多的措施也是,只要一个sql注入就全玩玩了。如何编写安全的web 代码,可以参照owasp。 个人认为在配iis也有很多的安全窍门。【比如urlscan过滤啊等】 数据库层:数据库的安全加固往往大家容易忽略。这方面可以参考cis相关资料。 另外:重中之重:是要建立一套完整的风险管理体系。风险评估,渗透测试,安全加固等等等等。网站架构和访问控制权限上下手,如果为前台静态发布+管理发布生成控制台+后台数据库+各模块,架构安全了,再谈其他的首先看一下三层架构的组成: 一:界面层 界面层提供给用户一个视觉上的界面,通过界面层,用户输入数据、获取数据。界面层同时
19、也提供一定的安全性,确保用户有会看到机密的信息。 二:逻辑层 逻辑层是界面层和数据层的桥梁,它响应界面层的用户请求,执行任务并从数据层抓取数据,并将必要的数据传送给界面层。 三:数据层 数据层定义、维护数据的完整性、安全性,它响应逻辑层的请求,访问数据。这一层通常由大型的数据库服务器实现,如Oracle 、Sybase、MS SQl Server等。 下面是三层架构的优势分析: 从开发角度和应用角度来看,三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发,每人可以有不同的分工,协同工作使效率倍增。开发双层或单层应用时,每个开发人员都应对系统有较深的理解,能力要求很高,开发三层应用时,
20、则可以结合多方面的人才,只需少数人对系统全面了解,从一定程度工降低了开发的难度。 三层架构属于瘦客户的模式,用户端只需一个较小的硬盘、较小的内存、较慢的CPU就可以获得不错的性能。相比之下,单层或胖客户对面器的要求太高。 三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行,充分利用网络的计算功能。分布式计算的潜力巨大,远比升级CPU有效。 三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层,减少了入口点,把很多危险的系统功能都屏蔽了。 另外三层架构还可以支持如下功能:Remote Access(远程访问资料),例如可透过Internet存取
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 应用 系统安全 规范 制定 建议
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【a199****6536】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【a199****6536】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。