Cubadebate

Imaginemos por un momento que la seguridad de la información fuera como un exclusivo club nocturno. En la puerta, un portero enorme revisa una lista: “¿Está en la lista VIP? Adelante. ¿No está? Fuera”. Eso, en esencia, es el control de acceso basado en roles (RBAC). Elegante, sencillo y profundamente sin sentido para cualquier escenario que no sea una fiesta de los años ochenta.

Durante décadas, las empresas han vivido engañadas por esta falsa sensación de orden: asignar permisos según el puesto de una persona —“gerente”, “contador”, “practicante”— y olvidarse del problema. Pero el mundo ya no funciona así. Los roles son camisas de fuerza que ignoran el contexto, la hora, la ubicación, el peligro inminente o incluso el humor del sistema. Usted puede ser el director financiero, pero ¿de verdad necesita exportar la nómina completa desde un café de un aeropuerto con una red wifi abierta? El RBAC, en su naturaleza, diría que sí. Porque es su rol. Y ahí es donde todo se derrumba.

La ciberseguridad moderna no se trata de paredes, sino de torniquetes inteligentes. Y el RBAC, por más que duela admitirlo, es un torniquete que solo sabe leer carnets de identidad vencidos. La industria ha despertado tarde a una realidad incómoda: los ataques ya no buscan vulnerabilidades técnicas brutales; buscan credenciales legítimas mal administradas. Y nada es más legítimo que un vicepresidente con acceso a todo, incluso cuando está actuando de forma anómala. Por eso, en las mejores mesas de incidentes, ya se susurra una herejía: el rol es un remanente feudal, una casta informática que premia el título por encima del comportamiento. Y como toda casta, está destinada a no perdurar en el tiempo.

Entonces mis estimados lectores, es ahí cuando llega el despertar de los atributos: cuando el acceso se vuelve líquido. Frente a este monumental dislate, surge el control de acceso basado en atributos (ABAC). No es una simple actualización; es un cambio de paradigma. Si RBAC pregunta “¿quién eres?”, ABAC pregunta “¿quién eres, dónde estás, qué intentas hacer, con qué dispositivo, a qué hora y cuánto riesgo hay en este preciso instante?”. Los atributos son las nuevas moléculas de la autorización: todo se descompone en características mínimas e innegociables. El sujeto (una persona, una máquina, un proceso), el recurso (un archivo, una API, una base de datos), la acción (leer, escribir, ejecutar) y el entorno (red, geolocalización, nivel de parche de seguridad). Combinando estos elementos se construyen políticas dinámicas, expresivas y, lo más importante, contextuales.

Una política ABAC podría decir: “Un empleado del departamento de ventas puede leer el informe de prospectos solo si está dentro de la red corporativa, entre las 8 y las 18 horas, y si su dispositivo tiene el antivirus actualizado”. Ninguna de esas condiciones existe en un rol tradicional. El RBAC solo puede dar un sí o un no absoluto. El ABAC, en cambio, negocia. Y en un mundo donde las brechas de seguridad ocurren por excesos de confianza, negociar el acceso es más valioso que negarlo todo o permitirlo todo. De hecho, las arquitecturas de confianza cero —esa moda que muchos predican pero pocos aplican— no pueden sostenerse sin ABAC. Porque la confianza cero no significa no confiar en nadie, significa verificar cada solicitud como si fuera la primera vez, y para eso necesitas atributos, no etiquetas fijas.

En este momento entonces la solución reside en la disrupción oculta. Estamos en presencia del fin del administrador todopoderoso. Aquí es donde el artículo se vuelve incómodo para los puristas. Decir que ABAC es mejor que RBAC suena a esnobismo tecnológico. Pero la verdadera disrupción no está en la tecnología, sino en quién tiene el poder de definir el acceso. Con RBAC, la jerarquía de la empresa se replica en el sistema: un gerente general tiene más permisos que un jefe de área, y este más que un becario. Es un diseño que viene por defecto en el organigrama. Con ABAC, el poder se dispersa en reglas lógicas que pueden incluso contradecir el rango. Un becario en horario nocturno desde su casa podría tener acceso restringido a datos no sensibles, pero el director regional desde un hotel en un país con sospecha de interceptación podría perder su privilegio de exportación masiva. ¿Se imagina la reacción de un ejecutivo al que le bloquean el acceso por “contexto de riesgo”? Pues esa es la disrupción: la seguridad deja de ser una cortesía del cargo y se convierte en un veredicto del momento.

Y eso, claro, da miedo. Las organizaciones no siempre están preparadas para que un motor de políticas diga “no” al jefe. Pero la historia de la ciberseguridad está llena de ejecutivos con cuentas privilegiadas que se convirtieron en el vector de ataque más destructivo. El caso de la filtración de datos de una famosa oficina de crédito en 2017 ocurrió justamente por un rol sobredimensionado. No hubo hackeo ninja, hubo un empleado con demasiado acceso y poca supervisión. RBAC no lo evitó. ABAC, con atributos de ubicación, hora y tipo de consulta, tal vez sí. O al menos habría añadido capas de fricción que hoy lamentamos no haber tenido.

Pero no todo es miel sobre hojuelas: los dolores de cabeza reales de ABAC. Ser disruptivo también implica ser honesto. ABAC no es una varita mágica; es una bestia compleja que requiere disciplina casi monástica. Definir atributos es fácil: “edad”, “cargo”, “ubicación”. Lo difícil es mantenerlos actualizados, consistentes y libres de contradicciones. En RBAC, si Juan cambia de rol, solo se modifica su grupo. En ABAC, si Juan cambia de ubicación, de dispositivo, de hora de trabajo o de nivel de riesgo, las reglas deben evaluarse en tiempo real. Eso implica infraestructura: motores de políticas (PDP, PAP, PIP, PEP para los técnicos), directorios sincronizados, metadatos en cada recurso y una latencia que no afecte la experiencia del usuario. Una mala implementación de ABAC puede convertir un sistema ágil en una tortuga burocrática.

Además, hay un problema cultural: los atributos exponen la lógica del negocio como nunca antes. Cuando una política ABAC deniega el acceso porque “el dispositivo no está parcheado”, la indignación no es técnica, es política. “¿Cómo se atreve el sistema a decidir que mi computadora es insegura?”. RBAC nunca generaba esas preguntas: o estabas en el rol o no. ABAC abre la caja de Pandora de la explicabilidad. ¿Por qué me denegaste el acceso? Porque el atributo “nivel_de_riesgo_dispositivo” superó el umbral. Y eso obliga a las áreas de negocio, legales y compliance a sentarse a la misma mesa. Algo que muchas empresas no están dispuestas a hacer. Prefieren la simplicidad bruta del RBAC, aunque esa simplicidad les cueste una multa millonaria por filtración de datos.

¿Entonces cuál elijo? La herejía final: híbridos y madurez. Aquí va la conclusión que nadie quiere escuchar: la guerra RBAC vs ABAC es un falso debate en su forma pura. La mayoría de las organizaciones no necesitan un ABAC completo; necesitan un RBAC aumentado con atributos contextuales, lo que los ingenieros llaman atribución ligera o RBAC híbrido. Puede mantener los roles para el 80% de los casos triviales —acceso a carpetas compartidas, aplicaciones internas, calendarios— y reservar ABAC para los activos críticos: bases de datos de nómina, secretos industriales, las API de pago. Esa mezcla ofrece lo mejor de ambos mundos: simplicidad administrativa donde sobra y granularidad quirúrgica donde duele.

Pero la disrupción real no es técnica, sino estratégica. La pregunta que toda columna de ciberseguridad debería dejar resonando es: ¿su modelo de acceso actual está preparado para un mundo de trabajo híbrido, dispositivos personales, ataques de suplantación de identidad y nubes múltiples? Si la respuesta es “tenemos roles y grupos”, está en problemas. RBAC asume un mundo estable, con horarios fijos, oficinas fijas y jerarquías claras. Ese mundo se extinguió en algún momento entre la pandemia y el apagón de SolarWinds. ABAC, con todas sus dificultades, al menos reconoce que el acceso es un fenómeno temporal, local, condicional y frágil. Y la frágilidad, en ciberseguridad, es el punto de partida para construir sistemas honestos.

Ahora bien este autor tiene el honor de contarles que el futuro no tendrá roles, tendrá perfiles evolutivos. Si queremos ser realmente disruptivos, propongamos algo incómodo: en diez años, el concepto de “rol” como lo conocemos habrá desaparecido de las arquitecturas maduras. Será reemplazado por perfiles dinámicos que se construyen sobre la marcha, como un rompecabezas de atributos que cambia con cada transacción. La inteligencia artificial aplicada al control de acceso ya permite detectar patrones de comportamiento y sugerir políticas ABAC en lenguaje natural. Pronto, un administrador de seguridad podrá escribir: “Permitir el acceso a recursos financieros solo si el usuario ha completado la autenticación multifactor en los últimos 15 minutos, no proviene de una dirección IP considerada riesgosa y el recurso no tiene clasificación de alto impacto”. Eso no es un rol, es una oración condicional. Y las oraciones condicionales son mucho más poderosas que los sustantivos.

Para el público general, esto puede sonar a tecno-gerigonza. Pero para usted, que está leyendo esta columna porque sospecha que su empresa o su vida digital está mal protegida, el mensaje es sencillo: desconfíe de quien le ofrezca acceso basado únicamente en etiquetas. Las etiquetas mienten, caducan o se heredan mal. Los atributos, en cambio, son hechos. Y en ciberseguridad, los hechos (dónde está, qué hace, desde qué dispositivo, a qué hora) son la única verdad que vale la pena proteger. RBAC fue el analgésico de una época más ingenua. ABAC es la cirugía. Duele, es cara y requiere especialistas. Pero también es la única manera de curar la hinchazón crónica de los permisos excesivos. Así que la próxima vez que alguien le diga “tiene acceso porque es gerente”, responda: “¿Y eso qué importa ahora?”. Y observe cómo se encoge el mito del rol. Bienvenido al fin de las etiquetas. Que empiece el reinado de los atributos. Nos vemos la próxima semana.