Contexte : Problématique TAAF

Mission

La Direction des Systèmes d’Information (DSI) des Terres Australes et Antarctiques Françaises (TAAF) doit superviser et sécuriser son infrastructure informatique répartie sur les bases polaires.

Cette infrastructure isolée et critique pose plusieurs enjeux. Elle exige une solution de monitoring et de sécurité robuste.

---

Le terrain : un SI éclaté sur un quart de la planète

Avant de parler d’outils, il faut comprendre où on travaille. Les TAAF administrent des districts dispersés de l’océan Indien austral jusqu’au continent antarctique. La Réunion en est la tête de pont : c’est de là que partent les navires, les liaisons et l’administration du SI.

flowchart LR
  REU(["🇷🇪 La Réunion<br/><i>siège · services centraux</i>"])
  CRO["Alfred Faure<br/><small>Crozet</small>"]
  KER["Port-aux-Français<br/><small>Kerguelen</small>"]
  AMS["Martin-de-Viviès<br/><small>Amsterdam</small>"]
  DDU["Dumont d'Urville<br/><small>Terre Adélie</small>"]
  CCD["Concordia<br/><small>Dôme C · intérieur</small>"]

  REU ---|liaison satellite| CRO
  REU ---|liaison satellite| KER
  REU ---|liaison satellite| AMS
  REU ---|liaison satellite| DDU
  DDU ---|liaison interne| CCD

  classDef hub fill:#1d4ed8,stroke:#1e3a8a,color:#fff
  classDef base fill:#dcfce7,stroke:#15803d,color:#14532d
  classDef deep fill:#e0f2fe,stroke:#0369a1,color:#0c4a6e
  class REU hub
  class CRO,KER,AMS,DDU base
  class CCD deep

District	Base	Distance depuis La Réunion	Accès physique	Effectif d’hivernage
Crozet	Alfred-Faure	2 810 km	Marion Dufresne	18
Saint-Paul & Amsterdam	Martin-de-Viviès	2 820 km	Marion Dufresne	29
Kerguelen	Port-aux-Français	3 380 km	Marion Dufresne	45
Terre Adélie	Dumont-d’Urville	7 600 km	L’Astrolabe, depuis Hobart (2 700 km)	25
Terre Adélie — intérieur	Concordia (Dôme C)	plus de 1 000 km à l’intérieur, depuis DDU	Convoi terrestre, été austral	Équipe très réduite

Environ 140 personnes en hivernage sur l’ensemble des districts. C’est l’effectif total que ce SI dessert — équipes techniques comprises.

Le chiffre qui change tout : la fenêtre de réparation

Le ravitaillement des districts subantarctiques repose sur 4 rotations par an du Marion Dufresne au départ de La Réunion — environ 30 jours de mer par rotation, Crozet puis Kerguelen puis Amsterdam.

Pour la Terre Adélie, c’est pire : L’Astrolabe fait 4 à 5 rotations depuis Hobart, uniquement entre novembre et février. La banquise rend Dumont-d’Urville inaccessible d’avril à septembre. Concordia n’est atteinte qu’ensuite, par convoi terrestre.

4

rotations de ravitaillement par an

Marion Dufresne, depuis La Réunion

30 j

de mer par rotation

Crozet, puis Kerguelen, puis Amsterdam

6 mois

sans accès à la Terre Adélie

banquise, d'avril à septembre

0

renfort technique entre deux rotations

ce qui casse sur place reste cassé

Sources : TAAF — ravitaillement des territoires · TAAF — le Marion Dufresne · Institut polaire — la station Dumont d’Urville · Wikipédia — Terres australes et antarctiques françaises

---

Les 4 Enjeux Critiques

1. Surveillance et Visibilité du Système d’Information

Problématiques identifiées :

• Aucun monitoring temps réel des métriques système et applicatives
• Visibilité insuffisante sur l’état de santé de l’infrastructure distribuée
• Aucune détection proactive des anomalies de performance ou de disponibilité
• Incidents difficiles à anticiper sur des sites distants et peu accessibles

Impact : Les équipes IT découvrent les problèmes une fois qu’ils touchent les utilisateurs. La maintenance reste réactive au lieu d’être proactive.

---

2. Centralisation et Corrélation des Événements

Problématiques identifiées :

• Logs dispersés sur plusieurs machines et environnements
• Aucun puits centralisé pour collecter les événements du SI
• Corrélation impossible des événements de sécurité entre systèmes
• Schémas d’attaques et incidents coordonnés difficiles à repérer

Impact : L’analyse post-incident devient longue et complexe. Les attaques multi-vecteurs passent sous le radar.

---

3. Sécurité et Détection des Menaces

Problématiques identifiées :

• Aucune détection temps réel des intrusions ou activités suspectes
• Surveillance insuffisante des conteneurs et services critiques
• Aucune alerte automatisée en cas d’accès non autorisé
• Opérations sensibles non tracées (ex : suppression massive de fichiers dans NextCloud)

Impact : Une menace peut rôder pendant des jours, voire des semaines. Elle compromet l’intégrité des données et la disponibilité des services.

---

4. Conformité, Traçabilité et Audit

Problématiques identifiées :

• Conserver les traces d’accès et d’opérations système
• Disposer d’un historique centralisé pour les audits de sécurité
• Démontrer la conformité aux normes de sécurité
• Répondre vite aux incidents, preuves documentées à l’appui

Impact :

Non-conformité réglementaire, audits impossibles à satisfaire, exposition légale en cas d’incident.

---

Votre Mission

Quatre enjeux, une même cible : un SI visible, sécurisé, traçable et conforme.

• La visibilité — monitoring temps réel de l’infrastructure
• La sécurité — détection et prévention des menaces
• La traçabilité — centralisation et conservation des événements
• La conformité — respect des normes et préparation des audits

Selon votre parcours, vous n’attaquez pas cette cible par le même bout. Ingénieurs, vous concevez et montez l’architecture qui la rend atteignable, avant de la superviser. BUT, vous partez d’un SI déjà en place et vous l’amenez à ce niveau, puis vous prouvez qu’il y est. Voir Deux rôles sur la même base plus bas.

---

Architecture Cible

Pour répondre à ces enjeux, vous déployez et configurez :

Stack Monitoring

• Prometheus : collecte de métriques système et applicatives
• Grafana : visualisation et dashboards
• Loki : agrégation et analyse de logs
• Alertmanager : alerting multi-canaux
• Zabbix : supervision SNMP des équipements réseau et OT (stations Concordia & DDU)
• Télémétrie satellite : ingestion de la télémétrie des stations sol (AegisSat)
• Sources temps réel externes : lien Starlink, électricité de La Réunion

Stack SIEM — SOC Grafana-natif

• Détection-as-code : règles Sigma → LogQL (mêmes Loki/Grafana que l’Acte 1)
• Falco (IDS runtime) + Suricata / Zeek (réseau) → Loki
• Alerting : Grafana Alerting → Discord · couverture MITRE ATT&CK
• SSO Active Directory ↔ NextCloud : identité fédérée (prérequis détection)
• Bonus : Wazuh (SIEM clé-en-main), intégration journaux Windows/AD, threat hunting assisté par IA (LLM local + MCP)

---

Contexte Opérationnel : Les Bases Polaires TAAF

Services critiques

• PostgreSQL : bases de données RH, météo, communications
• NextCloud : partage de fichiers et collaboration
• Active Directory : authentification et gestion d’identité

Les 4 contraintes qui commandent l’architecture

01

Éloignement

Aucune intervention physique rapide. La réparation attend le prochain navire.
Conséquence : tout doit être administrable et réparable à distance — ou redondé sur place.

02

Réseau restreint

Liaison satellite : débit faible, latence élevée, quota.
Conséquence : on n'envoie pas tout à la métropole. Il faut agréger, échantillonner, compresser — et décider ce qui mérite de passer.

03

Conditions extrêmes

De +20 °C aux îles subantarctiques en été à ~-80 °C à Concordia. Cyclones, coupures électriques, liaison interrompue plusieurs jours.
Conséquence : le site doit fonctionner sans la métropole, puis se resynchroniser.

04

Équipes réduites

Un personnel technique minimal, souvent polyvalent et non spécialiste.
Conséquence : une solution que seul son auteur sait exploiter est une solution qui tombera.

---

Deux rôles sur la même base

Le même SI TAAF est abordé par deux publics qui n’y jouent pas le même rôle — et qui n’y interviennent pas au même moment.

Sur une base australe, celui qui construit et celui qui exploite ne sont jamais la même personne. L’un travaille pendant la campagne d’été, quand le navire est là et qu’on peut encore faire venir du matériel. L’autre reste, avec ce qu’on lui a laissé. C’est exactement la répartition de ce module.

Ingénieurs

Bâtir la base

Rien ne vous est livré. Vous étudiez les contraintes, proposez une architecture et la défendez, puis vous la montez — segmentation, pare-feu, interconnexion.
Parcours : étude d'architecture (TP0), puis construction — le déroulé des séances est donné en cours.

BUT

Tenir la base

Vous montez votre socle — trois machines, sans plan de segmentation — puis vous exploitez un SI dont vous n'avez pas choisi l'architecture, comme tout exploitant. Vous le rendez visible, puis vigilant, puis vous prouvez qu'il tient.
Parcours : Actes 0, 1, 2 et 3.

Aucun des deux n’est la version facile de l’autre

Celui qui bâtit répond de ce qu’il laisse : dans six mois, plus personne sur place ne saura pourquoi telle règle de pare-feu existe — s’il ne l’a pas écrite quelque part, elle sera supprimée par le premier qui la trouvera gênante. Puis il repart sur le bateau.

Celui qui tient la base répond de ce qu’il hérite, et il ne repart pas. Il décide seul, sans pouvoir appeler celui qui a conçu l’architecture, sur un SI qu’il n’a pas choisi, pendant les mois où aucun renfort ne peut arriver. C’est le rôle qui porte le plus d’enjeu — et c’est lui qui a le dernier mot, à l’Acte 3.

Deux responsabilités différentes. Pas deux niveaux. (Et la séparation est celle de ce module, pas celle d’une carrière : dans la vraie vie on passe d’un rôle à l’autre.)

---

Le fil rouge : un incident unique

Un seul incident traverse toute la formation. Ce n’est pas une suite de TP indépendants : c’est la même intrusion, reprise sous un angle différent à chaque étape — un hameçonnage qui aboutit à un compte compromis, une progression dans le SI, puis une exfiltration par la liaison satellite.

C’est ce fil rouge qui relie les deux publics. Les ingénieurs construisent l’architecture complète dans laquelle il se produira ; les BUT l’affrontent sur un socle plus resserré, dont ils n’ont pas dessiné la segmentation. Ni les uns ni les autres ne le découvrent au même moment, et c’est le même incident.

La progression : trois verbes

flowchart LR
  subgraph CONC["🏗️ Conception — ingénieurs"]
    direction TB
    TP0["<b>TP0</b> · Étude d'architecture"]:::ing
    TP1["<b>TP1</b> · Segmentation & pare-feu"]:::ing
    TP2["<b>TP2</b> · Accès distant IPsec"]:::ing
    TP3["<b>TP3</b> · Reproductibilité"]:::ing
    TP0 --> TP1 --> TP2 --> TP3
  end

  subgraph TRONC["🤝 Tronc commun — les deux publics"]
    direction TB
    A0["<b>Acte 0</b> · Déployer"]:::run
    A1["<b>Acte 1</b> · Voir"]:::run
    A2["<b>Acte 2</b> · Détecter"]:::run
    A0 --> A1 --> A2
  end

  subgraph AUDIT["🔎 Épreuve — ceux qui tiennent la base"]
    direction TB
    A3["<b>Acte 3</b> · Prouver<br/>Conformité & durcissement"]:::aud
    A3B["Audit AD · Purple Team<br/>LotL · Downgrade PQC"]:::aud
    A3C["Rapport d'audit<br/><i>le dernier mot sur l'archi</i>"]:::aud
    A3 --> A3B --> A3C
  end

  ING(["Ingénieurs<br/><i>entrent ici</i>"]):::entry --> TP0
  BUT(["BUT<br/><i>entrent ici</i>"]):::entry --> A0
  TP3 --> A0
  A2 --> A3

  classDef ing fill:#ede9fe,stroke:#6d28d9,color:#3b0764
  classDef run fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
  classDef aud fill:#fef3c7,stroke:#b45309,color:#78350f
  classDef entry fill:transparent,stroke-dasharray:4 3,stroke:#64748b,color:#475569

Chaque public a son extrémité propre ; le tronc commun est au centre. Les actes d’exploitation tiennent en trois verbes :

Voir → Détecter → Prouver

Chacun s’appuie sur le précédent : pas de détection sans visibilité, pas de preuve sans détection.

Où s’arrête chaque parcours — et pourquoi ce n’est pas le même acte

Les ingénieurs s’arrêtent à l’Acte 2. Leur conclusion n’est pas un TP de plus : c’est le moment où l’incident se déclenche dans l’architecture qu’ils ont livrée. La question qui clôt leur parcours est celle-là — ta segmentation a-t-elle ralenti l’attaquant ? ton default-deny a-t-il tenu ?

Pour ceux qui tiennent la base, l’Acte 2 ne juge personne : il sert à établir ce qui s’est réellement passé sur une infrastructure qu’ils n’ont pas dessinée — et dont ils répondent quand même. C’est la position réelle de l’exploitant, et c’est la plus exigeante des deux : le concepteur peut expliquer ses intentions, l’exploitant n’a que les traces.

Eux seuls poursuivent jusqu’à l’Acte 3, où ils attaquent délibérément le SI pour vérifier que la détection tient. Ils vont plus loin dans l’histoire : le dernier mot sur cette architecture n’appartient pas à celui qui l’a conçue.

Acte 1 — “Mise en lumière” (Monitoring)

Port-aux-Français, base perdue dans l’océan Indien. Un service tombe — et personne ne le sait avant qu’un chercheur ne trouve porte close. La DSI des TAAF pilote à l’aveugle.

Votre première mission : lui rendre la vue. Métriques système, dashboards opérationnels, logs centralisés, alertes automatiques. À la fin de l’acte, vous voyez tout ce qui se passe sur l’infrastructure.

Acte 2 — “Sentinelle” (SIEM)

La DSI voit, désormais. Mais voir ne suffit pas : des connexions anormales rôdent autour des liaisons satellite. Constater un incident, c’est déjà trop tard — il faut le détecter avant.

Vous transformez la supervision en sentinelle. Détection-as-code (Sigma→LogQL) sur la même stack Grafana/Loki, IDS runtime (Falco) et réseau (Suricata/Zeek), alerting Grafana→Discord. L’infrastructure passe de passive à vigilante. (Wazuh en TP bonus.)

C’est ici que le parcours ingénieur se referme : l’attaquant se déplace dans les zones que vous avez découpées au TP1, franchit — ou non — les règles que vous avez écrites. Les encarts [FULL] de cet acte vous renvoient à votre propre conception.

Acte 3 — “Épreuve du feu” (Audit & Purple Team) (BUT)

L’ANSSI alerte : des groupes APT ciblent la recherche polaire française. Le RSSI ne veut plus de promesses, il veut des preuves. Vos défenses tiennent-elles vraiment ?

Le seul moyen de le savoir : les attaquer. Audit de conformité, scan de vulnérabilités, simulation d’attaques Purple Team, rapport d’audit assisté par IA. L’Acte 3 valide les Actes 1 et 2 : si votre monitoring et votre SIEM sont bien configurés, vos propres attaques apparaissent dans vos dashboards.

---

Prêt à Commencer ?

Ingénieurs, votre point de départ est la Conception. BUT, c’est l’Acte 0.

• Conception d’architecture — Étudier, proposer, construire l’infrastructure (ingénieurs — point de départ)
• Acte 0 — Mise en place — Déployer les VMs, les services et le scénario (BUT — point de départ)
• Monitoring — Surveillance et observabilité (Acte 1 — tronc commun)
• SIEM — Sécurité et détection des menaces (Acte 2 — tronc commun)
• Audit & Purple Team — Tests d’intrusion et rapport d’audit (Acte 3 — BUT)