Aller au contenu
KDS Documentation
TAAF-OPS --:-- UTC

TP2 — Services & identité : l'AD, Nextcloud et la supervision

Conception d'architecture Ingénieurs · ESIROI Active Directory · Nextcloud · Alloy → Loki → Grafana · ~6 h

1. Contexte — la matrice rencontre la réalité

Section intitulée « 1. Contexte — la matrice rencontre la réalité »

Au TP1, vous avez écrit la matrice avant les services — des témoins nc en tenaient la place. Aujourd’hui, les vrais services arrivent, et le contrat s’inverse : chaque service doit rentrer dans la matrice, ou la faire amender en justifiant l’amendement. C’est la gestion de changement d’une vraie infrastructure : rien ne s’ouvre « parce que ça ne marche pas sinon ».

Et le service central du jour est celui qui met toutes les matrices à l’épreuve : l’annuaire. Un Active Directory ne parle pas qu’en LDAP — DNS, Kerberos, SMB… c’est le service qui fait exploser les matrices trop simples. Vous allez le monter vous-mêmes, et découvrir ligne à ligne ce qu’il exige.

2. Palier E6 — L’annuaire : un AD monté par vous

Section intitulée « 2. Palier E6 — L’annuaire : un AD monté par vous »

Créez la VM à la main dans VirtualBox — comme OPNsense, c’est une appliance qui s’installe, pas une box à télécharger :

ParamètreValeur
VMTAAF-AD-001 — 4 Go de RAM, 2 vCPU, ~40 Go de disque
Réseauune seule carte, pontée sur le port access du switch (VLAN de z-services, poste du Membre C), IP statique de votre plan (ex. 10.G.10.10)
OSWindows Server (ISO d’évaluation 180 jours) — édition Desktop Experience

Puis, dans l’ordre :

  1. IP statique + nom de machine (TAAF-AD-001) — avant toute promotion.
  2. Rôle AD DS + promotion en contrôleur de domaine d’une nouvelle forêt : le domaine est le vôtre, par exemple base-g<G>.taaf — distinct de celui du groupe voisin (au TP3, deux domaines identiques ne cohabitent pas).
  3. Le DNS s’installe avec la promotion : l’AD porte le DNS de son domaine.
  4. Créez 3 comptes : un utilisateur standard, un compte de service (pour Nextcloud — jamais un compte d’administration), un admin nommé. Désactivez ce qui ne sert pas.

Côté OPNsense, configurez le forward conditionnel d’Unbound : les requêtes de votre zone de domaine partent vers l’AD. Le DNS général du reste du SI ne change pas.

Preuve E6 : depuis z-front, la résolution DNS du domaine répond via la patte OPNsense ; un ldapsearch (ou Test-ComputerSecureChannel depuis une machine jointe) réussit sur 389 ; et un port AD non déclaré dans la matrice tombe en filtered.

3. Palier E7 — Les services : PostgreSQL et Nextcloud sur l’AD

Section intitulée « 3. Palier E7 — Les services : PostgreSQL et Nextcloud sur l’AD »

Étendez votre Vagrantfile : le provisioning de TAAF-DB-001 installe PostgreSQL (base nextcloud, compte dédié, écoute restreinte), celui de TAAF-WEB-001 installe Caddy + Nextcloud (conteneurs bienvenus — un docker compose versionné est du code parfaitement acceptable).

Puis le branchement qui donne son sens au TP :

  1. Nextcloud → PostgreSQL : l’application dans z-front, sa base dans z-services — le flux 5432 de votre matrice devient réel.
  2. Nextcloud → AD (LDAP) : activez l’application LDAP user and group backend, pointez sur TAAF-AD-001:389 avec le compte de service (jamais l’admin), mappez les utilisateurs. Un utilisateur du domaine se connecte à Nextcloud sans compte local.

Preuve E7 : un login Nextcloud avec un compte du domaine réussit ; le compte de service LDAP n’a que les droits de lecture nécessaires ; le balayage depuis z-front ne montre que les flux de la matrice.

4. Palier E8 — La supervision : construire la chaîne, pas l’opérer

Section intitulée « 4. Palier E8 — La supervision : construire la chaîne, pas l’opérer »

Vous ne faites pas de détection dans ce module — mais une architecture qui n’a pas prévu son observabilité ne pourra jamais l’accueillir. Vous construisez la chaîne :

  1. Sur TAAF-MON-001 (z-soc) : Loki (ingestion 3100) + Grafana (3000).
  2. Sur chaque machine Linux : un agent Alloy qui pousse les journaux système vers 10.G.50.10:3100. (Les journaux Windows de l’AD : bonus — exporter les événements de sécurité vaut des points, pas des excuses.)
  3. Sur OPNsense : les journaux du pare-feu — vos refus block log — partent aussi vers Loki.
  4. Dans Grafana (consulté depuis mgmt, jamais depuis les zones) : un tableau de bord minimal — les refus du pare-feu par zone source.

L’invariant du TP1 s’applique à la lettre : tout pousse vers le SOC, rien n’en sort. Si votre configuration a besoin d’un flux SOC → zone, c’est elle qui a tort.

Preuve E8 : une requête LogQL montre un refus que vous venez de provoquer (un balayage depuis z-front, par exemple) ; et depuis z-front, 3100 est open mais 3000 est filtered — Grafana ne se consulte pas depuis le SI.

5. Livrable

Section intitulée « 5. Livrable »

Dans le dépôt Git du groupe :

  1. La procédure AD — étapes de promotion, domaine, comptes créés et leur raison d’être (le mot de passe admin n’y figure jamais).
  2. Le Vagrantfile étendu — provisioning PostgreSQL, Caddy + Nextcloud, Alloy ; idempotent (deux runs, même résultat).
  3. La matrice amendée — chaque flux ajouté depuis le TP1 est daté et justifié ; les écarts assumés (LDAP en clair) documentés.
  4. Les preuves — login Nextcloud en compte du domaine, requête LogQL montrant un refus, balayage confirmant la matrice.
  5. L’export config.xml à jour, sans secrets.

6. Critères de réussite

Section intitulée « 6. Critères de réussite »
CritèreCe qu’on vérifie
L’AD est monté et raisonnéDomaine propre au groupe, DNS porté, 3 comptes typés, ports ouverts = ports justifiés.
Nextcloud vit dans l’architectureServi par Caddy en z-front, base en z-services, authentification par l’AD via le compte de service.
La matrice a survécu aux servicesLes amendements sont datés et justifiés ; rien d’ouvert « pour que ça marche ».
La chaîne de supervision tient l’invariantLes refus sont requêtables en LogQL ; rien ne sort de z-soc ; Grafana injoignable depuis les zones.
Le code est idempotentvagrant provision deux fois de suite : ni erreur ni changement au second passage.