30. La sécurité : réduire les chemins d'abus
Pourquoi ce chapitre existe
La sécurité échoue lorsqu'elle apparaît à la fin comme une validation séparée ou une liste de vulnérabilités à fermer. Les choix de données, d'identité, de contrat, de journalisation et de déploiement ont déjà déterminé une grande partie de la surface d'attaque. La sécurité est une propriété continue : comprendre ce qui doit être protégé, qui peut agir, quels abus sont plausibles et comment détecter puis contenir une violation.
Les idées essentielles
- La sécurité part des actifs, acteurs, frontières de confiance et conséquences métier, pas d'une liste d'outils.
- Les contrôles doivent être proportionnés : authentification, autorisation, validation, secret, journalisation et limitation répondent à des risques différents.
- Le moindre privilège et la séparation des responsabilités limitent le rayon d'action d'un compte ou service compromis.
- La détection et la réponse font partie de la sécurité : un contrôle silencieusement contourné est une promesse fragile.
Modéliser les menaces au moment où les choix sont encore ouverts
Une revue de menace courte peut demander : quelles données, opérations ou décisions ont de la valeur ? quels acteurs y accèdent ? où la confiance change-t-elle ? qu'arriverait-il si une requête était rejouée, modifiée ou vue par un tiers ? L'objectif n'est pas de prédire chaque attaquant. Il est de révéler les hypothèses de confiance et de choisir des protections avant que l'architecture ne les rende coûteuses.
| Risque | Contrôles possibles | Preuve attendue |
|---|---|---|
| Accès non autorisé | Authentification, autorisation côté serveur, moindre privilège | Tests de droits et audit de rôles |
| Fuite de donnée | Minimisation, chiffrement, masquage, rétention | Revue de flux, logs contrôlés, tests d'accès |
| Rejeu ou abus | Idempotence, limite de débit, expiration, signature | Tests de scénarios abusifs et métriques |
| Dépendance compromise | Inventaire, mises à jour, isolation, provenance | Scan, politique d'exception, artefact traçable |
L'autorisation est une décision de domaine
Vérifier qu'une personne est connectée ne dit pas qu'elle peut accomplir une action sur cette ressource dans ce contexte. Les règles d'autorisation méritent un lieu central, des tests de cas négatifs et des traces d'audit pour les opérations sensibles. Les déléguer à une interface cliente ou à une convention de route les rend faciles à contourner.
Les logs peuvent aider à investiguer ; ils peuvent aussi exposer des secrets, données personnelles ou tokens. Chaque nouvelle trace doit être examinée comme un flux de données avec accès, rétention et masquage, en particulier pendant un incident où la tentation de tout enregistrer est forte.
Anti-patterns
Considérer le scan de dépendances comme stratégie complète
Les scans détectent des composants connus, pas une autorisation erronée, un abus métier ou une fuite par journalisation. Ils sont une barrière essentielle parmi d'autres, et leurs alertes doivent être triées selon l'exposition réelle et un délai de correction assumé.
Introduire des secrets dans le code ou les logs
Un secret commité, copié dans une configuration non contrôlée ou exposé par un message d'erreur se propage très vite. Utiliser un stockage dédié, limiter les accès, faire tourner les secrets et vérifier l'absence de fuite dans les artefacts réduit ce risque systémique.
Ajouter une approbation de sécurité sans changer le flux
Une signature tardive ne protège pas un modèle de confiance mal compris. Les compétences de sécurité doivent intervenir sur les changements à haut risque, avec des décisions, critères et outils qui restent utilisables par l'équipe qui livre.
Bonnes pratiques
Construire des chemins d'exception explicites
Un correctif urgent ou une dépendance vulnérable peut justifier un risque temporairement accepté. L'exception doit nommer l'actif, le risque, les protections compensatoires, le décideur et la date de révision. Le silence transforme une exception temporaire en vulnérabilité durable.
Exercer la réponse aux événements de sécurité
Savoir révoquer un accès, faire tourner un secret, préserver les preuves et communiquer de façon responsable ne s'improvise pas. Des exercices proportionnés valident les accès et réduisent le dommage d'une compromission réelle.
Checklist — Le changement réduit-il les chemins d'abus ?
- Quels actifs et opérations sensibles sont concernés, et quels acteurs peuvent y accéder ?
- Où se trouvent les frontières de confiance et les hypothèses qui les traversent ?
- Les droits sont-ils contrôlés côté serveur, au plus près de la décision ?
- Les données, secrets et logs ont-ils un cycle d'accès et de rétention adapté ?
- Quels abus plausibles ont été testés, détectés ou limités ?
- Qui décide et réexamine les risques de sécurité temporairement acceptés ?
À retenir
La sécurité est une discipline de réduction des chemins d'abus. Elle devient durable lorsqu'elle est intégrée aux décisions de conception, aux preuves, à l'observabilité et à la réponse opérationnelle — pas ajoutée comme une porte finale.