Su base de datos está cifrada. El vendedor habla de “KMS integrado”. Luego ocurrió un incidente: ¿quién descifró la copia de seguridad de prueba a las 2 a. m.? Nadie lo sabe: los registros KMS no se exportan, el acceso del administrador del host no está correlacionado y el contrato solo dice "cifrado habilitado".
Un Servicio de administración de claves no es otra opción técnica. Aquí es donde se produce la separación comprobable entre quien almacena los datos y quien puede leerlos. Bien diseñado, produce evidencia. Mal diseñado, agrega una capa de jerga sin cambiar el modelo de confianza.
Arquitectura: donde viven las claves y los datos
El principio es simple: los datos cifrados permanecen en el disco o en el objeto; las llaves maestras se encuentran en otro lugar, en un departamento exclusivo con estrictas políticas de acceso.
En la práctica, tres patrones son comunes entre los anfitriones europeos:
KMS nativo de la nube. Una clave por proyecto, región o recurso. Posibilidad de rotación automática. Las llamadas Decrypt se registran, si tiene acceso a los registros.
KMS externo o HSM cliente. Traes la llave; el host solo almacena referencias (cifrado de sobre). Control reforzado, mayor complejidad en la disponibilidad.
KMS compartido sin aislamiento de IAM. Varios clientes comparten una instancia; las claves están lógicamente separadas pero los administradores de la plataforma siguen siendo poderosos. Debe documentarse explícitamente.
| Elemento | Pregunta para hacer | Señal saludable |
|---|---|---|
| Alcance clave | ¿Una clave por entorno? | Producción / puesta en escena / respaldo separadas |
| Rotación | ¿Automático o manual? | Política fechada + prueba post-rotación |
| Registros KMS | ¿Exportable a SIEM? | Retención ≥ duración de la auditoría |
| Rotura de cristal | ¿Procedimiento de emergencia? | Escrito, probado, trazado |
Separar claves y datos es inútil si la misma cuenta de administrador puede afectar a ambos.
IAM y separación de poderes
KMS rara vez falla en el algoritmo. Falla en quién puede llamar a qué API.
Comprueba que nadie en el anfitrión –o en tu casa– acumula sin control:
- creación/eliminación de claves;
- descifrado de datos de producción;
- eliminación de registros de uso de claves.
El privilegio mínimo se aplica tanto a KMS como a servidores. Idealmente: dos personas para operaciones destructivas, alertas sobre "Decrypt" masivo, correlación con tickets de incidentes.
Para una auditoría ISO o un cuestionario de cliente, muestre un extracto de registro anónimo que demuestre que un acceso clave corresponde a un cambio documentado, no a una promesa verbal.
Errores frecuentes del proyecto
Una clave para todo. La producción, las copias de seguridad y los análisis comparten la misma clave maestra. Una filtración o revocación lo paraliza todo.
Rotación sin prueba de restauración. La llave gira; las copias de seguridad antiguas se vuelven ilegibles debido a la falta de documentación de la versión.
KMS en una región, datos en otra. La latencia, el cumplimiento y la disponibilidad divergen. Las copias entre regiones a veces contienen claves replicadas sin que el DPO lo sepa.
Dependencia total del KMS host de salida. Sin exportación clave o período de transición, la reversibilidad se convierte en una palanca unilateral.
Cada error se corrige mediante un mapa: qué recurso utiliza qué clave, quién puede revocarla, cuánto tiempo se guardan los registros.
La cumbre: el KMS no sustituye al contrato
Esto es lo que omiten las diapositivas sobre “seguridad en la nube”.
El pináculo del análisis: exigir prueba de separación, no un acrónimo. En una reunión de crisis, necesita saber quién puede cortar el acceso a las llaves en una hora y si esa persona está en su casa o en la de ellos.
Decide y avanza sin puntos ciegos
Enumere los recursos cifrados (bases, depósitos, volúmenes, copias de seguridad). Para cada uno, tenga en cuenta el ID de clave, la región KMS, el propietario de IAM y la frecuencia de rotación.
Pregunte a dos hosts preseleccionados: exportación de registros KMS durante 30 días, política de rotación, escenario de revocación. Haga una referencia cruzada con nuestro comparador y la guía Cifrado en reposo para alinear claves y datos.
Pruebe una rotación en la puesta en escena y luego una restauración de archivos fechados. Sin esta prueba, la política del KMS sigue siendo teórica.
Preguntas frecuentes
¿Qué es un KMS en un contexto de hosting?
Un Servicio de Gestión de Claves centraliza la creación, almacenamiento, rotación y auditoría del uso de claves de cifrado. Separa lógicamente las claves de los datos cifrados, siempre que los derechos de acceso estén adecuadamente aislados.
¿KMS administrado por el host o KMS externo?
El KMS del host simplifica la integración pero a menudo comparte el mismo alcance operativo. Un KMS externo (HSM, nube soberana, local) refuerza la independencia si controlas la disponibilidad y la latencia.
¿Cómo puedo comprobar que una clave no ha sido mal utilizada?
A través de registros de llamadas API (Decrypt, GenerateDataKey), correlacionados con identidades de IAM, con suficiente retención y acceso de lectura reservado para su equipo de seguridad o el auditor.
¿Qué sucede si el KMS no está disponible?
Los servicios que dependen de él pueden negarse a iniciar o leer datos. Esta es la compensación del control: alta disponibilidad de documentos, claves de respaldo y el procedimiento de rotura de cristales.
Un KMS solo vale lo que sus registros y derechos pueden probar, no lo que promete la hoja del producto.