Chapitre 29. L'architecture cible d'Astrea : assemblage et grille d'analyse

Objectifs pédagogiques¶

Présenter l'architecture cible complète et la défendre décision par décision. Écrire une matrice de flux exhaustive et l'utiliser comme contrat de recette. Appliquer la grille à six colonnes sur une architecture réelle. Exécuter l'étape 5 et la recetter. Installer les rituels qui empêchent l'architecture de mentir avec le temps.

Prérequis¶

Chapitres 27 et 28, et en réalité tout le cursus : ce chapitre est l'assemblage.

Cours¶

29.1 Le plan d'ensemble¶

L'architecture cible tient sur un écran. C'était un critère du chapitre 14 pour les montages, c'en est un pour l'ensemble.

  zone administration & gardien (10.10.10.0/24)
  +--------------------+  +--------------------+  +--------------------+
  | admin-01 (.21)     |  | vault-transit-01   |  | monitor-01 (.31)   |
  | postes d'admin.    |  | (.11) Shamir 3/2   |  | journaux, metriques|
  +--------------------+  | cle autounseal-core|  | (recoit, n'initie  |
                          +--------------------+  |  rien)             |
                                                  +--------------------+
  zone Vault (10.10.20.0/24)
  +---------------------------------------------------------------+
  | lb-vault-01 (.10) = vault.astrea.lab:8200 -- TCP passthrough   |
  |        |                                                       |
  |   vault-core-01 (.11)   vault-core-02 (.12)   vault-core-03(.13)
  |   [cluster raft -- 8201 entre noeuds seulement]                |
  +---------------------------------------------------------------+

  zone applicative (10.10.30.0/24)              zone future (10.10.40.0/24)
  +--------------------+  +------------------+  +--------------------+
  | app-billing-01(.21)|  | db-pg-01 (.31)   |  | k8s-astrea         |
  +--------------------+  +------------------+  | (partie XIII)      |
                                                +--------------------+

Et la matrice de flux, le contrat, chaque ligne au format du chapitre 27.

Source	Destination	Port	Besoin	Justification
consommateurs	lb-vault-01	8200	l'API	tout le cursus
lb-vault-01	les trois nœuds	8200	trafic aveugle et sondes vérifiées	ch. 28
les nœuds	entre eux	8201	Raft	ch. 24
les trois nœuds	transit-01	8200	descellement	ch. 23
admin-01	nœuds, transit-01, lb	22 et 8200	administration nominative	ch. 19, 30
tous	monitor-01	journaux et métriques	sens unique sortant	ch. 30
l'actif	db-pg-01	5432	moteur Database	ch. 19

Sept lignes, groupées par besoin plutôt qu'éclatées par destination : c'est la forme qui se relit en revue et se compare aux règles de pare-feu. Tout le reste est refusé par défaut, et la recette de l'étape 5 inclut la vérification de quelques refus choisis, parce qu'une matrice ne se prouve pas seulement par ses oui.

29.2 Les décisions qui tiennent l'édifice¶

Chaque décision avec son chapitre, parce que c'est ainsi que le dossier se défend en revue. Le descellement délégué à un gardien souverain avec quorum humain à froid (23). Trois nœuds impairs sur des hôtes distincts (24). Le nettoyage automatique borné au quorum nominal (25). L'entrée en aveugle, la frontière de confidentialité sur les nœuds (28). Un token de gardien par machine, révocable seul (26). La PKI à deux niveaux servant tout le parc, wildcard interdit par construction (17, 28). Les certificats d'infrastructure en exception documentée, bornée par le chapitre 40 (28). Les secrets applicatifs dynamiques partout où la grille du chapitre 18 le permet (19). L'audit en double flux, décidé ici et mis en œuvre au chapitre 30, la ligne de flux correspondante figurant déjà dans la matrice.

L'architecture n'a pas d'opinions, elle a des références.

29.3 Colonnes un et deux : actifs et menaces¶

Les actifs, du plus précieux au plus discret. Le stockage chiffré, en quatre exemplaires avec les sauvegardes. La clé d'enveloppe sur le gardien, dont l'accès en déchiffrement, combiné à un stockage, ouvre tout. Les parts du gardien et les recovery keys du core, deux quorums, deux registres, deux jeux de coffres. Les tokens de seal dans les configurations. La clé de la racine PKI, identité de tout le parc. Les journaux d'audit, précieux deux fois, pour ce qu'ils prouvent et pour ce qu'ils révéleraient. Les schémas et matrices eux-mêmes. Et les sauvegardes, dont la partie XI fera un chapitre entier.

Les menaces, par acteur. L'externe en position réseau, depuis la zone applicative compromise, qui est le pivot le plus probable. L'interne applicatif, une application détournée qui use de ses droits légitimes, que les policies bornent. L'interne administrateur, détenteur de l'accès distant, de l'hyperviseur ou du DNS, que la séparation des domaines borne. L'accès physique aux disques et aux baies, que la barrière et la destruction attestée bornent. Et la chaîne d'approvisionnement, binaires, images et dépendances.

29.4 Colonnes trois et quatre : frontières et surface¶

Les frontières de confiance, numérotées sur le schéma pour que la conversation soit possible. Le chapitre 5 en avait tracé trois, celles du produit : client-serveur, serveur-stockage, et la mémoire du processus qui n'en est pas une. Celles qui suivent sont d'un autre ordre : ce sont les frontières de cette installation, une décomposition topologique du même principe, pas une définition concurrente. Une architecture différente en compterait quatre ou sept ; les trois du chapitre 5, elles, valent pour tout déploiement de Vault.

F1, l'entrée, là où l'inconnu devient client. F2, l'intérieur de la zone Vault, franchissable par les seuls flux de la matrice. F3, la zone gardien et administration, le sanctuaire dont les franchissements entrants se comptent sur une main. F4, la sortie vers les cibles, la frontière qu'on oublie, celle où Vault est client. F5, la frontière humaine et hyperviseur, celle qui ne se dessine pas au pare-feu : qui administre quoi, quels domaines de virtualisation, la paire fatale du chapitre 23.

La surface d'attaque, côté par côté. Depuis la zone applicative, un seul point, l'entrée, TLS vérifié et authentification exigée derrière. Depuis la zone Vault, le port de cluster entre nœuds et les ports de service pour le répartiteur et l'administration. Depuis le sanctuaire, tout, et c'est pourquoi il est le sanctuaire. Depuis l'extérieur du réseau d'entreprise, rien : Vault n'est pas exposé à l'Internet, et cette phrase si simple est un contrôle de première classe. S'y ajoute la surface non réseau : consoles d'hyperviseurs, sauvegardes, coffres physiques des parts. La grille les compte, parce que les attaquants les comptent.

29.5 Colonne cinq : les contrôles, mappés¶

Chaque contrôle en face de sa menace, avec son chapitre. La lecture par familles.

Préventifs : la barrière et le seal contre le vol de stockage ; TLS de bout en bout et vérification systématique contre l'interposition ; policies au refus par défaut et moindre privilège contre l'abus de droits ; secrets dynamiques et durées courtes contre la valeur du vol ; quorums de machines et d'humains contre la décision unilatérale ; pare-feu au refus par défaut contre le pivot.

Détectifs : l'audit intègre et externalisé, la supervision des motifs de santé et des élections, l'alerte de capacité à redémarrer, la corrélation entre le gardien et les redémarrages.

Correctifs : la révocation fine par accessor, par domaine et par machine ; les bascules ; les sauvegardes et la reprise, chantier ouvert que la grille a le droit de pointer mais pas d'ignorer.

29.6 Colonne six : les risques résiduels, signés¶

La colonne qui fait la valeur du dossier. Chaque ligne porte le risque, l'acceptation et le critère de révision.

R1 : le répartiteur est seul. Sa panne coupe l'entrée le temps d'une reconstruction ou d'un contournement, toute porte du cluster restant valide. Accepté par la direction technique, daté. Critère de révision : plus d'une panne d'entrée par an, ou une exigence d'indisponibilité sous cinq minutes. Alors VRRP, dont le principe est acquis (section 28.6) et dont le mode opératoire reste à rédiger.

R2 : le gardien est le point unique de la capacité à redémarrer. Un core en marche l'ignore ; un redémarrage pendant sa panne attend. Accepté, mitigé par sa sobriété, sa supervision dédiée et sa sauvegarde propre. Critère : si les redémarrages deviennent fréquents ou l'exigence de reprise se durcit.

R3 : le site est unique. Le sinistre de salle emporte tout le dessin. La réponse est la partie XI, avec un objectif de reprise en heures, accepté à ce niveau et chiffré au chapitre 34.

R4 : les administrateurs d'hyperviseur voient la mémoire. Le chapitre 5 l'a dit. Mitigé par la liste courte, les domaines séparés et la journalisation des consoles. Accepté : c'est le risque que seul un module matériel réduirait encore.

R5 : la racine PKI vit dans Vault. Choix documenté du chapitre 17, borné par un montage dédié aux policies quasi nulles. Critère : croissance ou exigence de conformité, auquel cas la racine hors ligne passe à l'ordre du jour.

Cinq lignes honnêtes, et la phrase du chapitre 27 en exergue : une analyse qui n'avoue rien n'analyse rien.

29.7 L'étape 5, exécutée¶

[Laboratoire]. Il ne reste qu'un geste, préparé pour être minuscule : l'enregistrement DNS du nom de service passe du premier nœud au répartiteur.

Tout le reste était prêt. Les clients pointent le nom depuis le chapitre 7, les certificats le portent en SAN depuis le chapitre 28, les URL de la PKI l'ont toujours inscrit.

La recette, dans l'heure du changement. Depuis l'hôte applicatif : login, lecture KV, émission dynamique et chiffrement Transit, soit quatre succès via l'entrée. Depuis monitor-01 : le motif de santé des nœuds inchangé, 200 sur l'actif et 429 sur les deux standbys, et les journaux du répartiteur qui montrent le trafic. Les refus attendus de la matrice : le port d'un nœud tenté depuis la zone applicative, bloqué ; le gardien tenté depuis l'hôte applicatif, bloqué. Et le test de bascule du chapitre 26 rejoué à travers l'entrée : neuf secondes d'élection, deux secondes de convergence de sonde, billing aveugle à l'événement.

L'étape 5 tient dans une ligne de registre, et c'est le compliment que se fait une architecture : le dernier geste était le plus petit.

Exemple : la revue devant la direction¶

Trente minutes, trois documents : le schéma, la matrice, la grille. La directrice technique pose ses trois questions rituelles.

Que se passe-t-il quand une machine meurt ? Réponse chiffrée : un nœud, neuf secondes de bascule mesurées, zéro impact client ; le répartiteur, minutes de reconstruction avec contournement documenté ; le gardien, aucun effet sur le vivant, redémarrages gelés.

Que faut-il voler pour lire nos secrets ? Réponse en paires : un stockage et l'accès au gardien de son époque, séparés par zones, machines et administrations. Aucune personne, aucune machine, aucun lieu ne réunit une paire.

Qu'est-ce qui vous inquiète encore ? La sixième colonne, lue à voix haute : cinq lignes, cinq critères de révision. C'est cette réponse qui a emporté la confiance, dit le registre : une équipe qui montre ses risques résiduels est une équipe qu'on peut croire sur ses contrôles.

Décision de sortie : l'architecture cible est adoptée, et la partie X est commanditée dans la foulée. La direction veut voir la grille attaquée.

Sécurité : que l'architecture ne mente jamais¶

La dérive est l'ennemi numéro un. L'architecture du dossier et celle du réseau divergent dès la première exception temporaire. Le rituel trimestriel compare le réel au contrat, et toute divergence est soit corrigée, soit promue dans le dossier : une exception assumée est une ligne de plus, pas une honte. La grille suit le même régime, chaque changement notable la faisant repasser par les six colonnes en version courte, faute de quoi elle décrit dans deux ans un système qui n'existe plus.

Les refus se testent comme les succès. Une matrice prouvée par ses seuls flux autorisés n'est prouvée qu'à moitié. C'est la grille de refus du chapitre 11, montée à l'échelle du réseau.

Le dossier se gouverne. Schéma, matrice, grille et registre racontent ensemble où frapper et ce qui saigne encore : accès restreint, diffusion tracée, et une version de présentation distincte de la version de travail.

Erreurs fréquentes¶

Une architecture jamais recettée contre sa matrice. Le dessin dit sept flux, le pare-feu en laisse treize, et le dossier rassure à tort (section 29.1).

Des risques résiduels sans propriétaire ni critère. L'acceptation n'engage personne et ne se rediscutera jamais. Chaque ligne porte qui, quand, et ce qui la rouvre (section 29.6).

Oublier les frontières non réseau. Hyperviseurs, consoles, coffres, DNS : la grille qui ne compte que les ports laisse à l'attaquant ses meilleurs chemins (section 29.4).

Confier tout le TLS à un DNS non gouverné. Qui écrit cette zone tient l'aiguillage : le DNS interne entre dans le périmètre d'administration durci (sections 29.4, 29.7).

Traiter la supervision en spectateur inoffensif. Elle reçoit les journaux, donc les rythmes, les identités et les traces de tout : le tier d'observation est dans la grille comme actif et comme surface (section 29.3).

Faire de la revue direction un exercice de communication. Une grille propre sans sixième colonne sincère achète trente minutes de confort et perd la confiance au premier incident (Exemple).

Mise en pratique : la grille au travail¶

Sur papier ; réponses commentées en fin de partie.

Deux actifs manquent volontairement à l'inventaire de 29.3 : trouvez-les et écrivez leur ligne complète. Indice : l'un se renouvelle tous les mois, l'autre dort dans des coffres.
Écrivez la matrice de flux de la zone future telle qu'elle devra s'insérer : lignes nouvelles, lignes modifiées, refus à tester.
Rédigez, en dix lignes, la réponse à un auditeur qui conteste R1 sans que vous déployiez VRRP : l'argumentaire du risque résiduel bien tenu.

Questions de compréhension¶

Combien de lignes compte la matrice de flux, et pourquoi la recette doit-elle tester des refus ?
Citez six des décisions qui tiennent l'édifice, avec leur chapitre.
Donnez quatre actifs non évidents de l'inventaire et ce qui fait leur valeur.
Décrivez les deux frontières qu'on oublie, et le contrôle principal de chacune.
Pourquoi l'absence d'exposition à l'Internet est-elle un contrôle de première classe ?
Restituez trois des cinq risques résiduels avec leur mitigation et leur critère de révision.
Qu'est-ce qui a rendu l'étape 5 minuscule, et quels chapitres avaient préparé cette petitesse ?
En quoi la sixième colonne a-t-elle emporté la confiance à la revue de direction ?
Décrivez le rituel trimestriel anti-dérive : ce qu'on compare, ce qu'on fait des divergences.

Synthèse¶

L'architecture cible tient sur un écran et dans sept lignes de flux : tout le reste est refusé, et les refus se testent. Ses décisions ont des références, pas des opinions. Ses actifs sont inventoriés jusqu'aux coffres et aux schémas. Ses frontières comptent l'humain et l'hyperviseur autant que les ports. Ses contrôles se lisent par familles, chacun renvoyant au chapitre qui l'a construit. Et ses cinq risques résiduels sont signés, datés, munis de leur critère de révision : la colonne qui fait qu'on peut la croire. L'étape 5 fut un changement DNS, le dernier geste le plus petit parce que tout ce qui précède l'avait préparé. Déclenche le TP 12 (énoncé en partie XV).