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

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

应用系统安全规制定建议

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

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 用户身份认证

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

相关文档
最新文档