La cobertura PSO de cuentas de servicio: verificar cada cuenta

Qué debe demostrar la cobertura PSO de cuentas de servicio

La cobertura PSO de cuentas de servicio es la evidencia de que cada identidad de servicio incluida en el alcance se ha revisado según su modelo real de gestión de credenciales y la configuración base de contraseñas aprobada. Para un usuario de dominio tradicional que ejecuta un servicio, esto significa leer el Password Settings Object (PSO) resultante, o registrar la política predeterminada del dominio cuando no se aplica ningún PSO. Encontrar una política vinculada a una cuenta de servicio no permite establecer la cobertura del resto de la población.

El entregable práctico es una matriz: cuenta, servicio, responsable, PSO resultante, evidencia de la política predeterminada del dominio y decisión sobre la excepción. Mantenga visibles los fallos de recopilación en esa matriz. Una política inaccesible es una carencia de evidencia sin resolver; no debe convertirse silenciosamente en «protegida» o «sin política».

Esta distinción importa al interpretar un hallazgo automatizado. La implementación de etc-collector revisada aquí pregunta si alguna cuenta de servicio seleccionada tiene un vínculo FGPP que cumpla los criterios. No determina si cada cuenta seleccionada recibe una política resultante aprobada. Por tanto, la ausencia de un hallazgo requiere una revisión de cobertura antes de respaldar una decisión de cierre.

Diferencia entre un vínculo de política y una política resultante

La referencia de Microsoft de Get-ADUserResultantPasswordPolicy identifica msDS-ResultantPSO como el atributo de política resultante. Las asignaciones directas tienen prioridad sobre las políticas vinculadas a grupos. Dentro del nivel aplicable, gana el valor más bajo de msDS-PasswordSettingsPrecedence; los valores iguales se resuelven mediante el objectGUID más bajo, como especifica el algoritmo de Microsoft del PSO resultante. Por tanto, un vínculo de política candidata no demuestra qué política gana.

La revisión de cobertura debe conservar la identidad y los parámetros de la política devuelta en lugar de deducir la ganadora a partir de un nombre de grupo. Si una política vinculada a un grupo, aparentemente sólida, coexiste con otra asignación directa, investigue el objeto resultante antes de aceptar el grupo como evidencia de protección. Es un ejemplo de razonamiento, no un informe de una configuración incorrecta observada.

Otra cuestión es qué identidades deben incluirse en la revisión. Las directrices de Microsoft sobre cuentas de servicio distinguen las cuentas de servicio basadas en usuarios de dominio tradicionales de las identidades administradas y virtuales. Describen la gestión automática de contraseñas gMSA y no establecen una longitud mínima universal para las cuentas de servicio. La revisión debe preservar estas diferencias en lugar de tratar cada nombre que parezca de servicio como un usuario ordinario con una contraseña mantenida manualmente.

Detección y verificación: construir la matriz de cobertura

1. Acordar la población con los responsables de los servicios

Parta del inventario de servicios y concílielo con los candidatos del directorio. Registre el identificador estable de la cuenta, los servicios asociados, el responsable operativo, el estado de habilitación, el tipo de identidad y la responsabilidad de gestión de credenciales. Cuando una cuenta dé servicio a varias aplicaciones, conserve todas las dependencias en lugar de elegir un único nombre de servicio conveniente.

La lista de candidatos del detector es una entrada útil, pero no constituye el inventario de servicios de referencia. Una heurística de nombres puede incluir usuarios sin relación y omitir un servicio que se ejecute con un nombre inesperado sin SPN. Resuelva estas diferencias con los responsables. Nuestra revisión de nombres de cuentas y comprobaciones de políticas efectivas explica por qué los nombres seleccionan candidatos sin demostrar la debilidad de una contraseña; utilice ese tutorial existente para la investigación más amplia de los nombres.

Mantenga visibles las cuentas deshabilitadas con una resolución separada: conservadas por una razón documentada, pendientes de retirada o excluidas de la configuración base de servicios activos con aprobación. No cuente la política de una cuenta deshabilitada como evidencia de que la población de servicios activos está cubierta. El detector no hace esa distinción.

Para las identidades administradas, la capacidad de filtrado documentada de Get-ADServiceAccount permite esta adaptación de inventario de solo lectura:

Get-ADServiceAccount -Filter * -Server dc01.contoso.com

La orden devuelve objetos de cuentas de servicio administradas, no un inventario completo de todos los servicios ni de las cuentas de servicio basadas en usuarios tradicionales. Use la identidad y el tipo del objeto para conciliar los resultados con el inventario de servicios. No solicite material de contraseñas administradas para esta revisión. Registre las gMSA bajo su ruta de revisión de credenciales administradas en lugar de marcarlas como defectuosas únicamente porque un campo PSO de usuario tradicional esté vacío o no sea aplicable.

2. Leer una política resultante para cada cuenta de usuario tradicional

Ejecute la siguiente adaptación documentada de los parámetros de identidad y servidor para cada cuenta de servicio aprobada basada en un usuario tradicional, sustituyendo el DN y el controlador de dominio ilustrativos por el destino verificado:

Get-ADUserResultantPasswordPolicy -Identity "CN=svc-sql,OU=Service Accounts,DC=contoso,DC=com" -Server dc01.contoso.com -ErrorAction Stop

La referencia del cmdlet documenta estos parámetros, la gestión común de errores y los errores de permisos del directorio. Conserve la orden, la identidad consultada, el servidor, la marca de tiempo, el objeto devuelto y el registro de error. Una respuesta satisfactoria con un objeto de política proporciona la identidad y los parámetros del PSO resultante. Un error aporta evidencia de una lectura fallida; no aporta ningún veredicto sobre la cobertura de políticas.

Repita la lectura para cada cuenta de la población de usuarios tradicionales. Conserve las filas satisfactorias cuando otra cuenta falle y mantenga abierta la fila fallida. No convierta una llamada fallida en un valor de política nulo dentro de una exportación, ni omita las filas fallidas del denominador. Toda automatización que recopile la matriz debe incluir un campo de estado de lectura distinto junto al campo de política.

3. Registrar la política predeterminada del dominio y explicar los vínculos en conflicto

Use el ejemplo de identidad y el parámetro de servidor documentados por Get-ADDefaultDomainPasswordPolicy, adaptados al dominio previsto:

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com -Server dc01.contoso.com

Conserve la política predeterminada como evidencia de ámbito de dominio. Para una lectura de usuario satisfactoria sin PSO devuelto, verifique la identidad y el contexto de consulta, y después registre la política predeterminada aplicable y su evaluación frente a la configuración base. Deje la fila sin resolver si la integridad de la lectura o los permisos siguen siendo inciertos. Un campo PSO vacío, por sí solo, no es evidencia suficiente para aprobar la fila.

Para investigar los vínculos de políticas candidatas, use la capacidad de filtrado documentada de Get-ADFineGrainedPasswordPolicy:

Get-ADFineGrainedPasswordPolicy -Filter * -Server dc01.contoso.com

Examine los valores devueltos de AppliesTo, Precedence y los parámetros junto al resultado por usuario. El inventario de políticas explica las asignaciones candidatas; no sustituye la lectura resultante. Guarde solo la evidencia de políticas e identidades necesaria para la revisión.

Si una ruta de pertenencia anidada es pertinente, documente la cadena de la cuenta al grupo, el destino de la política, la evidencia de pertenencia obtenida con autorización y la política resultante devuelta. Etiquete una cadena incompleta como no verificada. No deduzca un PSO efectivo a partir de un diagrama con apariencia recursiva ni de la comparación de miembros directos del detector. Pida al responsable del directorio que concilie las evidencias inconsistentes de pertenencia y política resultante antes de cerrar esa fila.

4. Usar resultados explícitos por fila

El siguiente esquema de evidencia es una propuesta, no una muestra de cuentas reales o resultados de pruebas:

Una fila completada puede aprobarse mediante un PSO resultante verificado, una política predeterminada del dominio aprobada o una ruta de control de identidad administrada justificada por separado. Son resultados diferentes. «Denegación», «fallo» y «aplicabilidad pendiente» siguen siendo carencias de evidencia abiertas. Una excepción es una decisión documentada, no una aprobación automática.

Concilie la matriz con la población acordada antes de resumirla. Informe explícitamente de las lecturas sin resolver y las identidades excluidas. La ausencia de un hallazgo automatizado no debe borrar esas filas.

Remediación: resolver la carencia de cada cuenta frente a su configuración base (Remediation)

1. Aprobar los parámetros según el contexto del servicio

Use la matriz para identificar qué cuentas tradicionales no cumplen su configuración base aprobada. Haga que los responsables del servicio y del directorio acuerden los parámetros de contraseña requeridos, la compatibilidad operativa, el mantenimiento de credenciales y el plan de despliegue. Revise los parámetros devueltos en su conjunto; una comparación de longitud mínima por sí sola es insuficiente para una configuración base aprobada localmente.

El valor 20 del detector es un umbral de implementación. No lo convierta en un requisito de Microsoft para todos los servicios, ni copie parámetros de políticas de demostración como recomendaciones de producción. Mantenga la configuración base aprobada del servicio y su justificación en la fila de la cuenta.

2. Corregir deliberadamente las asignaciones y las carencias de evidencia

Cuando se prevea una FGPP aprobada, planifique la corrección necesaria de asignación o prioridad mediante el proceso de cambios del directorio. Considere las asignaciones directas en conflicto y los consumidores de políticas compartidas antes del cambio. Evite crear un único vínculo que cumpla los criterios solo para reducir el contador del detector.

Una lectura denegada requiere acceso autorizado u otra ruta aprobada de recopilación de evidencia antes de decidir la cobertura. Capture juntos el error original y la lectura satisfactoria posterior. Corregir la recopilación es un requisito previo para interpretar la política; no remedia por sí mismo las credenciales de la cuenta.

Para las excepciones conservadas, registre la dependencia del servicio, el responsable, las medidas compensatorias, el aprobador y la próxima fecha de revisión. Mantenga visible la excepción de la fila en los futuros informes de cobertura. Una excepción sin responsable o caducada debe volver a revisión.

3. Separar las decisiones sobre cuentas administradas y retirada

Para un servicio apto para gMSA, evalúe una migración a identidad administrada con su responsable y valide la compatibilidad y la recuperación autorizada de credenciales. Es un cambio distinto de asignar una FGPP a una cuenta tradicional. Mantenga la decisión de clasificación y la evidencia de migración en la matriz.

Para las identidades deshabilitadas, resuelva las dependencias y la razón de conservación antes de retirarlas. No elimine cuentas en masa porque aparezcan en una revisión de cobertura. A la inversa, no permita que una identidad sin uso que cumpla los criterios oculte carencias en los servicios activos.

Para la exposición a ataques, nuestra guía de Kerberoasting sobre tickets de servicio y secretos de cuentas de servicio cubre la investigación separada de tickets, secretos y privilegios. Esta matriz establece la cobertura de la revisión de políticas; no demuestra resistencia al descifrado fuera de línea ni ausencia de actividad maliciosa.

4. Repetir las lecturas después de los cambios aprobados

Vuelva a ejecutar la orden de política resultante por usuario y las lecturas de inventario pertinentes después del cambio aprobado. Adjunte evidencia anterior y posterior a cada fila afectada; después, haga que los responsables validen el funcionamiento del servicio y el plan de mantenimiento de credenciales. Un resultado PSO modificado demuestra un resultado de política, no la calidad de un secreto existente.

Cómo detecta EtcSec este problema

La comprobación de etc-collector SERVICE_ACCOUNT_WEAK_PASSWORD_POLICY tiene la categoría Password y la gravedad Medium. Esta descripción procede de public/internal/audit/detectors/ad/password/service-account-password-policy.go:39 en el commit del collector 0423094759d50002457031317098417993e19510.

Selecciona los usuarios recopilados con un SPN o un nombre probable de servicio: prefijos svc_, svc-, sa_, sa-, sql, iis o app, o la subcadena service, tras convertir sAMAccountName a minúsculas. Las cuentas seleccionadas deben tener un DN no vacío. El conjunto de DN resultante se deduplica sin excluir las cuentas deshabilitadas ni separar las gMSA.

La comprobación busca después las FGPP recopiladas cuya longitud mínima sea al menos 20. Una coincidencia directa de AppliesTo con cualquier cuenta seleccionada, o una coincidencia con la lista de Members directos de un grupo que contenga esa cuenta, activa su indicador de cobertura. La búsqueda se detiene tras la primera relación que cumple los criterios.

En consecuencia, Count=1 significa que existen cuentas seleccionadas y no se encontró ninguna relación que cumpliera los criterios en los datos recopilados. Count=0 significa que no se seleccionó ninguna cuenta o que se encontró al menos una relación que cumplía los criterios. Count es binario, no el número de cuentas sin cobertura. Los detalles incluyen serviceAccountCount, que es el tamaño del conjunto de DN seleccionados, no un total de cobertura.

La comprobación no lee msDS-ResultantPSO, no calcula la prioridad efectiva, no expande grupos anidados, no compara cada cuenta con una configuración base, no inspecciona una contraseña existente ni verifica MFA. Su texto descriptivo no debe tratarse como evidencia de que esos controles se probaron.

La recopilación también limita la conclusión. En public/internal/providers/ldap/client.go:1835, GetFGPPs devuelve nil, nil cuando falla su búsqueda en el contenedor de políticas. El motor acepta un error nil en public/internal/audit/engine.go:557; esta ruta no distingue un contenedor inaccesible de una lista vacía de políticas para este detector. Con cuentas seleccionadas, esa entrada vacía puede conducir a Count=1. Investigue la recopilación antes de afirmar que no existen políticas.

Decisiones que registrar antes del cierre

Resuelva tres preguntas con los responsables que rinden cuentas:

1. ¿Qué identidades ejecutan realmente servicios, incluidas las cuentas deshabilitadas y administradas, y qué ruta de control se aplica a cada una?
2. ¿Cómo se registraron y conciliaron las lecturas denegadas, las consultas fallidas y las pertenencias anidadas pertinentes?
3. ¿Qué configuración base está aprobada para cada servicio y qué excepciones conservadas tienen aprobador y fecha de revisión?

Guarde juntos la definición de la población, las lecturas de políticas, las explicaciones de pertenencia, la evidencia de cambios y las decisiones, sin exportar secretos. La declaración final de cobertura debe describir las cuentas realmente revisadas y las carencias todavía abiertas. Nunca debe deducir una protección universal a partir de una sola relación FGPP que cumpla los criterios.