La separación de obligaciones es el concepto de asegurar que un individuo no tenga todos los permisos necesarios para poder completar una acción maliciosa. En Cloud Key Management Service, esto podría ser una acción como usar una clave para acceder y desencriptar datos a los que el usuario no debería tener acceso normalmente.
La separación de obligaciones es un control empresarial que se suele usar en organizaciones más grandes, y cuyo propósito es ayudar a evitar incidentes y errores de seguridad o privacidad. Se considera una recomendación.
Para obtener más orientación, consulte nuestra documentación sobre cómo usar administración de identidades y accesos de forma segura.
Configura Cloud KMS en un proyecto aparte
Cloud KMS puede ejecutarse en un proyecto existente, por ejemplo your-project
, y esto puede ser razonable si los datos que se encriptan con claves en Cloud KMS se almacenan en el mismo proyecto.
Sin embargo, cualquier usuario con acceso owner
en ese proyecto también puede administrar las claves (y realizar operaciones criptográficas con ellas) en Cloud KMS en ese proyecto. Esto se debe a que las claves pertenecen al proyecto, del cual el usuario es un owner
.
En su lugar, para permitir una separación de obligaciones, puedes ejecutar Cloud KMS en su propio proyecto, por ejemplo, your-key-project
. Posteriormente, dependiendo de lo estricto de tus requisitos de separación, podrías realizar una de las siguientes opciones:
- (recomendado) Crea
your-key-project
sin unowner
a nivel de proyecto y designa un administrador de la organización otorgado a nivel de la organización. A diferencia deowner
, los administradores de la organización no pueden administrar ni usar claves de forma directa. Están restringidos a la configuración de políticas de IAM, que restringen quién puede administrar y usar las claves. Si usas un nodo a nivel de la organización, puedes restringir más permisos para los proyectos de tu organización. - (no recomendado) Si debes seguir usando la función
owner
, asegúrate de que se otorgue a una principal diferente enyour-key-project
que la principal, que es laowner
deyour-project
.owner
puede seguir usando claves, pero solo en un único proyecto.