|
伴随互联网的技术发展和新信息安全时代的来临，企业数据库的信息价值和可访问性逐步提升，使得数据库面临的来自内部及外部的安全风险急剧增加。恶意入侵、违规越权操作等风险将会导致机密信息被窃取、泄露，但事后却无法有效追溯和审计，企业信息资产面临严峻的挑战。
在此背景之下，数据库审计功能越显重要，越来越多的场景需要使用审计功能。
数据库审计方式主要分两类，一类是旁路方式审计，通过“外围”的抓包，对数据库网络流量进行采集，根据数据库协议进行解析与还原，收集数据库的行为数据，生成审计记录。另一类是数据库内核级审计，数据库内部直接分析语句，根据预先定义的审计规则，生成审计记录。
金仓数据库KingbaseES提供数据库内核级、实时、准确、高性能的审计功能，通过完善的审计机制，为数据库牢筑安全防护之盾!
金仓KES数据库审计简介
审计功能介绍
数据库审计（简称DBAudit）以安全事件为中心，以全面审计和精确审计为基础，实时记录网络上的数据库活动，对数据库操作进行细粒度审计的合规性管理，对数据库遭受到的风险行为进行实时告警。
金仓数据库KingbaseES支持三种类型的审计：
事件审计
审计数据库服务器发生的事件，包含以下几种：数据库服务器的启动、数据库服务器的停止、数据库服务器配置文件的重新加载、用户登录、用户登出。
语句级别审计
也称为“STATEMENT AUDITING”，指在DBMS 范围内，对DBMS 拥有的结构或模式对象进行操作时引发的事件进行审计，此类结构或模式对象并不指具体的某个结构或模式对象，而是一类结构或模式对象的泛称。通常，包括DBMS 提供的DDL、DML、DQL、DCL、TCL 等语句引发的事件。
模式对象级别审计
也称为“SCHEMA OBJECT AUDITING”，指在某个确定的模式对象上，对进行SELECT 或DML 操作时引发的事件进行审计。模式对象包括表、视图、物化视图、过程、函数、序列等。
金仓数据库KingbaseES支持风险行为进行实时告警：
基于审计的实时入侵检测分析，当用户的操作行为，达到入侵检测规则设定的阀值后，数据库将通过告警提示、断开连接、发送email的方式阻断用户行为，通知系统管理员。
审计的部署架构
金仓数据库KingbaseES审计支持两种部署架构。
1、审计日志直接保存在生产数据库中的审计部署架构：
优点：架构简单。
缺点：安全性不足。若生产数据库的硬盘损坏，审计日志可能丢失。 审计日志保存在生产数据库中
2、审计日志保存在第三方审计数据库中的审计部署架构：
优点：审计日志安全性提高；支持多台数据库的审计日志集中管理。
缺点：架构复杂。
审计日志保存在第三方审计数据库中
实现原理
旁路方式实现的数据库审计功能，一般由数据库流量采集、审计数据还原和分析、审计数据存储等三部分构成，需要相应的软件和硬件支持。
内核级实现的数据库审计功能，不需要额外的软件和硬件，审计数据可直接在用户连接进程中产生，同步在用户进程中生成审计记录，也可把审计记录发送至专门处理进程或线程中，异步生成审计记录。
金仓数据库KingbaseES的审计功能在实现的过程中，为满足在审计数据量极大时“实时记录、审计信息不丢失、对于用户应用影响小”等需求， 采取类似于生产者和消费者模型，采用了多生产者多消费者模型，m对n的模型，生产者和消费者之间的通讯采用共享内存。
金仓KES审计安全解决方案的特点
审计功能自身的安全性
1、结合三权分立，实现交叉审计
金仓数据库KingbaseES中，安全管理员对普通用户和审计管理员进行审计，审计管理员对数据库管理员和安全管理员进行审计。这种权限划分方式，可以有效防止“既是裁判员，又是运动员”状况的出现，全面提升审计的安全性。
2、内核级的防删除和防篡改
金仓数据库KingbaseES支持内核级别的审计，可在代码层次，限制管理员和普通用户对审计记录的insert、update、delete，防止审计记录被恶意的删除或篡改。
审记记录的安全性
1、审计记录自动脱敏，保证安全性
对于审计记录中的敏感数据，例如用户的口令，进行自动脱敏，保证审计记录不会泄露用户的敏感信息。
可通过配置参数，关闭记录执行的SQL语句，提高安全性，同时提升性能。
2、审计记录存储的安全性
审计记录保存在数据库的系统表。
通过国密SM4算法实现存储透明加密，非法用户无法解密。
通过国密SM3算法保证完整性，防止非法篡改。
3、审计记录转储的安全性
当数据库保存的审计记录过多时，可通过转储功能，把审计记录备份到外部文件。
通过国密SM4算法实现存储加密，非法用户无法解密。
通过国密SM3算法保证完整性，防止非法篡改。
审记的高可用性
在单机、集群等多种部署情况下，金仓数据库KingbaseES审计功能都能做到只要数据库服务不断，审计的服务就不能中断，审计数据不丢！
金仓数据库KingbaseES从如下3个方面保证审计的高可用。
金仓KES数据库审计性能实测
测试目标
国外知名数据库对审计性能提出如下建议：
As auditing is a transactional activity with typical ACID properties to guarantee record of database activities, we recommend that you fine-tune your audit policies to collect audit data that is targeted to your needs. collecting unnecessary audit information impacts database performance, increases storage costs, and may make it more difficult to spot malicious database activity。
由此可见，审计规则对审计的性能影响颇大。因此实际使用中，为达到良好的性能体验，应对所需审计的对象有所取舍，不应全部审计。
本次我们将模拟用户真实使用环境，测试审计功能开启时对数据库性能的影响。验证金仓数据库KingbaseES在审计功能开启时，能否确保性能的合理衰减？
测试环境
采用的测试环境、测试工具和测试版本如下：
测试的软件版本及采用的测试工具
测试内容|使用模拟场景测试审计 性能损耗
模拟实际使用场景验证审计的性能：
1、构造10张数据表，表上创建Btree索引，并对每张表，初始灌数10000000条记录。
2、构造对表的操作，select和dml(包括insert、update、delete)的比例为7：3。
3、对所有表设置select、insert、update、delete审计规则。
4、使用JMeter启动2000个连接，进行2列出的操作，接续运行15分钟。
审计日志本地存储测试结果：
采用审计日志直接保存在生产数据库中的审计部署架构时，每秒大约产生9.9万条审计记录，而性能损耗仅5.4%。
审计日志存储在第三方审计数据库测试结果：
采用审计日志存储在第三方审计数据库中的审计部署架构时，每秒大约产生9.8万条审计记录，性能损耗仅5.8%。
在模拟的测试场景下，KingbaseES能够在每秒近10万条审计记录的同时，确保性能损耗在6%以内。若减少审计的对象或减少审计的语句类型，性能损耗将会缩减，性能将会持续提高，完全满足各类客户日常场景的使用。
测试内容|使用TPCC测试审计 性能损耗
使用最经典权威的TPCC测试参数配置，验证性能损耗：
审计日志本地存储测试结果：
采用审计日志直接保存在生产数据库中的审计部署架构时，在TPCC测试的极限情况下，当我们对所有表进行所有操作的审计时，性能损耗不到20%。
审计日志存储在第三方审计数据库测试结果：
在TPCC测试下，当采用审计日志存储在第三方审计数据库中的审计部署架构时，由于网络传输将会增加损耗，性能下降1%左右。由此可见，审计在增强安全性的同时，性能损耗有些上升，但却能够全方位确保用户对于审计安全性和审计性能的需求！
测试小结
本次审计性能实测，在模拟用户使用场景，且大并发的情况下，当金仓数据库KingbaseES开启审计功能后，性能极限值仅下降6%。在TPCC大压力测试场景下，金仓数据库KingbaseES开启审计功能后，性能极限值仅下降20%以内，完全能够满足绝大部分用户的需求。
结语
面对层出不穷的安全威胁，我们需要不断革新、进化的防御技术来达到攻防平衡，让数据更安全。在当下的审计市场中，审计的部署方案各有不同，有第三方审计软件，也有第三方审计服务器，其能力各有优劣。而金仓数据库KingbaseES 提供基于数据库库内核的审计能力。毫无疑问，数据库内部的审计对用户行为将会审计地更加全面，粒度更丰富，对应用的性能影响小。
（文章来自金仓数据库，如有违权请联系删除！）
| 
私信
