Compartir vía

Protección de cuentas de servicio administradas independientes

  • Artículo

Las cuentas de servicio administradas independientes (sMSA) son cuentas de dominio administradas que ayudan a proteger los servicios que se ejecutan en un servidor. No se pueden reutilizar en varios servidores. Las sMSA tienen administración automática de contraseñas, administración simplificada de nombre de entidad de seguridad de servicio (SPN) y administración delegada a los administradores.

En Active Directory (AD), las sMSA están vinculados a un servidor que ejecuta un servicio. Puede encontrar cuentas en el complemento Usuarios y equipos de Active Directory en Microsoft Management Console.

Nota:

Las cuentas de servicio administradas se introdujeron en el esquema de Active Directory de Windows Server 2008 R2 y requieren Windows Server 2008 R2 o una versión posterior.

Ventajas de sMSA

Las sMSA tienen mayor seguridad que las cuentas de usuario utilizadas como cuentas de servicio. Ayudan a reducir la sobrecarga administrativa:

  • Establecimiento de contraseñas seguras: las sMSA usan contraseñas complejas generadas aleatoriamente de 240 bytes
    • La complejidad minimiza la probabilidad de poner en peligro los ataques por fuerza bruta o diccionario
  • Cambio de contraseñas periódico: Windows cambia la contraseña de sMSA cada 30 días.
    • No es necesario que los administradores de servicios y dominios programen los cambios de contraseña ni administren el tiempo de inactividad asociado
  • Simplificación de la administración de SPN: los SPN se actualizan si el nivel funcional del dominio es Windows Server 2008 R2. El SPN se actualiza cuando:
    • Se cambia el nombre de la cuenta del equipo host
    • Se cambia el nombre del servidor de nombres de dominio (DNS) del equipo host
    • Uso de PowerShell para agregar o quitar otros parámetros sam-accountname o dns-hostname
    • Consulte, Set-ADServiceAccount

Uso de sMSA

Use las sMSA para simplificar las tareas de administración y seguridad. Las sMSA son útiles cuando los servicios se implementan en un servidor y no puede usar una cuenta de servicio administrada de grupo (gMSA).

Nota

Puede usar las sMSA para más de un servicio, pero se recomienda que cada servicio tenga una identidad para la auditoría.

Si el creador del software no puede indicarle si la aplicación usa una MSA, pruebe la aplicación. Cree un entorno de prueba y asegúrese de que accede a los recursos necesarios.

Más información: Cuentas de servicio administradas: Reconocimiento, implementación, procedimientos recomendados y solución de problemas

Evaluación de la posición de seguridad de las sMSA

Considere el ámbito de sMSA de acceso como parte de la posición de seguridad. Para mitigar posibles problemas de seguridad, consulte la tabla siguiente:

Problema de seguridad Mitigación
Una sMSA es un miembro de grupos con privilegios - Quitar las sMSA de los grupos con privilegios elevados, como Administradores de dominio
- Usar el modelo con menos privilegios
- Conceder los derechos y permisos de sMSA para ejecutar los servicios
- Si no está seguro acerca de los permisos, consulte al creador del servicio
Una sMSA tiene acceso de lectura y escritura a los recursos confidenciales - Auditar el acceso a recursos confidenciales
- Archivar registros de auditoría en un programa de administración de eventos e información de seguridad (SIEM), como Azure Log Analytics o Microsoft Sentinel
- Corregir permisos de recursos si se detecta un acceso no deseado
De manera predeterminada, la frecuencia de sustitución de contraseñas de una sMSA es de 30 días La directiva de grupo se puede usar para ajustar la duración en función de los requisitos de seguridad de la empresa. Para establecer la duración de expiración de la contraseña, vaya a:
Configuración del equipo: >Directivas>Configuración de Windows>Configuraciones de seguridad>Opciones de seguridad. Para un miembro del dominio, use la duración máxima de contraseña de cuenta de equipo.

Desafíos de las sMSA

Use la tabla siguiente para asociar desafíos con mitigaciones.

Desafío Mitigación
Las sMSA están en un solo servidor de red Use una gMSA para usar la cuenta en todos los servidores
Las sMSA no se pueden usar entre dominios Use una gMSA para usar la cuenta en todos los dominios
No todas las aplicaciones admiten las sMSA Use una gMSA, si es posible. De lo contrario, use una cuenta de usuario estándar o una cuenta de equipo, según lo recomendado por el creador

Búsqueda de las gMSA

En un controlador de dominio, ejecute DSA.msc y, a continuación, expanda el contenedor de cuentas de servicio administradas para ver todos las sMSA.

Ejecute el comando de PowerShell siguiente para devolver todas las sMSA y gMSA del dominio de Active Directory:

Get-ADServiceAccount -Filter *

Para devolver sMSA en el dominio de Active Directory, ejecute el siguiente comando:

Get-ADServiceAccount -Filter * | where { $_.objectClass -eq "msDS-ManagedServiceAccount" }

Administración de las sMSA

Para administrar las sMSA, puede usar los siguientes cmdlets de Active Directory PowerShell:

Get-ADServiceAccount Install-ADServiceAccount New-ADServiceAccount Remove-ADServiceAccount Set-ADServiceAccount Test-ADServiceAccount Uninstall-ADServiceAccount

Migración a las sMSA

Si un servicio de aplicación admite las sMSA, pero no las gMSA, y está usando una cuenta de usuario o una cuenta de equipo para el contexto de seguridad, consulte
Cuentas de servicio administradas: Reconocimiento, implementación, procedimientos recomendados y solución de problemas.

Si es posible, mueva recursos a Azure y use identidades administradas de Azure o entidades de servicio.

Pasos siguientes

Para obtener más información sobre cómo proteger las cuentas de servicio, consulte: