Sie übersetzt Schutzbedarfe in Designs für Identität, Netzwerke, Workloads, Anwendungen, Daten, Management-Ebenen, Monitoring, Resilienz und Provider-Abhängigkeiten. Sie ist eine Architekturbeschreibung und ein Entscheidungsmodell, kein Produkt und keine generische Checkliste.
Die Architektur sollte sowohl provider- als auch kundenbetriebene Elemente über die gewählten Service- und Bereitstellungsmodelle hinweg beschreiben. Sie verbindet geschäftliche Auswirkungen und Datensensitivität mit konkreten Durchsetzungspunkten, Administrationspfaden, kryptographischen Grenzen, Telemetrie, Wiederherstellungsmechanismen und Lebenszyklusprozessen. Referenzmuster müssen an System und Vertrag angepasst werden.
Wichtigste Punkte
Scope und KontextAssets, Dienste, Abhängigkeiten, Jurisdiktionen, Bedrohungsannahmen, erforderliche Datenflüsse, Verfügbarkeitsbedarfe sowie die Folgen einer Kompromittierung oder eines Providerausfalls identifizieren.
Vertrauen und VerantwortungDarstellen, wo Identitäten, Richtlinienentscheidungen, Durchsetzung, Schlüssel, Daten und Administration organisatorische oder technische Grenzen überschreiten, und für jede Kontrolle einen verantwortlichen Eigentümer benennen.
Zusicherung und WeiterentwicklungDesignentscheidungen und Ausnahmen festhalten, wesentliche Eigenschaften validieren, Provider- und Anwendungsänderungen überprüfen, die Wiederherstellung testen sowie Diagramme und Bedrohungsmodelle mit der bereitgestellten Infrastruktur synchron halten.
Wichtige EinschränkungEin Architekturdiagramm belegt nicht, dass Kontrollen existieren, funktionieren oder korrekt konfiguriert bleiben. Referenzmuster können dienstspezifisches Verhalten auslassen, und ein Design, das operative Verantwortung, beobachtbare Nachweise, Fehlermodi oder Anwendungslogik ignoriert, kann falsche Sicherheit erzeugen.