En Cloud KMS, los recursos se organizan en una jerarquía. Esta jerarquía te ayuda a gestionar y conceder acceso a los recursos en varios niveles de granularidad. Las claves se encuentran en conjuntos de claves, y los conjuntos de claves se encuentran en un proyecto. Las conexiones EKM también se encuentran en un proyecto. Los proyectos se pueden organizar en carpetas u organizaciones.
En este tema se proporcionan más detalles sobre la jerarquía de recursos de Cloud KMS. Para obtener más información sobre los Google Cloud recursos en general, consulta Jerarquía de recursos.
Jerarquía de recursos
El ámbito de un rol de gestión de identidades y accesos cambia en función del nivel de la jerarquía de recursos en el que se concede el rol. En esta tabla se muestran las funciones efectivas que concede el rol Encargado de encriptar CryptoKey de Cloud KMS (roles/cloudkms.cryptoKeyEncrypter
) en los distintos niveles de la jerarquía.
Puedes gestionar el acceso a las claves o a los conjuntos de claves, pero no a las versiones de claves concretas.
Jerarquía de recursos | Competencia |
---|---|
Organización | Cifrar con todas las claves de todos los proyectos de la organización |
Carpeta | Cifrar con todas las claves de todos los proyectos de la carpeta |
Proyecto | Cifrar con todas las claves del proyecto |
Conjunto de claves | Encriptar con todas las claves del llavero de claves |
Clave | Encriptar usando solo esa clave |
Principios de seguridad
IAM ayuda a aplicar los principios de seguridad interrelacionados de separación de obligaciones y mínimos accesos:
Cuando aplicas el principio de separación de funciones, ningún miembro tiene todo el acceso necesario para completar una función empresarial esencial. Por ejemplo, un empleado de un banco solo puede retirar fondos de una cuenta cuando el titular de la cuenta está presente físicamente e inicia la transacción.
Cuando aplicas el principio de mínimos accesos, un miembro solo tiene el nivel mínimo de acceso necesario para completar las funciones empresariales específicas de ese miembro. Por ejemplo, un empleado de un banco no tiene automáticamente la capacidad de aprobar un préstamo a un cliente.
Funciones predefinidas
IAM proporciona roles predefinidos que conceden acceso a cada tipo de recursos de Google Cloud . Si ningún rol predefinido se ajusta a tus necesidades, puedes crear un rol personalizado.
IAM ofrece los siguientes roles predefinidos para Cloud KMS:
Role | Permissions |
---|---|
Cloud KMS Admin( Provides access to Cloud KMS resources, except for access to restricted resource types and cryptographic operations. Lowest-level resources where you can grant this role:
|
|
Cloud KMS Autokey Admin( Enables management of AutokeyConfig. |
|
Cloud KMS Autokey User( Grants ability to use KeyHandle resources. |
|
Cloud KMS CryptoKey Decrypter( Provides ability to use Cloud KMS resources for decrypt operations only. Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Decrypter Via Delegation( Enables Decrypt operations via other Google Cloud services Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Encrypter( Provides ability to use Cloud KMS resources for encrypt operations only. Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Encrypter/Decrypter( Provides ability to use Cloud KMS resources for encrypt and decrypt operations only. Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Encrypter/Decrypter Via Delegation( Enables Encrypt and Decrypt operations via other Google Cloud services Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Encrypter Via Delegation( Enables Encrypt operations via other Google Cloud services Lowest-level resources where you can grant this role:
|
|
Cloud KMS Crypto Operator( Enables all Crypto Operations. Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Decapsulator Beta( Enables Decapsulate and GetPublicKey operations |
|
Cloud KMS EkmConnections Admin( Enables management of EkmConnections. |
|
Cloud KMS Expert Raw AES-CBC Key Manager( Enables raw AES-CBC keys management. Lowest-level resources where you can grant this role:
|
|
Cloud KMS Expert Raw AES-CTR Key Manager( Enables raw AES-CTR keys management. Lowest-level resources where you can grant this role:
|
|
Cloud KMS Expert Raw PKCS#1 Key Manager( Enables raw PKCS#1 keys management. Lowest-level resources where you can grant this role:
|
|
Cloud KMS Importer( Enables ImportCryptoKeyVersion, CreateImportJob, ListImportJobs, and GetImportJob operations |
|
Key Access Justifications Enrollment Viewer Beta( Grant ability to view Key Access Justification enrollment configs of a project. |
|
Key Access Justifications Policy Config Admin Beta( Grant ability to manage Key Access Justifications Policy at parent resource level. |
|
Cloud KMS Organization Service Agent( Gives Cloud KMS organization-level service account access to managed resources. |
|
Cloud KMS Protected Resources Viewer( Enables viewing protected resources. |
|
Cloud KMS CryptoKey Public Key Viewer( Enables GetPublicKey operations Lowest-level resources where you can grant this role:
|
|
Cloud KMS Service Agent( Gives Cloud KMS service account access to managed resources. |
|
Cloud KMS CryptoKey Signer( Enables Sign operations Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Signer/Verifier( Enables Sign, Verify, and GetPublicKey operations Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Verifier( Enables Verify and GetPublicKey operations Lowest-level resources where you can grant this role:
|
|
Cloud KMS Viewer( Enables Get and List operations. Lowest-level resources where you can grant this role:
|
|
Cloud KMS KACLS Service Agent( Grants Cloud KMS KACLS Service Agent access to KMS resource permissions to perform DEK encryption/decryption. |
|
Roles personalizados
Además de los roles predefinidos, puedes crear roles personalizados. Los roles personalizados te permiten aplicar el principio de mínimos accesos, ya que puedes conceder a un rol los permisos mínimos necesarios para llevar a cabo una tarea determinada.
Un rol personalizado incluye uno o varios de los permisos que se indican en la referencia de gestión de identidades y accesos.
Los permisos relacionados con la API Cloud Key Management Service empiezan por la cadena cloudkms
.
Para obtener más información, consulta Niveles de compatibilidad de los permisos de roles personalizados.
Para obtener información sobre los permisos necesarios para invocar un método específico de la API Cloud Key Management Service, consulta la referencia de la API de ese método.
Directrices generales para gestionar el acceso en Cloud KMS
Te recomendamos que no uses roles básicos de todo el proyecto, como owner
, editor
y viewer
. Estos roles no separan la capacidad de gestionar claves de la capacidad de usar las claves para operaciones criptográficas, por lo que no se recomiendan para entornos de producción. En su lugar, usa roles predefinidos o crea roles personalizados que reflejen los requisitos de tu empresa.
Los siguientes ejemplos ilustran algunas buenas prácticas de seguridad:
En el caso de una organización grande o compleja, puedes optar por un enfoque como el siguiente:
- Asigna el rol Administrador de Cloud KMS (
roles/cloudkms.admin
) a los miembros de tu equipo de seguridad informática en todos los proyectos. Si diferentes miembros del equipo se encargan de distintos aspectos del ciclo de vida de una clave, puedes asignarles un rol más específico, como el rol Importador de Cloud KMS (roles/cloudkms.importer
). - Asigna el rol de encargado de encriptar o desencriptar de Cloud KMS (
roles/cloudkms.cryptoKeyEncrypterDecrypter
) a los usuarios o las aplicaciones que lean o escriban datos encriptados. - Asigna el rol Lector de claves públicas de Cloud KMS (
roles/cloudkms.publicKeyViewer
) a los usuarios o las aplicaciones que necesiten ver la parte pública de una clave usada para el cifrado asimétrico. - Crea roles predefinidos que se ajusten a los requisitos de tu empresa. Por ejemplo, un mismo usuario puede necesitar monitorizar las cuotas de un proyecto y ver los datos de registro.
- Asigna el rol Administrador de Cloud KMS (
En el caso de una organización pequeña con requisitos de seguridad sencillos, puedes optar por un enfoque más simple y asignar un rol amplio, como Administrador de la organización (
roles/resourcemanager.organizationAdmin
). Sin embargo, es posible que este enfoque no se adapte a tus necesidades a medida que cambien.Te recomendamos que alojes tus claves en un proyecto Google Cloud independiente de los datos protegidos por esas claves. Un usuario con un rol básico o con muchos privilegios en un proyecto, como
editor
, no puede usar este rol para obtener acceso no autorizado a claves de otro proyecto.No concedas el rol
owner
a ningún miembro. Sin el rolowner
, ningún miembro del proyecto puede crear una clave y usarla para descifrar datos o para firmar, a menos que se le concedan ambos permisos. Para conceder un acceso administrativo amplio sin conceder la capacidad de cifrar o descifrar, asigna el rol Administrador de Cloud KMS (roles/cloudkms.admin
).Para limitar el acceso a los datos cifrados, como los datos de clientes, puede restringir quién puede acceder a la clave y quién puede usarla para descifrar. Si es necesario, puedes crear roles personalizados detallados para satisfacer los requisitos de tu empresa.
Comprobando permisos
Cada tipo de objeto de Cloud KMS para el que puedes definir permisos de IAM detallados tiene un método testIamPermissions
.
El método testIamPermissions
devuelve el conjunto de permisos que se han concedido a la persona que llama para ese objeto.
- En el caso de los llaveros, puedes invocar el método
cloudkms.keyRings.testIamPermissions
. - En el caso de las claves, puedes invocar el método
cloudkms.cryptoKeys.testIamPermissions
. - En el caso de las tareas de importación de claves, puedes invocar el método
cloudkms.keyRings.importJobs.testIamPermissions
. - En el caso de las conexiones EKM, puedes invocar el método
cloudkms.ekmConnections.testIamPermissions
.
No puedes definir permisos de gestión de identidades y accesos en una versión de clave, por lo que el tipo de objeto CryptoKeyVersion
no tiene este método.
El método testIamPermissions
de un objeto devuelve un TestIamPermissionsResponse
.
Para ver ejemplos de cómo invocar métodos testIamPermissions
, consulta la documentación sobre permisos de prueba en la documentación de gestión de identidades y accesos.
Siguientes pasos
- Consulta cómo IAM centraliza la gestión de permisos y ámbitos de acceso para los recursos de Google Cloud .
- Conocer los diferentes tipos de objetos de Cloud KMS.