Auditoría de accesos: qué se registra
Un log operativo explica por qué falló una consulta. Un registro de accesos explica quién vio qué información y con qué habilitación. Son artefactos distintos y conviene no mezclarlos.
Por Marco Ferreiro ·
Un registro de accesos responde una pregunta distinta de la que responde un log de aplicación. El log operativo existe para diagnosticar: cuánto tardó una consulta, qué error devolvió, qué versión la atendió. El registro de accesos existe para reconstruir quién vio qué información, cuándo y con qué habilitación.
La diferencia no es semántica. Un log operativo se rota en días, se copia a herramientas de observabilidad y lo lee medio equipo. Un registro de accesos sobre datos de infracciones tiene que sobrevivir a esa rotación y pasar por menos manos. Cuando ambos viven en el mismo archivo, gana la política del más laxo.
La guía de controles de seguridad y privacidad de NIST describe qué debería contener un registro de auditoría: qué evento ocurrió, cuándo, desde dónde, con qué resultado y qué identidad estuvo asociada. Ese esqueleto se traduce bien a una consulta vehicular.
Los campos mínimos de un asiento
Un asiento útil combina identidad, alcance y decisión. En una integración de flota registramos al menos:
- momento del intento en UTC, con la zona de presentación aparte;
- identidad del actor y credencial efectiva, por identificador interno y nunca por token;
- ámbito: empresa, sucursal o grupo bajo el que se resolvió el permiso;
- referencia opaca al recurso alcanzado y su tipo, sea consulta, reporte o exportación;
- operación y canal: API, panel o proceso por lotes;
- decisión, motivo y versión de la política que la produjo;
- resultado agregado: cantidad de registros devueltos, no su contenido.
El motivo de la decisión es el campo que más se olvida y el que más sirve después. Saber que un acceso fue concedido no explica nada; saber que lo habilitó un rol sobre un ámbito, bajo una versión concreta de la matriz de permisos, permite reproducir el razonamiento meses más tarde. Las reglas además cambian: un acceso legítimo en mayo puede ser inadmisible en agosto, y sin ese campo la revisión juzga con criterios de hoy hechos de ayer.
El acceso denegado vale tanto como el concedido
Registrar sólo lo que salió bien deja ciega a la auditoría. Un rechazo describe un intento: alguien pidió datos de otra empresa, una patente fuera del alcance de su credencial o un reporte cuyo enlace ya había vencido.
Un intento aislado casi nunca significa algo; una serie sí, y esa serie sólo existe si el rechazo se escribió. Conviene además distinguir la causa —credencial inválida, permiso insuficiente, recurso inexistente— aunque la respuesta que ve el cliente sea deliberadamente indistinguible.
Qué no entra en el asiento
Un registro de accesos no es una segunda copia de los datos. Quedan afuera la patente o el documento en claro, el cuerpo de la respuesta, los encabezados con credenciales y cualquier campo que permita reconstruir el resultado leyendo sólo el log.
La razón es simple: la normativa argentina de datos personales trata la conservación como una forma de tratamiento, y la Agencia de Acceso a la Información Pública recuerda que quien es responsable de una base debe adoptar medidas de seguridad y confidencialidad. Un log que replica la respuesta hereda esas obligaciones y multiplica la superficie expuesta.
La correlación se resuelve con una referencia interna opaca. Cuando un reclamo exige llegar al dato original, lo hace un índice separado, con su propio control y su propio asiento. Qué identificadores pueden viajar en telemetría lo desarrollamos en trazas y métricas sin patentes ni CUIT.
Quién puede leer el registro de accesos
El registro es, él mismo, un dato sensible: describe conductas de personas identificables. Por eso su lectura genera un asiento propio y su acceso se separa de las funciones que audita. Quien administra los permisos no debería poder borrar la evidencia de haberlos usado.
Tres controles resuelven la mayor parte:
- escritura en un destino que la aplicación no puede editar ni truncar;
- lectura acotada a un rol de auditoría, con motivo obligatorio;
- alerta cuando el volumen de asientos cae de golpe, porque un registro vacío se parece demasiado a uno apagado.
La normativa reconoce a las personas derechos sobre sus datos personales, entre ellos conocer qué información se conserva. Ese derecho apunta al dato y no automáticamente al listado de quién lo consultó, pero el registro de accesos es lo que permite responder internamente con seriedad. Verificar que esa secuencia no fue alterada es otro problema, y lo tratamos en auditoría verificable sin payloads completos.
Qué verificar antes de necesitarlo
Un registro de accesos se prueba cuando no hace falta, no durante un incidente. Tomá una consulta de la semana pasada y reconstruila: identidad, ámbito, motivo de la decisión, versión de la política y cantidad devuelta. Si algún campo falta o llegó vacío, falta ahora y no en el peor momento.
Después probá el otro lado: intentá un acceso que debe fallar y confirmá que el rechazo dejó asiento con su causa. Revisá que ninguna patente ni documento aparezca en claro, que las lecturas del propio registro se anoten y que la ventana de conservación esté escrita y alcance a las copias de seguridad.
Metodología
- Alcance
- Composición de un asiento de auditoría de accesos para consultas de infracciones por API o panel, incluyendo qué campos se excluyen y quién puede leer el registro. No cubre integridad criptográfica ni plazos legales de conservación.
- Unidad de análisis
- Un intento de acceso a datos de infracciones, concedido o denegado, con la decisión que lo resolvió.
- Cobertura
- Criterios generales de contenido y protección de registros de auditoría según la guía de controles de NIST, contrastados con las obligaciones y derechos generales de la normativa argentina de datos personales vigentes al 29 de agosto de 2026.
Limitaciones
- La nota es orientación general de diseño y no constituye asesoramiento jurídico sobre plazos, finalidades ni bases de tratamiento de un caso concreto.
- Los campos propuestos deben ajustarse a la arquitectura real: un panel, una API y un proceso por lotes generan asientos con contexto distinto.
- Un registro completo no prueba por sí solo que la persona detrás de una credencial sea quien dice ser; la identidad depende de la autenticación.
Fuentes
- NIST SP 800-53 Revision 5 — Security and Privacy Controls — National Institute of Standards and Technology (consultada el )
- Ley 25.326 de Protección de los Datos Personales — Argentina.gob.ar (consultada el )
- Obligaciones de responsables de bases de datos personales — Agencia de Acceso a la Información Pública (consultada el )
- Derechos de las personas respecto de sus datos personales — Agencia de Acceso a la Información Pública (consultada el )
Preguntas frecuentes
¿Alcanza con el log del servidor web para auditar accesos?
Rara vez. Ese log describe solicitudes HTTP: método, ruta, código y latencia. No suele registrar qué identidad efectiva resolvió el permiso, sobre qué ámbito ni por qué la decisión fue afirmativa. Sirve para diagnóstico, no para reconstruir quién vio qué.
¿Por qué registrar también los accesos denegados?
Porque un rechazo describe un intento. Una serie de denegaciones sobre datos de otra empresa, o sobre una patente ajena al alcance de una credencial, es la señal que después permite investigar. Si sólo se registra lo concedido, ese patrón desaparece.
¿El registro de accesos puede contener la patente consultada?
Conviene evitarlo. Una referencia interna opaca cumple la misma función de correlación sin convertir el registro en otra copia de datos personales. La resolución hacia el dato original se hace desde un índice con acceso propio y por un motivo concreto.
¿Cuánto tiempo se conserva un registro de accesos?
No hay un plazo único: depende de la finalidad, del riesgo y de las obligaciones aplicables a cada responsable. Lo razonable es fijar una ventana explícita, documentar por qué y aplicarla también a copias de seguridad y exportaciones.
Notas relacionadas
Auditar consultas de multas sin guardar payloads para siempre
Una secuencia mínima de eventos y hashes encadenados puede revelar alteraciones sin convertir cada respuesta sensible en un archivo permanente.
Claves JSON duplicadas: dos clientes leen distinta la misma multa
Dos campos `status` o `amount` pueden atravesar validación sintáctica y terminar con valores distintos según el parser. La frontera segura los rechaza antes del binding.
Null, campo ausente o cero: tres respuestas distintas en un contrato de infracciones
Un monto cero es un número, null es un valor explícito y un campo ausente no fue enviado. Si el contrato los mezcla, un cliente puede informar que no hay deuda cuando sólo falta un dato.