Sicherheitsarchitektur für die Hybrid Cloud

Kapitel 1. Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Sicherheit wird oft vereinfacht auf die Auswahl von Sicherheitskontrollen oder Gegenmaßnahmen reduziert, die den Verlust von Vertraulichkeit, Integrität und Verfügbarkeit verhindern. Die Integration der Kontrollen ist jedoch genauso wichtig wie die Auswahl der Kontrollen. Die Integration der Sicherheitskontrollen hängt von einer Reihe von architektonischen Entscheidungen ab, die von der Sensibilität der Daten und dem Kontext der Systemumgebung abhängen.

Es gibt Veröffentlichungen, die nützliche Anleitungen für den Entwurf und die Implementierung von Cybersicherheitstechnologien, den Einsatz von Softwarearchitekturmethoden und die Anwendung von Cloud-Sicherheitsdiensten bieten. Es besteht jedoch ein Bedarf an einer wiederholbaren und konsistenten Herangehensweise an die architektonischen Überlegungen für die sichere Gestaltung eines Informationssystems, das in einer hybriden Cloud gehostet wird.

Es ist notwendig, die architektonischen Denkweisen klar zu kommunizieren und zu gewährleisten, dass die Kontrollen effektiv und umfassend sind. In einem regulierten Umfeld ist dies besonders wichtig, denn es muss Transparenz herrschen, angefangen bei der Gestaltung der Sicherheitskontrollen bis hin zu den Kontrollmechanismen, mit denen die Einhaltung der Vorschriften nachgewiesen wird.

Dieses Buch führt dich Schritt für Schritt durch die Sicherheitsarchitektur einer Lösung, die in der Hybrid Cloud angesiedelt ist. Dieses erste Kapitel gibt den Kontext für den Rest des Buches vor, indem es beschreibt:

• Die Notwendigkeit einer effektiven Integration der grundlegenden Sicherheitstechniken

• Die Art von Architekt, die das in diesem Buch beschriebene architektonische Denken anwenden sollte

• Wie die Struktur des Buches ein Artefakt-Abhängigkeitsdiagramm als Roadmap für architektonisches Denken für Sicherheit verwendet

Wenn du das Einführungskapitel gelesen hast, kannst du zu einem Kapitel springen, das für den aktuellen Stand deines Architekturdenkens relevant ist. Wir empfehlen dir jedoch, am Anfang zu beginnen, denn die End-to-End-Methode hilft dir, die Rückverfolgbarkeit von Anforderungen, die Zerlegung der Architektur und die Modellierung von Bedrohungen bis hin zur Erkennung und Reaktion zu verstehen. Sobald du die End-to-End-Methode gelesen hast, ist das Buch ein nützliches Nachschlagewerk, um die Techniken aufzufrischen, während du an der Sicherheit einer Lösungsarchitektur arbeitest.

Beginnen wir damit, die grundlegenden Sicherheitstechniken für eine effektive Integration von Sicherheit und Compliance in Hybrid-Cloud-Lösungen zu erörtern.

Grundlegende Sicherheitstechniken

gibt es viele verschiedene Sicherheitskontrollen, die dazu dienen, Daten vor dem Verlust der Vertraulichkeit, Integrität und Verfügbarkeit zu schützen. Grundlegende Sicherheitstechniken integrieren die Kontrollen in ein System. In der Regel wird jedoch jede dieser Techniken oder Konzepte unabhängig voneinander diskutiert, und die ausgewählten Techniken sind meist die Favoriten des lautesten Interessenvertreters oder Lösungsanbieters. Keine dieser Techniken allein reicht aus, um ein sicheres System zu entwickeln, aufzubauen und zu betreiben.

In diesem Buch integrieren wir vier grundlegende Sicherheitstechniken in eine durchgängige Methode:

• Compliance Management

• Datenzentrierte Sicherheit

• Sicherheit durch Design mit Bedrohungsmodellierung

• Zero-Trust-Architektur

Abbildung 1-1 zeigt, wie diese Techniken zusammenwirken und die Grundlage für die Methode bilden, die wir besprechen werden.

In der Mitte des Diagramms befinden sich die drei architektonischen Denkansätze, die wir verwenden, um die Sicherheit in die Architektur einer Lösung einzubetten. Dies alles wird durch die Demonstration der Konformität an der Außenseite unterstützt.

Die Einhaltung von Vorschriften ist ein statischer, unkonzentrierter Ansatz für die Sicherheit, aber Daten, die sich durch ein System bewegen, sind dynamisch, da sie während der Übertragung, im Ruhezustand und bei der Nutzung verarbeitet werden. Beginnen wir mit der Technik, die sich auf den Transaktionsfluss und die Verarbeitung von Daten konzentriert.

Abbildung 1-1. Gründungstechniken

Datenzentrierte Sicherheit

Bei der datenzentrierten Sicherheit liegt der Schwerpunkt auf der Analyse des Datenflusses durch ein System vom Beginn einer Transaktion bis zu ihrem Ende. In jeder Phase der Reise berücksichtigen wir die Sicherheitskontrollen, die erforderlich sind, um den Transaktionsfluss bei der Übertragung, im Ruhezustand und bei der Nutzung zu schützen.

Das Diagramm in Abbildung 1-2 zeigt den Datenfluss auf dem Weg durch ein System:

In dem Diagramm löst der Käufer eine Transaktion aus, um Waren zu bestellen. Der Kasten steht für das Unternehmen und die äußere Ellipse stellt die Grenze des Systems dar, das die Daten verarbeitet. Innerhalb des Systems gibt es drei miteinander verbundene Subsysteme, die die Daten verarbeiten. Die gepunktete Linie stellt die Transaktionsflüsse dar, die die Daten durch die Teilsysteme transportieren und geschützt werden müssen.

Abbildung 1-2. Datenzentrierte Sicherheit

Gehen wir jeden der Transaktionsflüsse der Reihe nach durch:

1. Die Bestellung wird zunächst als Transaktionsfluss vom Shopper an das Subsystem "Core app" weitergeleitet. Wenn die Bestellung abgeschlossen werden kann, wird der Fluss an das Subsystem "Zahlungen" und an ein externes Zahlungssystem weitergeleitet, wie inFluss 1 dargestellt.

2. Nach Abschluss der Zahlung kehrt die Transaktion zum Subsystem "Zahlungen" zurück und geht weiter zum Subsystem "Lieferung", um eine externe Verbindung herzustellen, um die Lieferung zu veranlassen, wie in Fluss 2 dargestellt.

3. Nachdem die Lieferung arrangiert wurde, wird die Bestellbestätigung an das Subsystem "Core app" und die Person, die die Bestellung aufgegeben hat, zurückgeschickt, wie in Fluss 3 dargestellt.

Bei vielen Schritten in diesem Transaktionsfluss werden Daten verarbeitet und aggregiert, was den Wert der Daten erhöht und den Bedarf an verstärkten Kontrollen steigert. In allen Phasen des Transaktionsflusses müssen wir die Sicherheitskontrollen berücksichtigen, um die Daten vor Verlust der Vertraulichkeit, Integrität und Verfügbarkeit zu schützen.

Sobald wir die Transaktionsabläufe verstanden haben, können wir mit dem sicheren Design von fortfahren.

Secure by Design mit Bedrohungsmodellierung

Secure by design nutzt die Modellierung von Bedrohungen, um risikobasierte Sicherheitskontrollen direkt für Transaktionen und Daten zu identifizieren, die ein Technologieprodukt oder -system durchlaufen.

In ihrem Papier " Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure-by-Design and -Default" definieren die CISA und andere nationale Sicherheitsorganisationen den Begriff "Secure-by-Design" so, dass "Technologieprodukte so konstruiert werden, dass sie einen angemessenen Schutz davor bieten, dass böswillige Cyber-Akteure erfolgreich Zugang zu Geräten, Daten und vernetzten Infrastrukturen erhalten". Das bedeutet, dass Ingenieure die Sicherheit in den Entwurf einer Software- oder Hardwarekomponente einbeziehen müssen, indem sie das Risiko durch eine Bedrohungsmodellierung bewerten.

Die Bedrohungsmodellierung identifiziert spezifische Bedrohungen und baut auf Sicherheitsrichtlinien, -praktiken und -prozessen auf, die nicht speziell auf die Risiken für sensible Daten ausgerichtet sind. Du kannst die Praxis auf die Untersuchung der Anwendungs- und Infrastrukturarchitektur ausweiten, um risikobasierte Kontrollen zu identifizieren.

Um die Identifizierung aller sensiblen Daten zu gewährleisten, verwenden wir einen systematischen architektonischen Denkansatz für die Untersuchung aller wichtigen Datenströme und Transaktionen. Die Verfahren zur Bedrohungsmodellierung müssen in einer hybriden Cloud-Umgebung über mehrere Computerplattformen hinweg funktionieren.

In Kapitel 6 werden wir die Modellierung von Bedrohungen weiter erörtern, einschließlich neuerer Ansätze wie MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge).

Zero Trust Architektur

Die Cloud und der Einsatz mobiler Geräte stellten das traditionelle Konzept eines perimeterbasierten Sicherheitsmodells in Frage. Traditionelle "Burg- und Graben"-Sicherheitsmodelle gingen davon aus, dass, nachdem die Daten den Perimeter passiert hatten, alles innerhalb eines Systems als vertrauenswürdig eingestuft werden konnte. Das Umdenken begann, als das Jericho Forum 2007 die Jericho Forum Gebote für eine entperimiterisierte Welt veröffentlichte, in der man davon ausgeht, dass es keinen Netzwerkperimeter mehr gibt.

John Kindervag, von Forrester Research, hat dann 2010 den Begriff "Zero Trust" geprägt und die Phrase "never trust, always verify" entwickelt. Er bezeichnete Zero Trust als ein Modell, das das implizite Vertrauen innerhalb einer Systemgrenze aufhebt und die Risiken kontinuierlich bewertet, indem es bei jedem Schritt der Geschäftsvorgänge und Datenströme Abhilfemaßnahmen anwendet. Der Ausdruck "assume breach" wird ebenfalls oft mit Zero Trust in Verbindung gebracht und stammt von dem Ausdruck "assume compromise", der in den 1990er Jahren vom US-Verteidigungsministerium verwendet wurde.

Der Ansatz erfordert eine Kombination aus Technologien, Prozessen, Praktiken und kulturellen Veränderungen, um erfolgreich umgesetzt zu werden. Er erfordert einen grundlegenden Wandel in der Art und Weise, wie Organisationen an die Cyber-Sicherheit herangehen .

Null Vertrauen Grundlagen

Das Zero-Trust-Modell geht davon aus, dass alle Geschäftstransaktionen und Datenflüsse, egal ob sie von innerhalb oder außerhalb des Netzwerks stammen, potenziell bösartig sind. Jede Interaktion im Rahmen einer Geschäftstransaktion oder eines Datenflusses muss kontinuierlich überprüft werden, um sicherzustellen, dass nur autorisierte Benutzer und Geräte auf sensible Geschäftsdaten zugreifen können. Damit wird die Grenze von der Systemgrenze zu dem Punkt verlagert, an dem die Identifizierung, Authentifizierung und Autorisierung stattfindet, so dass die Identität zur neuen Grenze wird. Das ganze Konzept wird oft auf das Prinzip "never trust, always verify" reduziert, aber es ist mehr als das.

Eine Zero-Trust-Architektur erfordert einen Kulturwandel, der die Bedeutung der Sicherheit und nicht nur der Einhaltung von Vorschriften im gesamten Unternehmen betont. Das bedeutet, dass die Umsetzung einer Zero-Trust-Architektur nicht nur den Einsatz spezifischer Technologien erfordert, sondern auch die Entwicklung von Prozessen und Praktiken, die eine auf Datensicherheit ausgerichtete Denkweise im gesamten Unternehmen fördern, die auf dem bereits erwähnten datenzentrierten Sicherheitsansatz aufbaut.

Bei der Planung und Entwicklung von Sicherheit für ein System sollte ein Architekt eine Reihe von Prinzipien, Grundsätzen oder einfach eine Denkweise befolgen, um Zero Trust anzuwenden. Zero Trust ist keine durchgängige Methode, und ein umfassender Ansatz erfordert die Integration mit anderen Architekturtechniken.

Null Vertrauen Prinzipien

Organisationen bieten in ihren Veröffentlichungen Anleitungen an, darunter das US National Institute of Standards and Technology (NIST) SP 800-207 Zero Trust Architecture Dokument, das eine Reihe von Grundsätzen für eine Zero-Trust-Architektur enthält und das UK National Cyber Security Centre (NCSC) Zero Trust Architecture Design Principles.

Grundsätze der Zero Trust Netzwerkarchitektur

Lass dich nicht von den "Prinzipien der Zero-Trust-Netzwerkarchitektur " verwirren, die von Lösungsanbietern zur Beschreibung ihrer Produkte verwendet werden; sie sind eine Untermenge der allgemeinen Zero-Trust-Prinzipien.

Im gesamten Buch zeigen wir die Zero-Trust-Leitsätze und -Prinzipien, die in die Methode eingebettet sind. In Tabelle 1-1 haben wir fünf übergeordnete Leitprinzipien erstellt, die den Grundsätzen und Prinzipien zugeordnet sind. Wir haben sie auf die bekannten Phrasen aus dem Marketing zurückgeführt.

Tabelle 1-1. Null-Vertrauensgrundsätze und Prinzipien - Zuordnung

Leitsätze	NIST SP 800-207 Zero Trust Architecture - Grundsätze	UK NCSC Zero Trust Architecture Gestaltungsprinzipien
Datenzentrierte Sicherheit	Alle Datenquellen und Rechendienste werden als Ressourcen betrachtet.	Kenne deine Architektur mit Benutzern, Geräten, Diensten und Daten. Kenne deine Benutzer-, Dienst- und Geräteidentitäten.
"Never trust,always verify"oder Identitätsprüfung + Zugriffskontrolle + Least privilege + Mikrosegmentierung	Der Zugriff auf einzelne Unternehmensressourcen wird pro Sitzung gewährt. Der Zugang zu den Ressourcen wird durch dynamischeRichtlinien bestimmt, die den beobachtbaren Zustand der Client-Identität, der Anwendung/des Dienstes und des anfragenden Objektsumfassen und weitere Verhaltens- und Umgebungsattribute beinhalten können. Alle Ressourcenauthentifizierungen und -autorisierungen sind dynamisch und werden streng erzwungen, bevor der Zugriff erlaubt wird.	Verwende Richtlinien, um Anträge zu genehmigen. Authentifiziere und autorisiere dich überall.
Datenschutz überall	Die gesamte Kommunikation ist unabhängig vom Standort des Netzwerks gesichert.	Vertraue keinem Netzwerk, auch nicht deinem eigenen.
"Bruch annehmen" oder Kontinuierliche Überwachung	Das Unternehmen überwacht und misst die Integrität und die Sicherheitslage aller eigenen und zugehörigen Vermögenswerte. Das Unternehmen sammelt so viele Informationen wie möglich über den aktuellen Zustand der Anlagen, der Netzwerkinfrastruktur und der Kommunikation und nutzt sie, um seine Sicherheitslage zu verbessern.	Beurteile das Nutzerverhalten, den Service und den Gerätezustand. Konzentriere deine Überwachung auf Nutzer, Geräte und Dienste.
Auswahl der Komponenten ohne Vertrauen		Entscheide dich für Dienste, die auf Null Vertrauen ausgelegt sind.

Wir müssen dann nachweisen, dass wir nicht nur die Richtlinien, Praktiken und Prozesse einhalten, sondern auch die Bedrohungen, die wir identifiziert haben.

Compliance Management

Eine Organisation nutzt Compliance-Management-Prozesse, um zu zeigen, dass sie eine Reihe von Regeln, Vorschriften oder Standards einhält, die von externen Organisationen wie Regierungen und Branchenverbänden vorgegeben werden. Der Prozess stellt sicher, dass Unternehmen diese strengen Anforderungen in Bezug auf betriebliche Risiken, Sicherheit, Datenschutz und Ausfallsicherheit einhalten.

Das Compliance-Management umfasst die Überprüfung, ob ein Informationssystem eine Reihe von Richtlinien, Praktiken und Prozessen für die Organisation erfüllt. Sie decken möglicherweise nur einen Teil der Sicherheitskontrollen ab, die für den Schutz sensibler Daten erforderlich sind, da sie oft ein Mindestmaß an Sicherheit darstellen, das Organisationen erfüllen müssen, um Geldbußen oder gesetzliche Strafen zu vermeiden.

Oft kann das Sicherheitsteam nicht mit dem technologischen Wandel, neuen Systemschwachstellen, aufkommenden Bedrohungen oder fortschrittlichen Angriffstechniken Schritt halten, was zu langsamen oder verzögerten Aktualisierungen der Sicherheitsrichtlinien und -standards führt. In manchen Fällen muss erst ein Sicherheitsvorfall eintreten, um Verbesserungen des Schutzes zu erzwingen, damit neue Arten von Angriffen oder Sicherheitsschwachstellen, die zuvor nicht erkannt oder blockiert wurden, bewältigt werden können.

Die ständige Anhebung der Anforderungen an die Einhaltung der Vorschriften erfordert manchmal die Einführung neuer Kontrollen, auch wenn das Risiko die verstärkten Kontrollen nicht rechtfertigt. Die verstärkte Einhaltung der Vorschriften verursacht zusätzliche Kosten, und der Schutz kann für die sensibelsten Daten immer noch unwirksam sein.

Compliance ist keine Sicherheit

Compliance ist nicht Sicherheit, und ohne Sicherheit wirst du keine Compliance erreichen. Wir haben schon viele Unternehmen gesehen, die viel Geld in den Nachweis der "Nichteinhaltung" von Vorschriften investieren, indem sie die Einhaltung der Vorschriften überprüfen, Kontrollen durchführen und Audits durchführen, aber nur wenig in die Sicherheit investieren. Konzentriere dich auf Sicherheit und Rückverfolgbarkeit, um die Einhaltung der Vorschriften nachzuweisen.

In Kapitel 4 werden Techniken zur Überprüfung der Einhaltung der Vorschriften erörtert, einschließlich Rückverfolgbarkeit zum Nachweis der Einhaltung der Vorschriften, und in Kapitel 10 werden Techniken zur Sicherung der Einhaltung der Vorschriften erörtert.

Fahren wir fort mit einer Diskussion über die Benutzer der grundlegenden Sicherheitstechniken in der Branche heute.

Anwender der Sicherheitstechniken

Die Techniken oder Modelle, die wir in diesem Abschnitt besprechen, werden oft von verschiedenen Arten von Sicherheitsexperten verwendet, was dazu führt, dass jeder der verschiedenen Benutzer seine eigene Lieblingstechnik fördert. Über die Integration dieser Techniken wird nicht oft geschrieben oder sie wird nicht als integriertes Set von Techniken praktiziert.

Und wo werden diese Techniken heute eingesetzt?

Datenzentrierte Sicherheit

Wir haben gesehen, wie Architekten farbige Datenflüsse für architektonisch bedeutsame Datenflüsse überlagern, aber das sehen wir nicht regelmäßig. Manchmal wird es aus Sicherheitsgründen verwendet, und manchmal dient es nur dazu, den Transaktionsfluss zu zeigen.

Sicherheit durch Design mit Bedrohungsmodellierung

Secure by design wird meist auf die Entwicklung eines Softwareprodukts im Rahmen des Softwareentwicklungszyklus verwiesen. Es behandelt die Verwendung eines Bedrohungsmodells als Teil des Produktdesigns. Seit der Veröffentlichung von Threat Modeling: Designing for Security (Wiley) von Adam Shostack im Jahr 2014 verwenden Softwareentwickler/innen (oder -ingenieure) die Bedrohungsmodellierung immer häufiger als Technik während der Softwareentwicklung. Wir sehen, dass die Technik meist in der Softwareentwicklung eingesetzt wird und nicht für das End-to-End-Design einer ganzen Anwendung, eines Systems oder eines Systems von Systemen verwendet wird.

Zero-Trust-Architektur

Viele verschiedene Organisationen setzen Zero-Trust-Architekturen ein, aber Lösungsanbieter dominieren, wenn sie diese Technik nutzen, um Produkte zu verkaufen, die sich auf einen Bereich konzentrieren, wie z.B. Netzwerksicherheit, Identitätsmanagement oder Bedrohungsmanagement.

Compliance

Compliance steht in vielen regulierten Branchen oft im Fokus der Risiko- und Compliance-Organisationen. Wir vermuten, dass dies daran liegt, dass es für Prüfer, Berater und Führungskräfte einfacher ist, über eine Reihe von Checklisten nachzudenken, die nicht das tiefe technische Hintergrundwissen erfordern, das für die Anwendung anderer Techniken notwendig ist.

Dieses Buch führt dich durch eine Methode, die alle diese Techniken miteinander verbindet. Doch bevor wir über eine Methode sprechen, sollten wir uns überlegen, wer die Sicherheit in eine Lösung einbauen sollte.

Architekten-Rollen für Sicherheit

Architektonisches Denken ist die Hauptaufgabe eines Architekten. Aber auch Berater/innen und Softwareentwickler/innen, die architektonische Entscheidungen treffen, können diese Fähigkeit nutzen. In Kapitel 2 werden wir näher darauf eingehen, wie architektonisches Denken mit Beratung und Technik zusammenpasst.

Architektonisches Denken für sicheres Design ist nicht nur für Sicherheitsarchitekten wichtig; eine Vielzahl von Architektenrollen muss die Sicherheit bei der Entwicklung eines Informationssystems berücksichtigen. Architekten, die Infrastruktur oder Anwendungen entwickeln, sollten diese Methode anwenden, nicht nur Sicherheitsarchitekten.

In der agilen Entwicklung wird eine hybride Rolle benötigt, ein sogenannter Security Champion, der sowohl über architektonische als auch technische Fähigkeiten verfügt. Er sollte in der Lage sein, die Entwickler bei der Einbindung von Sicherheit in DevSecOps zu beraten.

Eine Reihe von verschiedenen Architektenrollen sollte architektonisches Denken für Sicherheitstechniken nutzen, darunter:

• Sicherheitsarchitekt

• Architekt für Infrastruktur und Anwendungen

• Meister der Sicherheit

Fahren wir fort, indem wir jede dieser Architektenrollen besprechen und wie sie die Methode in diesem Buch anwenden sollten.

Sicherheitsarchitekt

Ein Sicherheitsarchitekt ist ein Architekt, der sich auf die Bereiche Sicherheit, Compliance und Risikomanagement spezialisiert hat. Wir haben die Rolle des Sicherheitsarchitekten weiter in vier Kategorien unterteilt: Enterprise Security Architect, Solution Security Architect, Product Security Architect und Advisory oder Consulting Security Architect. Jede Rolle verfügt über die gleichen Sicherheitskompetenzen, hat aber einen anderen Schwerpunkt mit zusätzlichen Fähigkeiten und Erfahrungen:

Architekt für Unternehmenssicherheit

Ein Sicherheitsexperte, der sich auf Unternehmensarchitekturen spezialisiert hat und auf Unternehmensebene Leitlinien für die Anwendung von Sicherheit in einem Unternehmen erstellt. Sie entwickeln eine Unternehmensarchitektur und Leitprinzipien, die sich an der Sicherheitsstrategie orientieren und die Entwicklung der Sicherheit in Lösungsarchitekturen leiten.

Sie müssen ein gutes Verständnis für aktuelle Bedrohungen und die Ausrichtung der Branche haben und über ausgezeichnete Kommunikationsfähigkeiten verfügen, um das Unternehmen mit der Sicherheitsstrategie und -architektur in Einklang zu bringen.

Wenn du diese Rolle innehast, enthält dieses Buch in den Kapiteln 2 und 3 einige allgemeine Hinweise zur Unternehmensarchitektur. Zusammen mit dem Rest des Buches versetzen diese Kapitel einen Sicherheitsarchitekten in die Lage, das architektonische Denken für einen sicheren Entwurfsprozess zu verstehen, so dass er den richtigen Input liefern kann, um Architekten bei der Entwicklung von Sicherheitslösungen zu unterstützen.

Architekt für Lösungssicherheit

Ein Sicherheitsexperte, der auf die Entwicklung von Lösungsarchitekturen für die Sicherheit in bestimmten Projekten oder Initiativen innerhalb einer Organisation spezialisiert ist. Er kann zum Beispiel eine Architektur für eine bestimmte Lösung entwickeln, wie zum Beispiel einen Dienst zur Verwaltung von privilegiertem Zugang.

Sie müssen ein tiefes Verständnis der spezifischen Bedrohungen und Risiken haben, die mit der Technologie verbunden sind, und sie müssen die Unternehmensstrategie, die Unternehmensarchitektur, die Richtlinien, Standards und Leitlinien des Unternehmens gut kennen.

Außerdem müssen sie über alle Fähigkeiten von Infrastruktur- und Anwendungsarchitekten in den Bereichen Ausfallsicherheit, Skalierbarkeit und Betrieb verfügen, da sie die Architektur für eine Sicherheitsanwendung entwickeln werden.

Sie werden eng mit Ingenieuren, Entwicklern, Testern und Projektmanagern zusammenarbeiten. Sie müssen über ausgezeichnete Kommunikationsfähigkeiten verfügen, um nicht-technischen Interessengruppen Sicherheitsbelange zu erklären.

Wenn du diese Rolle innehast, bietet das gesamte Buch die sicherheitsspezifischen Architekturaktivitäten, die für eine Sicherheitslösung benötigt werden. Allgemeine Architekturtechniken, die in anderen Veröffentlichungen zur Software- und Anwendungsarchitektur zu finden sind, ergänzen jedoch die in diesem Buch behandelten Techniken. Am Ende dieses Kapitels findest du Verweise auf andere nützliche Publikationen.

Architekt für Produktsicherheit

Ein Sicherheitsexperte, der ein Spezialist für die Entwicklung eines Sicherheitsprodukts oder einer Produktreihe ist. Sie sind oft Spezialisten in einem bestimmten Sicherheitsbereich, wie z.B. Identitäts- und Zugriffsmanagement oder Bedrohungserkennung, und kennen die Software- und Hardwareanforderungen der Produkte genau.

Sie werden für die Entwicklung der Architektur eines Sicherheitsprodukts verantwortlich sein und eng mit den Entwicklungs- und Testteams zusammenarbeiten. Damit das Produkt schnell angenommen wird, müssen sie verstehen, wie es in eine Unternehmensumgebung passt und welche Vorteile es bringt.

Sie brauchen hervorragende Kommunikationsfähigkeiten, um dem Produktmanagementteam, das die Lösung vermarktet und verkauft, die Vorteile des Produkts zu erklären.

Wenn du diese Rolle innehast, liefert das gesamte Buch die sicherheitsspezifischen Architekturaktivitäten, die für ein Softwareprodukt benötigt werden. Allgemeine Architekturtechniken, die in anderen Softwarearchitektur-Publikationen verfügbar sind, ergänzen jedoch die in diesem Buch besprochenen Techniken. Am Ende dieses Kapitels findest du Verweise auf andere nützliche Publikationen.

Beratender oder beratender Sicherheitsarchitekt

Sicherheitsexperte, der eine Organisation bei der Integration von Sicherheitskontrollen in ihre Infrastruktur und Anwendungen berät. Er arbeitet mit dem federführenden oder leitenden Architekten für das Projekt und manchmal auch mit Architekten anderer Fachrichtungen zusammen, um die Sicherheit in die entwickelte Lösung einzubinden.

Sie müssen nicht nur die bewährten Methoden der Branche, die gesetzlichen Anforderungen und die Sicherheitstechnologien kennen, sondern auch die Lösungen der Infrastruktur- und Anwendungsarchitektur. Der Architekt verfügt über "T-förmige" Fähigkeiten mit einem tiefgreifenden Sicherheitsverständnis und einem breiten Spektrum an Fähigkeiten im Zusammenhang mit Informationssystemen.

Sie müssen in der Lage sein, mit einer Vielzahl von Interessenvertretern über Sicherheit zu sprechen, auch mit denen, die nicht technisch versiert sind, und mit denen, die an der konkreten Umsetzung der Sicherheitskontrollen arbeiten und über umfassende technische Kenntnisse verfügen.

Wenn du diese Rolle innehast, enthält das gesamte Buch die sicherheitsspezifischen Architekturaktivitäten, die für eine Infrastruktur- oder Anwendungsarchitektur erforderlich sind, und die Artefakte, die die von einem Infrastruktur- oder Anwendungsarchitekten entwickelte Architektur überlagern müssen. Am Ende dieses Kapitels findest du Verweise auf andere nützliche Publikationen, mit denen du die Architekten, die du berätst, besser unterstützen kannst.

Wenn du ein Architekt für ein Informationssystem bist, überlege dir, welche Rolle du bei der Integration der Sicherheit in die Lösungsarchitektur spielst. Die Frage ist nicht, ob du verantwortlich bist, sondern in welchem Umfang.

Infrastruktur- und Anwendungsarchitekt

gibt es viele Projekte oder Initiativen, die keinen spezialisierten Sicherheitsarchitekten benötigen. Der Infrastruktur- oder Anwendungsarchitekt muss die Sicherheit in die Lösung integrieren. Der Infrastrukturarchitekt entwickelt vielleicht eine Cloud-Plattform, während der Anwendungsarchitekt eine Zahlungsplattform entwickelt, die auf der Cloud-Plattform gehostet wird. In beiden Fällen liegt die Verantwortung für die Sicherheit bei diesen Architekten. Dieses Buch hilft ihnen dabei, die architektonische Denkweise für ein sicheres Design zu entwickeln, die sie in ihren Rollen benötigen.

Sicherheits-Champion

In einer agilen oder DevOps-Entwicklungsumgebung kann ein Security Champion die Rolle eines beratenden Sicherheitsarchitekten übernehmen. In diesem Fall verfügt der Sicherheitsexperte über eine Mischung aus architektonischem Denken und technischen Fähigkeiten, die ihn in die Lage versetzen, einen Entwickler im Detail zu beraten, wie er seinen Code sicher entwickeln kann. Weitere Einzelheiten zu dieser Rolle findest du in Kapitel 10.

Rollen und Verantwortlichkeiten im Kontext

Alle Rollen müssen den durchgängigen architektonischen Denkprozess und die damit verbundenen Artefakte verstehen. Die Zuständigkeiten der einzelnen Rollen für die Leitung oder Unterstützung bei der Entwicklung von Artefakten sind unterschiedlich. Als technische Führungskräfte müssen sie ihre Aufgaben je nach Kontext des Unternehmens, des Produkts, des Projekts oder des Programms anpassen.

Nachdem wir nun über die grundlegenden Sicherheitskonzepte, die in eine Methode integriert werden müssen, und die Architektenrollen gesprochen haben, wollen wir nun die Struktur des Buches besprechen, die einen effektiven Durchgang durch die Methode ermöglicht.

Buchstruktur

Das Buch besteht aus einer Reihe von Kapiteln, die eine Sicherheitsarchitektur aufbauen und dabei Techniken zur Entwicklung von Artefakten verwenden, die sich durch das ganze Buch ziehen. Jedes Kapitel konzentriert sich auf bestimmte Artefakte und Techniken, so dass du das Buch auch als Nachschlagewerk nutzen kannst. In jedem Kapitel werden Techniken vorgestellt, die Zero Trust unterstützen. Um das Gelernte zu vertiefen, haben wir Beispiele für Artefakte auf der Grundlage der Fallstudie in Anhang A beigefügt.

Artefakt-Rahmen

Auf findest du zunächst einen Überblick über den Rahmen, der in diesem Buch verwendet wird, gefolgt von einem detaillierten Diagramm der Artefaktabhängigkeit.

In Abbildung 1-3 zeigen wir einen Rahmen für das architektonische Denken, das für die Entwicklung einer Sicherheitsarchitektur verwendet wird. Jeder Block im Diagramm steht für eine Gruppierung zusammengehöriger Artefakte.

Abbildung 1-3. Artefakt-Rahmen

Ganz oben haben wir den Unternehmenskontext, der alle organisatorischen Inputs enthält, die für die Lösungsarchitektur verwendet werden, einschließlich des Geschäftskontexts und der Organisationsrichtlinien. Diese Artefakte werden normalerweise vor der Lösungsarchitektur erstellt, aber manchmal gibt es sie nicht und das Projekt ist für ihre Entwicklung verantwortlich. Es kann sein, dass du diese Details ausfüllen musst, was einen zusätzlichen Aufwand für das Projekt bedeutet.

Darunter befinden sich die Abschnitte Anforderungen, Architektur und Betrieb, die die Entwicklung der Architektur von links nach rechts zeigen. Der Abschnitt Anforderungen enthält die Artefakte zur Erfassung der funktionalen und nicht-funktionalen Anforderungen an die Lösung. Der Abschnitt Architektur enthält die Artefakte für die Top-Down-Zerlegung der Lösungsarchitektur, beginnend mit der Architekturübersicht und dem Systemkontext. Der Abschnitt Betrieb ist zwar der letzte in diesem Bild, aber nicht weniger wichtig. Er enthält Artefakte, die aus den Teilen Anforderungen und Architektur des Frameworks entwickelt wurden.

Unten links befindet sich der Bereich Governance, der die Artefakte enthält, die zur Unterstützung der Gesamtentwicklung der Architektur verwendet werden und in allen Phasen der Architekturentwicklung zum Einsatz kommen.

Rechts unten auf befindet sich schließlich der Bereich " Assurance", der alle Aktivitäten umfasst, die notwendig sind, um das Vertrauen in die Planung und Umsetzung der Sicherheitskontrollen zu stärken, und die bis zum zweiten Tag fortgesetzt werden.

Das ist ein Ausgangspunkt, und jetzt müssen wir den Rahmen ausarbeiten.

Artefakt-Abhängigkeitsdiagramm

Der Rahmen in Abbildung 1-4 zeigt ein Artefakt-Abhängigkeitsdiagramm mit den Dokumenten, Diagrammen und Tabellen, die mit den in diesem Buch enthaltenen Techniken erstellt wurden. In den folgenden Kapiteln werden wir die Erstellung der Artefakte anhand dieses Diagramms nachvollziehen.

Die Anzahl der Artefakte mag überwältigend erscheinen, aber die Artefakte können einzelne Diagramme und Tabellen sein und nicht ein großes Dokument. Es gibt auch Artefakte, die Code enthalten, wie z. B. eine einsatzfähige Architektur. Nutze die Artefakte und Techniken als Werkzeuge, je nach den spezifischen Anforderungen des Projekts.

Diagramm Format

Die ursprünglichen Diagramme, die wir erstellt haben, wurden neu gezeichnet, um die Konsistenz zu gewährleisten und die Anforderungen der Veröffentlichung zu erfüllen. Wenn du ausgewählte Originaldiagramme sehen möchtest, findest du sie auf der Begleitwebsite des Buches.

Es ist wahrscheinlich, dass du als Architekt mit diesen Artefakten in Berührung kommst, wobei du je nach deiner Rolle unterschiedlich viel dazu beitragen kannst. Wie bereits erwähnt, ist der Anwendungs- oder Infrastrukturarchitekt für einige dieser Artefakte verantwortlich, und du kannst sie mit Inhalten füllen. In anderen Fällen gehören sie dir. Wenn sie nicht jemandem gehören, bist du es höchstwahrscheinlich. Wenn es um Betriebsartefakte geht, erstellst du die Artefakte vielleicht nicht, aber du bist dafür verantwortlich, dass sie bereitgestellt werden.

Es ist auch nicht notwendig, alle Artefakte zu verwenden. Die Zeit, die für jedes Artefakt aufgewendet wird, sollte gerade ausreichen, um die architektonisch wichtigen Merkmale eines Systems zu vermitteln. Wenn du zum Beispiel die Wirksamkeit von Kontrollmechanismen prüfst, musst du nicht jeden einzelnen Transaktionsfluss berücksichtigen, der im System auftreten könnte. Stattdessen solltest du nach einer repräsentativen Sammlung von architektonisch bedeutsamen Transaktionsflüssen suchen, die es dir ermöglichen, alle wichtigen Wege durch das System mindestens einmal zu überprüfen.

Abbildung 1-4. Diagramm der Artefaktabhängigkeit; siehe das Originaldiagramm

Erstelle eine Dokumentation, die dem Kontext des Projekts und der Sensibilität der Daten, die das System verarbeitet, angemessen ist. Für eine Anwendung, die Vorschriften unterliegt, muss eine umfangreiche Dokumentation erstellt werden, um dem internen Risikomanagement und externen Prüfern Sicherheit zu geben. Eine Organisation, die weniger risikotolerant ist, muss möglicherweise eine erweiterte Liste von Bedrohungen und Gegenmaßnahmen erstellen.

Integration von Artefakten mit anderen Methoden

Wir haben Namen für Artefakte verwendet, die sich von denen unterscheiden können, die du für architektonisches Denken verwendest. Wir haben versucht, uns an den branchenüblichen Namen zu orientieren, und wo es keine Einigung gibt, haben wir versucht, Namen zu vergeben, die den meisten Software- oder Infrastrukturarchitekten bekannt sind. In Anhang B findest du eine Zuordnung zwischen den von uns verwendeten Artefaktnamen und anderen Methoden und Veröffentlichungen.

Du wirst oft feststellen, dass es kein gleichwertiges Artefakt zu den von uns vorgeschlagenen gibt. Das zeigt nur, dass sich andere Methoden auf bestimmte Teile des architektonischen Denkprozesses konzentrieren. Wir haben versucht, eine Reihe von Artefakten und Techniken zu entwickeln, die Praktiken wie Design Thinking und Stretching in die kritischen operativen Aspekte der Sicherheit integrieren.

Wir hoffen, dass du mit diesem allgemeinen Satz von Artefaktnamen jede beliebige Softwarearchitektur-Methode, die du verwendest, überlagern kannst. Wir versuchen nicht, dir die Methoden vorzuschreiben, die in deinem Unternehmen verwendet werden, aber wir hoffen, dass du einen Weg findest, die Methoden, Artefakte und Techniken, die du bereits verwendest, zu integrieren und zu verbessern.

Wir sind daran interessiert zu erfahren, ob du unsere Denkweise in andere Softwarearchitektur-Methoden integrierst oder ob du Ideen zur Verbesserung der Methode hast.

Jetzt müssen wir besprechen, wie wir die Anwendung der Techniken am besten demonstrieren können, um Artefakte zu erstellen.

Fallstudie

Wir haben festgestellt, dass man die Techniken zur Erstellung der Artefakte am besten anhand einer Fallstudie lernt, die ein Problem mit einem gewissen geschäftlichen Kontext, der aktuellen IT-Architektur und einem Architekturübersichtsdiagramm definiert. Wir verweisen in jedem Kapitel auf die Fallstudie in Anhang A und verwenden sie, um Beispielartefakte zu erstellen, die die Anwendung der Technik zeigen.

Abbildung 1-5 zeigt die in der Fallstudie enthaltenen Artefakte. Sie liefert einen allgemeinen geschäftlichen Kontext für das Projekt, indem sie die Notwendigkeit eines Systems zur Erhebung von Gebühren für umweltschädliche Fahrzeuge bei der Einfahrt in die Stadt erläutert. Es wird die aktuelle IT-Architektur beschrieben, einschließlich der Organisationen, die in das System integriert werden müssen, wie z. B. Clean Air Pay, das eine RabbitMQ-Integration benötigt. Wenn es sich um ein Projekt für eine Organisation mit vielen bestehenden Anwendungen handeln würde, gäbe es viel mehr Einschränkungen für die Lösung.

Abbildung 1-5. Artefakt-Abhängigkeitsdiagramm der Fallstudie

Da das System personenbezogene Daten verarbeitet, richten sich die erforderlichen Kontrollen nach den geltenden Datenschutzgesetzen. Die Anwendung muss den Payment Card Industry Data Security Standard (PCI DSS) erfüllen, da sie Zahlungen verarbeitet. Die Fallstudie sagt wenig über die bestehenden Sicherheitsrichtlinien aus, spricht aber von der Anwendung des NIST Cybersecurity Frameworks als Praxis, die das Projekt auf das System anwenden muss.

Die Fallstudie bietet ein Architekturübersichtsdiagramm, um das Gesamtsystem darzustellen. Erwarte nicht, dass das Diagramm alle externen Akteure des Systems aufzeigt. Möglicherweise musst du zusätzliche Informationen aus der Beschreibung oder implizite Systeme identifizieren, die integriert werden müssen. Dies ist das erste Diagramm, das du wahrscheinlich vom Projekt bekommst, oder du musst es selbst erstellen. Es ist ein Diagramm, das einen Überblick über die Lösung gibt, aber es wird nicht erwartet, dass es ein Standardformat hat und ein Diagramm ist, das jeder aus einer nichttechnischen Perspektive verstehen kann. Im Fallstudiendiagramm sind die Komponenten durch Linien miteinander verbunden, aber es könnte auch einfach ein Blockdiagramm mit gruppierten Fähigkeiten sein, ohne Linien, die den Kontroll- oder Datenfluss zeigen. Es wird sich wahrscheinlich im Laufe der Zeit weiterentwickeln. Achte also darauf, ob der leitende Architekt Änderungen an diesem Diagramm vornimmt, denn die Aktualisierungen können deine Lösung verändern.

Wir werden in jedem Kapitel ein Artefakt-Abhängigkeitsdiagramm verwenden, um die besprochenen Artefakte hervorzuheben. Gehen wir die einzelnen Kapitel und ihre Inhalte durch.

Buchorganisation

Wie bereits erläutert hat, sind die Kapitel in diesem Buch grob nach dem Entwicklungsprozess gegliedert, um eine Lösungsarchitektur zu erstellen, die die Sicherheit einschließt. Abbildung 1-6 zeigt den Lebenszyklus der Lösung, wobei die Kästchen Plan, Design, Build und Run die Phasen darstellen.

Diese Phasen des Lösungslebenszyklus fließen alle in die Sicherheitsarchitektur im unteren Teil des Diagramms ein. Die Blöcke "Govern", "Identify", "Protect", "Detect", "Respond" und "Recover" stimmen mit den sechs Funktionen des NIST Cybersecurity Framework überein, die wir in Kapitel 2 zusammen mit den Sicherheitsdomänen, die wir für eine Sicherheitsarchitektur im Unternehmen definiert haben, besprechen werden.

Wir werden dich nun durch die verschiedenen Teile des Buches führen, die sich an den Phasen des Lösungslebenszyklus in Abbildung 1-6 orientieren. Jeder Teil besteht aus einem oder mehreren Kapiteln.

Abbildung 1-6. Architektonisches Denken für den Sicherheitsrahmen; siehe das Originaldiagramm

Teil I. Konzepte

Wir beginnen das Buch mit zwei Kapiteln, in denen die Sicherheits- und Architekturkonzepte erläutert werden, die in diesem Buch verwendet werden. Diese Kapitel bilden die Grundlage, bevor wir uns mit den Phasen des Lebenszyklus einer Lösung beschäftigen:

Einführung

In Kapitel 1 erfährst du einiges über die Architektur, die Sicherheitsarchitektur und den Ansatz, den dieses Buch verwendet, um die Methode zu erläutern.

Architektur-Konzepte

In Kapitel 2 wird erörtert, wie sich architektonisches Denken in den Design- und Entwicklungslebenszyklus einfügt und worin der Unterschied zwischen Unternehmens- und Lösungsarchitektur besteht.

Teil II. Plan

Wir fahren mit der Planungsphase in Abbildung 1-6 fort, in der wir die Beschaffung von Anforderungen aus dem Unternehmenskontext und die Definition von Anforderungen besprechen:

Unternehmenskontext

Kapitel 3 behandelt die Informationen, die für die Entwicklung der Lösungsarchitektur von außen kommen, wie z.B. der geschäftliche Kontext, die aktuelle IT-Umgebung, Gesetze und Vorschriften, Richtlinien und Standards, die Unternehmensarchitektur und Leitprinzipien.

Anforderungen und Beschränkungen

Kapitel 4 befasst sich mit dem Sammeln von Anforderungen, beginnend mit externen Gesetzen, Vorschriften und Industriestandards. Danach geht es um die Dokumentation der funktionalen und nicht-funktionalen Anforderungen an ein System.

Teil III. Entwurf

Nachdem wir nun die Anforderungen gesammelt haben, fahren wir mit der Entwurfsphase in Abbildung 1-6 fort, in der wir den Entwurf der Lösungsarchitektur besprechen, beginnend mit den funktionalen Komponenten und weiterführend mit der implementierten Architektur:

Systemkontext

In Kapitel 5 wird die zentrale architektonische Denkweise für den Schutz sensibler Werte erörtert, indem der Fokus auf die Grenzen des Systems gelegt wird, d.h. darauf, wo die Daten fließen, wo sie gespeichert und wo sie verarbeitet werden. Ein Architekt verwendet das Systemkontextdiagramm, um die Grenzen des Systems und die externen Akteure zu definieren, die durch Interaktionen mit dem System Datenflüsse auslösen. Im weiteren Verlauf des Kapitels werden die Dokumentation von, ein Verzeichnis der Informationsbestände und die Klassifizierung der Daten beschrieben, um die Arten von Kontrollen je nach Sensibilität der Daten zu bestimmen.

Anwendungssicherheit

Kapitel 6 befasst sich mit der Entwicklung einer funktionalen Architektur für eine Anwendung oder einen Workload durch die Dokumentation eines Komponentenarchitekturdiagramms. Weiter geht es mit der Bedrohungsmodellierung auf hoher Ebene für die Anwendungskomponenten.

Geteilte Verantwortlichkeiten

In Kapitel 7 wird der Einsatz von Anwendungsteilsystemen auf Technologieplattformen erörtert und die gemeinsamen Verantwortlichkeiten für eine Reihe von Hybrid-Cloud-Plattformen dokumentiert.

Sicherheit der Infrastruktur

In Kapitel 8 wird die Lösung weiter ausgearbeitet, indem die funktionalen Komponenten in der Infrastruktur eingesetzt werden und sichergestellt wird, dass die Datenflüsse nach dem Zero-Trust-Prinzip geschützt werden. Ein Architekturdiagramm für die Bereitstellung oder ein Cloud-Architekturdiagramm liefert die Dokumentation für eine hybride Cloud-Infrastrukturarchitektur. In den Architekturdiagrammen wird dann die Bedrohungsmodellierung wiederholt.

Architekturmuster und -entscheidungen

In Kapitel 9 geht es darum, wie du das architektonische Denken mit Hilfe von Architekturmustern und einsatzfähigen Architekturen beschleunigen kannst. Das Kapitel führt dann in die Verwendung von architektonischen Entscheidungsprotokollen ein.

Teil IV. Baue

Wenn wir eine Lösungsarchitektur entworfen haben, fahren wir mit der Build-Phase in Abbildung 1-6 fort, indem wir den Entwicklungslebenszyklus betrachten:

Sichere Entwicklung und Gewährleistung

In Kapitel 10 geht es um den Entwicklungszyklus und darum, wie sich das architektonische Denken für die Sicherheit in diesen Zyklus einfügt, einschließlich der agilen Entwicklung und der Rolle eines Sicherheitsbeauftragten. Anschließend wird die Rolle des Risiko-, Problem-, Annahmen- und Abhängigkeitsprotokolls während des Entwurfs- und Entwicklungslebenszyklus betrachtet.

Teil V. Lauf

Schließlich muss das System auch nach der Inbetriebnahme sicher bleiben. Deshalb besprechen wir die betrieblichen Aspekte des Systems, wie in der Ausführungsphase in Abbildung 1-6 dargestellt:

Sicherheitsmaßnahmen

In Kapitel 11 werden die Rollen und Zuständigkeiten, die mit dem Diagramm der geteilten Verantwortung ermittelt wurden, in in einer RACI-Tabelle (Responsible, Accountable, Consulted, and Informed) zusammengefasst. Die Zuständigkeiten werden dann durch die Prozesse, Verfahren und Arbeitsanweisungen dokumentiert, die zur Sicherung des Systems erforderlich sind. Wir fahren dann mit der Dokumentation der Erkennung von Bedrohungen und der Reaktion auf Vorfälle durch einen Anwendungsfall zur Erkennung von Bedrohungen und ein Runbook zur Reaktion auf Vorfälle fort.

Teil VI. Schließen

Und das letzte Kapitel enthält einige abschließende Gedanken:

Schlussgedanken

Kapitel 12 schließt das Buch mit einigen Überlegungen zu bewährten Methoden bei der Integration von Sicherheit in eine Lösungsarchitektur ab.

Architektonisches Denken ist die Zerlegung einer Lösung durch einen iterativen Prozess in immer mehr Details. Lasst uns besprechen, wie wir das tun werden.

Zerlegung der Lösungsarchitektur

Auf gliedern wir die Lösungsarchitektur des Informationssystems in Schichten, wie in Abbildung 1-7 dargestellt. Wir beginnen auf der obersten Ebene, indem wir ein Systemkontextdiagramm verwenden, um die Grenzen des Systems zu beschreiben und wie es mit externen menschlichen und Systemakteuren verbunden ist. In Kapitel 5 werden wir mehr darüber erfahren.

Anschließend werden wir uns die funktionalen Komponenten der Anwendung oder des Workloads ansehen, die sich innerhalb der Systemgrenze befinden. Wir werden beschreiben, wie sie miteinander interagieren und die Bedrohungen für die Anwendung untersuchen. In Kapitel 6 werden wir dies genauer untersuchen.

Abbildung 1-7. Schichten zur Zerlegung der Lösungsarchitektur

Auf der untersten Ebene werden wir die Bereitstellung der funktionalen Komponenten der Anwendung in der Infrastruktur untersuchen und die Praktiken der Zero-Trust-Architektur anwenden. In Kapitel 8 werden wir diese Schicht genauer untersuchen.

Andere Architekturmodelle können zusätzliche Schichten einführen, aber wir haben versucht, es einfach zu machen, damit du die Techniken auf verschiedene Architekturmethoden anwenden kannst. Es ist jedoch wahrscheinlich, dass du jede Schicht von einer logischen zu einer physischen (oder präskriptiven) Perspektive zerlegen wirst. Ein Beispiel für diese Unterteilung findest du in Kapitel 5. Ein weiteres Beispiel ist die Unterteilung in Container-, Komponenten- und Codediagramme im C4-Modell.

Wir fahren fort mit einer Diskussion über die Schritte, die beim architektonischen Denken und der Zerlegung eine Rolle spielen.

Methodentechniken

In jedem der folgenden Kapitel wird mindestens eine Technik des architektonischen Denkens behandelt.

Wir unterteilen die Techniken in zwei Typen:

Unternehmen

Die besprochenen Techniken gelten für die Unternehmensarchitektur und verwenden keine Fallstudie.

Fallstudie

Die unter besprochenen Techniken werden anhand der Fallstudie in Anhang A demonstriert, wie sie anzuwenden sind.

Tabelle 1-2 listet die Techniken und ihre Art auf, die in den einzelnen Kapiteln behandelt werden.

Tabelle 1-2. Techniken nach Kapitel

Kapitel	Technik Typ	Technik
Kapitel 2, "Architektur-Konzepte"	Unternehmen	Sicherheitsarchitektur für Unternehmen
Kapitel 3, "Unternehmenskontext"	Unternehmen	Alle Artefakte aus der Unternehmenskontextgruppe
Kapitel 4, "Anforderungen und Beschränkungen"	Fallstudie	Anwendungsfall Journey Map User Stories Swimlane-Diagramm Matrix der Aufgabentrennung Nicht-funktionale Anforderungen Matrix zur Rückverfolgbarkeit von Anforderungen
Kapitel 5, "Systemkontext"	Fallstudie	Systemkontextdiagramm Register der Informationsgüter
Kapitel 6, "Anwendungssicherheit"	Fallstudie	Datenflussdiagramm Diagramm der Komponentenarchitektur Sequenzdiagramm Kollaborationsdiagramm Bedrohungsmodell
Kapitel 7, "Geteilte Verantwortlichkeiten"	Fallstudie	Diagramm der geteilten Verantwortung
Kapitel 8, "Sicherheit der Infrastruktur"	Fallstudie	Diagramm der Bereitstellungsarchitektur Diagramm der Cloud-Architektur
Kapitel 9, "Architekturmuster und -entscheidungen"	Fallstudie	Architekturmuster Einsetzbare Architektur Architektonische Entscheidungsprotokolle
Kapitel 10, "Sichere Entwicklung und Assurance"	Fallstudie	Protokoll der Risiken, Annahmen, Probleme und Abhängigkeiten (RAID) Teststrategie und -plan
Kapitel 11, "Sicherheitsmaßnahmen"	Fallstudie	Geteilte Verantwortlichkeiten RACI Prozess (Swimlane-Diagramm) Statechart-Diagramm Abläufe Arbeitsanweisungen Matrix der Aufgabentrennung Anwendungsfall der Bedrohungserkennung Runbook für die Reaktion auf Vorfälle Matrix zur Rückverfolgbarkeit von Bedrohungen

Reihenfolge der Techniken

Die Reihenfolge der Techniken im Buch entspricht der Reihenfolge, in der wir die Studierenden im Rahmen des MSc-Moduls in Großbritannien unterrichten. Wir haben die Reihenfolge so gestaltet, dass die Architektur Schritt für Schritt aufgebaut wird. Die Dokumentation der architektonischen Entscheidungsprotokolle und RAID-Artefakte sollte bereits zu Beginn des architektonischen Denkprozesses erfolgen, aber es ist sinnvoller, sie nach Abschluss einiger architektonischer Überlegungen zu besprechen.

In vielen Kapiteln bieten wir eine QS-Checkliste oder zusätzliche Details zu den Schritten, die du durchführen solltest, um hochwertige Artefakte zu liefern.

Am Ende eines jeden Kapitels gibt es einen Übungsteil mit Multiple-Choice-Fragen. Die Antworten findest du in Anhang C. Weitere zusammenfassende Fragen mit Antworten findest du auf der begleitenden Website.

Lasst uns dieses Kapitel mit einigen abschließenden Gedanken beenden.

Zusammenfassung

Wir haben zunächst vier grundlegende Techniken für die Entwicklung von Sicherheit in Systemen erörtert und dargelegt, wie problematisch es ist, wenn diese Techniken nicht miteinander integriert werden und so ein unzusammenhängender Ansatz zur Integration von Sicherheit in ein Informationssystem entsteht. Wir glauben, dass es notwendig ist, die Techniken zu integrieren, um eine robuste Methode für die Sicherheitsarchitektur zu schaffen, die die bestehenden Methoden für Informationssysteme und Softwarearchitekturen überlagert.

Anschließend haben wir die verschiedenen Arten von Architekten besprochen, die die Methode anwenden werden. Wir glauben, dass alle Arten von Informationssystemarchitekten in der Lage sein müssen, die Sicherheit eines Informationssystems zu entwerfen. Ein Sicherheitsarchitekt ist dazu da, andere Architekten zu unterstützen und eine Architektur für Sicherheitsdienste zu entwickeln. Überlege dir, welche Rolle du als Berater, Architekt oder Ingenieur spielst und wie die Architektur für Sicherheit in deine aktuellen Projekte passt.

Im letzten Abschnitt wird die Struktur des Buches erläutert, wobei das Diagramm der Artefaktabhängigkeit die Reise durch die Methode des architektonischen Denkens für sicheres Design unterstützt. Das Kapitel enthält eine Zusammenfassung der späteren Kapitel und der Techniken, die zur Erstellung der Artefakte verwendet werden. Vielleicht möchtest du eine Kopie des Diagramms der Artefaktabhängigkeit erstellen, um es an deine Wand zu pinnen und als Eingabeaufforderung in deinem Projekt zu verwenden.

In Kapitel 2 nehmen wir uns etwas Zeit, um darüber nachzudenken, wie sich architektonisches Denken in den Entwicklungszyklus einfügt. Oft wird vom Design Thinking zur Softwareentwicklung übergegangen, ohne dass die Architektur berücksichtigt wird, was zu Problemen führt, wenn später größere architektonische Änderungen erforderlich sind. Wir werden auch über den Unterschied zwischen Unternehmens- und Lösungsarchitektur sprechen, da dies oft verwechselt wird. Diese Themen helfen dabei, den Kontext für das folgende Kapitel zu schaffen, in dem wir uns auf die Reise durch das Artefakt-Abhängigkeitsdiagramm begeben.

Weitere Lektüre

Wir erörtern eine umfassende Methode für die Integration von Sicherheit in ein Informationssystem. Ein Verständnis für andere Themen wie Cloud-Sicherheit, Softwarearchitektur, Cybersicherheitsarchitektur und Unternehmenssicherheitsarchitektur ist dabei von Vorteil.

Anstatt dies am Ende des Buches zu verstecken, solltest du vielleicht einige dieser anderen Bücher und Online-Quellen zu Rate ziehen, während du unsere Diskussion über architektonisches Denken für sicheres Design liest.

Für Cloud-Sicherheitstechnologie, die mehrere Cloud-Provider umfasst, ist Practical Cloud Security (O'Reilly) von Chris Dotson ein guter Ausgangspunkt. Es gibt viele weitere Quellen im Internet und in Büchern, die sich auf bestimmte Cloud-Provider konzentrieren.

Für die Architektur von Cybersicherheitslösungen empfehlen wir das Buch Practical Cybersecurity Architecture (Packt Publishing) von Ed Moyle und Diana Kelley.

Wenn du mehr über Softwarearchitekturmethoden erfahren möchtest, empfehlen wir dir drei weitere Quellen. Practical Software Architecture (IBM Press) von Tilak Mitra beschreibt eine Methode, die bei IBM weit verbreitet ist und sich auf die On-Premises-Architektur für Unternehmenssysteme konzentriert. Für Softwareentwicklung mit einem technischen Ansatz empfehlen wir die Lektüre von Fundamentals of Software Architecture (O'Reilly) von Mark Richards und Neal Ford. Außerdem erwähnen wir an mehreren Stellen das C4-Modell von Simon Brown, das einen einfachen Ansatz zur Visualisierung der Softwarearchitektur bietet.

Für Unternehmens- und Lösungsarchitekturen beschreibt Enterprise Security Architecture (CRC Press) von John Sherwood, Andrew Clark und David Lynas die sechsschichtige Sicherheitsarchitektur, die als Sherwood Applied Business Security Architecture (SABSA) bekannt ist. Darauf wird auch an anderen Stellen verwiesen, unter anderem bei The Open Group. Von der Open Group gibt es die Open Enterprise Security Architecture (O-ESA), die einen Rahmen für dieSicherheitsarchitektur von Unternehmen bietet.

Im Laufe des Buches werden wir dir zusätzliche Lektüre empfehlen.

Übungen

1. Welches sind die grundlegenden Sicherheitstechniken, die in der in diesem Buch beschriebenen Methode verwendet werden? Wähle alle aus, die zutreffen.

   1. Sicherheit durch Design mit Bedrohungsmodellierung

   2. Zero-Trust-Architektur

   3. Vertrauliche Datenverarbeitung

   4. Compliance Management

   5. Datenzentrierte Sicherheit

2. Was sind die Merkmale von "Secure by Design"? Wähle alles aus, was zutrifft.

   1. Dazu gehört auch die Modellierung von Bedrohungen.

   2. Sie geht dem architektonischen Denken voraus.

   3. Sie ist auf die Gestaltung von Technologieprodukten ausgerichtet.

   4. Sie skaliert, um ein System von Systemen zu entwerfen.

3. Was sind die Merkmale einer Zero-Trust-Architektur? Wähle alles aus, was zutrifft.

   1. "Vertraue nie, überprüfe immer."

   2. Es geht nur um Netzwerksicherheit.

   3. Identität ist die neue Grenze.

   4. Es ist ein Produkt oder eine Lösung.

4. Welche dieser Architektenrollen wird speziell in einer agilen oder DevOps-Entwicklungsumgebung eingesetzt?

   1. Architekt für Unternehmenssicherheit

   2. Anwendungsarchitekt

   3. Meister der Sicherheit

   4. Beratender Sicherheitsarchitekt

5. Welcher der Artefaktabschnitte unterstützt die Gesamtentwicklung der Architektur in allen Phasen der Entwicklung?

   1. Anforderungen

   2. Architektur

   3. Betrieb

   4. Governance

   5. Versicherung

6. Das Artefakt-Abhängigkeitsdiagramm enthält welche der folgenden Arten von Artefakten? Wähle alle zutreffenden aus.

   1. Diagramme

   2. Ereignisprotokolle

   3. Automatisierung

   4. Tische

7. Welche der folgenden Aussagen ist richtig?

   1. Die Zerlegung der Lösungsarchitektur umfasst die Unternehmensarchitektur, die Komponentenarchitektur und die Einsatzarchitektur.

   2. Die Zerlegung der Lösungsarchitektur umfasst die Architekturübersicht, die Komponentenarchitektur und die Einsatzarchitektur.

   3. Die Zerlegung der Lösungsarchitektur umfasst den Systemkontext, die Komponentenarchitektur und die Einsatzarchitektur.

   4. Die Zerlegung der Lösungsarchitektur umfasst den Systemkontext, die Komponentenarchitektur und das Datenflussdiagramm.