Planteamiento y alcance
Diseña un servicio de registros de auditoría multi-tenant que registre acciones relevantes para la seguridad y el cumplimiento normativo: inicios de sesión, cambios de permisos, acceso a datos y actualizaciones de configuración. Los investigadores necesitan un historial con capacidad de búsqueda y exportaciones verificables, mientras que el tráfico de la aplicación debe permanecer disponible durante una interrupción del servicio de registro.
Define la promesa de integridad con precisión. AWS CloudTrail describe un historial de eventos inmutable y con capacidad de búsqueda, mientras que OpenTelemetry proporciona un modelo de registros estructurado común; ninguno de los dos afirma que un evento fuera correcto antes de ser emitido. Tu diseño debe establecer qué puede demostrar el servicio.
Qué está evaluando el entrevistador
Están evaluando la ingesta durable, el almacenamiento append-only, la verificación de integridad, el aislamiento de inquilinos, la política de retención y las compensaciones operativas. Una buena respuesta separa la evidencia de auditoría de los registros de depuración ordinarios y explica cómo evitar perder o mutar eventos de seguridad durante una sobrecarga.
Preguntas para clarificar antes de responder
- ¿Qué acciones son obligatorias y cuál es la tasa esperada de eventos por segundo y el tamaño de los picos (bursts)?
- ¿El requisito es a prueba de manipulaciones evidentes (tamper-evident), resistente a manipulaciones (tamper-resistant) o comprobable externamente?
- ¿Debe fallar la solicitud de la aplicación si no se puede aceptar un evento de auditoría?
- ¿Cuánto tiempo debe retener los eventos cada inquilino y las retenciones legales (legal holds) anulan la eliminación?
- ¿Quién puede buscar, exportar o verificar los datos de otro inquilino?
- ¿Qué dimensiones de consulta y formatos de exportación necesitan los investigadores?
Estructura de respuesta en 30 segundos
“Expondría una API de ingesta regional y un búfer durable local para que las llamadas de la aplicación no dependan del índice de búsqueda. Cada evento incluye inquilino, actor, acción, objetivo, correlación de solicitud, hora del evento, hora de ingesta, versión del esquema y origen. Particionaría un registro append-only por inquilino y tiempo, lo replicaría y crearía una cadena de hashes o un manifiesto de segmentos firmado para que las ediciones posteriores sean detectables. Separaría los índices de búsqueda calientes (hot) del almacenamiento inmutable de retención. Aplicaría autorización delimitada por inquilino, retención y retenciones legales, y proporcionaría una exportación con metadatos de verificación. Monitorearía eventos aceptados frente a descartados, desfase (lag) de ingesta, comprobaciones de integridad y finalización de exportaciones”.
Análisis paso a paso en profundidad
Paso 1: Definir el contrato del evento
Exige un ID de evento, ID de inquilino, actor y contexto de autenticación, acción, objetivo, resultado, servicio de origen, ID de solicitud, hora del evento, hora de ingesta, versión del esquema y atributos seleccionados. Mantén los secretos y las cargas útiles innecesarias fuera del registro; en su lugar, registra una referencia o un resumen redactado.
Paso 2: Separar la aceptación de la indexación
Devuelve una respuesta exitosa solo después de que el evento llegue a un búfer durable o a un registro replicado. Luego, los consumidores construyen índices de búsqueda y exportaciones de forma asíncrona. Esto evita que un incidente en el clúster de búsqueda elimine evidencia silenciosamente o haga que cada solicitud de la aplicación espere a la indexación.
Paso 3: Hacer verificable la integridad
Canonicaliza cada evento, calcula su hash junto con el evento anterior o la raíz del segmento, y firma o ancla periódicamente el manifiesto en un dominio de confianza independiente. Almacena las brechas de secuencia y los resultados de verificación. Una cadena de hashes detecta cambios después de la ingesta; no demuestra que un servicio ascendente haya emitido un evento verídico.
append(event):
canonical = canonicalize(event)
record.hash = H(previous_hash || canonical)
durable_log.append(record)
return accepted(record.event_id, record.hash)Paso 4: Particionar y replicar
Particiona por inquilino y tiempo, con una clave de hash o de inquilino para distribuir a los inquilinos de alto tráfico (hot tenants). Replica entre dominios de falla antes de confirmar según el objetivo de durabilidad. Preserva el orden por inquilino o agregado, pero no prometas un orden global a menos que el costo esté justificado.
Paso 5: Construir búsqueda en caliente y retención en frío
Indexa los eventos recientes para las consultas de los investigadores y compacta los segmentos más antiguos en almacenamiento de objetos inmutable. Mantén el índice reconstruible a partir del registro. Los trabajos de retención deben respetar la política por inquilino y las retenciones legales; la eliminación debe dejar un registro de política auditable sin retener la carga útil protegida.
Paso 6: Aplicar controles de acceso y exportación
Autoriza cada consulta por inquilino, rol, propósito y rango de tiempo. Registra también las lecturas y exportaciones como eventos de auditoría. Genera un manifiesto firmado que contenga filtros, recuentos de eventos, hashes de segmentos y marcas de tiempo para que el destinatario pueda verificar la integridad y detectar alteraciones.
Paso 7: Definir el comportamiento ante interrupciones y sobrecarga
Elige un búfer local delimitado, contrapresión (backpressure) y una política clara para eventos obligatorios. Para la telemetría no crítica, el muestreo o la entrega retrasada pueden ser aceptables; para eventos de seguridad, rechaza la mutación de origen o desvíala a un canal de emergencia aislado. Nunca reportes un estado aceptado cuando el evento solo se guardó en memoria volátil.
Paso 8: Operar el límite de confianza
Mide el desfase de ingesta, la latencia de aceptación durable, el desfase de los consumidores, los eventos rechazados, las brechas de secuencia, los fallos de verificación de hash, la frescura del índice, la duración de las exportaciones y los errores en los trabajos de retención. Restringe el acceso a claves, rota las claves de firma, prueba la restauración y verificación, y alerta sobre la pista de auditoría de la propia pista de auditoría.
Respuesta de ejemplo de alta calidad
“Trataría el registro de auditoría como un sistema de evidencia independiente. Un servicio de negocio emite un evento canónico con ID de evento, inquilino, actor, contexto de autenticación, acción, objetivo, resultado, ID de solicitud y versión del esquema. El servicio confirma la recepción solo después de que el evento llega a un registro durable replicado. Los consumidores asíncronos construyen índices de búsqueda y exportaciones, de modo que un índice perdido pueda reconstruirse a partir de la evidencia.
El registro de evidencia se segmenta por inquilino y tiempo, vincula registros con hashes y periódicamente firma o ancla las cabeceras de los segmentos. Las consultas se autorizan por inquilino, rol, propósito y rango de tiempo; las consultas y exportaciones se auditan a su vez. Una exportación incluye sus filtros, recuento de eventos, hashes de segmentos y un manifiesto firmado. Durante una falla de ingesta, los eventos de seguridad entran en una ruta de emergencia durable y delimitada o bien se rechaza la acción original de alto riesgo; un búfer en memoria no se considera un evento aceptado. Las operaciones monitorean la latencia de ingesta, brechas de secuencia, fallos de hash, frescura del índice, eventos rechazados y errores de retención, y realizan simulacros regulares de reconstrucción de índices, rotación de claves y aislamiento de inquilinos con alta carga. Este servicio demuestra la integridad posterior a la recepción; la identidad, la autorización y las transacciones de negocio siguen siendo las encargadas de establecer si el evento ascendente era verídico”.
Errores comunes
- Confirmar un evento antes de que esté en almacenamiento durable, creando brechas silenciosas tras una caída del proceso.
- Tratar una tabla de base de datos mutable o un registro de depuración común como evidencia de auditoría.
- Hacer que el índice de búsqueda sea la única copia, impidiendo su reconstrucción en caso de corrupción.
- Olvidar que las consultas, exportaciones, cambios de retención y rotaciones de claves también requieren auditoría.
- Afirmar que una cadena de hashes demuestra que un evento ascendente era verídico.
Preguntas de seguimiento y respuestas
¿Qué sucede si se pierde todo el índice de búsqueda?
Se mantiene disponible la ingesta de evidencia, se reconstruye el índice a partir de los segmentos inmutables y se verifica el rango reconstruido con recuentos de eventos, secuencias y manifiestos firmados.
¿Debe continuar el tráfico de negocio durante una interrupción de la ingesta?
Se decide según la criticidad del evento. Las acciones de bajo riesgo pueden entrar en un búfer durable delimitado. Una acción de seguridad de alto riesgo que no se pueda registrar de manera confiable debe rechazarse o enrutarse a través de una ruta de emergencia aislada, nunca permitirse silenciosamente.
¿Cómo evitas que un inquilino de alto tráfico afecte a los demás?
Particionando por inquilino y tiempo, aplicando cuotas de ingesta, consulta y exportación, y aislando los recursos de los consumidores. Las pruebas de carga deben verificar los objetivos de nivel de servicio (SLO) de durabilidad y consulta para los inquilinos no afectados.
¿Cómo coexisten la eliminación por privacidad y la retención de auditoría?
Clasificando los campos según la retención legal y la política del inquilino, prefiriendo resúmenes (digests) redactados o referencias controladas, aplicando la eliminación de manera consistente en índices, segmentos de objetos y copias de seguridad, y conservando un registro verificable de la acción de política ejecutada.