Qué constituye un acceso indebido a una base de datos
El artículo 197 bis del Código Penal tipifica el acceso no autorizado a sistemas informáticos —o a una parte de ellos— vulnerando las medidas de seguridad establecidas. En el contexto de bases de datos, esto abarca dos escenarios jurídicamente distintos pero técnicamente investigables con las mismas herramientas.
El primero es el acceso sin autorización: un tercero que no tiene credenciales legítimas explota una vulnerabilidad, utiliza credenciales robadas o aprovecha una configuración deficiente para conectarse a la base de datos. Un ataque de inyección SQL, un brute force contra el panel de administración o el uso de credenciales filtradas en un data breach anterior son ejemplos clásicos.
El segundo es el exceso de autorización: un usuario legítimo (empleado, proveedor, administrador) que tiene acceso a la base de datos pero consulta, modifica o exporta datos que están fuera de su ámbito funcional. Un comercial que descarga la cartera completa de clientes cuando su rol solo le da acceso a sus cuentas asignadas, o un administrador de sistemas que consulta datos de nóminas sin justificación operativa.
La distinción es relevante porque el enfoque pericial cambia: en el primer caso, el perito busca evidencia de intrusión externa (exploits, credenciales comprometidas, IPs anómalas). En el segundo, busca patrones de consulta que excedan el perfil funcional del usuario, lo que requiere conocer previamente qué accesos son legítimos para contrastarlos con los registrados. En ambos casos, el perito informático judicial documenta los hechos de forma que el tribunal pueda valorar si hubo acceso indebido conforme al tipo penal.
Fuentes de evidencia en una investigación de accesos
Una investigación forense de accesos indebidos a bases de datos no se limita a revisar un único log. La solidez de las conclusiones depende de cruzar múltiples fuentes independientes que corroboren la misma narrativa.
Audit logs del motor de base de datos
PostgreSQL con pg_audit registra cada sentencia SQL por usuario y sesión. MySQL con el general_log o el audit plugin captura consultas, conexiones y errores. Oracle Unified Auditing y SQL Server Audit permiten granularidad a nivel de tabla y operación. Estos logs son la fuente primaria: revelan qué consultas ejecutó cada usuario, sobre qué tablas y en qué momento exacto.
Logs de aplicación
El software que se conecta a la base de datos (ERP, CRM, panel de administración) suele tener su propio registro de actividad: qué usuario ejecutó qué acción desde la interfaz. Estos logs permiten correlacionar la acción en la aplicación con la consulta SQL subyacente y detectar accesos directos a la base de datos que sortean la capa de aplicación.
Logs de red y firewall
Los registros del firewall y del IDS/IPS documentan las conexiones al puerto de la base de datos (3306 MySQL, 5432 PostgreSQL, 1521 Oracle, 1433 SQL Server): IP de origen, volumen de datos transferidos y si la conexión fue permitida o denegada. Permiten detectar conexiones desde IPs no autorizadas o transferencias de volumen inusual.
Active Directory, LDAP y VPN
Si la autenticación se gestiona mediante directorio activo, los logs de AD registran cada inicio de sesión con timestamp e IP. Los logs de VPN documentan desde qué ubicación y dispositivo se conectó el usuario a la red corporativa. Cruzar la sesión VPN con la conexión a la base de datos permite vincular un acceso remoto a una persona concreta y una ubicación geográfica.
Correlación de eventos: quién, cuándo, qué y desde dónde
La potencia probatoria de un peritaje de accesos indebidos reside en la correlación: cruzar los registros de múltiples fuentes independientes para construir una narrativa temporal coherente que responda a las cuatro preguntas clave del tribunal: quién accedió, cuándo lo hizo, qué datos consultó o extrajo, y desde dónde se conectó.
El proceso comienza normalizando todos los timestamps a una zona horaria común (habitualmente UTC o la hora local del servidor). Los logs de la base de datos proporcionan el qué: las consultas SQL ejecutadas, las tablas accedidas, los filtros aplicados y el volumen de filas devueltas. Los logs de autenticación del motor (o del directorio activo) proporcionan el quién: la cuenta de usuario que inició la sesión y el momento exacto del login y logout.
Los registros de red y VPN aportan el desde dónde: la dirección IP de origen, que puede geolocalizarse y compararse con las IPs habituales del usuario. Si el mismo usuario que normalmente se conecta desde la oficina (IP de rango corporativo) aparece de madrugada conectándose desde una IP residencial o de otro país, el patrón es relevante para el caso.
La correlación temporal es especialmente crítica: si el log de VPN muestra que el usuario se autenticó a las 23:41, el log de PostgreSQL registra un SELECT * FROM clientes a las 23:43, y el firewall registra una transferencia de 28 MB hacia una IP externa a las 23:47, la secuencia de eventos habla por sí sola. Esta metodología es idéntica a la que se aplica en un análisis de logs para juicio, pero enfocada específicamente en la actividad sobre la base de datos.
Escenarios típicos que llegan a juicio
Tras años de experiencia en análisis forense, estos son los escenarios de acceso indebido a bases de datos que con mayor frecuencia acaban en un procedimiento judicial:
Exempleado que descarga la cartera de clientes antes de irse
El caso más frecuente. Un comercial o directivo que sabe que va a ser despedido —o que está negociando con la competencia— descarga masivamente datos de clientes, precios, condiciones contractuales o propiedad intelectual en los días previos a su salida. El peritaje documenta el volumen anómalo de consultas SELECT y exportaciones en un periodo concentrado, comparándolo con el patrón habitual del usuario en meses anteriores. La evidencia más contundente aparece cuando se demuestra que accedió a datos que no necesitaba para su función (clientes de otras zonas, datos financieros, información técnica protegida).
Insider que vende datos confidenciales
Un empleado con acceso legítimo extrae datos periódicamente para venderlos a terceros: listados de clientes, datos médicos, información financiera. A diferencia del caso anterior, las extracciones suelen ser más pequeñas pero recurrentes. El peritaje busca patrones temporales (consultas siempre a la misma hora, coincidentes con comunicaciones externas) y accesos a tablas que no corresponden con las funciones asignadas al rol del empleado.
Acceso mediante credenciales compartidas
Un competidor, un exsocio o un proveedor que conoce credenciales de acceso compartidas (la contraseña del usuario «admin» que nadie cambió en años) accede a la base de datos para obtener información comercial privilegiada. El reto pericial es vincular el acceso a la persona concreta cuando la cuenta utilizada es genérica: se recurre a la IP de origen, los horarios, la correlación con otros sistemas y, en ocasiones, al análisis del dispositivo del sospechoso.
Administrador que modifica registros
Un DBA o administrador de sistemas descontento que modifica o elimina registros de la base de datos como represalia o para encubrir un fraude. Es el escenario más difícil de investigar porque el administrador suele tener privilegios para desactivar o modificar los propios logs de auditoría. El peritaje se centra en fuentes externas al control del admin: logs del SIEM centralizado, registros de red, backups que permitan comparar el estado de los datos antes y después de la modificación.
Errores que destruyen la prueba de acceso indebido
La diferencia entre un caso que prospera y uno que se archiva por falta de prueba técnica suele estar en errores cometidos antes de que el perito intervenga. Estos son los más frecuentes y los más dañinos:
No tener el audit logging activado
La mayoría de motores de bases de datos no activan la auditoría detallada por defecto. Si no se configuró pg_audit, el general_log o el equivalente antes del incidente, no existirá registro de las consultas ejecutadas. Se sabrá que alguien se conectó (log de autenticación), pero no qué hizo una vez dentro. Sin este dato, la prueba del acceso indebido se debilita enormemente.
Perder los logs por rotación automática
Los logs se rotan y sobrescriben automáticamente cuando alcanzan un tamaño o antigüedad configurados. Si el incidente se detecta semanas después de producirse y la rotación es de 7 días, los registros críticos ya no existen. Enviar los logs a un servidor centralizado (SIEM) o a un almacenamiento inmutable previene este problema.
Acceder a la base de datos «para comprobar» sin metodología forense
Cuando la empresa sospecha un acceso indebido, el instinto del equipo IT es conectarse a la base de datos para verificar qué pasó. Cada consulta que ejecutan genera nuevos registros en los logs, mezclándose con la actividad del atacante y dificultando la reconstrucción cronológica. Además, si acceden con la misma cuenta sospechosa, contaminan la evidencia de sesión de ese usuario.
No preservar los backups que muestran el estado anterior
Si el acceso indebido incluyó modificación o borrado de datos, la única forma de demostrar qué cambió es comparar el estado actual con un backup anterior al incidente. Si los backups se reciclan por política de retención antes de que el perito los adquiera, se pierde la posibilidad de hacer esa comparación. Preservar los backups es tan importante como preservar los logs. La cadena de custodia digital debe aplicarse también a las copias de seguridad.
Qué incluye el informe pericial en estos casos
El informe pericial de un acceso indebido a base de datos debe proporcionar al tribunal una narrativa técnica clara, respaldada por evidencia verificable. Estos son los elementos esenciales que incluye:
Timeline de accesos documentada. Una cronología detallada de todas las conexiones y consultas relevantes, con timestamp normalizado, usuario, IP de origen, sentencia SQL ejecutada y resultado. Cada entrada referencia el registro original en los anexos para que otro perito pueda verificarla.
Mapeo usuario-consulta. Una tabla que vincula cada usuario identificado con las consultas específicas que ejecutó, agrupadas por sesión. Esto permite al juez entender de un vistazo qué hizo cada persona, sin necesidad de interpretar SQL. Las consultas se traducen a lenguaje natural: «El usuario X consultó todos los registros de la tabla de clientes con facturación superior a 50.000 euros.»
Evaluación del alcance de los datos afectados. Determinar no solo que hubo acceso, sino a cuántos registros, de qué naturaleza (datos personales, secretos comerciales, información financiera) y si hubo exportación efectiva. La diferencia entre «consultó 5 registros de su zona» y «exportó 12.000 registros de todas las zonas a un CSV» es determinante para la calificación jurídica.
Documentación de la cadena de custodia. Cómo se adquirieron los logs, con qué herramientas, cuándo, quién los custodiaba antes del peritaje y cómo se ha garantizado su integridad (hashes SHA-256 de cada archivo de log en el momento de la adquisición).
Comparación con patrones de acceso autorizados. Para demostrar que un acceso fue «indebido», el perito contrasta la actividad investigada con el patrón habitual del usuario (qué tablas consulta normalmente, en qué horario, con qué frecuencia) y con la política de permisos de la organización. La anomalía solo es significativa si se establece primero cuál es la normalidad. Este análisis comparativo es lo que transforma datos técnicos en prueba de acceso indebido.
¿Sospechas de un acceso indebido a tu base de datos?
Investigo accesos no autorizados a bases de datos con metodología forense, preservando la evidencia para que tenga valor en un procedimiento judicial.
Preguntas frecuentes
Depende del motor. En PostgreSQL, instala y configura pg_audit para registrar sentencias DDL y DML por rol. En MySQL, activa el general_log o, mejor, el audit_log plugin de Enterprise. En SQL Server, habilita SQL Server Audit con especificaciones de auditoría a nivel de servidor y base de datos. En Oracle, configura unified auditing. En todos los casos, registra al menos: inicio y cierre de sesión, consultas SELECT sobre tablas sensibles, operaciones INSERT/UPDATE/DELETE, cambios de permisos y exportaciones masivas (COPY, SELECT INTO OUTFILE, bcp). Sin estos logs activos antes del incidente, la investigación forense queda gravemente limitada.
Sí, si el audit log registra las sentencias completas. Con pg_audit en PostgreSQL o el general_log en MySQL, se captura la consulta SQL íntegra: tablas accedidas, filtros WHERE aplicados y columnas solicitadas. Esto permite al perito reconstruir no solo que el usuario ejecutó una consulta, sino exactamente qué registros obtuvo. Si además existen logs de exportación (COPY TO, mysqldump, bcp), se puede determinar si los datos se extrajeron a un archivo externo. La limitación principal es que los logs de consulta en producción generan un volumen elevado, por lo que muchas empresas solo los activan para roles o tablas específicas.
No hay un periodo legal único. La configuración por defecto de la mayoría de motores rota los logs automáticamente cuando alcanzan un tamaño determinado o tras un número de días. PostgreSQL, por ejemplo, recicla los WAL y los logs de consulta según log_rotation_age y log_rotation_size. MySQL rota el general_log según expire_logs_days. En la práctica, muchas empresas pierden logs relevantes en 7-30 días por rotación automática sin ser conscientes. La recomendación forense es configurar una retención mínima de 12 meses para logs de auditoría y enviarlos a un SIEM o servidor centralizado fuera del alcance del administrador de la base de datos.
Técnicamente, sí, si no se han revocado correctamente sus credenciales. Es sorprendentemente habitual que las cuentas de exempleados permanezcan activas semanas o meses después de la baja. Si el empleado conocía credenciales compartidas o de servicio, podría acceder incluso después de desactivar su cuenta nominal. El perito investiga los logs de autenticación para detectar accesos posteriores a la fecha de baja, correlacionándolos con las IPs de origen y las sesiones VPN. Si se demuestra el acceso posterior al despido con credenciales no revocadas, puede constituir un delito del art. 197 bis CP independientemente de que la empresa fuera negligente en la gestión de credenciales.
Depende del contexto y la intención. Si el empleado accede a datos que necesita para su trabajo habitual, no hay ilícito. Pero si descarga masivamente datos de clientes que exceden su función, con intención de usarlos en beneficio propio o de un competidor, puede incurrir en varios tipos penales: revelación de secretos (art. 197 CP), acceso indebido a sistemas si excede sus privilegios autorizados (art. 197 bis CP), y competencia desleal (Ley 3/1991). Además, si los datos contienen información personal, puede haber infracción del RGPD. El perito documenta el volumen y naturaleza de los datos accedidos, la frecuencia y el patrón temporal para establecer si el acceso fue operativo o anómalo.
No. El peritaje puede realizarse como diligencia preventiva antes de presentar denuncia, como prueba preconstituida para un futuro procedimiento civil o penal, o como investigación interna de la empresa sin necesidad de judicializar el asunto. De hecho, es recomendable realizar el peritaje antes de la denuncia: así se preserva la evidencia con garantías y se presenta ante el juzgado un informe técnico sólido desde el primer momento, lo que facilita la admisión de la prueba y la comprensión de los hechos por el juez.
Sí. Los servicios gestionados de bases de datos en la nube (AWS RDS, Google Cloud SQL, Azure SQL Database) generan sus propios logs de auditoría accesibles mediante las consolas de administración o APIs del proveedor. AWS RDS, por ejemplo, permite habilitar audit logs que se exportan a CloudWatch. Cloud SQL de Google integra data access audit logs en Cloud Logging. El perito puede adquirir estos logs con garantías forenses (exportación con hash, documentación de la fuente y el momento de adquisición). La diferencia con un servidor on-premise es que no hay acceso físico al hardware, pero la evidencia lógica (logs, snapshots, backups) suele ser igualmente válida en procedimientos judiciales.
La auditoría de seguridad es preventiva: evalúa la configuración, los permisos, las vulnerabilidades y el cumplimiento normativo de la base de datos para evitar incidentes futuros. El peritaje forense es reactivo: investiga un incidente que ya ha ocurrido para determinar qué pasó, quién lo hizo, cuándo y qué datos se vieron afectados. La auditoría recomienda mejoras; el peritaje produce un informe con valor probatorio para un procedimiento judicial. Ambos comparten herramientas y conocimientos técnicos, pero difieren en objetivo, metodología y forma de presentación de resultados. Una buena auditoría previa facilita enormemente un peritaje posterior, porque garantiza que los logs necesarios existen y están correctamente configurados.