Modèle Active Directory N-TIERS - Présentation du modèle N-TIERS

Après avoir présenté le modèle 3-tiers et ses limites dans l’article Modèle Active Directory N-TIERS - États des lieux des infrastructures Active Directory, nous vous présentons aujourd’hui un autre modèle d’architecture Active Directory : le modèle n-tiers.

Le modèle N-TIERS, un modèle théorique ?

Dans notre précédent article, nous avons pu voir que le modèle 3-Tiers ne limite pas suffisamment l’impact de l’exploitation d’une vulnérabilité par un attaquant. En effet, ce dernier reste en mesure de se déplacer au sein du silo qu’il aurait compromis, pouvant ainsi grandement impacter le système d’information.

Pour palier cela, nous proposons un modèle de silotage avancé : le modèle n-Tiers. Ce modèle n’a pas vocation à remplacer le modèle 3-Tiers mais plutôt à venir s’ajouter à lui comme une couche supplémentaire de sécurité.

Le principe de ce modèle est d’appliquer un niveau de segmentation supplémentaire à chaque silo. Sur le plan technique, la définition des silos se fait via le mécanisme des stratégies d’authentification (Authentication Policies and Authentication Policy Silos). Cette fonctionnalité introduite dans l’Active Directory par Windows Server 2012 R2 permet de définir des conteneurs, les silos de stratégies d’authentification, dans lesquels nous pouvons affecter des comptes utilisateurs, de machines, ou de services. On peut ensuite appliquer des stratégies d’authentification à ces silos qui s’appliqueront alors à tous les comptes qu’ils contiennent. Ces stratégies permettent de restreindre les zones du domaine dans lesquelles les comptes en question peuvent s’authentifier.
Plus spécifiquement, les stratégies d’authentification permettent de contrôler, entre autres, les éléments suivants :

1. La durée de vie du TGT du compte (définie comme non renouvelable).
2. Les critères que les comptes de périphériques doivent respecter pour se connecter avec un mot de passe ou un certificat.
3. Les critères que les comptes utilisateurs et les périphériques doivent respecter pour s’authentifier auprès des services s’exécutant sous ce compte.

Ces stratégies sont appliquées lors de l’échange du TGS et TGT et nécessitent donc l’utilisation du protocole Kerberos pour l’authentification des comptes. Cela signifie également qu’elles ne peuvent s’appliquer qu’à des comptes de domaines, les comptes locaux ne sont pas affectés.

Lorsque les stratégies d’authentification sont implémentées, il est conseillé d’utiliser également le groupe de sécurité des « Utilisateurs protégés ». Ce groupe de sécurité est conçu pour protéger les comptes contre les vols d’informations d’identification. Il active une protection non configurable sur les appareils pour empêcher la mise en cache des identifiants de connexion lors de l’authentification des membres du groupe. De plus, l’appartenance à ce groupe force également l’authentification via Kerberos, l’authentification NTLM n’est alors plus possible.

Une fois ce mécanisme compris, il convient de définir la logique de silotage qui définira les critères d’appartenance de chaque compte à chaque silo. La politique de segmentation appliquée est grandement dépendante du contexte de l’entreprise et de son SI, on peut par exemple définir un silo par application, par environnement applicatif (prod, dev, test, QA, etc.), par niveau d’exposition extérieure (i.e. DMZ), par localisation géographique, par niveau de sécurité et sensibilité, etc.

Une bonne pratique consiste à maintenir une cohérence entre la stratégie de segmentation réseau et la stratégie de silotage de l’Active Directory. Il n’est pas pour autant question de chercher une correspondance exacte entre les deux, les différents niveaux de segmentation réseau ne pouvant pas être reproduits dans l’AD, mais plutôt de respecter la même logique entre les deux architectures.

Cette considération nous permet d’ailleurs de mettre en lumière la nécessité d’une instance de pilotage permettant de faire le lien entre les équipes réseaux et Active Directory. En effet, il est assez fréquent de retrouver des blocages organisationnels par manque de communication entre ces deux équipes. De telles problématiques constitueraient des obstacles majeurs à l’implémentation du modèle n-Tiers.

L’implémentation des Authentication Policies à elle seule ne peut pas suffire à mettre en place le modèle de silotage et à considérer l’Active Directory comme sécurisé. Il convient également d’appliquer les GPO adéquates à chaque silo. Dans un modèle n-Tiers, aucune GPO en dehors de celle par défaut ne devrait être appliquée au niveau du domaine. Les GPO doivent être configurées pour chaque silo de manière indépendante afin de respecter les besoins de sécurité de chaque zone.

Ainsi, en implémentant ces différentes fonctionnalités, nous pouvons nous assurer que l’accès de chaque compte est restreint uniquement à sa zone d’usage nominal. Par exemple, un développeur n’aura accès qu’aux éléments du système d’information qui concernent le développement, le service comptabilité ne pourra se connecter que dans la zone qui le concerne, etc. On réduit donc au maximum la porosité entre les différentes zones du SI en appliquant autant que possible le principe du moindre privilège. Cette logique a de fortes conséquences sur le niveau de sécurité du SI puisque cela implique que la compromission d’un compte ne viendra impacter que la zone restreinte (le silo) à laquelle il a accès, un attaquant ne pourra pas exploiter de droits résiduels affectés au compte. Les déplacements intra-Tier qui étaient encore possibles sous l’architecture 3-Tiers sont donc très largement réduits.

Dans notre article sur le modèle 3-Tiers, nous avions évoqué la nécessité de la connaissance et la compréhension des différents chemins d’attaques exploitables par un attaquant. Cette considération était déjà très complexe, mais elle le devient encore plus dans ce modèle n-Tiers. En effet, la maîtrise des flux au sein du SI doit atteindre un niveau de précision extrêmement fin puisqu’il permettra à la fois la définition du périmètre des silos et des interactions entre ces derniers.

Les limites opérationnelles du modèle

Cela étant dit, les limitations de ce modèle nous apparaissent assez rapidement. En effet, la restriction aussi stricte des droits d’accès des comptes correspond rarement au réel usage des utilisateurs : si l’on prend comme exemple un silotage par environnement applicatif, un compte utilisateur sera limité à l’environnement de production, de test, de QA, etc. Or en réalité un même développeur aura la nécessité d’avoir accès à plusieurs (voir tous) de ces environnements. Cette problématique devient encore plus évidente lorsqu’il s’agit des droits d’administration. Ainsi, dans cette logique, les utilisateurs voient leur nombre de comptes multiplié par autant de silos auxquels ils doivent avoir accès, ce qui, selon la stratégie de silotage, peut rapidement mener à plusieurs dizaines de comptes.

Considérant une telle contrainte, et sans solution pour l’alléger, il serait irréaliste d’attendre des utilisateurs que chacun de ces comptes possède un mot de passe fort et la MFA activée. Ainsi, une logique initialement pensée pour sécuriser le système d’information pourrait en fait venir le fragiliser. C’est à cause de cette complexité d’implémentation et d’usage que Microsoft ne mentionne pas ce modèle et qu’aujourd’hui aucune organisation n’a cherché à l’adopter.

Dans nos prochains articles nous verrons quelle réponse nous pouvons apporter à cette limitation afin de rendre le modèle n-Tiers implémentable. Nous aborderons également les aspects plus techniques de l’implémentation de ce modèle.