Windows como sistema de seguridad

La seguridad de Windows está en el contexto de cada decisión

Dos personas pueden abrir el mismo archivo y recibir resultados distintos. Un programa que funciona desde una consola puede fallar cuando lo inicia un servicio. Un usuario que pertenece a Administrators puede ejecutar una aplicación con un contexto estándar y otra con un contexto elevado. Estas diferencias no son excepciones misteriosas: son el resultado de cómo Windows materializa una identidad, la compara con la política del objeto y aplica restricciones adicionales al proceso.

El error profesional consiste en resumir todo eso como «el usuario tiene permisos» o «la cuenta es administradora». Windows no tiene una única propiedad llamada permiso. Tiene sujetos, objetos, tokens, descriptores, privilegios, niveles de integridad, políticas de elevación y fronteras de autenticación. Cada una responde una pregunta distinta.

Este capítulo construye un modelo operativo para seguir una decisión de acceso desde el inicio de sesión hasta la operación concreta. No es una guía de administración ni una lista de configuraciones recomendadas. Su propósito es que el lector pueda explicar por qué una operación fue permitida o rechazada, qué evidencia debe pedir y qué conclusión no está autorizada por una observación aislada.

¿Qué significa ser un principal en Windows?

Un security principal es una entidad a la que Windows puede atribuir decisiones: una cuenta de usuario, un grupo, un equipo, un servicio o una sesión de inicio de sesión. Su identidad operativa se representa mediante un Security Identifier (SID), no mediante el texto que una interfaz muestra como nombre. Un nombre puede resolverse desde una cuenta local o desde un directorio; el SID es el identificador que aparece en los contextos de autorización.

El nombre y el SID cumplen funciones distintas. El nombre facilita la interacción humana y la resolución administrativa. El SID permite que una regla identifique al principal aunque su presentación cambie. La comprobación, sin embargo, no se reduce a buscar un SID: también importan los SIDs de grupos, los privilegios, el nivel de integridad, el tipo de token y el objeto solicitado.

La Local Security Authority (LSA) es el subsistema que participa en la autenticación local, el inicio de sesión y la política de seguridad local. En un entorno con identidad de dominio pueden intervenir servicios y protocolos adicionales. Las aplicaciones suelen usar la Security Support Provider Interface (SSPI) para solicitar servicios de autenticación, integridad o privacidad sin implementar cada proveedor de protocolo. Esta abstracción no transforma autenticación en autorización: sólo establece cómo una aplicación obtiene o usa un contexto autenticado.

Un inicio de sesión satisfactorio produce estado de seguridad que otros componentes consumirán. Para una investigación, la pregunta no es sólo «¿qué nombre se autenticó?», sino «¿qué token recibió el proceso que intenta la operación, a qué sesión pertenece y qué política se aplica en ese momento?». La misma cuenta puede tener tokens diferentes en sesiones o procesos distintos.

El token convierte una autenticación en contexto de proceso

Un access token es un objeto que describe el contexto de seguridad de un proceso o thread. Puede contener el SID de la cuenta, SIDs de grupos, el SID de la sesión de logon, privilegios, propietario, grupo primario, DACL predeterminada y datos sobre el tipo y origen del token. Microsoft documenta el token como el contexto que el sistema usa para identificar al principal cuando un thread interactúa con un objeto protegible o solicita una operación que requiere un privilegio. Microsoft Learn, Access Tokens

El proceso tiene normalmente un primary token. Un thread puede usar además un impersonation token para actuar temporalmente con el contexto de un cliente, algo habitual en servidores que reciben llamadas de otros principales. Por eso preguntar sólo por el usuario que lanzó el proceso puede omitir la autoridad efectiva del thread que ejecuta la comprobación.

Una forma útil de razonar es separar cuatro capas:

• la cuenta o principal que inició una autenticación;
• el token que Windows materializó para una sesión o proceso;
• la operación y el objeto que el thread intenta usar;
• la decisión resultante, incluidos privilegios y restricciones adicionales.

El token es estado materializado, no una consulta permanente a la base de cuentas. Si cambia una membresía después de crear una sesión, no debe suponerse que todos los procesos existentes adoptan de inmediato un token nuevo. La comprobación profesional debe capturar el proceso, su token y el momento, además de la configuración de la cuenta.

Grupos, privilegios y autoridad no son sinónimos

Los SIDs de grupo amplían el conjunto de identidades que una DACL puede reconocer. Un privilege es una autorización especial del sistema, representada en el token, que puede permitir ciertas operaciones administrativas que no se modelan como un permiso ordinario de archivo. Los privilegios también tienen atributos, como estar habilitados o no, y su presencia no implica que cada API los use automáticamente.

Así, «está en Administrators» es una observación de pertenencia que no describe por completo el token efectivo. «Tiene SeBackupPrivilege» es una observación de privilegio que no explica qué código lo habilitó, qué objeto se solicitó ni qué operación concluyó. En una revisión hay que obtener la información del token y vincularla con la llamada o el servicio que la utiliza.

El objeto aporta la otra mitad: security descriptor y ACL

Un objeto protegible —por ejemplo, un archivo, una clave de registro, un proceso, un servicio o un recurso expuesto por el sistema— puede tener un security descriptor. El descriptor puede contener el SID del propietario, el grupo primario, una Discretionary Access Control List (DACL), una System Access Control List (SACL) y bits de control. La DACL expresa permisos permitidos o denegados para trustees; la SACL define qué intentos pueden auditarse. Una Access Control Entry (ACE) vincula un SID con derechos permitidos, denegados o auditados. Microsoft Learn, Security Descriptors

La DACL no es una tabla abstracta de «seguro/inseguro». Sus ACE expresan derechos concretos del tipo de objeto. Leer atributos, escribir contenido, cambiar permisos, iniciar un servicio o abrir un proceso no son necesariamente la misma operación. Los derechos genéricos de una API deben mapearse al conjunto específico que el objeto entiende.

La herencia añade otra fuente de error. Una ACE que aparece en el descriptor de una carpeta puede haber sido heredada por un archivo; una ACE explícita puede tener un alcance o una excepción diferente. Para afirmar que un principal puede escribir un archivo hay que comprobar el descriptor efectivo del archivo, la ruta relevante, la operación solicitada y cualquier restricción del entorno, no sólo la ACL visible en una carpeta padre.

¿Cómo se decide un acceso?

Alcance: operación, objeto, token y momento concretos.

Un access check recibe, al menos conceptualmente, un access token, un security descriptor, una máscara de acceso solicitada y el tipo de objeto. AccessCheck compara el descriptor con el token y devuelve si los derechos solicitados están permitidos; su propia documentación insiste en que la comparación se hace para el cliente y la máscara concretos. Microsoft Learn, AccessCheck

El algoritmo documentado para la autorización recorre las ACE relevantes de la DACL. Una ACE sólo participa si su SID está en el contexto de autorización del token; las concesiones satisfacen derechos pendientes y una denegación aplicable puede hacer fallar la solicitud. La especificación MS-DTYP, sección 2.5.3.2 describe el pseudocódigo y sus casos de DACL nula o vacía. No conviene memorizar la regla como «la primera ACE gana» sin considerar canonicalización, herencia, tipo de acceso y la solicitud concreta.

Un ejemplo sintético ayuda a mantener las fronteras. Supongamos que un proceso con SID de una cuenta de análisis y SID de un grupo Informe solicita FILE_READ_DATA sobre D:\Informes\enero.csv. El descriptor del archivo permite lectura al grupo Informe, pero contiene una denegación explícita para el SID de la cuenta. La conclusión no es que «la cuenta tiene acceso porque pertenece al grupo», ni que «el archivo está bloqueado»: hay que reconstruir qué ACE son aplicables, en qué orden efectivo, qué derechos pide la API y si hay restricciones adicionales. El resultado sólo habla de esa operación sobre ese objeto en ese momento.

La DACL tampoco resume todas las formas de autoridad. Una API puede requerir un privilegio; un driver puede imponer una comprobación propia; un servicio puede autorizar dentro de su protocolo después de que el sistema haya permitido abrir un handle. Windows aporta un modelo de control de acceso, pero la propiedad de seguridad final pertenece a la composición entre kernel, servicio, aplicación, configuración y entorno.

MIC añade una frontera obligatoria

Alcance: UAC split-token e impersonation dependen de política y contexto.

El Mandatory Integrity Control (MIC) introduce niveles de integridad para principales y objetos. Windows define niveles como low, medium, high y system. El nivel del principal se representa en el token y el del objeto mediante una etiqueta obligatoria en el descriptor. MIC se evalúa antes del control de acceso discrecional de la DACL; la política puede impedir, por ejemplo, que un proceso de menor integridad escriba en un objeto de mayor integridad aunque una ACE discrecional parezca conceder la escritura. Microsoft Learn, Mandatory Integrity Control

Esta separación evita una confusión común: una DACL pregunta qué derechos discrecionales puede obtener un principal; MIC impone una relación de protección que la DACL no puede relajar por sí sola. Un navegador ejecutado con integridad baja y un editor con integridad media pueden pertenecer al mismo usuario, pero no tienen la misma capacidad de modificar los objetos del usuario.

MIC tampoco es una clasificación de confianza total. Un nivel high no significa que el proceso sea correcto o que todas sus entradas sean confiables; sólo describe una posición en el mecanismo de integridad y las políticas asociadas. Tampoco sustituye el aislamiento de un proceso, una DACL bien diseñada, la validación de entradas o el control de una interfaz de servicio.

UAC separa el uso cotidiano de la elevación

User Account Control (UAC) reduce el uso rutinario de privilegios administrativos y solicita aprobación o credenciales cuando una operación necesita un contexto más elevado. En Admin Approval Mode, un administrador interactivo puede iniciar aplicaciones con un token estándar y obtener un token administrativo separado durante una elevación aprobada. Los procesos iniciados desde el contexto estándar heredan ese contexto; la elevación crea una transición que debe poder observarse. Microsoft Learn, How User Account Control works

UAC no significa que cada ventana tenga una frontera aislada ni que aprobar un cuadro de diálogo valide la intención del binario. Es un mecanismo de reducción de privilegio y consentimiento. Si el usuario aprueba una aplicación maliciosa o un proceso elevado expone una interfaz débil, la elevación puede producir precisamente la autoridad solicitada. UAC tampoco convierte una cuenta estándar en administradora ni prueba que una operación de negocio sea correcta.

Para diagnosticar un fallo, compara el token del proceso no elevado con el del proceso elevado, su nivel de integridad, sus SIDs y privilegios, y el objeto que cada uno intenta usar. El mensaje «Access is denied» puede resultar de una DACL, MIC, privilegio ausente, política de servicio o una ruta diferente; la apariencia de un escudo UAC no identifica la causa.

Autenticación local, autenticación remota y autorización

En Windows, la autenticación local y la remota atraviesan fronteras distintas. La arquitectura de autenticación incluye proveedores como Negotiate, Kerberos, NTLM y Schannel; las aplicaciones pueden acceder a ellos mediante SSPI. Windows Authentication Architecture describe a LSA como componente que valida inicios de sesión y ofrece servicios de política y traducción de nombres a SIDs.

Que un servidor autentique a un cliente no decide automáticamente qué recurso puede usar. El servidor debe convertir la identidad recibida en un contexto que su objeto, servicio o política pueda evaluar. En una llamada RPC, además, un thread puede usar impersonation para aplicar la identidad del cliente en vez del primary token del proceso servidor. Un bug de delegación o una comprobación ejecutada con el token equivocado puede crear una decisión incorrecta aunque el protocolo de autenticación haya funcionado.

Las cuentas locales administrativas presentan otra frontera: UAC puede filtrar el token en conexiones de red. Microsoft documenta que las restricciones de Remote UAC afectan qué privilegios recibe una cuenta local en interfaces de administración remota y que cambiar la política de filtrado modifica ese riesgo. Microsoft Learn, Local accounts Por eso no debe extrapolarse «puedo administrar localmente» a «la misma cuenta tiene la misma autoridad por red».

SACL y auditoría: visibilidad con alcance

Alcance: la auditoría no reemplaza autorización ni confirma por sí sola el resultado de negocio.

La SACL controla qué intentos de acceso generan auditoría para un objeto. Los registros resultantes pueden aportar evidencia de quién, qué proceso, qué objeto y qué resultado reportó el sistema, siempre que la política, la configuración de auditoría, la retención y la integridad de los registros sean adecuadas. Una SACL no concede ni revoca permisos: esa función corresponde a la DACL y a otros mecanismos de autorización.

Tampoco es correcto tratar un evento de auditoría como copia perfecta de la operación de negocio. Un registro puede describir un intento, una apertura de handle o una decisión intermedia, mientras la aplicación falla después al validar datos o confirmar una transacción. La propia documentación de AccessCheck diferencia la comprobación de acceso de las funciones que además generan auditoría. Microsoft Learn, Access Control Lists

La pregunta profesional es «¿qué observación produce este evento y qué transición no observa?». Correlacionar proceso, identificador, objeto y tiempo ayuda, pero no elimina límites de cobertura. Una ausencia de registro puede deberse a una SACL no aplicable, una política no habilitada, una ruta distinta, retención vencida o una falla de recolección. No permite afirmar por sí sola que el acceso no ocurrió.

Caso conductor: un servicio que genera un archivo de informes

Considera un caso sintético. Un servicio de Windows genera D:\Informes\diario.csv. El equipo dice: «el servicio es seguro porque se ejecuta como una cuenta dedicada y la carpeta sólo permite acceso al grupo de analistas».

La frase mezcla varios claims. Primero hay que identificar el servicio, su binario, su cuenta, el proceso concreto y el token que usa. La cuenta dedicada puede reducir autoridad, pero no explica sus SIDs suplementarios, privilegios, handles heredados, nivel de integridad o capacidad de iniciar otros procesos. Después hay que leer el descriptor efectivo de la carpeta y del archivo: propietario, DACL, ACE heredadas, derechos de creación y derechos para cambiar permisos. Finalmente hay que preguntar cómo el servicio recibe solicitudes y si su propia lógica autoriza el nombre y contenido del informe.

Supón que una cuenta de analista puede leer el archivo, pero también puede modificar la carpeta y cambiar el descriptor del archivo. El claim «sólo analistas leen» no equivale a integridad de los informes: la misma autoridad puede permitir reemplazar el contenido o conceder acceso a otro principal. Supón también que el proceso del servicio crea el archivo con un token que contiene una DACL predeterminada más amplia de lo esperado. La política de la carpeta no basta para describir el objeto resultante.

Un plan de verificación razonable sería capturar la configuración del servicio y el proceso, consultar el token, obtener los descriptores de carpeta y archivo, solicitar explícitamente lectura y escritura como principal permitido y como principal de control, y comprobar qué eventos de auditoría se producen. La conclusión debe decir qué objeto y operación se probaron. No puede generalizarse a todos los archivos del host, a una cuenta de dominio distinta, a un cambio de política futuro ni a la lógica completa del servicio.

Errores frecuentes en trabajo profesional

«Está en Administrators, por tanto puede hacerlo todo». Confunde membresía, token, privilegios, UAC, MIC y la operación concreta. Un administrador no elevado puede usar un token filtrado; una operación puede requerir un privilegio no habilitado; un servicio puede imponer una política propia.

«La DACL dice que tiene acceso, por tanto la escritura funcionará». Falta la máscara exacta, la ruta, la herencia, MIC, el privilegio requerido, el estado del objeto y la validación de la aplicación. Una ACE es una premisa del access check, no un resultado universal.

«El prompt de UAC demuestra que el programa es confiable». UAC muestra una transición de privilegio y solicita una decisión; no certifica la intención ni la corrección del binario. La propiedad a evaluar es qué autoridad recibió el proceso y qué hizo con ella.

«La autenticación funcionó, así que la autorización también». Autenticación establece o valida un principal. La autorización compara el contexto efectivo con la política del objeto o servicio. Entre ambas puede haber impersonation, delegación, token filtrado y reglas de aplicación.

«No hay evento de auditoría, así que no hubo acceso». La ausencia puede reflejar cobertura de SACL, política, retención o recolección. La conclusión correcta puede ser «no hay evidencia en esta fuente y ventana», no «el acceso no ocurrió».

«El descriptor de la carpeta es la seguridad del archivo». La herencia y las ACE explícitas pueden divergir; además, la aplicación puede crear objetos con una DACL predeterminada diferente o gestionar una autorización adicional.

Método para analizar un access claim

Cuando una revisión afirma que «la cuenta X puede leer el recurso Y», reconstruye la cadena siguiente:

1. Fija host, versión, dominio o fuente local, momento y operación exacta.
2. Identifica el principal y el proceso o thread que realiza la operación.
3. Obtén el primary token y, si aplica, el impersonation token: SID, grupos, privilegios, tipo e integridad.
4. Identifica el objeto real, su ruta o nombre interno y el security descriptor efectivo.
5. Separa owner, DACL, SACL, herencia, derechos solicitados y resultado del access check.
6. Comprueba MIC, privilegios, UAC, política de servicio, driver o intermediario que añada una condición.
7. Repite con un control positivo y uno negativo definidos por la misma operación.
8. Correlaciona auditoría y estado posterior sólo hasta donde la procedencia, cobertura y retención permitan.
9. Formula el claim con sus precondiciones y declara qué cambios obligarían a repetir la prueba.

El orden evita dos errores opuestos. No debes reducir la decisión a un listado de ACL si el proceso tiene un contexto diferente. Tampoco debes atribuir todo a UAC o al kernel sin inspeccionar el descriptor y el protocolo de aplicación. La evidencia tiene que conservar la transición completa, no sólo la etiqueta final de «permitido» o «denegado».

Límites del modelo

El modelo de tokens y descriptores es central para los objetos protegibles de Windows, pero no describe por sí solo cada frontera. El firmware, el hipervisor, los drivers, la cadena de actualización, el hardware de seguridad, los servicios remotos, los dispositivos de red y la lógica de negocio pueden cambiar el claim. Una aplicación puede copiar un dato después de una lectura legítima; un proceso privilegiado puede usar una interfaz no prevista; una política de dominio puede modificar una configuración local; una credencial puede tener validez diferente según el protocolo.

Las protecciones de LSA son un ejemplo de control acotado. Microsoft describe la protección adicional de LSASS para impedir que procesos no protegidos lean su memoria o inyecten código. Configure added LSA protection Esa medida puede reducir una clase de exposición de credenciales, pero no prueba que las credenciales no se hayan obtenido por otra ruta ni que las decisiones de autorización posteriores sean correctas.

Por la misma razón, no hay una configuración universal que convierta a Windows en «seguro» sin condiciones. El claim debe especificar edición y versión relevantes, configuración de política, tipo de sesión, identidad, objeto, operación, controles ambientales y ventana de observación. Si cambia cualquiera de ellos, la evidencia puede seguir siendo útil como premisa histórica, pero no se extiende automáticamente a la nueva situación.

Síntesis

Windows construye decisiones de seguridad componiendo estados y políticas. La autenticación y LSA participan en la creación de un contexto; el access token materializa identidad, grupos, privilegios e integridad; el security descriptor describe propietario, DACL, SACL y control; el access check compara token, descriptor y operación; MIC y UAC añaden fronteras obligatorias y de elevación; la auditoría aporta observaciones con cobertura limitada.

El mecanismo importante no es una etiqueta de administrador ni una pantalla de consentimiento, sino la relación concreta entre sujeto, token, objeto, política y transición. Una conclusión profesional conserva esa relación y sus límites. Si sólo se observa un nombre, una pertenencia, una ACE o un registro, todavía falta reconstruir el contexto que hace que esa evidencia responda la pregunta.

Comprobación de comprensión

1. Reconstruye la cadena desde un inicio de sesión hasta el access check de una lectura de archivo. ¿Qué cambia si el thread usa un impersonation token?
2. Compara SID, nombre de cuenta y grupo. ¿Qué puede afirmar cada uno y qué no puede afirmar sobre la autoridad efectiva?
3. Un access token contiene un SID de grupo que aparece en una ACE de lectura, pero la operación de escritura falla. Enumera tres condiciones que debes comprobar antes de adjudicar la causa.
4. Explica por qué MIC puede impedir una escritura aunque la DACL parezca concederla. ¿Qué relación de niveles debes observar?
5. Un administrador abre una consola sin elevación y desde otra ventana ejecuta una herramienta elevada. ¿Qué evidencia pedirías para distinguir sus contextos?
6. Un registro de auditoría muestra un intento de apertura exitoso, pero el servicio no produjo el resultado esperado. Separa observación, inferencia e impacto posible.
7. Una cuenta local administra el host de forma interactiva pero no puede usar la misma operación por red. Formula una hipótesis relacionada con filtrado de token y qué prueba la falsaría.
8. Diseña un claim acotado para afirmar que un servicio sólo puede escribir informes en una carpeta. Incluye token, descriptor, operación, controles y límites.

Problema de transferencia

Un equipo afirma: «La aplicación de nóminas está protegida porque sólo los administradores pueden abrir la carpeta, UAC está activado y tenemos auditoría». Redacta una evaluación profesional sin aceptar ni rechazar la frase como un todo. Elige una operación concreta, identifica el proceso y el token, reconstruye el descriptor y las políticas relevantes, separa MIC, privilegios y UAC, y especifica qué probaría la auditoría. Incluye un control positivo, uno negativo y al menos dos condiciones que dejarían fuera de alcance la conclusión, como una interfaz remota, otro proceso elevado o una copia de los datos creada por la aplicación.

Fuentes principales

• Microsoft. Parts of the Access Control Model.
• Microsoft. Access Tokens.
• Microsoft. Windows Authentication Architecture.
• Microsoft. Security Descriptors y Access Control Lists.
• Microsoft. AccessCheck y MS-DTYP Access Check Algorithm Pseudocode.
• Microsoft. Mandatory Integrity Control.
• Microsoft. How User Account Control works.
• Microsoft. Configure added LSA protection.