Loading...
墨滴

eZy

2021/10/19  阅读:51  主题:默认主题

MySQL 审计解决方案调研:第一阶段

MySQL 审计解决方案调研:第一阶段

目录

十六字运维方针依法合规、安全高效、预防为主、持续改进。


审计概览

目的

对于线上的应用系统,特别是数据库管理系统,尽量在审计实施时做到覆盖最基本的 3W 要求:Who?When?do What? 即:在出现问题时,能够定位到谁?在哪个时间点?做了什么?

追责不是第一目的,是要让每个运维/开发人员对线上应用特别是数据库应用存有敬畏之心。

针对 MySQL 的审计,需要覆盖到的范围是怎样的呢?请接着往下看。

MySQL 审计应覆盖范围

在文章前面我们有提到审计要覆盖到最基本的 3W 要求,那针对 MySQL 审计实施前,我们就要搞清楚以下 3 个方面的信息:

  • MySQL 入口 & 审计目标群体:针对 3W 中的 Who,我们要弄清楚进入 MySQL 都有哪些入口,把住这些入口,对进来的人(这里不仅是指数据库账号,这些账号对应使用者可能有:DBA、SA、开发者、入侵者等等角色)做好记录。
  • 审计目标操作:针对 3W 中的 What,审计要确认好对哪些操作/命令做记录。

下面我们逐个分析这 3 方面的信息。


1. MySQL 入口

审计软件最好能覆盖到这些入口。

参考:https://dev.mysql.com/doc/refman/5.7/en/transport-protocols.html localfile://media/16306387914744/16306551697894.jpg

2 个远程,2 个本地:

localfile://media/16306387914744/16306553050836.jpg

远程:IPv4 及 IPv6。 本地:loopback 及 socket(unix /类 unix 系统)/命名管道 & 共享内存(Windows)。

类似 LNMP 这种本地部署模式的应用,也可以通过 socket 进行数据库连接:

参考:https://cloud.google.com/sql/docs/mysql/samples/cloud-sql-mysql-sqlalchemy-create-socket?hl=zh-cn localfile://media/16306387914744/16306526157075.jpg


2. 审计目标群体

审计软件最好能覆盖到以下群体:

内部群体:

  • RD(开发/研发人员)
  • DBA(数据库管理员)
  • SA(系统管理员)

外部群体:

  • 其他任何人(黑客入侵者)

3. 审计目标操作/MySQL 命令

审计软件最好能覆盖到以下这些命令:

  • DDL
  • DML(量大)
  • Query(量大)
  • 登录活动
  • 其他(包含执行错误的命令,之前遇一案例是由于执行不存在的存储过程导致的数据库性能问题,即对 error 的处理有时也会导致性能问题出现。)

那是不是说做好以上 3 个方面的信息确认,就可以直接对数据库进行审计操作了呢?未必,请看以下分析。


为什么说对单纯针对数据库的审计不能形成闭环

SA/DBA 对数据库具有绝对控制权,可以随时在数据库服务器本地打开或关闭审计功能,且 SA/DBA 可随时删除审计文件,SA 更能停止审计 agent,而这些行为只能通过堡垒机去约束,但不能避免其行为的发生。所以可能会发生以下情况:XX 与 SA/DBA 串通一气,对线上数据库进行破坏,破坏行为对应的时段日志被 SA/DBA 销毁(通过停止 agent 或 删除审计日志),SA/DBA 可以以误操作为由,使犯罪团伙的犯罪记录无迹可寻,无法完成追责。

对于线上已有 MySQL 系统怎样形成闭环?

  • 安全团队介入,如果公司条件有限,指定专人负责。
  • 不使用基于内核的审计功能(此处指改内核/插件形式),使用基于旁路监听的方案(安全产品);
  • 不使用基于 agent 的审计方案;
  • 关闭 MySQL 套接字登录入口:设置 socket(对类 Unix 系统) 参数为空;
  • 关闭 MySQL 共享内存/命名管理连接入口(对 Windows 系统);
  • 关闭 loopback 登录入口:设置 bind-address 使数据库只监听 IPv4/IPv6 地址。

另外,对于某些平台化系统,用户操作大部分通过统一入口,审计数据往往不能直接体现操作源头 IP(日志中往往是平台对应的 IP 信息),此时只能在平台中实现操作日志以实现闭环,或需要在更底层(交换机、路由器、防火墙等等)实现全链路审计功能,排查问题时需要联动分析。

既然单纯数据库层面的审计存在缺陷,我们应该怎样安全且高效的开展数据库审计工作呢?不妨抄抄作业,看看各大公有云 & 商用数据库审计系统 - DAS 对应审计实现方式。

数据库审计方案对比

主流云平台

调研范围:主流公有云服务供应商,共涉及 6 家,国内外各 3 家。

供应商 MySQL 审计实现方式 补充说明
AWS MariaDB audit plugin 可以视为内核级。
微软 Azure 应是应用层实现(不排除旁路监听模式)。 az 命令行级别打开。
Google Google cloud logs 应是应用层实现,通用日志系统,猜测应类似于 Proxysql 中间层。
阿里云 数据库审计服务:旁路监听模式。
腾讯云 数据库内核级实现。 号称比旁路监听更准确。
华为云 DBSS 数据库安全服务:旁路监听模式。

国内商用数据库审计系统(DAS)

厂商 机制 补充说明
天融信 DAS 旁路监听
山石 旁路监听
启明星辰 旁路监听
亿赛通 旁路监听
绿盟 旁路监听
安华金和 旁路监听

有些产品也兼容代理(agent)部署模式。

分析及小结

各方案优点分析:

  • 旁路监听审计实现
    • 数据库 sever 端性能几乎无损失。(高权重因素)
    • 通过一定的设计,能使审计数据集中化,收集较方便,对运维相对友好。
  • 内核级审计实现
    • 审计结果最准确。
    • 对通信链路中的路由交换设备基本无额外要求。

各方案缺点分析:

  • 旁路监听审计实现
    • 解析出的 SQL 文本准确度很依赖于 SQL 解析器,对产品研发技术要求较高。
    • 对通信链路中的路由交换设备有额外要求,以处理镜像流量。
  • 内核级审计实现
    • 数据库 server 端性能有损失。(高权重因素)
    • 审计数据分散,收集麻烦,对运维不友好。

结论:除了腾讯与 aws 两家在数据库层面实现审计功能,其他 4 家云厂商全部采用旁路监听模式。

其他:

  • 关于腾讯宣称内核级实现更准确解释:旁路监听需要将网络报文解析成文本,还需要从文本中解析出 SQL 完整语句,如果 SQL 解析器实现存在 BUG,可能导致识别的 SQL 不准确。
  • 疑问:旁路监听模式下,基于 socket/loopback/IPv6 连接的会话行为是否能覆盖到?

不建议使用的方案

percona audit plugin

percona audit plugin 只适配自家的 mysql 分支版本。

localfile://media/16306387914744/16306438594123.jpg

官方文档中也未找到任何与其他 MySQL 分支版集成操作相关的参数或命令(无 plugin-load 对应选项,无 FORCE_PLUS_PERMANENT 对应相关参数)。


网传 init_connect with binlog(使用 threead_id 关联)方案

  • 淘汰理由-1. binlog 记录内容不全
    • 不记录 query 语句:如有人在线上执行大查询,导致 IO 资源过度消耗,严重影响业务接口响应时间,则 binlog 无法定位此类问题。
    • 一般不会记录原始语句:定位问题相关困难,如有人在线上执行 delete 操作,导致 100000 条记录被删除,则 binlog 中可能记录对应 100000 条原始行数据,从 100000 条数据中查找问题将相当困难。
  • 淘汰理由-2. 覆盖面不全:具有 super 权限的用户都会忽略 init_connect 配置

localfile://media/16306387914744/16306388508632.jpg

  • 淘汰理由-3. 权限/职责未分离:采用此方案至少给被审计用户 insert 权限,用户可以伪造审计条目(审计员的本子攥在被审计人手里)。一般被审计对象都都有比较大的权限,如 super,具有此权限的账号可以 set sql_log_bin=off;set global init_connect='';(丢到审计员的小本本 or 把审计员赶走)。

结论:此参数可见一般(可能还有其他场景未覆盖到),binlog 从来或最起码现阶段就不是为了审计而生,否则 MySQL 各分支版也不会专门推出审计插件(percona audit plugin、mariadb audit plugin、收费的 mysql enterprise audit plugin)。

调研结论

旁路监听模式审计方案目前看是主流趋势,无 agent 模式更是对数据库性能影响最小化,可以真正做到权限分离,是个人比较推荐的。此方案也最符合:依法合规(安全团队负责评估,专业的人做专业的事)、安全高效(对性能影响最小)运维方针。

标准化建设中,大部分都是由安全团队掌握堡垒机和数据库审计的控制权限,进而实现 4 级防护要求,否则就存在安全漏洞,且大大增加运维团队(不限于 DBA)的工作量。

方案 防范等级 防范对象 运维团队增加的工作量 推荐值
Init_connect with binlog 1 小部分开发(有伪造数据风险) 最多:精细化权限管控、大批量日志处理。 极不推荐
数据库本地审计(改内核/插件) 2 开发 多:大批量日志处理(类 EFK/ELK 中)。 不推荐
旁路监听(with agent) 3 开发、DBA 少:大批量日志处理(安全团队处理)。 推荐
旁路监听(without agent) 4 开发、SA、DBA 少:大批量日志处理(安全团队处理)。 极其推荐

当然,每个公司介于成本考量,对安全体系建设的程度要求不一,也可参照以上安全等级择其一进行落地实施。

参考资料

  • https://cloud.google.com/sql/docs/mysql/audit-logging

  • https://aws.amazon.com/cn/blogs/database/configuring-an-audit-log-to-capture-database-activities-for-amazon-rds-for-mysql-and-amazon-aurora-with-mysql-compatibility/

  • https://docs.microsoft.com/zh-cn/azure/mysql/concepts-audit-logs

  • https://docs.microsoft.com/zh-cn/azure/mysql/flexible-server/how-to-configure-audit-log-cli

  • https://help.aliyun.com/document_detail/52480.htm?spm=a2c4g.11186623.0.0.75832d75qtJ81E#section-tfx-us2-klj

  • https://cloud.tencent.com/document/product/672/14402

  • https://www.huaweicloud.com/intl/zh-cn/product/dbss.html

  • https://www.modb.pro/db/12486

  • https://www.percona.com/doc/percona-server/5.7/management/audit_log_plugin.html

预告

本篇都在讲数据库审计相关的内容,设想此情景: 有一 MySQL 数据库实例,未开启任何日志:error log、general_log、binlog、slow log 全部禁用,也未接入任何审计系统。运行期间发生 drop database 误删除事件,这种情况下如何定位到操作人?您可直接留言,说出你能想到的解决方案。我也将在以后的文章中给出这种情况下定位问题的方法,敬请期待(未填)!


作者:eZy_1990(ixdba/linora)

来源:公众号 - 悟空的数橘窟私房菜(ID:wkDB007)

关于作者:DBA 一枚,09 年开始接触数据库,早年间从事 Oracle DBA 一职,目前专注于开源数据库领域,混过很多家公司,也玩过很多种数据库。

其他说明:不保证全文没有任何错漏之处,如有不妥不吝赐教。

eZy

2021/10/19  阅读:51  主题:默认主题

作者介绍

eZy