Ran Harel

Les comptes de service jouent un rôle essentiel dans la communication entre machines dans les environnements Active Directory (AD). Par exemple, les plateformes de messagerie, les bases de données et les applications internes et tournées vers l'internet s'appuient sur ces comptes pour s'authentifier auprès d'autres applications et services dorsaux. Ils sont également largement utilisés par les outils de sécurité pour s'intégrer à des plateformes contrôlées comme AD.

Les comptes de service étant omniprésents dans la quasi-totalité des opérations commerciales, ils offrent aux acteurs malveillants une surface d'attaque incroyablement vaste, avec une myriade de points d'entrée potentiels. De nombreuses cyberattaques très médiatisées ont commencé par la compromission d'un compte de service.

Un exemple notable - l'attaque NotPetya contre le géant pharmaceutique Merck en 2017 - est l'un des plus coûteux de l'histoire, avec des dommages totalisant 1,4 milliard de dollars. Fait effrayant, le point de compromission initial était un compte de service utilisé par System Center Configuration Manager (SCCM) pour l'application des correctifs logiciels. (Nous explorons cette attaque en détail dans un épisode dédié de notre podcast sur la protection de l'identité hybride.)

Pourquoi continuons-nous à vivre avec un point d'exposition aussi évident dans notre système d'identité ? La réponse est simple : C'est compliqué.

Pourquoi les comptes de service sont-ils si difficiles à sécuriser ?

L'utilisation généralisée des comptes de service les rend notoirement difficiles à trouver, à gérer et à sécuriser. Ces difficultés sont dues à de multiples facteurs.

Les comptes de service sont essentiels pour l'entreprise

Si un compte de service n'est pas en mesure d'accéder à AD - par exemple, en raison d'un verrouillage de compte ou d'un changement de mot de passe - l'application associée cesse souvent de fonctionner, entraînant l'arrêt des activités de l'entreprise.

Compte tenu de la criticité de la plupart des applications et services d'entreprise, de nombreux praticiens de la sécurité hésitent à apporter des modifications liées à la sécurité qui pourraient perturber un compte de service et interrompre les activités, de sorte que les comptes restent intacts et vulnérables.

Les comptes de service ont une faible visibilité

La plupart des environnements AD sont en place depuis de nombreuses années, voire des décennies. Au cours de cette période, d'innombrables services intégrés à AD ont été mis en place, mis à niveau et supprimés. Et chacun d'entre eux introduit son propre ensemble de comptes de service avec des autorisations spécifiques.

Contrairement aux comptes d'utilisateurs humains, qui sont généralement gérés par des processus structurés d'intégration et de désintoxication, les comptes de service ne bénéficient souvent pas d'une gestion formelle de leur cycle de vie. Par conséquent, lorsque les applications sont mises hors service, les comptes de service qui leur sont associés sont souvent abandonnés.

Au fil du temps, ces anciens comptes de service s'accumulent. Les entreprises peuvent avoir des centaines, voire des milliers de comptes périmés et non gérés qui traînent dans l'environnement, chacun d'entre eux représentant un risque potentiel pour la sécurité.

Les mots de passe statiques des comptes de service sont omniprésents

Les comptes de service utilisent souvent des mots de passe statiques qui changent rarement et sont parfois codés en dur dans des scripts ou des applications. Ces informations d'identification sont difficiles à faire pivoter et, une fois exposées - par des fuites de code source, des fichiers de configuration ou des vidages de mémoire -, elles peuvent être exploitées par des attaquants qui se déplacent ensuite latéralement ou escaladent leurs privilèges dans l'environnement.

Les mots de passe statiques faibles sont particulièrement vulnérables aux attaques par pulvérisation de mot de passe. Comme les comptes de service ne peuvent pas utiliser l'authentification multifactorielle, il leur manque une couche essentielle de protection. Dans les environnements AD, ils sont également sensibles au Kerberoasting, où les attaquants extraient et craquent les tickets de service pour obtenir des mots de passe en clair.

Les comptes de service ont souvent des privilèges excessifs

Les équipes chargées des applications et des développeurs attribuent souvent des autorisations excessives aux comptes de service parce qu'elles n'ont pas une connaissance approfondie des modèles d'autorisation et de délégation d'Active Directory. Au lieu d'adopter une approche nuancée, elles peuvent créer régulièrement des comptes à privilèges élevés avec des autorisations qui dépassent de loin ce qui est nécessaire.

Cette pratique offre aux attaquants une occasion unique d'utiliser l'une des nombreuses techniques d'attaque pour prendre le contrôle d'un compte de service et augmenter rapidement les privilèges. En outre, la plupart des activités des comptes de service ne sont généralement pas surveillées et la compromission des comptes n'est souvent détectée que lorsqu'il est trop tard.

Comment combler les lacunes en matière de sécurité des comptes de service

Ensemble, ces défis constituent un problème presque insurmontable pour les équipes de sécurité, et les comptes de service constituent une lacune critique dans la plupart des programmes de sécurité de l'identité.

Examinons une approche à plusieurs niveaux pour résoudre ce problème difficile.

Inventaire et classification

La première étape consiste à découvrir tous les comptes de service dans votre environnement Active Directory. Généralement, cela implique d'utiliser des outils tels que des scripts PowerShell ou des plateformes de gouvernance des identités.

Identifiez ensuite le propriétaire, l'objectif et les systèmes associés à chaque compte. Classez-les par niveau de privilège, unité organisationnelle et méthode d'authentification. Supprimez les comptes orphelins ou inutilisés et tenez un inventaire centralisé et régulièrement mis à jour.

Appliquer le principe du moindre privilège

N'attribuez que les autorisations nécessaires au fonctionnement de chaque compte de service. Évitez d'accorder des droits d'administrateur de domaine ou d'administrateur d'entreprise à moins que cela ne soit absolument nécessaire.

Dans la mesure du possible, utilisez des comptes de service gérés par groupe (gMSA) pour simplifier la gestion des autorisations et réduire les risques.

Éliminer les identifiants codés en dur

Analysez les scripts, les tâches programmées et les applications à la recherche d'informations d'identification intégrées. Dans la mesure du possible, remplacez les mots de passe codés en dur par des solutions de stockage sécurisées, telles que Windows Credential Manager ou gMSA, afin d'éviter les fuites d'informations d'identification.

Pour certains comptes, il est impossible d'éviter les mots de passe codés en dur. Dans ce cas, veillez à utiliser un mot de passe sécurisé à forte entropie, avec la longueur de caractère maximale autorisée.

Contrôler et alerter

L'activité des comptes de service doit suivre des schémas et des emplacements de connexion prévisibles. Activez l'audit des événements de connexion aux comptes de service et surveillez les comportements inhabituels, tels que les connexions à partir d'hôtes inattendus ou à des heures bizarres.

Intégrer les journaux à une plateforme de gestion des informations et des événements de sécurité (SIEM) afin de centraliser la surveillance et de générer des alertes en cas d'activité suspecte.

Restreindre la connexion et l'accès

Utiliser la stratégie de groupe pour refuser les droits de connexion interactive aux comptes de service. Restreignez l'endroit où les comptes peuvent s'authentifier à l'aide du paramètre Postes de travail de connexion, en autorisant les connexions uniquement sur les serveurs nécessaires.

Automatisation de la sécurité des comptes de service en couches

Comme vous l'avez probablement compris, l'approche traditionnelle de la gestion des comptes de service et de l'atténuation des vulnérabilités est prohibitive en termes de temps et de ressources. Naturellement, c'est sur cela que comptent les cyberattaquants.

C'est pourquoi Semperis a proposé une alternative.

Nos services Protection des comptes de service renforce les capacités de Directory Services Protector DSPen simplifiant le processus de sécurisation des comptes de service et en réduisant considérablement le temps et les efforts requis par les étapes décrites ci-dessus.

Ce module découvre en permanence les comptes de service inconnus et mal placés, détecte les mauvaises configurations des comptes de service et met en évidence les configurations à risque et les expositions critiques, tout en vous alertant sur les comportements malveillants et anormaux.

Les comptes de service sont depuis longtemps le talon d'Achille de la sécurité des identités, une faille critique que les attaquants tentent toujours d'atteindre. DSP vous aide à les défendre.

En savoir plus sur la protection des comptes de service dans Active Directory