Quién tiene la llave, el proveedor o tú

En AWS KMS conviven tres clases de claves. Las propiedad de AWS las usa el servicio por dentro y no aparecen en tu cuenta. Las administradas por AWS sí aparecen, pero las gestiona el proveedor: rotan solas cada año, no puedes activar ni desactivar esa rotación y tampoco puedes borrarlas. Las claves del cliente son tuyas: tú escribes su política, decides si rotan y cada cuánto, y puedes programar su borrado. Entre más control, más responsabilidad.

La pregunta de auditoría no es cuál es mejor, sino cuál exige la política de la empresa para ese dato.

En Azure, un servicio como un almacenamiento o una base de datos cifra por defecto con una clave que administra Microsoft. Si la empresa necesita más control, usa una clave suya guardada en Key Vault: ella decide su rotación y puede revocar el acceso del servicio a la clave. Ese control tiene un precio: si la clave se desactiva o se purga, el servicio no puede leer los datos. Por eso, cuando un servicio como Storage usa una clave del cliente, el vault debe tener la eliminación suave y la protección contra purga activadas.

Una clave propia protege más y, a la vez, convierte un descuido de administración en una pérdida de acceso a los datos.

Abre el laboratorio. La política de datos de Quebrada Alta exige, para lo Restringido, una clave del cliente y no acepta la administrada por el proveedor. Compara en el inventario la clasificación de cada recurso de AWS con la clave que lo cifra: el recurso que incumple es el que lleva una clasificación y una clase de clave que no encajan.

La misma regla vale en la otra nube. Esta vez el desajuste no está en AWS: busca en las filas de Azure el recurso cuyo dato es Restringido y cuya clave de cifrado en reposo la administra Microsoft. Anota el nombre del recurso tal como aparece, porque es el que irá al informe.