¿Qué es ABAC?
Privacidad, seguridad e identidad
ABAC significa Control de Acceso Basado en Atributos (Attribute-Based Access Control). Es un modelo de control de acceso en el que las decisiones se toman evaluando atributos del usuario o sujeto, el recurso solicitado, la acción que se intenta realizar y, cuando corresponde, el entorno circundante. En lugar de preguntar únicamente "¿qué rol tiene esta persona?", ABAC también puede preguntar "¿a qué departamento pertenece, qué etiqueta lleva el documento, qué dispositivo está usando, qué hora es, desde dónde se conecta y es la solicitud coherente con la política?". En el trabajo práctico habilitado por IA, ABAC resulta útil cuando las decisiones de acceso necesitan más contexto del que un rol estático puede ofrecer.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
ABAC se entiende mejor por comparación. RBAC establece que los permisos se asocian a roles como revisor de RRHH, analista financiero o responsable de soporte. Eso funciona bien cuando las funciones laborales son estables. ABAC va más lejos: permite que la política evalúe múltiples atributos en el momento del acceso.
Esos atributos pueden describir al solicitante, el recurso, la actividad solicitada y el contexto de la solicitud. Un usuario puede pertenecer al departamento jurídico, formar parte del Proyecto Mercury, usar un dispositivo gestionado, conectarse desde el Reino Unido en horario laboral y solicitar acceso de solo lectura a un documento etiquetado como confidencial. Una política puede combinar esos datos y devolver una decisión.
Esto no significa que ABAC sea siempre mejor que RBAC, sino que es más expresivo. Resulta útil cuando los roles simples no capturan suficientemente la regla de negocio. Es especialmente relevante cuando las organizaciones quieren un acceso dinámico basado en clasificación, pertenencia a proyectos, confianza en el dispositivo, ubicación, hora o señales de riesgo cambiantes.
Por qué es importante
ABAC importa porque las decisiones de acceso modernas suelen ser más contextuales de lo que el antiguo modelo de perímetro suponía. Un rol por sí solo puede no ser suficiente. El mismo usuario podría tener permiso para leer un documento desde un portátil gestionado en la red de la oficina, pero no para descargarlo desde un dispositivo personal no gestionado en una ubicación de riesgo. O puede que solo pueda abrir un archivo de proyecto mientras forme parte de él y esté empleado en el departamento promotor.
Esto cobra mayor relevancia en entornos cloud distribuidos, arquitecturas de tipo zero-trust y sistemas de conocimiento habilitados por IA. Cada vez más, se indica a las organizaciones que no confíen únicamente en la ubicación de red, y las orientaciones oficiales de NIST y NCSC reflejan esa dirección. Las decisiones de acceso se benefician de múltiples señales, no de una única comprobación genérica. Eso hace que ABAC resulte atractivo cuando la organización quiere que la política responda al contexto real del acceso.
ABAC también ayuda con la escala cuando los roles por sí solos se multiplicarían de forma incontrolable. Si cada combinación de departamento, geografía, clasificación y estado del dispositivo se convierte en un rol independiente, el diseño de roles deriva en una explosión de roles. ABAC puede reducir esa presión manteniendo las categorías base simples y expresando las condiciones más precisas mediante políticas.
También es relevante para el trabajo habilitado por IA porque no todos los usuarios necesitan el mismo nivel de recuperación de información, detalle en los resultados o acceso a sistemas conectados. La guía de NCSC sobre seguridad en aprendizaje automático señala explícitamente tanto RBAC como ABAC como formas útiles de controlar distintos niveles de detalle en los resultados. Es un recordatorio práctico de que la gobernanza de la IA a menudo requiere decisiones de acceso contextuales, no un simple sí o no.
Cómo funciona
ABAC funciona evaluando reglas frente a atributos. El modelo de NIST es explícito: la decisión puede utilizar atributos del sujeto, atributos del objeto, la operación solicitada y las condiciones del entorno relevantes para la solicitud.
Los atributos del sujeto describen al solicitante. Pueden incluir departamento, situación laboral, nivel de autorización, pertenencia a proyectos, formación completada, posición en la organización o puntuación de riesgo. En algunos sistemas, los atributos del dispositivo también se incorporan al lado del sujeto en la decisión, a través de la identidad del dispositivo o su pertenencia a grupos.
Los atributos del objeto o recurso describen aquello a lo que se accede. Pueden incluir la clasificación del documento, el equipo propietario, el tipo de base de datos, la sensibilidad jurídica, la geografía, la línea de producto o la etiqueta de proyecto. Si los metadatos del recurso son débiles o inconsistentes, ABAC se vuelve mucho más difícil de aplicar.
Los atributos de acción describen lo que el solicitante quiere hacer. Leer, editar, descargar, compartir, exportar, aprobar y administrar no son acciones equivalentes. Una buena política ABAC distingue entre ellas.
Los atributos del entorno describen las condiciones circundantes. NIST ofrece ejemplos prácticos al respecto, como la hora, el día, la ubicación y el nivel de amenaza. La guía más reciente de NCSC sobre zero-trust añade identidad del usuario, pertenencia a grupos, identidad del dispositivo, estado del dispositivo y señales de comportamiento del usuario. En lenguaje claro, ABAC permite decir: permitir que este tipo de usuario realice este tipo de acción sobre esta clase de recurso solo bajo estas condiciones.
La mecánica depende de atributos fiables y políticas bien mantenidas. Esa es la parte difícil. Los atributos deben emitirse, actualizarse y retirarse de forma fiable. Las políticas deben ser lo suficientemente claras para gestionarse y probarse. Los registros deben preservar la responsabilidad para que la organización pueda explicar por qué se tomó una decisión. Si los atributos están desactualizados o la política es excesivamente compleja, ABAC puede convertirse en una fuente de confusión en lugar de precisión.
Dónde aparece en flujos de trabajo reales
Un ejemplo sencillo parte de los documentos. Supongamos que una empresa almacena actas del consejo, expedientes de RRHH y registros de proyectos en un entorno gobernado. Un rol base puede permitir a los directivos leer información de gestión, pero ABAC puede afinar más: un directivo solo puede leer un archivo si pertenece al departamento promotor, el archivo lleva la etiqueta de clasificación correcta y la solicitud se realiza desde un dispositivo gestionado. Eso es más fácil de mantener que crear un nuevo rol para cada combinación de departamento, clasificación y dispositivo.
Consideremos ahora el trabajo por proyectos. Un consultor es asignado al Proyecto Atlas durante tres meses. En lugar de añadirlo manualmente a numerosos grupos específicos del proyecto en distintos servicios, una política ABAC puede conceder acceso basándose en un atributo de pertenencia activa al proyecto, la situación laboral y la clasificación de los recursos pertinentes. Cuando cambia la pertenencia al proyecto, el acceso puede cambiar con ella.
Un ejemplo más específico de IA es el acceso al conocimiento interno. Un asistente interno puede estar autorizado a responder distintas preguntas según quién pregunte, qué repositorios están en alcance, qué modo de salida se solicita y si el usuario está en un dispositivo de confianza. Un agente de soporte podría recibir orientación resumida de artículos de conocimiento etiquetados. Un investigador formado en un dispositivo seguro podría acceder a detalles más completos del caso. Aquí ABAC es útil porque la política depende de más que el rol por sí solo.
Otro ejemplo proviene del horario y la geografía. Una empresa puede permitir la aprobación de cambios sensibles en proveedores solo a empleados con la función adecuada, durante ventanas horarias normales, desde dispositivos gestionados conocidos y no desde regiones de alto riesgo inusuales. Eso es el pensamiento ABAC clásico: combinar atributos de sujeto, recurso, acción y entorno en una sola decisión.
Malentendidos frecuentes
Un malentendido habitual es que ABAC es simplemente "RBAC pero más inteligente". Eso es demasiado simplista. RBAC y ABAC son enfoques de diseño distintos. Muchas organizaciones los combinan. RBAC gestiona bien el acceso base estable. ABAC añade condiciones de política cuando el contexto importa. No es necesario elegir un ganador en todos los casos.
Otro malentendido es que ABAC elimina automáticamente la necesidad de roles. En la práctica, los roles siguen siendo útiles con frecuencia. La pertenencia a un grupo o rol puede ser en sí misma uno de los atributos del sujeto en una decisión ABAC. La diferencia real es que la decisión de acceso final no está obligada a depender únicamente del rol.
Los equipos también subestiman la importancia de la calidad de los datos. ABAC solo funciona bien si los atributos son fiables. Si la pertenencia a proyectos está desactualizada, las señales de estado del dispositivo son ruidosas, faltan etiquetas de clasificación o las señales geográficas se interpretan mal, el resultado de la política se vuelve poco fiable. ABAC no es más inteligente que la información en la que se basa.
También existe la tentación de hacer la política infinitamente granular porque el modelo lo permite. Eso rara vez es aconsejable. La guía de zero-trust de NCSC advierte explícitamente contra una granularidad excesiva en las políticas, porque rápidamente se vuelve difícil de gestionar y mantener. La precisión es útil; una política ilegible no lo es.
Por último, algunas personas creen que ABAC es solo para grandes empresas. Es cierto que ABAC introduce complejidad, pero las organizaciones pequeñas y medianas pueden igualmente usar ideas de estilo ABAC de forma selectiva, especialmente cuando la confianza en el dispositivo, la ubicación, la clasificación o la pertenencia a proyectos cambian materialmente la respuesta correcta.
Riesgos y límites
El mayor riesgo de ABAC es la complejidad. Si se introducen demasiados atributos, demasiadas excepciones y demasiadas políticas puntuales, las decisiones se vuelven difíciles de razonar. Los operadores tienen dificultades para diagnosticar problemas. Los directivos no pueden revisar el modelo. Los usuarios no entienden por qué el acceso se concede en un contexto y se deniega en otro.
La confianza en los atributos es el segundo límite principal. Las políticas son tan sólidas como los sistemas que suministran los atributos. Si los datos de cumplimiento del dispositivo van por detrás de la realidad, si los atributos de identidad no se actualizan cuando las personas cambian de rol, o si los documentos están mal etiquetados, las decisiones ABAC pueden ser incorrectas en cualquier dirección.
La responsabilidad también requiere atención. Dado que las decisiones pueden ser dinámicas, la organización debe registrar suficiente información para explicar quién accedió a qué, bajo qué condiciones y por qué la política lo permitió. De lo contrario, el control se vuelve difícil de gobernar.
ABAC no reemplaza los controles más simples cuando estos son suficientes. Si un modelo de roles estable funciona, úselo. Si una regla de denegación fija funciona, úsela. ABAC justifica su uso cuando el contexto cambia materialmente el resultado correcto. Aplicado en todas partes, puede sobrecargar a equipos pequeños. Aplicado de forma selectiva, puede resolver exactamente los tipos de casos límite que hacen que RBAC por sí solo resulte torpe.
Qué deberían hacer los líderes a continuación
Los líderes no deberían empezar por un motor de políticas, sino por un problema. Conviene identificar un puñado de decisiones de acceso en las que RBAC por sí solo claramente no es suficiente: quizás requisitos de dispositivo seguro, acceso basado en proyectos, gestión de documentos con conciencia de clasificación o protección de resultados de IA de mayor fidelidad.
A continuación, hay que verificar si los atributos que respaldan esas decisiones son realmente fiables. Si la respuesta es no, conviene corregir los datos de identidad, los metadatos de recursos y las señales de dispositivo antes de añadir nuevas políticas encima. Los atributos débiles generan confusión costosa.
Por último, conviene ser disciplinado con el alcance. Mantener el acceso base simple, habitualmente con roles, y añadir ABAC solo donde el contexto adicional cambia la respuesta correcta de forma significativa. Probar las políticas con flujos de trabajo reales, registrar los resultados y asegurarse de que alguien en la organización pueda explicar el modelo en lenguaje claro.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Qué tipos de atributos se usan habitualmente en ABAC?
Las categorías comunes incluyen atributos del usuario o sujeto, como departamento, situación laboral, pertenencia a proyectos o formación completada; atributos del recurso, como clasificación, propietario o etiqueta de metadatos; atributos de acción, como leer, editar, descargar o aprobar; y atributos del entorno, como hora, ubicación, estado del dispositivo o nivel de amenaza actual. La clave no está en recopilar todos los atributos posibles, sino en usar el pequeño conjunto que realmente mejora la calidad de la decisión.
¿Debería ABAC reemplazar a RBAC?
Generalmente no. En la mayoría de las organizaciones, el patrón práctico es la combinación, no la sustitución. RBAC sigue siendo útil para categorías de acceso amplias y estables porque es más fácil de explicar, asignar y revisar. ABAC resulta valioso cuando el acceso también depende del contexto, como la pertenencia a proyectos, la clasificación, el estado del dispositivo gestionado o la hora de la solicitud. Si se intenta hacer de ABAC la respuesta a cada pregunta de acceso, la complejidad puede superar el beneficio.
¿Por qué es relevante ABAC para el zero-trust y el trabajo habilitado por IA?
Las guías de estilo zero-trust hacen hincapié en usar múltiples señales en lugar de depender de un único factor genérico como la ubicación de red. ABAC encaja de forma natural con esa forma de pensar, porque puede combinar identidad, dispositivo y contexto del entorno en la decisión. En el trabajo habilitado por IA, el mismo enfoque ayuda cuando algunos usuarios solo deben recibir resúmenes, otros pueden acceder a las fuentes subyacentes y ciertas acciones deben bloquearse a menos que el dispositivo y el contexto sean de confianza.
Fuentes
National Institute of Standards and Technology: Guide to Attribute Based Access Control (ABAC) Definition and Considerations - Formal ABAC definition, subject/object/action/environment structure, policy logic, environment conditions and complexity considerations.
National Cyber Security Centre: Signals and policy engines - Modern UK guidance on user identity, group membership, authentication strength, device identity, device health and user behaviour signals.
National Cyber Security Centre: How to implement ZTNA - Use of multiple signals in access decisions, risk-based policy design and warning against excessive policy granularity.
National Institute of Standards and Technology: Zero Trust Architecture - Zero trust principle that there is no implicit trust based solely on network location or asset ownership, and that authentication and authorisation are discrete functions.
National Cyber Security Centre: Protect information that could be used to attack your model - AI-specific context for using RBAC and ABAC to control different levels of model output and user authorisation.
National Institute of Standards and Technology: The NIST Cybersecurity Framework (CSF) 2.0 - Least privilege, access permissions, entitlements and authorisations as part of an overall cybersecurity risk framework.