SIDs, GUIDs, DACLs, ACEs ¿Qué Son y Cómo Se Relacionan?

A diferencia de la mayoría de las notas de este blog esta vez no voy a mostrar ningún procedimiento paso a paso, sino que vamos a revisar algunos conceptos básicos de seguridad en ambiente de red

Me enfocaré en los conceptos, términos y siglas de ambiente Microsoft ya que es lo que conozco con un poco de profundidad

Conocer cómo funcionan los procesos de autenticación y autorización en ambiente Microsoft es fundamental para comprender ciertos procesos y no incurrir en errores básicos como por ejemplo que “si se llama igual” es “el mismo”

Además de comprender algunos funcionamientos servirá para interpretar algunas de las siglas y términos usados comunmente

Comenzaré desde lo más básico como es el proceso de acceso a recursos, y noten que no estoy nombrando «recursos de red” o “recursos locales” ya que el procedimiento es muy similar

Ya que los sistemas se manejan con el concepto de seguridad “¿quién eres? ¿qué acciones puedes hacer a este objeto?” el acceso a un recurso, sea éste archivo, carpeta, impresora, etc. requiere dos procesos, que aunque muchas veces se confundan con uno único, en realidad son dos, y totalmente independientes: Autenticación y Autorización

El primero verifica la identidad, si eres realmente quien dices ser, mientras que el segundo es qué puedes hacer con el objeto, ya sea crear, modificar, borrar, etc. comunmente conocidos como Permisos o Derechos

Aprovecho para aclarar la diferencia entre estos: un Permiso siempre es sobre un objeto en particular, mientras que un Derecho es sobre un sistema. Ejemplos que pueden ayudar a comprender la diferencia, Permiso sobre un archivo, pero Derecho para cambiar la fecha y hora de una máquina

Inclusive una diferencia mayor, mientras que un Permiso está en el objeto protegido, un Derecho está en las credenciales de la cuenta, ya veremos de qué se trata esta credencial

 

Autenticación

Comencemos por el primero de los conceptos: Autenticación, o Autentificación, es lo mismo, varía la forma de expresarlo de acuerdo al país :)

Este proceso es para verificar la identidad, y está basado en conocer una relación correcta entre dos objetos: conocer el nombre de una cuenta y su correspondiente y secreta contraseña. Si esta correspondencia es correcta entonces el sistema puede verificar que el que conoce el correspondiente secreto realmente es el titular de la cuenta

Estoy planteando el problema de la forma más básica posible, sin tener en cuenta procesos que requieran más de una prueba de conocimiento de datos secretos de la cuenta

El proceso básico es cuenta/contraseña, pero se aplica también en forma general por ejemplo con Certificados Digitales: que el que tenga la “Clave Pública” tenga además la correspondiente “Clave Privada”

Volvamos al caso cuenta/contraseña, y para que ser lo más claro posible de ahora en adelante a esta relación la llamaré usuario/contraseña, ya que es más fácil asimilar un usuario a una persona en particular

Si alguien dice llamarse, por ejemplo, “Guillermo” e ingresa su correspondiente contraseña, el sistema debe verificarlo, pero se encuentra con un problema porque “Guillermo” es un nombre compartido por miles o millones de personas, y por lo tanto identificar a cuál de todos los “Guillermo” corresponde y verificar su contraseña se torna en algo complejo y además inseguro, ya que podría darse el caso de dos “Guillermo” diferentes pero que utilizan la misma contraseña

Para evitar esto, al crear la cuenta propia «Guillermo», a esta el sistema le asigna, análogamente a la realidad, un pseudo número de documento de identidad, sólo que en lugar de llamarlo, por ejemplo DNI, se llama SID “(“Security ID”) único e irrepetible

Al ser el SID único e irrepetible, el sistema puede diferenciar cada cuenta aunque se llame igual, y es algo que confunde al que no conoce este funcionamiento y piensa que “si se llaman igual”, “son el mismo” ¡Error! :)

Aclaración, la no confusión con dos «Guillermo» diferetes es al momento de verificar la autorización. El sistema no permite dos usuarios que tengan el mismo nombre de inicio de sesión, o en el caso de Dominio que tengan el mismo «Full Name»

Por lo tanto si se borra una cuenta, y se la vuelve a crear con el mismo nombre, es otra diferente, porque tendrá diferente SID (Único e irrepetible)

Para ver el tema con un poco más de detalle se debe considerar algo muy importante y es que el sistema asigna un SID único, a cada objeto al cual luego se le pueden asignar permisos, por ejemplo cuentas de usuario, cuentas de máquinas y grupos locales o de Dominio

Para conocer cómo se asegura el sistema que el SID sea único e irrepetible debemos ver cuál es su estructura de formación. Si alguien de los que lee esto no está familiarizado puede ver algo simplemente mirando el contenido REGEDIT en HKEY-USERS donde podemos ver los SIDs del usuario que ha iniciado sesión

El motivo por el que aparecen varios, es simplemente porque no sólo está el “SID del usuario” sino además los SIDs de algunos grupos predefinidos a los cuales pertenece

Observen que todos comienzan con “S-1-5-…” esto se debe a que esta nomenclatura indica que es un identificador de seguridad (S), revisión (1), una clase de identidad de la autoridad que lo otorgó (5 = SECURIY_NT_AUTHORITY), y luego continuan una larga serie de números que básicamente identifican qué instancia en particular lo emitió, salvo lo que queda luego del último “-“ que consiste en un identificador relativo que se incrementa en cada otorgamiento, y que normalmente es lo que se llama el RID (“Relative IDentifier”)

La secuencia de números entre esta primera parte y la última es también una secuencia única que identifica a la máquina si la cuenta es local, o al Dominio si la cuenta es de Dominio. Todos los SIDs otorgados por una determinada autoridad comparten esta secuencia de números

Me adelanto a la pregunta ¿y por qué hay algunos mucho más cortos en extensión? esto es así porque hay SIDs predefinidos y estandarizados que corresponden a conjuntos o grupos válidos en todos los sistemas

Para quien quiera profundizar en detalles dejo enlaces relativos a esta información:

Security Identifiers Technical Overview
https://technet.microsoft.com/en-us/library/dn743661(v=ws.11).aspx

SID Components (Windows)
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379597(v=vs.85).aspx

Well-known SIDs (Windows)
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379649(v=vs.85).aspx

Well-known security identifiers in Windows operating systems
https://support.microsoft.com/en-us/help/243330/well-known-security-identifiers-in-windows-operating-systems

Entonces resumiendo lo visto hasta ahora: durante la creación de un objeto al cual luego se le pueden dar permisos y/o derechos sobre un objeto o sistema, se le asigna un identificador único e irrepetible llamado SID

En ambiente Microsoft anteriormente con esto alcanzaba para la identificación única de una cuenta, pero el problema surgió a partir de Windows 2000 cuando comenzó la posiblidad de mover cuentas entre diferentes Dominios, ya que como vimos antes hay una parte de la secuencia que identifica el Dominio, esta parte de la secuencia debe cambiar, y por lo tanto se perdería la trazabilidad del objeto

Y por lo tanto a partir de Windows 2000, y además del SID se le asigna al objeto un Identificador Universal +Único (UUID = “Universally Unique IDentifier”) que en ambiente Microsoft es llamado GUID (“Global Unique IDentifier”) y que queda asociado el objeto de manera indisoluble y nunca cambia, aunque la cuenta sea movida desde un Dominio a otro diferente y cambie el SID

Más información sobre los UUID puede ser consultada en:

Universally unique identifier – Wikipedia
https://en.wikipedia.org/wiki/Universally_unique_identifier

SID vs. GUID
https://technet.microsoft.com/en-us/library/cc961625.aspx

Y para ir completando el tema, en el momento en que una cuenta es autenticada, verificada su identidad, hay componentes en el sistema operativo que comienza su trabajo posterior

Todos hemos visto, y si no fue así revisen, que en el Administrador de Tareas hay un proceso que siempre se está ejecutando que se llama LSASS.EXE y su nombre es una abreviatura de “Local Security Authority Security Subprocess” que es encargado de todo lo que es la seguridad local de la máquina

Luego de verificada la autenticación es el encargado de crear una credencial de acceso, que será presentada para cada acceso que requiera un proceso creado por el usuario

Esta credencial se llama comunmente “Access Token”, es creada durante la autenticación, y nunca es actualizada mientras esté iniciada la sesión

Una copia del “Access Token” del usuario se adjunta a cada proceso iniciado por la cuenta de usuario

Es muy importante desde el punto de vista seguridad tener en cuenta que en ningún caso el “Access Token” se transmite por la red, y sus contenido está almacenado siempre en memoria RAM no paginable

Cuando se accede a un recurso remoto, en otra máquina, esta última debe hacer una autenticación del usuario y luego crea el localmente otro “Access Token” para acceder a sus recursos

Esta credencial incluye información como SID, GUID, nombre, SIDs de los grupos a los que pertenece la cuenta, si tiene algún Derecho asignado, y aún más

 

Autorización

Cada vez que se va a acceder a un objeto, aún algo tan simple como leer o ejecutar un archivo, un componente de la LSASS llamado SRM (“Security Reference Monitor”) se encarga de comparar este “Access Token” con la lista de permisos que reside en la metadata del objeto, y ver si está autorizado a la operación que se va a efectuar, y en este caso ya pasamos a la segunda parte del proceso: Autorización

Cada objeto tiene asignados permisos, quién puede y qué puede, ya sea que los asignamos manualmente o fueron asignados por omisión por el propio sistema

En los metadatos del objeto, hay una estructura llamada ACL (“Access Control List”), que a su vez está dividida en dos partes:

• DACL (“Discretional Access List”) que contiene los permisos y acciones
• SACL (“System Access List”) que contiene la configuración de la auditoría de seguridad del objeto

Me ocuparé sólo de la DACL ya que estamos con el tema permisos. Ésta contiene, entre otros datos que no vienen al caso actual, diversas entradas como si fuera una lista, que de hecho la es, y cada entrada llamada ACE (“Access Control Entry”) indica si es un “permitido” o un “denegado”, sobre qué permiso en particular, y a quién se aplica

Cuando se requiere autorización de un proceso a un objeto, como habíamos comentado, el SRM local se encarga de comparar cada una de los datos del “Access Token” en forma secuencial contra cada una de de las ACE del objeto, hasta que encuentra un “denegado” o “permitidos” que autoricen el tipo de acceso solicitado

Siempre las entradas que deniegan el permiso están al principio de la DACL del objeto, y eso explica el motivo por el cual los “denegados” prevalecen sobre los “permitidos”

Además cuando hay permisos como los de seguridad (NTFS) que son específicos del objeto, y además otros heredados de la carpeta superior, siempre se evalua primero la DACL del objeto, y recién luego la DACL de herencia. Y esto explica por qué los permisos específicos siempre prevalencen sobre los heredados, aunque estos deniegen

Aclaro que los permisos de compartido (“Share”) no están en el objeto en sí mismo, sino que se leen desde el Registro de la máquina

Agrego unos enlaces a notas de este blog donde ya he tratado el tema de la combinación de permisos de seguridad y de compartido y cómo se llega al permiso efectivo

Permisos – Permisos Efectivos | WindowServer
https://windowserver.wordpress.com/2011/04/30/permisos-permisos-efectivos/

Windows Server 2012 (R2): Compartir Carpetas – Permisos de Seguridad Combinados | WindowServer
https://windowserver.wordpress.com/2014/09/24/windows-server-2012-r2-compartir-carpetas-permisos-de-seguridad-combinados/

 

Creo que con lo visto ya hay un panorama que permite una visión global del tema, y además he dejado enlaces sobre el tema para quien quiera profundizar sobre los detalles, así que dejo acá que el tema es tedioso :)