Partage via

Sécuriser les comptes de service gérés autonomes

  • Article

Les comptes de service géré autonomes (sMSA) sont des comptes de domaine managé utilisés pour sécuriser des services exécutés sur un serveur. Ils ne peuvent pas être réutilisés sur plusieurs serveurs. Les sMSA offrent une gestion automatique des mots de passe, une gestion simplifiée du nom de principal du service (SPN) et la possibilité de déléguer la gestion à d’autres administrateurs.

Dans Active Directory (AD), les sMSA sont liés à un serveur qui exécute un service. Vous pouvez trouver des comptes dans le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory de la console de gestion Microsoft.

Remarque

Les comptes de service géré ont été introduits dans le schéma Active Directory de Windows Server 2008 R2, et ils requièrent Windows Server 2008 R2 ou une version ultérieure.

Avantages des sMSA

Les sMSA sont plus sécurisés que les comptes d'utilisateur utilisés comme comptes de service. Ils permettent de réduire la surcharge administrative :

  • Définition de mots de passe forts: les sMSA utilisent des mots de passe complexes de 240 octets générés de manière aléatoire.
    • La complexité réduit la probabilité qu’un service soit compromis par des attaques par force brute ou par dictionnaire
  • Recyclage régulier des mots de passe : Windows modifie le mot de passe du sMSA tous les 30 jours.
    • Les administrateurs de service et de domaine n’ont pas besoin de planifier des modifications de mot de passe ni de gérer les temps d’arrêt qui en résultent
  • Simplification de la gestion des SPN : les noms de principal de service sont mis à jour si le niveau fonctionnel de domaine est Windows Server 2008 R2. Le SPN est mis à jour lorsque vous :
    • Changez le nom du compte de l'ordinateur hôte
    • Modifiez le nom DNS de l'ordinateur hôte
    • Ajoutez ou supprimez d'autres paramètres sam-accountname ou dns-hostname avec PowerShell
    • Voir Set-ADServiceAccount

Utilisation des sMSA

Les sMSA peuvent simplifier les tâches de gestion et de sécurité. Vous pouvez utiliser les sMSA lorsque des services sont déployés sur un serveur et que vous n'avez pas la possibilité d'utiliser un gMSA (compte de service géré de groupe).

Notes

Vous pouvez utiliser des sMSA pour plusieurs services, mais il est recommandé que chaque service dispose d’une identité pour l’audit.

Si le créateur du logiciel ne peut pas vous dire si l’application utilise un MSA, testez l’application. Créez un environnement de test et assurez-vous qu’il accède aux ressources requises.

Pour en savoir plus, consultez Comptes de service administrés : présentation, implémentation, recommandations et dépannage

Évaluer la posture de sécurité du sMSA

Considérez l’étendue de l’accès du sMSA dans le cadre de la posture de sécurité. Pour atténuer les potentiels problèmes de sécurité, consultez le tableau suivant :

Problème de sécurité Limitation des risques
Le sMSA est membre de groupes privilégiés. - Supprimez le sMSA des groupes à privilèges élevés tels que le groupe Administrateurs de domaine
- Utilisez le modèle le moins privilégié
- Accordez au sMSA les droits et autorisations dont il a besoin pour exécuter ses services
- Si vous n’êtes pas sûr des autorisations requises, consultez le créateur du service
Le sMSA dispose d’un accès en lecture/écriture aux ressources sensibles - Auditez l’accès aux ressources sensibles
- Archivez les journaux d’audit dans un programme de gestion des informations et des événements de sécurité (SIEM, Security Information and Event Management) tel qu’Azure Log Analytics ou Microsoft Sentinel
- Corrigez les autorisations d’accès aux ressources si un niveau d’accès indésirable est détecté
Par défaut, la fréquence de substitution de mot de passe des sMSA est de 30 jours. Vous pouvez utiliser la stratégie de groupe pour régler la durée en fonction des exigences de l'entreprise en matière de sécurité. Pour définir la durée d’expiration du mot de passe, accédez à :
Configuration de l’ordinateur>Stratégies>Paramètres Windows>Paramètres de sécurité>Options de sécurité. Sous Membre de domaine, choisissez Ancienneté maximale du mot de passe du compte d'ordinateur.

Défis sMSA

Utilisez le tableau suivant pour associer les défis aux atténuations.

Problème Limitation des risques
Les sMSA sont sur un serveur unique Utilisez un gMSA pour utiliser le compte sur plusieurs serveurs
Les sMSA ne peuvent pas être utilisés dans plusieurs domaines Utilisez un gMSA pour utiliser le compte sur plusieurs domaines
Toutes les applications ne prennent pas en charge les sMSA Utilisez un gMSA dans la mesure du possible. Sinon, utilisez un compte d'utilisateur standard ou un compte d'ordinateur, comme recommandé par le créateur

Rechercher des sMSA

Sur n'importe quel contrôleur de domaine, exécutez DSA.msc, puis développez le conteneur Comptes de service géré pour afficher tous les sMSA.

Pour renvoyer tous les sMSA et gMSA du domaine Active Directory, exécutez la commande PowerShell suivante :

Get-ADServiceAccount -Filter *

Pour renvoyer les sMSA dans le domaine Active Directory, exécutez la commande suivante :

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

Gérer des sMSA

Pour gérer vos sMSA, vous pouvez utiliser les cmdlets PowerShell Active Directory suivantes :

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

Passer à des sMSA

Si un service d'application prend en charge les sMSA mais pas les gMSA, et que vous utilisez un compte d’utilisateur ou un compte d’ordinateur dans un contexte de sécurité, consultez
Comptes de service administrés : présentation, implémentation, recommandations et dépannage.

Dans l’idéal, déplacez les ressources vers Azure et utilisez des identités managées Azure ou des principaux de service.

Étapes suivantes

Pour en savoir plus sur la sécurisation des comptes de service, consultez :