SEC02-BP06 Uso de grupos y atributos de usuarios - Marco de AWS Well-Architected
Guía para la implementaciónRecursos

SEC02-BP06 Uso de grupos y atributos de usuarios

Definir los permisos según los grupos y los atributos de usuarios ayuda a reducir la cantidad y la complejidad de las políticas, lo que facilita la aplicación del principio de privilegio mínimo. Puede emplear los grupos de usuarios para administrar los permisos de muchas personas en un solo lugar según la función que desempeñen en su organización. Los atributos, como el departamento, el proyecto o la ubicación, pueden proporcionar un nivel adicional en el ámbito de los permisos si hay personas que hacen una función similar, pero para diferentes subconjuntos de recursos.

Resultado deseado: puede aplicar cambios en los permisos según la función a todos los usuarios que desempeñen esa función. La pertenencia a grupos y los atributos determinan los permisos de los usuarios, lo que reduce la necesidad de administrar los permisos para cada usuario individual. Los grupos y atributos que defina en su proveedor de identidades (IdP) se propagan automáticamente a sus entornos de AWS.

Patrones comunes de uso no recomendados:

  • Administrar los permisos de usuarios individuales y duplicarlos para muchos usuarios.

  • Definir grupos en un nivel demasiado alto y conceder permisos demasiado amplios.

  • Definir grupos en un nivel demasiado detallado, lo que crea duplicación y confusión en torno a la pertenencia a dichos grupos.

  • Usar grupos con permisos duplicados en diversos subconjuntos de recursos cuando, en su lugar, se pueden usar atributos.

  • No administrar grupos, atributos y pertenencias a grupos con un proveedor de identidades estandarizado integrado con sus entornos de AWS.

  • Usar encadenamiento de roles al utilizar las sesiones del AWS IAM Identity Center.

Nivel de riesgo expuesto si no se establece esta práctica recomendada: medio

Guía para la implementación

Los permisos de AWS se definen en documentos denominados políticas que están asociados a una entidad principal, como un usuario, grupo, rol o recurso. Puede escalar la gestión de permisos organizando las asignaciones de permisos (grupo, permisos o cuenta) dependiendo de la función del trabajo, la carga de trabajo y el entorno de SDLC. En el caso de su plantilla, esto le permite definir grupos según la función que desempeñen los usuarios en su organización, en lugar de en virtud de los recursos a los que se accede. Por ejemplo, un grupo de desarrolladores de aplicaciones web puede tener una política adjunta para configurar servicios como Amazon CloudFront dentro de una cuenta de desarrollo. Es posible que un grupo de AutomationDeveloper tenga algunos permisos que coincidan con los del grupo de WebAppDeveloper. Estos permisos pueden recopilarse en una política independiente y asociarse a ambos grupos, en lugar de permitir que los usuarios de ambas funciones pertenezcan a un grupo de CloudFrontAccess.

Además de los grupos, puede utilizar atributos para ampliar el acceso al ámbito. Por ejemplo, puede tener un atributo Proyecto para los usuarios del grupo de WebAppDeveloper para limitar el acceso a los recursos específicos de su proyecto. El uso de esta técnica elimina la necesidad de tener diferentes grupos para los desarrolladores de aplicaciones que trabajen en diferentes proyectos si, por lo demás, sus permisos son los mismos. La forma de hacer referencia a los atributos en las políticas de permisos se basa en su origen, ya sea que estén definidos como parte de su protocolo de federación (como SAML, OIDC o SCIM), como aserciones SAML personalizadas o que se hayan configurado en IAM Identity Center.

Pasos para la implementación

  1. Establezca dónde definirá los grupos y los atributos:

    1. Al seguir las instrucciones que se indican en SEC02-BP04 Uso de un proveedor de identidades centralizado, puede determinar si tiene que definir grupos y atributos en el proveedor de identidades, en IAM Identity Center o usar grupos de usuarios de IAM en una cuenta específica.

  2. Defina grupos:

    1. Determine los grupos según la función y el ámbito del acceso requerido. Puede utilizar una estructura jerárquica o convenciones de nomenclatura para organizar los grupos de forma eficaz.

    2. Si especifica la definición en IAM Identity Center, cree grupos y asocie el nivel de acceso deseado mediante conjuntos de permisos.

    3. Si especifica la definición con un proveedor de identidades externo, determine si el proveedor admite el protocolo SCIM y plantéese la posibilidad de habilitar el aprovisionamiento automático en IAM Identity Center. Esta capacidad sincroniza la creación, la pertenencia y la eliminación de grupos entre su proveedor e IAM Identity Center.

  3. Defina los atributos:

    1. Si utiliza un proveedor de identidades externo, los protocolos SCIM y SAML 2.0 proporcionan ciertos atributos de forma predeterminada. Los atributos adicionales se pueden definir y transferir mediante aserciones de SAML que utilizan el nombre del atributo https://aws.amazon.com/SAML/Attributes/PrincipalTag. Consulte la documentación de su proveedor de identidades a fin de conocer las instrucciones necesarias para definir y configurar atributos personalizados.

    2. Si define roles en IAM Identity Center, active la característica de control de acceso basado en atributos (ABAC) y defina los atributos como desee. Debería usar atributos que vayan en consonancia con la estructura o la estrategia de etiquetado de recursos de su organización.

Si necesita encadenar los roles de IAM a partir de los roles de IAM asumidos a través del centro de identidad de IAM, los valores como source-identity y principal-tags no se propagarán. Para obtener información más detallada, consulte Habilitación y configuración de atributos para el control de acceso.

  1. Los permisos de ámbito se basan en grupos y atributos:

    1. Plantéese la posibilidad de incluir condiciones en las políticas de permisos que comparen los atributos de su entidad principal con los atributos de los recursos a los que se accede. Por ejemplo, puede definir una condición para permitir el acceso a un recurso solo si el valor de una clave de condición PrincipalTag coincide con el valor de una clave ResourceTag del mismo nombre.

    2. Al definir las políticas de la ABAC, siga las instrucciones de las prácticas recomendadas y ejemplos de autorización de la ABAC.

    3. Revise y actualice periódicamente su estructura de grupos y atributos a medida que evolucionen las necesidades de su organización para garantizar una gestión óptima de los permisos.

Recursos

Prácticas recomendadas relacionadas:

Documentos relacionados:

Videos relacionados: