Tutorial de IAM: definición de permisos para acceder a los recursos de AWS en función de etiquetas

El control de acceso basado en atributos (ABAC) es una estrategia de autorización que define permisos en función de atributos. En AWS, estos atributos se denominan etiquetas. Puede asociar etiquetas a recursos de IAM, incluidas entidades de IAM (usuarios o roles) y recursos de AWS. Puede definir políticas que utilicen claves de condición de etiqueta para conceder permisos a sus entidades principales en función de sus etiquetas. Cuando utiliza etiquetas para controlar el acceso a sus recursos de AWS, permite que sus equipos y recursos crezcan con menos cambios en las políticas de AWS. Las políticas de ABAC son más flexibles que las políticas tradicionales de AWS, en las que debe enumerar cada recurso individual. Para obtener más información acerca de ABAC y su ventaja sobre las políticas tradicionales, consulte ¿Qué es ABAC para AWS?.

nota

Debe pasar un solo valor para cada etiqueta de sesión. AWS Security Token Service no admite etiquetas de sesión de varios valores.

Temas

• Información general del tutorial
• Requisitos previos
• Paso 1: crear usuarios de prueba
• Paso 2: crear la política de ABAC
• Paso 3: crear roles
• Paso 4: Probar la creación de secretos
• Paso 5: Probar la visualización de secretos
• Paso 6: Probar la escalabilidad
• Paso 7: Probar la actualización y eliminación de secretos
• Resumen
• Recursos relacionados
• Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC

Información general del tutorial

En este tutorial se muestra cómo crear y probar una política que permite a los roles de IAM con etiquetas principales obtener acceso a los recursos con etiquetas coincidentes. Cuando una entidad principal realiza una solicitud a AWS, sus permisos se conceden en función de si la entidad principal y las etiquetas de recursos coinciden. Esta estrategia permite a las personas ver o editar solo los recursos de AWS necesarios para sus trabajos.

Escenario

Supongamos que es un desarrollador líder de una gran empresa denominada Empresa Ejemplo y que es un administrador de IAM con experiencia. Está familiarizado con la creación y administración de usuarios, roles y políticas de IAM. Quiere asegurarse de que los ingenieros de desarrollo y los miembros del equipo de control de calidad puedan obtener acceso a los recursos que necesitan. También necesita una estrategia que se escale a medida que su empresa crezca.

Puede elegir utilizar etiquetas de recursos de AWS y etiquetas principales de rol IAM para implementar una estrategia de ABAC para los servicios que la admitan, que comienzan por AWS Secrets Manager. Para saber qué servicios admiten la autorización basada en etiquetas, consulte Servicios de AWS que funcionan con IAM. Para obtener información sobre las claves de condición de etiquetado que pueden utilizarse en políticas con cada acción y recurso de servicio, consulte Acciones, recursos y claves de condición para servicios de AWS. Puede configurar su proveedor de identidad web o basado en SAML para que pase las etiquetas de sesión a AWS. Cuando los empleados se federan en AWS, sus atributos se aplican a su entidad principal resultante en AWS. Entonces puede utilizar ABAC para permitir o denegar permisos basados en esos atributos. Para saber cómo el uso de etiquetas de sesión con una identidad federada SAML difiere de este aprendizaje, consulte Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC.

Los miembros del equipo de ingeniería y control de calidad están en el proyecto Pegasus o Unicorn. Puede elegir los siguientes valores de etiqueta de equipo y proyecto de 3 caracteres:

• access-project = peg para el proyecto Pegasus

• access-project = uni para el proyecto Unicorn

• access-team = eng para el equipo de ingeniería

• access-team = qas para el equipo de control de calidad

Además, puede solicitar la etiqueta de asignación de costos cost-center para habilitar los informes de facturación personalizados de AWS. Para obtener más información, consulte Uso de etiquetas de asignación de costos en la Guía del usuario de AWS Billing and Cost Management.

Resumen de decisiones clave

• Los empleados inician sesión con las credenciales de usuario de IAM y, a continuación, asumen el rol de IAM para su equipo y proyecto. Si su empresa tiene su propio sistema de identidad, puede configurar la federación para permitir a los empleados asumir un rol sin usuarios de IAM. Para obtener más información, consulte Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC.

• La misma política se asocia a todos los roles. Las acciones se permiten o deniegan en función de las etiquetas.

• Los empleados pueden crear nuevos recursos, pero solo si asocian las mismas etiquetas al recurso que se aplica a su rol. Esto garantiza que los empleados puedan ver el recurso después de crearlo. Ya no es necesario que los administradores actualicen las políticas con el ARN de los nuevos recursos.

• Los empleados pueden leer los recursos que pertenecen a su equipo, independientemente del proyecto.

• Los empleados pueden actualizar y eliminar recursos propiedad de su propio equipo y proyecto.

• Los administradores de IAM pueden agregar un nuevo rol para nuevos proyectos. Pueden crear y etiquetar un nuevo usuario de IAM para permitir el acceso al rol adecuado. Los administradores no tienen que editar una política para admitir un nuevo proyecto o miembro del equipo.

En este tutorial, etiquetará cada recurso, etiquetará los roles del proyecto y añadirá políticas a los roles para permitir el comportamiento descrito anteriormente. La política resultante permite a los roles Create, Read, Update y Delete acceso a los recursos que están etiquetados con las mismas etiquetas de proyecto y equipo. La política también permite el acceso entre proyectos a Read para los recursos que están etiquetados con el mismo equipo.

Requisitos previos

Para realizar los pasos en este tutorial, deberá disponer de lo siguiente:

• Una Cuenta de AWS en la que puede iniciar sesión como usuario con permisos administrativos.

• Su ID de cuenta de 12 dígitos, que utilizará para crear los roles en el paso 3.

  Para encontrar el número de ID de cuenta de AWS mediante la AWS Management Console, seleccione Support (Soporte) en la barra de navegación en la parte superior derecha y, a continuación, elija Support Center (Centro de soporte). El número de cuenta (ID) aparece en el panel de navegación de la izquierda.

  

• Experimente creando y editando usuarios, roles y políticas de IAM en la AWS Management Console. Sin embargo, si necesita ayuda para recordar un proceso de administración de IAM, este tutorial proporciona enlaces en los que puede ver las instrucciones paso a paso.

Paso 1: crear usuarios de prueba

Para realizar pruebas, cree cuatro usuarios de IAM con permisos para asumir roles con las mismas etiquetas. Esto facilita añadir más usuarios a sus equipos. Al etiquetar los usuarios, estos obtienen acceso automáticamente para asumir el rol correcto. No es necesario agregar los usuarios a la política de confianza del rol si solo trabajan en un proyecto y en un equipo.

1. Cree la siguiente política administrada por el cliente denominada access-assume-role. Para obtener más información acerca de la creación de un política JSON, consulte Crear políticas de IAM.

   Política de ABAC: asume cualquier rol de ABAC, pero solo cuando coinciden las etiquetas de usuario y rol.

   La siguiente política permite a un usuario asumir cualquier rol de su cuenta con el prefijo de nombre access-. El rol también debe estar etiquetado con las mismas etiquetas de proyecto, equipo y centro de costos que el usuario.

   Para utilizar esta política, sustituya el texto del marcador de posición en cursiva por la información de la cuenta.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "TutorialAssumeRole",
               "Effect": "Allow",
               "Action": "sts:AssumeRole",
               "Resource": "arn:aws:iam::account-ID-without-hyphens:role/access-*",
               "Condition": {
                   "StringEquals": {
                       "iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
                       "iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
                       "iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
                   }
               }
           }
       ]
   }

   Para escalar este tutorial a un gran número de usuarios, puede asociar la política a un grupo y añadir cada usuario al grupo. Para obtener más información, consulte Creación de un grupo de usuarios de IAM y Agregar y eliminar usuarios de un grupo de usuarios de IAM.

2. Cree los siguientes usuarios de IAM, asocie la política de permisos access-assume-role. Asegúrese de seleccionar Conceder acceso de usuario a la AWS Management Console y, luego, agregue las siguientes etiquetas. Para obtener más información acerca de cómo crear y etiquetar un nuevo usuario, consulte Creación de usuarios de IAM (consola).

   Usuarios de ABAC
   Nombre de usuario	Clave de la etiqueta de usuario	Valor de la etiqueta de usuario
   access-Arnav-peg-eng	access-project access-team cost-center	peg eng 987654
   access-Mary-peg-qas	access-project access-team cost-center	peg qas 987654
   access-Saanvi-uni-eng	access-project access-team cost-center	uni eng 123456
   access-Carlos-uni-qas	access-project access-team cost-center	uni qas 123456

Paso 2: crear la política de ABAC

Cree la siguiente política con el nombre access-same-project-team. Añadirá esta política a los roles en un paso posterior. Para obtener más información acerca de la creación de un política JSON, consulte Crear políticas de IAM.

Para obtener más políticas que puede adaptar para este tutorial, consulte las siguientes páginas:

• Control del acceso para entidades principales de IAM

• Amazon EC2: permite iniciar o detener instancias EC2 que un usuario haya etiquetado, mediante programación y en la consola

• EC2: iniciar o detener instancias basándose en etiquetas de recursos y principal coincidentes

• EC2: iniciar o detener instancias en función de las etiquetas

• IAM: asumir funciones que tienen una etiqueta específica

Política de ABAC: acceso a los recursos de Secrets Manager solo cuando coinciden las etiquetas principal y de recursos

La siguiente política permite a las entidades principales crear, leer, editar y eliminar recursos, pero solo cuando dichos recursos están etiquetados con los mismos pares clave-valor que la entidad principal. Cuando una entidad principal crea un recurso, debe añadir etiquetas access-project, access-team y cost-center con valores que coincidan con las etiquetas de la entidad principal. La política también permite añadir etiquetas Name u OwnedBy opcionales.

{
 "Version": "2012-10-17",
 "Statement": [
     {
         "Sid": "AllActionsSecretsManagerSameProjectSameTeam",
         "Effect": "Allow",
         "Action": "secretsmanager:*",
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
                 "aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
             },
             "ForAllValues:StringEquals": {
                 "aws:TagKeys": [
                     "access-project",
                     "access-team",
                     "cost-center",
                     "Name",
                     "OwnedBy"
                 ]
             },
             "StringEqualsIfExists": {
                 "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
                 "aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
                 "aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
             }
         }
     },
     {
         "Sid": "AllResourcesSecretsManagerNoTags",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:GetRandomPassword",
             "secretsmanager:ListSecrets"
         ],
         "Resource": "*"
     },
     {
         "Sid": "ReadSecretsManagerSameTeam",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:Describe*",
             "secretsmanager:Get*",
             "secretsmanager:List*"
         ],
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
             }
         }
     },
     {
         "Sid": "DenyUntagSecretsManagerReservedTags",
         "Effect": "Deny",
         "Action": "secretsmanager:UntagResource",
         "Resource": "*",
         "Condition": {
             "ForAnyValue:StringLike": {
                 "aws:TagKeys": "access-*"
             }
         }
     },
     {
         "Sid": "DenyPermissionsManagement",
         "Effect": "Deny",
         "Action": "secretsmanager:*Policy",
         "Resource": "*"
     }
 ]
}

¿Qué hace esta política?

• La instrucción AllActionsSecretsManagerSameProjectSameTeam permite todas las acciones de este servicio en todos los recursos relacionados, pero solo si las etiquetas de los recursos coinciden con las etiquetas principales. Al agregar "Action": "secretsmanager:*" a la política, la política crece a medida que Secrets Manager crece. Si Secrets Manager añade una nueva operación de API, no es necesario que agregue dicha acción a la instrucción. La instrucción implementa el ABAC utilizando tres bloques de condición. La solicitud solo se permite si los tres bloques devuelven true.

  • El primer bloque de condición de esta instrucción devuelve true si las claves de etiqueta especificadas están presentes en el recurso y sus valores coinciden con las etiquetas de la entidad principal. Este bloque devuelve false para etiquetas no coincidentes o para acciones que no admiten el etiquetado de recursos. Para saber qué acciones no permite este bloque, consulte Claves de condición, recursos y acciones de AWS Secrets Manager. En dicha página se muestra que las acciones realizadas en el tipo de recurso Secret admiten la clave de condición secretsmanager:ResourceTag/tag-key. Algunas acciones de Secrets Manager no admiten ese tipo de recurso, incluidas GetRandomPassword y ListSecrets. Debe crear instrucciones adicionales para permitir esas acciones.

  • El segundo bloque de condición devuelve true si todas las claves de etiqueta pasadas en la solicitud se incluyen en la lista especificada. Esto se realiza utilizando ForAllValues con el operador de condición StringEquals. Si no se pasa ninguna clave ni subconjunto del conjunto de claves, la condición se vuelve verdadera. Esto permite operaciones Get* que no permiten pasar etiquetas en la solicitud. Si el solicitante incluye una clave de etiqueta que no está en la lista, la condición devuelve false. Cada clave de etiqueta que se transfiere en la solicitud debe coincidir con un miembro de esta lista. Para obtener más información, consulte Claves de contexto multivalor.

  • El tercer bloque de condición devuelve true si la solicitud admite la transferencia de etiquetas, si las tres etiquetas están presentes y si coinciden con los valores de etiqueta principal. Este bloque también devuelve true si la solicitud no admite la transferencia de etiquetas. Esto se debe a ...IfExists en el operador de condición. El bloque devuelve false si no se pasa ninguna etiqueta durante una acción que lo admite, o si las claves y los valores de la etiqueta no coinciden.

• La instrucción AllResourcesSecretsManagerNoTags permite las acciones ListSecrets y GetRandomPassword que la primera instrucción no permite.

• La instrucción ReadSecretsManagerSameTeam permite operaciones de solo lectura si la entidad principal está etiquetada con la misma etiqueta de equipo de acceso que el recurso. Esto está permitido independientemente del proyecto o de la etiqueta del centro de costos.

• La instrucción DenyUntagSecretsManagerReservedTags deniega las solicitudes para eliminar de Secrets Manager etiquetas con claves que comienzan por "access-". Estas etiquetas se utilizan para controlar el acceso a los recursos, por tanto, si se eliminan etiquetas se podrían eliminar permisos.

• La instrucción DenyPermissionsManagement deniega el acceso para crear, editar o eliminar políticas basadas en recursos de Secrets Manager. Estas políticas se pueden utilizar para cambiar los permisos del secreto.

importante

Esta política utiliza una estrategia para permitir todas las acciones de un servicio, pero deniega explícitamente las acciones de modificación de permisos. Si se deniega una acción, se anula cualquier otra política que permita a la entidad principal realizar dicha acción. Esto puede tener resultados no deseados. Como práctica recomendada, utilice denegaciones explícitas solo cuando no haya ninguna circunstancia que deba permitir dicha acción. De lo contrario, permita una lista de acciones individuales y las acciones no deseadas se deniegan de forma predeterminada.

Paso 3: crear roles

Cree los siguientes roles de IAM y asocie la política access-same-project-team creada en el paso anterior. Para obtener más información sobre cómo crear un rol de IAM, consulte Creación de un rol para delegar permisos a un usuario de IAM. Si decide utilizar la federación en lugar de usuarios y roles de IAM, consulte Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC.

Roles de ABAC
Función de trabajo	Nombre de rol	Etiquetas de roles	Descripción del rol
Ingeniería del proyecto Pegasus	access-peg-engineering	access-project = peg access-team = eng cost-center = 987654	Permite a los ingenieros leer todos los recursos de ingeniería y crear y administrar los recursos de ingeniería de Pegasus.
Control de calidad del proyecto Pegasus	access-peg-quality-assurance	access-project = peg access-team = qas cost-center = 987654	Permite al equipo de control de calidad leer todos los recursos de control de calidad y crear y administrar todos los recursos de control de calidad de Pegasus.
Ingeniería del proyecto Unicorn	access-uni-engineering	access-project = uni access-team = eng cost-center = 123456	Permite a los ingenieros leer todos los recursos de ingeniería y crear y administrar los recursos de ingeniería de Unicorn.
Control de calidad del proyecto Unicorn	access-uni-quality-assurance	access-project = uni access-team = qas cost-center = 123456	Permite al equipo de control de calidad leer todos los recursos de control de calidad y crear y administrar todos los recursos de control de calidad de Unicorn.

Paso 4: Probar la creación de secretos

La política de permisos asociada a los roles permite a los empleados crear secretos. Esto solo se permite si el secreto está etiquetado con su proyecto, equipo y centro de costos. Confirme que sus permisos funcionan según lo previsto iniciando sesión como usuarios, asumiendo el rol correcto y probando la actividad en Secrets Manager.

Para probar la creación de un secreto con y sin las etiquetas necesarias

1. En la ventana principal del navegador, mantenga la sesión iniciada como usuario administrador para que pueda revisar los usuarios, los roles y las políticas en IAM. Utilice una ventana de incógnito del navegador o un navegador independiente para las pruebas. Ahí, inicie sesión como usuario de IAM access-Arnav-peg-eng en la consola de Secrets Manager en https://console.aws.amazon.com/secretsmanager/.

2. Intente cambiar al rol access-uni-engineering.

   Esta operación falla porque los valores de la etiqueta access-project y cost-center no coinciden con el usuario access-Arnav-peg-eng y el rol access-uni-engineering.

   Para obtener más información acerca del cambio de roles en la AWS Management Console, consulte Cambio a un rol (Consola)

3. Cambie al rol access-peg-engineering.

4. Almacene un nuevo secreto con la siguiente información. Para obtener información sobre cómo almacenar un secreto, consulte Creación de un secreto básico en la Guía del usuario de AWS Secrets Manager.

   importante

   Secrets Manager muestra avisos indicando que no tiene permisos para servicios de AWS adicionales que funcionan con Secrets Manager. Por ejemplo, para crear credenciales para una base de datos de Amazon RDS, debe tener permiso para describir instancias de RDS, clústeres de RDS y clústeres de Amazon Redshift. Puede ignorar estas alertas, ya que en este tutorial no está utilizando estos servicios de AWS específicos.

   1. En la sección Select secret type (Seleccionar tipo de secreto), elija Other type of secrets (Otro tipo de secretos). En los dos cuadros de texto, escriba test-access-key y test-access-secret.

   2. Escriba test-access-peg-eng en el campo Secret name (Nombre del secreto).

   3. Añada diferentes combinaciones de etiquetas de la siguiente tabla y vea el comportamiento esperado.

   4. Elija Store (Almacenar) para intentar crear el secreto. Cuando se produzca un error en el almacenamiento, vuelva a las páginas de la consola de Secrets Manager anteriores y utilice el siguiente conjunto de etiquetas de la siguiente tabla. El último conjunto de etiquetas está permitido y creará correctamente el secreto.

   Combinaciones de etiquetas de ABAC para el rol test-access-peg-eng
   access-project Valor de etiqueta	access-team Valor de etiqueta	cost-center Valor de etiqueta	Etiquetas adicionales	Comportamiento esperado
   (ninguno)	(ninguno)	(ninguno)	(ninguno)	Se deniega porque el valor de la etiqueta access-project no coincide con el valor del rol de peg.
   uni	eng	987654	(ninguno)	Se deniega porque el valor de la etiqueta access-project no coincide con el valor del rol de peg.
   peg	qas	987654	(ninguno)	Se deniega porque el valor de la etiqueta access-team no coincide con el valor del rol de eng.
   peg	eng	123456	(ninguno)	Se deniega porque el valor de la etiqueta cost-center no coincide con el valor del rol de 987654.
   peg	eng	987654	owner = Jane	Se deniega porque la política no permite la etiqueta adicional owner, aunque las tres etiquetas obligatorias estén presentes y sus valores coincidan con los valores del rol.
   peg	eng	987654	Name = Jane	Se permite porque las tres etiquetas obligatorias están presentes y sus valores coinciden con los valores del rol. También puede incluir la etiqueta Name opcional.

5. Cierre la sesión y repita los tres primeros pasos de este procedimiento para cada uno de los siguientes roles y valores de etiqueta. En el cuarto paso de este procedimiento, pruebe cualquier conjunto de etiquetas que faltan, etiquetas opcionales, etiquetas no permitidas y valores de etiqueta no válidos que elija. A continuación, utilice las etiquetas necesarias para crear un secreto con las siguientes etiquetas y nombre.

   Roles y etiquetas de ABAC
   Nombre de usuario	Nombre de rol	Nombre del secreto	Etiquetas de secretos
   access-Mary-peg-qas	access-peg-quality-assurance	test-access-peg-qas	access-project = peg access-team = qas cost-center = 987654
   access-Saanvi-uni-eng	access-uni-engineering	test-access-uni-eng	access-project = uni access-team = eng cost-center = 123456
   access-Carlos-uni-qas	access-uni-quality-assurance	test-access-uni-qas	access-project = uni access-team = qas cost-center = 123456

Paso 5: Probar la visualización de secretos

La política que ha adjuntado a cada rol permite a los empleados ver cualquier secreto etiquetado con su nombre de equipo, independientemente de su proyecto. Confirme que sus permisos funcionan según lo previsto probando los roles en Secrets Manager.

Para probar la visualización de un secreto con y sin las etiquetas requeridas

1. Inicie sesión como uno de los siguientes usuarios de IAM:

   • access-Arnav-peg-eng

   • access-Mary-peg-qas

   • access-Saanvi-uni-eng

   • access-Carlos-uni-qas

2. Cambie al rol coincidente:

   • access-peg-engineering

   • access-peg-quality-assurance

   • access-uni-engineering

   • access-uni-quality-assurance

   Para obtener más información acerca del cambio de roles en la AWS Management Console, consulte Cambio a un rol (Consola).

3. En el panel de navegación de la izquierda, elija el icono de menú para ampliar el menú y, a continuación, elija Secrets (Secretos).

4. Debería ver los cuatro secretos en la tabla, independientemente del rol actual. Esto se espera porque la política con el nombre access-same-project-team permite la acción secretsmanager:ListSecrets para todos los recursos.

5. Elija el nombre de uno de los secretos.

6. En la página de detalles del secreto, las etiquetas de su rol determinan si puede ver el contenido de la página. Compare el nombre de su rol con el nombre de su secreto. Si comparten el mismo nombre de equipo, las etiquetas access-team coinciden. Si no coinciden, el acceso se deniega.

   Comportamiento de visualización de secretos de ABAC para cada rol
   Nombre de rol	Nombre del secreto	Comportamiento esperado
   access-peg-engineering	test-access-peg-eng	Permitida
   	test-access-peg-qas	Denegado
   	test-access-uni-eng	Permitida
   	test-access-uni-qas	Denegado
   access-peg-quality-assurance	test-access-peg-eng	Denegado
   	test-access-peg-qas	Permitida
   	test-access-uni-eng	Denegado
   	test-access-uni-qas	Permitida
   access-uni-engineering	test-access-peg-eng	Permitida
   	test-access-peg-qas	Denegado
   	test-access-uni-eng	Permitida
   	test-access-uni-qas	Denegado
   access-uni-quality-assurance	test-access-peg-eng	Denegado
   	test-access-peg-qas	Permitida
   	test-access-uni-eng	Denegado
   	test-access-uni-qas	Permitida

7. En la parte superior de la página, elija Secrets (Secretos) para volver a la lista de secretos. Repita los pasos de este procedimiento utilizando diferentes roles para probar si puede ver cada uno de los secretos.

Paso 6: Probar la escalabilidad

Un motivo importante para utilizar el control de acceso basado en atributos (ABAC) sobre el control de acceso basado en roles (RBAC) es la escalabilidad. A medida que su empresa añade nuevos proyectos, equipos o personas a AWS, no es necesario actualizar sus políticas basadas en ABAC. Por ejemplo, supongamos que la Empresa Ejemplo está financiando un nuevo proyecto, con un código con el nombre Centaur. Un ingeniero llamado Saanvi Sarkar será el ingeniero jefe de Centaur y continuará trabajando en el proyecto Unicorn . Saanvi también revisará el trabajo del proyecto Peg. También hay varios ingenieros recién contratados, incluido Nikhil Jayashankar, que trabajará solo en el proyecto Centaur.

Para añadir el nuevo proyecto a AWS

1. Inicie sesión como usuario administrador de IAM y abra la consola de IAM en https://console.aws.amazon.com/iam/.

2. En el panel de navegación de la izquierda, seleccione Roles y añada un rol de IAM con el nombre access-cen-engineering. Asocie la política de permisos access-same-project-team al rol y agregue las siguientes etiquetas de rol:

   • access-project = cen

   • access-team = eng

   • cost-center = 101010

3. En el panel de navegación de la izquierda, elija Usuarios.

4. Agregue un nuevo usuario denominado access-Nikhil-cen-eng, asocie la política denominada access-assume-role y agregue las siguientes etiquetas de usuario.

   • access-project = cen

   • access-team = eng

   • cost-center = 101010

5. Utilice los procedimientos de Paso 4: Probar la creación de secretos y Paso 5: Probar la visualización de secretos. En otra ventana del navegador, pruebe que Nikhil solo puede crear secretos de ingeniería de Centaur y que puede ver todos los secretos de ingeniería.

6. En la ventana principal del navegador en la que ha iniciado sesión como administrador, elija el usuario access-Saanvi-uni-eng.

7. En la pestaña Permissions (Permisos ), elimine la política de permisos access-assume-role.

8. Añada la siguiente política insertada denominada access-assume-specific-roles. Para obtener más información acerca de cómo añadir una política insertada a un usuario, consulte Para integrar una política insertada de un usuario o un rol (consola).

   Política de ABAC: asumir solo roles específicos

   Esta política permite a Saanvi asumir los roles de ingeniería de los proyectos Pegasus y Centaur. Es necesario crear esta política personalizada porque IAM no admite etiquetas con varios valores. No puede etiquetar al usuario de Saanvi con access-project = peg y access-project = cen. Además, el modelo de autorización de AWS no puede coincidir con ambos valores. Para obtener más información, consulte Reglas para etiquetar en IAM y AWS STS. En su lugar, debe especificar manualmente los dos roles que puede asumir.

   Para utilizar esta política, sustituya el texto del marcador de posición en cursiva por la información de la cuenta.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "TutorialAssumeSpecificRoles",
               "Effect": "Allow",
               "Action": "sts:AssumeRole",
               "Resource": [
                   "arn:aws:iam::account-ID-without-hyphens:role/access-peg-engineering",
                   "arn:aws:iam::account-ID-without-hyphens:role/access-cen-engineering"
               ]
           }
       ]
   }

9. Utilice los procedimientos de Paso 4: Probar la creación de secretos y Paso 5: Probar la visualización de secretos. En otra ventana del navegador, confirme que Saanvi puede asumir ambos roles. Compruebe que solo puede crear secretos para su proyecto, equipo y centro de costos, en función de las etiquetas del rol. Confirme también que puede ver detalles sobre cualquier secreto propiedad del equipo de ingeniería, incluidos los que acaba de crear.

Paso 7: Probar la actualización y eliminación de secretos

La política access-same-project-team asociada a los roles permite a los empleados actualizar y eliminar los secretos etiquetados con su proyecto, equipo y centro de costos. Confirme que sus permisos funcionan según lo previsto probando los roles en Secrets Manager.

Para probar la actualización y eliminación de un secreto con y sin las etiquetas requeridas

1. Inicie sesión como uno de los siguientes usuarios de IAM:

   • access-Arnav-peg-eng

   • access-Mary-peg-qas

   • access-Saanvi-uni-eng

   • access-Carlos-uni-qas

   • access-Nikhil-cen-eng

2. Cambie al rol coincidente:

   • access-peg-engineering

   • access-peg-quality-assurance

   • access-uni-engineering

   • access-peg-quality-assurance

   • access-cen-engineering

   Para obtener más información acerca del cambio de roles en la AWS Management Console, consulte Cambio a un rol (Consola).

3. Para cada rol, intente actualizar la descripción del secreto y, a continuación, intente eliminar los siguientes secretos. Para obtener más información, consulte Modificación de un secreto y Eliminación y restauración de un secreto en la Guía del usuario de AWS Secrets Manager.

   Comportamiento de actualización y eliminación de secretos de ABAC para cada rol
   Nombre de rol	Nombre del secreto	Comportamiento esperado
   access-peg-engineering	test-access-peg-eng	Permitida
   	test-access-uni-eng	Denegado
   	test-access-uni-qas	Denegado
   access-peg-quality-assurance	test-access-peg-qas	Permitida
   	test-access-uni-eng	Denegado
   access-uni-engineering	test-access-uni-eng	Permitida
   	test-access-uni-qas	Denegado
   access-peg-quality-assurance	test-access-uni-qas	Permitida

Resumen

Ha completado correctamente todos los pasos necesarios para utilizar etiquetas para el control de acceso basado en atributos (ABAC). Ha aprendido a definir una estrategia de etiquetado. Ha aplicado dicha estrategia a sus entidades principales y recursos. Ha creado y aplicado una política que aplica la estrategia para Secrets Manager. También ha aprendido que ABAC se escala fácilmente cuando añade nuevos proyectos y miembros del equipo. Como resultado, puede iniciar sesión en la consola de IAM con sus roles de prueba y experimentar cómo utilizar etiquetas para ABAC en AWS.

nota

Ha agregado políticas que permiten acciones solo en determinadas condiciones. Si aplica una política diferente a los usuarios o roles que tiene permisos más amplios, es posible que las acciones no se limiten a requerir el etiquetado. Por ejemplo, si concede a un usuario permisos administrativos completos mediante la política administrada por AWS AdministratorAccess, estas políticas no restringen ese acceso. Para obtener más información acerca de cómo se determinan los permisos cuando se aplican varias políticas, consulte Cómo determinar si se una solicitud se permite o se deniega dentro de una cuenta.

Recursos relacionados

Para obtener información relacionada, consulte los recursos siguientes:

• ¿Qué es ABAC para AWS?

• Claves de contexto de condición globales de AWS

• Creación de usuarios de IAM (consola)

• Creación de un rol para delegar permisos a un usuario de IAM

• Etiquetado de recursos de IAM

• Control de acceso a los recursos de AWS mediante etiquetas

• Cambio a un rol (Consola)

• Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC

Para obtener información sobre cómo monitorear las etiquetas en su cuenta, consulte Monitorear los cambios de etiquetas en recursos de AWS con flujos de trabajo sin servidor y Amazon CloudWatch Events.