简介启明星辰天玥数据库审计系统V6.0.17.8官方用户手册面向网络管理员与数据库安全审计人员系统讲解DAS的产品描述、安装部署、策略配置、日志告警与故障处理等全流程操作。压缩包内为单个PDF文档容量约5.67MB内容完整、目录清晰适合作为入门学习和日常运维的参考手册。目前已有913人学习下载。手册不仅涵盖一体化单机与分布式组网部署、管理员账户与权限管理、典型案例配置等实用章节还专门说明加密算法选型、SNMP安全建议、抓包合规等注意事项可帮助读者在保障数据合规的前提下完成数据库操作监控、审计策略定制与安全加固。从安装准备到故障排查均提供明确步骤与场景化指引便于快速上手独立于业务系统的数据库审计方案。1. 天玥数据库审计系统是什么这东西到底帮你盯着什么很多从业者第一次拿到天玥数据库审计系统 V6.0.17.8 的用户手册时第一反应是把它当成一个“数据库日志收集器”以为部署完、能看到 SQL 列表就完事了。实际用过一轮等保测评或数据安全治理项目后才会明白数据库审计系统的核心价值不在“记录”而在“还原”和“告警”——它能还原出某条危险 SQL 是哪个应用账号、从哪台客户端、在什么时间、以什么权限打进来的也能在拖库、撞库、误删数据这类事件发生前或发生时给出实时阻断或告警。天玥 V6.0.17.8 是国产数据库审计设备里迭代比较成熟的版本用户手册覆盖了从流量采集、策略配置到日志检索、报表输出的完整链路。这篇笔记面向三类读者刚接手数据库审计运维的人需要把设备从部署到出报告快速跑通做等保或数据安全合规整改的工程师需要把审计策略配到能经得起检查的程度以及被“审计记录太多找不到重点”困扰的熟手想搞清楚怎么让这套系统真正在攻防和溯源里发挥作用。我尽量按真实项目实施时的顺序来讲不按手册目录念。2. 部署前必须想清楚的三个问题部署模式、流量获取方式和管理面规划海量告警和日志往往不是部署后才出现的而是部署方式选错后一路累积出来的。天玥 V6.0.17.8 支持多种部署形态手册里写得比较抽象落到实际项目里主要就是三选一直连部署、旁路镜像部署、以及高可用集群部署。我先说直连。直连模式是把审计设备串接在数据库服务器和应用服务器之间所有 SQL 流量物理上必须经过设备这种模式在少数对审计实时性要求极高的内网场景才会用生产环境极少采用因为一旦设备出故障数据库链路就断了。真正让绝大多数项目跑起来的是旁路镜像部署。核心思想是利用交换机端口镜像或 TAP 分光把数据库服务器的出入流量复制一份给审计设备设备本身不参与数据链路。这样即使审计设备宕机、重启、被管理员误配置数据库业务都不受影响。这是我最推荐的默认选型也最符合运维侧的“别动我生产链路”底线。高可用集群则通常用于金融、政务类核心数据库场景两台设备做 HA镜像流量同时接入一台故障时另一台无缝接管审计任务。2.1 旁路部署时镜像流量怎么接交换机端口镜像的两种常见做法部署的第一步永远是画清楚流量路径而不是急着开箱。你需要确定数据库服务器接在哪个交换机上应用服务器的 IP 网段是什么数据库端口是默认的 3306、1521、1433 还是非标准端口。然后在交换机上做端口镜像把数据库服务器所在端口的双向流量复制到审计设备接入的镜像端口。常见的镜像配置有两种方式。一种是基于端口的镜像把数据库服务器连接的物理端口全部镜像过去另一种是基于 VLAN 的镜像把整个 VLAN 的流量镜像给审计设备。生产环境里我一般建议用端口镜像尽量精确到数据库服务器的物理端口避免镜像了整个 VLAN 后流量过大导致审计设备性能被打满。配置完镜像后先用 tcpdump 或设备自带的抓包诊断功能确认审计设备确实能收到通往 3306 或 1521 的流量再做后续的策略配置。这一步没确认清楚后面所有审计数据都是空的排查起来非常痛苦。# 在交换机上配置端口镜像以常见厂商命令风格为例 # 将连接数据库服务器的端口 GE0/0/1 镜像到连接审计设备的端口 GE0/0/24 monitor-port GE0/0/24 mirroring-port GE0/0/1 both命令里的both表示同时镜像入方向和出方向流量缺了这一项很可能只能看到应用服务器发来的 SQL看不到数据库返回的结果集导致后续“影响行数”“返回结果集大小”这类字段全部为空。配置完成后在审计设备上查看端口流量统计如果入方向包数持续增长说明镜像链路已经通了。2.2 管理面、审计面和数据面的网络规划一个容易被忽略的坑天玥设备通常有独立的管理口和审计口有些型号还支持 HA 专用口。部署时最容易犯的错误是把管理口和管理网段混在业务网段里导致审计设备的管理 IP 暴露在数据库相关网段。正确做法是管理口单独接在运维管理网审计口接镜像流量两个口之间不做路由互通。如果现场条件实在不允许分开至少要确保管理口有独立的访问控制策略只允许堡垒机和运维跳板机的 IP 访问。另一个常见问题是审计设备的时钟同步。数据库审计日志里每条记录都带时间戳如果设备时钟和数据库服务器时钟不一致后续做事件溯源时时间线是错乱的。部署时就要把 NTP 服务器地址配置到位并且确认审计设备、数据库服务器、应用服务器三方时间偏差在秒级以内。这个点看似基础却是我见过最多审计日志对不上号的根因。# 在天玥设备命令行或 Web 管理界面配置 NTP 时间同步常见做法 ntp server 192.168.10.10 prefer clock timezone Asia/Shanghai配置完成后用ntpq -p或管理界面里的时间同步状态页确认与 NTP 服务器已达同步状态。如果现场没有 NTP 服务器可以在两台设备里选一台作为时间源让另一台和它做同步。时区一定要手动确认国内项目普遍使用 Asia/Shanghai 时区如果设备默认是 UTC 时区日志时间会偏差 8 小时排查时极具迷惑性。3. 规则和策略配置从入库到告警的完整链路部署完成后下一步就是让审计系统真正“认识”你的数据库。这里说的认识不是指网络连通而是指设备需要知道被审计的数据库是什么类型、监听在哪个端口、有哪些账号、哪些是应用账号哪些是运维账号、哪些表属于核心敏感表。V6.0.17.8 的数据源配置通常支持 Oracle、MySQL、SQL Server、PostgreSQL、达梦等主流数据库类型配置数据源时要填数据库 IP、端口、实例名或服务名、数据库版本等信息。V6.0.17.8 的规则体系可以理解为三层数据源层决定审计谁策略层决定如何审计告警层决定如何响应。手动逐条配置策略对于大规模部署来说效率太低我一般会建议先按数据库类型和业务重要程度做数据源分组把核心生产库、开发测试库、办公系统库分开管理再针对不同分组配置差异化的审计策略。3.1 创建数据源和数据库分组先分区再配置避免策略混用在设备 Web 管理界面里一般路径是“数据源管理 → 添加数据源”填写数据库类型、IP、端口、实例名、所属业务系统等信息。这里有一个关键选项数据库端口。很多项目用了非默认端口例如 MySQL 跑在 3307Oracle 跑在 1522如果按默认端口去关联设备会识别不到流量导致该数据源长期处于“离线”状态。配置完成后用“测试连接”确认设备能正常获取该数据库的登录握手流量这一步验证的是“设备是否认识这个库”。创建完数据源后我习惯先建分组再建策略。例如把某核心交易库的数据源归入“核心生产库”分组审计策略级别设为最高所有 SQL 全量记录并开启高危操作实时告警把开发测试库归入“非核心库”分组只记录登录、DDL、DCL 等关键操作减少无效日志量。分组的好处是后续做报表、做权限划分时都可以按组筛选不至于所有库的日志混在一起。-- 示例某核心生产库的访问账号权限分级在审计策略里按账号维度配置 -- 超级管理员账号记录全部操作并实时告警 -- 应用业务账号记录全量 SQL但只对高危操作告警 -- 只读查询账号只记录登录日志和失败操作策略配置界面上通常有“账号”维度可以把数据库账号和审计策略关联起来。生产环境里最常见的做法是把应用使用的数据库账号设置为“记录全量、不告警普通操作”把 DBA 账号设置为“记录全量、高危操作实时告警”把疑似测试或临时账号设置为“登录即告警”。这里注意数据库账号维度的规则是精确匹配如果数据库里存在多个连接串共用同一个账号的情况策略会同时生效需要提前评估影响面。3.2 审计策略配置全量记录与风险操作识别怎么平衡审计策略的核心矛盾是“全量记录”和“有效负载”之间的冲突。全部 SQL 都记下来日志量会很大存储很快被占满而且真正有价值的告警会被海量正常查询淹没。完全不记出了问题又无从溯源。V6.0.17.8 里通常有预设的审计策略模板比如“合规审计”“运维审计”“风险审计”等我一般不建议直接套默认模板而是按实际场景做裁剪。一个我常用的基准配置是核心生产库记录所有增删改操作和 DDL 操作查询操作只记录涉及敏感表如用户表、订单表、支付表的 SELECT普通的只读查询不记录或只记录汇总统计。这个配置能覆盖绝大多数安全事件场景同时日志量控制在可接受范围。对于运维场景只记录运维账号的操作应用账号的日常操作默认不记录除非触发风险规则。风险规则包括但不限于非工作时间登录、批量删除、无 WHERE 条件的 UPDATE、对系统表的异常访问、短时间内大量失败登录等。-- 风险规则示例无 WHERE 条件的 UPDATE 语句识别 -- 匹配条件SQL 类型为 UPDATE 且语句中不含 WHERE 关键字 -- 动作记录日志并产生高优先级告警 UPDATE 规则名称 无WHERE条件UPDATE SQL在规则配置界面里一般有“特征匹配”和“行为匹配”两种方式。特征匹配是根据 SQL 文本里的关键字或正则表达式匹配行为匹配是根据操作类型、影响行数、返回结果集大小等维度匹配。实际配置中两者结合效果最好例如先按特征匹配定位到可疑语法再按影响行数做二次过滤这样能显著降低误报。3.3 告警响应设置邮件、Syslog和界面弹窗怎么选告警方式的选择决定了安全事件能否被及时感知。V6.0.17.8 通常支持邮件告警、SNMP Trap、Syslog 转发和界面告警中心。我在项目里的做法是高危风险规则同时启用界面弹窗和邮件告警中危规则只做界面告警并每日汇总低危或信息级事件不告警只留日志。如果客户现场有 SIEM 平台则把所有高危告警通过 Syslog 转发出去方便安全运营中心统一处置。配置 Syslog 转发时需要确认设备支持的标准格式是 RFC 3164 还是 RFC 5424以及是否需要配置特定的 facility 和 severity 映射。现场最常见的问题是转发出去的告警在 SIEM 里解析不出字段原因通常是设备默认发送的是中文描述的键值对格式而 SIEM 侧只配置了标准 Syslog 解析规则。解决办法是在设备侧把 Syslog 模板切换为统一格式或在 SIEM 侧配置自定义解析规则。另外邮箱告警要格外注意邮件服务器连通性测试很多项目部署完几个月后才发现告警邮件从未成功发出过原因不外乎 SMTP 端口被防火墙拦截、认证失败、发件人地址被反垃圾策略过滤。4. 日志检索与审计分析从海量记录中快速找回需要的数据配置完成后每天产生的审计日志量少则几十万条多则上亿条。如果检索能力跟不上审计系统就退化成“只存不看”的摆设。V6.0.17.8 的日志查询入口通常提供多条件组合过滤包括时间范围、数据库 IP、数据库账号、客户端 IP、SQL 类型、执行状态、影响行数、告警级别等维度。实际操作里日志检索最大的痛点是“知道有问题但定位不到具体语句”。比如安全通报说某业务系统存在 SQL 注入风险你需要快速找出所有来自外网 IP 且包含 union、sleep、benchmark 等特征的 SQL。这时仅靠基础查询是不够的需要用到高级搜索语法和正则表达式。4.1 检索语法和筛选条件字段组合检索让你快速缩小范围V6.0.17.8 的检索界面一般支持类似 SQL 的查询表达式例如在搜索框里输入client_ip1.1.1.1 and sql_typeSELECT就能组合过滤。常见的可检索字段包括源 IP、目的 IP、数据库用户名、客户端工具、SQL 类型、执行耗时、影响行数、返回行数、语句特征、告警状态等。手册里通常有一张完整的字段列表实际使用中我依赖最多的是以下字段组合字段名典型过滤条件用途场景client_ipclient_ip10.20.1.0/24定位来自某个网段的全部访问db_userdb_userbackup追踪备份账号的异常行为sql_typesql_type in (DELETE,DROP)快速发现高危操作execute_timeexecute_time 5筛选慢 SQL 或大事务keywordskeywordsselect.*into.*outfile发现导出文件的危险语句检索出结果后建议先按时间做排序再逐条打开查看完整的 SQL 文本和执行的上下文信息。V6.0.17.8 在日志详情里通常会展示关联的会话 ID、客户端工具名、应用账号、数据库返回码等信息这些信息在做事件溯源时非常关键。会话 ID 可以帮你把一次连接里的所有操作串起来看到攻击者的完整操作链而不是只看单条语句。4.2 会话行为回放为什么单条 SQL 看不出攻击意图单条 SQL 本身往往说明不了问题一次完整的攻击行为是由一系列操作组成的。例如一个拖库行为会经历多次探测性查询确认数据库版本、访问系统表获取表结构、大批量查询用户表数据、尝试导出到文件等阶段。如果只审查单条 SQL很可能把中间某次无害的版本查询当成正常行为放过。V6.0.17.8 的会话回放功能可以把同一次数据库连接内的所有操作按时间顺序展示出来还原攻击者的完整操作序列。使用会话回放时的推荐路径是从告警中心找到一条高危告警点击会话 ID 进入会话详情查看该会话在告警前后还执行过哪些语句以及每条语句的返回结果集大小。如果发现某条 SELECT 语句返回了 10 万行数据且紧接着执行了 outfile 导出操作基本可以断定这是一次正在进行的拖库行为。这种链路式的分析视角才是数据库审计系统区别于普通数据库日志的核心理由。4.3 内置报表和自定义报表给管理层的审计报告不能只丢数据每到等保测评或内部安全检查时都需要输出一份审计报告。V6.0.17.8 的报表中心通常预设了多类报表模板包括数据库操作汇总报表、风险操作统计报表、账号使用情况报表、时间段活跃度报表等。我通常建议第一次使用默认模板生成周报或月报看看哪些报表的维度是管理员真正关心的再决定是否调整。自定义报表时重点考虑三个维度时间维度日报、周报、月报、对象维度数据库、账号、客户端 IP、事件维度操作类型、风险级别、告警状态。一个实用的报表设计是“高危操作日报”列出当天所有高优先级告警的操作人、来源 IP、目标库、SQL 摘要、影响行数和处置建议每天上班时自动推送到安全管理员邮箱。这类报表比一个大而全的月度统计表更有实际运维价值也更容易被管理层理解和认可。5. 常见问题与排查这些坑我都踩过帮你提前避掉用到一定深度后真正的问题往往不是“功能不会用”而是“数据不对、告警不响、日志查不到”。这类问题最容易让人怀疑人生因为看着哪里都正常但就是结果不对。下面按我踩过的高频坑位整理成排查清单每一条都是真实发生过的对应的排查思路可以直接照做。5.1 SQL 日志漏记或延迟先查镜像链路再查数据源关联现象某数据库服务器明明有大量访问但审计系统里该数据源日志量很少或者日志延迟超过 10 分钟。原因可能是交换机镜像端口配置了过滤 ACL把部分流量丢掉了也可能是审计设备接入的镜像端口本身有速率限制在业务高峰时丢包严重还有可能是数据源配置的端口和数据库实际监听端口不一致导致设备把流量识别成未知协议而没有入库。解决第一步在审计设备上看端口流量统计是否与交换机镜像流量统计大致匹配如果设备收到流量但解析出来的协议不匹配检查数据源端口配置如果设备收到流量本身就少检查交换机的镜像配置和 ACL。对于高峰期丢包问题可以临时在设备上开启抓包或流量统计工具确认丢包比例是否超过阈值。如果丢包率超过 1%需要优化镜像策略或升级设备处理能力。5.2 告警不触发或误报过多优先级检查策略匹配顺序和阈值现象测试时手动执行了高危 SQL但告警没有按时推送或反之日常正常操作频繁触发高危告警。原因通常是策略匹配顺序设置不当或阈值设置得过于严格或过于宽松。解决V6.0.17.8 的多条策略之间一般有匹配顺序命中了前面的策略就停止匹配后面的策略。如果前面有一条“记录所有操作”的宽泛策略后面的“高危操作告警”策略可能永远没机会生效。排查时先确认策略列表里的优先级关系把具体规则放在宽泛规则之前。阈值设置方面无 WHERE 条件 UPDATE 这类规则建议直接命中即告警而失败登录这类行为规则建议设置时间窗口内的次数阈值例如 5 分钟内失败登录超过 10 次才告警避免单次密码错误就触发告警轰炸。5.3 日志详情里客户端 IP 全部是同一个地址检查是否开启了统一源 IP 映射现象明明不同终端在访问数据库但审计日志里所有操作的客户端 IP 都显示为应用服务器的 IP。原因通常是因为应用服务器使用连接池访问数据库数据库看到的源 IP 都是应用服务器的 IP并不是最终用户的真实 IP。解决这类场景需要开启应用关联或中间件解析配置从应用服务器传来的 HTTP 头或业务参数里提取真实用户 IP。V6.0.17.8 部分版本支持通过关联参数解析来还原真实客户端地址。如果无法实现完整解析至少要保证应用层账号能区分业务类型并把应用服务器 IP 单独标记为“内部跳转地址”避免误判为外部来源。在实际排查中应用服务器 IP ≠ 操作者 IP 是最常见的溯源障碍一定要提前和客户确认清楚。5.4 数据库账号密码变更后审计失效重新验证数据源连接信息现象某数据库实例调整了账号密码或端口后审计系统对该库的操作日志从某个时间点开始断档或者显示数据源离线。原因很简单数据源配置里的连接信息没有同步更新。解决数据库侧发生变更后需要同步到审计系统的数据源配置里更新端口、实例名、服务名等信息。注意数据库审计设备不需要数据库账号密码来做镜像流量审计但数据源配置里的连接信息如果和实际不匹配设备就不知道去关联哪个流量自然无法正确入库。项目上线时就要建立配置变更联动机制明确数据库变更时由谁负责同步审计系统配置。5.5 审计日志存储空间溢出导致旧日志被覆盖设置存储预警及时扩充容量现象日志查询时发现最早只能查到最近几天的数据更早的记录不见了。原因通常是磁盘空间已满设备自动清理了最早的历史日志。解决查看存储管理中的磁盘使用率和日志保留策略。V6.0.17.8 一般支持按存储天数和按空间比例两种清理策略我建议设置存储空间达到 80% 时触发告警留出充足时间扩容或归档。对于有长期留存要求的项目可以配置日志归档到外部存储或者定期导出日志进行离线保存。这类事件最怕的是等保检查时发现日志留存时间不足整改成本很高。6. 让审计策略真正有效几个提高命中率和溯源效率的实用习惯前面把部署、配置、使用和排查都过了一遍最后一章想把几个让审计系统真正发挥价值的技巧收拢起来。这些技巧是手册里不会写的更多来自实际运维中的反思。先说策略优化的迭代节奏。上线初期可以先把策略全开一段时间观察实际产生的告警类型再逐步收敛。我通常在第二周做一次告警分析把一周内触发告警数量排名前五的规则找出来逐个确认是真实风险还是误报。如果是误报调整规则参数或关闭该规则如果是真实风险确认处置流程是否闭环。这个节奏比“配好就再也不动”要健康得多。配置完成后在测试环境上我习惯用真实的攻击工具或写几个典型的高危 SQL 做模拟验证确认告警确实能按预期触发而不是自己骗自己。日志检索和溯源方面有个让人印象深刻的教训某次排查一个数据导出问题花了一整天都没定位到是谁在什么时间导出了敏感数据原因就是我一开始只查了 SQL 类型为 SELECT 的日志漏掉了同一个会话里最后执行的那条 outfile 语句。从那以后我的检索习惯是先找会话再筛语句不论确认事件的起点是告警还是某条异常 SQL都先进入会话详情页面把整个会话的操作链路完整拉出来再判断是否需要继续扩大范围到同一客户端 IP 的近段时间全部会话。还有一个值得养成的习惯是定期抽查审计策略与实际数据库资产的匹配度。项目上线时配置的数据源清单半年后可能已经有新的数据库实例上线但没接入审计或者旧实例已下线但策略还在运行产生无效日志。每隔一两个季度和 DBA 团队对一次资产清单把新增数据库实例和下线实例同步到审计系统避免审计覆盖面与真实资产脱节。这种脱轨在系统数量较多的环境里发生概率极高是审计有效性最大的隐形杀手。最后说一个让报告更有说服力的细节在输出审计报告时不要只给统计数字而是在风险事件列表后面附带典型会话回放和规则命中说明例如“该 UPDATE 语句未包含 WHERE 条件命中规则 R-10086已触发高优先级告警并通知值班人员”。这种报告给到管理层和安全测评方能直接证明审计系统不是摆设而是真实可用的防线。我的习惯是每月第一个工作日导出上月高危操作统计表按风险级别排序后逐条确认处置状态再归档。这个习惯坚持下来应对等保测评和内部审计时就有充足的底气。希望帮到你。本文还有配套的精品资源点击获取