Prácticas recomendadas para organizar recursos y asignar accesos

Después de configurar su cuenta IBM Cloud®, ya puede empezar a planificar cómo desea organizar los recursos Una instancia física o lógica que puede ser aprovisionada o reservada.Algunos ejemplos de recursos pueden ser el almacenamiento, los procesadores, la memoria, las bases de datos, los clústeres y las máquinas virtuales. y asignar el acceso a las identidades de su cuenta. Estas prácticas recomendadas le proporcionan los bloques de construcción básicos para permitir el desarrollo de apps seguro y satisfactorio en IBM Cloud.

Las siguientes prácticas recomendadas se centran en los recursos habilitados para Identity and Access Management (IAM) de IBM Cloud y asignados a grupos de recursos. Los servicios de infraestructura clásicos no están habilitados para IAM, lo que significa que no pueden asignarse a grupos de recursos.

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

Utilice los grupos de recursos para organizar los recursos de la cuenta a fin de facilitar su control de acceso y facturación.

Los administradores pueden tener un mejor control del uso de recursos en el nivel de entorno de proyecto si se utiliza un grupo de recursos por entorno de proyecto. Por ejemplo, un proyecto típico tiene entornos de desarrollo, prueba y producción. Un proyecto denominado CustApp puede tener los siguientes grupos de recursos:

CustApp-Dev
CustApp-Test
CustApp-Prod

En este caso, puede asignar a un desarrollador un amplio acceso al grupo de recursos de desarrollo y un acceso mucho más restringido o nulo al grupo de recursos de producción.

Organización de recursos en grupos de recursos

Todos los recursos que se gestionan utilizando el control de acceso de IAM pertenecen a un grupo de recursos. Es usted quien asigna un recurso a un grupo de recursos cuando lo crea desde el catálogo. Es importante crear grupos de recursos primero porque no puede cambiar la asignación de recursos después de establecerla. Si accidentalmente asigna un recurso al grupo de recursos incorrecto, suprímalo y cree uno nuevo.

Se crea un grupo de recursos predeterminado para su cuenta. Si tiene una cuenta de Lite, está limitado al uso de un grupo de recursos. Si desea crear varios grupos de recursos, actualice a una cuenta de Suscripción o de Pago según uso.

Búsqueda de recursos

Puede utilizar etiquetas de usuario para organizar y buscar fácilmente recursos en su cuenta. También puede utilizar etiquetas de usuario para ayudar a identificar el uso de un equipo específico o la asignación de costes cuando vea su Exportar sus detalles de uso a un archivo CSV.

Para obtener más información, consulte Cómo trabajar con etiquetas.

Cómo funciona el acceso de IAM

Después de configurar y organizar grupos de recursos en su cuenta, puede aprovechar un par de estrategias para optimizar el proceso de gestión de accesos:

Grupos de acceso: Puede gestionar mínimamente el número de políticas asignadas proporcionando el mismo acceso a todas las identidades de un grupo de acceso en lugar de asignar el mismo acceso varias veces mediante el usuario individual, ID de servicio o perfil de confianza. Debe invitar previamente a los usuarios a su cuenta para poder añadirlos a un grupo de acceso. Si un usuario está cualificado para un perfil de confianza que es miembro del grupo de acceso, no es necesario invitarlo a su cuenta.
Perfiles de confianza: Si su organización tiene un directorio de empresa, los perfiles de confianza pueden reducir el tiempo y el trabajo necesarios para gestionar el acceso. Simplifica el proceso de inicio de sesión en la cuenta de IBM Cloud para los usuarios federados de la empresa. Puede otorgar automáticamente a los usuarios federados o los recursos de cálculo acceso a su cuenta creando perfiles de confianza. Para los usuarios federados, añada condiciones basadas en atributos SAML para definir qué usuarios federados pueden aplicar un perfil. Para los recursos de cálculo, especifique recursos específicos o añada condiciones basadas en atributos de recursos para definir qué recursos de cálculo pueden aplicar un perfil. Para ambos tipos de entidad, el nivel de acceso otorgado lo determinan las políticas de acceso especificadas dentro de cada perfil de confianza, o los grupos de acceso de los que el perfil de confianza es miembro. No obstante, los perfiles de confianza no requieren que se invite a usuarios federados a una cuenta, y solo los usuarios que estén federados por un proveedor de identidad (IdP) externo podrán aplicar un perfil de confianza.

Cuando es miembro de varios grupos de acceso, todas las políticas se aplican a la vez cuando accede a una cuenta. Como usuario federado, tiene la opción de aplicar distintos perfiles de confianza, aunque debe seleccionar solo un perfil para aplicarlo cuando inicie la sesión. Por ejemplo, si desea realizar tareas relacionadas con el desarrollo, seleccione el perfil Developer al iniciar sesión. Si desea completar una tarea relacionada con el administrador, seleccione el perfil de Admin que tenga permisos privilegiados. De esta forma, se reduce el riesgo de realizar acciones privilegiadas por error.

Una política consta de un sujeto, un destino y un rol. El tema en este caso es el grupo de acceso o el perfil de confianza. El destino es al que desea que acceda el sujeto como, por ejemplo, un conjunto de recursos en un grupo de recursos, una instancia de servicio, todos los servicios de la cuenta o todas las instancias de un servicio. El rol define el nivel de acceso otorgado.

El diagrama siguiente muestra cómo funciona una política de acceso:

Los roles de plataforma utilizados con más frecuencia son visor, editor, operador y administrador.

El rol de visor proporciona la menor cantidad de acceso para ver instancias y grupos de recursos en una cuenta.
El rol de operador incluye acciones como la capacidad de ver instancias y gestionar credenciales.
El rol de editor incluye las mismas acciones de un rol de operador y además acciones para crear, editar, suprimir y enlazar instancias de servicio.
El rol de administrador incluye todo para trabajar con una instancia de servicio y asignar acceso a otros para dicho servicio o instancia de la política.

Si bien estos son los roles más populares para asignar acceso en la plataforma, hay un segundo conjunto de roles a tener en cuenta llamados roles de servicio. Las acciones correlacionadas con estos roles se definen para cada servicio. Normalmente, las acciones correlacionadas con estos roles se relacionan específicamente con la capacidad de trabajar con las API y la interfaz de usuario de un servicio.

Para obtener más información sobre los roles que se pueden asignar, consulte los Roles de IAM.

Reducción del tiempo y del esfuerzo necesarios para gestionar el acceso

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, las condiciones basadas en el tiempo para las políticas de acceso otorgan acceso sólo durante el periodo de tiempo que especifique, lo que reduce la oportunidad de ataque en el caso de una infracción de seguridad. Para obtener más información, consulte Limitación del acceso con condiciones basadas en el tiempo.
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.
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 e ID de servicio de su cuenta a escala. Al asignar acceso sólo a recursos e ID de servicio que tengan etiquetas específicas asociadas, puede evitar múltiples 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.

Asigne acceso utilizando un grupo de servicios para que solo necesite una única política para asignar acceso a varios servicios. De esta forma, disminuirá el número de políticas en su cuenta y reducirá el tiempo y el esfuerzo para gestionar el acceso.

 * **All Identity and Access enabled services**: All catalog services that use IAM for access management.
 * **All Account Management services**: Platform services, such as billing and usage, license and entitlements, enterprises, and more. For more information, see [Assigning access to account management services](/docs/iam?topic=iam-account-services).
 * **All IAM Account Management services**: A subset of account management services that includes the IAM platform services IAM Identity, IAM Access Management, IAM Users, IAM Groups, and future IAM services.

La eliminación del acceso para identidades inactivas y políticas inactivas puede reducir el riesgo de acceso no autorizado a sus recursos de IBM Cloud y ayudarle a gestionar el acceso de forma más eficiente. Para obtener más información, consulte Identificación de identidades inactivas y Auditoría de políticas de acceso.

¿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 habilitados para Identidad y Acceso 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. Los usuarios con la función de administrador pueden cambiar el acceso y eliminar grupos de acceso y agregar y eliminar usuarios de un grupo de acceso, incluidos otros usuarios con la función de administrador.

Los usuarios con función de administrador en grupos de acceso pueden otorgar o revocar el acceso agregando o eliminando usuarios de un grupo de acceso. Al crear un grupo de acceso con acceso de administrador, está delegando la concesión y revocación del acceso de administrador de la cuenta a los administradores agregados del grupo de acceso. El acceso de administrador a todo lo que hay en la cuenta incluye la capacidad de revocar el acceso de otros usuarios con la función de administrador.

El diagrama siguiente muestra cómo se asigna el acceso a los grupos de recursos:

Asignación de acceso a grupos de recursos

Para conocer más prácticas recomendadas de IBM Garage for Cloud, consulte Gestión del acceso a los recursos en IBM Cloud.

Políticas de acceso de ejemplo

Revise las siguientes políticas de acceso de ejemplo para determinar cómo puede asignar acceso a un grupo de acceso para recursos organizados en grupos de recursos.

Una política que otorga al grupo de acceso un rol de administrador de plataforma en IBM Cloud Kubernetes Service en toda la cuenta. Los usuarios del grupo de acceso pueden acceder a todas las instancias de este servicio y crear instancias del servicio en cualquier grupo de recursos que tengan al menos un rol de visor asignado. Los miembros del grupo de acceso con un rol de administrador asignado en cualquier recurso también pueden otorgar acceso a dicho recurso.
Una política que otorga al grupo de acceso un rol de visor de plataforma en un grupo de recursos pero que no a los recursos que lo componen. Los usuarios del grupo de acceso tienen visibilidad para el grupo de recursos, necesario para crear instancias de cualquier servicio en este grupo de recursos.
Una política que otorga al grupo de acceso un rol de editor de plataforma en todos los recursos del grupo de recursos. Los usuarios del grupo de acceso pueden editar o suprimir ese recurso.
Una política que otorga al grupo de acceso un rol de administrador de plataforma en toda la cuenta (todos los servicios habilitados para IAM). Los usuarios del grupo de acceso pueden llevar a cabo cualquier acción de plataforma en cualquier recurso de la cuenta así como acciones de gestión como, por ejemplo, los grupos de recursos en la cuenta.

¿En qué consiste una buena estrategia de perfiles de confianza?

Un perfil de confianza es una agrupación de usuarios federados o recursos de cálculo a los que se puede otorgar el mismo acceso IAM. Todas las identidades que pueden aplicar un perfil individual heredan el mismo acceso. Para reducir el número de políticas de una cuenta, puede añadir recursos de cálculo y usuarios federados al mismo perfil de confianza si sus necesidades de acceso son las mismas.

Una forma lógica de asignar acceso a sus grupos de recursos y a los recursos incluidos es mediante la creación de un perfil de confianza. Para obtener más información, consulte Perfiles de confianza para usuarios federados y cargas de trabajo por nivel de acceso requerido. A continuación, puede correlacionar cada perfil de confianza con los grupos de recursos creados previamente. Por ejemplo, para controlar el acceso al proyecto CustApp, puede crear los siguientes perfiles de confianza:

Perfil de auditor
Perfil de desarrollador
Perfil de administrador

Para el Auditor-Profile, especifique condiciones basadas en atributos SAML para los usuarios federados que desea que puedan aplicar este perfil. Estos atributos SAML se definen en el directorio de usuarios corporativo. De esta forma, la gestión de usuarios federados, el otorgamiento de acceso y la revocación del acceso se realizan principalmente en el directorio de usuarios corporativo. A continuación, asigne dos políticas de acceso que otorguen acceso de visor a los recursos CustApp-Test y CustApp-Prod y a los grupos de recursos.

Para el Developer-Profile, especifique condiciones basadas en atributos SAML para los usuarios federados que desea que puedan aplicar este perfil. Asigne dos políticas de acceso que otorguen acceso de editor a los recursos CustApp-Dev y CustApp-Test y a los grupos de recursos. Para el Admin-Profile, especifique condiciones basadas en atributos SAML para los usuarios federados que desea que puedan aplicar este perfil. A continuación, asigne tres políticas de acceso que otorguen acceso de administrador a los tres grupos de recursos CustApp y a sus recursos.

A un perfil de confianza, como otras identidades de IAM, se le puede otorgar acceso utilizando una política o añadiéndole a un grupo de acceso. Si tiene grupos de acceso que tienen el mismo nivel de acceso que necesita un perfil de confianza, el perfil de confianza se puede añadir a ese grupo de acceso.

El diagrama siguiente muestra cómo se asigna el acceso a los perfiles de confianza:

Asignación de acceso a perfiles de confianza

Solo puede seleccionar un tipo de entidad de confianza cuando crea por primera vez un perfil de confianza. Puede empezar por Actualizar perfiles de confianza utilizando la consola en cualquier momento para añadir relaciones de confianza con recursos informáticos.

Puede asignar acceso de administrador a todo en una cuenta creando un perfil de confianza y asignándole dos políticas. Para crear la primera política, seleccione Todos los servicios habilitados para Identidad y Acceso con el rol de plataforma Administrador y el rol de servicio Gestor. Para la segunda política, seleccione Todos los servicios de gestión de cuentas con el rol de administrador asignado. Los usuarios con la función de administrador pueden actualizar y eliminar el acceso del perfil confiable y agregar y eliminar usuarios del perfil confiable, incluidos otros usuarios con la función de administrador.

Los usuarios con el rol de Administrador en perfiles confiables pueden otorgar o revocar el acceso agregando o eliminando reglas de perfiles confiables. Al crear un perfil confiable con acceso de administrador, delega la concesión y revocación del acceso de administrador de la cuenta a los administradores agregados del perfil confiable. El acceso de administrador a todo lo que hay en la cuenta incluye la capacidad de revocar el acceso de otros usuarios con la función de administrador.

Políticas de acceso de ejemplo

Revise las siguientes políticas de acceso de ejemplo para determinar cómo puede asignar a los perfiles de confianza acceso a recursos organizados en grupos de recursos.

Una política que otorga a los usuarios federados un rol de administrador de plataforma en IBM Cloud Kubernetes Service en toda la cuenta. Los usuarios federados pueden aplicar este perfil cuando los atributos de IdP externo del usuario federado cumplen las condiciones de la relación de confianza. Por ejemplo, si el directorio de usuarios corporativo tiene un atributo jobrole que identifica a los administradores por el valor admin, puede crear una condición que añada dinámicamente usuarios federados con dicho atributo al perfil de confianza, junto con otras condiciones. Los usuarios federados que tienen permiso para aplicar el perfil de confianza pueden acceder a todas las instancias de este servicio y crear instancias del servicio en cualquier grupo de recursos para el que tengan al menos un rol de visor asignado. Los perfiles de confianza con un rol de administrador para un recurso también pueden otorgar acceso a dicho recurso. Se pueden especificar condiciones para que solo los usuarios federados que requieran los máximos privilegios puedan aplicar este perfil de confianza. Los demás usuarios federados se pueden filtrar en función de sus atributos SAML.
Una política que otorga los roles Reader y Writer de recursos de cálculo en un grupo de recursos. Cuando los recursos de cálculo se autentican y cumplen las condiciones especificadas en el perfil de confianza, por ejemplo, la location o el resource type, el perfil de confianza se aplica automáticamente. De este modo, los recursos existentes o futuros que cumplan estas condiciones pueden tener el perfil que se aplica automáticamente cuando se autentica.
También puede establecer la confianza con recursos de cálculo específicos como, por ejemplo, un clúster de Kubernetes individual. Por ejemplo, puede tener una aplicación ejecutándose en Kubernetes Service y que la aplicación necesite leer y escribir en IBM Cloudant y leer y escribir en un grupo de Cloud Object Storage Dedicated IBM Managed. Las instancias de IBM Cloudant y Cloud Object Storage Dedicated IBM Managed estarán en el mismo grupo de recursos y se asignarán los roles Reader o Writer al perfil de confianza.

La utilización de perfiles de confianza es una práctica recomendada para las aplicaciones que se ejecutan en recursos de cálculo de IBM Cloud para obtener acceso a recursos habilitados para IAM.

Comparación de grupos de acceso y perfiles de confianza

Los grupos de acceso se utilizan mejor para conceder acceso al trabajo diario de un usuario, mientras que los perfiles de confianza son adecuados para conceder a los usuarios federados el nivel de acceso que necesitan para completar un conjunto especializado y específico de tareas en un periodo de tiempo limitado. Suelen ser tareas críticas que desearía no tener que hacer accidentalmente en el trabajo diario. Con los perfiles de confianza, los usuarios federados no necesitan incorporarse en IBM Cloud; se les otorga acceso a recursos de IBM Cloud en una cuenta mediante la relación de confianza. Si un usuario federado deja su empresa, simplemente puede suprimir su identidad corporativa en el directorio, lo que también elimina el acceso a IBM Cloud. El acceso basado en el tiempo con perfiles de confianza permite realizar comprobaciones de autenticación frecuentes para reducir los riesgos de seguridad.

Utilice la tabla siguiente para comprender las diferencias entre el uso de grupos de acceso y perfiles de confianza para tomar la mejor decisión para su caso de uso.

Comparación de grupos de acceso y perfiles de confianza
Característica	Grupo de acceso	Perfil de confianza
Control de acceso de IAM	Sí	Sí
Se requiere invitar a los usuarios a la cuenta IBM Cloud	Sí	No
El acceso se puede definir antes de añadir el usuario a la cuenta	Sí, utilizando reglas dinámicas	Sí
Usuarios federados	Sí	Sí
Usuarios no federados	Sí	Sí
ID de servicio	Sí	Sí
Identidades de recursos de cálculo	No	Sí
La gestión de usuarios se realiza principalmente en	Cuenta IBM Cloud	Directorio de usuarios corporativo

Los grupos de acceso y los perfiles de confianza se pueden utilizar por separado o conjuntamente para la gestión de usuarios y accesos, en función de las necesidades de su organización.

Por ejemplo, para el proyecto CustApp, puede elegir crear un perfil de confianza IAM Admin con las políticas siguientes:

Administrator para los grupos de acceso CustApp-Dev/Test/Prod. De esta forma, el administrador puede otorgar y revocar el acceso a los usuarios añadiéndolos y eliminándolos de los grupos de acceso.
Administrator para el servicio de gestión de cuentas de identidad IAM. De esta forma, el administrador puede gestionar los ID de servicio, los perfiles de confianza, las reglas, etc.
Editor para el servicio de gestión de cuentas de Gestión de usuarios. De esta forma, el administrador puede invitar los usuarios a la cuenta, ver los usuarios de la cuenta, etc.

Con este perfil de confianza, el administrador puede añadir desarrolladores a un grupo de acceso con amplias políticas de acceso para realizar las acciones y las tareas del día a día en los entornos de desarrollo y prueba. El acceso para las operaciones en el entorno de producción se puede configurar en un perfil de confianza denominado Operator-Profile. De esta forma, el desarrollador puede cambiar los roles de trabajo iniciando una sesión y aplicando el Operator-Profile cuando necesite realizar alguna acción de operación en el proyecto CustApp en producción.

Casos de uso para la organización de recursos y asignación de acceso

Revise los siguientes casos de uso para ayudarle a preparar un plan que funcione para su organización. Para cada caso de uso, se recomienda utilizar grupos de acceso o perfiles de confianza para proporcionar acceso a un grupo de usuarios manteniendo un número mínimo de políticas de acceso. Al utilizar grupos de acceso, simplemente puede añadir o eliminar usuarios de la cuenta de los grupos de acceso para asignar o revocar el acceso según sea necesario. Mediante el uso de perfiles de confianza, puede actualizar fácilmente las condiciones en las que los usuarios federados de su directorio de usuarios corporativo pueden aplicar perfiles de confianza sin necesidad de invitarlos a la cuenta ni de asignar acceso individual a cada usuario.

Varios usuarios que trabajan juntos en un proyecto individual utilizando grupos de acceso

Algunos de los usuarios de la cuenta necesitan gestionar la cuenta y asignar acceso a otros usuarios. Algunos usuarios necesitan crear instancias de servicio que incurran en gastos. Otros usuarios son desarrolladores de aplicaciones que necesitan utilizar sólo las instancias de servicio de los componentes de su aplicación.

Quiere otorgar a todos los usuarios diversos roles de la cuenta y del grupo de recursos predeterminado. No le hace falta crear más grupos de recursos para separar recursos o restringir el acceso a algunos usuarios a ciertos recursos. Puede otorgar a los usuarios los roles adecuados para sus necesidades creando un grupo de acceso para cada grupo de usuarios:

Cree un grupo de acceso y asigne usuarios al grupo que necesitan gestionar la cuenta y dar acceso a otros usuarios. A continuación, asigne una política con un rol de administrador en todos los servicios habilitados para IAM y todos los servicios de gestión de cuentas.
Cree un grupo de acceso y asigne usuarios al grupo que necesiten crear instancias de servicio. A continuación, asigne una política con un rol de editor sobre el grupo de recursos predeterminado y una política con el rol de editor para cualquier servicio que los usuarios necesiten crear.
Cree un grupo de acceso y asigne usuarios al grupo que necesite utilizar las instancias de servicio de un grupo de recursos. A continuación, asigne una política con un rol de escritor o lector sobre las instancias de servicio que existen en el grupo de recursos.

Varios usuarios que trabajan juntos en un proyecto individual utilizando perfiles de confianza

En una organización, cuando se desea gestionar el acceso a escala, algunos de los miembros de la organización deben gestionar la cuenta IBM Cloud y asignar el acceso a otros usuarios. Algunos miembros necesitan crear instancias de servicio que incurren en gastos. Otros miembros son desarrolladores de aplicaciones que necesitan utilizar solo las instancias de servicio de sus componentes de aplicación.

Cree un perfil de confianza para los usuarios que necesitan gestionar la cuenta y dar acceso a otros usuarios. Establezca una relación de confianza con el IdP externo y defina los atributos que permitan aplicar el perfil a los miembros adecuados de su organización. A continuación, asigne una política con un rol de administrador en todos los servicios habilitados para IAM y todos los servicios de gestión de cuentas.
Cree un perfil de confianza para los usuarios que necesitan crear instancias de servicio. Establezca una relación de confianza con el IdP externo y defina los atributos que permitan aplicar el perfil a los miembros adecuados de su organización. A continuación, asigne una política con un rol de editor sobre el grupo de recursos predeterminado y una política con el rol de editor para cualquier servicio que los usuarios necesiten crear.
Cree un perfil de confianza para los usuarios que necesitan utilizar las instancias de servicio en un grupo de recursos. Establezca una relación de confianza con el IdP externo y defina los atributos que permitan aplicar el perfil a los miembros adecuados de su organización. A continuación, asigne una política con un rol de escritor o lector sobre las instancias de servicio que existen en el grupo de recursos.

Dos equipos que trabajan en dos proyectos relacionados

Tiene dos proyectos funcionales en su cuenta. Los desarrolladores que trabajan en un proyecto necesitan acceso a todos sus recursos. Como administrador de la cuenta, puede otorgar acceso creando grupos de acceso para cada proyecto e incorporando etiquetas de gestión de acceso a las políticas de acceso de cada grupo.

La flexibilidad es importante y con IAM puede compartir recursos entre varios grupos. Digamos que usted advierte que un recurso podría funcionar bien para ambos proyectos. Puede compartir un recurso entre los dos proyectos etiquetando el recurso y confiando en los permisos existentes para otorgar acceso a los desarrolladores. Si un proyecto ya no necesita un recurso, simplemente puede revocar el acceso de los desarrolladores desconectando la etiqueta adecuada de la instancia de servicio. Consulte el siguiente vídeo para entender mejor cómo puede utilizar las etiquetas de gestión de acceso para gestionar el acceso a los recursos de su cuenta.

Transcripción del vídeo

Como administrador de la cuenta, puede utilizar etiquetas para gestionar de forma centralizada el acceso a los recursos de su cuenta a escala.

Por ejemplo, tiene dos proyectos funcionales: uno se llama soulmate y se utiliza para el almacenamiento y los servicios de lenguaje de Watson, y el otro se llama Soul-FAQ y es un soporte para el proyecto soulmate. Utiliza Watson Assistant y Cloud Object Storage.

Para crear etiquetas de gestión de acceso como administrador de la cuenta, pulse Gestionar y, a continuación, Cuenta en la consola de IBM Cloud. En la página Etiquetas, pulse Etiquetas de gestión de acceso. Para crear nuevas etiquetas, escriba los nombres de etiqueta separados por comas. Vamos a crear dos etiquetas, una para el proyecto soulmate y otra para el proyecto soul-faq.

Al saltar a la lista de recursos se pueden ver todos los recursos de la cuenta. Puede etiquetar aquí los recursos relacionados con el proyecto y verlos en toda la cuenta filtrando por etiquetas.

En este punto, el desarrollador no puede ver los recursos porque todavía no tiene los permisos correctos asignados.

Un administrador de cuentas puede otorgar a los desarrolladores permisos para acceder a los recursos de su proyecto utilizando una combinación de grupos de acceso y etiquetas.

Como administrador de la cuenta, pulse Gestionar, después Acceso y seleccione Grupos de acceso. Tiene dos grupos de acceso configurados: uno para el proyecto soulmate y otro para FAQ.

Hay un desarrollador en el grupo de desarrolladores de soulmate. No hay ninguna política configurada, por lo que el administrador de la cuenta debe asignar acceso. Para hacerlo, seleccione todos los servicios de la cuenta según atributos específicos. Seleccione Etiquetas de gestión de acceso para ver todas las etiquetas que están disponibles en la cuenta. Puesto que está creando una política para el proyecto soulmate, seleccione la etiqueta correspondiente. La consola muestra que la etiqueta soulmate del proyecto se correlaciona con tres recursos distintos.

A continuación, seleccione algunos roles. Dele a todo el grupo el rol de visor para que todos puedan ver los recursos de la lista, así como todo el acceso funcional a estos servicios. Pulse Asignar para crear la política.

Ahora hay tres servicios disponibles para el desarrollador. Tienen acceso a los tres recursos y a los subrecursos que puedan existir.

La flexibilidad es importante, por lo que hemos facilitado la compartición de recursos entre varios grupos. Digamos que un administrador de cuentas advierte que IBM Cloud Object Storage es ideal a efectos de copia de seguridad y funciona bien con el proyecto FAQ. El administrador de la cuenta desea utilizar IBM Cloud Object Storage en el proyecto soulmate.

Simplemente edite las etiquetas de gestión de acceso. Añada la etiqueta del proyecto soulmate y pulse Guardar.

En la lista de recursos, puede confirmar que hay dos etiquetas de gestión de acceso conectadas a la instancia de Cloud Object Storage.

Además de los recursos originales, el desarrollador puede ver ahora el recurso de Cloud Object Storage. La instancia está disponible para cualquier persona que tenga acceso al proyecto soulmate o al proyecto FAQ.

Digamos que ya no desea tener el servicio Tone Analyzer para el proyecto. Al desconectar la etiqueta del proyecto soulmate del servicio Tone Analyzer se revoca el acceso del desarrollador a dicha instancia de servicio. Un administrador de cuentas puede desconectar la etiqueta pulsando Editar etiquetas y suprimiendo la etiqueta de la lista.

La instancia del servicio Tone Analyzer ya no está incluida en la lista de recursos del desarrollador.

Cuando utiliza etiquetas de gestión de acceso para controlar el acceso, los proyectos de su equipo pueden crecer sin que sea necesario realizar actualizaciones en las políticas de IAM.

Tres equipos trabajando en tres proyectos

Algunos usuarios de mi cuenta son administradores. Necesitan crear nuevos grupos de recursos y asignar acceso a los usuarios. Asigno estos usuarios a un grupo de acceso con una política que tiene el rol de administrador que está asignado en todos los servicios habilitados para IAM.

Los usuarios restantes necesitan acceso solo al grupo de recursos asociado a su proyecto. Utilizo grupos de acceso y asigno varios roles al grupo de recursos y a sus miembros asociados con su proyecto: un rol de editor en el grupo de recursos para aquellos que necesitan crear instancias, además de un rol de lector o de escritor en los miembros del grupo de recursos para aquellos que necesitan utilizar dichas instancias.

Varios grupos de recursos de mi cuenta

Algunos de los usuarios de mi cuenta son administradores de un servicio Service A, de toda la cuenta, y deben poder acceder a todas las instancias de ese servicio y a crear instancias. Estos usuarios no necesitan acceso a otros recursos de la cuenta. Se crea un grupo de acceso y se asigna un rol de administrador en el Servicio A a nivel de cuenta y una política con el rol de visor para los grupos de recursos de la cuenta en la que necesitan poder crear instancias. Para ello, seleccione Sólo grupo de recursos y, a continuación, seleccione el grupo de recursos y, al menos, el rol de espectador para ese grupo de recursos. A continuación, repita para cada grupo de recursos al que necesite acceder.

Un usuario que requiere acceso a un recurso específico

Mi cuenta incluye un usuario que necesita acceso solo a un recurso específico de un servicio, por ejemplo, la posibilidad de escribir en un grupo, Bucket A, en IBM Cloud Object Storage. Este usuario no necesita ver los grupos de recursos de mi cuenta o acceder a otros servicios o grupos de esta instancia de Object Storage.

Asigno al usuario un rol de escritor en el Grupo A en la instancia específica de Object Storage. Puedo elegir utilizar la interfaz de usuario de IAM o la interfaz de usuario de Object Storage para asignar el rol. Utilizo la interfaz de usuario específica del servicio porque puedo hacerlo desde una lista de recursos. La interfaz de usuario de IAM no muestra recursos pasados al nivel de instancia de servicio y tengo que especificar manualmente el CRN para asignar política a dichos recursos.

Próximos pasos

Ahora que sabe cómo configurar los grupos de recursos, organizar los recursos y crear grupos de acceso en su cuenta, puede empezar a invitar a usuarios a su cuenta y asignarles acceso a los grupos de acceso. Si ya has invitado a usuarios a tu cuenta, puedes ir a tu página de Usuarios y empezar a Asignar accesos en la consola.

Si decide que su organización quiere gestionar el acceso de los usuarios basándose en su directorio de usuarios corporativo, puede empezar por crear un perfil de confianza. Para obtener más información, consulte Perfiles de confianza para usuarios y cargas de trabajo federados.