Défense en profondeur — Sécurité
Vue d'ensemble
La sécurité est multicouche, présuppose que toute couche unique peut échouer et accorde le moins de privilège possible. Les attaquants trouvent la couche que vous avez oubliée — un système qui repose sur un seul mur s'effondre quand ce mur présente un bogue ; des contrôles superposés à moindre privilège survivent à la défaillance d'un seul d'entre eux.
Les principes (universels)
- Modélisez les menaces avant de construire quoi que ce soit qui manipule des entrées non fiables, des secrets ou des données utilisateur. Réalisez une analyse légère STRIDE (Usurpation, Falsification, Récusation, Divulgation d'informations, Déni de service, Élévation de privilèges) par nouvelle surface. Enregistrez le modèle et les mesures d'atténuation (voir
recording-decisions). - Défense en profondeur. Aucun contrôle unique n'est « la » sécurité. L'authentification, l'autorisation, la validation des entrées et l'application au niveau des données supposent chacun que les autres pourraient être contournés.
- Moindre privilège partout — rôles, jetons, comptes de service, autorisations de base de données. Par défaut, pas d'accès ; accordez le minimum ; révoquez l'inutilisé.
- Les secrets ne vivent jamais dans le code, les images ou la configuration versionnée. Ils proviennent d'un coffre à secrets à l'exécution, sont renouvelés et sont limités à la charge de travail qui en a besoin.
- Validez toutes les entrées à la frontière de confiance ; traitez toute sortie d'un système externe comme des données non fiables, jamais comme des instructions.
- La chaîne d'approvisionnement des dépendances est une surface d'attaque. Les fichiers de verrouillage sont versionnés et vérifiés pour leur intégrité ; les dépendances sont analysées et mises à jour ; les images de base sont épinglées et analysées.
- Les actions sensibles sont auditées — qui a fait quoi, quand — afin que les abus et les erreurs puissent être reconstitués.
Référence rapide
| Surface | Premières questions |
|---|---|
| Nouveau point d'accès acceptant une entrée utilisateur | Quel est le modèle STRIDE ? Où est la validation ? Quel est le rôle le plus restreint qui fonctionne ? |
| Tout ce qui implique un secret | Est-il dans le coffre à secrets (pas dans le code/image) ? Limité ? Renouvelable ? |
| Nouvelle dépendance | Fichier de verrouillage épinglé ? Analysée ? Est-elle bien maintenue ? |
| Mutation privilégiée | Est-elle audité ? L'acteur est-il autorisé au niveau des données, pas seulement au niveau de l'application ? |
Mécanismes de la pile
RLS comme couche de forçage finale, limite de profondeur/coût GraphQL comme contrôle anti-déni de service, Key Vault pour les secrets, pnpm audit/Trivy dans le CI — voir postgres-postgraphile-rls-and-sql et cloud-delivery-aks.
Application : audit des dépendances + analyse d'images + analyse de secrets dans le CI (bloquant) ; les modèles de menaces et la couverture d'audit relèvent du jugement du relecteur.
Raisonnement complet : Articles X & XIV de la constitution, regroupés dans engineering-constitution/references/engineering-constitution.md.