Control de acceso ABAC sobre DataWindow: decisiones dinámicas, explicables y auditables

Este artículo técnico fue preparado por Luis Avilan a partir de un demo reproducible de la carpeta articulo_appeon.

ABAC no pregunta solamente “¿qué rol tiene el usuario?”. También evalúa quién es, qué intenta hacer, sobre qué información, desde qué entorno y bajo qué nivel de riesgo.

Qué es ABAC

ABAC, o Attribute-Based Access Control, es un modelo de autorización que toma decisiones combinando atributos. El permiso no queda asociado únicamente a un rol estático, sino al contexto completo de cada solicitud.

Sujeto

Usuario, departamento, nivel de seguridad, límite de aprobación y permisos especiales.

Recurso y acción

Clasificación del expediente, propietario, PII, monto y operación solicitada: consultar, editar, aprobar, exportar o ver PII.

Entorno

Red, dispositivo, horario, riesgo de sesión, reautenticación y estado de emergencia.

Una política ABAC puede expresarse conceptualmente así: “Permitir que RRHH edite salarios únicamente desde una red segura, durante horario laboral, con un dispositivo corporativo y riesgo bajo o medio”. El mismo usuario puede recibir una decisión diferente sin cambiar de rol cuando cambia alguno de esos atributos.

Forma tradicional frente a ABAC

Autorización tradicional

La aplicación suele consultar el rol y habilitar una pantalla o botón: administrador, supervisor, operador o invitado. La decisión es amplia y normalmente permanece igual durante toda la sesión.

IF rol = "ADMIN" THEN acceso = TRUE

Autorización ABAC

La aplicación evalúa el sujeto, el recurso, la acción y el entorno cada vez que necesita proteger una operación. La decisión puede incluir obligaciones como enmascarar, filtrar o solicitar reautenticación.

decisión = motor.of_evaluar_contexto(contexto)

Desventajas de mantener únicamente la forma tradicional

• Explosión de roles: cada combinación de departamento, jerarquía, ubicación y excepción termina creando un rol nuevo.

• Permisos excesivos: para resolver casos especiales se asignan perfiles más amplios de lo necesario.

• Ceguera contextual: un permiso válido en la oficina puede permanecer activo desde una red pública o un dispositivo personal.

• Excepciones dispersas: reglas especiales aparecen como condiciones duplicadas en ventanas, menús y eventos.

• Poca granularidad: permitir abrir una pantalla no distingue qué filas, columnas u operaciones deben protegerse.

• Auditoría débil: saber que un usuario tenía un rol no siempre explica por qué pudo consultar un dato concreto.

• Mantenimiento costoso: un cambio regulatorio obliga a revisar numerosos objetos visuales y combinaciones de perfiles.

Ventajas de ABAC

• Aplica el principio de mínimo privilegio con mayor precisión.

• Reacciona a cambios de riesgo, red, horario o dispositivo durante la sesión.

• Permite decisiones diferentes para consulta, edición, aprobación y exportación.

• Centraliza reglas en un motor en lugar de duplicarlas en eventos visuales.

• Genera explicaciones y auditoría asociadas a políticas concretas.

• Admite obligaciones intermedias: solo lectura, PII enmascarada, filtros o reautenticación.

• Facilita incorporar nuevos atributos sin diseñar una jerarquía completa de roles.

La demo en ejecución

La ventana real permite cambiar usuario, red, hora, dispositivo, riesgo y acción. La tarjeta central, el DataWindow protegido, las políticas y la auditoría se recalculan con el contexto.

La captura muestra a Roberto Silva desde una red interna, durante horario laboral, con dispositivo corporativo y riesgo bajo. El motor permite consultar siete expedientes, mantiene el salario protegido y autoriza PII y exportación según los atributos de ese perfil.

Arquitectura implementada

Script 1: captura, evaluación y aplicación

La ventana coordina el ciclo y el NVO concentra las reglas. La decisión se pasa por referencia porque es un NVO autoinstanciado.

w_centro_control_abac.of_evaluar_contexto tiene una responsabilidad breve: captura los controles, llama al motor, aplica la decisión y registra el resultado. No decide si una red es segura ni si un salario puede editarse.

nvo_motor_abac.of_evaluar_contexto restablece la decisión y calcula cada dimensión por medio de funciones pequeñas: riesgo, bloqueo crítico, filtro de filas, edición de salario, PII, exportación, aprobación y reautenticación. El resultado consolidado puede ser permitido, permitido con restricciones, reautenticación requerida, denegado o acceso de emergencia.

Script 2: seguridad por fila en el DataWindow

El motor produce una expresión DataWindow y la ventana restaura el buffer antes de aplicar el filtro del nuevo usuario.

RRHH ve expedientes de RRHH, Finanzas ve los suyos, Ventas recibe únicamente Ventas y un usuario externo obtiene registros públicos. Dirección o una emergencia autorizada pueden ampliar el alcance. Una sesión crítica devuelve 1 = 0 y oculta todas las filas.

La restauración previa evita conservar el subconjunto del usuario anterior. Además, la demo valida los retornos de SetFilter() y Filter(), y muestra la cantidad de filas visibles en la tarjeta y en la auditoría.

Script 3: protección y enmascaramiento de PII

La columna visible recibe el valor completo o una representación protegida según la obligación producida por el motor.

El motor no cambia directamente el DataWindow. Indica si la PII debe enmascararse y la ventana delega la transformación en nvo_enmascaramiento_abac. Una tarjeta como 5200123412344582 puede presentarse como ****-****-****-4582.

La columna salario utiliza Modify() para alternar Protect y color de fondo. Esto comunica claramente el estado de solo lectura. Antes de guardar, exportar o aprobar, una aplicación real debe repetir la autorización en la capa de negocio.

Políticas visibles de la demo

Recorrido de una decisión

• El usuario selecciona identidad, red, hora, dispositivo, riesgo y acción.

• La ventana traduce los controles a un nvo_contexto_abac.

• El motor calcula riesgo y evalúa políticas aplicables.

• La estrategia de resolución evita que un permiso general anule una denegación crítica.

• La decisión determina filtro, lectura, PII, exportación, aprobación y reautenticación.

• La ventana restaura el DataWindow, enmascara, filtra y protege columnas.

• El monitor explica las políticas y la consola registra usuario, departamento y filas visibles.

Cómo comprobar que ABAC cambia la experiencia

• Seleccione Ana López, red interna, hora 10, dispositivo corporativo y riesgo bajo: aparecen dos filas de RRHH y el salario puede editarse.

• Cambie únicamente la red a pública: la edición y exportación se bloquean y la PII queda protegida.

• Seleccione Carlos Méndez en contexto seguro: aparecen dos filas financieras y se habilitan permisos financieros.

• Seleccione Laura Torres: queda visible una fila de Ventas con datos sensibles enmascarados.

• Seleccione Roberto Silva: Dirección puede consultar los siete expedientes, aunque el salario continúa protegido.

• Cambie el riesgo a crítico: la decisión se vuelve denegada y el DataWindow queda sin filas.

Costos y precauciones de ABAC

ABAC ofrece más precisión, pero requiere disciplina. Los atributos deben ser confiables y mantenerse actualizados; las políticas necesitan nombres, propietarios, prioridad y pruebas; y la combinación de reglas puede ser más difícil de comprender que un rol simple. También conviene medir el costo de evaluación cuando existen miles de políticas o llamadas remotas.

La respuesta es gobernanza: centralizar el motor, registrar cada decisión, mantener funciones cortas, probar escenarios positivos y negativos, y separar la decisión de su representación visual. La demo aplica esa separación para que nuevas políticas puedan incorporarse sin convertir la ventana en un script extenso.

Conclusión

PowerBuilder y DataWindow pueden ofrecer una experiencia de autorización mucho más rica que habilitar menús por rol. La demo demuestra filtrado por fila, protección de columnas, enmascaramiento de PII, decisiones dependientes del entorno, explicaciones y auditoría inmediata.

ABAC no elimina necesariamente los roles: los convierte en un atributo más dentro de una decisión contextual. Esa combinación permite conservar la simplicidad organizativa de los perfiles y añadir la precisión que exigen los sistemas empresariales modernos.