Auditer la sécurité

Contrôler secrets, Git, ports, images et processus.

Dans ce chapitre : 3 étapes et 16 preuves de validation.

Étape 101 — Séparer configuration et secrets

Objectif. Tu sauras où chaque valeur doit vivre et pourquoi.

État du projet avant cette étape. L’application fonctionne ; l’audit commence par les informations sensibles qui ne doivent jamais entrer dans Git.

Comprendre le changement

srcs/.env contient la configuration non secrète comme le domaine et les noms. Les fichiers secrets contiennent les mots de passe. Compose injecte le chemin d’un secret dans une variable se terminant par _FILE.

Faire une seule chose

Relis .env, docker-compose.yml et secrets. Classe chaque valeur : publique, sensible ou générée à l’exécution.

Fichiers ou emplacements concernés

srcs/.env
srcs/docker-compose.yml
secrets/

Prouver que c’est correct

Preuves de validation 0 / 5

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

.env ne contient aucun mot de passe.Les Dockerfiles ne contiennent aucun credential.Les services reçoivent des chemins de secrets et non les valeurs en clair.Les fichiers secrets ont des permissions restrictives.Toutes les valeurs de démonstration ont été remplacées localement.

Question de soutenance — Un fichier .env est-il automatiquement secret ?

Non. C’est un fichier texte ; aucune valeur confidentielle ne doit y être placée ici.

Étape 102 — Auditer ce que Git pourrait rendre

Objectif. Tu vérifieras l’index Git, pas seulement les fichiers visibles.

État du projet avant cette étape. Les secrets sont séparés, mais un ancien ajout Git peut encore les avoir placés dans l’index ou l’historique.

Comprendre le changement

.gitignore empêche les nouveaux ajouts ; il ne retire pas automatiquement un fichier déjà suivi. git ls-files montre ce qui ferait partie du rendu.

Faire une seule chose

Vérifie les règles d’ignorance, la liste des fichiers suivis et recherche des motifs sensibles dans les fichiers rendus.

Fichiers ou emplacements concernés

.gitignore

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository

chmod 700 secrets
chmod 600 secrets/*.txt
find secrets -maxdepth 1 -type f -exec stat -c '%a %n' {} \;

Ce que fait chaque partie

chmod 700 : seul le propriétaire traverse/liste le dossier.
chmod 600 : seul le propriétaire lit/écrit les fichiers.
stat : affiche seulement modes et noms, pas les valeurs.

Résultat attendu

Chaque fichier secret affiche 600 et le dossier 700.

Si cela échoue

Sur macOS stat utilise une autre syntaxe ; ce contrôle cible la VM Linux demandée.

Prouver que c’est correct

Preuves de validation 0 / 5

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

git check-ignore confirme que le dossier secrets est ignoré.srcs/.env peut être suivi seulement s’il ne contient aucune valeur confidentielle.git ls-files ne liste aucun fichier secret réel.La recherche ne trouve aucun mot de passe dans les fichiers suivis.Les exemples documentaires utilisent uniquement des valeurs fictives clairement signalées.

Question de soutenance — Un fichier .env est-il automatiquement secret ?

Non. C’est un fichier texte ; aucune valeur confidentielle ne doit y être placée ici.

Étape 103 — Auditer toutes les interdictions techniques

Objectif. Tu élimineras les raccourcis qui invalident l’architecture.

État du projet avant cette étape. Les credentials ont été contrôlés. Il reste à examiner les images, le réseau, les processus et les ports.

Comprendre le changement

L’audit cherche des signatures précises : latest, image de service prête, network_mode host, links, boucle infinie, processus factice, mot de passe dans une recette ou port interne publié.

Faire une seule chose

Exécute les recherches, puis explique chaque résultat. Une recherche vide est attendue pour les motifs interdits.

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository

git status --short
git ls-files secrets
git grep -nEi '(password|passwd|secret|api[_-]?key|BEGIN .*PRIVATE KEY)'
git log -p --all -- . ':(exclude)en.subject*'

Ce que fait chaque partie

git ls-files secrets : doit rester vide pour les secrets réels.
git grep : trouve les mots sensibles dans la version suivie.
git log -p --all : permet d’auditer aussi les anciens commits.
La recherche sert de signal, pas de verdict automatique.

Résultat attendu

Aucune valeur réelle ni clé privée n’est trouvée ; seules des références de variables ou explications peuvent apparaître.

Si cela échoue

Si un secret réel a été commité, révoquez-le immédiatement. Nettoyer l’historique est une opération distincte à coordonner avant push.

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository

grep -Rni '^FROM' srcs/requirements
grep -Rni 'latest' srcs || true
docker compose -f srcs/docker-compose.yml images

Ce que fait chaque partie

grep ^FROM : liste toutes les bases.
grep latest : cherche le tag explicitement interdit.
compose images : associe services et images construites.

Résultat attendu

Trois FROM identiques ou cohérents vers Alpine/Debian autorisé ; aucune occurrence latest ; noms d’images mariadb, wordpress, nginx.

Si cela échoue

Une occurrence dans une explication/commentaire doit être revue, mais une vraie référence doit être supprimée.

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository

grep -RniE 'network_mode:[[:space:]]*host|network:[[:space:]]*host|links:|--link|80:80|3306:3306|9000:9000' srcs || true
docker compose --env-file srcs/.env -f srcs/docker-compose.yml config
docker compose -f srcs/docker-compose.yml ps

Ce que fait chaque partie

grep : cherche les formes interdites et ports externes suspects.
|| true : garde le contrôle suivant même si grep ne trouve rien.
config/ps : montrent déclaration résolue et exposition effective.

Résultat attendu

Aucun motif interdit ; un réseau explicite sur les trois services ; uniquement 443:443 sur NGINX.

Si cela échoue

Si config affiche un port inattendu issu d’un override Compose, identifiez tous les fichiers chargés et retirez l’override.

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository · containers démarrés

grep -RniE 'tail[[:space:]]+-f|sleep[[:space:]]+infinity|while[[:space:]]+true|entrypoint.*bash|CMD.*bash' srcs/requirements || true
for service in mariadb wordpress nginx; do docker inspect "$(docker compose -f srcs/docker-compose.yml ps -q "$service")" --format '{{.Name}} -> {{.Path}} {{join .Args " "}}'; done

Ce que fait chaque partie

grep : cherche les hacks explicitement cités.
for : parcourt exactement les trois containers, puis se termine.
docker inspect : montre le processus de lancement réel.

Résultat attendu

Aucun motif interdit ; MariaDB, PHP-FPM et NGINX sont les processus finaux de leurs entrypoints.

Si cela échoue

Un script peut légitimement utiliser une boucle bornée for. L’interdiction vise les boucles infinies qui maintiennent le container.

Prouver que c’est correct

Preuves de validation 0 / 6

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

Aucun FROM ni image n’utilise latest.Aucune image prête NGINX, WordPress ou MariaDB n’est utilisée.Aucun network_mode: host, links: ou --link n’existe.Aucun tail -f, sleep infinity, while true ou shell nu ne maintient un container.Seul 443 est publié.Les trois PID 1 sont les vrais services attendus.

Question de soutenance — Un fichier .env est-il automatiquement secret ?

Non. C’est un fichier texte ; aucune valeur confidentielle ne doit y être placée ici.