Fundamentos de la identidad y del control de acceso

Es el acto de declarar una identidad ante el sistema mediante un identificador, como un nombre de usuario, una dirección de correo, un número de empleado o un DNI. Por sí sola no prueba nada, ya que cualquiera puede escribir un nombre ajeno. En Linux, el identificador que usa el núcleo es el UID, que el sistema obtiene a partir del nombre de usuario consultando /etc/passwd o el servicio de directorio configurado.

De esa naturaleza se derivan tres consecuencias prácticas:

Una última distinción, que condiciona todo lo demás. La persona no es la cuenta. Una misma persona suele tener varias cuentas, por ejemplo una nominal para su trabajo diario y otra administrativa para las tareas que lo requieren, y los sistemas no autentican personas sino cuentas. De ahí que la trazabilidad dependa de que cada cuenta tenga un titular único e identificable, y que las aplicaciones y los dispositivos necesiten también su propia identidad, como se ve en la sección 3.

Es el proceso de verificar que quien se identifica es quien dice ser, mediante una o varias pruebas denominadas factores. El resultado es binario, el sujeto queda autenticado o no, pero la confianza que merece ese resultado no lo es, y de ahí que existan niveles de garantía, estudiados en el capítulo de autenticación multifactor.

El sistema no guarda la prueba, sino una referencia contra la que compararla, como el hash de una contraseña, la clave pública de un usuario o la plantilla de un rasgo biométrico. Esa referencia debe elegirse de modo que, si alguien se hace con ella, no pueda reconstruir el secreto ni suplantar a su titular.

Tres precisiones evitan los errores más comunes:

Un sujeto autenticado no tiene todavía ningún permiso.

Una vez autenticado, el sistema decide qué puede hacer el sujeto, según permisos, roles, atributos y políticas. Este capítulo estudia los modelos con los que se expresan esas decisiones en la sección 4, y la arquitectura que separa quién decide de quién aplica la decisión en la sección 5.

La autorización se comprueba en cada acceso, no una sola vez al entrar. Una sesión abierta no es un permiso permanente, y por eso un cambio de grupo o la retirada de un rol deben surtir efecto sin esperar a que el usuario vuelva a identificarse.

Conviene distinguir además entre dos cosas que suelen confundirse. Los permisos se definen sobre el recurso y responden a quién puede leerlo o modificarlo, como el modo de un archivo en Linux o una lista de control de acceso en Windows. Los privilegios son capacidades del sujeto que valen para todo el sistema y a menudo esquivan los permisos, como sudo, las capacidades del núcleo o el privilegio de hacer copias de seguridad. Un usuario sin permiso sobre un archivo puede leerlo igualmente si tiene el privilegio adecuado, de modo que el bastionado de la autorización pasa tanto por revisar los permisos como por limitar quién acumula privilegios.

Dos principios rigen el diseño. La denegación por defecto, según la cual lo que no está permitido está prohibido, y el mínimo privilegio, con cada sujeto limitado a lo que necesita para su tarea, que se desarrolla en la sección 3. Cuando se incumplen, aparece el fallo más frecuente de las aplicaciones web, el del acceso roto, que encabeza la lista OWASP Top 10 y que casi siempre consiste en confundir estar autenticado con estar autorizado.

Es el registro de quién hizo qué y cuándo. Aunque el modelo original la llama Accounting, porque en protocolos como RADIUS sirve para contabilizar el consumo de las sesiones, en seguridad se entiende como la capacidad de reconstruir los hechos y de imputar responsabilidades. Sin trazabilidad no hay detección de intrusiones, análisis forense ni cumplimiento normativo. Exige además cuentas individuales, porque una cuenta compartida impide saber qué persona realizó una acción.

Para que un registro sirva de evidencia tiene que reunir cuatro propiedades:

La imputación exige además mantener el hilo entre la identidad y la acción cuando el usuario cambia de identidad por el camino. En Linux, el identificador de auditoría auid se fija al iniciar sesión y no cambia aunque después se use sudo o su, de modo que un evento con auid=ana uid=root sigue atribuyendo la acción a Ana. En Windows, el identificador de inicio de sesión cumple esa función y enlaza cada evento con la sesión que lo originó. Sin ese hilo, un conjunto de acciones realizadas como root no se puede atribuir a nadie.

Borrar el rastro es uno de los primeros objetivos de quien entra en un sistema, una técnica catalogada en MITRE ATT&CK como Indicator Removal (T1070). Por eso los registros se envían a un sistema independiente, donde quien ha comprometido el equipo ya no puede alterarlos.

Conviene recordar, por último, que estos registros son datos personales. Registrar es necesario, pero no justifica cualquier recogida, así que el alcance debe ser proporcionado, el acceso a los propios registros debe estar controlado y auditado, y el plazo de conservación, definido de antemano. Las obligaciones concretas se tratan en el capítulo de biometría y la puesta en práctica de todo lo anterior, en la guía de trazabilidad y auditoría en Linux.

El propietario del recurso decide quién puede acceder a él. Es el modelo de los permisos de archivos de Linux, de las ACL y de las carpetas compartidas de Windows. En un equipo compartido, quien crea un documento decide quién más puede leerlo o modificarlo, y puede cambiar esa decisión cuando quiera sin consultar con nadie.

Una autoridad central define la política, y ni siquiera el propietario puede modificarla. Cada sujeto y cada objeto reciben una etiqueta, como Confidencial o Secreto, y el sistema compara ambas antes de permitir el acceso. En un servidor, el uso habitual no son las etiquetas militares sino el confinamiento de los servicios, de modo que quien compromete el servidor web no alcanza los archivos que la etiqueta de ese servicio no autoriza, aunque el proceso se ejecute como root.

Los permisos se asignan a roles, que representan funciones de la organización, y las personas obtienen permisos al recibir un rol. En un banco, el rol Cajero permite operar con cuentas y el rol Director permite autorizar préstamos.

La decisión se toma evaluando atributos del sujeto, del recurso, de la acción y del entorno: cargo, departamento, clasificación del documento, hora, ubicación o estado del dispositivo. En un hospital, un médico solo puede consultar los expedientes de los pacientes asignados a su servicio y durante su turno.

En la práctica se combinan: el DAC protege los archivos de cada usuario, el MAC contiene los servicios, el RBAC organiza a las personas y el ABAC añade condiciones contextuales. Este es también el planteamiento de las arquitecturas de confianza cero.

De ese reparto se derivan dos reglas que no admiten excepción. El PEP nunca decide por sí mismo, ni siquiera cuando conoce la respuesta, porque en cuanto empieza a interpretar la política aparece una segunda política implícita que nadie audita. Y el PDP nunca aplica la decisión, de modo que su compromiso no concede acceso de forma directa, sino que falsea las respuestas que otros aplican. NIST SP 800-207 traslada esa frontera a su arquitectura y sitúa el PDP y el PAP en el plano de control, separado del plano de datos por donde circula el tráfico que el PEP vigila.

El diagrama anterior numera los pasos de un acceso completo. Supóngase que la usuaria maria intenta consultar un expediente a través de una pasarela corporativa:

Los atributos pueden llegar al PDP de dos maneras. En el modelo push, viajan dentro de la propia consulta, normalmente en un token firmado por el proveedor de identidad, lo que resulta rápido pero congela el valor en el instante de la emisión. En el modelo pull, que son los pasos 3 y 4, el PDP los consulta en el PIP en el momento de decidir, con lo que obtiene datos frescos a costa de latencia y de una dependencia más. La elección no es inocua, porque un atributo volátil como la postura de un equipo pierde su sentido si se evalúa con el valor que tenía al abrir la sesión.

Un PDP no devuelve únicamente un sí o un no. XACML define cuatro resultados, y los dos últimos concentran la mayoría de los fallos de autorización.

Interpretar el no aplicable como una autorización convierte cualquier hueco de la política en un permiso silencioso. Es lo que se comprueba en el Ejercicio 3, donde pam_time permite el acceso cuando ninguna regla alcanza al usuario, en contra de la denegación por defecto del apartado 2.3.

Cuando varias reglas discrepan, decide el algoritmo de combinación declarado en la política. Los dos habituales son la prevalencia de la denegación, donde un solo «denegar» anula cualquier «permitir», y la primera regla aplicable, donde el orden de escritura forma parte de la política. Por eso en sudoers manda la última regla coincidente y una línea permisiva al final deja sin efecto a las anteriores.

La decisión puede llevar además obligaciones, acciones que el PEP debe ejecutar para que la autorización sea válida, como exigir un segundo factor, conceder el recurso en modo de solo lectura o limitar la duración de la sesión. Un PEP que las ignora concede más acceso del autorizado aunque la decisión fuese correcta.

El vocabulario anterior no describe solo productos corporativos. Los mecanismos que se estudian en el resto del curso encajan en el mismo esquema, y reconocerlo ayuda a saber dónde buscar cuando un acceso no se comporta como se espera.

En un caso tan cotidiano como sudo, las cuatro funciones se distinguen incluso en la línea de órdenes, y cada una tiene su comprobación asociada:

La diferencia entre sudo -l -U maria y la lectura manual del archivo es la que hay entre consultar al decisor y suponer su respuesta. El primero evalúa la política completa, con sus inclusiones y su algoritmo de combinación, que es justo lo que la lectura a ojo suele interpretar mal.

Separar estas funciones permite cambiar la política sin modificar las aplicaciones, centralizar la auditoría de las decisiones y aplicar un criterio homogéneo a servicios muy distintos. La guía de confianza cero despliega esta arquitectura completa en un laboratorio, con una pasarela que actúa de PEP y un motor de políticas que resuelve cada petición, y el capítulo de autenticación centralizada muestra su versión más veterana en los protocolos RADIUS y TACACS+.

Realice los siguientes pasos:

Realice los siguientes pasos:

En el ejercicio anterior el permiso dependía solo del rol. Aquí la decisión dependerá además de un atributo del entorno, la hora del intento, que es lo que caracteriza al control basado en atributos del apartado 4.4. La impone el módulo pam_time, que se estudia a fondo en la guía de PAM.

Realice los siguientes pasos:

En los ejercicios anteriores la decisión dependía del rol o de un atributo del entorno, pero en todos ellos el propietario del archivo conservaba la última palabra sobre sus permisos. Aquí la política la impone el sistema y no la puede levantar ni el propietario ni root, que es lo que caracteriza al control obligatorio del apartado 4.2. Ubuntu incorpora AppArmor activado de serie, de modo que no hay nada que instalar.

Realice los siguientes pasos: