Planteamiento y alcance
Diseñe un monitor de registros de Certificate Transparency (CT) multiinquilino. Un usuario envía uno o más dominios; el servicio consulta continuamente registros públicos de CT, genera alertas sobre certificados o precertificados coincidentes y demuestra que los datos del registro no fueron reescritos silenciosamente. También debe detectar registros desactualizados, fallas en las pruebas y violaciones del maximum merge delay.
Esta es una sólida pregunta de diseño de sistemas para roles de seguridad de plataformas e infraestructura de certificados. La parte importante es una canalización de datos verificable y límites de falla explícitos, no una lista de servicios de moda.
Qué evalúa el entrevistador
- Si distingue un monitor de la política del navegador y de la emisión de las CA.
- Si comprende los signed tree heads (STH), las pruebas de inclusión de Merkle, las pruebas de consistencia y la semántica de solo adición (append-only).
- Si el maximum merge delay (MMD) se convierte en una condición medible de programación y alerta.
- Si cubre múltiples registros, lecturas duplicadas, vistas divididas (split views), interrupciones del servicio y aislamiento de inquilinos.
- Si las suposiciones de almacenamiento, idempotencia, control de ruido en las alertas y capacidad son concretas.
Aclaraciones que se deben hacer primero
Confirme cuatro límites:
- ¿La coincidencia debe cubrir un nombre exacto, un dominio registrable, comodines o nombres en SAN?
- ¿Se requiere detección casi en tiempo real o es aceptable una latencia a nivel de minutos? ¿Qué canales y escalamiento de guardia se necesitan?
- ¿Debe el monitor inspeccionar cada registro público o solo un conjunto confiable seleccionado? ¿Se deben retener los certificados y las pruebas sin procesar?
- ¿Cuáles son la cantidad de inquilinos, el período de retención, los requisitos de privacidad y el presupuesto?
Si no se proporciona respuesta, asuma 100 registros sondeados una vez por minuto, un objetivo de descubrimiento de extremo a extremo de cinco minutos y evidencia de auditoría retenida.
Estructura de respuesta de treinta segundos
Dividiría el sistema en recolección de registros, verificación criptográfica, coincidencia de certificados, alertas y almacenamiento de auditoría. Cada registro mantiene un tamaño de árbol verificado y el STH más reciente. Los recolectores verifican la firma del STH, obtienen entradas de forma incremental y usan pruebas de inclusión o consistencia para comprobar el comportamiento de solo adición. La capa de coincidencia normaliza SAN, comodines y dominios registrables; la capa de alertas deduplica y escala según la política del inquilino; la capa de auditoría almacena entradas sin procesar, STH, pruebas y hashes. Las métricas clave son la frescura del STH, el retraso del registro, la tasa de fallas en las pruebas, la latencia de las alertas y la tasa de falsos positivos. Una vista dividida o una violación de MMD congela el estado de confianza de ese registro y lo escala.
Análisis detallado paso a paso
1. Recolección y máquina de estados
Almacene la identidad de cada registro, la clave pública, el tamaño de árbol de confianza, el último STH verificado, la última hora de sondeo y el estado. Un programador asigna trabajo según el estado: los registros normales usan lecturas incrementales, las fallas transitorias usan retroceso exponencial y las fallas repetidas entran en cuarentena. Utilice la identidad del registro más el tamaño del árbol objetivo como clave de tarea para que los reintentos sean idempotentes.
2. Verificación de STH y Merkle
Primero verifique la firma y la marca de tiempo del STH con la clave pública del registro, luego exija un tamaño de árbol monótonamente no decreciente. Una sincronización inicial puede establecer una instantánea completa; las sincronizaciones posteriores usan una prueba de consistencia para demostrar que el nuevo árbol incluye al árbol anterior. Para cada entrada coincidente, use una prueba de inclusión para demostrar que pertenece a ese árbol. Una prueba fallida, una reversión o una firma incorrecta no deben sobrescribir el estado anterior; retenga la evidencia y marque el registro como sospechoso.
3. Lecturas incrementales e integridad
Solicite el rango posterior al último tamaño de árbol confirmado y escriba certificados sin procesar, precertificados, posiciones en el registro y horas de recepción. Deduplique por identidad de entrada sin descartar el hecho de que un certificado apareció en varios registros. Si no llega ningún STH nuevo verificable dentro del MMD, registre el retraso del registro y genere una alerta de plataforma. “Ningún certificado coincidente” no debe inferirse de “no se observaron nuevas entradas”.
4. Coincidencia de certificados y alertas
Analice sintácticamente SAN, comodines, emisor, notBefore, notAfter y huellas digitales de certificados. Prefiera reglas de nombres explícitos y dominios registrables sobre la coincidencia de subcadenas. Una alerta debe incluir inquilino, nombre, registro, huella digital, hora de primera observación y enlaces a la evidencia. Deduplique la misma huella digital dentro de una ventana corta; un nuevo emisor, una validez inusualmente corta o un dominio de producción pueden aumentar la severidad.
5. Almacenamiento, tenencia y recuperación
Mantenga el estado activo (hot) en un almacén relacional o de clave-valor; coloque las entradas y pruebas sin procesar en almacenamiento de objetos indexado por registro y tamaño de árbol. Escriba eventos en un flujo de auditoría inmutable para su reproducción. Las consultas de los inquilinos devuelven solo nombres autorizados. Aplique límites de tasa por registro y un límite de concurrencia global para que el monitor no sobrecargue los registros públicos. Si se pierde el estado local, recupérese a partir del último STH de confianza y póngase al día con pruebas de consistencia en lugar de confiar en un cursor no verificado.
6. Observabilidad y manejo de fallas
Mida la antigüedad del STH, el retraso del MMD, el tamaño de árbol confirmado, el rendimiento de extracción, las fallas en las pruebas, la disponibilidad del registro, la tasa de coincidencias, la latencia de las alertas y los duplicados. Durante una interrupción del servicio, retenga el último estado de confianza y reintente. Ante una vista dividida o una falla de consistencia, deje de usar las coincidencias de ese registro, use otros registros y cree un evento de seguridad. Si fallan las notificaciones, persista los eventos en una cola duradera y entréguelos por ID de evento después de la recuperación.
Respuesta de ejemplo de alta calidad
Definiría primero el progreso confiable: el cursor de un registro avanza solo después de que un STH correctamente firmado y de tamaño monótono supera una prueba de consistencia. El recolector almacena ese cursor y el rango solicitado con un token de reintento. La primera ejecución establece una línea base; las ejecuciones posteriores leen por rango de tamaño de árbol. Cada entrada retiene su huella digital, SAN, posición en el registro, respuesta sin procesar y prueba de verificación.
El comparador normaliza los SAN antes de compararlos con las reglas del inquilino para nombres exactos, dominios registrables y comodines explícitos. Un evento identificado por inquilino, huella digital y registro entra en una cola; los procesos de notificación deduplican, escalan y registran la entrega. El almacenamiento de auditoría retiene el STH, la prueba, el hash de la entrada y la versión del verificador para que los ingenieros de seguridad puedan reproducir la decisión de forma independiente.
Trato las anomalías del registro como fallas de confianza en los datos: una firma incorrecta, una reversión, una prueba de consistencia fallida o un tiempo de espera excedido de MMD crean un evento de plataforma de alta prioridad. Ese registro se pone en cuarentena y se preserva su antiguo estado de confianza. La fragmentación por registro, la limitación de tasa, las lecturas por lotes y el almacenamiento de objetos controlan los costos; las consultas autorizadas y las cuotas de inquilinos aplican el aislamiento. Aceptaría el diseño utilizando la frescura del STH, las fallas en las pruebas, la latencia de descubrimiento, la tasa de falsos positivos en las alertas y la tasa de éxito de reproducción.
Errores comunes
- Sondear un solo registro e ignorar que los certificados pueden aparecer en varios registros.
- Leer el texto del certificado sin validar las firmas STH y las pruebas de Merkle.
- Avanzar un cursor porque la última solicitud tuvo éxito, a pesar de que los datos no se verificaron.
- Tratar el MMD como validez del certificado, o no tener ninguna alerta de frescura del registro.
- Hacer coincidir dominios con búsqueda de subcadenas, lo que genera falsos positivos para nombres similares y SAN no relacionados.
- Deduplicar globalmente una huella digital y perder sus ubicaciones en los diferentes registros.
- Continuar emitiendo conclusiones de baja confianza de “no encontrado” mientras un registro es anómalo.
- Guardar solo las alertas finales y ninguna entrada sin procesar, STH o pruebas, haciendo imposibles las auditorías.
Preguntas de seguimiento y respuestas
¿Qué pasa si un registro devuelve un árbol más pequeño?
No avance el cursor. Conserve ambos STH y la respuesta, ponga en cuarentena el registro y genere una alerta de consistencia. Reanude solo después de una revisión humana o de una nueva línea base de confianza establecida.
¿Cómo reduce el costo del sondeo casi en tiempo real?
Fragmente por registro, procese nuevos rangos por lotes, ajuste la frecuencia de sondeo dinámicamente y coloque la evidencia fría en almacenamiento de objetos. No sacrifique la verificación para cumplir con un objetivo de latencia.
¿Cómo verifica la propiedad del dominio?
Exija autorización por DNS, HTTP u organizacional cuando se cree un monitor. Solo un principal autorizado puede cambiar las reglas de coincidencia, y cada cambio es auditado.
¿En qué se diferencia un monitor de la política de CT del navegador?
Un monitor descubre y prueba entradas en registros públicos. La política del navegador decide si un certificado cumple con los requisitos de conexión. Su manejo de fallas y límites de confianza son diferentes.
¿Cómo lo probaría?
Use un registro controlable o respuestas grabadas para inyectar firmas incorrectas, pruebas no válidas, reversiones, tiempos de espera de MMD, entradas duplicadas y reintentos de notificación. Verifique que los cursores nunca avancen incorrectamente, que los eventos sigan siendo idempotentes y que las auditorías se reproduzcan con éxito.