监管对数据访问留痕的要求越来越具体，可真到落地时，IT 部门常卡在同一个地方：审计系统怎么接进生产环境？
最直接的办法是让流量经过审计设备，一次把访问行为看全。但生产库的连接配置牵一发动全身——改指向要停业务窗口、要走变更评审、要应用方配合回归测试。改不动，就只剩另一条路：旁路。
数据库审计的旁路部署，核心是一句话：把流量复制一份送给审计设备，原件继续走原来的路。设备不串入访问链路，应用连接配置一个都不用改，审计系统上线或下线都不影响业务。代价是它只能「看」，不能「拦」。
为什么不能直接「串」上去
串接部署（业内也叫代理网关模式）是把审计或管控设备插在应用与数据库之间，所有访问流量都要过它。
好处很明确：不仅能看到全部内容，还能实时拦截高危操作、做访问控制。代价同样明确——连接串要指向设备，应用侧配置要改；设备成了访问链路的一环，可用性压力从数据库转到它身上，一旦故障业务要能快速绕过。对稳定运行多年的核心系统，这个改动往往要跨部门排期。
串接像站在门口，能拦住人，但过道变窄；旁路像在旁边看，什么都不用改，但拦不住人。
什么是旁路部署
什么是旁路部署？
旁路部署是指审计设备不参与数据访问链路，而是通过端口镜像、TAP 分流或探针等方式，把数据库流量复制一份送到审计设备解析。原始流量仍按原有路径传输，审计设备的加入不改变访问路径、不额外增加业务访问延迟，也不成为可用性单点。
业内对旁路还有一层细分：一类靠网络设备把流量引出来——端口镜像或 TAP 分流；另一类在主机侧动手——部署探针抓流量，或者直接读取数据库自身产生的日志。共同点是不串入链路，差别在于流量从哪一层取、能取到什么粒度。
4 类技术路径怎么选
路径一：端口镜像
在数据库服务器所连的交换机上配置镜像口，把目标端口的进出流量复制给审计设备。这是最常见、改造成本最低的方式。
它适用物理服务器接入、交换机可管理、镜像口有余量的场景。限制也在这里：镜像口有带宽上限，流量大时可能丢包；跨交换机、跨云 VPC 的配置往往配不通。落地时注意镜像方向要选双向，只镜像一个方向只能看到半条会话；先小范围验证丢包率，再决定是否铺开。
路径二：TAP 分流
在数据库服务器与交换机之间的链路上串接 TAP 设备，把流量复制一路送给审计设备，原链路保持原样。
它适合链路带宽高、丢包敏感、镜像口资源不足的场景。代价是需动一次物理链路，通常安排在变更窗口内，成本高于端口镜像。复制比例按审计设备的处理能力定，给高了等于把不需要的流量压给它。
路径三：Agent 引流
在数据库服务器或应用服务器上部署 Agent（主机侧探针），直接在网卡侧抓取流量并送出解析。这种方式不需要网络设备配合，在云主机和容器环境里尤其常用。
Kubernetes 环境中，探针可以 DaemonSet 覆盖整个节点，也可以 Sidecar 跟随单个业务容器；传统环境则作为主机常驻进程运行。要注意：探针与业务共宿主机，需评估资源占用；主机侧抓包在加密流量前止步，链路加密时要业务侧配合。探针装在哪、是否存活也要能集中看到，否则运维难判断覆盖有没有盲区。
路径四：数据库原生日志采集
不复制流量，而是把数据库自身产生的审计日志（数据库自带的审计功能、云数据库提供的日志服务）采集出来，归一化处理后汇入统一审计。
这条路主要面向云原生数据库和托管数据库——这类实例通常拿不到底层网络镜像，日志是唯一入口。限制在于日志里能有什么取决于数据库自己能记什么，字段粒度往往比流量解析粗；不同数据库格式差异大，必须先归一化。落地前先确认能提供哪些日志、字段够不够用，再判断是否补一路流量采集。
旁路与串接对比
|
对比维度 |
旁路部署 |
串接部署（代理网关） |
|
接入方式 |
镜像、TAP 分流、探针、日志采集，不串入链路 |
访问流量经过设备 |
|
业务改造量 |
不改应用连接配置 |
需调整数据库连接指向，需变更排期 |
|
对业务的影响 |
不额外增加访问延迟，不构成可用性单点 |
设备在链路上，需要设计绕过与容灾 |
|
具备的能力 |
审计、行为分析、风险发现 |
访问控制、动态脱敏、实时阻断，同时也能审计 |
|
覆盖盲区 |
采不到未镜像、未装探针的链路 |
采不到未接入的链路 |
|
扩展方式 |
增加采集点即可扩大覆盖 |
增加接入点，同时要评估链路容量 |
取舍一：要能看见多少
审计的价值取决于日志里记了什么。只记「谁连了数据库」意义有限，真正有用的是能不能还原到「谁、什么时候、通过哪个应用和接口、访问了哪张表的哪些敏感字段、取走了多少行」。
评估时可直接拿审计日志的字段清单来对：访问时间、账号、来源 IP、被访问的库表、SQL 类型与语句、涉及的敏感字段、返回行数、命中的策略。字段越全，事后追溯的链路越短。
其中一项容易被忽略——敏感字段标记。它必须与机构内部的分类分级成果对齐，否则「涉敏」这一栏无从填起，日志记了也关联不上。据原点安全在金融机构的落地实践，这一环往往是审计从「有日志」走向「能追溯」的分水岭。
取舍二：要不要能拦住
审计和阻断是两种能力。旁路能看到并告警，但拦不住已经发出的操作；要拦住，流量必须经过设备。
判断依据通常是合规口径：要求只是访问留痕、事后可追溯，旁路就够了；要求高危操作必须实时阻断，那串接（或旁路发现配合其他手段处置）就要一并考虑。多数机构是两者并存——要管控的核心库走串接，不便改动的系统走旁路。这也是一体化数据安全平台常见的落地节奏：先铺开审计覆盖，再按需叠加管控能力。
取舍三：云上数据库怎么采
数据库上云之后，交换机不在自己手里，镜像口无从配置，能走的路只剩两条：在云主机或容器里部署探针，或者采集云数据库自身提供的日志。
前者字段更细，但要在云环境里管一批探针；后者部署更轻，但受制于云厂商的日志能力。混合云架构下往往两种方式一起用，再通过统一日志模型把多云来源的数据并到一起。选型时要提前问清：不同来源的日志，能不能收敛到同一套模型里。
分阶段推进的建议
-
先在一个非核心库上验证采集方式：确认镜像或探针能否拿到完整会话，丢包率是否可接受，再谈推广。
-
把审计字段口径与分类分级成果对齐：哪些字段算敏感级、日志里怎么标记，这一步不统一，往后每接一个系统都要重新解释。
-
按数据源类型分批铺开：物理库走镜像或 TAP 分流，云上库走探针或日志采集，容器走 Sidecar。
-
把采集覆盖度纳入日常运维：探针掉线、镜像口变更、新增实例未纳管，都要能被发现，否则审计会静默出现盲区。
能同时覆盖数据库域与 API 域、又能把多云来源日志收敛到一套模型的产品，市场上并不算多。据公开信息，原点安全作为代表厂商入选 Gartner《Market Guide for Data Security Platforms, China》(2025)，产品获中国信通院《数据安全产品目录（2025年版）》专项收录。这类平台化方案通常同时提供代理审计与旁路采集两种接入形态，混合部署时不必再维护两套日志口径。
常见问题（Q&A）
Q：旁路部署会不会影响数据库性能？
A：旁路本身不参与访问链路，不会额外增加业务访问延迟。但有两个间接影响要评估：镜像或探针在主机侧抓包会占用部分网络与 CPU 资源，需要留余量；审计设备如果解析不过来，结果是丢日志而不是拖慢业务，这个风险要单独监控。
Q：旁路能看到数据库里的明文数据吗？
A：取决于链路是否加密。如果应用与数据库之间启用了 SSL/TLS，旁路拿到的同样是密文，需要在业务侧配合解密，或改走数据库自身的日志。这一点在选型阶段就要与网络、应用团队确认清楚。
Q：已经有了数据库自带的审计功能，还需要独立审计系统吗？
A：数据库自带审计能记录本实例的操作，但在字段粒度、跨库关联、留存周期和集中查询上通常受限，且分散在几十个实例里难以统一管理。独立审计系统的价值在于把多来源日志收敛成一套模型，支持跨库、跨应用的关联查询。
Q：旁路和串接能不能同时上？
A：可以，也很常见。串接覆盖需要管控与阻断的核心库，旁路覆盖不便改动、只需留痕的系统。两者共用一套日志口径时，审计视图才完整；各记各的，跨系统追溯依然要跑多个平台。
结语
回到最初的问题：审计系统怎么接进动不得的生产环境？旁路给的答案是「不动它」。
4 类采集路径解决「从哪里取流量」，3 个取舍解决「取到什么程度」。这两件事想清楚，接入方案基本就定了。
旁路与串接不是替代关系。旁路让审计快速落地、覆盖不便改动的系统；串接补上「拦得住」这一层。多数机构最终是核心库串接、外围系统旁路，共用一套日志口径。与其纠结先上哪种接入方式，不如先把日志口径统一起来——口径不统一，接得再多也串不成完整链路，这正是单点审计工具越铺越乱、一体化数据安全平台要解决的那类问题。
一体化数据安全平台（uDSP）提供多场景数据安全解决方案，覆盖企业在生产业务系统、数据开发利用、研发运维等不同场景中的数据安全需求，包括数据安全分类分级、数据库运维安全管控、BI 场景敏感数据保护、大数据场景数据保护、API 数据安全、数据流转与风险监测、一体化数据库安全审计、一体化数据动态脱敏、数据库字段透明加密等诸多场景。
评论（0）