5 企业案例-网络安全审计系统(数据库审计)解决方案

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

数据库审计系统技术建议书

目次

1.综述 (1)

2.需求分析 (1)

2.1.内部人员面临的安全隐患 (2)

2.2.第三方维护人员的威胁 (2)

2.3.最高权限滥用风险 (2)

2.4.违规行为无法控制的风险 (2)

2.5.系统日志不能发现的安全隐患 (2)

2.6.系统崩溃带来审计结果的丢失 (3)

3.审计系统设计方案 (3)

3.1.设计思路和原则 (3)

3.2.系统设计原理 (4)

3.3.设计方案及系统配置 (14)

3.4.主要功能介绍 (5)

3.4.1.数据库审计........................ 错误!未定义书签。

3.4.2.网络运维审计 (9)

3.4.3.OA审计............................ 错误!未定义书签。

3.4.4.数据库响应时间及返回码的审计 (9)

3.4.5.业务系统三层关联 (9)

3.4.6.合规性规则和响应 (10)

3.4.7.审计报告输出 (12)

3.4.8.自身管理 (13)

3.4.9.系统安全性设计 (14)

3.5.负面影响评价 (16)

3.6.交换机性能影响评价 (17)

4.资质证书.......................... 错误!未定义书签。

1.综述

随着计算机和网络技术发展,信息系统的应用越来越广泛。数据库做为信息技术的核心和基础,承载着越来越多的关键业务系统,渐渐成为商业和公共安全中最具有战略性的资产,数据库的安全稳定运行也直接决定着业务系统能否正常使用。

围绕数据库的业务系统安全隐患如何得到有效解决,一直以来是IT治理人员和DBA们关注的焦点。做为资深信息安全厂商,结合多年的安全研究经验,提出如下解决思路:

管理层面:完善现有业务流程制度,明细人员职责和分工,规范内部员工的日常操作,严格监控第三方维护人员的操作。

技术层面:除了在业务网络部署相关的信息安全防护产品(如FW、IPS 等),还需要专门针对数据库部署独立安全审计产品,对关键的数据库操作行为进行审计,做到违规行为发生时及时告警,事故发生后精确溯源。

不过,审计关键应用程序和数据库不是一项简单工作。特别是数据库系统,服务于各有不同权限的大量用户,支持高并发的事务处理,还必须满足苛刻的服务水平要求。商业数据库软件内置的审计功能无法满足审计独立性的基本要求,还会降低数据库性能并增加管理费用。

2.需求分析

随着信息技术的发展,XXX已经建立了比较完善的信息系统,数据库中承载的信息越来越受到公司相关部门、领导的重视。同时数据库中储存着诸如XXX等极其重要和敏感的信息。这些信息一旦被篡改或者泄露,轻则造成企业或者社会的经济损失,重则影响企业形象甚至社会安全。

通过对XXX的深入调研,XXX面临的安全隐患归纳如下:

2.1.内部人员面临的安全隐患

随着企业信息化进程不断深入,企业的业务系统变得日益复杂,由内部员工违规操作导致的安全问题变得日益突出起来。防火墙、防病毒、入侵检测系统等常规的安全产品可以解决一部分安全问题,但对于内部人员的违规操作却无能为力。

2.2.第三方维护人员的威胁

企业在发展的过程中,因为战略定位和人力等诸多原因,越来越多的会将非核心业务外包给设备商或者其他专业代维公司。如何有效地管控设备厂商和代维人员的操作行为,并进行严格的审计是企业面临的一个关键问题。

2.3.最高权限滥用风险

因为种种历史遗留问题,并不是所有的信息系统都有严格的身份认证和权限划分,权限划分混乱,高权限账号(比如DBA账号)共用等问题一直困扰着网络管理人员,高权限账号往往掌握着数据库和业务系统的命脉,任何一个操作都可能导致数据的修改和泄露,最高权限的滥用,让数据安全变得更加脆弱,也让责任划分和威胁追踪变得更加困难。

2.4.违规行为无法控制的风险

管理人员总是试图定义各种操作条例,来规范内部员工的访问行为,但是除了在造成恶性后果后追查责任人,没有更好的方式来限制员工的合规操作。而事后追查,只能是亡羊补牢,损失已经造成。

2.5.系统日志不能发现的安全隐患

我们经常从各种系统日志里面去发现是否有入侵后留下来的“蛛丝马迹”来判断是否发生过安全事件。但是,系统往往是在经历了大量的操作和变化后,才逐渐变得不安全。另外的情况是,用户通过登录业务服务器来访问数据库等核心资产,单纯的分析业务系统或者数据库系统的日志,都无法对整

个访问过程是否存在风险进行判断。从系统变更和应用的角度来看,网络审计日志比系统日志在定位系统安全问题上更可信。

2.6.系统崩溃带来审计结果的丢失

一般来说,数据库系统都会存储操作日志,也能开启审计模块对访问进行审计,但是一旦有意外发生导致系统的崩溃,这些审计日志也随之消失,管理人员无法得知系统到底发生了什么。

3.审计系统设计方案

3.1.设计思路和原则

需要部署一款数据库审计系统,既能独立审计针对数据库的各种访问行为,又不影响数据库的高效稳定运行。该系统主要从以下8个方面进行设计考虑:

➢实用性:由于业务系统数据在数据库中进行集中存储,故对于数据库的操作审计需要细化到数据库指令、表名、视图、字段等,同时能够

审计数据库返回的信息,包括错误码和数据库响应时长,这样能够在

数据库出现关键错误时及时响应,避免由于数据库故障带来的业务损

失;

➢灵活性:审计系统可提供缺省的审计策略及自定义策略,可结合用户业务特点,对关键业务用户、操作途径、重要操作、重要表、重要字

段进行过滤审计,并可指定操作事件发生时,系统的响应方式。

➢兼容性:审计系统应适应不同的数据库类型和应用环境,对于主流商业数据库、国产数据库的各种版本均能进行审计。且对于不同数据库

的审计策略编辑方法、日志展现能做到统一。

➢独立性:审计系统应独立于数据库系统存在,即使数据库或者操作系统遭到破坏,仍然要保证审计日志的准确性和完整性。同时,审计系

相关文档
最新文档