数据库审计(简称DBAudit)以
安全事件为中心,以
全面审计和精确审计为基础,
实时记录网络上的数据库活动,对
数据库操作进行
细粒度审计的合规性管理,对数据库遭受到的风险行为进行实时告警。它通过对用户访问数据库行为的记录、分析和汇报,来帮助用户事后生成合规报告、事故追根溯源,同时通过大数据
搜索技术提供高效查询
审计报告,定位事件原因,以便日后查询、分析、过滤,实现加强内外部数据库网络行为的监控与审计,提高
数据资产安全。
安全挑战
数据库是任何商业和
公共安全中最具有战略性的资产,通常都保存着重要的商业伙伴和
客户信息,这些
信息需要被保护起来,以防止
竞争者和其他非法者获取。互联网的急速发展使得
企业数据库信息的价值及
可访问性得到了提升,同时,也致使数据库
信息资产面临严峻的挑战,概括起来主要以下三个层面:
1.
管理风险:主要表现为人员的职责、流程有待完善,内部员工的日常操作有待规范,第三方维护人员的操作监控失效等等,离职员工的后门,致使安全事件发生时,无法追溯并定位真实的操作者。
2.
技术风险:Oracle, SQL Server是一个庞大而复杂的系统,
安全漏洞比如:溢出、 注入等层出不穷,每一次的
CPU(Critical Patch Update)都疲于奔命, 而企业和政府处于稳定性考虑,往往对补丁的跟进非常延后,更何况通过应用层的注入攻击使得数据库处于一个无辜受害的状态。
3. 审计层面:现有的依赖于数据库
日志文件的
审计方法,存在诸多的弊端,比如:数据库
审计功能的开启会影响数据库本身的性能、数据库日志文件本身存在被篡改的风险,难于体现审计信息的有效性和公正性。此外,对于审计数据的挖掘和迅速定位也是任何审计系统必须面对和解决的一个核心问题之一。
伴随着数据库信息价值以及
可访问性提升,使得数据库面对来自内部和外部的
安全风险大大增加,如违规越权操作、恶意入侵导致机密信息窃取泄漏,但事后却无法有效追溯和审计。
历史回顾
对于数据库审计的理解,其实有一个发展过程。 从几年前开始, 开始在原来日志审计的基础上发展包装了一个数据库审计,这类系统能记录并显示基本的往数据库发的sql, 并且有一定的查询和报表功能。客观地说, 这种系统一开始出现时满足了一定的需求。
但是随着新
信息安全时代的到来,原来的
基本功能越来越体现起不足,比如越来越多的控制是关注返回而不是请求,
弱口令等
管理风险如何控制, 还有如何进行用户
访问控制细粒度策略的定制和实施, 和万一数据被篡改或删除后(不管是有意还是无意)能否尽快实施定位式恢复。
主要功能
通过应用层访问和
数据库操作请求进行多层业务关联审计,实现访问者信息的完全追溯,包括:操作发生的URL、客户端的IP、请求报文等信息,通过多层业务关联审计更精确地定位事件发生前后所有层面的访问及操作请求,使管理人员对用户的行为一目了然,真正做到数据库
操作行为可监控,违规操作可追溯。
通过对不同数据库的SQL
语义分析,提取出SQL中相关的要素(用户、SQL操作、表、字段、视图、索引、过程、函数、包…) 实时监控来自各个层面的所有数据库活动,包括来自
应用系统发起的数据库操作请求、来自数据库客户端工具的操作请求以及通过
远程登录服务器后的操作请求等 通过远程
命令行执行的SQL命令也能够被审计与分析,并对违规的操作进行阻断 系统不仅对数据库操作请求进行实时审计,而且还可对数据库返回结果进行完整的还原和审计,同时可以根据返回结果设置审计规则。
精准化行为回溯:
一旦发生
安全事件,提供基于
数据库对象的完全自定义
审计查询及审计数据展现,彻底摆脱数据库的
黑盒状态。
灵活的策略定制:根据登录用户、源
IP地址、数据库对象(分为
数据库用户、表、字段)、操作时间、SQL操作命令、返回的记录数或受影响的行数、关联表数量、SQL执行结果、SQL执行时长、报文内容的灵活组合来定义客户所关心的重要事件和
风险事件 多形式的实时告警:当检测到可疑操作或违反审计规则的操作时,系统可以通过
监控中心告警、短信告警、邮件告警、Syslog告警等方式通知数据库管理员。
职权分离:
《计算机信息系统安全等级保护数据库管理技术要求》、《企业内部控制规范》、
SOX法案或
PCI中明确提出对工作人员进行
职责分离,系统设置了权限
角色分离。
友好真实的操作过程回放:
对于客户关心的操作可以回放整个相关过程,让客户可以看到真实输入及
屏幕显示内容。 对于
远程操作实现对精细内容的检索,如执行删除表、文件命令、数据搜索等。
审计手册
数据库系统功能强大而丰富,对于一个
数据库环境而言,我们可以生成很多类型的审计记录。知道有哪些审计类型以及如何实施这些审计有助于你满足合规需求。要实施完善的数据库审计,必须理解的一个关键问题是需求,从而知道可以使用哪些审计类型来满足自己的需求。
登入和登出
在你要进入一家公司会晤某人的时候,一般需要在前台进行登记。这样做可确保公司完整的记录进入公司的任何人,在出现问题时,或在追踪和调查“这事儿是谁干的?”时,这种登录很有用处。这种日志通常会记录来客是谁、何时进入、何时离开。同样的过程也适用于数据库,多数环境中所需要的首要审计就是完整的记录哪些人曾登入过数据库。
对于这类审计,你需要记录两类事件:登入事件和登出事件。对于每一个事件,你都需要保存
登录名和时间,但你还应该考虑记录附加信息。这包括发起连接的客户端的IP地址,以及用于初始化连接的程序。例如,在
Oracle环境中,你可能想知道该连接是否由SQL Plus等初始化。
数据库源头
与登录活动审计相关的是客户源信息的审计。这包括审计哪个
网络节点连接到了数据库(例如,使用一个
IP地址还是
主机名),并且审计使用哪个
应用程序访问了数据库。
虽然这种信息是我们在审计
数据连接时通常都会捕获的值之一,但在SQL调用水平上捕获这种信息非常重要。除了知道一个用户是使用
Excel而不是
SAP系统连接之外,你还需要知道某次更新是由Excel电子
数据表软件还是由SAP系统执行的。因此,你在每次查询和数据库操作中,应该将
源程序收集在审计记录中,特别当IP地址能够单独确认一个用户时。如果你的架构是基于
客户/服务器的,那么源IP地址通常会确认一个确定的用户。这种情况下,根据用户每次SQL调用的IP地址进行跟踪和报告,这同报告
终端用户的数据库操作和数据查看同样有益。另一方面,如果你使用一种应用程序服务器架构,那么IP地址不会帮助你确认和报告终端用户,你需要借助于其它技术。
在审计和提供
审计信息时,你还得做另一个决定,这与你是提供“
原始数据”还是更易于使用的数据有关。例如,上图三中的左侧显示了哪些
源程序被用于访问运行在155.212.221.84上的
SQL服务器上。这种信息对于了解环境的人员来说非常有用。而上图右侧所提供的信息对一般人来说更有意义,这些人并不关心IP地址是什么,却知道HR(人力资源)数据库是怎么回事。如果相关人员理解与开发者工具登录进入人力资源(HR)数据库有关的风险,这种信息显然更有意义。
审计数据库错误
审计由数据库返回的错误也是很重要的,它是你应实施的首个审计日志之一。从安全的观点来看,这尤其重要。例如,在许多情况下,攻击者会进行很多尝试直至得逞。攻击者可以使用基于UNION的攻击,他需要猜测数据表的正确栏数,直到他得到正确的数字,数据库将会不断地返回一个
错误代码,表明
SELECT语句所选择的栏数不匹配。如果你记录了所有的错误,就可以确认这种攻击并做出响应。失败的登录是需要进行记录和监视的错误之一,即使你并没审计数据库的登录。最后,任何失败的提升特权的试图操作都表明攻击正在发生。
从质量的观点看,错误审计也很重要,它符合合规要求。我们应该确认并修复漏洞和应用程序错误,而记录SQL错误通常是确认这些问题的一种简单方法。因而,即使你关心的是
安全问题,将这种信息提供给应用程序的
所有者也很有意义,因为谁都不愿意运行存在着问题的代码。幸运的话,这些错误甚至会向你指出那些影响
响应时间和
可用性的问题。
产品特点
完整性:多层业务关联审计,可针对WEB层、应用中间层、
数据层各层次进行关联审计
细粒度:细粒度的审计规则、精准化的行为检索及回溯、全方位的风险控制。
有效性:独有专利技术实现对数据库安全的各类攻击风险和
管理风险的
有效控制;灵活的、可自定义的审计规则满足了各类内控和外审的需求(有效控制误操作、越权操作、恶意操作等违规行为)
公正性:基于独立审计的
工作模式,实现了
数据库管理与审计的分离,保证了审计结果的真实性、完整性、公正性
零风险:无需对现有数据库进行任何更改或增加配置,即可实现零风险部署
高可靠:提供多层次的物理保护、
掉电保护、
自我监测及冗余部署,
提升设备整体可靠性
易操作:充分考虑国内用户的使用和维护习惯,提供Web-based全中文操作界面及在线操作提示