Réaliser un Bastion de Tier 0 abordable – 1/5

Cet article est le premier d’un série de cinq qui présente la mise en place d’un bastion pour protéger le Tier 0, c’est à dire les serveurs les plus sensibles du système d’information, à coup raisonnable (moins de 5000 € d’investissement). Bien sûr, la solution n’est pas parfaite : mais elle offre une meilleure sécurité qu’un simple accès RDP depuis un poste bureautique !

Présentation

Royal TS, Royal Server et Yubikey

Bastion avec Royal TS et Royal Server

Mise en œuvre

Scénario d’utilisation

Télécharger les cinq articles en PDF !


Présentation

Objectif

La protection des identités à privilèges est aujourd’hui devenue une nécessité absolue pour toutes les entreprises. Malheureusement, les solutions du marché représentent un budget conséquent et une complexité certaine dans la mise en œuvre, freinant de nombreux services informatiques dans son déploiement. Ce document présente une solution abordable et simple à maitriser pour protéger les comptes à haut privilège de votre domaine Active Directory.

Cahier des charges

L’architecture proposée doit permettre de protéger les comptes du tier 0 contre le vol d’identité ; pour ce faire, le modèle devra s’affranchir de l’utilisation de mot de passe (pas de saisie au clavier) et utiliser une solution moderne d’authentification pour accéder aux ressources sensible (TOTP, SAML, …). La solution devra s’intégrer dans un modèle de silo d’identité et être en mesure de distribuer les droits via Active Directory.

Le modèle de silo d’identité

Présentation

Le modèle de Silo d’identité permet de limiter le mouvement d’un attaquant lorsqu’un compte est compromis. Il se base sur la ségrégation des ressources par Tier :

  • Le Tier 0 regroupe les éléments les plus sensibles du SI en charge de la gestion des identités. On y trouve tout naturellement les contrôleurs de domaine, les serveurs principaux de l’infrastructure de PKI, les serveurs méta-annuaire (azure AD Connect, Okta, …) et les hyperviseurs.
  • Le Tier 1 regroupe les serveurs hébergeant les applications ou les services nécessaires au fonctionnement du SI. Ces derniers sont challengés au regard du risque qu’ils représentent pour le Tier 0 : si un service requiert des droits élevés sur les objets du domaine, le serveur devra être considéré comme de Tier 0 – tous les autres seront de Tier 1 – on y trouve donc les services de base de données, les serveurs web, les serveurs applicatifs ou les serveurs de fichiers.
  • Le Tier 2 regroupe les équipements directement utilisé par l’utilisateur : poste de travail, imprimante, copieur, badgeuse, …

Le schéma ci-dessous illustre le principe de protection apportée par une combinaison des tiers et des silos d’identités dans le cas d’une attaque réussie :

Comptes et périmètres opérationnels

Pour le bon fonctionnement de chaque Tier, vous devrez définir des comptes d’administration dédiés à chacun d’eux – ces derniers ne doivent en aucun cas être utilisé sur un autre Tier : un compte de Tier 0 ne doit donc pas se connecter sur un serveur de Tier 1 ou un poste de Travail (dans l’illustration précédente, les deux tiers seraient compromis).

Pour simplifier l’explication, vous pouvez considérer que le Tier 0 regroupe les comptes administrateurs du domaine (ci-après désigné sous la terminologie de compte Gestionnaire) et les comptes de gestion des serveurs du Tier (ci-après désigné sous la terminologie de compte opérateur).

D’autre part, deux périmètres doivent être séparés : les comptes en charge de l’administration des systèmes, et donc les plus vulnérable au vol d’identité, ne peuvent pas être les comptes en charge de l’administration des objets de l’annuaire Active Directory. Ainsi, le modèle de Silo des identités doit être construit avec ce type d’approche :

Dans le cadre du bastion de Tier 0, nous aurons à prendre en compte les éléments factuels suivant :

  • Le compte d’origine, qui se présentera au bastion, sera un compte utilisateur classique (dans le cas où vous disposez d’un réseau d’administration, il s’agira de votre compte de login) ;
  • Les permissions du bastion devront être gérés par un administrateur des objets AD, ces derniers donnant l’accès au bastion par l’appartenance à des groupes ;
  • Le compte qui se connectera au système cible ne pourra pas être administrateur des objets AD ;
  • Seul le mot de passe du compte d’origine pourra être utilisé.

Les bases étant maintenant définies, nous regardons comment implémenter la solution de Tier 0 dans le prochain article.