Sicherheit brauchteinen Sollzustand.
Architektur macht Schutzanforderungen vor der Umsetzung verbindlich. Der Prozess übersetzt Geschäft, Daten, Bedrohungen, Risiken und Pflichten in Prinzipien, Zielbilder und begründete Architekturentscheide.
Vom Schutzbedarf zum
prüfbaren Entwurf.
Ein Diagramm allein ist keine Sicherheitsarchitektur. Der Prozess muss zeigen, welche Anforderungen gelten, warum ein Entwurf sie erfüllt und wie Abweichungen verantwortet werden.
Aufnehmen
Leistung, Daten, Nutzer, Abhängigkeiten und Veränderungsanlass verstehen.
klarer Architekturauftrag
Ableiten
Bedrohungen, Risiken, Schutzbedarf und Verpflichtungen zusammenführen.
begründete Anforderungen
Begrenzen
Verbindliche Regeln für Identität, Daten, Netze, Plattformen und Produkte setzen.
genehmigte Leitplanken
Gestalten
Zielbild, Vertrauensgrenzen, Kontrollpunkte und Betriebsmodell beschreiben.
prüfbarer Architekturentwurf
Prüfen
Entwurf gegen Prinzipien, Risiken, Betrieb und Nachweisfähigkeit bewerten.
dokumentierter Entscheid
Verantworten
Kompensation, Restrisiko, Owner, Befristung und Zielkorrektur festlegen.
beherrschte Ausnahme
Übergeben
Anforderungen an Entwicklung, Beschaffung, Konfiguration und Prüfung übergeben.
anschlussfähiger Sollzustand
Prinzip, Muster,
Entscheid.
Architektur braucht unterschiedliche Ebenen. Ein allgemeines Prinzip kann nicht den konkreten Systementscheid ersetzen. Ein Produktentscheid darf umgekehrt kein neues Unternehmensprinzip durch die Hintertür schaffen.
Verbindliche Leitplanke
Technologieunabhängige Aussage, etwa minimale Berechtigung, segmentierte Vertrauenszonen oder geschützte Geheimnisse.
Wiederverwendbares Zielbild
Erprobte Struktur für Identität, Cloud, Netzwerk, Daten, Endpunkte, Produkte oder Betriebsmodelle.
Prüfbarer Sollzustand
Konkrete Bedingung mit Geltung, Verantwortlichkeit und erwarteter Nachweismethode.
Begründete Auswahl
Kontext, Optionen, Abwägung, Folgen und Owner einer wesentlichen Architekturentscheidung.
Befristete Restlücke
Nicht erfüllte Vorgabe mit Ursache, Kompensation, Risiko, Genehmigung und Ablaufdatum.
Umgesetzte Architektur
Konfiguration, Test, Review oder technische Beobachtung, die den erreichten Zustand belegt.
Die Grenze liegt
zwischen Vertrauen.
Die Prüfung folgt nicht einer Produktliste. Sie betrachtet Datenflüsse, Identitäten, Vertrauensgrenzen, Ausfallwirkungen und den späteren Betrieb.
| Prüffeld | Zentrale Architekturfrage | Typischer Nachweis |
|---|---|---|
| Identität | Wie werden menschliche und technische Identitäten authentisiert, berechtigt und entzogen? | Identitätsfluss, Rollenmodell und technische Policy |
| Daten | Wo entstehen, fliessen, ruhen und verlassen schutzwürdige Informationen den kontrollierten Bereich? | Datenfluss, Klassifizierung und Schutzmechanismen |
| Netz und Cloud | Welche Vertrauenszonen und Kontrollpunkte begrenzen Bewegung und Exposition? | Zonenmodell, Pfadprüfung und Konfigurationsnachweis |
| Plattform und Endpunkt | Welcher sichere Sollzustand wird ausgerollt, überwacht und wiederhergestellt? | Baseline, Driftprüfung und Wiederherstellungstest |
| Produkt und Anwendung | Wie werden Sicherheitsanforderungen über Entwicklung, Release, Update und Support erhalten? | Threat Model, Freigaben und Produktnachweise |
| Resilienz | Welche Abhängigkeit kann eine kritische Leistung unterbrechen und wie wird weitergearbeitet? | Redundanz, Notbetrieb und getesteter Wiederanlauf |
Der Entwurf ist
noch kein Betrieb.
Architektur verantwortet den Sollzustand und seine Begründung. Die Umsetzung und dauerhafte Einhaltung liegen in den zuständigen Betriebs- und Entwicklungsprozessen.
Architektur verantwortet
- Prinzipien und Referenzarchitekturen
- Schutzanforderungen und Vertrauensgrenzen
- Architekturentscheid und dokumentierte Abweichung
- Übergabe eines prüfbaren Sollzustands
Andere Prozesse liefern
- Risiko: Risikohöhe und Restrisikoentscheid
- Entwicklung: sichere Realisierung und Release
- Konfiguration und Änderungen: kontrollierter Betrieb
- Wirksamkeit: unabhängige Prüfung des erreichten Zustands
Abweichungen zeigen
den Architekturdruck.
Nicht die Anzahl produzierter Diagramme zählt. Relevant ist, ob wesentliche Vorhaben rechtzeitig geprüft werden und ob wiederkehrende Abweichungen eine strukturelle Ursache zeigen.
Wesentliche Vorhaben mit Architekturentscheid vor Beschaffung oder Umsetzung.
Sicherheitsanforderungen, die erst im Test, Audit oder Betrieb erkannt wurden.
Offene Ausnahmen ohne gültige Kompensation, Risk Owner oder Ablaufdatum.
Mehrere Vorhaben mit derselben Abweichung vom Zielbild.
Anforderungen ohne definierte technische oder organisatorische Prüfung.
Referenzarchitekturen, die neue Bedrohungen, Technologien oder Pflichten nicht abdecken.
Security Tool NavigatorWerkzeugklassen entlang ihrer tatsächlichen Sicherheitsaufgabe einordnen.Navigator öffnen →
CRA ProduktsicherheitsmodellProduktanforderungen über Entwicklung, Release, Update und Support verbinden.Framework öffnen →
Sollzustände bleiben
begründet.
Architektur übersetzt Schutzbedarf in Prinzipien, Muster und begründete Abweichungen. Referenzen definieren keine Zielarchitektur, sondern liefern den Rahmen für überprüfbare Sicherheitsentscheide.
| Referenz | Beitrag zum Prozess | Grenze |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.8 und relevante technologische Controls stützen sichere Architektur- und Engineering-Prinzipien. | Ersetzt keine konkrete Produkt- oder Integrationsentscheidung. |
| NIST CSF 2.0 | Verbindet Architektur mit Plattformschutz, Daten, Identitäten und Infrastrukturresilienz. | Definiert keine einheitliche Referenzarchitektur. |
| BSI Standards 200-1 und 200-2 | Unterstützen Schutzbedarfsfeststellung, Modellierung und nachvollziehbare Sicherheitskonzeption. | Die konkrete Umsetzung bleibt organisations- und objektbezogen. |
| Inhalt | Beitrag | Weiter |
|---|---|---|
| 05 Inventar | Liefert Services, Abhängigkeiten, Owner und technischen Bestand. | Prozess öffnen → |
| Änderungen | Sichert, dass Architekturentscheide im Eingriff berücksichtigt werden. | Prozess öffnen → |
| Konfiguration | Hält freigegebene technische Sollzustände im Betrieb überprüfbar. | Prozess öffnen → |
Security Tool Navigator · Werkzeuge zum Prozess
Werkzeuge nach Gebiet einordnen.
Die Werkzeugklassen dieses Prozesses sind im Security Tool Navigator nach Sicherheitsgebieten geordnet. Die Gebietsseiten zeigen Abgrenzung, Auswahlfragen für CIO und CISO und alle Werkzeugklassen im Zusammenhang.