Un proveedor de analítica sanitaria había implantado una autenticación sólida: llaves físicas de FIDO2, resistentes al phishing y bien implementadas. Su evaluación de TPRM confirmó la sólida postura de autenticación y los evaluadores pasaron a otra cosa. A lo que la evaluación no llegó fue al modelo de autorización. Una vez autenticado el usuario, la aplicación del proveedor aplicaba un control de acceso basado en funciones, pero las definiciones de las funciones eran amplias. La función 'Analytics User', asignada a sesenta y uno de los setenta y ocho empleados del proveedor, daba acceso de lectura a todos los conjuntos de datos de clientes de la plataforma de analítica: todas las categorías clínicas, todas las organizaciones clientes y el historial completo. La decisión de autorización que permitía a cada usuario de analítica leer cualquier registro de cualquier cliente se tomó una sola vez, al definir la función, y se aplicó a los sesenta y un usuarios sin diferenciar el alcance individual. Un usuario de analítica incorporado hacía dos meses para un proyecto con un cliente concreto tenía el mismo acceso a los conjuntos de datos que el analista sénior que llevaba seis años en la organización. La autenticación confirmaba que era el usuario de analítica. La autorización le daba acceso a todo lo que permitía la función, es decir, a todos los historiales clínicos de la plataforma. La autenticación era sólida. La autorización no discriminaba.
¿Qué es realmente la confusión entre autenticación y autorización?
La autenticación es el proceso de verificar que una entidad es quien o lo que dice ser, confirmando la identidad mediante credenciales, certificados u otras pruebas de identidad. Responde a una pregunta binaria: ¿coincide esta credencial con una identidad conocida y válida? La autorización es el proceso de determinar qué puede hacer una entidad autenticada: a qué recursos puede acceder, qué operaciones puede realizar y en qué condiciones. Responde a una pregunta contextual: dado que se trata de una identidad válida confirmada, ¿qué se le permite hacer concretamente en este contexto concreto?
Ambos procesos suelen tratarse juntos y a veces se confunden, pero abordan problemas de seguridad fundamentalmente distintos y fallan de maneras fundamentalmente distintas. Un fallo de autenticación permite que una identidad equivocada acceda al sistema. Un fallo de autorización permite que la identidad correcta acceda a lo que no debe. Una autenticación sólida con una autorización débil significa que solo las identidades válidas y verificadas pueden acceder al sistema y que, una vez dentro, pueden acceder a mucho más de lo que deberían. Una autenticación débil con una autorización sólida significa que identidades mal verificadas pueden entrar en el sistema, pero que, una vez dentro, solo pueden acceder a aquello para lo que están autorizadas concretamente. Ambos son problemas. Son problemas distintos que requieren controles distintos.
El problema de la amplitud excesiva del RBAC es el fallo de autorización más común en las aplicaciones empresariales. El control de acceso basado en funciones es el modelo de autorización dominante: los permisos se asignan a funciones y los usuarios se asignan a funciones. Las funciones suelen definirse para el caso de uso más amplio dentro de un área: la función Analytics User incluye acceso a todos los datos de analítica porque algunos usuarios de analítica necesitan legítimamente acceder a todos ellos. Cuando esa función se aplica por igual a todos los usuarios de analítica, da a cada uno de ellos el acceso más amplio que cualquier usuario de analítica podría necesitar legítimamente, lo que otorga una autorización muy superior a la necesaria a la mayoría de los usuarios, cuyo trabajo real requiere solo una parte de ese acceso.
- Autenticación confirmada como indicador de la autorización: una autenticación sólida tratada como prueba de una autorización adecuada
- Amplitud excesiva del RBAC: definiciones de funciones diseñadas para el caso de uso máximo y aplicadas por igual a todos sus miembros
- Sin autorización basada en atributos: las decisiones de autorización no incorporan atributos propios de cada usuario más allá de la pertenencia a una función
- Sin autorización sensible al contexto: la autorización no tiene en cuenta el contexto del acceso, la sensibilidad de los datos ni el momento del acceso
- Autorización no evaluada por separado de la autenticación
Por qué es importante
La confusión entre autenticación y autorización es importante para TPRM porque la solidez de la autenticación y el diseño de la autorización son propiedades de seguridad independientes que requieren evaluaciones independientes. La mayoría de las evaluaciones de TPRM confirman la solidez de la autenticación (tipo de MFA, gestión de credenciales, resistencia al phishing) y usan esa confirmación como indicador de la seguridad del acceso en general. El modelo de autorización, que determina a qué pueden acceder realmente los usuarios autenticados, es una evaluación aparte que muchos programas de TPRM no realizan de forma expresa.
La dimensión de la determinación del alcance de una brecha es donde la distinción tiene más consecuencias. Las investigaciones de brechas que preguntan 'a qué datos podía acceder la credencial comprometida' están planteando una pregunta de autorización. La respuesta no la determina la solidez de la autenticación, sino el modelo de autorización. Una credencial con una autenticación muy sólida y una autorización amplia produce una brecha de gran alcance. Una credencial con una autenticación débil y una autorización limitada produce una de alcance reducido. La solidez de la autenticación no predice el alcance de la brecha. El modelo de autorización sí.
Dónde se equivocan la mayoría de los equipos
El fallo más habitual es tratar la autenticación y la autorización como una sola dimensión de la evaluación de seguridad. Confirmar una autenticación sólida sin evaluar el modelo de autorización ofrece una gran confianza en que la identidad correcta está accediendo a lo que no debe. Las dos preguntas requieren marcos de evaluación separados.
- Tratar la autenticación y la autorización como una sola dimensión de evaluación
- Modelo de autorización no evaluado por separado
- Amplitud de las funciones de RBAC no evaluada
- No se evalúa a qué pueden acceder realmente los usuarios autenticados
- El alcance de una brecha lo determina la autorización, no la autenticación, pero solo se evalúa la autenticación
Cómo se ve una buena práctica
Las evaluaciones maduras de la seguridad de las identidades abordan la autenticación y la autorización como dimensiones separadas: la autenticación sólida se confirma mediante la evaluación de la gestión de credenciales y de la MFA, y el modelo de autorización se evalúa mediante el análisis de la amplitud de las funciones, la verificación del privilegio mínimo y la evaluación del alcance real del acceso.
- Evaluación separada de la autenticación y la autorización: ambas dimensiones evaluadas expresamente
- Análisis de la amplitud de las funciones: a qué puede acceder la función más amplia de cada área
- Verificación del privilegio mínimo en la autorización: si las funciones se limitan al acceso mínimo necesario
- Autorización basada en atributos: decisiones de autorización que incorporan el contexto propio de cada usuario más allá de la pertenencia a una función
- Modelización del alcance de una brecha: a qué puede llegar una credencial autenticada a través del modelo de autorización
Herramientas
Motores de políticas de autorización: Open Policy Agent (OPA), Cedar
Los motores de autorización basados en políticas proporcionan una autorización detallada y sensible al contexto que va más allá del control de acceso basado en funciones, ya que permiten decisiones de autorización que incorporan la sensibilidad de los datos, atributos propios de cada usuario, el contexto de la solicitud y restricciones temporales. Para los profesionales de TPRM, preguntar si el proveedor usa autorización basada en políticas para el acceso a datos sensibles, además del RBAC, es una pregunta concreta sobre la sofisticación del modelo de autorización.
Analítica de identidades: Veza
Las plataformas de analítica de identidades ofrecen visibilidad del modelo de autorización: muestran a qué puede acceder realmente cada función y cada usuario en todos los sistemas conectados, lo que permite evaluar la amplitud de la autorización en lugar de deducirla de las definiciones de las funciones. Para los profesionales de TPRM, preguntar si el proveedor puede aportar un mapa del alcance de la autorización que muestre a qué puede acceder realmente cada función del personal es una pregunta concreta de evaluación de la autorización.
Desafíos de gobernanza
El reto de gobernanza de la autenticación frente a la autorización es el problema del alcance de la evaluación. La seguridad de la autenticación es visible y se comprende bien: el tipo de MFA, la gestión de credenciales y la resistencia al phishing son controles que se pueden documentar y evaluar. La evaluación del modelo de autorización es más compleja: requiere entender las definiciones de las funciones, el alcance del acceso a los datos y los permisos efectivos que confiere la pertenencia a una función en todos los sistemas conectados. La complejidad de evaluar la autorización crea un sesgo hacia la evaluación, más sencilla, de la autenticación.
- Separe expresamente la autenticación y la autorización en las evaluaciones
- Pregunte a qué puede acceder la función más común: el alcance de acceso que tiene la mayoría de los usuarios autenticados
- Pregunte por la amplitud de las funciones de RBAC: si se limitan a los requisitos mínimos o máximos de cada función
- Pregunte por la autorización basada en atributos para el acceso a datos sensibles
- Modele el alcance de una brecha a partir de la autorización: a qué podría llegar una credencial autenticada
Si usted forma parte de un equipo pequeño
Añada una pregunta sobre autorización a cada evaluación de la seguridad del acceso, junto con la confirmación de la autenticación: en el caso de la función de usuario más común de su sistema, la que tiene la mayoría de su personal que accede a datos de clientes, ¿cuál es el alcance de los datos a los que puede acceder? ¿Se limita a clientes concretos, categorías de datos concretas o periodos concretos, o es un acceso amplio a todos los datos de clientes de su área? Esa pregunta describe la calidad del diseño de la autorización que la evaluación de la autenticación no aborda.
- Pregunte a qué puede acceder la función de usuario más común: alcance y amplitud
- Pregunte si la autorización se limita a clientes concretos o abarca a todos los clientes
- Pregunte si la autorización basada en atributos añade contexto individual más allá de la pertenencia a una función
- Separe expresamente las dimensiones de evaluación de la autenticación y la autorización
Qué exigir
Pregunte directamente:
“En el caso de la función más común entre su personal que accede a datos de clientes, ¿qué alcance de acceso proporciona esa función? En concreto, ¿pueden los miembros de esa función acceder a la vez a los datos de todos los clientes, o el acceso se limita a clientes o categorías de datos concretos?”
“Además de confirmar la MFA y la solidez de la autenticación, ¿puede describir su modelo de autorización para el acceso a los datos de clientes? En concreto, ¿cómo se limita el acceso más allá de la pertenencia a una función y cómo se evita el exceso de autorización?”
Evidencia que debe esperar
- Documentación del alcance de autorización de la función más común: a qué puede acceder esa función
- Descripción del modelo de autorización más allá del RBAC: controles basados en atributos, limitación por cliente
- Análisis de la amplitud de las funciones: si se definen con el alcance mínimo o máximo
- Modelo del alcance de una brecha: a qué puede acceder una credencial autenticada
A un proveedor que confirme la FIDO2 MFA se le debe preguntar a qué puede acceder un usuario de FIDO2 autenticado una vez dentro del sistema. Una autenticación sólida confirma la identidad. El modelo de autorización determina el radio de impacto. Ambos requieren evaluación.
Cómo demostrarlo
- Registros de evaluación de la autenticación y la autorización, ambas evaluadas por separado
- Documentación del alcance de las funciones más comunes
- Descripción del modelo de autorización
- Registros de modelización del alcance de una brecha
Conclusión clave
La autenticación y la autorización son dos preguntas distintas, con dos respuestas distintas y dos controles distintos. La autenticación dice: confirmo que esta es una identidad válida. La autorización dice: confirmo que esta identidad válida puede hacer esta acción concreta. Una autenticación sólida con una autorización débil es una entrada de alta confianza a un sistema en el que hay demasiado accesible. La llave física de FIDO2 confirmó que el usuario de analítica era quien decía ser. La función Analytics User confirmó que podía acceder a todos los historiales clínicos de la plataforma. La autenticación era sólida. La autorización no discriminaba. El alcance de la brecha lo determinó por completo el modelo de autorización, que la evaluación dio por bueno al no preguntar por él. Evalúe ambas. No son la misma pregunta.