市面上出现的两种数据库审计技术有何差别

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介:

在日渐火热的数据库安全领域,数据库审计应该是应用最为广泛,用户接受度最高的产品了,没有之一。

市面上出现的两种数据库审计技术有何差别

本文将对目前数据库审计市场上的两类技术路线进行分析,从使用效果出发,浅析两者在各维度的审计效果上存在哪些差异,呈现产品真正能实现的功能和价值。希望能为广大用户在数据库审计产品的选型上提供参考依据。

概括来讲,两类数据库审计的技术路线区别,根本来自于两者的部署方式、获取数据库访问记录的途径不同以及SQL解析方式不同,审计效果自然不同。

旁路式VS植入式

旁路式VS植入式

从5个衡量维度看技术路线的差异

衡量两种技术路线的差异,可以从两类产品在真实测试中的功能表现上能够更直观的呈现。下面从5个主要的衡量维度来看基于两类技术路线的审计效果表现,这几个维度也是业内对专业数据库审计产品评判中普遍遵循的主要衡量指标。

1. 审计结果全面性的表现

旁路式:通过镜像流量或探针的方式进行全流量采集,基于全量数据库流量进行语句和会话分析,再通过对sql语句的协议解析,能够审计到客户端信息,返回结果集。这种采集方式首先对数据库类型不挑剔,均可支持,并且能够审计到普通用户和超级用户的访问行为。

植入式:属于注册代理程序的“侵入式”审计,利用数据库的自审计插件(如Oracle的FGAC插件),读取数据库自审计日志,依赖的是数据库自身审计能力,这里有一个很大的问题,如果数据库自身不具备审计能力,那么这类数据库审计产品就无法支持对此类型数据库的审计;并且,数据库自审计功能一般只提供增、删、改、查语句和部分数据定义语句,无法提供全操作类型的审计,也无法完整审计结果集。不过从另一个角度来看,植入方式也有其亮点——本地操作的审计,这些不通过网络的流量,传统的流量镜像方式捕获不到,不过旁路式的审计,也可以通过增加rmagent,实现这项功能。

2. 审计结果准确性的表现

前面提到,两者对数据库访问的采集方式不同,这决定了两者在审计结果准确性上的差异表现。

旁路式:由于是基于全流量的审计,如果能配合sql语句的协议解析和特征捕获等技术,可以准确关联语句和会话,进行精确的审计结果查询分析能力;准确关联应用用户与SQL语句,这样可以实现对业务行为的审计。在此基础上形成的规则库,也能够更准确的识别风险访问及漏洞攻击行为。

植入式:由于是基于正则表达式完成SQL语句规则,无法基于通讯协议解析命中语句规则,在实际工作中,会导致语句和会话无法关联,不能按照会话进行语句梳理汇总,那么会缺乏连贯分析能力;并且,由于不是基于流量和协议的SQL语句解析,对于目前用户普遍要求的应用关联审计,也无法实现。

3. 检索及入库速度的表现

基于SQL语句的获取方式不同,两者在检索及入库速度方面也会存在差异表现。

植入式:由于原始审计信息是记录在数据库中的,需要定期获取到审计设备上,这其中可能产生较大的延迟。另一方面,开启数据库自审计功能本身会占用大量内存,如果遇到高压力并发的情况,会拖慢数据处理能力,连累正常业务访问。

旁路式:旁路镜像流量的方式对应用到数据库的访问完全透明,不会产生影响,这也是目前市面上大多数审计厂商如安华金和等,选择旁路镜像方式,配合精确SQL解析技术来实现审计高可用性的主要原因之一。

4. 关于存储空间的占用表现

旁路式:由于是镜像方式获取流量,对于审计产品本身的存储优化能力有一定要求,但不会影响数据库服务器本身的存储空间,需要考量对比的是产品本身能否提供归一化技术和压缩存储技术,以节约存储空间。

植入式:由于需要开启自审计功能,需要占用大量数据库本身的存储空间,如果同时缺乏SQL归一技术,那么在大数据处理情况下,数据库本身的硬盘空间就会非常紧张。

5. 产品易用性方面的表现

两者在配置和操作的易用性方面也存在较大差异。

植入式:数据库审计产品在注册实例的时候,需要手工输入IP端口数据库实例,还需要sys用户及口令,向数据库中注册用户及程序。另一方面,如果是基于正则式的规则配置,需要数据库管理人员具备一定的技术能力,深度参与规则和策略的配置定义。

旁路式:由于是基于数据库流量的语句语法解析,可以自动识别并添加审计数据库;更专业的产品应能够基于解析结果,从风险、语句、会话三个维度进行深度解析,维度之间相互关联、多重钻取分析,这样用户可以对数据库的整体安全状态有更直观的判断。

目前,市场上的数据库审计产品多以旁路镜像方式为主,但也出现了采用植入式技术路线的产品。从表面来看都能够实现数据库访问行为的审计,但在审计效果及用户体验上存在显著的差异,用户需要在产品选型时更多关注产品的核心技术路线,以避免在实施部署后,为信息管理工作带来麻烦。


原文发布时间为:2017-11-02

本文作者:安华金和

本文来自云栖社区合作伙伴51CTO,了解相关信息可以关注51CTO。

目录
相关文章
|
1月前
|
Java 关系型数据库 MySQL
"解锁Java Web传奇之旅:从JDK1.8到Tomcat,再到MariaDB,一场跨越数据库的冒险安装盛宴,挑战你的技术极限!"
【8月更文挑战第19天】在Linux上搭建Java Web应用环境,需安装JDK 1.8、Tomcat及MariaDB。本指南详述了使用apt-get安装OpenJDK 1.8的方法,并验证其版本。接着下载与解压Tomcat至`/usr/local/`目录,并启动服务。最后,通过apt-get安装MariaDB,设置基本安全配置。完成这些步骤后,即可验证各组件的状态,为部署Java Web应用打下基础。
40 1
|
20天前
|
SQL Java 关系型数据库
探索Java数据库连接的奥秘:JDBC技术全攻略
探索Java数据库连接的奥秘:JDBC技术全攻略
40 8
|
26天前
|
存储 缓存 负载均衡
【PolarDB-X 技术揭秘】Lizard B+tree:揭秘分布式数据库索引优化的终极奥秘!
【8月更文挑战第25天】PolarDB-X是阿里云的一款分布式数据库产品,其核心组件Lizard B+tree针对分布式环境优化,解决了传统B+tree面临的数据分片与跨节点查询等问题。Lizard B+tree通过一致性哈希实现数据分片,确保分布式一致性;智能分区实现了负载均衡;高效的搜索算法与缓存机制降低了查询延迟;副本机制确保了系统的高可用性。此外,PolarDB-X通过自适应分支因子、缓存优化、异步写入、数据压缩和智能分片等策略进一步提升了Lizard B+tree的性能,使其能够在分布式环境下提供高性能的索引服务。这些优化不仅提高了查询速度,还确保了系统的稳定性和可靠性。
54 5
|
26天前
|
Cloud Native 数据库 开发者
云原生数据库2.0问题之帮助阿里云数据库加速技术更新如何解决
云原生数据库2.0问题之帮助阿里云数据库加速技术更新如何解决
|
26天前
|
Cloud Native 关系型数据库 分布式数据库
云原生数据库2.0问题之PolarDB利用云计算技术红利如何解决
云原生数据库2.0问题之PolarDB利用云计算技术红利如何解决
|
29天前
|
关系型数据库 OLAP 分布式数据库
揭秘Polardb与OceanBase:从OLTP到OLAP,你的业务选对数据库了吗?热点技术对比,激发你的选择好奇心!
【8月更文挑战第22天】在数据库领域,阿里巴巴的Polardb与OceanBase各具特色。Polardb采用共享存储架构,分离计算与存储,适配高并发OLTP场景,如电商交易;OceanBase利用灵活的分布式架构,优化数据分布与处理,擅长OLAP分析及大规模数据管理。选择时需考量业务特性——Polardb适合事务密集型应用,而OceanBase则为数据分析提供强大支持。
90 2
|
7天前
|
存储 负载均衡 数据库
探索后端技术:从服务器架构到数据库优化的实践之旅
在当今数字化时代,后端技术作为支撑网站和应用运行的核心,扮演着至关重要的角色。本文将带领读者深入后端技术的两大关键领域——服务器架构和数据库优化,通过实践案例揭示其背后的原理与技巧。无论是对于初学者还是经验丰富的开发者,这篇文章都将提供宝贵的见解和实用的知识,帮助读者在后端开发的道路上更进一步。
|
7天前
|
SQL 关系型数据库 MySQL
MySQL技术安装配置、数据库与表的设计、数据操作解析
MySQL,作为最流行的关系型数据库管理系统之一,在WEB应用领域中占据着举足轻重的地位。本文将从MySQL的基本概念、安装配置、数据库与表的设计、数据操作解析,并通过具体的代码示例展示如何在实际项目中应用MySQL。
32 0
|
14天前
|
关系型数据库 Java MySQL
"解锁Java Web传奇之旅:从JDK1.8到Tomcat,再到MariaDB,一场跨越数据库的冒险安装盛宴,挑战你的技术极限!"
【9月更文挑战第6天】在Linux环境下安装JDK 1.8、Tomcat和MariaDB是搭建Java Web应用的关键步骤。本文详细介绍了使用apt-get安装OpenJDK 1.8、下载并配置Tomcat,以及安装和安全设置MariaDB(MySQL的开源分支)的方法。通过这些步骤,您可以快速构建一个稳定、高效的开发和部署环境,并验证各组件是否正确安装和运行。这为您的Java Web应用提供了一个坚实的基础。
30 0