¿Qué conviene registrar en los "registros de auditoría" que suelen pedirse en los concursos?
Hola, soy Otsuka, CTO de Liberogic.
Cuando participamos en concursos para sitios web o servicios web, es frecuente encontrar requisitos como "debe poder obtenerse un registro de auditoría" o "los registros deben conservarse durante un periodo determinado".
Para cumplir con esos requisitos, se elige un servicio, se cambia de plan o se añaden opciones de almacenamiento de registros. Sin embargo, ¿a qué se refiere exactamente el "registro de auditoría"?
En este artículo intentaremos aclarar un poco estos puntos.
Tipos de registros
En términos generales, existen varios tipos de registros.
Tipos de registro | Qué registran principalmente | Usos principales |
|---|---|---|
Registros de acceso | URL, fecha y hora, estado, origen de la conexión, etc. | Investigación del uso y de las incidencias |
Registros de la aplicación | Inicio y finalización de procesos, eventos de negocio | Verificación del funcionamiento y análisis de fallos |
Registros de errores | Excepciones, terminaciones anómalas y detalles de los errores | Identificación de la causa de las incidencias |
Registros de auditoría | Quién, cuándo y qué operó | Control interno y conservación de evidencias |
Registros de seguridad | Autenticación, accesos denegados y detección de ataques | Investigación de incidentes |
Todos son registros, pero el contenido que almacenan y la finalidad para la que se utilizan son distintos.
Por ejemplo, los que registran acciones como que un administrador cambió los permisos de un usuario o que un responsable publicó un contenido se parecen a lo que comúnmente se conoce como registros de auditoría.
Investigación de fallos y conservación de evidencias: consideraciones por separado
La finalidad de los registros se divide, a grandes rasgos, en dos tipos.
Uno son los registros que sirven para investigar la causa cuando se produce un fallo o una anomalía.
Se utilizan para investigar consultas como "Envié el formulario ayer, pero no llegó" o "Hubo errores solo durante un período de tiempo concreto".
El otro es un registro para verificar posteriormente las operaciones realizadas.
Es un registro que permite saber "quién cambió la configuración", "cuándo se publicó el contenido" y "qué operaciones se realizaron en el panel de administración".
Elemento de comparación | Investigación de incidencias y mejora | Auditoría y conservación de pruebas |
|---|---|---|
Usuarios principales | Desarrolladores y personal de operaciones | Personal de auditoría y seguridad |
Período de consulta habitual | De unos pocos días a varias semanas recientes | De unos meses a varios años |
Aspectos a tener en cuenta | Facilidad de búsqueda y cantidad de información | Que no falte información y que se conserve durante mucho tiempo |
Frecuencia de consulta | Revisión habitual en el día a día | Recuperación cuando sea necesario |
Estos dos tipos tienen períodos de conservación y formas de uso diferentes.
Si se intenta mantener todos los registros durante largos períodos con capacidad de búsqueda, los costos también aumentan considerablemente. Por el contrario, si solo se conservan los registros más recientes, las evidencias necesarias para auditorías o investigaciones de incidentes pueden perderse.
Separarlos desde el principio permite un diseño más razonable.
Convertir "se necesitan registros de auditoría" en requisitos
Con solo el término "registros de auditoría" no se puede determinar una estructura concreta.
Primero confirmamos el objetivo y, a partir de ahí, definimos qué registros se necesitan y cómo deben almacenarse.
"Los registros están disponibles" no es suficiente
Cuando los registros aparecen en el panel de administración del servicio en la nube, es fácil pensar que "los registros están capturados".
Sin embargo, el contenido y el período de conservación varían según el servicio.
- Los errores quedan registrados, pero no las acciones del administrador
- Se pueden consultar en el panel de administración, pero se eliminan después de un período determinado
- Para enviarlos a un sistema externo se requiere un plan superior
- Las operaciones propias de la aplicación deben registrarse por nuestra cuenta
Los registros operativos, como "quién cambió la información de un producto" o "qué datos de solicitud se procesaron", a veces no se pueden determinar solo con los servicios en la nube.
Si los requisitos de una licitación mencionan "registros de auditoría", conviene confirmar al menos los siguientes puntos.
Lista de verificación para la definición de requisitos
✅️ ¿Qué operaciones se deben registrar?
✅️ ¿Son operaciones de usuarios o de administradores?
✅️ ¿El objetivo es investigar fallos o cumplir con auditorías?
✅️ ¿Durante cuánto tiempo deben conservarse?
✅️ ¿Es necesario buscarlos con frecuencia?
✅️ ¿Quién puede consultar los registros?
✅️ ¿Podrían incluir datos personales?
Si se eligen servicios o planes sin aclarar estos puntos, la arquitectura puede acabar siendo más grande de lo necesario o, por el contrario, no conservar los registros que realmente se necesitan.
En los servicios web actuales, los registros también están distribuidos
En los servidores web tradicionales, bastaba con un enfoque relativamente sencillo: guardar los archivos de registro dentro del propio servidor.
Hoy en día es cada vez más común crear servicios web combinando varios servicios en la nube, como CDN, hosting, bases de datos, CMS sin cabeza y envío de correo electrónico.
En Liberogic utilizamos, según el proyecto, no solo AWS sino también Cloudflare, Vercel, Supabase, microCMS y Kuroco.
Como los registros también se guardan en cada servicio por separado, es necesario revisar el conjunto del sistema para entender qué queda registrado en total.
Primero, empecemos por aclarar el objetivo.
Cuando se menciona que se necesitan "registros de auditoría", puede parecer que hay que incorporar algún servicio especial.
Por supuesto, según los requisitos, puede ser necesario un servicio externo de gestión de logs o un mecanismo de almacenamiento a largo plazo. Sin embargo, tampoco conviene preparar desde el principio una arquitectura de gran envergadura.
Primero, hay que definir qué registros se necesitan, para qué fin y durante cuánto tiempo deben conservarse.
Una vez aclarado esto, lo realista es separar las partes que pueden cubrirse con las funciones estándar de las que requieren construir mecanismos adicionales.
En la próxima entrega, compararemos a grandes rasgos qué registros generan servicios que utilizamos con frecuencia, como AWS, Cloudflare, Vercel, Supabase y los CMS headless.
Eso es todo por ahora.
La columna vertebral del departamento técnico de Liberogic. Cuando escucha frases como "Ojalá existiera algo así, sería muy útil...", con su ingenio añade valor extra y lo implementa en un abrir y cerrar de ojos. Con una gran capacidad de comunicación y muchos seguidores entre nuestros clientes, es un verdadero tesoro para la empresa, además de un gran amante de los gatos.
Sho Otsuka
Director de CTO / Ingeniero jefe / Representante de Nekoana LLC / Aparenta ser más joven de lo que es