Tiering AD : protection de l'accès administrateur aux tiers 1 et 2 

Alors que la surface d'attaque sur l'identité continue d'évoluer avec de nouvelles méthodes de compromission, la nécessité de sécuriser les données d'une organisation Active Directory (AD) devient de plus en plus important. Active Directory est une pratique fondamentale pour séparer et protéger les comptes à privilèges élevés, mais de nombreuses organisations négligent son importance, les laissant vulnérables aux acteurs malveillants.  

La mise en œuvre de contrôles de sécurité stricts pour les groupes d'accès est essentielle pour empêcher tout accès non autorisé et mouvement latéral au sein du réseau. Dans ce blog, nous explorerons les éléments essentiels du tiering AD et les défis courants en matière de protection, et des capacités de protection de Silverfort pour surmonter ces défis, rendant le tiering AD plus simple et plus efficace. 

Défis courants pour étendre les contrôles d’accès au-delà du tier 0

Une fois que le projet de tiering Active Directory a atteint la phase de mise en œuvre, généralement des contrôles natifs (Active Directory stratégies de groupe (GPO) avec restrictions de connexion) et / ou Silos de stratégies d'authentification sont utilisés pour verrouiller les accès au Tier 0 (Contrôleurs de domaine, AC de signature en ligne PKI, Entra Connect / AD FS), qui seront ensuite gérés exclusivement depuis des consoles d'administration dédiées, les Privilege Access Workstations. 

Cependant, pour diverses raisons, les organisations ont souvent du mal à étendre cette approche au Tier 1 – où 98 % de tous les comptes administrateurs et privilèges sont généralement utilisés. privilégiés résider. En conséquence, les clients potentiels nous demandent souvent comment nous pouvons les aider à mettre en œuvre des contrôles d'accès efficaces au-delà du Tier 0.

Voici les principaux défis auxquels la plupart des organisations sont confrontées lorsqu'elles tentent d'étendre leur sécurité. protocoles d'authentification et contrôles d'accès aux Tiers 1 et 2 :  

Les GPO (objets de stratégie de groupe) ne sont pas mis à l'échelle

Le grand nombre de permutations distinctes de contrôle d'accès requises pour chaque combinaison de rôle (propriétaire de l'application, administrateur de base de données, sauvegarde, etc.), de ressource (nom de l'application) et d'environnement (dev/test/staging/prod), nécessite un si grand nombre de GPO dont la mise en œuvre et le fonctionnement deviendraient trop complexes à gérer avec succès pour mettre en œuvre moindre privilège à l’intérieur du Tier 1. 

Restrictions de connexion définies de manière centralisée, mais appliquées localement

Les restrictions de connexion – étant la méthode la plus courante pour mettre en œuvre des contrôles d'accès, sont définies et stockées de manière centralisée dans le partage de fichiers SYSVOL, téléchargées sur chaque ordinateur avec un mappeur de stratégie de groupe et appliquées localement. Cette approche présente plusieurs inconvénients : 

• Les utilisateurs ou processus disposant de privilèges d'administrateur sur un système peuvent changer/désactiver/modifier les restrictions de connexion des utilisateurs pour d'autres comptes.  

• Des problèmes d’analyse des stratégies de groupe peuvent entraîner la non-application des restrictions de connexion.  

Pour détecter les problèmes lors de l'application des politiques ou les tentatives de les contourner (par exemple en utilisant ntrights.exe or Carbone), une surveillance des modifications de configuration locales sur chaque système est requise ainsi qu'un reporting centralisé de toute notification de non-conformité.  

Contrôles d'accès séparés pour les non-Windows Active Directory Outils

Une empreinte importante d'infrastructure non Windows qui est d'une manière ou d'une autre intégrée à Active Directory; si les systèmes *NIX se sont joints à l'aide d'une forme de pontage AD, d'applications et d'appliances qui s'appuient sur LDAP, Kerberos ou authentifications NTLM avec AD – utilisant souvent un compte de service plutôt qu'une identité de machine et ne traitant aucune ou seulement quelques stratégies de groupe. Ces appareils, applications et appareils nécessitent leurs propres contrôles d'accès, généralement définis localement et liés à l'appartenance au groupe AD. 

Ces ressources nécessitent chacune une configuration dédiée pour les contrôles d’accès et la surveillance de la conformité. 

Silos de stratégies d'authentification – Pas de panacée

Pour pallier aux problèmes liés aux contrôles d'accès appliqués localement sur chaque élément de l'infrastructure, Microsoft propose Silos de stratégies d'authentification. Ceux-ci peuvent être efficaces pour gérer et appliquer de manière centralisée les limites d’authentification des comptes et des actifs et sont évalués par le contrôleur de domaine pour chaque authentification. Bien qu’il s’agisse d’une excellente méthode pour verrouiller le Tier 0, leur manque de flexibilité a tendance à empêcher le déploiement au Tier 1, ce qui fait que les actifs (ressources et comptes) ne font partie que d’un seul silo de politique d’authentification à la fois. Souvent, différents groupes de utilisateurs privilégiés ont besoin d’accéder à différents ensembles de systèmes, qui peuvent se chevaucher en partie, ce qui ne correspond pas aux silos de stratégies d'authentification. 

Pour utiliser les silos de stratégie d’authentification, Kerberos Armoring (FAST) doit être activé. Des outils existants, notamment certains Privileged Access Management (PAM) des solutions de type Bastion ne sont pas toujours compatibles avec Kerberos Armoring.  

Après la mise en œuvre de contrôles d'accès efficaces au Tier 0, le déploiement vers d'autres tiers s'arrête souvent en raison d'un ou plusieurs des défis ci-dessus rencontrés par le personnel informatique, qui étaient jusqu'à présent très difficiles à contourner. Discutons de certaines choses que Silverfort peut faire pour étendre la mise en œuvre des contrôles d’accès et MFA au-delà du tier 0. 

Comment Silverfort Aide au tiering AD   

Silverfort peut améliorer le tiering AD en permettant visibilité et contrôle étendus sur l’accès des utilisateurs dans toute l’organisation. Il surveille en permanence les activités d'authentification et d'accès, en attribuant des indicateurs de risque et des scores aux utilisateurs et aux machines en fonction de leurs modèles de comportement, et vérifie si le contexte d'authentification correspond à un contexte. S'il y a une correspondance, la stratégie définit s'il faut autoriser l'authentification, suspendre l'authentification pour appliquer MFA ou bloquer l'authentification. un peu comme un feu de circulation pour votre Active Directory authentifications. Ce processus permet d'identifier et de gérer l'accès aux actifs à haut risque ou de grande valeur, ce qui est crucial pour le tiering AD. En plus, L'intégration de Entra ID fournit des informations supplémentaires sur le comportement et les risques des utilisateurs, soutenant la mise en œuvre d’une stratégie efficace de tiering AD. 

Voyons exactement comment cela se matérialise dans la console Silverfort: 

Protection 

Les politiques étendent le concept de contrôle d’accès conditionnel à Active Directory, permettant de contrôler qui peut s'authentifier où ainsi que le niveau d'assurance d'authentification (si MFA est requis, ainsi que le type d'authentification accepté lors de l'étape d'authentification secondaire), en fonction du contexte utilisateur enrichi de son propre moteur de risque ainsi que de tout Les risques sont perçus par les moteurs de risque tiers, tels que les silos d'identité EDR, XDR et cloud, et sont appliqués de manière centralisée au niveau du contrôleur de domaine. 

Voici quelques exemples de politiques d’authentification qui peuvent aider à la mise en œuvre d’un modèle de tiering AD : 

Bloquer la connexion interactive entre les tiers  

Après une formation de sensibilisation auprès des administrateurs informatiques qui ont franchi les barrières de tier avec leurs comptes de Tier 0 ou de Tier 1 (par exemple découverts à l'aide des politiques NOTIFY proposées dans l'article du blog AD Tiering sur la visibilité), cela peut être le bon moment pour faire passer ces politiques de l'action NOTIFY à l'action DENY, pour bloquer l'utilisation inappropriée du compte à travers les Tiers et recevoir des alertes en temps réel ainsi que des rapports quotidiens sur toute tentative de ce type. 

Protéger les privilégiés Comptes d'utilisateurs Avec MFA approprié

L'accès avec des comptes privilégiés dans n'importe quel Tier peut être protégé avec des méthodes MFA appropriées. Par exemple, l'administration à distance de « Application X dans PROD » par les administrateurs d'applications Tier 1 pour ce périmètre peut être protégée avec FIDO2 et/ou Silverfort MFA Push sur mobile s’il n’y a pas de MFA tiers dédié disponible pour les comptes de Tier 1. 

Accès sécurisé à la console sur les contrôleurs de domaine

 Si l'accès aux contrôleurs de domaine sur la console est possible (par exemple via l'hyperviseur) et n'est pas suffisamment protégé, la stratégie de connexion Windows Silverfort peut aider à protéger l’accès à la console. 

Appliquer l'utilisation de solutions d'administration spécifiques à chaque Tier

Pour forcer l'administration à partir d'un serveur de saut d'administrateur dédié ou Solution PAM en T1, l'authentification RDP et Remote PowerShell peut être refusée depuis toute autre origine à l'aide d'une stratégie DENY. 

Arrêter les mouvements latéraux des comptes d'utilisateurs au sein d'un tier

Pour limiter les mouvements latéraux / mettre en œuvre les moindres privilèges au sein du Tier 1, l'administration à distance d'un groupe de serveurs « Application X dans PROD » peut être limitée au(x) groupe(s) d'administrateurs des serveurs d'applications utilisant une politique DENY. 

Arrêter les mouvements latéraux des comptes de service au sein d'un tier

Pour limiter les mouvements latéraux/mettre en œuvre les moindres privilèges au sein du Tier 1, les comptes de service peuvent être « cantonnés » pour fournir uniquement un accès au périmètre où ils devraient opérer. 

Les politiques de protection SIlverfort aident à étendre le tiering AD au-delà du tier 0 

La combinaison du pare-feu d'authentification, des politiques MFA et la protection des comptes de service offrent une approche élégante et efficace pour accélérer le déploiement du tiering AD au-delà du Tier 0 

Silverfort peut aider à protéger les comptes Active Directory avec une méthode MFA la plus appropriée pour la tâche. Le Silverfort le pare-feu d'authentification permet la détection et la prévention de tout accès inter-niveaux par des comptes privilégiés pour empêcher les déplacements verticaux et élévations de privilèges attaques, ainsi que la limitation de l'accès horizontal au sein d'un tier pour empêcher les mouvements latéraux, en utilisant une application centrale tout en évitant les complexités typiques associées aux méthodes existantes.  

Les comptes humains et de service peuvent être sécurisés, bloquant les accès non autorisés pour arrêter les mouvements latéraux et empêcher l'élévation des privilèges par un adversaire. Utilisation des contrôles de sécurité fournis par Silverfort peut accélérer la mise en œuvre du tiering AD, ou peut aider à remettre le projet sur les rails s'il est bloqué à la fin de la couverture du Tier 0. Vous cherchez à renforcer votre gestion du tiering AD et à obtenir une visibilité complète sur votre environnement ? Contactez l'un de nos experts ici.