Entrevista de diseño de sistemas: Diseñar un servicio multi-inquilino de gestión de secretos

Enunciado y contexto aplicable

Diseña un servicio de gestión de secretos para una plataforma multi-inquilino (multi-tenant). Un secreto puede ser una credencial de base de datos, un token de API, una clave privada o un certificado. El sistema almacena 20 millones de nombres de secretos activos con un promedio de tres versiones retenidas. Los valores tienen un promedio de 2 KiB y no pueden exceder los 64 KiB. El tráfico pico es de 100 000 lecturas y 2000 escrituras de versiones por segundo. En la región de origen (home region) del secreto, las lecturas exitosas deben completarse por debajo de 50 milisegundos en el p99.

Cada región abarca tres zonas de disponibilidad. Una escritura confirmada por la región de origen debe sobrevivir a la pérdida de una zona. El objetivo de recuperación ante desastres ante la pérdida de toda la región es un RTO de 15 minutos y un RPO de un minuto. Estos volúmenes y objetivos son supuestos de entrevista, no límites publicados de un producto comercial de gestión de secretos. Si el negocio requiere cero pérdida de datos tras una falla regional, el candidato debe asumir explícitamente el costo de un consenso síncrono entre regiones u otro límite de durabilidad equivalente.

El modelo de amenazas incluye una instantánea (snapshot) de base de datos robada, copias de seguridad comprometidas, errores de autorización entre inquilinos, un operador con acceso al almacenamiento ordinario, registros accidentales en logs y el robo de un host del plano de datos (data plane). No pretende impedir que una carga de trabajo ya autorizada utilice un valor que obtuvo legítimamente. El diseño debe reducir los privilegios y el tiempo de vida de las credenciales de esa carga de trabajo, preservar la atribución y limitar el radio de impacto ante un compromiso.

El alcance incluye autenticación de cargas de trabajo, evaluación de políticas, secretos estáticos y dinámicos, cifrado, versiones inmutables, rotación por etapas, revocación, concesiones (leases), auditoría, replicación y recuperación. La construcción del proveedor de identidad de la organización, la base de datos que consume una credencial generada y un servicio de gestión de claves criptográficas de propósito general son dependencias externas. El material público para entrevistas de ingeniería de seguridad disponible en 2026 incluye la consigna específica de diseñar un servicio de gestión de secretos y lista un gestor de secretos para microservicios como un ejercicio de diseño de sistemas de seguridad. Esto respalda la representatividad actual del tema sin demostrar su frecuencia en ninguna empresa en particular.

Qué evalúa el entrevistador

La primera señal es un límite de protección preciso. Decir "cifrar la base de datos" deja la clave de descifrado junto al texto cifrado y no explica qué tipo de compromiso queda contenido. Una respuesta sólida separa una raíz protegida por hardware o KMS, claves de cifrado de claves (KEK) delimitadas por inquilino, claves de cifrado de datos (DEK) por versión y el almacenamiento ordinario de texto cifrado. También identifica dónde puede existir brevemente el texto plano.

La segunda señal es la autorización en cada solicitud. El aislamiento de inquilinos no puede depender de un prefijo de ruta proporcionado por el emisor. El servicio deriva el inquilino, la carga de trabajo, el entorno y los roles a partir de la identidad autenticada, evalúa una política versionada para la acción y el recurso exactos, e incluye esos hechos en un evento de auditoría. La autenticación, la autorización, el cifrado y la auditoría son controles distintos.

La tercera señal es el razonamiento sobre el ciclo de vida. Un nuevo valor, un cambio de clave de envoltura criptográfica y un cambio de credencial en una base de datos externa son tres operaciones diferentes. La rotación en un sistema externo no es una transacción atómica de base de datos única. Necesita etapas duraderas, reglas de solapamiento (overlap), idempotencia, pruebas, compensación y conciliación.

La cuarta señal es la semántica honesta de revocación. Denegar lecturas futuras no borra una contraseña estática ya copiada en un proceso. Una revocación de emergencia efectiva también deshabilita o rota la credencial en el sistema que la acepta. Una credencial dinámica puede ofrecer una expiración y revocación más sólidas porque el sistema de destino participa en la concesión (lease).

Finalmente, el candidato debe equilibrar latencia, seguridad y disponibilidad. Llamar a un HSM para cada una de las 100 000 lecturas por segundo suele ser el cuello de botella equivocado. Almacenar texto plano en una caché distribuida compartida es el remedio equivocado. La respuesta debe utilizar una jerarquía de claves, cachés de memoria protegida con un alcance delimitado, límites explícitos de políticas para datos obsoletos (stale policy) y modos de falla probados.

Preguntas para aclarar antes de responder

• ¿Qué tipos de secretos están dentro del alcance? Los valores estáticos opacos necesitan almacenamiento de versiones. Los usuarios de bases de datos y los certificados también pueden admitir emisión dinámica y revocación del lado del destino.
• ¿Quién lee los secretos? Se prefieren identidades de cargas de trabajo y sesiones de corta duración. La visualización por parte de humanos, si se permite, requiere una aprobación más estricta, autenticación escalonada (step-up authentication) y una política de auditoría independiente.
• ¿Qué promete la revocación? El servicio puede rechazar de inmediato nuevas lecturas. Invalidar un valor estático copiado requiere que el sistema downstream lo rote o lo deshabilite.
• ¿Qué consistencia requiere current? Este diseño hace que la promoción y la revocación sean linearizables por secreto en su región de origen. El emisor también puede solicitar explícitamente una versión inmutable.
• ¿Puede fallar una región con cero pérdida de datos? El RPO de recuperación ante desastres establecido es de un minuto. Un RPO de cero requiere confirmación sincrónica entre regiones y modifica el equilibrio entre latencia y disponibilidad.
• ¿Pueden las aplicaciones usar una caché local durante una interrupción? Solo una política explícita puede permitir una caché de agente cifrada y con límite de tiempo para secretos estáticos seleccionados. Esto debilita las garantías de revocación inmediata.
• ¿Qué tamaño tienen los valores y las versiones? La consigna limita los valores a 64 KiB y asume un promedio de tres versiones retenidas. Los documentos grandes corresponden a un diseño diferente de almacenamiento de objetos cifrado.
• ¿Qué debe contener el registro de auditoría? Entidad principal (principal), carga de trabajo, inquilino, identificador de recurso, acción, versión de la política, decisión, ID de solicitud, región y hora; nunca el valor en texto plano.
• ¿Quién puede administrar la raíz de confianza? Se requieren separación de funciones, acceso de emergencia (break-glass) controlado por quórum y simulacros de recuperación. Un administrador universal para el día a día anula el aislamiento de inquilinos.

Estructura de respuesta en 30 segundos

"Separaría un plano de control de políticas y creación de un plano de datos de lectura de baja latencia. Una carga de trabajo se autentica con una identidad de plataforma de corta duración; el servicio deriva su inquilino y evalúa una política versionada de mínimo privilegio para el secreto y la acción exactos. Cada versión inmutable del secreto se cifra con una clave de datos aleatoria utilizando cifrado autenticado. Esa clave de datos es envuelta por una clave de inquilino, mientras que un HSM o KMS protege la raíz que desenvuelve las claves de inquilino; el almacenamiento ordinario solo ve texto cifrado y claves envueltas. Un quórum transaccional regional añade atómicamente una versión y mueve el puntero current mediante compare-and-set. La rotación es un flujo de trabajo duradero de creación, instalación, prueba, promoción, solapamiento y retiro, dado que el destino externo no puede unirse a una sola transacción. Las credenciales dinámicas llevan concesiones (leases) que el emisor renueva o revoca. Almacenaría en caché el texto cifrado y solo por un breve período las claves desenvueltas dentro de la memoria protegida del servicio, nunca en una caché compartida de texto plano. La auditoría se envía a una canalización de solo anexión (append-only) protegida de forma independiente. Verificaría la denegación entre inquilinos, la promoción concurrente, la pérdida de claves, interrupciones del KMS, revocaciones bloqueadas, fugas en logs y la restauración regional completa".

Análisis detallado paso a paso

Paso 1: Convertir la consigna en invariantes y un límite de amenazas

Comienza con cinco invariantes:

1. A request can address only a tenant derived from authenticated identity.
2. Ordinary databases, queues, logs, traces, and backups never receive plaintext values or plaintext keys.
3. A published version is immutable; promotion only changes a version pointer.
4. Every allow and deny decision emits an audit event without the value.
5. Acknowledged regional writes survive one availability-zone failure.

Estos invariantes aún dejan un riesgo residual. Una carga de trabajo autorizada recibe texto plano y puede verse comprometida. Un proceso del plano de datos retiene brevemente material de claves desenvuelto y texto plano. Un administrador malicioso de la raíz de confianza puede exceder la política normal. Reduce esos riesgos con identidades de corta duración, políticas acotadas, aislamiento de procesos, volcados de memoria (core dumps) deshabilitados, memoria protegida, auditoría independiente, separación de funciones y alcances reducidos para las claves. No afirmes que el cifrado en reposo resuelve el compromiso en tiempo de ejecución.

Paso 2: Separar el plano de control del plano de datos de lectura

El plano de control gestiona inquilinos, políticas, metadatos de secretos, nuevas versiones, trabajos de rotación, aprobaciones y acciones de emergencia. Su tasa de escritura es más baja y prioriza la validación estricta y los flujos de trabajo auditables. El plano de datos autentica cargas de trabajo, evalúa políticas, descifra una versión permitida y la devuelve a través de TLS con autenticación mutua. Su ruta crítica (hot path) debe mantenerse reducida.

Cada inquilino tiene una región de origen para escrituras autoritativas de secretos y políticas. Un quórum transaccional de tres zonas en esa región confirma metadatos, texto cifrado, punteros de versión, concesiones (leases), registros de idempotencia y una bandeja de salida (outbox) de auditoría. Los nodos de lectura pueden escalar horizontalmente, pero las lecturas de current pasan a través del almacén fuertemente consistente de la región de origen o de una réplica con una barrera de lectura comprobada. Una réplica desactualizada no debe resucitar una versión revocada.

La identidad proviene del proveedor de identidades de la plataforma mediante mecanismos como certificados de carga de trabajo o tokens firmados de cuentas de servicio. El servicio de secretos valida el emisor, la audiencia, la expiración, la identidad de la carga de trabajo y el enlace de canal (channel binding), y luego asigna la identidad de confianza al inquilino y al rol. El cliente no puede anular ese inquilino mediante un encabezado.

Paso 3: Definir una API reducida y un modelo de datos inmutable

Una posible API es:

POST /v1/secrets/{path}/versions
  { value, idempotencyKey, expectedCurrentVersion? }
  -> { secretId, version, status: "PENDING" }

POST /v1/secrets/{path}/versions/{version}/promote
  { expectedCurrentVersion, idempotencyKey }
  -> { currentVersion }

GET /v1/secrets/{path}?version=current
  -> { value, version, expiresAt? }

POST /v1/dynamic/{role}/credentials
  { requestedTtl, idempotencyKey }
  -> { value, leaseId, expiresAt, renewable }

POST /v1/leases/{leaseId}/renew
POST /v1/leases/{leaseId}/revoke

La ruta es un nombre de recurso, no una prueba de autorización. El servidor la normaliza una vez, rechaza codificaciones ambiguas, deriva el inquilino a partir de la identidad y verifica la política específica para la acción.

Secret(secret_id, tenant_id, canonical_path, state,
       current_version, policy_ref, created_at)

SecretVersion(secret_id, version, status, ciphertext, nonce, auth_tag,
              wrapped_dek, tenant_kek_version, content_fingerprint_hmac,
              created_by, created_at)

Policy(policy_id, tenant_id, version, document, state, created_at)

Lease(lease_id, tenant_id, secret_id, principal_id, target_ref,
      status, expires_at, renewable_until, last_error)

Idempotency(tenant_id, principal_id, operation, key,
            request_fingerprint_hmac, result_ref, expires_at)

(tenant_id, canonical_path) y (secret_id, version) son únicos. Las filas de versiones nunca modifican su carga útil cifrada. La promoción utiliza una actualización condicional en current_version; dos administradores compitiendo por promover desde la versión 7 no pueden sobrescribirse silenciosamente entre sí. La bandeja de salida de auditoría se confirma con cada cambio de estado y luego se exporta a un almacenamiento controlado de forma independiente. Las huellas digitales (fingerprints) son HMAC con clave creados con una clave independiente por inquilino, no hashes sin procesar de credenciales de baja entropía que una instantánea robada podría probar fuera de línea.

Paso 4: Construir una jerarquía de cifrado de sobre (envelope encryption)

Genera una clave de cifrado de datos aleatoria para cada versión y cifra el valor con un modo de cifrado autenticado. Vincula tenant_id, secret_id, la versión y el identificador de algoritmo como datos autenticados adicionales (AAD), de modo que el texto cifrado no pueda trasladarse a otro inquilino o versión sin ser detectado. Almacena juntos el texto cifrado, el nonce, la etiqueta de autenticación y la clave de datos envuelta.

Cada inquilino tiene una o más claves de cifrado de claves versionadas. Una raíz protegida por un HSM o KMS en la nube desenvuelve esas claves de inquilino únicamente para nodos autorizados del plano de datos. La clave del inquilino envuelve la clave de datos de cada versión. Por lo tanto, una instantánea de almacenamiento ordinario carece del material necesario para descifrar los valores. Un host del plano de datos robado solo expone las claves de inquilino y las claves de datos presentes en ese proceso, por lo que la ubicación y el alcance de la caché deben limitar cuántos inquilinos puede atender un solo nodo.

HSM/KMS root
  -> unwrap tenant KEK version
      -> unwrap per-secret-version DEK
          -> AEAD-decrypt secret value with bound tenant/version metadata

Llamar al HSM para cada lectura convertiría al servicio raíz en un cuello de botella de latencia y rendimiento. Los nodos del plano de datos pueden almacenar en caché claves de inquilino o claves de datos desenvueltas durante un período corto y acotado en memoria protegida, particionada según el riesgo del inquilino. Borran las cachés ante eventos de políticas o claves, y al apagarse el proceso. Instancias compartidas de Redis, swap de disco, volcados por caídas (crash dumps), logs y trazas nunca reciben texto plano ni claves desenvueltas.

Cambiar la clave de envoltura del inquilino permite reenvolver las claves de datos sin descifrar cada valor almacenado. Cambiar la contraseña de una base de datos crea un nuevo valor de secreto y debe coordinarse con la base de datos. Estas operaciones tienen radios de impacto distintos y no deben compartir un único y ambiguo botón de "rotar".

Paso 5: Hacer que la autorización y el almacenamiento en caché reconozcan la revocación

Las políticas definen acciones como create-version, promote, read, issue-dynamic, renew, revoke y administer-policy. Pueden restringir inquilino, proyecto, entorno, ruta, carga de trabajo, zona de red, hora y TTL máximo. La denegación prevalece sobre la autorización. El acceso humano a texto plano está deshabilitado de forma predeterminada; una excepción aprobada registra el ticket, los aprobadores, el motivo y la concesión temporal de corta duración.

La evaluación de políticas se ejecuta localmente para optimizar la latencia, pero la política almacenada en caché tiene una versión y una antigüedad máxima. La revocación de una política o entidad principal se confirma primero, publica la invalidación y avanza una época de autorización del inquilino. Un nodo de lectura debe demostrar que tiene al menos la época requerida antes de responder. Si la invalidación no está disponible y la antigüedad máxima expira, las lecturas sensibles fallan de forma cerrada (fail closed) en lugar de confiar en la política indefinidamente.

El texto cifrado y los metadatos inmutables son seguros para almacenar ampliamente en caché. El texto plano no. Un agente del lado de la carga de trabajo puede retener un valor permitido en su propia memoria hasta un TTL declarado, reduciendo las lecturas repetidas. Si el producto permite una caché de disco cifrada para secretos seleccionados críticos para la disponibilidad, su clave vinculada al dispositivo, su expiración y su promesa de revocación más débil deben ser explícitas. Devolver un secreto antiguo simplemente porque el plano de control está caído no es una solución de contingencia universal.

Paso 6: Tratar la rotación de credenciales como un flujo de trabajo recuperable

La rotación de credenciales estáticas en una base de datos de destino sigue etapas duraderas:

CREATED_PENDING
  -> INSTALLED_AT_TARGET
  -> VERIFIED
  -> PROMOTED_CURRENT
  -> OLD_VERSION_IN_OVERLAP
  -> OLD_VERSION_REVOKED
  -> COMPLETE

Cada transición cuenta con una operación de conector idempotente y evidencia registrada. Crea la nueva credencial, instálala en el destino, pruébala mediante la ruta prevista, promueve la nueva versión, permite un solapamiento acotado cuando el consumidor lo requiera y luego deshabilita la credencial antigua en el destino. Un proceso de conciliación compara el estado del flujo de trabajo con el destino y se reanuda tras posibles caídas. Si la instalación tiene éxito pero la respuesta se pierde, una búsqueda debe descubrir ese hecho en lugar de crear otra credencial.

La rotación de emergencia puede omitir el solapamiento porque se sospecha que el valor anterior está comprometido. Esa decisión puede provocar una interrupción en la aplicación y debe requerir una ruta de autorización restringida al incidente. Denegar lecturas a la versión almacenada anterior por sí sola es insuficiente mientras el sistema de destino aún la acepte.

Para secretos dinámicos, un conector crea una credencial única de corta duración para una carga de trabajo y registra una concesión (lease). La renovación devuelve la nueva expiración real, que puede ser más corta que la solicitada. La expiración o la revocación manual indica al destino que invalide la credencial. Si el destino es inalcanzable, la concesión pasa a REVOCATION_PENDING; los reintentos, las alertas y un manual operativo siguen activos. El servicio no debe marcarla como revocada simplemente porque se envió un mensaje a una cola.

Paso 7: Presupuestar la capacidad y aislar a inquilinos de alto tráfico

Con tres versiones retenidas para 20 millones de nombres y 2 KiB por valor, los bytes sin procesar de valores cifrados son aproximadamente:

20,000,000 × 3 × 2 KiB = 122,880,000,000 bytes ≈ 114 GiB

Si los metadatos cifrados promedian otro 1 KiB por versión, eso añade aproximadamente 57 GiB. Tres réplicas regionales sitúan la estimación de almacenamiento inicial cerca de 513 GiB antes de índices, auditoría, concesiones (leases), idempotencia, copias de seguridad y crecimiento. Este cálculo proviene de la consigna y es una base de dimensionamiento, no una prueba de rendimiento del producto.

A 100 000 lecturas por segundo y un valor devuelto promedio de 2 KiB, solo la salida de texto plano se aproxima a 195 MiB por segundo, antes de TLS y la sobrecarga de respuestas. Distribuye a los inquilinos mediante sharding basado en un identificador de inquilino estable, y luego aísla a los inquilinos inusualmente activos o regulados en celdas dedicadas. Aplica presupuestos de concurrencia y tasa por inquilino para que una carga de trabajo comprometida no pueda consumir todos los recursos de descifrado o la capacidad de auditoría.

La latencia de lectura debe desglosarse en validación de identidad, evaluación de políticas, búsqueda de metadatos, desenvolvimiento/caché de claves, descifrado, puesta en cola de auditoría y tiempo de red. Los fallos de caché del HSM y la contrapresión (backpressure) de auditoría merecen presupuestos independientes. Nunca descartes auditorías silenciosamente para proteger el p99; utiliza un límite duradero local/outbox o rechaza solicitudes sensibles cuando no se pueda preservar el registro de auditoría requerido.

Paso 8: Diseñar la recuperación regional y la recuperación de la raíz por separado

Replica el estado cifrado y los registros de la bandeja de salida de auditoría de forma asíncrona a una región de recuperación ante desastres en espera (warm standby), con medición del retraso de replicación (replication lag). La promoción requiere una época de delimitación (fencing epoch) para que la antigua región de origen no pueda reanudar escrituras como un segundo primario. Con el RPO establecido de un minuto, los emisores deben comprender que las versiones confirmadas más recientes pueden requerir recreación tras la pérdida total de la región. Si eso es inaceptable, exige quórum entre regiones antes de confirmar una escritura.

La región de recuperación ante desastres también necesita acceso independiente al servicio de raíz de confianza, identidades de cargas de trabajo funcionales, estado de políticas y exportación de auditoría. Copiar solo texto cifrado no es un plan de recuperación. Prueba instantáneas cifradas y restauración a un punto en el tiempo, pero protege la configuración, las credenciales de arranque y el material de auto-desbloqueo (auto-unseal) por separado, ya que pueden ser sensibles incluso cuando la instantánea de datos está cifrada.

La recuperación de la raíz utiliza procedimientos de emergencia (break-glass) controlados por quórum, administradores independientes, evidencia inmutable y simulacros periódicos. Perder una clave de inquilino puede destruir el acceso a los valores de ese inquilino; filtrarla puede exponer cada valor envuelto por esa clave. Por lo tanto, el respaldo, la rotación, la ubicación y la destrucción de claves requieren pruebas explícitas de ciclo de vida.

Paso 9: Verificar propiedades de seguridad y comportamiento ante fallas

Diseña pruebas en torno a invariantes, no solo para la latencia del camino feliz (happy path):

• Genera intentos de acceso cruzado entre inquilinos mediante rutas directas, rutas codificadas, políticas con comodines e identidades obsoletas, y demuestra que cada uno es denegado.
• Provoca condiciones de carrera entre creación de versiones, promoción, revocación de políticas y lecturas; confirma que ningún nodo desactualizado sirva una versión recién denegada.
• Escanea bases de datos, colas, logs, trazas, volcados por caídas y copias de seguridad en busca de texto plano señuelo (canary) y material de claves desenvuelto.
• Inyecta latencia en KMS, desalojo de caché de claves, pérdida de quórum de almacenamiento, contrapresión de auditoría e interrupción total del plano de control.
• Interrumpe cada etapa de rotación antes y después de la acción en el destino; demuestra que la conciliación converge sin duplicar credenciales ni generar falsas finalizaciones.
• Haz que el destino de un secreto dinámico no esté disponible durante la expiración; demuestra que la concesión (lease) permanece visiblemente pendiente hasta que la invalidación en el destino tenga éxito.
• Restaura la región de recuperación ante desastres a partir de la replicación cifrada e instantáneas; verifica delimitación (fencing), identidad, políticas, claves, auditoría, RTO y el RPO medido.
• Realiza pruebas de carga con una distribución de inquilinos altamente asimétrica a 100 000 lecturas y 2000 escrituras por segundo mientras mides p99, precisión de denegaciones, tráfico al HSM, alcance de caché e integridad de auditoría.

Ejemplo de respuesta de alta calidad

"Comenzaría declarando que el servicio protege contra compromisos de almacenamiento, copias de seguridad, accesos entre inquilinos, logs y compromisos limitados de hosts, mientras que una carga de trabajo autorizada aún puede hacer un uso indebido del valor que recibe. Cada solicitud comienza con una identidad de carga de trabajo de corta duración. El servicio deriva el inquilino y la carga de trabajo a partir de esa identidad, y luego evalúa una política versionada para el recurso y la acción exactos; una ruta proporcionada por el emisor no puede seleccionar a otro inquilino.

Utilizaría versiones inmutables. Una solicitud de creación escribe una versión pendiente, y la promoción mueve condicionalmente el puntero current del secreto desde la versión anterior esperada. Un quórum de tres zonas en la región de origen confirma texto cifrado, metadatos, idempotencia y una bandeja de salida de auditoría en conjunto. Las lecturas de current utilizan una barrera de lectura para que una réplica desactualizada no pueda servir una versión revocada.

Para el cifrado, cada versión obtiene una clave de datos aleatoria y cifrado autenticado vinculado al inquilino, al secreto y a la versión. Una clave de inquilino envuelve esa clave de datos, y una raíz protegida por HSM o KMS desenvuelve las claves de inquilino solo en nodos autorizados del plano de datos. El almacenamiento ordinario y las copias de seguridad contienen texto cifrado y claves envueltas. Los nodos de lectura pueden almacenar brevemente en caché claves desenvueltas en memoria protegida particionada por inquilino; el texto plano nunca ingresa a cachés compartidas, logs, trazas, swap o volcados de memoria.

La rotación de credenciales es una máquina de estados: crear, instalar en el destino, verificar, promover, solapar, revocar la credencial antigua del destino y completar. Cada llamada al conector es idempotente y se concilia, porque una base de datos externa no puede unirse a la transacción de metadatos. Un compromiso de emergencia puede eliminar el solapamiento. Las credenciales dinámicas se emiten por carga de trabajo con una concesión (lease); la expiración solo se completa después de que el destino confirme la revocación; de lo contrario, el sistema mantiene un estado pendiente visible y genera alertas.

El plano de control gestiona políticas, versiones, aprobaciones y flujos de trabajo; celdas del plano de datos escaladas horizontalmente atienden las lecturas. El texto cifrado se puede almacenar ampliamente en caché, la política tiene una caché versionada acotada y el almacenamiento en caché de claves desenvueltas es breve y local. Ante la pérdida de una región, el estado cifrado se replica a una región en espera con un RPO de un minuto y una época de delimitación evita el split-brain. Si el requisito cambia a RPO cero, confirmaría sincrónicamente entre regiones y aceptaría una mayor latencia o menor disponibilidad de escritura.

Finalmente, probaría ataques entre inquilinos y con rutas codificadas, promoción y revocación concurrentes, fugas de valores señuelo en todas las superficies de observabilidad y respaldos, interrupciones de KMS y auditoría, caídas en cada paso de rotación, revocaciones de concesiones bloqueadas y una restauración completa de recuperación ante desastres. El diseño se considera aprobado únicamente cuando las decisiones de seguridad se mantienen correctas bajo estas fallas y el pico de 100 000 lecturas sigue cumpliendo con su presupuesto de latencia medido".

Errores comunes

• Usar una única clave de cifrado de base de datos junto a la base de datos → el compromiso de una instantánea puede incluir tanto el texto cifrado como su ruta de descifrado → separa la raíz de HSM/KMS, las claves de envoltura de inquilinos, las claves de datos por versión y el almacenamiento ordinario.
• Confiar en el inquilino o en la ruta de la solicitud → un cambio en el nombre del objeto se convierte en acceso entre inquilinos → deriva el inquilino a partir de la identidad verificada, canoniza una sola vez y autoriza la acción y el recurso exactos.
• Registrar cuerpos de solicitud o respuesta en logs para depuración → la infraestructura de observabilidad se convierte en un almacén de secretos en texto plano → utiliza identificadores, decisiones, versiones y pruebas de fuga con valores señuelo sin exponer valores reales.
• Llamar al HSM en cada lectura → la latencia y las cuotas de la raíz de confianza se convierten en el cuello de botella de la plataforma → utiliza cifrado de sobre y cachés de claves acotadas en memoria protegida con un radio de impacto explícito.
• Colocar valores descifrados en Redis → una optimización de latencia crea un amplio límite de compromiso en texto plano → almacena ampliamente en caché el texto cifrado y mantén el texto plano solo en la memoria delimitada del consumidor autorizado.
• Tratar la rotación como una sola actualización → la instalación en el destino puede tener éxito mientras los metadatos fallan, o viceversa → utiliza un flujo de trabajo duradero por etapas, operaciones de conector idempotentes, reglas de solapamiento y conciliación.
• Marcar una concesión (lease) como revocada tras publicar un mensaje → la credencial downstream aún puede funcionar → mantén un estado pendiente hasta que se confirme la invalidación en el destino y genera alertas si la revocación se bloquea.
• Prometer revocación inmediata de valores estáticos copiados → se pueden denegar lecturas futuras, pero las copias existentes siguen siendo utilizables → rota o deshabilita la credencial en el sistema que la acepta y prefiere credenciales dinámicas de corta duración.
• Fallar de forma abierta (fail open) ante políticas indefinidamente obsoletas → una entidad principal eliminada puede seguir leyendo valores confidenciales → versiona las cachés de políticas, invalídalas, impón una antigüedad máxima y falla de forma cerrada tras superar el límite.
• Copiar texto cifrado a una segunda región y llamarlo recuperación ante desastres → la identidad, las claves raíz, las políticas, la delimitación (fencing) y la auditoría pueden seguir sin estar disponibles → prueba el grafo de dependencias de recuperación completo y mide el RTO y RPO reales.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿En qué se diferencia un gestor de secretos de un KMS?

Un gestor de secretos almacena y versiona credenciales opacas, autoriza su recuperación, coordina la rotación, emite concesiones (leases) y audita el acceso. Un KMS gestiona claves criptográficas y realiza operaciones como envoltura o firma. Este diseño utiliza un KMS o HSM como su raíz de confianza; no expone esa raíz como un secreto recuperable ordinario.

Pregunta de seguimiento 2: ¿Se puede almacenar en caché un secreto en la aplicación?

Sí, únicamente bajo un contrato explícito. Un agente puede mantener un valor permitido en la memoria del proceso hasta un TTL acotado y actualizarlo antes de que expire. Eso reduce la dependencia de disponibilidad y el volumen de lecturas, pero extiende el período durante el cual la revocación de la política por sí sola no puede eliminar una copia existente. Las credenciales dinámicas o de alto riesgo deben usar concesiones más cortas y revocación en el destino en lugar de una caché sin límites.

Pregunta de seguimiento 3: ¿Qué sucede cuando el KMS o el HSM no están disponibles?

Los nodos solo pueden continuar operando con claves ya desenvueltas dentro de su tiempo de vida de caché aprobado. Nuevos inquilinos, fallos de caché y operaciones con claves raíz fallan de forma cerrada. Supervisa la cobertura de la caché, la tasa de errores de KMS y la ventana segura restante; descongestiona la carga antes de que todos los nodos expiren simultáneamente. Extender el tiempo de vida de las claves durante un incidente es una decisión de seguridad que requiere una política predefinida, no un bucle de reintento automático.

Pregunta de seguimiento 4: ¿Cómo se rota la clave del inquilino sin descifrar cada secreto?

Desenvuelve la clave de datos de cada versión con la clave de inquilino anterior y envuélvela con la nueva clave de inquilino, preferiblemente dentro del servicio de claves de confianza para que las claves de datos en texto plano no salgan de ese límite. Almacena tanto la versión de la clave del inquilino como la clave de datos envuelta, registra puntos de control de la migración y conserva la clave de inquilino anterior hasta que cada referencia y política de respaldo permita su retiro. El valor del secreto cifrado en sí no cambia.

Pregunta de seguimiento 5: ¿Cómo se evita que un operador privilegiado lea los secretos de todos los inquilinos?

Separa la administración de políticas, la administración de claves, la operación de la infraestructura y la revisión de auditoría. Deshabilita la recuperación rutinaria de texto plano por parte de humanos, exige concesiones de corta duración aprobadas por quórum para excepciones, ubica a los inquilinos regulados en celdas y alcances de claves independientes, y envía evidencia a un sistema de auditoría controlado de forma autónoma. Ningún rol de uso diario debe poder otorgarse acceso a sí mismo y descifrar valores sin dejar evidencia externa.

Pregunta de seguimiento 6: ¿Deben permanecer disponibles las lecturas cuando la región de origen está caída?

Solo si la región de recuperación ante desastres tiene una época autoritativa delimitada, datos cifrados y políticas suficientemente actualizados, acceso a su raíz de confianza y un RPO claramente aceptado. Atender solicitudes desde una réplica desactualizada arbitraria puede resucitar accesos revocados. Con el RPO establecido de un minuto, promueve la región en espera a través del proceso de conmutación por error probado; un RPO de cero requiere confirmaciones sincrónicas entre regiones previas al incidente.

Pregunta de seguimiento 7: ¿Por qué no almacenar secretos únicamente como variables de entorno?

Una variable de entorno es un mecanismo de entrega, no una gestión del ciclo de vida. Puede quedar expuesta mediante la inspección de procesos, volcados por caídas, diagnósticos, procesos secundarios o configuraciones de despliegue; además, carece de versiones centralizadas, rotación en el destino, concesiones (leases) y atribución por lectura. Si un agente de despliegue inyecta una variable de entorno, mantén su alcance y tiempo de vida reducidos y conserva el gestor de secretos como la fuente de verdad de políticas y ciclo de vida.