数据库保存着监管机构、攻击者和审计人员最关心的客户、支付和健康记录。SQL Server、Oracle、MySQL 和 PostgreSQL 的本地审计功能捕获对象和权限变更，但对谁读取了敏感行的可见性很有限。
Netwrix 2026 数据与Identity安全报告发现75%的敏感数据泄露始于身份被泄露或权限配置错误。原生审计在这些身份拥有最大权限的地方——可以自行编辑审计轨迹的privileged accounts——的可见性最低。
数据库活动监控生成访问、更改和管理操作的独立记录，使安全团队能够调查事件、证明合规性，并在受损账户或静默配置更改成为可报告的违规之前检测滥用行为。
什么是数据库活动监控？
数据库活动监控（DAM）是一种安全学科，独立于数据库引擎本身，捕获、存储并分析数据库内用户和管理员的活动。按需回答谁连接了，读取或更改了什么，以及是否有人修改了审计配置。
DAM 与性能监控并行存在，但用途不同。性能工具跟踪 CPU、I/O 和查询延迟以保持引擎健康。DAM 则捕获 SQL 语句、用户身份、客户端 IP 地址和时间戳，以便将活动关联到特定人员或服务。
DAM 工具通过 network tap、主机代理 或数据库自身的审计功能收集信息，然后将其转发到数据库外的存储库，以确保记录在管理员账户被攻破时依然保存。
为什么数据库活动监控很重要
对于数据库管理员（DBA）或安全分析师来说，任何事件或审计中最难的部分是证明谁操作了什么。没有独立的数据库轨迹，团队通常在截止日期前从部分日志手工重建该证据。
敏感数据集中在数据库层
客户记录、持卡人数据和protected health information (PHI) 存储在数据库表中。任何受监管的数据都会在某个阶段经过数据库。当数据库访问未被监控时，环境中最敏感的资产将失去其最近的责任层，所有下游控制都依赖于从未被捕获的痕迹。
本地数据库日志无法支持调查
SQL Server 的默认跟踪捕获对象和权限更改，但不捕获 SELECT 活动，并且仅保留 100 MB 的历史记录。更糟的是，Microsoft 警告 sysadmins 可以篡改审计轨迹本身，这就是为什么 NIST SP 800-53 AU-9(2) 要求将审计记录存储在与被审计系统分开的系统上。
合规框架要求数据库审计追踪
每个主要框架都将数据库活动视为证据。 PCI DSS v4.0.1 要求10规定必须记录12个月的持卡人数据访问和审计日志完整性。HIPAA的45 CFR 164.312(b) 要求具备记录和检查ePHI系统活动的机制。
在其对Ernst & Young Incorporated的2023年检查报告中（PCAOB发布号104-2024-113），PCAOB指出该公司未评估客户的控制所有者如何审查其会计系统背后数据库的直接更改，在根据SOX进行的财务报告内部控制审计中。
GDPR 第5条第2款要求控制者证明遵守该法规的原则，包括显示谁访问了个人数据。
被泄露的账户和内部滥用首先在数据库中显现
有效的登录对除记录其操作的系统外的所有系统看起来都是合法的，这就是为什么凭证盗窃和内部人员滥用很少触发外围控制。Verizon的2026 Data Breach Investigations Report发现凭证滥用在攻击链的某个阶段出现在39%的泄露事件中，持续的数据库监控通常是捕捉随后的横向移动的最早场所。
Netwrix Auditor记录混合Microsoft环境中访问和更改事件的前后值。请求演示。
您需要监控的数据库活动
以下类别具有足够的安全性或合规性重要性，足以支持其自身的检测规则。它们共同涵盖了谁进入了系统、查看或更改了什么，以及是否有人篡改了记录：这是每次调查开始时都会提出的问题。
身份验证和连接事件
登录记录是被盗凭证首次显现的地方。登录失败揭示了密码猜测或credential stuffing，而来自异常来源的成功登录则显示凭证被用于不该使用的地方。
特权和服务账户登录值得特别关注，因为服务账户突然从新的工作站而非其通常的应用层连接，几乎总是值得调查。Oracle在新数据库中默认启用predefined failed-logon policy，但升级的数据库通常需要手动开启。
敏感数据读取和批量导出
直接查看谁查询了受监管的表，可以区分知道发生了暴露和证明被窃取了什么。用户首次访问从未接触过的表，以及通过 bcp 或 expdp 等工具进行的大批量提取，是最值得关注的读取模式，这与端点的 data loss prevention 控制监视的行为相同。
架构和配置更改
架构和配置更改可能会破坏数据或使旨在捕捉其他所有内容的监控失效。 CREATE、ALTER、和 DROP 针对表和存储过程的语句需要单独警报，审计配置的更改本身也应得到最快响应。 Microsoft在SQL Server中默认禁用 xp_cmdshell，因为启用它会给攻击者一个命令行界面。
新的或升级的权限
单个权限授予可能将有限账户变为可读取所有内容或完全禁用审计跟踪的账户。角色成员变更、新登录以及对SQL Server中的sysadmin角色或Oracle中等效的DBA角色的任何添加，都是不可协商的警报，同样是privilege escalation模式，在身份层进行监控。最小权限是基本控制。Oracle的ORA_ACCOUNT_MGMT策略涵盖此项，但默认情况下处于禁用状态。
对敏感表的数据更改
当薪资或账户余额未经授权发生变动时，首要问题是变动前的数值是多少。原生审计记录仅记录语句文本，不记录行值，因此需要一个单独机制来保存变动前后的内容，比如 SQL Server 的 Change Data Capture、MySQL 的行图像二进制日志，或 PostgreSQL triggers。对受监管表的大批量或非工作时间变更的警报对应 MITRE T1565, Data Manipulation。
打破正常模式的活动
基线规则捕捉那些单独看似普通但对执行账户来说异常的活动，例如用户在五分钟内突然查询10个表，或已知应用账户从新的IP地址连接。
这是唯一依赖于SIEM分析而非本地审核配置的类别，采用了与账户层使用的identity threat detection相同的行为基线方法。
如何实施数据库活动监控
请按顺序完成五个步骤，因为每一步都依赖于上一步。您在第1步确定的范围决定了第2步适用的收集方法，依此类推。
他们还假设团队规模较小，无法手动审查每个事件，因此以下几个步骤依赖分阶段推出和自动基线，而非手动分类。
1. 定义将被监控的范围
首先清点哪些数据库存储受监管或业务敏感数据，如工资、持卡人、健康或知识产权，并按监管驱动因素进行排名。只有当您知道哪些表包含敏感字段时，该清单才有意义，因此请先运行 data classification；如果跳过，工资审计规范将无从指向。
风险是真实存在的：根据Netwrix 2026 Data and Identity Security Report背后的调查，57%的组织没有持续维护敏感数据清单，因此大多数团队在这一步骤开始时是盲目的。
一旦映射了敏感数据库，就将相同的清单扩展到访问它们的privileged、共享和服务账户，并承诺全面监控每个privileged会话，即使普通用户的日志记录保持选择性。
CIS Safeguard 8.5 设定了该承诺的最低标准。至少应捕获每个持有敏感数据资产的用户名、时间戳以及源地址和目标地址。
2. 选择与您的环境匹配的收集方法
如果需要服务器零负载，SPAN端口的被动网络捕获是起点。然而，这种零负载的权衡会导致无法看到前向保密的Transport Layer Security (TLS)、本地连接和云管理数据库。
当阻止语句比查看语句更重要时，内联代理更合适，因为它自行终止TLS，但该控制会增加延迟，使代理成为可用性依赖。
如果之后本地连接仍需覆盖，且团队能够承受CPU成本以及每次内核或数据库升级带来的重新验证工作，则主机代理可弥补这一空白。运行数据库即服务（DBaaS）或需要查看存储过程和加密的团队，则通过将本地审计与无代理收集结合来实现。
Oracle报告称本地审计的CPU开销为中等个位数，每小时最多可处理360,000条审计记录。无代理收集会增加额外负载，因此在投入使用前请测试组合效果。
实际上，大多数团队都会结合使用多种方法，因为Oracle的AVDF文档建议将网络监控与数据库审计配对，以便相互覆盖盲点。
3. 设置小团队可以执行的策略和警报阈值
分阶段启用规则，而不是一次全部启用，因为第一天启用所有规则会让小团队陷入大量误报。请从上述六个活动类别中映射的审计篡改和sysadmin授权开始分阶段推出，因为这两项对漏报的容忍度最低。
NIST SP 800-94 警告说，新部署的系统通常在规则完全调整到环境之前，会产生过多的误报，这正是分阶段方法重要的原因。
卷量和访问模式规则需要不同的处理。将它们作为异常运行，针对至少一周的基线数据进行调整，规模与Microsoft Sentinel用于其自身受影响行异常规则的训练时间（14天）相当。
预计这些阈值将保持在您的环境本地，而不是遵循统一数字，因为一个团队的异常是100行，另一个是500,000行，只有您自己的基线能揭示哪一个是哪一个。
4. 集中管理数据库事件，并将其与identity上下文关联
首先集中收集日志，正如 CIS Safeguard 8.9 所要求的，使用能将大量事件数据过滤到人类可审查范围的工具，正如NIST SP 800-61 Rev. 3所推荐。一旦建立了该管道，将每个事件与其背后的账户关联起来，因为没有身份上下文的集中日志仍然只能让你阅读原始SQL语句，而不是名称。
在 Microsoft Sentinel 中，该关联通过特定表进行。将 Azure SQL 审计事件路由到 SQLSecurityAuditEvents 表（或旧版本中为 AzureDiagnostics），将 SQL Server Windows 事件路由到 SecurityEvent，将 Defender 警报路由到 SecurityAlert； 然后使用 IdentityInfo 表来关联每个账户背后的人。
Splunk 和 IBM QRadar 用户可以使用自己的身份查询遵循相同的模式；这样就能将“有人执行了大型 SELECT”转变为“两个小时前添加到 sysadmin 的承包商账户执行了大型 SELECT”。
5. 测试、调整并维护监控管道
在生产环境中信任之前，先用代表性活动测试完整管道。向服务器角色添加测试登录，修改审计规范，运行600行导出，然后确认每个警报都附带正确的身份。记录事件但丢失身份上下文的管道只是半成品。
每当应用程序发生变化时重建基线，并定期重新检查审计策略本身，因为 Oracle's AVDF documentation 警告DBA可能会修改或删除它们。按计划检索并审查设置；CIS Safeguard 8.1 要求至少每年进行一次审查。
保留需要同样的纪律。将其设置为适用的最严格规定，以PCI DSS的12个月为基准，并将为Azure SQL管道提供诊断设置也保留在监控列表中，因为删除它可能会悄无声息地停止数据收集。
Netwrix如何帮助您监控数据库活动
上述大部分工作，从定义范围到关联身份上下文，无论使用何种工具均适用。Netwrix Auditor 负责 SQL Server 和 Oracle 的收集、警报及前后细节，Netwrix Access Analyzer 则在此基础上增加权限和敏感数据层。
跟踪登录和特权访问
Netwrix Auditor的SQL Server monitoring记录成功和失败的登录，并跟踪DBA活动，包括特权操作和服务器角色更改。其Oracle Database monitoring软件跟踪成功和失败的登录，并监控SQL语句和权限。对于任一来源，您都可以配置警报，以通过电子邮件通知分析师或运行您定义的脚本作为响应操作。
Auditor报告也可作为合规证据。 First National Bank and Trust of Beloit 将Netwrix Auditor作为其主要的OCC合规解决方案，现在准备审计只需一小时，而非一周。 Bank of the South 使用它来保护关键业务数据并遵守PCI DSS和GLBA，每年在审计准备上节省至少40小时。
捕获数据更改的前后值
Netwrix Auditor for SQL Server 默认以无触发器模式运行，每五分钟读取一次跟踪日志，无额外负载，并报告谁在何时更改了什么。基于触发器的模式为 INSERT、UPDATE 和 DELETE 添加了前后值，这是本地审计无法提供的，但会增加高事务服务器的负载。
将活动连接到敏感数据
Netwrix Auditor 在无触发器模式下于表级应用敏感数据上下文，使用您配置的表和策略，使报告能够标记受监管表的活动。对于跨 SQL Server 和 Oracle 的更深入发现和权限分析，Netwrix Access Analyzer 映射有效权限并揭示超暴露数据，超出 Auditor 单独覆盖的范围。
以最小的生产影响进行部署
Netwrix Auditor 远程收集，因此只有基于触发器的模式会直接访问被监控的表。Oracle 收集通过 Auditor 服务器上的 Oracle Instant Client 每十分钟运行一次，SQL Server 跟踪读取每五分钟运行一次。插件将活动记录转发到 Splunk、IBM QRadar 和 ArcSight，适用于已集中使用 SIEM 的团队。
将数据库活动监控付诸实践
从包含您最受监管数据的实例开始，建立基线，只有在第一组警报产生可操作结果后才进行扩展。
对于云管理的工作负载，覆盖范围取决于数据源和部署模型。Netwrix Access Analyzer 发现敏感数据并分析 SQL Server、Azure SQL、Amazon RDS for SQL Server 和 Oracle 的权限。
请求演示，了解 Netwrix 如何帮助您监控数据库活动，集中审计跟踪，并在滥用成为安全漏洞之前发现它。
关于数据库活动监控的常见问题
分享到
了解更多
关于作者
