Definir permisos en función de los atributos con la autorización de ABAC - AWS Identity and Access Management

Definir permisos en función de los atributos con la autorización de ABAC

El control de acceso basado en atributos (ABAC) es una estrategia de autorización que define los permisos en función de atributos. AWS denomina a estos atributos etiquetas. Puede asociar etiquetas a recursos de IAM, tales como entidades de IAM (usuarios de IAM o roles de IAM) y recursos de AWS. Puede crear una única política ABAC o un conjunto pequeño de políticas para sus entidades principales de IAM. Puede diseñar políticas de ABAC que permitan operaciones cuando la etiqueta de la entidad principal coincida con la etiqueta del recurso. El sistema de atributos de ABAC proporciona un alto contexto de usuario y un control de acceso detallado. Debido a que ABAC se basa en atributos, puede realizar autorizaciones dinámicas para datos o aplicaciones que conceden o revocan el acceso en tiempo real. ABAC es útil en entornos que se encuentran en proceso de escalado y en situaciones donde la gestión de políticas de identidad o recursos se ha vuelto compleja.

Por ejemplo, puede crear tres roles de IAM con la clave de etiqueta access-project. Establezca el valor de etiqueta del primer rol de IAM en Heart, el segundo en Star y el tercero en Lightning. A continuación, puede utilizar una única política que permita el acceso cuando el rol de IAM y el recurso de AWS tengan el valor de etiqueta access-project. Para ver un tutorial detallado que muestra cómo utilizar ABAC en AWS, consulte Tutorial de IAM: definición de permisos para acceder a los recursos de AWS en función de etiquetas. Para obtener información sobre los servicios que respaldan a ABAC, consulte Servicios de AWS que funcionan con IAM.

En este diagrama, se ilustra que las etiquetas aplicadas a una entidad principal deben coincidir con las etiquetas aplicadas a un recurso para que se concedan permisos al usuario a efectos de acceder al recurso. Las etiquetas pueden aplicarse a grupos de usuarios, grupos de recursos, usuarios individuales y recursos individuales.

Comparación de ABAC con el modelo RBAC tradicional

El modelo de autorización tradicional utilizado en IAM es el control de acceso basado en roles (RBAC). RBAC asigna permisos según la función de trabajo o el rol de una persona, lo cual es diferente de un rol de IAM. IAM sí incluye políticas administradas para funciones de trabajo que alinean los permisos a una función de trabajo en un modelo RBAC.

En IAM, implemente RBAC creando diferentes políticas para diferentes funciones de trabajo. A continuación, asocie las políticas a identidades (usuarios de IAM, grupos de IAM o roles de IAM). Como práctica recomendada, debe conceder los permisos mínimos necesarios para la función de trabajo. Esto da como resultado un acceso con privilegios mínimos. Cada política de función de trabajo enumera los recursos específicos a los que pueden acceder las identidades asignadas a esa política. La desventaja de utilizar el modelo RBAC tradicional es que, cuando usted o sus usuarios agregan nuevos recursos al entorno, debe actualizar las políticas para permitir el acceso a esos recursos.

Por ejemplo, suponga que tiene tres proyectos, denominados Heart, Star y Lightning, en los que trabajan los empleados. Puede crear un rol de IAM para cada proyecto. A continuación, asocie políticas a cada rol de IAM para definir los recursos a los que puede acceder cualquier persona que tenga permiso para asumir el rol de IAM. Si un empleado cambia de trabajo dentro de su empresa, usted les asigna un rol de IAM diferente. Puede asignar personas o programas a más de un rol de IAM. Sin embargo, el proyecto Star puede requerir recursos adicionales, como un nuevo contenedor de Amazon EC2. En ese caso, debe actualizar la política adjunta al rol de IAM Star para especificar el nuevo recurso de contenedor. De lo contrario, los miembros del proyecto Star no pueden obtener acceso al nuevo contenedor.

En este diagrama, se ilustra que el control de acceso basado en roles requiere que cada identidad sea asignada a una política específica de función de trabajo para acceder a diferentes recursos.
ABAC ofrece las siguientes ventajas con respecto al modelo RBAC tradicional:
  • Los permisos ABAC se escalan con innovación. Ya no es necesario que un administrador actualice las políticas existentes para permitir el acceso a nuevos recursos. Por ejemplo, suponga que ha diseñado su estrategia ABAC con la etiqueta access-project. Un desarrollador utiliza el rol de IAM con la etiqueta access-project = Heart. Cuando las personas del proyecto Heart necesitan recursos de Amazon EC2 adicionales, el desarrollador puede crear nuevas instancias Amazon EC2 con la etiqueta access-project = Heart. A continuación, cualquier persona en el proyecto Heart puede iniciar y detener esas instancias porque sus valores de etiqueta coinciden.

  • ABAC requiere menos políticas. Dado que no tiene que crear diferentes políticas para diferentes funciones de trabajo, debe crear menos políticas. Estas políticas son más fáciles de administrar.

  • Con ABAC, los equipos pueden responder de manera dinámica a los cambios y al crecimiento. Como los permisos para nuevos recursos se conceden en forma automática en función de los atributos, no es necesario asignar políticas a las identidades de forma manual. Por ejemplo, si su empresa ya admite los proyectos Heart y Star con ABAC, es fácil añadir un nuevo proyecto Lightning. Un administrador de IAM crea un nuevo rol de IAM con la etiqueta access-project = Lightning. No es necesario cambiar la política para admitir un nuevo proyecto. Cualquier persona que tenga permisos para asumir el rol de IAM puede crear y ver instancias etiquetadas con access-project = Lightning. Otro caso es cuando un miembro del equipo pasa del proyecto Heart al proyecto Lightning. Para permitir que los miembros del equipo accedan al proyecto Lightning, el administrador de IAM les asigna un rol de IAM diferente. No es necesario cambiar las políticas de permisos.

  • Los permisos granulares son posibles con ABAC. Al crear políticas, se recomienda conceder privilegios mínimos. Con el RBAC tradicional, se redacta una política que permite el acceso a recursos específicos. Sin embargo, al utilizar ABAC, se pueden permitir acciones en todos los recursos si la etiqueta del recurso coincide con la etiqueta de la entidad principal.

  • Utilice los atributos de los empleados de su directorio corporativo con ABAC. Puede configurar su proveedor SAML u OIDC para que envíe etiquetas de sesión a IAM. Cuando sus empleados se federan en AWS, IAM aplica sus atributos a la entidad principal resultante. Entonces puede utilizar ABAC para permitir o denegar permisos basados en esos atributos.

Para ver un tutorial detallado que muestra cómo utilizar ABAC en AWS, consulte Tutorial de IAM: definición de permisos para acceder a los recursos de AWS en función de etiquetas.