Monitoreo de la actividad de la base de datos: qué observar y cómo hacerlo

Las bases de datos contienen los registros de clientes, pagos y salud que más interesan a reguladores, atacantes y auditores. Las funciones nativas de auditoría en SQL Server, Oracle, MySQL y PostgreSQL capturan cambios en objetos y permisos, pero ofrecen poca visibilidad sobre quién leyó filas sensibles.

El Informe de Seguridad de Datos e Identity 2026 de Netwrix reveló que el 75 % de las exposiciones de datos sensibles comienzan con identidades comprometidas o permisos mal configurados. La auditoría nativa ofrece la menor visibilidad donde esas identidades tienen más poder: cuentas privilegiadas que pueden editar el registro de auditoría ellas mismas.

La monitorización de la actividad de la base de datos genera un registro independiente de accesos, cambios y acciones administrativas, para que los equipos de seguridad puedan investigar incidentes, demostrar cumplimiento y detectar usos indebidos antes de que una cuenta comprometida o un cambio silencioso en la configuración se conviertan en una violación reportable.

¿Qué es la monitorización de la actividad de bases de datos?

La monitorización de la actividad de la base de datos (DAM) es una disciplina de seguridad que captura, almacena y analiza la actividad de usuarios y administradores dentro de una base de datos, independientemente del motor de base de datos. Bajo demanda, responde quién se conectó, qué leyó o cambió y si alguien modificó la configuración de auditoría.

DAM se sitúa junto a la monitorización del rendimiento, pero cumple un propósito diferente. Las herramientas de rendimiento rastrean la CPU, I/O y la latencia de consultas para mantener el motor saludable. DAM, en cambio, captura la sentencia SQL, la identidad del usuario, la dirección IP del cliente y la marca de tiempo, para que puedas vincular la actividad a una persona o servicio identificado.

Una herramienta DAM recopila esa información a través de un network tap, un agente host, o la propia función de auditoría de la base de datos, y luego la envía a un repositorio fuera de la base de datos para que el registro sobreviva a una cuenta de administrador comprometida.

Por qué es importante la supervisión de la actividad de la base de datos

Para un administrador de bases de datos (DBA) o analista de seguridad, la parte difícil de cualquier incidente o auditoría es demostrar quién tocó qué. Sin una pista independiente en la base de datos, los equipos reconstruyen esa prueba manualmente a partir de registros parciales, generalmente con un plazo límite.

Los datos sensibles se concentran en la capa de base de datos

Los registros de clientes, los datos de titulares de tarjetas y la protected health information (PHI) residen en tablas de bases de datos. Cualquier dato regulado pasa por una base de datos en algún momento. Cuando el acceso a la base de datos no se supervisa, los activos más sensibles del entorno pierden su capa más cercana de responsabilidad, y cada control posterior depende de un rastro que nunca se capturó.

Los registros nativos de la base de datos no pueden respaldar una investigación

La traza predeterminada de SQL Server captura cambios en objetos y permisos pero no la actividad SELECT, y solo conserva 100 MB de historial. Peor aún, Microsoft advierte que los sysadminsExpand pueden manipular la propia pista de auditoría, por lo que NIST SP 800-53 AU-9(2) requiere almacenar los registros de auditoría en un sistema separado del que se audita.

Los marcos de cumplimiento requieren un registro de auditoría de base de datos

Cada marco principal considera la actividad de la base de datos como evidencia. PCI DSS v4.0.1 El Requisito 10 exige 12 meses de acceso registrado a datos de titulares de tarjetas y la integridad del registro de auditoría. El 45 CFR 164.312(b) de HIPAA requiere mecanismos que registren y examinen la actividad en sistemas ePHI.

En su informe de inspección 2023 sobre Ernst & Young Incorporated (Publicación PCAOB No. 104-2024-113), el PCAOB señaló a la firma por no evaluar cómo los propietarios de control del cliente revisaron los cambios directos en la base de datos detrás de su sistema contable, en una auditoría del control interno sobre la información financiera bajo SOX.

El RGPD Artículo 5(2) exige a los responsables demostrar el cumplimiento de los principios del reglamento, lo que incluye mostrar quién accedió a los datos personales.

Las cuentas comprometidas y el uso indebido interno aparecen primero en la base de datos

Un inicio de sesión válido parece legítimo para todos los sistemas excepto para el que registra lo que hizo, por eso el robo de credenciales y el uso indebido interno rara vez activan los controles perimetrales. El 2026 Data Breach Investigations Report de Verizon encontró que el abuso de credenciales estuvo presente en el 39 % de las brechas en algún punto de la cadena de ataque, y la supervisión continua de bases de datos suele ser el primer lugar para detectar el movimiento lateral que sigue.

Actividades de base de datos que necesita monitorear

Las categorías siguientes tienen suficiente peso en seguridad o cumplimiento para justificar sus propias reglas de detección. En conjunto, cubren quién accedió, qué leyó o cambió y si alguien manipuló el registro: las preguntas con las que comienza toda investigación.

Eventos de autenticación y conexión

Los registros de inicio de sesión son el primer lugar donde una credencial robada se vuelve visible. Los inicios de sesión fallidos revelan intentos de adivinar contraseñas o credential stuffing, mientras que los inicios de sesión exitosos desde fuentes inusuales revelan que las credenciales se están usando en lugares donde no deberían.

Los inicios de sesión privilegiados y de cuentas de servicio merecen atención especial, ya que una cuenta de servicio que se conecta repentinamente desde una nueva estación de trabajo en lugar de su capa habitual de aplicación casi siempre vale la pena investigarla. Oracle habilita una predefined failed-logon policy por defecto en bases de datos nuevas, aunque las actualizadas a menudo necesitan activarla manualmente.

Lecturas de datos sensibles y exportaciones masivas

La visibilidad directa de quién consultó tablas reguladas diferencia saber que ocurrió una exposición de probar qué se tomó. El acceso por primera vez a una tabla que un usuario nunca ha tocado, y la extracción masiva mediante herramientas como bcpExpand o expdpExpand, son los patrones de lectura que más vale la pena vigilar, el mismo comportamiento que los controles de data loss prevention monitorean en el endpoint.

Cambios en el esquema y la configuración

Los cambios en el esquema y la configuración pueden destruir datos o cegar la supervisión diseñada para detectar todo lo demás. CREATE, ALTER, Expandy DROPExpand declaraciones contra tablas y procedimientos almacenados necesitan sus propias alertas, y los cambios en la configuración de auditoría merecen la respuesta más rápida. Microsoft incluye xp_cmdshellExpand deshabilitado por defecto en SQL Server porque activarlo da a un atacante una consola de comandos.

Privilegios nuevos o escalados

Una única concesión de privilegios puede convertir una cuenta limitada en una que lea todo o desactive completamente la auditoría. Los cambios en la membresía de roles, nuevos inicios de sesión y cualquier adición al rol sysadmin en SQL Server, o un rol DBA equivalente en Oracle, son alertas innegociables, el mismo privilege escalation patrón vigilado en la capa de identidad. El principio de menor privilegio es el control básico. La política ORA_ACCOUNT_MGMT de Oracle lo cubre, pero viene deshabilitada por defecto.

Cambios de datos en tablas sensibles

Cuando un salario o saldo de cuenta cambia sin autorización, la primera pregunta es cuál era el valor antes del cambio. Los registros nativos de auditoría solo registran el texto de la declaración, no los valores de la fila, por lo que se necesita un mecanismo separado que preserve el contenido antes y después, como Change Data Capture de SQL Server, el registro binario de imagen de fila de MySQL o los PostgreSQL triggers. Las alertas sobre cambios masivos o fuera de horario en tablas reguladas se asignan a MITRE T1565, Data Manipulation.

Actividad que rompe el patrón normal

Las reglas base detectan actividades que parecen normales por sí solas pero inusuales para la cuenta que las realiza, como un usuario que consulta 10 tablas en cinco minutos o una cuenta de aplicación conocida que se conecta desde una nueva dirección IP.

Esta es la única categoría que depende del análisis SIEM en lugar de la configuración nativa de auditoría, el mismo enfoque de línea base conductual que identity threat detection utiliza en la capa de cuenta.

Cómo implementar la monitorización de la actividad de la base de datos

Sigue los cinco pasos en orden, ya que cada uno depende del anterior. Lo que definas en el paso 1 determina qué método de recopilación corresponde en el paso 2, y así sucesivamente.

También asumen un equipo pequeño que no puede revisar manualmente cada evento, por lo que varios pasos a continuación dependen de implementaciones escalonadas y líneas base automatizadas en lugar de una evaluación manual.

1. Defina el alcance de lo que se monitoreará

Comience inventariando qué bases de datos contienen datos regulados o sensibles para el negocio, como nóminas, titulares de tarjetas, salud o propiedad intelectual, y clasifíquelos según el impulsor regulatorio. Ese inventario solo importa una vez que sabe qué tablas contienen campos sensibles, así que ejecute primero data classification; si lo omite, una especificación de auditoría de nómina no tendrá nada a qué referirse.

Las apuestas son reales: la encuesta detrás del Netwrix 2026 Data and Identity Security Report encontró que el 57 % de las organizaciones no mantienen continuamente un inventario de datos sensibles, por lo que la mayoría de los equipos comienzan este paso a ciegas.

Una vez que mapee las bases de datos sensibles, extienda el mismo inventario a las cuentas privileged, compartidas y de servicio que las utilizan, y comprométase a monitorear cada sesión privileged por completo, incluso cuando el registro de usuarios regulares sea selectivo.

CIS Safeguard 8.5 establece el mínimo para ese compromiso. Como mínimo, capture el nombre de usuario, la marca de tiempo y las direcciones de origen y destino de cada activo que contenga datos sensibles.

2. Elija un método de recopilación que se adapte a su entorno

La captura pasiva de red a través de un puerto SPAN es el punto de partida si necesita cero carga en el servidor. Sin embargo, esa compensación de carga cero le cuesta visibilidad en Transport Layer Security (TLS) con secreto hacia adelante, conexiones locales y bases de datos gestionadas en la nube.

Cuando bloquear una declaración es más importante que verla, un proxy inline es más adecuado, ya que termina TLS por sí mismo, aunque ese mismo control añade latencia y convierte al proxy en una dependencia de disponibilidad.

Si las conexiones locales aún necesitan cobertura después de eso, y el equipo puede tolerar el costo de CPU más el trabajo de revalidación que cada actualización del kernel o base de datos implica, un agente host cierra esa brecha. Los equipos que ejecutan base de datos como servicio (DBaaS) o que necesitan visibilidad en procedimientos almacenados y cifrado, lo logran combinando la auditoría nativa con la recopilación sin agente.

Oracle informa una sobrecarga de CPU de un solo dígito medio para la auditoría nativa de hasta 360,000 registros de auditoría por hora. La recopilación sin agente añade carga adicional, por lo que debe probar la combinación antes de implementarla.

En la práctica, la mayoría de los equipos combinan métodos de todos modos, ya que la documentación AVDF de Oracle recomienda emparejar la monitorización de red con la auditoría de bases de datos para que cada uno cubra los puntos ciegos del otro.

3. Establezca políticas y umbrales de alerta que un equipo pequeño pueda gestionar

Activa las reglas por etapas, no todas a la vez, ya que habilitar todo desde el primer día satura a un equipo pequeño con falsos positivos. Comienza ese despliegue gradual con la manipulación de auditorías y las concesiones de sysadmin, mapeadas desde las seis categorías de actividad mencionadas arriba, ya que estas dos tienen la menor tolerancia a alertas perdidas.

NIST SP 800-94 advierte que un sistema recién implementado suele generar demasiados falsos positivos antes de que sus reglas se ajusten completamente al entorno, por lo que el enfoque por etapas es fundamental aquí.

Las reglas de volumen y patrón de acceso requieren un tratamiento diferente. Ejecútelas como anomalías, ajustadas con al menos una semana de datos base, del mismo orden de magnitud que Microsoft Sentinel usa para su propia regla de anomalías de filas afectadas, que se entrena durante 14 días.

Espere que esos umbrales se mantengan locales a su entorno en lugar de seguir un número universal, ya que la anomalía para un equipo son 100 filas, para otro 500,000, y solo su propia línea base revela cuál es cuál.

4. Centralice los eventos de la base de datos y correlaciónelos con el contexto de identidad

Centralice primero la recopilación de registros, como CIS Safeguard 8.9 requiere, y utilice una herramienta que filtre grandes conjuntos de eventos a un conjunto que un humano pueda revisar, tal como recomienda NIST SP 800-61 Rev. 3. Una vez que exista esa canalización, correlacione cada evento con la cuenta detrás de él, ya que un registro centralizado sin contexto de identidad aún lo deja leyendo sentencias SQL en bruto en lugar de nombres.

En Microsoft Sentinel, esa correlación se realiza a través de tablas específicas. Dirija los eventos de auditoría de Azure SQL a la tabla SQLSecurityAuditEventsExpand (o AzureDiagnosticsExpand en configuraciones antiguas), los eventos de Windows de SQL Server a SecurityEventExpand, y las alertas de Defender a SecurityAlert;Expand luego use la tabla IdentityInfoExpand para asociar a la persona detrás de cada cuenta.

Los usuarios de Splunk e IBM QRadar pueden seguir el mismo patrón con sus propias búsquedas de identidad; el beneficio es convertir "alguien ejecutó un SELECT grande" en "una cuenta de contratista añadida a sysadmin hace dos horas ejecutó un SELECT grande."

5. Pruebe, ajuste y mantenga la canalización de monitoreo

Pruebe toda la canalización con actividad representativa antes de confiar en ella en producción. Añada un inicio de sesión de prueba a un rol de servidor, modifique una especificación de auditoría y ejecute una exportación de 600 filas, luego confirme que cada alerta llega con la identidad correcta adjunta. Una canalización que registra el evento pero pierde el contexto de identidad está solo a medio construir.

Reconstruya las líneas base cada vez que cambien las aplicaciones y vuelva a verificar periódicamente las políticas de auditoría, ya que Oracle's AVDF documentation advierte que un DBA puede modificarlas o eliminarlas. Recupere y revise la configuración según un calendario; CIS Safeguard 8.1 exige esa revisión al menos una vez al año.

La retención merece la misma disciplina. Establézcala según el mandato más estricto que aplique, tomando como base el mínimo de 12 meses de PCI DSS, y mantenga también la configuración de diagnóstico que alimenta una canalización de Azure SQL en su lista monitoreada, ya que eliminarla puede detener la recopilación sin aviso.

Cómo Netwrix te ayuda a monitorear la actividad de la base de datos

La mayor parte del trabajo anterior, desde definir el alcance hasta correlacionar el contexto de identidad, se aplica independientemente de las herramientas que uses. Netwrix Auditor cubre la recopilación, alertas y detalles antes y después para SQL Server y Oracle, y Netwrix Access Analyzer añade la capa de permisos y datos sensibles encima.

Seguimiento de inicios de sesión y acceso privilegiado

Netwrix Auditor SQL Server monitoring registra los inicios de sesión exitosos y fallidos y rastrea la actividad del DBA, incluidas las acciones privilegiadas y los cambios en los roles del servidor. Su Oracle Database monitoring supervisa los inicios de sesión exitosos y fallidos y controla las sentencias SQL y los privilegios. Para cualquiera de las fuentes, puede configurar alertas para enviar un correo electrónico a un analista o ejecutar un script que defina como una acción de respuesta.

Los informes de Auditor también sirven como evidencia de cumplimiento. First National Bank and Trust of Beloit utiliza Netwrix Auditor como su solución principal para el cumplimiento de OCC y ahora dedica una hora, en lugar de una semana, para prepararse para las auditorías. Bank of the South lo usa para proteger datos críticos para el negocio y cumplir con PCI DSS y GLBA, ahorrando al menos 40 horas al año en la preparación de auditorías.

Capturando valores antes y después de los cambios de datos

Netwrix Auditor for SQL Server funciona por defecto en modo sin disparadores, leyendo el registro de seguimiento cada cinco minutos sin carga adicional y reportando quién cambió qué y cuándo. El modo basado en disparadores añade valores antes y después para INSERT, UPDATE y DELETE, que la auditoría nativa no puede proporcionar, a costa de una carga adicional en servidores con muchas transacciones.

Conectando la actividad con datos sensibles

Netwrix Auditor aplica contexto de datos sensibles a nivel de tabla en modo sin disparadores, usando las tablas y políticas que has configurado, para que los informes puedan señalar actividad contra tablas reguladas. Para un descubrimiento y análisis de permisos más profundo en SQL Server y Oracle, Netwrix Access Analyzer mapea permisos efectivos y revela datos sobreexpuestos, más allá de lo que cubre Auditor por sí solo.

Implementación con impacto mínimo en producción

Netwrix Auditor recopila de forma remota, por lo que solo el modo basado en disparadores accede a las tablas monitoreadas. La recopilación de Oracle se realiza a través de Oracle Instant Client en el servidor Auditor cada diez minutos, y la lectura de trazas de SQL Server se ejecuta cada cinco minutos. Los complementos envían registros de actividad a Splunk, IBM QRadar y ArcSight para los equipos que ya centralizan en un SIEM.

Ponga en práctica la monitorización de la actividad de la base de datos

Comience con la instancia que contiene sus datos más regulados, establezca una línea base y expanda solo después de que el primer conjunto de alertas produzca resultados accionables.

Para cargas de trabajo gestionadas en la nube, la cobertura depende de la fuente de datos y el modelo de implementación. Netwrix Access Analyzer descubre datos sensibles y analiza permisos en SQL Server, Azure SQL, Amazon RDS para SQL Server y Oracle.

Solicite una demostración para ver cómo Netwrix puede ayudarle a monitorear la actividad de la base de datos, centralizar la auditoría y detectar el uso indebido antes de que se convierta en una brecha.