Ce projet assemble tout le tronc commun en une infrastructure que vous construisez de bout en bout, puis que vous vérifiez commande par commande. Il n'est lié à aucun fournisseur : le même plan se réalise sur Scaleway, AWS, OUTSCALE ou un autre, et une bonne partie se rejoue en local sans compte. Il s'adresse à qui a parcouru les blocs réseau, compute, données et sécurité, et veut savoir ce qu'il en a réellement retenu.
Ce que vous allez construire
Section intitulée « Ce que vous allez construire »Une application web à trois étages, joignable depuis Internet, dont les données ne le sont pas.
| Étage | Contenu | Joignable depuis |
|---|---|---|
| Exposé | un répartiteur de charge, terminaison TLS | Internet, ports 80 et 443 |
| Applicatif | deux machines identiques servant l'application | le répartiteur uniquement |
| Données | une base managée, sauvegardée | l'étage applicatif uniquement |
Quatre exigences transverses complètent l'ensemble, et ce sont elles qui distinguent un exercice d'école d'une infrastructure défendable : tout est décrit par du code, rien ne sort d'un secret en clair, la restauration a été essayée, et l'environnement se détruit entièrement à la fin, sans laisser de ressource facturée derrière lui.
Deux façons de le faire, et ce que chacune prouve
Section intitulée « Deux façons de le faire, et ce que chacune prouve »Vous pouvez mener ce projet sans compte cloud, à condition de savoir ce que cela ne démontre pas. Cette distinction est le cœur de la méthode enseignée ici : un test réussi ne vaut que par ce qu'il mesure.
| Sur l'émulateur, sans compte | Sur un compte réel | |
|---|---|---|
| Plan d'adressage et segmentation | oui | oui |
| Création des ressources et dépendances | oui | oui |
| Cycle Terraform complet, second plan vide | oui | oui |
| Règles de filtrage écrites | oui, écrites | oui, et appliquées |
| Trafic réel qui traverse le répartiteur | non | oui |
| Stockage objet | non émulé | oui |
| Permissions réellement refusées | non, jamais vérifiées | oui |
| Sauvegarde et restauration | non | oui |
| Facture et budget | non | oui |
Faites les deux, dans cet ordre. L'émulateur vous permet de rater le plan d'adressage cinq fois sans conséquence, ce qui est exactement le moment où l'on apprend. Le compte réel valide ensuite ce que seul le trafic peut valider, sur un périmètre réduit et pour quelques euros.
Le plan d'adressage
Section intitulée « Le plan d'adressage »Commencez par écrire ce tableau avant de créer quoi que ce soit. La plage du réseau ne se modifie plus après création chez la plupart des fournisseurs, et c'est la seule décision de ce projet qui soit vraiment irréversible.
| Rôle | Zone A | Zone B | Route par défaut |
|---|---|---|---|
| Exposé | 10.50.1.0/24 | 10.50.2.0/24 | passerelle Internet |
| Applicatif | 10.50.11.0/24 | 10.50.12.0/24 | passerelle NAT |
| Données | 10.50.21.0/24 | 10.50.22.0/24 | aucune |
Réseau : 10.50.0.0/16. Les dizaines séparent les rôles, ce qui rend une
adresse lisible d'un coup d'œil : 10.50.22.7 est une base en zone B.
La dernière colonne porte l'essentiel de la sécurité de ce projet. L'étage de données n'a aucune route vers l'extérieur, donc une donnée volée ne part pas facilement, et cela ne coûte rien : il suffit de ne pas ajouter la route.
Les lots de travail
Section intitulée « Les lots de travail »-
Le réseau
Réseau privé en
/16, six sous-réseaux, deux tables de routage, une passerelle Internet, une passerelle NAT. Rien d'autre.Révision : tables de routage et passerelles.
-
Le filtrage
Trois groupes de sécurité, un par étage. Chacun n'autorise que l'étage précédent, en référençant le groupe plutôt qu'une plage d'adresses. L'accès d'administration ne vient jamais de
0.0.0.0/0.Révision : sécurité réseau.
-
Les machines
Deux instances applicatives, dans deux zones différentes, préparées par cloud-init et sans aucun secret dans leurs données de configuration. Prenez la taille en dessous de votre intuition.
Révision : choisir et dimensionner une machine.
-
Le répartiteur et le nom
Répartiteur de niveau 7, terminaison TLS, sonde de santé sur une adresse applicative et non sur le port. Un nom de domaine pointe vers lui, avec un TTL court le temps du projet.
Révision : répartition de charge et TLS et DNS managé.
-
La base de données
Base managée dans l'étage de données, chiffrée, avec sauvegardes activées et une fenêtre de restauration que vous aurez vérifiée.
Révision : données managées.
-
Les identités et les secrets
Une identité attachée aux machines, portant le droit minimal. Le mot de passe de la base vit dans un gestionnaire de secrets, jamais dans le code ni dans cloud-init.
Révision : gérer les identités et les accès.
-
La gouvernance
Toutes les ressources étiquetées
environnement,equipeetprojet. Un budget mensuel avec alerte à 50 %, 80 % et 100 %.Révision : gouvernance et coûts.
-
L'observabilité
Les journaux du répartiteur et des machines envoyés au service de journalisation, avec une rétention explicite et non celle par défaut. Une seule alerte, mais une vraie : le taux d'erreurs HTTP 5xx au-delà d'un seuil, routée vers une adresse que vous relevez.
Révision : exploiter un environnement cloud.
Huit lots, dans cet ordre. Chacun s'appuie sur le précédent : le filtrage n'a pas de sens sans le découpage réseau, et l'alerte n'a rien à observer avant que le service ne réponde. Livrez-les un par un, en vérifiant le lot avant de passer au suivant, plutôt que de tout construire puis de tout déboguer ensemble.
Les critères de validation
Section intitulée « Les critères de validation »Chaque ligne se vérifie par une commande ou une manipulation, pas par une impression. C'est la partie qui compte : une infrastructure qui « a l'air de marcher » n'a rien prouvé.
| Ce qui doit être vrai | Comment le vérifier |
|---|---|
| Le site répond en HTTPS | curl -I https://votre-nom renvoie 200 et un certificat valide |
| Le second plan est vide | terraform plan après apply n'annonce aucun changement |
| Les machines applicatives ne sont pas joignables | une connexion directe vers leur adresse échoue par expiration |
| La base n'est pas joignable depuis Internet | idem, depuis une machine extérieure |
| Les machines sortent bien vers Internet | une mise à jour de paquets réussit depuis une machine applicative |
| Une machine arrêtée ne casse pas le service | éteignez-en une, le site répond toujours |
| La sonde retire bien un serveur défaillant | arrêtez le service applicatif sur une machine, elle sort de la rotation |
| Aucun secret n'est en clair | relisez cloud-init et le dépôt : aucun mot de passe |
| La restauration fonctionne | restaurez la base dans une instance de test, chronomètre en main |
| Le budget alerte | descendez temporairement le seuil, vérifiez que l'alerte arrive |
| Tout est étiqueté | listez les ressources sans étiquette : la liste doit être vide |
| L'administration n'est ouverte à personne | aucun groupe de sécurité n'autorise le port 22 ou 3389 depuis 0.0.0.0/0 |
| Le filtrage référence des groupes | relisez les règles : aucune plage d'adresses privées codée en dur entre étages |
| Le certificat est correct | openssl s_client -connect votre-nom:443 -servername votre-nom renvoie une chaîne complète et valide |
| Les journaux arrivent | provoquez une erreur 500, retrouvez-la dans le service de journalisation |
| L'alerte part vraiment | abaissez le seuil d'erreurs, provoquez-en, vérifiez la réception |
| La rétention est choisie | aucun flux de journaux ne conserve « indéfiniment » par défaut |
La revue d'architecture
Section intitulée « La revue d'architecture »Une fois l'ensemble debout, relisez-le sur six axes. L'exercice prend une heure et vaut plus que la construction elle-même, car il transforme un montage en décisions assumées.
| Axe | La question à se poser |
|---|---|
| Sécurité | Que peut atteindre un attaquant qui compromet une machine applicative ? |
| Fiabilité | Qu'est-ce qui tombe si une zone entière disparaît ? |
| Performance | Quelle ressource sature en premier, et l'ai-je mesurée ? |
| Coût | Quelle serait la facture mensuelle, et quel poste domine ? |
| Excellence opérationnelle | Puis-je tout recréer depuis zéro avec le code, sans mémoire humaine ? |
| Souveraineté | Sous quelle juridiction sont mes données, et à quel coût puis-je partir ? |
Répondez par écrit. Trois lignes par axe suffisent, et une réponse embarrassée signale toujours un vrai trou. La question sur le coût mérite un chiffre, même approximatif : une architecture dont personne ne sait estimer la facture est une architecture que personne n'arbitrera.
Refaire le même projet ailleurs
Section intitulée « Refaire le même projet ailleurs »Le meilleur usage de ce capstone est de le rejouer sur un second fournisseur. Le plan d'adressage ne change pas, les groupes de sécurité non plus, et vous mesurez alors ce qui est réellement transférable.
Ce qui se transpose sans réfléchir : le découpage, les plages, la logique des trois étages, la sonde de santé, l'étiquetage.
Ce qui demande une traduction : les noms des services, la façon de rendre un sous-réseau public, et surtout le modèle de permissions, qui diffère réellement d'un cloud à l'autre comme l'explique la page IAM.
Ce qui change vraiment la facture : le trafic sortant et la passerelle NAT, dont le traitement varie du tout au tout selon le fournisseur.
Détruire l'environnement, et vérifier qu'il ne reste rien
Section intitulée « Détruire l'environnement, et vérifier qu'il ne reste rien »Le dernier lot du projet est sa destruction, et c'est un exercice à part entière. Une commande de destruction qui se termine sans erreur ne prouve pas que le compte est vide : elle prouve que l'outil a supprimé ce qu'il connaissait. Tout ce qui a été créé à côté, ou recréé automatiquement par un service, lui échappe.
-
Sauvegardez d'abord ce que vous voulez garder. Le code d'infrastructure, vos réponses écrites à la revue d'architecture, et une capture de la facture du mois. Le reste est jetable, c'est le principe.
-
Lancez la destruction depuis votre outil, puis relisez son compte rendu ligne à ligne. Une ressource « conservée » y apparaît explicitement, et c'est souvent le seul endroit où vous la verrez.
Fenêtre de terminal terraform destroy -
Chassez les restes, qui se logent toujours aux mêmes endroits. Le tableau ci-dessous liste ceux qui survivent le plus souvent, et qui continuent à être facturés en silence.
-
Revenez sur la facture 48 heures plus tard. C'est le seul contrôle qui fait autorité : la console de facturation voit ce que votre inventaire a oublié, et un poste résiduel y apparaît immanquablement.
| Ce qui survit à la destruction | Pourquoi | Ce que ça coûte |
|---|---|---|
| Les instantanés de disques et de bases | souvent créés hors du code, ou générés à la suppression de la base | facturés au gigaoctet, sans limite de durée |
| Les disques détachés | la suppression d'une machine ne supprime pas toujours son volume | plein tarif du stockage bloc |
| Les adresses IP publiques réservées | une adresse réservée non attachée est facturée plus cher qu'attachée | quelques euros par mois et par adresse |
| Les seaux de stockage objet non vides | un seau avec du versionnage refuse d'être supprimé tant que les anciennes versions existent | stockage plus requêtes |
| Les groupes de journaux | leur rétention par défaut est parfois illimitée | stockage qui ne décroît jamais |
| Les clés de chiffrement | leur suppression est différée d'un délai de sécurité, et elles restent facturées pendant ce délai | quelques euros par clé et par mois |
| Les secrets | même logique de suppression différée | facturés au secret et par mois |
| Les enregistrements DNS et la zone | rarement gérés par le même code que l'infrastructure | coût de la zone hébergée |
Prenez l'habitude de détruire, y compris quand vous comptez recommencer demain. Une infrastructure décrite en code se reconstruit en quelques minutes, et cette reconstruction est justement le contrôle qui prouve que votre code est complet. Un environnement qu'on n'ose plus détruire est un environnement dont personne n'est certain qu'il se recrée : c'est exactement la situation que ce projet cherche à vous faire éviter.
À retenir
Section intitulée « À retenir »- La destruction fait partie du projet. Une commande de destruction sans erreur ne prouve pas que le compte est vide, seule la facture à 48 heures fait autorité.
- Instantanés, disques détachés, adresses réservées et groupes de journaux sont les restes les plus fréquents, et ils se facturent en silence.
- Écrivez le plan d'adressage avant de créer quoi que ce soit : c'est la seule décision irréversible du projet.
- L'étage de données n'a aucune route sortante. Gratuit, et c'est la mesure qui gêne le plus un attaquant.
- Référencez les groupes de sécurité entre eux plutôt que des plages : la règle décrit un rôle et survit aux changements d'adressage.
- Aucun secret dans cloud-init, qui est lisible depuis la machine et depuis la console.
- Un second plan vide est le vrai test de votre code d'infrastructure.
- Éteignez une machine pour de bon. C'est le seul test qui prouve la redondance.
- Chronométrez la restauration : c'est votre RTO réel, et il diffère toujours du RTO annoncé.
- Rejouez le projet sur un second fournisseur pour mesurer ce qui est vraiment transférable.