Cifrado y llaves con Cloud KMS

En Cloud KMS los recursos se ordenan en tres niveles: el anillo de claves (key ring), que agrupa llaves y fija una ubicación; la llave (key), que tiene un propósito, por ejemplo cifrar y descifrar o firmar; y la versión (key version), que es el material criptográfico concreto. Dos propiedades se deciden al crear y no se pueden cambiar: la ubicación del anillo y el nivel de protección de la llave (software, módulo de seguridad de hardware o llave externa). Y un anillo, una vez creado, no se puede borrar.

Las llaves simétricas tienen una versión primaria, la que se usa por defecto para cifrar. Rotar una llave significa crear una versión nueva y hacerla primaria. Lo que ya se cifró no se toca: sigue cifrado con la versión con la que se escribió.

Rotar con regularidad limita cuánto dato queda bajo una sola versión y acota el daño si una versión se compromete. Cloud KMS puede rotar de forma automática una llave simétrica según un período de rotación; una llave asimétrica, como la de firma, no admite esa rotación automática y se gestiona de otra manera.

Abre el laboratorio. En llaves.txt está la lista de llaves del proyecto de claves, con su propósito, su nivel de protección y su rotación. Busca la llave de cifrado simétrico que protege la base de datos de logística y que no tiene rotación programada.

Una versión de llave pasa por estados. ENABLED está lista para usarse. DISABLED no puede usarse, pero el material sigue guardado y se puede volver a habilitar. DESTROY_SCHEDULED tampoco puede usarse y está a la espera: por defecto la destrucción llega a los 30 días, un plazo que se fija al crear la llave (entre 24 horas y 120 días) y que no se puede cambiar después. Mientras no llegue la fecha, se puede restaurar. Al final, DESTROYED: el material desaparece, y lo cifrado con esa versión no se recupera nunca, salvo una reimportación en llaves importadas.

Esto importa porque Cloud Storage, con llaves del cliente, no puede descifrar un objeto si la versión que lo cifró no está habilitada, y seguirás pagando por almacenar datos que ya nadie puede leer. En versiones.txt verás qué versiones están programadas; en objetos-por-version.txt, qué buckets guardan objetos cifrados con cada versión.

Lo útil de una destrucción programada es que deja una ventana para rectificar. Una revisión no solo dice que hay una versión programada: dice cuánto tiempo queda para decidir. La fecha de la revisión está en el encargo y la fecha de destrucción en la lista de versiones.

En Cloud KMS los permisos de administrar una llave (crear, deshabilitar, programar su destrucción) y los de usarla (cifrar y descifrar) son roles distintos: roles/cloudkms.admin para lo primero y roles/cloudkms.cryptoKeyEncrypterDecrypter para lo segundo. Separarlos es una buena práctica: quien puede destruir una llave no debería poder además leer los datos que protege. Los agentes de servicio, como el de Cloud Storage, reciben el segundo rol para que el servicio cifre y descifre por ti.

En la política del anillo anillo-calidad hay una persona que tiene los dos roles.

En AWS el equivalente son las llaves de AWS KMS con su política de llave y un período de espera para la eliminación (de 7 a 30 días); en Azure, las llaves de Key Vault con el borrado suave y la protección contra purga. Los tres comparten la lección: la eliminación de una llave debe tener una ventana y alguien que la vigile.