Sécurité des actifs dans un contexte de silotage AD...

Sa protection doit donc être renforcée, surtout dans le contexte actuel où les cybermenaces ne cessent de s’amplifier. Même si on ne peut pas les empêcher, il existe des moyens de réduire la surface d’attaque d’Active Directory. Alors, qu’est-ce qu’on entend par silotage AD (AD Tiering) et surtout qu’est-ce qu’il permet de faire ? :

• Il va permettre de référencer les ressources pour les protéger au seins d’Active Directory
• Il va durcir le niveau de sécurité pour empêcher les cybercriminels de compromettre les comptes de l’annuaire.

Il est donc important que l’ensemble des mesures et recommandations abordées dans cet article, soit appliqué lors des actes d’administration dans des environnements critiques. Et en complémentarité, des solutions de gestion de comptes à privilège (PAM) vont devoir s’interfacer dans ces contextes de protection Active Directory, et ce, sans amoindrir le niveau de sécurité attendu.

L’ANSSI, dans son document PA-022, reprend deux points essentiels pour protéger l'accès aux annuaires des comptes d'administration (recommandation R28) :

1. Le ou les annuaires contenant les comptes d’administration doivent être protégés en confidentialité, en intégrité et ne doivent pas être exposés sur des environnements de moindre confiance
2. Dans un SIA (Système d’Information Administré), qui repose sur un annuaire Microsoft Active Directory, il est recommandé d’adopter un modèle « trois tiers » pour gérer les comptes à privilèges. En général, il est même recommandé de déployer un ou plusieurs annuaires dédiés au sein du système d'information d’administration.

Microsoft propose depuis Active Directory 2012 R2, un modèle d’administration multi-niveaux appelé « Tier-model ». L'objectif est de partitionner ce modèle en trois zones ou trois tiers, de référencer l'ensemble des comptes Active Directory et des ressources Windows, pour les ventiler dans chacun des tiers en fonction de leur criticité. Le browsing d’un tiers à l’autre est interdit.

En fait, on cloisonne sur trois niveaux d’administration les différentes strates de l’infrastructure du SIA pour garantir qu’en cas de cyber-attaque, un poste de travail corrompu ne vienne corrompre les serveurs d’infrastructure et les serveurs qui portent les identités (contrôleurs de domaine, PKI, ADFS, etc...). On limite ainsi les déplacements latéraux pour éviter toute propagation d’infection entre les différents tiers.

Pour commencer, il faut répartir l’ensemble des acteurs Active Directory, dans trois catégories au sein du système d’information :

• 1ère catégorie : Elle concerne les ressources qui hébergent, les données (fichiers, messagerie, BDD, métier, etc…) et les identités, les contrôles d’accès (comptes utilisateurs, comptes de services, certificats, etc...). Les ressources sont généralement représentées par des serveurs.
• 2ème catégorie : Elle concerne les utilisateurs qui doivent pouvoir accéder aux ressources via des accès limités en droits. Par définition, on sait qu’un utilisateur ne peut pas élever ses privilèges.
• 3ème catégorie : Elle concerne les administrateurs qui sont des utilisateurs à hauts privilèges. Ils peuvent gérer les autorisations d’accès aux ressources, contourner certains mécanismes de sécurité, modifier la configuration des systèmes, et encore bien d’autres choses.

Une fois cette répartition effectuée, on peut construire le Tier-model, donc définir la segmentation des tiers d’administration. Fonction de ces trois catégories, on segmente les tiers d’administration de la façon suivante :

• Segmentation des ressources :
  • Tiers 0 : Il implémente l’ensemble des ressources et des serveurs qui hébergent des mécanismes d’administration
  • Tiers 1 : Il implémente les serveurs d’infrastructure et les serveurs métier.
  • Tiers 2 : Il implémente les postes de travail.
• Segmentation des administrateurs :
  • Tiers 0 : Il implémente les administrateurs avec des droits admin du domaine
  • Tiers 1 : Il implémente les administrateurs des serveurs.
  • Tiers 2 : Il implémente les administrateurs des postes de travail.
• Segmentation des utilisateurs :
  • Il n’y a pas de segmentation car ils peuvent utiliser n’importe quelle ressource mais pas en prendre le contrôle.

Description du Tiers model :

• Tiers 0 (les identités) : il intègre les serveurs possédants les identités et les secrets d’authentification de l’organisation. Ce tiers permet de contrôler toutes les ressources, y compris celles des autres niveaux. C’est le niveau le plus sensible de ce modèle car la compromission de l’annuaire par exemple compromettrait implicitement les éléments des autres tiers. Si l’Active Directory s’arrête, toute l’organisation s’arrête.
• Tiers 1 (les serveurs) : il intègre tous les serveurs qui ne portent pas les identités. C’est le niveau le plus important car contient en général l’ensemble des données de l'organisation.
• Tiers 2 (les postes de travail) :  il intègre les postes clients, bureautique, etc… C’est le niveau le plus vulnérable.

Dans un environnement Active Directory, les secret d’authentification vont circuler sous des formes différentes selon le protocole d’authentification utilisé. Les protocoles d’authentification proposés par Microsoft dans Windows sont NTLM et Kerberos. Le choix du modèle de protocole sera donc crucial pour maximiser la protection des secrets d’authentification contre les tentatives de corruption de personnes malveillantes.

Protocole NTLM.

NTLM est le protocole d’authentification historique de Windows et encore aujourd’hui, nombre d’applications l’utilisent toujours. Même si le protocole Kerberos est à privilégier dans les domaines Active Directory, NTLM dans sa deuxième version, couplé à une politique de mots de passe complexe, reste toléré même s’il est à bannir dans les contexte Active Directory siloté.

Lors d’une authentification NTLM, les secrets d’authentification sont accessibles sur le poste client, le serveur distant (la ressource) et les échanges entre le poste et la ressource. NTLM les protège assez mal.

Protocole Kerberos.

Kerberos est un protocole d'authentification qui repose sur un mécanisme de clés secrètes et l'utilisation de tickets (cryptographie symétrique). C’est le protocole d’authentification par défaut utilisé par Windows car il améliore radicalement la protection des secrets d’authentification par rapport au protocole NTLM. En fait, le serveur de ressource cible n'est pas concerné par les informations d'authentification.

Lors d’une authentification Kerberos, les secrets d’authentification sont accessibles sur le poste client et les échanges AS (Authentication Service). Kerbéros les protège mieux que NTLM.

On sait maintenant que l’authentification et le choix du protocole jouent un rôle clé dans la protection du système d’information d’administration. Dans les environnements d’administration Active Directory, Microsoft recommande de renforcer cette sécurité d’authentification de la manière suivante :

• Côté NTLM : Interdire l’utilisation de NTLM.
• Côté Kerberos :
  • Interdire la délégation Kerberos
  • Dédier des Privileged Access Workstation (PAW) aux comptes d’administration.
  • Durcir la protection des échanges AS de Kerberos

Pour mettre en place ce renfort de sécurité d’authentification, Microsoft propose d'interagir sur les trois axes suivants : 

1. Le groupe de sécurité « Protected Users ». Il modifie la manière dont l’authentification se réalise en interdisant l’utilisation de NTLM et la délégation Kerberos. Tous les administrateurs qui sont affectés à ce groupe, bénéficient de ces restrictions.  
2. Le « silo d’authentification ». Son rôle permet de dédier le poste d’administration d’un tiers, aux comptes d’administration du même tiers. Cette affectation se fait au travers d’une stratégie d’authentification. De cette manière, un administrateur ne pourra se connecter aux ressources d’un tiers qu’avec les comptes d’administration et le poste d’administration associés à ce même tiers.
3. Les échanges « AS-REQ ». C'est le talon d’Achille de Kerberos. Et pour cette raison, Microsoft a renforcé l’authentification Kerberos avec le protocole FAST (Flexible Authentication via Secure Tunneling), et sécurisé la demande d’authentification en rajoutant les informations du compte d'ordinateur du poste de l'utilisateur. On parle alors de blindage Kerberos.

Le périmètre où les secrets d’authentification sont accessibles, est encore mieux protégé que celui de l’authentification Kerberos de base, car il impacte le poste client, mais les échanges AS sont plus sécurisés.

Dans les environnements Windows, lors des authentifications, les mots de passe sont stockés dans un format haché dans des ruches de registre. Les secrets pour les identiés de domaine, utilisées par la LSA (Autorité de Sécurité Locale), sont généralement stockés en mémoire cache sur le poste de l’utilisateur. Mais ces secrets peuvent en être facilement extrait, soit localement, à distance ou même hors ligne pour être utilisés dans le cadre de cyber-attaques. C’est principalement pour cette raison, qu'il est très fortement recommandé de mettre en place le Tier-Model, pour sécuriser Active Directory.

Quand un utilisateur s’authentifie sur l’annuaire Active Directory, il ouvre une session sur son poste de travail avec un couple « login/mot de passe ». Un hash du mot de passe est créé, stocké dans la mémoire du poste et envoyé avec l'identité de l'utilisateur à Active DIrectory. Un token (ou un ticket fonction du protocole utilisé), lié à une date d'expiration, est envoyé en retour. Si le hash de mot de passe n'était pas conservé en mémoire, l'utilisateur serait contraint à se réauthentifier dès l'expiration de la date. Malheureusement, cet emplacement en mémoire est vulnérable et convoité par les cyber-pirates qui savent qu'il contient le hash de mot de passe de l'utilisateur. S'ils réussissent à s'en emparer, comme il est identique à celui qui se trouvent dans Active Directory, ils pourront usurper l'identité de l'utilisateur.

Dans des contextes d'administration, les comptes Active Directory utilisés pour s'authentifier à des ressources possèdent des privilèges élévés. Si un poste d'accès est compromis lors d'une attaque, un cyber-pirate sera en capacité de récupérer le hash du mot de passe d’un compte d'administration, et pourra facilement se déplacer par rebond, de machines en machines (latéralement et verticalement), et s'emparer d'autres identités appartenant à des comptes qui disposent de privilèges plus élevés sur le domaine.

C'est là que la notion de PAW (Privileged Access Workstation), dans un Tier-Model, prend toute son importance.

Les comptes d’accès

Dans un modèle Active Directory « trois tiers », c'est ce facteur « vulnérabilité », lié à l'espace mémoire du poste, qui a conduit au choix d'affecter à chacun des tiers, des comptes d’administration dédiés. Un administrateur qui doit accéder aux ressources des trois tiers devra au minimum posséder trois comptes d’administration différents. Et comme les comptes d’administration sont exclusivement réservés aux actions d’administration, l’administrateur d’une organisation devra utiliser au moins quatre comptes s’il veut accéder à la fois à ses applications métier et aux ressources des trois tiers.

Postes physiques sécurisés et dédiés à l’administration (PAW) dans chacun des tiers

Les bonnes pratiques en termes de sécurité Active Directory, disent que pour administrer les ressources d’un tiers, l’administrateur doit se connecter avec un compte d’administration du tiers et à partir d’un poste qui se trouve dans ce même tiers. Or on sait que dans un modèle trois tiers, les postes de travail sont implémentés dans le tiers 2, ce qui pose un problème majeur si l’administrateur a besoin d’accéder aux ressources des tiers 0 et 1.

Pour lever cette restriction, on implémente des postes physiques sécurisés et dédiés à l’administration, appelés PAW (Privileged Access Workstation), dans chacun des tiers. Pour limiter leur exposition, ils ne doivent pas échanger avec des instances externes au tiers où ils sont implémentés. En tout cas, il faudra procéder à une gestion très fine des connexions réseaux entrantes ou sortantes si le besoin le justifiait.

L'ensemble de ces éléments mettent en évidence les bonnes pratiques à appliquer dans un contexte de silotage AD. Pour gérer la sécurité et la traçabilité des comptes à privilèges dans ce type d'environnement, il faut pouvoir y intégrer une solution PAM (Privileged Access Management) full compatible avec ce modèle « trois tiers » et qui respecte l’ensemble des prérequis de sécurité Microsoft (voir cet article, repris du blog cybersécurité des consultants Wavestone).

La solution doit pouvoir s'interfacer entre le poste de l’administrateur et le poste PAW, tout en sachant que le poste PAW ne doit pas échanger avec des instances externes au tiers où il est implémenté. Dans le cadre d'une politique d’accès via une solution PAM, qui nécessite une administration locale et distante (accès externes), il faut être en mesure de garantir que le poste PAW n’accède qu’à un seul point de terminaison et ne soit pas exposé à Internet.

L'architecture d'accès zero-trust (ZTNA), multisites, couplée à un Design fonctionnel nativement multi-tenants, est très certainement l'une des seules du marché à répondre à l'ensemble des exigences de sécurité imposées par le silotage AD. Certaines solutions PAM utilisent cette architecture, je pense à Systancia Cleanroom pour des implémentations On-premise ou à cyberelements.io pour des services en mode SaaS. Aucun compromis de sécurité n’est nécessaire pour l’accès à un poste PAW, une passerelle logicielle garantit son étanchéité et sécurise son chemin d’accès.

Consultez cet article si vous souhaitez en savoir plus sur les recommandations de l'ANSSI rapport à l’administration sécurisée des environnements Active Directory et sur le cloisonnement du SI en zones de confiance.