Registro de acceso a archivos Windows: SACL, 4656/4663

¿Qué son las pruebas del registro de acceso a archivos Windows?

Las pruebas del registro de acceso a archivos Windows relacionan la directiva de auditoría efectiva de un servidor, las reglas de auditoría de un archivo y un intento de acceso controlado con los eventos Security resultantes. Un ajuste de directiva de grupo por sí solo no puede establecer esa relación. Antes de cambiar la directiva de producción, utilice archivos ficticios para determinar qué identidades y derechos de archivo generan realmente pruebas en un servidor dentro del ámbito acordado.

Esta guía separa tres preguntas: ¿está habilitado Audit File System en ese servidor, tiene el archivo una lista de control de acceso al sistema (SACL) coincidente y describe el evento registrado la operación que se probó? Mantenga las respuestas juntas en un registro de revisión. Un valor de directiva tranquilizador sin el evento correspondiente deja la prueba incompleta.

El procedimiento siguiente no se ha ejecutado en un dominio real. Los comandos utilizan sintaxis documentada por Microsoft; las rutas y las identidades son ejemplos que deben sustituirse por valores de prueba aprobados. Las observaciones esperadas son criterios de aceptación, no resultados de laboratorio comunicados.

Cómo funciona la auditoría de archivos: directiva, SACL y acceso

La documentación de Microsoft de Audit File System condiciona la auditoría a una SACL coincidente: la cuenta solicitante y el acceso solicitado deben coincidir con sus entradas. La auditoría de éxitos y la de errores sirven para resultados diferentes. Habilitar la subcategoría sin reglas de auditoría de objetos adecuadas no establece cobertura a nivel de archivo. Microsoft también aconseja planificar cómo se analizarán los eventos recopilados y eliminar reglas de auditoría excesivas.

Los permisos del archivo y sus reglas de auditoría tienen funciones distintas. Revise la lista de control de acceso discrecional (DACL) para establecer el acceso permitido o denegado previsto y después revise la SACL para establecer qué intentos deben registrarse. Añadir una regla de auditoría no justifica conceder un derecho de archivo que de otro modo no estaría autorizado.

Elija el ámbito de la prueba antes de realizarla. ¿Qué servidores y derechos de archivo deben demostrarse? Identifique el host, la ruta sintética, la identidad de prueba, la aplicación y la operación. Una lectura local en un servidor miembro respalda ese caso concreto; no establece cobertura para todos los servidores o aplicaciones. Mantenga diferenciada la supervisión de objetos de directorio: nuestra guía de supervisión AD sobre recopilación de eventos, correspondencia de campos y validación explica el proceso más amplio de supervisión de identidades, incluidos los eventos de directorio. Aquí, el objeto probado es un archivo ficticio.

Una solicitud de handle no es un derecho de archivo utilizado

Estas distinciones proceden de las referencias de Microsoft de 4656 y 4663. Cada uno también requiere la entrada SACL pertinente. En este protocolo, una lectura de archivo permitida debe evaluarse frente a un 4663 coincidente; una solicitud de handle denegada debe evaluarse frente a un Failure 4656 coincidente.

Verificación: construir las pruebas antes de remediar

Paso 1: registrar la directiva efectiva en el servidor elegido

Ejecute lo siguiente en el servidor que aloja los archivos ficticios, utilizando una cuenta autorizada para inspeccionar la directiva de auditoría. Microsoft documenta la selección de categorías y subcategorías y la opción de informe CSV en auditpol get:

auditpol /get /subcategory:* /r

Conserve la salida completa con el nombre del servidor, la hora de recopilación y el operador. Localice File System y registre sus ajustes de éxito y error. Para un protocolo que cubra tanto el acceso permitido como el denegado, establezca ambos ajustes antes de esperar ambos tipos de pruebas. Si un modo está deshabilitado, registre esa observación y su consecuencia en lugar de marcar todo el servidor como verificado.

Mantenga la vista GPO como un artefacto separado. Registra la configuración declarada; la consulta local registra la directiva de auditoría del sistema devuelta por ese host. Si una directiva por usuario puede afectar a la identidad de prueba, inspecciónela también mediante el selector /user documentado. Registre cualquier error de permisos como una medición incompleta y no como una directiva vacía o deshabilitada.

Paso 2: inspeccionar las SACL de los archivos ficticios reales

Prepare dos archivos sintéticos mediante la configuración de prueba aprobada, por ejemplo C:\AuditProof\allow.txt y C:\AuditProof\deny.txt. Configure la identidad de prueba para que tenga el derecho seleccionado sobre el primero y no lo tenga sobre el segundo. Inspeccione ambas DACL antes de continuar; no suponga que el nombre de un archivo determina si el acceso está permitido o denegado.

Microsoft documenta -Audit como opción para recuperar datos SACL en Get-Acl. Estos comandos adaptan sus parámetros documentados a las rutas de ejemplo. Ejecute cada línea por separado en Windows PowerShell o PowerShell en Windows:

$allowAcl = Get-Acl -LiteralPath 'C:\AuditProof\allow.txt' -Audit
$allowAcl.Audit
$allowAcl.Sddl

$denyAcl = Get-Acl -LiteralPath 'C:\AuditProof\deny.txt' -Audit
$denyAcl.Audit
$denyAcl.Sddl

Conserve las entradas de auditoría y el descriptor de seguridad devueltos para cada archivo, o el error exacto si falla la inspección. Revise la identidad, los derechos auditados, los indicadores de éxito y error y el ámbito de herencia. Un recuento de entradas no basta: la entrada pertinente debe cubrir esta identidad y esta operación sobre este objeto. Una regla heredada debe evaluarse en el archivo realmente utilizado, no deducirse únicamente de una carpeta principal.

La decisión aquí es concreta: ¿qué SACL cubre la identidad, los resultados y los derechos requeridos sin ruido excesivo ni contenido sensible? Indique los derechos seleccionados y por qué son suficientes para la prueba. Evite ampliar el ámbito solo para obtener más eventos.

Paso 3: ejercitar los casos permitido y denegado por separado

Utilizando la aplicación de prueba elegida bajo la identidad de prueba ordinaria, realice la operación seleccionada sobre allow.txt. Después intente la misma operación sobre deny.txt. Registre las horas de inicio y fin, la aplicación, la identidad, el destino y el resultado observado para cada caso. Evite utilizar al administrador de inspección como identidad de la prueba de acceso; el protocolo debe ejercitar los permisos que se revisan.

En una prueba de lectura, lea realmente el archivo ficticio permitido en lugar de limitarse a seleccionarlo en un selector de archivos. En el caso denegado, registre la denegación de la aplicación e inspeccione las pruebas asociadas de solicitud de handle. Si la denegación ocurre antes de llegar al archivo previsto, el caso todavía no demuestra la auditoría de ese archivo. Mantenga ese resultado visible en el registro e investigue la ruta de acceso.

No espere un número fijo de eventos. Inspeccione el registro Security del host en Event Viewer durante la ventana registrada y filtre por 4656 y 4663. Compare la cuenta, el objeto y los campos de acceso con la ficha de prueba antes de asignar un evento a un caso.

Paso 4: preservar el evento y explicar la decisión

Para cada evento pertinente, conserve su XML original en la ubicación de evidencias aprobada. Microsoft documenta la identidad del sujeto y el identificador de inicio de sesión, el tipo y nombre del objeto, la información del proceso, el identificador de handle y los campos de acceso. En 4663, la lista de acceso describe los derechos utilizados; en 4656 describe los derechos solicitados. Para una lectura de archivo, el derecho ReadData documentado es 0x1; distíngalo de la enumeración de directorios o del acceso exclusivo a metadatos al interpretar el objeto y la operación.

Utilice el identificador de handle para la correlación cuando esté disponible, junto con el host, la hora, el sujeto, el proceso y el objeto. Microsoft indica que el campo de handle puede ser 0x0; no debe ser la única clave de unión. Anote si cada evento conservado respalda la operación permitida o la solicitud denegada y qué sigue sin demostrarse.

Si el contrato de supervisión incluye recopilación central, localice allí el mismo evento y compare sus campos esenciales. Un evento local y un registro utilizable centralmente son elementos de prueba separados. Esta comparación es un paso de validación propuesto, no una afirmación de que un colector concreto preserve esos campos.

Remediación: corregir la carencia demostrada y repetir la prueba (Remediation)

Paso 5: cambiar la directiva o SACL que no superó la verificación

Si falta la auditoría de éxitos o errores de File System, corrija la directiva aplicable al servidor elegido. La documentación de auditpol set permite especificar una subcategoría por nombre o GUID y habilitar cada resultado. En un piloto aprobado con un nombre de subcategoría en inglés, el comando correspondiente es:

auditpol /set /subcategory:"File System" /success:enable /failure:enable

Trátelo como un cambio local en el piloto, conservando los ajustes anteriores para revertirlo. Para un despliegue administrado, corrija la directiva aplicable mediante el proceso de cambios GPO del equipo y verifique de nuevo el estado resultante del host. Una respuesta satisfactoria del comando por sí sola no cierra la carencia de pruebas de acceso a archivos.

En sistemas localizados, utilice el nombre o GUID real obtenido mediante el comando auditpol list documentado por Microsoft:

auditpol /list /subcategory:* /r

Si la directiva está habilitada pero la SACL no coincide, corrija la entrada de auditoría para la identidad de prueba, el derecho y el resultado elegidos mediante el procedimiento aprobado de seguridad de objetos. Preserve la DACL y la SACL original para su revisión. Repita la inspección antes de repetir el acceso; cambiar los permisos de acceso permitido o denegado cambiaría la propia prueba.

Paso 6: resolver las discrepancias de directiva sin declarar éxito

Cuando los ajustes GPO heredados parezcan correctos pero el comportamiento del host difiera, inspeccione la directiva avanzada aplicable y la opción de seguridad de prioridad de las subcategorías. Microsoft documenta SCENoApplyLegacyAuditPolicy como mecanismo que impide aplicar directivas de nivel de categoría. Nuestra guía de directivas de auditoría sobre ajustes efectivos y conflictos entre directivas heredadas y avanzadas aporta el contexto más amplio de configuración.

La decisión sin resolver es qué pruebas conservar cuando falta el evento esperado pese a una configuración heredada tranquilizadora. Mantenga juntos la salida de la directiva local, la SACL real, el resultado de la prueba, la ventana de búsqueda y la ubicación de recopilación. Asigne un responsable a la discrepancia. Después del cambio específico, repita la misma operación y la revisión de evidencias; no sustituya un caso sin resolver por una prueba más amplia y fácil.

Cómo detecta EtcSec este problema

En el commit del colector bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, HDS_5_4_LOG_ACCESS_TO_HEALTH_DATA lee GPOPolicies y sus valores heredados EventAudit.AuditObjectAccess. El proveedor SMB rellena ese campo a partir de [Event Audit] en GptTmpl.inf. Recopila por separado el archivo avanzado audit.csv, pero este Detect() no lo utiliza.

La condición implementada acepta cualquier GPO recopilada no nula con EventAudit no nulo y AuditObjectAccess >= 3. Cuando existe una GPO así, Count es cero. En caso contrario, Count es uno si la colección de directivas GPO no está vacía; una colección vacía también produce Count cero. Aunque el comentario describe que se requiere exactamente 3, la condición ejecutable es >= 3.

Por tanto, una GPO fuera del ámbito del servidor probado puede suprimir el hallazgo. Esta comprobación no observa la directiva efectiva por servidor, las SACL, las rutas de archivo, los intentos de acceso, la clasificación de datos de salud ni los eventos Security. Ni un hallazgo ni Count cero establecen el resultado de este protocolo de validación. Utilice la señal para solicitar pruebas con un ámbito definido y documentar sus límites.

Cerrar la revisión con un veredicto delimitado

Registre un veredicto para cada servidor, objeto, identidad y derecho: demostrado, fallido o incompleto. Incluya los artefactos de directiva y SACL, el resultado real de la aplicación, los eventos pertinentes, cualquier comparación de recopilación central, la decisión de remediación y el resultado de la repetición de la prueba. Indique explícitamente las exclusiones para que quien revise pueda distinguir un caso satisfactorio con un archivo ficticio de una cobertura que nunca se probó.

Fuentes técnicas e implementación del colector revisadas el 4 de octubre de 2026. Los ejemplos siguen siendo un procedimiento que debe ejecutarse con datos ficticios aprobados, sin capturar contenidos de datos de salud.