Implémentation de modèles d’administration selon le principe des privilèges minimum

  • Article

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Le passage suivant est extrait du Guide de planification de la sécurité des comptes d’administrateur, publié pour la première fois le 1er avril 1999 :

« La plupart des cours de formation et de la documentation liés à la sécurité traitent de l’implémentation d’un principe des privilèges minimum, mais les organisations le suivent rarement. Le principe est simple, et l’impact de son application correcte accroît considérablement la sécurité et réduit les risques. Le principe stipule que tous les utilisateurs doivent se connecter avec un compte d’utilisateur disposant des autorisations minimales absolues nécessaires pour terminer la tâche en cours et rien de plus. Cela offre une protection contre les codes malveillants, entre autres attaques. Ce principe s’applique aux ordinateurs et aux utilisateurs de ces ordinateurs. L’une des raisons pour lesquelles ce principe fonctionne si bien, c’est qu’il vous oblige à faire des recherches internes. Par exemple, vous devez déterminer les privilèges d’accès dont un ordinateur ou un utilisateur a vraiment besoin, puis les implémenter. Pour de nombreuses organisations, cette tâche peut d’abord sembler nécessiter une grande quantité de travail ; toutefois, il s’agit d’une étape essentielle pour sécuriser correctement votre environnement réseau. Vous devez accorder à tous les utilisateurs administrateurs du domaine leurs privilèges de domaine selon le concept des privilèges minimum. Par exemple, si un administrateur se connecte avec un compte privilégié et exécute par inadvertance un programme viral, le virus dispose d’un accès administratif à l’ordinateur local et à l’ensemble du domaine. Si l’administrateur s’était connecté avec un compte non privilégié (non administratif), les dommages du virus s’étendraient uniquement l’ordinateur local, car il s’exécuterait en tant qu’utilisateur d’ordinateur local. Dans un autre exemple, les comptes auxquels vous accordez des droits d’administrateur au niveau du domaine ne doivent pas avoir de droits élevés dans une autre forêt, même s’il existe une relation d’approbation entre les forêts. Cette tactique permet d’éviter des dommages généralisés si un attaquant parvient à compromettre une forêt gérée. Les organisations doivent régulièrement auditer leur réseau pour se protéger contre l’escalade non autorisée des privilèges. »

Le passage suivant est extrait du Kit de ressources de sécurité Microsoft Windows, publié pour la première fois en 2005 :

« Pensez toujours à la sécurité en termes d’octroi des privilèges minimum requis pour effectuer la tâche. Si une application qui a trop de privilèges est compromise, l’attaquant peut être en mesure d’étendre l’attaque au-delà de ce qu’elle aurait fait si l’application avait été soumise au principe des privilèges minimum. Par exemple, pensez aux conséquences si un administrateur réseau ouvre involontairement une pièce jointe à un e-mail qui lance un virus. Si l’administrateur est connecté à l’aide du compte d’Administrateur du domaine, le virus disposera de privilèges d’administrateur sur tous les ordinateurs du domaine et, par conséquent, d’un accès sans restriction à presque toutes les données du réseau. Si l’administrateur est connecté à l’aide d’un compte Administrateur local, le virus disposera de privilèges d’administrateur sur l’ordinateur local et pourra ainsi accéder à toutes les données de l’ordinateur et installer des logiciels malveillants tels qu’un logiciel de keylogging sur l’ordinateur. Si l’administrateur est connecté à l’aide d’un compte d’utilisateur normal, le virus n’aura accès qu’aux données de l’administrateur et ne pourra pas installer de logiciels malveillants. Si vous respectez le principe des privilèges minimum nécessaires pour lire les e-mails, dans cet exemple, l’étendue potentielle de la compromission est considérablement réduite. »

Le problème des privilèges

Les principes décrits dans les extraits précédents n’ont pas changé, mais dans l’évaluation des installations d’Active Directory, nous trouvons invariablement un nombre excessif de comptes qui ont reçu des droits et des autorisations bien au-delà de ceux requis pour effectuer le travail quotidien. La taille de l’environnement affecte le nombre brut de comptes trop privilégiés, mais pas la proportion. Des annuaires de taille moyenne peuvent avoir des dizaines de comptes dans les groupes les plus privilégiés, tandis que de grandes installations peuvent en avoir des centaines, voire des milliers. À quelques exceptions près, indépendamment de la sophistication des compétences et de l’arsenal d’un attaquant, les attaquants suivent généralement le chemin de la moindre résistance. Ils n’augmentent la complexité de leurs outils et de leur approche que si et quand des mécanismes plus simples échouent ou sont contrecarrés par les défenseurs.

Malheureusement, dans de nombreux environnements le chemin de la moindre résistance est bien souvent la surutilisation de comptes disposant de privilèges étendus et profonds. Les privilèges étendus sont des droits et des autorisations qui permettent à un compte d’effectuer des activités spécifiques dans une grande partie de l’environnement. Par exemple, le personnel du support technique peut se voir accorder des autorisations qui lui permettent de réinitialiser les mots de passe de nombreux comptes d’utilisateur.

Les privilèges profonds sont des privilèges puissants qui sont appliqués à un segment restreint de la population, comme le fait de donner à un ingénieur des droits d’Administrateur sur un serveur afin qu’il puisse effectuer des réparations. Ni les privilèges étendus ni les privilèges profonds ne sont nécessairement dangereux, mais lorsque de nombreux comptes dans le domaine bénéficient de privilèges étendus et profonds de façon permanente, si un seul des comptes est compromis, il peut rapidement être utilisé pour reconfigurer l’environnement conformément aux besoins de l’attaquant ou même pour détruire de grands segments de l’infrastructure.

Les attaques Pass-the-hash, qui sont un type de vol d’informations d’identification, sont omniprésentes car les outils permettant de les exécuter sont disponibles gratuitement et faciles à utiliser, et car de nombreux environnements sont vulnérables aux attaques. Toutefois, les attaques Pass-the-hash ne sont pas le véritable problème. Le nœud du problème est double :

  1. Il est généralement facile pour un attaquant d’obtenir des privilèges profonds sur un seul ordinateur, puis de propager largement ce privilège à d’autres ordinateurs
  2. Il existe généralement trop de comptes permanents disposant de niveaux de privilèges élevés dans le paysage informatique

Même si les attaques Pass-the-hash sont éliminées, les attaquants utiliseront simplement des tactiques différentes, et non une stratégie différente. Plutôt que de créer des programmes malveillants qui contiennent des outils de vol d’informations d’identification, ils peuvent créer des programmes malveillants qui journalisent les frappes, ou tirer parti d’un certain nombre d’autres approches pour capturer des informations d’identification qui sont puissantes dans l’environnement. Quelle que soit la tactique, les cibles restent les mêmes : les comptes avec des privilèges étendus et profonds.

L’octroi de privilèges excessifs ne se trouve pas uniquement dans Active Directory dans les environnements compromis. Lorsqu’une organisation a développé l’habitude d’accorder plus de privilèges que nécessaire, cet octroi est présent généralement dans l’ensemble de l’infrastructure, comme discuté dans les sections suivantes.

Dans Active Directory

Dans Active Directory, il est courant de constater que les groupes Administrateurs de l’entreprise, Administrateurs du domaine et Administrateurs intégrés contiennent un nombre excessif de comptes. Le plus souvent, le groupe Administrateurs de l’entreprise d’une organisation contient le moins de membres, les groupes Administrateurs du domaine contiennent généralement un multiple du nombre d’utilisateurs dans le groupe Administrateurs de l’entreprise, et les groupes Administrateurs contiennent généralement plus de membres que les populations des autres groupes combinés. Cela est souvent dû à la croyance que les administrateurs sont en quelque sorte « moins privilégiés » que les administrateurs du domaine ou les administrateurs de l’entreprise. Même si les droits et autorisations accordés à chacun de ces groupes diffèrent, ils doivent être considérés comme des groupes tout aussi puissants car un membre de l’un peut se faire membre des deux autres.

Sur les serveurs membres

Lorsque nous récupérons l’appartenance aux groupes Administrateurs locaux sur des serveurs membres dans de nombreux environnements, nous observons une appartenance allant d’une poignée de comptes locaux et de domaine à des dizaines de groupes imbriqués qui, une fois développés, révèlent des centaines, voire des milliers de comptes disposant d’un privilège d’administrateur local sur les serveurs. Dans de nombreux cas, les groupes de domaines avec des appartenances importantes sont imbriqués dans les groupes Administrateurs locaux des serveurs membres, sans tenir compte du fait que tout utilisateur qui peut modifier les appartenances de ces groupes dans le domaine peut obtenir le contrôle administratif de tous les systèmes sur lesquels le groupe a été imbriqué dans un groupe Administrateurs local.

Sur les stations de travail

Bien que les stations de travail comptent généralement beaucoup moins de membres dans leurs groupes Administrateurs locaux que les serveurs membres, dans de nombreux environnements, les utilisateurs se voient accorder l’appartenance au groupe Administrateurs local sur leurs ordinateurs personnels. Dans ce cas, même si UAC est activé, ces utilisateurs présentent un risque élevé pour l’intégrité de leurs stations de travail.

Important

Vous devez examiner attentivement si les utilisateurs ont besoin de droits d’administration sur leurs stations de travail et, si c’est le cas, une meilleure approche peut consister à créer un compte local distinct sur l’ordinateur qui est membre du groupe Administrateurs. Lorsque les utilisateurs ont besoin d’une élévation, ils peuvent présenter les informations d’identification de ce compte local pour l’élévation, mais comme le compte est local, il ne peut pas être utilisé pour compromettre d’autres ordinateurs ou accéder aux ressources de domaine. Comme pour tous les comptes locaux, toutefois, les informations d’identification du compte privilégié local doivent être uniques ; si vous créez un compte local avec les mêmes informations d’identification sur plusieurs stations de travail, vous exposez les ordinateurs à des attaques Pass-the-hash.

Dans les applications

Dans les attaques dans lesquelles la cible est la propriété intellectuelle d’une organisation, les comptes qui ont obtenu de puissants privilèges au sein des applications peuvent être ciblés pour permettre l’exfiltration des données. Même si les comptes qui ont accès à des données sensibles ne bénéficient d’aucun privilège élevé dans le domaine ou le système d’exploitation, les comptes qui peuvent manipuler la configuration d’une application ou l’accès aux informations fournies par l’application présentent un risque.

Dans les référentiels de données

Comme c’est le cas avec d’autres cibles, les attaquants qui cherchent à accéder à la propriété intellectuelle sous forme de documents et d’autres fichiers peuvent cibler les comptes qui contrôlent l’accès aux magasins de fichiers, les comptes qui ont un accès direct aux fichiers, ou même les groupes ou les rôles qui ont accès aux fichiers. Par exemple, si un serveur de fichiers est utilisé pour stocker des documents de contrat et que l’accès est accordé aux documents par l’utilisation d’un groupe Active Directory, un attaquant qui peut modifier l’appartenance au groupe peut ajouter des comptes compromis au groupe et accéder aux documents de contrat. Dans les cas où l’accès aux documents est fourni par des applications telles que SharePoint, les attaquants peuvent cibler les applications comme décrit précédemment.

Réduction des privilèges

Plus un environnement est grand et complexe, plus il est difficile à gérer et à sécuriser. Dans les petites organisations, la révision et la réduction des privilèges peuvent être une proposition relativement simple, mais chaque serveur, station de travail, compte d’utilisateur et application supplémentaires utilisés dans une organisation ajoute un autre objet qui doit être sécurisé. Étant donné qu’il peut être difficile, voire impossible, de sécuriser correctement tous les aspects de l’infrastructure informatique d’une organisation, vous devez d’abord vous concentrer sur les comptes dont le privilège crée le plus de risques, qui sont généralement les comptes et groupes privilégiés intégrés dans Active Directory, et les comptes locaux privilégiés sur les stations de travail et les serveurs membres.

Sécurisation des comptes d’administrateur local sur les stations de travail et les serveurs membres

Bien que ce document soit axé sur la sécurisation d’Active Directory, comme nous l’avons vu plus haut, la plupart des attaques contre l’annuaire commencent par des attaques contre des hôtes individuels. Il est impossible de fournir des instructions complètes pour la sécurisation des groupes locaux sur les systèmes membres, mais vous pouvez suivre les recommandations suivantes pour vous aider à sécuriser les comptes Administrateur locaux sur les stations de travail et les serveurs membres.

Sécurisation des comptes Administrateur locaux

Sur toutes les versions de Windows actuellement prises en charge, le compte Administrateur local est désactivé par défaut, ce qui le rend inutilisable pour les attaques Pass-the-hash et autres vols d’informations d’identification. Toutefois, dans les domaines contenant des systèmes d’exploitation hérités ou dans lesquels des comptes Administrateur locaux ont été activés, ces comptes peuvent être utilisés comme décrit précédemment pour propager la compromission parmi les serveurs membres et les stations de travail. Pour cette raison, les contrôles suivants sont recommandés pour tous les comptes Administrateur locaux sur les systèmes joints à un domaine.

Des instructions détaillées pour l’implémentation de ces contrôles sont fournies à l’Annexe H : Sécurisation des groupes et des comptes des administrateurs locaux. Toutefois, avant d’implémenter ces paramètres, vérifiez que les comptes Administrateur locaux ne sont pas actuellement utilisés dans l’environnement pour exécuter des services sur des ordinateurs ou effectuer d’autres activités pour lesquelles ces comptes ne doivent pas être utilisés. Testez soigneusement ces paramètres avant de les implémenter dans un environnement de production.

Contrôles pour les comptes Administrateur locaux

Les comptes Administrateur intégrés ne doivent jamais être utilisés comme comptes de service sur les serveurs membres, ni pour se connecter aux ordinateurs locaux (sauf en mode sans échec, qui est autorisé même si le compte est désactivé). L’objectif de l’implémentation des paramètres décrits ici est d’empêcher que le compte Administrateur local de chaque ordinateur soit utilisable, sauf si les contrôles de protection sont d’abord inversés. En implémentant ces contrôles et en supervisant les modifications apportées aux comptes Administrateur, vous pouvez réduire considérablement la probabilité de réussite d’une attaque ciblant les comptes Administrateur locaux.

Configuration d’objets de stratégie de groupe pour restreindre les comptes d’administrateur sur les systèmes joints à un domaine

Dans un ou plusieurs objets de stratégie de groupe que vous créez et liez à des unités d’organisation de station de travail et de serveur membre dans chaque domaine, ajoutez le compte Administrateur aux droits utilisateur suivants dans Configuration ordinateur\Stratégies\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Attributions des droits utilisateur :

  • Refuser l'accès à cet ordinateur à partir du réseau
  • Interdire l’ouverture de session en tant que tâche
  • Interdire l’ouverture de session en tant que service
  • Interdire l’ouverture de session par les services Bureau à distance

Lorsque vous ajoutez des comptes Administrateur à ces droits utilisateur, spécifiez si vous ajoutez le compte Administrateur local ou le compte Administrateur du domaine en étiquetant le compte. Par exemple, pour ajouter le compte Administrateur du domaine NWTRADERS à ces refus de droits, vous devez taper le compte NWTRADERS\Administrateur ou accéder au compte Administrateur pour le domaine NWTRADERS. Pour vous assurer de restreindre le compte Administrateur local, tapez Administrateur dans ces paramètres de droits utilisateur dans l’Éditeur d’objets de stratégie de groupe.

Remarque

Même si les comptes Administrateur locaux sont renommés, les stratégies s’appliqueront toujours.

Ces paramètres garantissent que le compte Administrateur d’un ordinateur ne peut pas être utilisé pour se connecter aux autres ordinateurs, même s’il est activé par inadvertance ou par malveillance. Les connexions locales utilisant le compte Administrateur local ne peuvent pas être complètement désactivées, et vous ne devez pas tenter de le faire, car le compte Administrateur local d’un ordinateur est conçu pour être utilisé dans des scénarios de reprise d’activité.

Si un serveur ou une station de travail membre devient dissocié du domaine sans aucun autre compte local disposant de privilèges d’administrateur, l’ordinateur peut être démarré en mode sans échec, le compte Administrateur peut être activé, et le compte peut ensuite être utilisé pour effectuer des réparations sur l’ordinateur. Une fois les réparations terminées, le compte Administrateur doit à nouveau être désactivé.

Sécurisation des comptes et groupes privilégiés locaux dans Active Directory

Loi numéro six : La sécurité d’un ordinateur est proportionnelle à la confiance que l’on peut accorder à son administrateur. - Dix lois immuables de la sécurité (version 2.0)

Les informations fournies ici sont destinées à fournir des instructions générales pour sécuriser les comptes et groupes intégrés disposant des privilèges les plus élevés dans Active Directory. Des instructions détaillées sont également fournies à l’Annexe D : Sécurisation des comptes Administrateur intégrés dans Active Directory, l’Annexe E : Sécurisation des groupes Administrateurs de l’entreprise dans Active Directory, l’Annexe F : Sécurisation des groupes Administrateurs du domaine dans Active Directory et l’Annexe G : Sécurisation des groupes Administrateurs dans Active Directory.

Avant d’implémenter l’un de ces paramètres, vous devez également tester soigneusement tous les paramètres afin de déterminer s’ils sont appropriés pour votre environnement. Toutes les organisations ne pourront pas implémenter ces paramètres.

Sécurisation des comptes Administrateur intégrés dans Active Directory

Dans chaque domaine d’Active Directory, un compte Administrateur est créé dans le cadre de la création du domaine. Ce compte est par défaut membre des groupes Administrateurs et Administrateurs du domaine dans le domaine, et si le domaine est le domaine racine de la forêt, le compte est également membre du groupe Administrateurs de l’entreprise. L’utilisation du compte Administrateur local d’un domaine doit être réservée uniquement aux activités de build initiales et, éventuellement, aux scénarios de reprise d’activité. Pour vous assurer qu’un compte Administrateur intégré peut être utilisé pour effectuer des réparations dans le cas où aucun autre compte ne peut être utilisé, vous ne devez modifier l’appartenance par défaut du compte Administrateur dans aucun domaine de la forêt. Au lieu de cela, vous devez suivre les instructions pour sécuriser le compte Administrateur dans chaque domaine de la forêt. Des instructions détaillées pour l’implémentation de ces contrôles sont fournies à l’Annexe D : Sécurisation des comptes Administrateur intégrés dans Active Directory.

Contrôles pour les comptes Administrateur intégrés

L’objectif de l’implémentation des paramètres décrits ici est d’empêcher l’utilisation du compte Administrateur de chaque domaine (et non d’un groupe), sauf si un certain nombre de contrôles sont inversés. En implémentant ces contrôles et en supervisant les modifications apportées aux comptes Administrateur, vous pouvez réduire considérablement la probabilité de réussite d’une attaque en tirant parti du compte Administrateur d’un domaine. Pour le compte Administrateur dans chaque domaine de votre forêt, vous devez configurer les paramètres suivants.

Activer l’indicateur « Le compte est sensible et ne peut pas être délégué » sur le compte

Par défaut, tous les comptes dans Active Directory peuvent être délégués. La délégation permet à un ordinateur ou à un service de présenter les informations d’identification d’un compte qui s’est authentifié auprès de l’ordinateur ou du service à d’autres ordinateurs afin d’obtenir des services pour le compte. Lorsque vous activez l’attribut Le compte est sensible et ne peut pas être délégué sur un compte basé sur un domaine, les informations d’identification du compte ne peuvent pas être présentées à d’autres ordinateurs ou services sur le réseau, ce qui limite les attaques qui tirent parti de la délégation pour utiliser les informations d’identification du compte sur d’autres systèmes.

Activer l’indicateur « Une carte à puce est nécessaire pour ouvrir une session interactive » sur le compte

Lorsque vous activez l’attribut Une carte à puce est nécessaire pour ouvrir une session interactive sur un compte, Windows réinitialise le mot de passe du compte à une valeur aléatoire de 120 caractères. En définissant cet indicateur sur les comptes Administrateur intégrés, vous garantissez que le mot de passe du compte est non seulement long et complexe, mais qu’il n’est connu d’aucun utilisateur. Il n’est pas techniquement nécessaire de créer des cartes à puce pour les comptes avant d’activer cet attribut, mais dans la mesure du possible des cartes à puce doivent être créées pour chaque compte Administrateur avant de configurer les restrictions de compte, et les cartes à puce doivent être stockées dans des emplacements sécurisés.

Bien que la définition de l’indicateur Une carte à puce est nécessaire pour ouvrir une session interactive réinitialise le mot de passe du compte, cela n’empêche pas un utilisateur autorisé à réinitialiser le mot de passe du compte de définir une valeur connue et d’utiliser le nom du compte et le nouveau mot de passe pour accéder aux ressources sur le réseau. Pour cette raison, vous devez implémenter les contrôles supplémentaires suivants sur le compte.

Configuration d’objets de stratégie de groupe pour restreindre les comptes d’administrateur du domaine sur les systèmes joints à un domaine

Bien que la désactivation du compte Administrateur dans un domaine rende le compte effectivement inutilisable, vous devez implémenter des restrictions supplémentaires sur le compte au cas où il serait activé par inadvertance ou par malveillance. Bien que ces contrôles puissent finalement être inversés par le compte Administrateur, l’objectif est de créer des contrôles qui ralentissent la progression d’un attaquant et limitent les dommages que le compte peut infliger.

Dans un ou plusieurs objets de stratégie de groupe que vous créez et liez à des unités d’organisation de station de travail et de serveur membre dans chaque domaine, ajoutez le compte Administrateur de chaque domaine aux droits utilisateur suivants dans Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignments :

  • Refuser l'accès à cet ordinateur à partir du réseau
  • Interdire l’ouverture de session en tant que tâche
  • Interdire l’ouverture de session en tant que service
  • Interdire l’ouverture de session par les services Bureau à distance

Remarque

Lorsque vous ajoutez des comptes Administrateur locaux à ce paramètre, vous devez spécifier si vous configurez des comptes Administrateur locaux ou des comptes Administrateur du domaine. Par exemple, pour ajouter le compte Administrateur local du domaine NWTRADERS à ces refus de droits, vous devez taper le compte NWTRADERS\Administrateur, ou accéder au compte Administrateur local pour le domaine NWTRADERS. Si vous tapez Administrateur dans ces paramètres de droits utilisateur dans l’Éditeur d’objets de stratégie de groupe, vous limitez le compte Administrateur local sur chaque ordinateur auquel l’objet de stratégie de groupe est appliqué.

Nous vous recommandons de restreindre les comptes Administrateur locaux sur les serveurs membres et les stations de travail de la même manière que les comptes Administrateur basés sur le domaine. Par conséquent, vous devez généralement ajouter le compte Administrateur pour chaque domaine de la forêt et le compte Administrateur pour les ordinateurs locaux à ces paramètres de droits utilisateur.

Configuration d’objets de stratégie de groupe de façon à restreindre les comptes Administrateur sur les contrôleurs de domaine

Dans chaque domaine de la forêt, la stratégie Contrôleurs de domaine par défaut ou une stratégie liée à l’unité d’organisation des contrôleurs de domaine doit être modifiée de façon à ajouter le compte Administrateur de chaque domaine aux droits utilisateur suivants dans Configuration ordinateur\Stratégies\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Attributions de droits utilisateur :

  • Refuser l'accès à cet ordinateur à partir du réseau
  • Interdire l’ouverture de session en tant que tâche
  • Interdire l’ouverture de session en tant que service
  • Interdire l’ouverture de session par les services Bureau à distance

Notes

Ces paramètres garantissent que le compte Administrateur local ne peut pas être utilisé pour se connecter à un contrôleur de domaine, bien que le compte, s’il est activé, puisse se connecter localement aux contrôleurs de domaine. Étant donné que ce compte ne doit être activé et utilisé que dans les scénarios de reprise d’activité, il est prévu que l’accès physique à au moins un contrôleur de domaine sera disponible, ou que d’autres comptes disposant d’autorisations d’accès aux contrôleurs de domaine à distance puissent être utilisés.

Configurer l’audit des comptes Administrateur intégrés

Une fois que vous avez sécurisé et désactivé le compte Administrateur de chaque domaine, vous devez configurer l’audit afin de superviser les modifications apportées au compte. Si le compte est activé, que son mot de passe est réinitialisé ou que d’autres modifications sont apportées au compte, des alertes doivent être envoyées aux utilisateurs ou aux équipes responsables de l’administration d’AD DS, en plus des équipes de réponse aux incidents de votre organisation.

Sécurisation des groupes Administrateurs, Administrateurs du domaine et Administrateurs de l’entreprise

Sécurisation des groupes Administrateurs de l’entreprise

Le groupe Administrateurs de l’entreprise, qui est hébergé dans le domaine racine de forêt, ne doit contenir aucun utilisateur au jour le jour, à l’exception possible du compte Administrateur local du domaine, à condition qu’il soit sécurisé comme décrit plus haut et à l’Annexe D : Sécurisation des comptes Administrateur intégrés dans Active Directory.

Lorsque l’accès Administrateurs de l’entreprise est requis, les utilisateurs dont les comptes nécessitent des droits et autorisations Administrateurs de l’entreprise doivent être temporairement placés dans le groupe Administrateurs de l’entreprise. Bien que les utilisateurs utilisent les comptes hautement privilégiés, leurs activités doivent être auditées et de préférence effectuées avec un utilisateur effectuant les modifications et un autre utilisateur observant les modifications afin de réduire la probabilité d’une mauvaise utilisation ou d’une mauvaise configuration par inadvertance. Une fois les activités terminées, les comptes doivent être supprimés du groupe Administrateurs de l’entreprise. Pour ce faire, vous pouvez utiliser des procédures manuelles et des processus documentés, des logiciels tiers de gestion des identités/accès privilégiés (PIM/PAM) ou une combinaison des deux. Des instructions relatives à la création de comptes qui peuvent être utilisés pour contrôler l’appartenance à des groupes privilégiés dans Active Directory sont fournies dans Comptes attrayants pour le vol d’informations d’identification, et des instructions détaillées sont fournies à l’Annexe I : Création de comptes de gestion pour les comptes protégés et les groupes dans Active Directory.

Les Administrateurs de l’entreprise sont, par défaut, membres du groupe Administrateurs intégré dans chaque domaine de la forêt. La suppression du groupe Administrateurs de l’entreprise des groupes Administrateurs de chaque domaine est une modification inappropriée, car dans le cas d’un scénario de reprise d’activité de forêt, des droits Administrateurs de l’entreprise seront probablement requis. Si le groupe Administrateurs de l’entreprise a été supprimé des groupes Administrateurs d’une forêt, il doit être ajouté au groupe Administrateurs dans chaque domaine, et les contrôles supplémentaires suivants doivent être implémentés :

  • Comme décrit plus haut, le groupe Administrateurs de l’entreprise ne doit contenir aucun utilisateur au jour le jour, à l’exception possible du compte Administrateur du domaine racine de forêt, qui doit être sécurisé comme décrit à l’Annexe D : Sécurisation des comptes Administrateur intégrés dans Active Directory.
  • Dans les objets de stratégie de groupe liés à des unités d’organisation contenant des stations de travail et des serveurs membres dans chaque domaine, le groupe Administrateurs de l’entreprise doit être ajouté aux droits utilisateur suivants :
    • Interdire l’accès à cet ordinateur à partir du réseau
    • Interdire l’ouverture de session en tant que tâche
    • Interdire l’ouverture de session en tant que service
    • Interdire l’ouverture d’une session locale
    • Interdire l’ouverture de session par les services Bureau à distance

Cela empêchera les membres du groupe Administrateurs de l’entreprise de se connecter aux stations de travail et serveurs membres. Si des serveurs de saut sont utilisés pour administrer les contrôleurs de domaine et Active Directory, vérifiez qu’ils se trouvent dans une unité d’organisation à laquelle les objets de stratégie de groupe restrictifs ne sont pas liés.

  • L’audit doit être configuré de façon à envoyer des alertes si des modifications sont apportées aux propriétés ou à l’appartenance au groupe Administrateurs de l’entreprise. Ces alertes doivent être envoyées, au minimum, aux utilisateurs ou aux équipes responsables de l’administration d’Active Directory et de réponse aux incidents. Vous devez également définir des processus et des procédures pour remplir temporairement le groupe Administrateurs de l’entreprise, y compris des procédures de notification lorsque un remplissage légitime du groupe est effectué.

Sécurisation des groupes Administrateurs du domaine

Comme c’est le cas avec le groupe Administrateurs de l’entreprise, l’appartenance aux groupes Administrateurs du domaine ne doit être requise que dans les scénarios de génération ou de reprise d’activité. Il ne doit y avoir aucun compte d’utilisateur au jour le jour dans le groupe Administrateurs du domaine, à l’exception du compte Administrateur local pour le domaine, s’il a été sécurisé comme décrit à l’Annexe D : Sécurisation des comptes Administrateur intégrés dans Active Directory.

Lorsque l’accès Administrateurs du domaine est requis, les comptes nécessitant ce niveau d’accès doivent être placés temporairement dans le groupe Administrateurs du domaine pour le domaine en question. Bien que les utilisateurs utilisent les comptes hautement privilégiés, les activités doivent être auditées et de préférence effectuées avec un utilisateur effectuant les modifications et un autre utilisateur observant les modifications afin de réduire la probabilité d’une mauvaise utilisation ou d’une mauvaise configuration par inadvertance. Une fois les activités terminées, les comptes doivent être supprimés du groupe Administrateurs du domaine. Pour ce faire, vous pouvez utiliser des procédures manuelles et des processus documentés, des logiciels tiers de gestion des identités/accès privilégiés (PIM/PAM) ou une combinaison des deux. Des instructions relatives à la création de comptes qui peuvent être utilisés pour contrôler l’appartenance à des groupes privilégiés dans Active Directory sont fournies à l’Annexe I : Création de comptes de gestion pour les comptes protégés et les groupes dans Active Directory.

Les Administrateurs du domaine sont, par défaut, membres des groupes Administrateurs locaux sur tous les serveurs membres et stations de travail de leurs domaines respectifs. Cette imbrication par défaut ne doit pas être modifiée, car elle affecte les options de prise en charge et de reprise d’activité. Si des groupes Administrateurs du domaine ont été supprimés des groupes Administrateurs locaux sur les serveurs membres, ils doivent être ajoutés au groupe Administrateurs sur chaque station de travail et serveur membre dans le domaine par le biais des paramètres de groupe restreints dans les objets de stratégie de groupe liés. Les contrôles généraux suivants, qui sont décrits en détail à l’Annexe F : Sécurisation des groupes d’administrateurs de domaine dans Active Directory, doivent également être implémentés.

Pour le groupe Administrateurs du domaine dans chaque domaine de la forêt :

  1. Supprimez tous les membres du groupe Administrateurs du domaine, à l’exception possible du compte Administrateur intégré pour le domaine, à condition qu’il ait été sécurisé comme décrit à l’Annexe D : Sécurisation des comptes Administrateur intégrés dans Active Directory.

  2. Dans les objets de stratégie de groupe liés à des unités d’organisation contenant des stations de travail et des serveurs membres dans chaque domaine, le groupe Administrateurs du domaine doit être ajouté aux droits utilisateur suivants :

    • Refuser l'accès à cet ordinateur à partir du réseau
    • Interdire l’ouverture de session en tant que tâche
    • Interdire l’ouverture de session en tant que service
    • Interdire l’ouverture d’une session locale
    • Interdire l’ouverture de session par les services Bureau à distance

    Cela empêchera les membres du groupe Administrateurs du domaine de se connecter aux stations de travail et serveurs membres. Si des serveurs de saut sont utilisés pour administrer les contrôleurs de domaine et Active Directory, vérifiez qu’ils se trouvent dans une unité d’organisation à laquelle les objets de stratégie de groupe restrictifs ne sont pas liés.

  3. L’audit doit être configuré de façon à envoyer des alertes si des modifications sont apportées aux propriétés ou à l’appartenance au groupe Administrateurs du domaine. Ces alertes doivent être envoyées, au minimum, aux utilisateurs ou aux équipes responsables de l’administration d’AD DS et de réponse aux incidents. Vous devez également définir des processus et des procédures pour remplir temporairement le groupe Administrateurs du domaine, y compris des procédures de notification lorsque un remplissage légitime du groupe est effectué.

Sécurisation des groupes d’administrateurs dans Active Directory

Comme c’est le cas pour les groupes Administrateurs de l’entreprise et Administrateurs du domaine, l’appartenance au groupe Administrateurs (Administrateurs intégrés) ne doit être requise que dans les scénarios de génération ou de reprise d’activité. Il ne doit y avoir aucun compte d’utilisateur au jour le jour dans le groupe Administrateurs, à l’exception du compte Administrateur local pour le domaine, s’il a été sécurisé comme décrit à l’Annexe D : Sécurisation des comptes Administrateur intégrés dans Active Directory.

Lorsque l’accès Administrateurs est requis, les comptes nécessitant ce niveau d’accès doivent être placés temporairement dans le groupe Administrateurs pour le domaine en question. Bien que les utilisateurs utilisent les comptes hautement privilégiés, les activités doivent être auditées et, de préférence, effectuées avec un utilisateur effectuant les modifications et un autre utilisateur observant les modifications afin de réduire la probabilité d’une mauvaise utilisation ou d’une mauvaise configuration par inadvertance. Une fois les activités terminées, les comptes doivent être immédiatement supprimés du groupe Administrateurs. Pour ce faire, vous pouvez utiliser des procédures manuelles et des processus documentés, des logiciels tiers de gestion des identités/accès privilégiés (PIM/PAM) ou une combinaison des deux.

Les administrateurs sont, par défaut, les propriétaires de la plupart des objets AD DS dans leurs domaines respectifs. L’appartenance à ce groupe peut être requise dans les scénarios de génération et de reprise d’activité dans lesquels la propriété ou la capacité à prendre possession des objets est requise. En outre, les Administrateurs du domaine et les Administrateurs de l’entreprise héritent d’un certain nombre de leurs droits et autorisations en vertu de leur appartenance par défaut au groupe Administrateurs. L’imbrication de groupes par défaut pour les groupes privilégiés dans Active Directory ne doit pas être modifiée, et le groupe Administrateurs de chaque domaine doit être sécurisé comme décrit à l’Annexe G : Sécurisation des groupes d’administrateurs dans Active Directory et dans les instructions générales ci-dessous.

  1. Supprimez tous les membres du groupe Administrateurs, à l’exception possible du compte Administrateur local pour le domaine, à condition qu’il ait été sécurisé comme décrit à l’Annexe D : Sécurisation des comptes Administrateur intégrés dans Active Directory.

  2. Les membres du groupe Administrateurs du domaine ne doivent jamais avoir besoin de se connecter aux stations de travail ou aux serveurs membres. Dans un ou plusieurs objets de stratégie de groupe liés à des unités d’organisation de stations de travail et de serveurs membres dans chaque domaine, le groupe Administrateurs doit être ajouté aux droits utilisateur suivants :

    • Refuser l'accès à cet ordinateur à partir du réseau
    • Interdire l’ouverture de session en tant que tâche
    • Interdire l’ouverture de session en tant que service
    • Cela empêchera les membres du groupe Administrateurs d’être utilisés pour se connecter à des stations de travail ou des serveurs membres (sauf si plusieurs contrôles sont d’abord enfreints), où leurs informations d’identification pourraient être mises en cache et ainsi compromises. Un compte privilégié ne doit jamais être utilisé pour se connecter à un système moins privilégié, et l’application de ces contrôles offre une protection contre un certain nombre d’attaques.

  3. Au niveau de l’unité d’organisation des contrôleurs de domaine dans chaque domaine de la forêt, le groupe Administrateurs doit se voir accorder les droits utilisateur suivants (s’il n’en dispose pas déjà), qui permettront aux membres du groupe Administrateurs d’effectuer les fonctions nécessaires pour un scénario de reprise d’activité à l’échelle de la forêt :

    • Accéder à cet ordinateur à partir du réseau
    • Permettre l’ouverture d’une session locale
    • Autoriser l’ouverture de session par les services Bureau à distance

  4. L’audit doit être configuré de façon à envoyer des alertes si des modifications sont apportées aux propriétés ou à l’appartenance au groupe Administrateurs. Ces alertes doivent être envoyées, au minimum, aux membres de l’équipe responsable de l’administration d’AD DS. Les alertes doivent également être envoyées aux membres de l’équipe de sécurité, et des procédures doivent être définies pour modifier l’appartenance au groupe Administrateurs. Plus précisément, ces processus doivent inclure une procédure par laquelle l’équipe de sécurité est avertie lorsque le groupe Administrateurs va être modifié, afin que lorsque des alertes sont envoyées elles soient attendues et qu’aucune alarme ne soit déclenchée. En outre, des processus doivent être implémentés afin d’informer l’équipe de sécurité lorsque l’utilisation du groupe Administrateurs est terminée et que les comptes utilisés ont été supprimés du groupe.

Remarque

Lorsque vous implémentez des restrictions sur le groupe Administrateurs dans des objets de stratégie de groupe, Windows applique les paramètres aux membres du groupe Administrateurs local d’un ordinateur en plus du groupe Administrateurs du domaine. Par conséquent, vous devez faire preuve de prudence lorsque vous implémentez des restrictions sur le groupe Administrateurs. Bien qu’il soit recommandé d’interdire les ouvertures de session réseau, par fichier de commande et par service pour les membres du groupe Administrateurs partout où cette implémentation est possible, ne limitez pas les ouvertures de session locales ou les ouvertures de session par le biais des services Bureau à distance. Le blocage de ces types d’ouverture de session peut bloquer l’administration légitime d’un ordinateur par les membres du groupe Administrateurs local. La capture d’écran suivante montre les paramètres de configuration qui bloquent l’utilisation incorrecte des comptes d’administrateurs locaux et de domaine intégrés, en plus de l’utilisation incorrecte des groupes d’administrateurs locaux ou de domaine intégrés. Notez que le droit d’utilisation Interdire l’ouverture de session par les services Bureau à distance n’inclut pas le groupe Administrateurs, car le fait de l’inclure dans ce paramètre bloquerait également ces ouvertures de session pour les comptes membres du groupe Administrateurs de l’ordinateur local. Si des services sur les ordinateurs sont configurés pour s’exécuter dans le contexte de l’un des groupes privilégiés décrits dans cette section, l’implémentation de ces paramètres peut entraîner l’échec des services et des applications. Par conséquent, comme pour toutes les recommandations de cette section, vous devez tester minutieusement les paramètres afin de vérifier leur applicabilité dans votre environnement.

least privilege admin models

Contrôle d’accès en fonction du rôle (RBAC) pour Active Directory

En règle générale, les contrôles d’accès en fonction du rôle (RBAC) sont un mécanisme permettant de regrouper les utilisateurs et de fournir l’accès aux ressources en fonction de règles métier. Dans le cas d’Active Directory, l’implémentation de RBAC pour AD DS est le processus qui consiste à créer des rôles auxquels des droits et des autorisations sont délégués pour permettre aux membres du rôle d’effectuer des tâches administratives quotidiennes sans leur accorder des privilèges excessifs. RBAC pour Active Directory peut être conçu et implémenté via des interfaces et des outils natifs, en tirant parti de logiciels que vous possédez peut-être déjà, en achetant des produits tiers ou toute combinaison de ces approches. Cette section ne fournit pas d’instructions pas à pas pour implémenter RBAC pour Active Directory, mais décrit plutôt les facteurs à prendre en compte lors du choix d’une approche d’implémentation de RBAC dans vos installations AD DS.

Approches natives de RBAC pour Active Directory

Dans l’implémentation RBAC la plus simple, vous pouvez implémenter des rôles en tant que groupes AD DS, et déléguer des droits et des autorisations aux groupes qui leur permettent d’effectuer une administration quotidienne dans l’étendue désignée du rôle.

Dans certains cas, les groupes de sécurité existants dans Active Directory peuvent être utilisés pour accorder des droits et des autorisations appropriés à une fonction de tâche. Par exemple, si des employés spécifiques de votre organisation informatique sont responsables de la gestion et de la maintenance des zones et enregistrements DNS, pour déléguer ces responsabilités il pourrait suffire de créer un compte pour chaque administrateur DNS et de l’ajouter au groupe Administrateurs DNS dans Active Directory. Le groupe Administrateurs DNS, contrairement aux groupes plus hautement privilégiés, dispose de peu de droits puissants dans Active Directory, bien que les membres de ce groupe aient reçu des autorisations déléguées qui leur permettent d’administrer le système DNS et qu’ils soient toujours sujets à des compromissions et à des abus pouvant entraîner une élévation de privilèges.

Dans d’autres cas, vous devrez peut-être créer des groupes de sécurité et déléguer des droits et des autorisations aux objets Active Directory, aux objets de système de fichiers et aux objets du Registre pour permettre aux membres des groupes d’effectuer des tâches d’administration désignées. Par exemple, si les opérateurs de votre support technique sont chargés de réinitialiser les mots de passe oubliés, d’aider les utilisateurs ayant des problèmes de connectivité et de résoudre les problèmes liés aux paramètres d’application, vous devrez peut-être combiner des paramètres de délégation sur des objets utilisateur dans Active Directory avec des privilèges qui permettent aux utilisateurs du support technique de se connecter à distance aux ordinateurs des utilisateurs pour afficher ou modifier les paramètres de configuration des utilisateurs. Pour chaque rôle que vous définissez, vous devez identifier :

  1. Quelles tâches les membres du rôle effectuent au jour le jour, et quelles tâches sont moins fréquemment exécutées.
  2. Sur quels systèmes et dans quelles applications les membres d’un rôle doivent se voir accorder des droits et des autorisations.
  3. Quels utilisateurs doivent être membres d’un rôle.
  4. Comment la gestion des appartenances aux rôles sera effectuée.

Dans de nombreux environnements, la création manuelle de contrôles d’accès en fonction du rôle pour l’administration d’un environnement Active Directory peut être difficile à implémenter et à tenir à jour. Si vous avez clairement défini des rôles et des responsabilités pour l’administration de votre infrastructure informatique, vous pouvez utiliser des outils supplémentaires pour vous aider à créer un déploiement RBAC natif gérable. Par exemple, si vous utilisez Forefront Identity Manager (FIM) dans votre environnement, vous pouvez automatiser la création et la population de rôles d’administration, ce qui peut faciliter l’administration continue. Si vous utilisez Microsoft Endpoint Configuration Manager et System Center Operations Manager (SCOM), vous pouvez utiliser des rôles propres à l’application pour déléguer des fonctions de gestion et de monitoring, et également appliquer une configuration et un audit cohérents parmi les systèmes du domaine. Si vous avez implémenté une infrastructure à clé publique (PKI), vous pouvez émettre et exiger des cartes à puce pour le personnel informatique responsable de l’administration de l’environnement. Avec FIM Credential Management (FIM CM), vous pouvez même combiner la gestion des rôles et des informations d’identification pour votre personnel administratif.

Dans d’autres cas, il peut être préférable pour une organisation de déployer un logiciel RBAC tiers qui fournit des fonctionnalités « prêtes à l’emploi ». Des solutions de type « produit du commerce » pour RBAC pour les systèmes d’exploitation et annuaires Active Directory, Windows et non-Windows sont proposées par un certain nombre de fournisseurs. Lorsque vous choisissez entre des solutions natives et des produits tiers, vous devez tenir compte des facteurs suivants :

  1. Budget : en investissant dans le développement de RBAC avec des logiciels et des outils que vous possédez peut-être déjà, vous pouvez réduire les coûts logiciels associés au déploiement d’une solution. Toutefois, à moins d’avoir du personnel expérimenté dans la création et le déploiement de solutions RBAC natives, vous devrez peut-être faire appel à des ressources de conseil pour développer votre solution. Vous devez évaluer soigneusement les coûts prévus pour une solution développée sur mesure, par rapport aux coûts de déploiement d’une solution « prête à l’emploi », en particulier si votre budget est limité.
  2. Composition de l’environnement informatique : si votre environnement est principalement composé de systèmes Windows, ou si vous utilisez déjà Active Directory pour la gestion de comptes et de systèmes non-Windows, des solutions natives personnalisées peuvent fournir la solution optimale pour vos besoins. Si votre infrastructure contient de nombreux systèmes qui n’exécutent pas Windows et qui ne sont pas gérés par Active Directory, vous devrez peut-être envisager des options de gestion des systèmes non-Windows séparément de l’environnement Active Directory.
  3. Modèle de privilège dans la solution : si un produit s’appuie sur le placement de ses comptes de service dans des groupes hautement privilégiés dans Active Directory et n’offre pas d’options qui ne nécessitent pas l’octroi de privilèges excessifs au logiciel RBAC, vous n’avez pas vraiment réduit votre surface d’attaque Active Directory ; vous avez seulement modifié la composition des groupes les plus privilégiés dans l’annuaire. À moins qu’un fournisseur d’application puisse fournir des contrôles pour les comptes de service qui réduisent la probabilité que les comptes soient compromis et utilisés de manière malveillante, vous devrez peut-être envisager d’autres options.

Privileged Identity Management

Privileged Identity Management (PIM), parfois appelé Privileged Account Management (PAM) ou Privileged Credential Management (PCM) est la conception, la construction et l’implémentation d’approches de gestion des comptes privilégiés dans votre infrastructure. En règle générale, PIM fournit des mécanismes par lesquels les comptes bénéficient de droits et d’autorisations temporaires nécessaires pour effectuer des fonctions de correction de build ou d’arrêt, plutôt que de laisser des privilèges attachés de façon permanente aux comptes. Si la fonctionnalité PIM est créée manuellement ou implémentée via le déploiement de logiciels tiers, une ou plusieurs des fonctionnalités suivantes peuvent être disponibles :

  • « Coffres » d’informations d’identification, où les mots de passe des comptes privilégiés sont « extraits » et où un mot de passe initial est affecté, puis « archivés » une fois les activités terminées, après quoi les mots de passe sont à nouveau réinitialisés sur les comptes.
  • Restrictions limitées dans le temps sur l’utilisation d’informations d’identification privilégiées
  • Informations d’identification à usage unique
  • Octroi de privilèges généré par workflow avec monitoring et création de rapports sur les activités effectuées et suppression automatique des privilèges lorsque les activités sont terminées ou que le temps alloué a expiré
  • Remplacement des informations d’identification codées en dur, telles que les noms d’utilisateur et les mots de passe dans les scripts, par des interfaces de programmation d’application (API) qui permettent de récupérer les informations d’identification à partir de coffres en fonction des besoins
  • Gestion automatique des informations d’identification de compte de service

Création de comptes non privilégiés pour gérer des comptes privilégiés

L’un des défis de la gestion des comptes privilégiés est le fait que, par défaut, les comptes qui peuvent gérer des comptes et des groupes privilégiés et protégés sont des comptes privilégiés et protégés. Si vous implémentez des solutions RBAC et PIM appropriées pour votre installation d’Active Directory, les solutions peuvent inclure des approches qui vous permettent de « dérenseigner » l’appartenance des groupes les plus privilégiés dans l’annuaire, et de renseigner les groupes uniquement temporairement et si nécessaire.

Toutefois, si vous implémentez RBAC et PIM nativement, vous devez envisager de créer des comptes qui n’ont aucun privilège et avec la seule fonction de renseigner et dérenseigner les groupes privilégiés dans Active Directory en cas de besoin. Annexe I : Création de comptes de gestion pour les comptes protégés et les groupes dans Active Directory fournit des instructions pas à pas que vous pouvez utiliser pour créer des comptes à cet effet.

Implémentation de contrôles d’authentification robustes

Loi numéro six : Il existe vraiment quelqu’un qui essaie de deviner vos mots de passe. - 10 lois immuables de l’administration de la sécurité

Les attaques Pass-the-hash et autres attaques de vol d’informations d’identification ne sont pas propres aux systèmes d’exploitation Windows, et elles ne sont pas nouvelles. La première attaque Pass-the-hash a été créée en 1997. Historiquement, cependant, ces attaques nécessitaient des outils personnalisés, elles ne réussissaient pas à chaque fois, et elles exigeaient des attaquants un niveau de compétence relativement élevé. L’introduction d’outils accessibles gratuitement et faciles à utiliser qui extraient de manière native des informations d’identification a entraîné une augmentation exponentielle du nombre et du taux de succès des attaques d’usurpation d’informations d’identification ces dernières années. Toutefois, les attaques de vol d’informations d’identification ne sont en aucun cas les seuls mécanismes par lesquels les informations d’identification sont ciblées et compromises.

Bien que vous deviez implémenter des contrôles pour vous protéger contre les attaques de vol d’informations d’identification, vous devez également identifier les comptes de votre environnement qui sont les plus susceptibles d’être ciblés par des attaquants, et implémenter des contrôles d’authentification robustes pour ces comptes. Si vos comptes les plus privilégiés utilisent l’authentification à facteur unique, comme les noms d’utilisateur et les mots de passe (tous deux sont « quelque chose que vous connaissez », ce qui est un facteur d’authentification), ces comptes sont faiblement protégés. Tout ce dont un attaquant a besoin est la connaissance du nom d’utilisateur et la connaissance du mot de passe associé au compte, et les attaques Pass-the-hash sont possibles si l’attaquant peut s’authentifier en tant qu’utilisateur sur un système qui accepte des informations d’identification à facteur unique.

Bien que l’implémentation de l’authentification multifacteur ne vous protège pas contre les attaques Pass-the-hash, son implémentation en combinaison avec des systèmes protégés peut vous en protéger. Des informations supplémentaires sur l’implémentation de systèmes protégés sont fournies dans Implémentation d’hôtes d’administration sécurisés, et des options d’authentification sont présentées dans les sections suivantes.

Contrôles d’authentification généraux

Si vous n’avez pas encore implémenté l’authentification multifacteur, comme des cartes à puce, envisagez de le faire. Les cartes à puce implémentent une protection matérielle des clés privées dans une paire de clés publique-privée. Cela empêche tout accès à la clé privée d’un utilisateur, ou son utilisation, sans présentation à la carte à puce d’un code confidentiel, d’un secret ou d’un identificateur biométrique correct. Même si le code confidentiel ou secret d’un utilisateur est intercepté par un enregistreur de frappe sur un ordinateur compromis, pour qu’un attaquant puisse réutiliser ce code, la carte doit également être physiquement présente.

Dans les cas où les mots de passe longs et complexes se sont avérés difficiles à implémenter en raison de la résistance des utilisateurs, les cartes à puce fournissent un mécanisme permettant à ceux-ci d’implémenter des codes confidentiels ou secrets relativement simples, sans que les informations d’identification soient exposées à des attaques par force brute ou basées sur des tables arc-en-ciel. Les codes confidentiels de carte à puce ne sont pas stockés dans Active Directory ou dans des bases de données SAM locales, même si des hachages d’informations d’identification peuvent encore être stockés dans une mémoire protégée pas LSAPS sur des ordinateurs sur lesquels des cartes à puce ont été utilisées à des fins d’authentification.

Contrôles supplémentaires pour les comptes VIP

Un autre avantage de l’implémentation de cartes à puce ou d’autres mécanismes d’authentification basés sur des certificats est la possibilité de tirer parti de l’Assurance de mécanisme d’authentification (AMA) pour protéger les données sensibles accessibles aux utilisateurs VIP. AMA est disponible dans les domaines dans lesquels le niveau fonctionnel est défini sur Windows Server 2012 ou Windows Server 2008 R2. Lorsqu’elle est activée, AMA ajoute une appartenance au groupe global désignée par l’administrateur au jeton Kerberos d’un utilisateur quand les informations d’identification de l’utilisateur sont authentifiées lors de l’ouverture de session à l’aide d’une méthode d’ouverture de session basée sur un certificat.

Cela permet aux administrateurs de ressources de contrôler l’accès aux ressources, telles que les fichiers, les dossiers et les imprimantes, selon que l’utilisateur se connecte à l’aide d’une méthode d’ouverture de session basée sur un certificat ou non, en plus du type de certificat utilisé. Par exemple, lorsqu’un utilisateur se connecte à l’aide d’une carte à puce, l’accès de l’utilisateur aux ressources sur le réseau peut être spécifié comme différent de ce qu’est l’accès lorsque l’utilisateur n’utilise pas de carte à puce (autrement dit, lorsqu’il se connecte en entrant un nom d’utilisateur et un mot de passe). Pour plus d’informations sur AMA, consultez Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide.

Configuration de l’authentification de compte privilégié

Dans Active Directory pour tous les comptes d’administration, activez l’attribut Ouverture de session interactive : carte à puce nécessaire et auditez (au minimum) les modifications apportées à tous les attributs de l’onglet Compte du compte (par exemple cn, name, sAMAccountName, userPrincipalName et userAccountControl).

Bien que la définition de Ouverture de session interactive : carte à puce nécessaire sur les comptes réinitialise le mot de passe du compte à une valeur aléatoire de 120 caractères et nécessite des cartes à puce pour les ouvertures de session interactives, l’attribut peut toujours être remplacé par les utilisateurs disposant d’autorisations qui leur permettent de modifier les mots de passe sur les comptes, et les comptes peuvent ensuite être utilisés pour établir des ouvertures de session non interactives avec uniquement le nom d’utilisateur et le mot de passe.

Dans d’autres cas, en fonction de la configuration des comptes dans Active Directory et des paramètres de certificat dans Active Directory Certificate Services (AD CS) ou une infrastructure PKI tierce, les attributs de nom d’utilisateur principal (UPN) pour les comptes administratifs ou VIP peuvent être ciblés pour un type d’attaque spécifique, comme décrit ici.

Détournement d’UPN pour l’usurpation de certificat

Bien qu’une discussion approfondie sur les attaques contre les infrastructures PKI ne rentre pas dans le cadre de ce document, les attaques contre les infrastructures PKI publiques et privées ont augmenté de façon exponentielle depuis 2008. Les violations des infrastructures PKI publiques ont été largement médiatisées, mais les attaques contre l’infrastructure PKI interne d’une organisation sont peut-être encore plus prolifiques. L’une de ces attaques tire parti d’Active Directory et des certificats pour permettre à un attaquant d’usurper les informations d’identification d’autres comptes d’une manière qui peut être difficile à détecter.

Lorsqu’un certificat est présenté pour l’authentification auprès d’un système joint à un domaine, le contenu de l’attribut Subject ou Subject Alternative Name (SAN) dans le certificat est utilisé pour mapper le certificat à un objet utilisateur dans Active Directory. En fonction du type de certificat et de la façon dont il est construit, l’attribut Subject d’un certificat contient généralement le nom commun (CN) d’un utilisateur, comme illustré dans la capture d’écran suivante.

Screenshot that shows the Subject attribute in a certificate typically contains a user's common name.

Par défaut, Active Directory construit le nom commun d’un utilisateur en concaténant le prénom du compte + «   » + nom de famille. Toutefois, les composants CN des objets utilisateur dans Active Directory ne sont pas obligatoires et leur caractère unique n’est pas garanti, et le déplacement d’un compte d’utilisateur vers un autre emplacement dans l’annuaire modifie le nom unique du compte, qui est le chemin complet de l’objet dans l’annuaire, comme illustré dans le volet inférieur de la capture d’écran précédente.

Étant donné que le caractère unique ou statique des noms d’objet de certificat n’est pas garanti, le contenu de l’autre nom de l’objet (SAN) est souvent utilisé pour localiser l’objet utilisateur dans Active Directory. L’attribut SAN pour les certificats émis aux utilisateurs par les autorités de certification d’entreprise (autorités de certification intégrées à Active Directory) contient généralement l’UPN ou l’adresse e-mail de l’utilisateur. Le caractère unique des UPN étant garanti dans une forêt AD DS, la localisation d’un objet utilisateur par UPN est généralement effectuée dans le cadre de l’authentification, avec ou sans certificats impliqués dans le processus d’authentification.

L’utilisation des UPN dans les attributs SAN dans les certificats d’authentification peut être exploitée par les attaquants pour obtenir des certificats frauduleux. Si un attaquant a compromis un compte qui a la capacité à lire et à écrire des UPN sur des objets utilisateur, l’attaque est implémentée comme suit :

La valeur de l’attribut UPN sur un objet utilisateur (tel qu’un utilisateur VIP) est temporairement modifiée. L’attribut de nom de compte SAM et le CN peuvent également être modifiés à ce moment-là, bien que cela ne soit généralement pas nécessaire pour les raisons décrites précédemment.

Lorsque l’attribut UPN sur le compte cible a été modifié, l’attribut UPN d’un compte d’utilisateur fraîchement créé ou d’un compte d’utilisateur obsolète activé est remplacé par la valeur qui était attribuée à l’origine au compte cible. Les comptes d’utilisateur obsolètes activés sont des comptes qui ne se sont pas connectés depuis très longtemps, mais qui n’ont pas été désactivés. Ils sont ciblés par des attaquants qui ont l’intention de « se cacher au vu de tous » pour les raisons suivantes :

  1. Étant donné que le compte est activé mais qu’il n’a pas été utilisé récemment, il est peu probable que son utilisation déclenche des alertes comme lors de l’activation d’un compte d’utilisateur désactivé.
  2. L’utilisation d’un compte existant ne nécessite pas la création d’un nouveau compte d’utilisateur, susceptible d’être remarquée par le personnel administratif.
  3. Les comptes d’utilisateur obsolètes qui sont encore activés sont généralement membres de différents groupes de sécurité et disposent d’un accès aux ressources sur le réseau, ce qui simplifie l’accès et permet à l’attaquant de mieux « se fondre dans la masse » au milieu d’une population d’utilisateurs existante.

Le compte d’utilisateur sur lequel l’UPN cible a maintenant été configuré est utilisé pour demander un ou plusieurs certificats aux services de certificats Active Directory.

Lorsque des certificats ont été obtenus pour le compte de l’attaquant, les UPN sur le « nouveau » compte et le compte cible sont rétablis à leurs valeurs d’origine.

L’attaquant dispose désormais d’un ou plusieurs certificats qui peuvent être présentés pour l’authentification auprès de ressources et d’applications comme si l’utilisateur était l’utilisateur VIP dont le compte a été temporairement modifié. Bien qu’une description complète de toutes les façons dont les certificats et l’infrastructure PKI peuvent être ciblés par des attaquants n’entre pas dans le cadre de ce document, ce mécanisme d’attaque est décrit afin d’illustrer pourquoi vous devez superviser les modifications apportées aux comptes privilégiés et VIP dans AD DS, en particulier celles apportées à l’un des attributs de l’onglet Compte du compte (par exemple cn, name, sAMAccountName, userPrincipalName et userAccountControl). En plus de superviser les comptes, vous devez faire en sorte qu’un ensemble d’utilisateurs administratifs le plus petit possible puisse les modifier. De même, les comptes des utilisateurs administratifs doivent être protégés et supervisés afin de détecter toute modification non autorisée.