¿Qué es ABAC para AWS? - AWS Identity and Access Management

¿Qué es ABAC para AWS?

El control de acceso basado en atributos (ABAC) es una estrategia de autorización que define permisos basados en atributos. En AWS, estos atributos se denominan etiquetas. Las etiquetas se pueden asociar a entidades principales de IAM (usuarios o roles) y a recursos de AWS. Puede crear una única política ABAC o un conjunto pequeño de políticas para sus entidades principales de IAM. Estas políticas ABAC se pueden diseñar para permitir operaciones cuando la etiqueta de la entidad principal coincida con la etiqueta del recurso. ABAC es útil en entornos que están creciendo rápidamente y ayuda con situaciones en las que la administración de políticas resulta engorrosa.

Por ejemplo, puede crear tres roles con la clave de etiqueta access-project. Establezca el valor de etiqueta del primer rol en Heart, el segundo en Lightning y el tercero en Sun. A continuación, puede utilizar una única política que permita el acceso cuando el rol y el recurso estén etiquetados con el mismo valor para access-project. Para ver un tutorial detallado que muestra cómo utilizar ABAC en AWS, consulte Tutorial: Uso de etiquetas para el control de acceso basado en atributos en AWS.


         Modelo ABAC

Comparación de ABAC con el modelo RBAC tradicional

El modelo de autorización tradicional utilizado en IAM se denomina control de acceso basado en roles (RBAC). RBAC define permisos en función de la función laboral de una persona, conocida fuera de AWS como rol. Dentro de AWS un rol normalmente se refiere a un rol de IAM, que es una identidad en IAM que puede asumir. IAM incluye políticas administradas para funciones de trabajo que alinean los permisos con una función de trabajo de 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 de (usuarios de IAM, grupos de usuarios o roles de IAM). Como práctica recomendada, debe conceder los permisos mínimos necesarios para la función de trabajo. Esto se conoce como concesión de privilegios mínimos. Para ello, enumeren los recursos específicos a los que puede obtener acceso la función de trabajo. La desventaja de utilizar el modelo RBAC tradicional es que cuando los empleados añaden nuevos recursos, debe actualizar las políticas para permitir el acceso a dichos recursos.

Por ejemplo, suponga que tiene tres proyectos, denominados Heart, Sun 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 cualquier persona que tenga permiso para asumir el rol puede acceder. Si un empleado cambia de trabajo dentro de su empresa, usted les asigna un rol de IAM diferente. Es posible asignar personas o programas a más de un rol. Sin embargo, el proyecto Sun puede requerir recursos adicionales, como un nuevo bucket de Amazon S3. En ese caso, debe actualizar la política adjunta al rol Sun para especificar el nuevo recurso del bucket. De lo contrario, los miembros del proyecto Sun no pueden obtener acceso al nuevo bucket.


            Modelo RBAC

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 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 cambiar y crecer rápidamente. Esto se debe a que los permisos para nuevos recursos se conceden automáticamente en función de los atributos. Por ejemplo, si su empresa ya admite los proyectos Heart y Sun con ABAC, es fácil añadir un nuevo proyecto Lightning. Un administrador de IAM crea un nuevo rol 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 puede crear y ver instancias etiquetadas con access-project = Lightning. Además, un miembro del equipo podría pasar del proyecto Heart al proyecto Lightning. El administrador de IAM asigna al usuario a 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 RBAC tradicional, debe escribir una política que permita el acceso solo a recursos específicos. Sin embargo, cuando utiliza ABAC, puede permitir acciones en todos los recursos, pero solo 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 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 ver un tutorial detallado que muestra cómo utilizar ABAC en AWS, consulte Tutorial: Uso de etiquetas para el control de acceso basado en atributos en AWS.