État résiduel & points de vigilance¶

Registre consolidé de la dette technique et des risques résiduels connus sur l'ensemble de l'infrastructure Indio, à date de fin de projet. Compilé par recoupement entre l'état réel du code/de l'infra (vérifications en lecture seule quand c'est possible) et l'historique opérationnel des sessions d'exploitation — chaque entrée renvoie vers la page qui porte le détail complet et, si pertinent, une piste de remédiation.

Légende de sévérité : Critique (exploitable immédiatement, impact large, priorité absolue) · Majeur (gap fonctionnel ou de sécurité réel, à corriger) · Structurel (pas un incident en soi, mais une fragilité de méthode/process qui expose à un risque en cas d'événement déclencheur) · Mineur/connu (impact limité ou contournement déjà en place, accepté en connaissance de cause) · Résolu, pour mémoire (traité, conservé pour traçabilité).

Critique¶

Sujet	Constat	Référence
Bastion Guacamole	Identifiants par défaut guacadmin/guacadmin toujours actifs (vérifiés fonctionnels au dernier audit, 2026-07-12), donnant accès à 55 connexions préconfigurées dont les 2 DC AD (RDP), vCenter, NSX Manager, GitLab, Nexus et ce nœud de contrôle lui-même. Un seul compte Guacamole existe (pas de comptes nominatifs, aucune imputabilité individuelle malgré la bannière SSH). Remédiation identifiée (rotation du mot de passe ou comptes nominatifs) mais pas encore appliquée. Gaps secondaires du même audit, non corrigés : IP client réelle non tracée (remote_host toujours 127.0.0.1, pas d'audit trail fiable), aucun enregistrement de session, pas de MFA/TOTP, guacd/MariaDB à l'écoute sur 0.0.0.0 (protégés par firewalld seul, pas de bind localhost), certificat TLS auto-signé sans SAN, fail2ban inactif sur le login web.	Bastion Guacamole

Majeur¶

Sujet	Constat	Référence
Zabbix — comptes par défaut	Le compte Admin/zabbix par défaut (jamais changé depuis l'installation) fonctionne toujours sur l'API et le frontend — même famille de problème que le bastion Guacamole ci-dessus. Signalé à l'exploitant, non corrigé. Accessoirement, le 2ᵉ contrôleur de domaine AD (INDIDEN009) n'existe pas comme host Zabbix et n'est donc couvert par aucun SLA.	Zabbix
NSX Distributed IDS/IPS — DETECT seul	La policy IDPS-Global couvre les 3 zones (DMZ/SOC/Admin) mais en action = "DETECT" uniquement : aucun blocage actif, une période d'observation reste à mener avant un passage en prévention. Identity Firewall évalué (prérequis LDAPS/svc-nsx-bind déjà en place) mais pas implémenté. Malware Prevention/NSX Intelligence-NDR nécessitent NSX Application Platform (cluster Kubernetes dédié non provisionné) — hors de portée en l'état ; la licence Advanced Threat Prevention correspondante est présente mais à quantité 0.	NSX
Pipeline logs — pont Kafka → syslog-ng/Elastic manquant	Kafka (cluster réel en production, 5 topics) alimente aujourd'hui syslog-ng et Elasticsearch uniquement via l'ingestion directe rsyslog de la flotte — le pont Logstash prévu (input{kafka{...}} → output syslog + Elasticsearch) n'a jamais été construit. Côté Elasticsearch, le terrain est prêt depuis le 2026-07-17 (rôle logstash_writer, index template et ILM soc-logs créés via Terraform, règle DFW mgmt-to-soc-elasticsearch ouverte) — il ne manque que le pipeline Logstash lui-même et sa règle DFW SOC-interne.	syslog-ng · Vue d'ensemble SOC
MISP / TheHive / Cortex — SOC investigation non fonctionnel	Les 3 VM (INDSOC018/020/021) sont provisionnées (Terraform) mais fonctionnellement vides : après une session de débogage complète le 2026-07-14 (MISP rendu fonctionnel, TheHive/Cortex proches d'aboutir), l'exploitant a explicitement demandé de tout redétruire et de repartir en VM nues pour une installation manuelle qu'il compte mener lui-même. Le code Ansible applicatif (rôles, correctifs trouvés pendant le débogage) reste conservé et poussé sur GitLab pour référence, mais ne doit pas être réappliqué sans demande explicite.	MISP · TheHive · Cortex

Structurel¶

Sujet	Constat	Référence
Aucun backend Terraform distant	Vérifié par recherche exhaustive (backend "s3" absent de tous les .tf de /root) : aucun des projets Terraform de l'infra (une trentaine de dépôts, aws-s3 lui-même y compris) n'utilise de backend d'état distant — tous les terraform.tfstate restent locaux au nœud de contrôle. Risque concret en cas de travail multi-opérateur (aucun verrouillage d'état partagé) ou de perte du disque du nœud de contrôle (state irrécupérable au-delà des .tfstate.backup locaux). Un bucket S3 dédié à cet usage existe déjà et un modèle backend.tf.example est fourni, mais n'a été adopté par aucun projet à ce jour.	AWS · vCenter & hôtes ESXi
Projets sans aucune trace git	Deux projets de l'IaC Indio n'ont aucune trace git locale (pas de .git) et n'existent pas non plus sur GitLab (vérifié directement — indio/iac/haproxy et indio/iac/aws-s3-siem introuvables tous les deux) : haproxy (composant critique — VIP repo.infra.infra utilisée par toute la flotte pour joindre le dépôt interne) et aws-s3-siem (lab SIEM). Risque de perte totale du code source en cas de panne ou de perte du nœud de contrôle, aucune copie de sauvegarde ailleurs.	HAProxy · AWS

Mineur / connu¶

Sujet	Constat	Référence
AD hardening — volets gatés/incomplets	AppLocker (script 15) reste en mode audit seul, aucune application n'est réellement bloquée. L'exigence de logon par carte à puce pour T0-Admins (script 33) est volontairement gatée, jamais exécutée — les prérequis PKI sont désormais tous réunis (NTAuth résolu le 2026-07-17) mais l'activation reste soumise à une fenêtre de maintenance et un enrôlement préalable de certificat par personne. INDSERV015 a une relation d'approbation cassée avec le domaine depuis le rebuild AD du 2026-07-15 (non bloquant, machine jamais rejointe depuis). Accessoirement : l'administration à distance via WinRM depuis ce nœud de contrôle Linux reste non fonctionnelle vers les DC quel que soit le mode d'authentification testé (NTLM, Basic, Kerberos) — cause exacte non identifiée.	Durcissement AD
Kafka — collecte JMX incomplète	Le port RMI secondaire du JMX Kafka est choisi aléatoirement à chaque démarrage (pas de valeur figée côté broker) : le template Zabbix « Apache Kafka by JMX » ne peut donc pas collecter la totalité de ses items (item en read timeout permanent). Le monitoring de base (agent Zabbix classique, port 10050) fonctionne normalement. Décision explicite de l'exploitant (2026-07-17) : non traité, jugé non critique — ne pas relancer l'investigation sans demande.	Kafka
vSAN File Service — écriture continue instable	L'écriture continue directe vers le partage NFS du vSAN File Service (file-node01, utilisé comme copie froide externe des logs syslog-ng déjà compressés) s'est révélée instable lors des tests du 2026-07-17 : blocages en état noyau D sous NFSv4.1 (injoignable même par SIGKILL), échecs silencieux sans erreur sous NFSv3 — cause racine jamais identifiée. Contournement en place et validé de bout en bout (écriture en local sur disque dédié 2 To + rsync périodique des seuls fichiers déjà compressés/clos, jamais de flux actif) mais des micro-coupures NFS récurrentes (plusieurs fois par heure, visibles en dmesg) persistent sur ce partage.	vSAN File Service · syslog-ng
Kubernetes — 2 nœuds injoignables	INDSERV020/INDSERV021 (2 des nœuds du cluster Kubernetes) sont injoignables réseau (100 % de perte de paquets, VM allumées côté vCenter). Découvert incidemment le 2026-07-17 lors d'une campagne d'enrôlement FreeIPA fleet-wide (ce sont les 2 seuls échecs sur toute la flotte testée) — jamais diagnostiqué depuis, non enrôlés IPA en conséquence.	Kubernetes
FreeIPA — trust AD non redondant	Le trust AD (établi et vérifié le 2026-07-17) ne dispose d'aucune haute disponibilité : ipa-adtrust-install n'a jamais été exécuté sur le réplica (INDIDEN005) — les services SMB/winbind du trust en sont absents, seul le primaire (INDIDEN004) répond aux requêtes AD/SMB liées au trust. Par ailleurs, la seule règle HBAC créée couvre le service SSH ; aucune règle sudo ou autre service n'existe.	FreeIPA & trust AD
NetBox — noms de VM obsolètes latents dans le seed	seed/populate.py a été nettoyé des entrées correspondant aux VM décommissionnées avant le 2026-07-07, mais l'état des noms pour le reste de la flotte encore active n'a jamais été audité entrée par entrée (dernier constat, 2026-07-07 : « à vérifier au cas par cas avant tout rejeu complet »). Rejouer le fichier en entier sans cette vérification préalable recrée des VM fantômes en double dans NetBox (déjà arrivé une fois, 31 VM fantômes créées puis nettoyées).	NetBox
Grafana — panels incomplets sur le nœud Zabbix standby	Sur le dashboard Grafana Zabbix, 3 des 7 panels restent vides pour le nœud Zabbix standby (INDSUPV002) : NVPS, processus Zabbix occupés, file d'attente. Le template applicatif fournissant ces items de self-monitoring n'a été attaché qu'au nœud actif lors du montage du cluster HA, jamais répliqué sur le standby. Correction possible (attacher le bon template côté Zabbix) mais non faite — signalée, hors scope au moment du constat.	Grafana

Résolu, pour mémoire¶

Sujet	Constat	Référence
Fuite du mot de passe admin NetBox	Le mot de passe admin par défaut (valeur en dur dans seed/populate.py) a circulé en clair dans l'historique GitLab public du projet depuis son tout premier commit. Résolu le 2026-07-17 : rotation réelle du mot de passe (appliquée côté application, pas seulement la variable d'environnement) + purge complète de l'historique git (git filter-repo, vérifiée sur clone frais, 0 occurrence résiduelle). Résiduel mineur non traité : la branche main du dépôt netbox est probablement restée dé-protégée avec l'option « Allowed to force push » activée côté GitLab (nécessaire pour pousser la purge) — à re-vérifier/re-protéger.	NetBox
Clés privées TLS committées par erreur	Un agent a committé par erreur des clés privées TLS lors d'un déploiement ELK. Depuis cet incident, une règle stricte s'applique à l'ensemble du projet IaC Indio, cette documentation comprise : vérification systématique de l'absence de secret après tout commit, pas seulement après une intervention d'agent ou une manipulation de certificats.	Gestion des secrets