Prácticas recomendadas

Existe un límite en cuanto al número total de políticas que se permiten en una cuenta. Puede utilizar varias estrategias para asegurarse de que no alcanza el límite y reducir la cantidad de tiempo que dedica a gestionar el acceso para las identidades en su cuenta (usuarios, ID de servicio o perfiles de confianza):

• Utilice el principio de menor privilegio y asigne solo el acceso que sea necesario. Esto le puede ayudar a garantizar que las entidades de su cuenta se limitan únicamente a las acciones que desea permitir. Por ejemplo, en lugar de que el propietario de la cuenta comparta sus credenciales, que de forma predeterminada les da acceso de Administrador y Gestor sobre todos los recursos de su cuenta, cree nuevas políticas para los usuarios que necesitan acceder a la cuenta y a cada instancia de servicio (y sus claves asociadas).
• Añada recursos a un grupo de recursos para minimizar el número de políticas necesarias. Por ejemplo, podría tener un equipo que trabaje en un proyecto que utilice recursos específicos de su cuenta. Añada los miembros del equipo a un grupo de acceso o un perfil de confianza con una política que asigne acceso solo a los recursos que están en un grupo de recursos específico. De este modo, no es necesario asignar una política a cada recurso para cada miembro del equipo. Para obtener más información sobre la asignación de acceso preciso, consulte Asignar acceso preciso a una sola clave.
• Utilice grupos de acceso para agilizar la gestión del acceso para las identidades que requieren el mismo nivel de acceso. Puede configurar un grupo de acceso con una política específica definida y luego añadir esas identidades al grupo. Si los miembros del grupo necesitan más acceso más adelante, solo tiene que definir una nueva política para el grupo de acceso.
• Utilice etiquetas de gestión de acceso para controlar el acceso a los recursos de su cuenta a escala. Al asignar el acceso solo a los recursos que tienen etiquetas específicas adjuntas, puede evitar varias actualizaciones de las políticas definidas. Para obtener más información, consulte Control del acceso a los recursos mediante etiquetas.
• Utilice perfiles de confianza para otorgar automáticamente a los usuarios federados y los recursos de cálculo acceso a su cuenta. De esta forma, los usuarios federados pueden correlacionarse con uno o varios perfiles de confianza durante el inicio de sesión evaluando los atributos basados en SAML para determinar qué perfiles pueden aplicar. La utilización de perfiles de confianza para recursos de cálculo permite evitar el almacenamiento de credenciales para ejecutar aplicaciones, así como la gestión y la rotación de credenciales. También puede añadir perfiles de confianza a grupos de acceso para aprovechar el conjunto de políticas que ya ha creado.
• Audite regularmente quién puede gestionar el control de acceso y suprimir los recursos clave. Debido a que los errores y un uso incorrecto por parte de los usuarios con permisos elevados pueden causar daños a su cuenta, a las instancias de servicio y a los datos protegidos mediante claves en la instancia de servicio, asegúrese de que se mantiene el acceso adecuado mediante la auditoría de los usuarios con dichos roles. Recuerde que las nuevas claves, conjuntos de claves o instancias de servicio que se creen están sujetos a las definiciones de roles existentes de forma predeterminada. Si no desea que un nuevo usuario que está asignado como Gestor de la instancia pueda acceder a una clave nueva ni modificarla, esa restricción debe asignarse específicamente, ya que los gestores de instancias tienen acceso a todas las claves de una instancia de forma predeterminada, incluyendo ida la capacidad de suprimir una clave.

¿Qué es una buena estrategia de grupo de acceso?

Un grupo de acceso es una organización de usuarios, ID de servicio y perfiles de confianza de una agrupación a la que se puede otorgar el mismo acceso IAM. Todas las identidades de un único grupo de acceso heredan el mismo acceso.

Una forma lógica de asignar acceso a los grupos de recursos y los recursos incluidos es mediante la creación de un grupo de acceso por nivel de acceso necesario. A continuación, puede correlacionar cada grupo de acceso con los grupos de recursos creados anteriormente. Por ejemplo, para controlar el acceso al proyecto CustApp, puede crear los siguientes grupos de acceso:

• Auditor-Group
• Developer-Group
• Admin-Group

Para Auditor-Group, asigne dos políticas de acceso que otorgaran acceso de visor a los recursos y grupos de recursos de CustApp-Test y CustApp-Prod. Para Developer-Group, asigne dos políticas de acceso que otorgan acceso de editor los recursos y grupos de recursos de CustApp-Dev y CustApp-Test. Para Admin-Group, asigne tres políticas de acceso que otorguen acceso de administrador a los tres grupos de recursos de CustApp y a sus recursos.

Puede asignar acceso de administrador a todo lo relacionado con la cuenta creando un grupo de acceso y asignándole dos políticas. Para crear la primera política, seleccione Todos los servicios de identidad y acceso habilitados en Cuenta con el rol de plataforma Administrador y el rol de servicio Gestor. Para crear la segunda política, seleccione Todos los servicios de gestión de cuentas con el rol de Administrador asignado.

Roles de plataforma

• Administrador: Tiene todo el espectro de derechos sobre un objeto determinado y sus objetos "hijo" (por ejemplo, las claves son objetos hijo de instancias), incluyendo el derecho a invitar a nuevos usuarios y asignar roles sobre el objeto (sólo los administradores pueden asignar roles). Tenga en cuenta que los administradores no tienen roles de servicio de forma predeterminada. Sin embargo, pueden asignarse roles a sí mismos.
• Editor: Puede ver, crear y suprimir instancias a nivel de cuenta, pero no puede invitar a nuevos usuarios. Tiene un uso limitado para objetos dentro de una instancia de servicio, como por ejemplo claves, más allá de la capacidad de verlos.
• Operador: Puede ver instancias a nivel de cuenta, pero no puede editarlas. Tiene un uso limitado para objetos dentro de una instancia de servicio, como por ejemplo claves, más allá de la capacidad de verlos.
• Visor: Puede ver instancias a nivel de cuenta, pero no puede editarlas. Tiene un uso limitado para objetos dentro de una instancia de servicio, como por ejemplo claves, más allá de la capacidad de verlos.

Los roles de plataforma se asignan sobre una cuenta completa, sobre instancias de servicio determinadas o dentro de objetos dentro de una instancia de servicio.

Enumera las funciones de gestión de la plataforma en lo que respecta a Key Protect

Acción	Visor	Editor	Operador	Administrador
Ver instancias de Key Protect
Crear instancias de Key Protect
Suprimir instancias de Key Protect
Invitar a nuevos usuarios y gestionar políticas de acceso

Aunque un rol de nivel de cuenta otorga a un usuario permisos particulares sobre instancias de servicio de forma predeterminada, los roles también se pueden asignar sobre una instancia de servicio determinada. Por ejemplo, un Editor de una cuenta (que tiene la capacidad de ver, crear y suprimir instancias, pero no la capacidad de asignar roles) se puede pasar a Administrador de una instancia de servicio determinada, por lo que se le permite asignar roles dentro de esa instancia de servicio.

Los roles de servicio se pueden aplicar a los tres objetos de primera clase dentro de una instancia de servicio: la instancia como un todo, claves particulares y conjuntos de claves. Al igual que los roles de cuenta tienen permisos sobre instancias de forma predeterminada, también los gestores de instancias tienen permisos sobre claves y conjuntos de claves de forma predeterminada. Sin embargo, estos permisos se pueden asignar de forma más precisa cuando sea necesario, por ejemplo, dar a un usuario el rol de Gestor sobre sólo una clave o un anillo de claves en particular y un nivel menor de permiso sobre la instancia en su conjunto.

Los roles de servicio se pueden asignar por instancia o para todas las instancias de una cuenta.

Funciones de las instancias de servicio

Tenga en cuenta que los permisos incluidos en los roles son aditivos. Un Gestor, por ejemplo, tiene todos los permisos que tiene un Lector y más. La excepción es el rol KeyPurge, que incluye la acción kms.secrets.purge que no forma parte de ningún otro rol y, por lo tanto, debe establecerse explícitamente.

• Gestor: Tiene todo el espectro de derechos sobre un objeto determinado (por ejemplo, el gestor de una clave tiene la capacidad de encapsular, desencapsular y suprimir la clave, así como el derecho exclusivo de leer y actualizar políticas de Key Protect como por ejemplo dualAuthDelete, allowedNetwork, allowedIP, entre otras).
• Escritor: Tiene la mayoría de los mismos derechos que un gestor a la hora de utilizar un objeto (incluyendo la capacidad de recuperar una clave y sus metadatos), pero generalmente no puede suprimir ni inhabilitar el objeto.
• Lector: Puede utilizar el objeto (por ejemplo, los lectores de claves pueden encapsular y desencapsular una clave), pero no crear, suprimir ni modificar el objeto.
• Lector Plus: Tiene los mismos derechos que un lector, con la capacidad adicional de recuperar la carga útil de una clave estándar.
• KeyPurge: Tiene la capacidad de Depurar claves pasadas cuatro horas.
• KmipAdapterManager: Tiene todos los derechos necesarios para gestionar el acceso a los recursos gobernados a través del protocolo KMIP

La siguiente tabla muestra cómo los roles acceso al servicio se correlacionan con los permisos de Key Protect.

Enumera los roles de acceso al servicio en lo que respecta a los recursos clave de Key Protect

Acción	Lector	ReaderPlus	Writer	Gestor	KeyPurge	KmipAdapterManager
Crear una clave
Importar una clave
Recuperar una clave
Recuperar metadatos de clave
Recuperar el total de claves
Listar claves
Listar versiones de clave
Encapsular una clave
Desencapsular una clave
Reencapsular una clave
Rotar una clave
Inhabilitar una clave
Habilitar una clave
Planificar la supresión de una clave
Cancelar la supresión de una clave
Suprimir una clave
Restaurar una clave
Aplicar parche a una clave
Sincronizar claves
Depurar claves después de cuatro horas

Enumera los roles de acceso al servicio en lo que respecta a los recursos del llavero de « Key Protect ».

Acción	Lector	ReaderPlus	Writer	Gestor	KeyPurge	KmipAdapterManager
Crear un conjunto de claves
Listar conjuntos de claves
Suprimir un conjunto de claves

Enumera los roles de acceso al servicio tal y como se aplican a los recursos de políticas de « Key Protect ».

Acción	Lector	ReaderPlus	Writer	Gestor	KeyPurge	KmipAdapterManager
Establecer políticas de claves
Listar políticas de claves
Establecer políticas de instancia
Listar políticas de instancia

Enumera los roles de acceso al servicio que se aplican a la importación de recursos de tokens

Acción	Lector	ReaderPlus	Writer	Gestor	KeyPurge	KmipAdapterManager
Crear una señal de importación
Recuperar una señal de importación

Enumera los roles de acceso al servicio en lo que respecta a los recursos de registro de Key Protect

Acción	Lector	ReaderPlus	Writer	Gestor	KeyPurge	KmipAdapterManager
Crear un registro[^services-1]
Listar los registros de una clave
Listar los registros de cualquier clave
Actualizar un registro[^services-2]
Sustituir un registro[^services-3]
Suprimir un registro[^services-4]

El rol KeyPurge sólo confiere la capacidad de depurar claves y debe considerarse como una adición a otros roles de acceso de servicio, como por ejemplo Gestor.

Enumera los roles de acceso al servicio en lo que respecta a los recursos clave de Key Protect

Acción	Lector	ReaderPlus	Writer	Gestor	KeyPurge	KmipAdapterManager
Lista de adaptadores KMIP
Crear un adaptador KMIP
Recuperar un adaptador KMIP
Borrar un adaptador KMIP
Lista de objetos KMIP de un adaptador KMIP
Recuperar un objeto KMIP de un adaptador KMIP
Borrar un objeto KMIP de un adaptador KMIP
Lista de certificados de cliente de un adaptador KMIP
Añadir un certificado de cliente a un adaptador KMIP
Recuperar un certificado de cliente de un adaptador KMIP
Eliminar un certificado de cliente de un adaptador KMIP

Los roles Writer, Reader y ReaderPlus no tienen acceso al protocolo KMIP.

Roles y políticas Cloud Identity and Access Management

Aunque la consola Key Protect permite a los usuarios un control de acceso preciso utilizando estos roles, puede ser útil recordar que estos roles están conectados a las políticas de Cloud Identity and Access Management:

• nombre de servicio (para Key Protect, siempre kms)
• id de instancia de servicio
• id de conjunto de claves
• tipo de recurso (sólo se da soporte a la key)
• id de recurso
• id de cuenta (debe especificarse siempre en la política)

A continuación se muestra un ejemplo de una política devuelta por la API de IAM:

"resources": [
    {
        "attributes": [
            {
                "name": "accountId",
                "value": "$ACCOUNT_ID",
            },
            {
                "name": "serviceName",
                "value": "kms",
            },
            {
                "name": "resourceType",
                "value": "key",
            },
            {
                "name": "resource",
                "value": "$KEY_ID",
            },
            {
                "name": "keyRing",
                "value": "$KEY_RING_ID",
            }
        ]
    }
]

Cualquier combinación de estos atributos se puede aplicar en una política. Si esa política tiene el rol de administrador adjunto, eso significa que cualquier user/service id/access group al que se le haya aplicado esta política puede crear una política que se aplique a un subrecurso del que se le ha otorgado. En otras palabras, todos los usuarios de subadministración sólo pueden tener un acceso igual (exactamente los mismos atributos especificados en su política) o menor (exactamente los mismos atributos especificados en su política y atributos adicionales especificados) que el del administrador padre.