¿Qué es ABAC para AWS?

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 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 crecen con rapidez y ayuda en situaciones en las que la administración de las 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 Star. 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 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.

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 generalmente se refiere a un rol de IAM, que es una identidad en IAM que usted puede asumir. 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, adjunte las políticas a identidades (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, 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 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 Star puede requerir recursos adicionales, como un nuevo contenedor de Amazon EC2. En ese caso, debe actualizar la política adjunta al rol Star para especificar el nuevo recurso del contenedor. De lo contrario, los miembros del proyecto Star no pueden obtener acceso al nuevo contenedor.

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 de acuerdo con los atributos. 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 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 SAML o OIDC 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 de IAM: definición de permisos para acceder a los recursos de AWS en función de etiquetas.