应用系统安全规范制定建议.docx

应用系统安全规范制定建议.docx

《应用系统安全规范制定建议.docx》由会员分享，可在线阅读，更多相关《应用系统安全规范制定建议.docx（13页珍藏版）》请在冰豆网上搜索。

应用系统安全规范制定建议

应用系统安全规范制定建议

  应用系统安全是当前众多大型企业要重点关注的问题,但这块有好多工作要做,现状是现在很多做安全的人,不怎么太做开发,做开发的人懂安全的人又少之又少,这里我从应用系统安全,提出几点自己的建议,当然不足之处还请大家讨论和指正。

1应用系统安全类别划分

  具体划分准则,需要根据自己单位实际规模和业务特征去定位,我这里把具体的分类细则隐去了,有兴趣的可以讨论.

2.1网络安全性

2.1.1网络接入控制

未经批准严禁通过电话线、各类专线接到外网；如确有需求，必须申请备案后先进行与内网完全隔离，才可以实施。

2.1.2网络安全域隔离

如果有需要与公司外部通讯的服务器，应在保证自身安全的情况下放入公司防火墙DMZ区，该应用服务器与公司内部系统通讯时，应采用内部读取数据的方式。

其他类应用系统服务器放置在公司内部网中。

2.2系统平台安全性

2.2.1病毒对系统的威胁

各应用系统WINDOWS平台应关闭掉服务器的完全共享，并安装防毒客户端软件，启用实时防护与接受管理，进行周期性对系统全机病毒扫描。

2.2.2黑客破坏和侵入

对各应用系统应及时进行系统补丁的升级和安全配置，并配合进行入侵检测和漏洞扫描等安全检查工作。

对于重点系统可以考虑部署主机入侵检测系统来保证主机的安全性。

2.3应用程序安全性

2.3.1在应用系统的生命周期中保证安全

应用系统的设计和管理者要在不同的阶段采用相应的工作方法和工作步骤，设计出一个把安全贯穿始终、切实可行的安全方案。

对应用系统应能提供书面可行的安全方案。

2.3.2在应用系统启始设计阶段实施安全计划

在应用系统启始设计阶段进行充分的安全可行性分析，对应用系统应该进行专门的安全可行性分析。

启始设计阶段同时还要进行风险的最初评估，在被选方案之间权衡效费比关系时，应该参照这个估计值，尤其在重点应用系统项目中应特别注重这方面的考虑。

2.3.3在应用系统开发阶段建立安全机制

安全需求定义：

在软件开发之前，需要了解相关的安全规定和软件运行的环境要求，并对此产生的安全需求做出定义。

安全设计：

安全设计不能简单依附于系统设计的控制而了事，安全的内容必须渗透到整个设计阶段。

当然，也不必对每项设计决定都采取安全方法。

通常，有各种方法使其达到必要的安全级别，需要考虑的是如何选择一种折衷方案给安全以适当的地位。

良好的安全设计能明显的减少应用系统的脆弱性并减少在系统运行时安全的强制性。

对于重点类系统应能够提供这方面的细节说明，以证实安全性设计的有效性。

安全的编程方法：

（1）  所有应用系统都应正确选择程序设计语言和其它程序设计工具，从而提高最终产品的可靠性和正确性；为提高整个系统的安全性，要恰当地选择并利用这些工具帮助防止程序错误进入源编码。

（2）  对于重点应用系统应该严格采用软件工程的方法编制程序，对编码至少由一名未参与程序设计的程序员检查程序编码，全面了解它的安全要点，他与原设计者对程序遗留问题应负有同样的责任。

（3）  对于重点应用系统程序库应有仅允许授权人存取程序模块功能，以及记录所有对程序模块存取的安全控制功能。

软件安全性的检测和评估:

公司所有类应用系统  综合运用静态和动态检测技术，进行全面认真的检测和评估，发现在应用系统设计和编码中的错误、疏忽和其它缺陷。

2.3.4在操作运行中保障安全

数据控制:

  重点应用系统应从输入准备、数据媒介存储、输出传播各个阶段所需的控制入手，保证数据安全成功处理。

对安全变异的响应:

重点应用系统中，一切与现行安全规定抵触的每一件事或不能解释的结果以及其它异常事件都应视为安全变异现象，应该给予足够的重视，并尽快报告管理员或其他负责人采取必要措施，以减少或消除不安全隐患。

报告方式要保密、过程要简单。

安全记账与审计：

重点应用系统中，应利用应用系统审计日志进行监控，并作为一种主动的监督管理形式和一种检测触犯安全规定事件的手段。

同时必须加强对应用系统的审计日志类信息的保护，对审计日志和监控功能的使用也必须做审计记录。

2.4接口安全性

2.4.1接口安全性要求

职责分隔：

应用系统接口是易受攻击的脆弱点，重点应用系统中，应从职责管理上加强，将责任实现最佳分离。

明确敏感客体和操作规定：

重点应用系统中，应能够根据可靠性、保密性和可用性三者定义每个数据客体（数据输入、数据存储和数据输出等）的安全需求，并通过系统实施时的培训来落实。

错误容限规定：

公司各类应用系统对错误的容限度和在可接受的限度内维护错误级别的需求必须被定义在安全需求中。

可用性需求：

公司各类应用系统为避免因为系统不能有效使用而产生的严重危害，必须制定可用性需求，然后根据需求采取措施来保证系统的可用性。

2.4.2接口扩展性要求

接口标准性要求：

对于各类应用系统应该能够尽量接口标准化，从而利于应用系统间信息的互通。

对于应用系统建设、改造等有代表性的，需要制定相关接口标准，作为将来工作的参照。

接口规范细化程度：

对于各类应用系统接口规范应该尽量细化，减少接口描述不清出现新的安全隐患。

对于重点应用系统应该有明确的接口类文档说明部分。

2.5数据安全性

2.5.1数据传输的机密性

重点应用系统中传输关键、敏感数据时要采用传输加密技术，实现数据机密性要求；其他类应用系统应根据具体情况来考虑。

密码算法选择:

（1）密码算法必须具有较高的保密强度和抗攻击能力。

（2）加密信息量大时应使用对称加密算法，加密重要信息时应使用非对称加密算法。

（3）要根据所保护信息的敏感程度与攻击者破解所要花的代价值不值得和系统所要求的反应时间来综合考虑决定要采用的密码算法。

加解密实现方式:

（1）如果要求全通信业务流机密性，那么应选取物理层加密，或传输安全手段（例如，适当的扩频技术）。

（2）如果要求高粒度保护（即对每个应用联系可能提供不同的密钥）和防抵赖或选择字段保护，应选取表示层加密。

（3）如果希望的是所有端系统到端系统通信的简单块保护，或希望有一个外部的加密设备（例如为了给算法和密钥以物理保护，或防止错误软件），那么应选取网络层加密。

这能够提供机密性与不带恢复的完整性。

（4）如果要求带恢复的完整性，同时又具有高粒度保护，那么将选取传输层加密。

这能提供机密性、带恢复的完整性或不带恢复的完整性。

（5）不推荐在数据链路层上加密。

当关系到以上问题中的两项或多项时，加密可能需要在多个层上提供。

2.5.2数据传输的完整性

数据完整性：

对于重点应用系统，因数据在INTERNET上传播或至关重要，应该保障数据的完整性，针对应用系统信息的重要程度，可以采用不同的数据完整性验证手段。

实现完整性方式选择：

（1）由加密提供的数据完整性机制；

（2）基于非对称加密的数据完整性机制，重点类系统应该尽量采用这种方式；

（3）其它数据完整性机制。

2.6用户安全性

2.6.1用户身份认证

对身份认证的需求:

对用户身份认证的需求取决于应用系统的性质，对于重点类系统要采用强身份认证方式。

身份认证的实现:

（1）弱身份认证方式加强：

对口令长度、复杂度、更新周期、保密性等进行严格管理。

（2）强身份认证方式有效保障：

对重要应用系统应逐渐倾向于加强的身份认证方式来保证用户身份安全，强身份认证方式可采用证书方式或动态口令方式等来实现。

从管理角度考虑：

没有一项身份认证技术是绝对可靠的，须依靠严格的强化管理和用户合作来提高认证技术的可靠性，并根据每个系统的实际需要部署，避免造成不必要的负担而影响应用系统的使用。

2.6.2不可否认性

对核心系统必须考虑不可否认性的功能，重点系统应该逐渐考虑系统操作的不可否认性，不可否认性可以用数字签名等来实现。

2.6.3授权

清晰的授权方案：

对重点系统需要有清晰的授权方案，有时不仅要指明应用哪些系统模块，还要明确使用哪台终端。

其他应用系统应能够满足系统功能、角色划分，满足用户需求。

授权委托时效性：

所有类应用系统的授权机制应该能够处理、识别、取消或修改授权操作的最终结果。

授权数据的保护：

（1）      所有类应用系统的授权系统维护应简单易行,避免发生错误。

（2）      重点应用系统的授权机制应具有自我保护能力。

异常情况或不兼容的授权数据应及早发现并报告。

授权数据必须认真加以保护，以防任何非授权修改和恶意破坏。

2.7应急计划

所有应用系统应制定相应的应急计划，它是重要的应用系统安全防卫措施。

应急计划应该包括操作系统中断、数据库和物理设备被破坏等情况的应急措施，这个计划也应该包括自动或人工过程所需设备的使用步骤。

2.7.1关键功能的鉴别

对于重点应用系统不仅应明确其关键功能的关键作用，而且也应该明确其它功能转变为关键功能之后的那段时间它的作用。

2.7.2替换场所操作

对于重点应用系统要设法在其它部门找到相同或兼容的设备，当紧急情况发生时，这些作为备份的设备有可能分配时间给运行失效的应用系统，这样的替换安排应该是相互的。

此外，针对替换场所的通信要设计出一种方法提供足够的传输设备；对配备的人员要进行有针对性的培训。

2.7.3有限的人工替换处理

必要时，将某些关键功能恢复成人工处理也是一种补偿办法。

对于重点应用系统如果对应用系统运行的持续性要求较高时，人工操作所需的一切必须事前准备妥当，如要考虑工作场所、实时数据的可用性、书面的原始数据、人工使用的特殊设备、报告格式、通信、传送、人员的选择和培训以及及时记录所有人工传递的处理过程等。

2.7.4数据备份

对于重点应用系统应该根据系统的重要程度制定相应的数据备份策略，并加以落实实施，并能熟练实现在发生数据灾难时的数据快速恢复工作。

2.8安全管理

2.8.1建立管理体制

建立管理体制包括建立防范组织、健全规章制度和明确职责任务三部分。

管理体制是进行管理的基础，规章制度应在权限的分配过程中建立，并可根据需要参照执行。

重点应用系统应建立良好的管理体制并归档，对于其他类应用系统应逐步完善管理体制。

2.8.2实施管理措施

实施管理措施应以实施存取控制和监督设备运行为主要内容。

管理措施是对管理辅之以技术手段，达到强化管理的目的。

重点类应用系统应建立起管理措施对应的规范化流程，其他类应用系统也应该明确其管理措施细节，落实到位。

2.8.3加强教育培训

重点类应用系统安全培训应该以普及安全知识、教授安全措施的具体操作为重点。

其他类应用系统应在系统帮助里面注明有关操作条目。

应该是个立体的从网络层-系统层-应用层-后台数据库层面..

都应该考虑

网络层主要考虑数据传输的可靠行和保密性（数据嗅探，监听，劫持）

系统层主要考虑系统自身安全（权限补丁等等）

应用层考虑代码的强壮性（开发初期就要注意安全的编码习惯）后期上线的白盒（源代码安全评估阅读-主要靠经验），黑盒测试（web的渗透测试安全检测-应用安全典型十大风险，及目前主流的发展变形技术）

数据库层面考虑数据库本身安全补丁端口权限设置（帐户，服务权限二次设置）等

其他还有很多小的方面需要有个总体的列表归纳下需要注意的点

产品方面现在有很多了国内国外都有ips（国内绿盟，启明的）效果还是不错的（针对应用层说）慢慢会比较多了ps-我们公司就在做要上线了呵呵

总之应用针对网站的说需要考虑的因素还是比较多的，需要一个有经验的人把握方方面面即便一个地方小的疏忽都很有可能威胁到网站安全

设备已经很多了。

除了楼主说的外，我认为应该精力更应该放到细节上，比如

系统安全不只是补丁和漏洞。

1、服务器权限。

尽量使用低权限账号，日常登陆服务器及维护站点都用低权限。

---防