- Les systèmes conçus sans modèle d'autorisation explicite accumulent une dette de sécurité structurelle : corriger un modèle d'accès binaire dans un système en production est significativement plus coûteux que de le concevoir correctement dès le départ.
- Citibank (2011) : la vulnérabilité d'API traversal — permettant à un utilisateur authentifié d'accéder aux données d'un autre client en modifiant son identifiant dans l'URL — résultait d'une API conçue sans contrôle d'autorisation au niveau des ressources individuelles.
- SolarWinds (2020) : le système de build sans isolation des identités entre les étapes du pipeline CI/CD illustre une architecture conçue pour la performance sans intégration des principes de séparation des droits dès la conception.
- Le principe "deny by default" — tout accès est refusé sauf ce qui est explicitement autorisé — est le fondement d'un modèle d'autorisation sécurisé by design : il inverse la charge de la preuve et réduit le risque d'accès involontaire.
- Les API sont le périmètre le plus critique de l'Identity by Design moderne : chaque endpoint doit avoir un modèle d'autorisation explicite définissant qui peut appeler quoi, avec quels paramètres, et accéder à quelles ressources.
L'Identity by Design — ou Security by Design appliqué à la gestion des identités — est le principe selon lequel les modèles d'authentification, d'autorisation et de gestion du cycle de vie des identités doivent être définis et intégrés dès la conception d'un système, pas ajoutés en couche de sécurité a posteriori. Ce principe est fondé sur un constat économique et technique : corriger un modèle d'accès défaillant dans un système en production est plusieurs fois plus coûteux — en effort, en risque de régression et en temps — que de le concevoir correctement dès le départ.
La dette de sécurité liée à des architectures d'accès défaillantes est l'une des plus persistantes dans les systèmes d'information : elle ne se résorbe pas naturellement avec le temps et s'aggrave à mesure que le système évolue et que les intégrations s'accumulent. Les organisations qui opèrent des systèmes anciens avec des modèles d'autorisation binaires (accès total ou absence d'accès) supportent cette dette indéfiniment — sauf refonte architecturale délibérée.
Les erreurs d'architecture les plus fréquentes
L'absence de séparation entre authentification et autorisation : de nombreux systèmes anciens vérifient que l'utilisateur est authentifié mais n'implémentent pas de contrôle d'autorisation granulaire au niveau des ressources. L'utilisateur authentifié peut accéder à n'importe quelle ressource du système — la protection est périmétrique (l'entrée), pas granulaire (chaque ressource). C'est la configuration qui a rendu possible la vulnérabilité Citibank 2011 et des centaines d'incidents similaires.
L'autorisation codée en dur dans les couches applicatives : les règles d'autorisation implémentées directement dans le code applicatif (if user.role == "admin" then allow) sont rigides, difficiles à modifier sans relivraison, et ne peuvent pas être adaptées aux besoins organisationnels changeants sans intervention technique. Les architectures modernes externalisent ces décisions vers des moteurs de politiques dédiés (OPA, Casbin, AWS IAM Policies) qui peuvent être modifiés sans toucher au code applicatif.
La violation Capital One illustre une erreur de conception IAM cloud classique : un rôle AWS IAM attaché à une instance EC2 avec des droits listRead sur l'ensemble des buckets S3 de l'organisation, alors que la fonction de cette instance ne nécessitait l'accès qu'à un sous-ensemble limité de buckets spécifiques. Ce rôle avait été conçu avec des droits larges pour simplifier la configuration initiale — une décision de commodité à la conception qui a créé une surface d'attaque persistante. Une approche Identity by Design aurait imposé de définir précisément les buckets nécessaires à la fonction de l'instance lors de la conception du rôle IAM, et de documenter cette décision pour les revues périodiques futures.
Patterns d'architecture sécurisée pour les identités
Le pattern "deny by default" est le fondement du modèle d'autorisation sécurisé : toute requête d'accès est refusée par défaut, et seules les ressources et actions explicitement autorisées sont accessibles. Ce pattern inverse la logique d'un système "allow by default" (tout est permis sauf ce qui est explicitement interdit) et réduit drastiquement le risque d'accès involontaire résultant d'une configuration incomplète.
Le pattern de la séparation des préoccupations (Separation of Concerns) appliqué aux identités signifie que chaque composant d'un système ne doit avoir accès qu'aux ressources nécessaires à sa fonction spécifique. Un service de recommandation produit n'a pas besoin d'accéder aux données de paiement. Un composant de logs ne doit pas avoir les droits d'écriture sur les données de production. Cette séparation doit être définie dans la conception de l'architecture et implémentée dans les politiques IAM dès le déploiement initial.
Identity by Design dans les API
Les API constituent le périmètre le plus critique de l'Identity by Design dans les architectures modernes. Chaque endpoint d'API doit être conçu avec un modèle d'autorisation explicite : qui peut appeler cet endpoint (identité requise : utilisateur, service, rôle), sur quelles ressources (l'appelant peut-il accéder à la ressource de n'importe quel utilisateur ou seulement à la sienne ?), avec quels paramètres autorisés. Les patterns OWASP API Security Top 10 documentent les erreurs d'autorisation les plus fréquentes dans les API — dont la Broken Object Level Authorization (BOLA), analogue de la vulnérabilité Citibank — et doivent être intégrés dans les exigences de conception dès le début du projet.
La violation Home Depot a été amplifiée par une architecture réseau conçue sans isolation entre les accès prestataires de maintenance et les réseaux de paiement. Cette décision d'architecture — ou son absence — avait été prise lors de la conception du réseau de l'organisation sans évaluation formelle des implications de sécurité. Un processus d'architecture intégrant des exigences de segmentation dès la conception des réseaux d'accès prestataires aurait imposé une isolation physique ou logique des environnements de paiement, limitant structurellement le périmètre d'impact d'une compromission prestataire.
La violation EasyJet affectant neuf millions de clients résultait en partie de lacunes dans le contrôle d'accès aux systèmes de traitement des données de réservation — des lacunes issues de décisions d'architecture prises lors de la construction des systèmes de réservation en ligne, sans modèle d'autorisation granulaire pour les composants d'intégration inter-systèmes. Les systèmes de réservation complexes intègrent de nombreux partenaires et composants tiers dont les droits d'accès aux données doivent être architecturés explicitement lors de la conception des flux d'intégration.
L'incident SoftBank lié au partage de données confidentielles via ChatGPT illustre une nouvelle dimension de l'Identity by Design : la nécessité d'intégrer le contrôle des flux de données vers les services d'IA externes dès la conception des politiques d'accès. Les nouvelles catégories de services (IA générative, copilotes de code, outils de productivité cloud) doivent être intégrées dans l'architecture de contrôle des accès sortants dès leur déploiement, et non gouvernées après incident. SoftBank a mis en place des restrictions d'accès réseau vers les services d'IA non approuvés à la suite de l'incident.