Présentation
Construire le cœur de l'infrastructure
Une fois la plateforme de virtualisation en place, HIVE dispose enfin de l'endroit où héberger ses services.
Mais il manque encore quelque chose d'essentiel :
une identité.
Utilisateurs, ordinateurs, serveurs, groupes, politiques de sécurité… tous ces éléments doivent pouvoir être centralisés et organisés.
C'est le rôle d'Active Directory.
Dans HIVE, Active Directory ne doit donc pas être considéré comme un simple annuaire d'utilisateurs. Il devient une des fondations sur lesquelles vont reposer les prochains services de l'infrastructure.
Authentification, gestion des accès, politiques de sécurité, intégrations avec la PKI ou encore SSO : de nombreuses briques vont dépendre de cette première base d'identité.
Construire une base propre dès le départ
Plutôt que de créer un domaine minimal avec quelques utilisateurs et de revenir dessus plus tard, j'ai préféré prendre le temps de réfléchir à son organisation dès le début.
L'objectif était simple :
ne pas devoir réorganiser Active Directory à chaque fois qu'un nouveau service arrive dans HIVE.
Le domaine est donc structuré autour de plusieurs catégories d'objets :
utilisateurs ;
comptes administrateurs ;
groupes ;
comptes de service ;
serveurs ;
postes de travail ;
ressources.
Cette organisation permet de distinguer clairement les différents types d'identités et de ressources présents dans le système d'information.
Organiser les OU avant que le domaine ne grossisse
Une partie importante du travail a donc consisté à construire une arborescence d'OU cohérente.
L'organisation retenue sépare notamment :
_ADMINS_GROUPES_UTILISATEURS_SERVEURS
Chaque branche possède ensuite ses propres sous-catégories.
Par exemple, les comptes administrateurs sont séparés des utilisateurs classiques, tandis que les serveurs sont organisés entre contrôleurs de domaine, infrastructure et applications.
Cette séparation n'est pas uniquement esthétique.
Elle doit permettre par la suite d'appliquer plus facilement des politiques, des droits et des stratégies GPO aux bons objets.
Une convention de nommage pour éviter le chaos
Un autre choix important concerne la convention de nommage.
Plus une infrastructure grandit, plus les noms deviennent importants.
Un serveur mal nommé, un compte administrateur difficile à identifier ou un groupe dont la fonction n'est pas évidente peuvent rapidement compliquer l'administration.
HIVE adopte donc une convention homogène selon le type d'objet.
Par exemple :
Utilisateur
prenom.nom
Compte administrateur
adm.prenom.nom
Compte de service
svc.service
Serveur
SRV-SITE-ROLE-identifiant
Groupe de sécurité
SG.service.role
L'objectif est d'obtenir des noms lisibles, prévisibles et facilement exploitables par les administrateurs comme par les scripts.
Type | Format | Exemple |
|---|---|---|
Utilisateur | prenom.nom | liam.salamagnon |
Administrateur | adm.prenom.nom | adm.liam.salamagnon |
Compte de service | svc.service | svc.active-directory |
Serveur | srv-site-role-identifiant | srv-rouen-ad-01 |
Groupe de sécurité | SG.service.role | SG.active-directory.create-user |
Séparer les niveaux de confiance
La construction d'Active Directory a également permis de définir une partie importante de l'architecture globale de HIVE :
les zones de confiance.
L'idée est de ne pas considérer tous les services de l'infrastructure comme équivalents.
HIVE est organisé autour de trois niveaux.
Zone 0 — Fondations
La zone la plus critique.
Elle contient les éléments qui constituent la racine de confiance de l'infrastructure, notamment :
Active Directory ;
Root CA ;
DNS intégré à l'AD ;
services fondamentaux.
Zone 1 — Services de confiance
Cette zone regroupe les services qui s'appuient sur les fondations :
step-ca ;
Authentik ;
Teleport ;
services d'administration.
Zone 2 — Exploitation
On y retrouve les services utilisés au quotidien :
Zabbix ;
Grafana ;
Loki ;
Wazuh ;
Gitea ;
GLPI ;
applications internes.
Cette séparation permet de mieux visualiser les dépendances et de réfléchir aux flux entre les différentes briques avant même qu'elles soient toutes déployées.
Pourquoi faire tout cela maintenant ?
Parce qu'il est beaucoup plus simple de définir une architecture lorsque l'infrastructure est encore petite.
Aujourd'hui, HIVE ne compte encore qu'une poignée de services.
Demain, il y aura des applications, des bases de données, de la supervision, de l'observabilité, de la sécurité, de l'authentification et probablement encore beaucoup d'autres composants.
L'objectif est donc de construire les règles avant que la complexité n'arrive.
Active Directory fournit désormais une base structurée pour les utilisateurs, les machines, les groupes et les politiques.
Et surtout, l'architecture des zones de confiance donne un cadre dans lequel les prochains services pourront venir s'intégrer.
Le cœur est en place
À l'issue de cette étape, HIVE dispose de son domaine Active Directory et d'une organisation pensée pour accompagner la croissance de l'infrastructure.
Les objets sont structurés, les conventions sont définies et les différentes zones de confiance commencent à donner une véritable architecture au projet.
La prochaine étape va justement s'appuyer sur cette nouvelle fondation.
Il faut maintenant permettre à HIVE de faire confiance à ses propres services.
La prochaine brique sera donc la PKI interne, avec une Root CA et une autorité intermédiaire basée sur Smallstep step-ca.