# 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 [Definición de permisos en función de los atributos con la autorización de ABAC](introduction_attribute-based-access-control.md). **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. **Topics** + [ ## Información general del tutorial ](#tutorial_attribute-based-access-control-overview) + [ ## Requisitos previos ](#tutorial_abac_prereqs) + [ ## Paso 1: crear usuarios de prueba ](#tutorial_abac_step1) + [ ## Paso 2: crear la política de ABAC ](#tutorial_abac_step2) + [ ## Paso 3: crear roles ](#tutorial_abac_step3) + [ ## Paso 4: Probar la creación de secretos ](#tutorial_abac_step4) + [ ## Paso 5: Probar la visualización de secretos ](#tutorial_abac_step5) + [ ## Paso 6: Probar la escalabilidad ](#tutorial_abac_step6) + [ ## Paso 7: Probar la actualización y eliminación de secretos ](#tutorial_abac_step7) + [ ## Resumen ](#tutorial-abac-summary) + [ ## Recursos relacionados ](#tutorial_abac_related) + [ # Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC ](tutorial_abac-saml.md) ## 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](reference_aws-services-that-work-with-iam.md). 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](reference_policies_actions-resources-contextkeys.html). Puede configurar su proveedor de identidad web o basado en SAML para que pase las [etiquetas de sesión](id_session-tags.md) 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](tutorial_abac-saml.md). 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](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) en la *Guía del usuario de Administración de facturación y costos de AWS*. **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](tutorial_abac-saml.md). + 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. ![\[En el diagrama, se muestran dos proyectos en los que los roles están limitados al acceso de solo lectura fuera del proyecto, mientras que tienen permisos para crear, leer, actualizar y eliminar recursos en su propio proyecto.\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png) ## 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 Consola de administración de AWS, 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. ![\[Página central de Soporte que muestra el número de cuenta.\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/account-id-support-center.console.png) + Experimente creando y editando usuarios, roles y políticas de IAM en la Consola de administración de AWS. 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](access_policies_create-console.md#access_policies_create-start). **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. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333: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 grupos de IAM](id_groups_create.md) y [Edición de usuarios de grupos de IAM](id_groups_manage_add-remove-users.md). 1. 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 Consola de administración de AWS** y, luego, agregue las siguientes etiquetas. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## 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](access_policies_create-console.md#access_policies_create-start). 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](access_iam-tags.md#access_iam-tags_control-principals) + [Amazon EC2: permite iniciar o detener instancias EC2 que un usuario haya etiquetado, mediante programación y en la consola](reference_policies_examples_ec2_tag-owner.md) + [EC2: iniciar o detener instancias basándose en etiquetas de recursos y principal coincidentes](reference_policies_examples_ec2-start-stop-match-tags.md) + [EC2: iniciar o detener instancias en función de las etiquetas](reference_policies_examples_ec2-start-stop-tags.md) + [IAM: asumir funciones que tienen una etiqueta específica](reference_policies_examples_iam-assume-tagged-role.md) **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. ------ #### [ JSON ] **** ``` { "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](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html). En dicha página se muestra que las acciones realizadas en el tipo de recurso [https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies) admiten la clave de condición `secretsmanager:ResourceTag/tag-key`. Algunas [acciones de Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions) 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 [Operadores de conjunto para claves de contexto multivalor](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys). + 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`](reference_policies_elements_condition_operators.md#Conditions_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 `GetRandomPassword` y `ListSecrets` 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](id_roles_create_for-user.md). 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](tutorial_abac-saml.md). | 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/](https://console.aws.amazon.com/secretsmanager/). 1. 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 Consola de administración de AWS, consulte [Cambiar de usuario a rol de IAM (consola)](id_roles_use_switch-role-console.md) 1. Cambie al rol `access-peg-engineering`. 1. 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](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) 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`. 1. Escriba `test-access-peg-eng` en el campo **Secret name (Nombre del secreto)**. 1. Añada diferentes combinaciones de etiquetas de la siguiente tabla y vea el comportamiento esperado. 1. 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. En la siguiente tabla, se muestra las combinaciones de etiquetas ABAC para el rol `test-access-peg-eng`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## 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` 1. 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 Consola de administración de AWS, consulte [Cambiar de usuario a rol de IAM (consola)](id_roles_use_switch-role-console.md). 1. 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)**. 1. 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. 1. Elija el nombre de uno de los secretos. 1. 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. En la siguiente tabla, se muestra el comportamiento de visualización de secretos de ABAC para cada rol. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. 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/](https://console.aws.amazon.com/iam/). 1. 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` 1. En el panel de navegación de la izquierda, elija **Usuarios**. 1. 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` 1. Utilice los procedimientos de [Paso 4: Probar la creación de secretos](#tutorial_abac_step4) y [Paso 5: Probar la visualización de secretos](#tutorial_abac_step5). 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. 1. En la ventana principal del navegador en la que ha iniciado sesión como administrador, elija el usuario `access-Saanvi-uni-eng`. 1. En la pestaña **Permissions (Permisos )**, elimine la política de permisos **access-assume-role**. 1. 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)](access_policies_manage-attach-detach.md#embed-inline-policy-console). **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](id_tags.md#id_tags_rules). 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. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeSpecificRoles", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/access-peg-engineering", "arn:aws:iam::111122223333:role/access-cen-engineering" ] } ] } ``` ------ 1. Utilice los procedimientos de [Paso 4: Probar la creación de secretos](#tutorial_abac_step4) y [Paso 5: Probar la visualización de secretos](#tutorial_abac_step5). 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` 1. 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 Consola de administración de AWS, consulte [Cambiar de usuario a rol de IAM (consola)](id_roles_use_switch-role-console.md). 1. 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](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html) y [Eliminación y restauración de un secreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html) en la *Guía del usuario de AWS Secrets Manager*. En la siguiente tabla, se muestra el comportamiento de actualización y eliminación de secretos de ABAC para cada rol. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## 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 `AdministratorAccess` AWS, 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 la lógica del código de aplicación de AWS evalúa las solicitudes para permitir o denegar el acceso](reference_policies_evaluation-logic_policy-eval-denyallow.md). ## Recursos relacionados Para obtener información relacionada, consulte los recursos siguientes: + [Definición de permisos en función de los atributos con la autorización de ABAC](introduction_attribute-based-access-control.md) + [Claves de contexto de condición globales de AWS](reference_policies_condition-keys.md) + [Creación de un rol para delegar permisos a un usuario de IAM](id_roles_create_for-user.md) + [Etiquetas para recursos de AWS Identity and Access Management](id_tags.md) + [Control de acceso a los recursos de AWS mediante etiquetas](access_tags.md) + [Cambiar de usuario a rol de IAM (consola)](id_roles_use_switch-role-console.md) + [Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC](tutorial_abac-saml.md) 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](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/). # Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC 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. Cuando las entidades se utilizan para realizar solicitudes de AWS, se convierten en entidades principales y esas entidades incluyen etiquetas. También puede pasar [etiquetas de sesión](id_session-tags.md) al asumir un rol o federar un usuario. A continuación, 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 [Definición de permisos en función de los atributos con la autorización de ABAC](introduction_attribute-based-access-control.md). Si su empresa utiliza un proveedor de identidades (IdP) basado en SAML para administrar las identidades de usuarios corporativos, puede utilizar atributos SAML para un control de acceso detallado en AWS. Los atributos pueden incluir identificadores de centros de coste, direcciones de correo electrónico de usuario, clasificaciones de departamento y asignaciones de proyectos. Cuando pasa estos atributos como etiquetas de sesión, puede controlar el acceso a AWS basándose en estas etiquetas de sesión. Para completar el [tutorial de ABAC](tutorial_attribute-based-access-control.md) pasando atributos de SAML a su sesión principal, complete las tareas de [Tutorial de IAM: definición de permisos para acceder a los recursos de AWS en función de etiquetas](tutorial_attribute-based-access-control.md), con los cambios que se incluyen en este tema. ## Requisitos previos Para realizar los pasos necesarios para utilizar las etiquetas de sesión de SAML para ABAC, ya debe tener lo siguiente: + Acceso a un IdP basado en SAML donde puede crear usuarios de prueba con atributos específicos. + La posibilidad de iniciar sesión como usuario con permisos administrativos. + Experimente creando y editando usuarios, roles y políticas de IAM en la Consola de administración de AWS. Sin embargo, si necesita ayuda para recordar un proceso de administración de IAM, el tutorial de ABAC proporciona enlaces en los que puede ver las instrucciones paso a paso. + Experimenta la configuración de un IdP basado en SAML en IAM. Para ver más detalles y vínculos a documentación detallada de IAM, consulte [Traspaso de etiquetas de sesión mediante AssumeRoleWithSAML](id_session-tags.md#id_session-tags_adding-assume-role-saml). ## Paso 1: crear usuarios de prueba Omita las instrucciones en [Paso 1: crear usuarios de prueba](tutorial_attribute-based-access-control.md#tutorial_abac_step1). Dado que sus identidades están definidas en su proveedor, no es necesario que agregue usuarios de IAM para sus empleados. ## Paso 2: crear la política de ABAC Siga las instrucciones de [Paso 2: crear la política de ABAC](tutorial_attribute-based-access-control.md#tutorial_abac_step2) para crear la política administrada especificada en IAM. ## Paso 3: crear y configurar el rol de SAML Cuando utilice el aprendizaje de ABAC para SAML, debe realizar pasos adicionales para crear el rol, configurar el IdP de SAML y habilitar el acceso a la Consola de administración de AWS. Para obtener más información, consulte [Paso 3: crear roles](tutorial_attribute-based-access-control.md#tutorial_abac_step3). ### Paso 3A: crear el rol de SAML Cree un único rol que confíe en el proveedor de identidades de SAML y en el usuario `test-session-tags` que creó en el paso 1. El tutorial de ABAC utiliza roles independientes con etiquetas de rol diferentes. Dado que está pasando etiquetas de sesión desde su IdP de SAML, solo necesita un rol. Para obtener información sobre cómo crear un rol basado en SAML, consulte [Creación de un rol para una federación SAML 2.0 (consola)](id_roles_create_for-idp_saml.md). Llame al rol `access-session-tags`. Asocie una política de permisos `access-same-project-team` al rol. Edite la política de confianza del rol para utilizar la siguiente política. Para obtener instrucciones detalladas sobre cómo editar la relación de confianza de un rol, consulte [Actualizar una política de confianza de rol](id_roles_update-role-trust-policy.md). La siguiente política de confianza del rol permite que el proveedor de identidad de SAML y el usuario `test-session-tags` asuman el rol. Cuando asumen el rol, deben pasar las tres etiquetas de sesión especificadas. La acción `sts:TagSession` es necesaria para permitir pasar etiquetas de sesión. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowSamlIdentityAssumeRole", "Effect": "Allow", "Action": [ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"}, "Condition": { "StringLike": { "aws:RequestTag/cost-center": "*", "aws:RequestTag/access-project": "*", "aws:RequestTag/access-team": [ "eng", "qas" ] }, "StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"} } } ] } ``` ------ La instrucción `AllowSamlIdentityAssumeRole` permite a los miembros de los equipos de Ingeniería y Garantía de Calidad asumir este rol cuando se federan en AWS desde el IdP de Example Corporation. El proveedor `ExampleCorpProvider` de SAML se define en IAM. El administrador ya ha configurado la aserción de SAML para pasar las tres etiquetas de sesión requeridas. La aserción puede pasar etiquetas adicionales, pero estos tres deben estar presentes. Los atributos de la identidad pueden tener cualquier valor para las etiquetas `cost-center` y `access-project`. Sin embargo, el valor del atributo `access-team` debe coincidir con `eng` o `qas` para indicar que la identidad está en el equipo de ingeniería o control de calidad. ### Paso 3B: configurar el IdP de SAML Configure su IdP de SAML para que pase los atributos `cost-center`, `access-project` y `access-team` como etiquetas de sesión. Para obtener más información, consulte [Traspaso de etiquetas de sesión mediante AssumeRoleWithSAML](id_session-tags.md#id_session-tags_adding-assume-role-saml). Para pasar estos atributos como etiquetas de sesión, incluya los siguientes elementos en su aserción de SAML. ``` 987654 peg eng ``` ### Paso 3C: Habilitar el acceso a la consola Habilite el acceso a la consola para los usuarios federados de SAML. Para obtener más información, consulte [Concesión de acceso a la Consola de administración de AWS a las entidades principales federadas de SAML 2.0](id_roles_providers_enable-console-saml.md). ## Paso 4: Probar la creación de secretos Federarse en la Consola de administración de AWS mediante el rol `access-session-tags`. Para obtener más información, consulte [Concesión de acceso a la Consola de administración de AWS a las entidades principales federadas de SAML 2.0](id_roles_providers_enable-console-saml.md). A continuación, siga las instrucciones de [Paso 4: Probar la creación de secretos](tutorial_attribute-based-access-control.md#tutorial_abac_step4) para crear secretos. Utilice diferentes identidades de SAML con atributos para que coincidan con las etiquetas indicadas en el tutorial de ABAC. Para obtener más información, consulte [Paso 4: Probar la creación de secretos](tutorial_attribute-based-access-control.md#tutorial_abac_step4). ## Paso 5: Probar la visualización de secretos Siga las instrucciones de [Paso 5: Probar la visualización de secretos](tutorial_attribute-based-access-control.md#tutorial_abac_step5) para ver los secretos que creó en el paso anterior. Utilice diferentes identidades de SAML con atributos para que coincidan con las etiquetas indicadas en el tutorial de ABAC. ## Paso 6: Probar la escalabilidad Siga las instrucciones de [Paso 6: Probar la escalabilidad](tutorial_attribute-based-access-control.md#tutorial_abac_step6) para probar la escalabilidad. Para ello, agregue una nueva identidad en su IdP basado en SAML con los siguientes atributos: + `cost-center = 101010` + `access-project = cen` + `access-team = eng` ## Paso 7: Probar la actualización y eliminación de secretos Siga las instrucciones de [Paso 7: Probar la actualización y eliminación de secretos](tutorial_attribute-based-access-control.md#tutorial_abac_step7) para actualizar y eliminar secretos. Utilice diferentes identidades de SAML con atributos para que coincidan con las etiquetas indicadas en el tutorial de ABAC. **importante** Elimine todos los secretos que ha creado para evitar cargos de facturación. Para obtener más información sobre los precios de Secrets Manager, consulte [Precios de AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/). ## Resumen Ahora ha completado correctamente todos los pasos necesarios para utilizar etiquetas de sesión y etiquetas de recursos de SAML para la administración de permisos. **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 `AdministratorAccess` AWS, 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 la lógica del código de aplicación de AWS evalúa las solicitudes para permitir o denegar el acceso](reference_policies_evaluation-logic_policy-eval-denyallow.md).