Elle traduit les besoins de protection en conceptions pour l'identité, les réseaux, les workloads, les applications, les données, les plans de gestion, la supervision, la résilience et les dépendances vis-à-vis des fournisseurs. C'est une description architecturale et un modèle de décision, pas un produit ni une checklist générique.
L'architecture doit décrire les éléments exploités par le fournisseur comme ceux exploités par le client, pour les modèles de service et de déploiement choisis. Elle relie les conséquences métier et la sensibilité des données à des points d'application concrets, des chemins administratifs, des frontières cryptographiques, de la télémétrie, des mécanismes de récupération et des processus de cycle de vie. Les modèles de référence doivent être adaptés au système et au contrat.
Points clés
Périmètre et contexteIdentifier actifs, services, dépendances, juridictions, hypothèses de menace, flux de données requis, besoins de disponibilité et conséquences d'une compromission ou d'une défaillance du fournisseur.
Confiance et responsabilitéMontrer où identités, décisions de politique, application, clés, données et administration franchissent des frontières organisationnelles ou techniques, et attribuer un responsable à chaque contrôle.
Assurance et évolutionConsigner les décisions de conception et les exceptions, valider les propriétés importantes, revoir les changements du fournisseur et de l'application, tester la récupération et garder diagrammes et modèles de menace alignés sur l'infrastructure déployée.
Limite importanteUn schéma d'architecture n'établit pas que des contrôles existent, fonctionnent ou restent correctement configurés. Les modèles de référence peuvent omettre des comportements propres au service, et une conception qui ignore la responsabilité opérationnelle, les indices observables, les modes de défaillance ou la logique applicative peut créer une fausse confiance.