Die Gestaltung robuster Software-Systeme erfordert mehr als nur funktionale Logik; es erfordert eine Grundlage, die auf Sicherheit basiert. Wenn Architekten die Infrastruktur visualisieren, nutzen sie UML-Bereitstellungsdiagramme, um Hardware, Software und Kommunikationspfade darzustellen. Ein Standarddiagramm übersieht jedoch oft die entscheidenden Sicherheitsebenen, die für den Schutz erforderlich sind. Die Integration von Sicherheitsaspekten direkt in das Bereitstellungsmodell stellt sicher, dass Schwachstellen bereits in der Entwurfsphase erkannt werden, anstatt erst in der Produktion.
Diese Anleitung untersucht, wie Sicherheitskontrollen, Vertrauensgrenzen und Compliance-Anforderungen in die UML-Bereitstellungsmodellierung integriert werden können. Indem Sicherheit als gleichberechtigter Bestandteil in architektonischen Diagrammen behandelt wird, können Teams Systeme aufbauen, die von Beginn an widerstandsfähig gegenüber Bedrohungen sind.
🏗️ Verständnis der Bereitstellungslandschaft
Ein UML-Bereitstellungsdiagramm stellt die physische Architektur eines Systems dar. Es zeigt Artefakte, Knoten und die Verbindungen zwischen ihnen. Ohne Sicherheitsanmerkungen bleibt diese Sichtweise rein strukturell. Um sie sicher zu gestalten, muss man die Komponenten verstehen:
- Knoten: Diese stellen physische oder virtuelle Rechenressourcen dar. Es könnten Server, Router oder Cloud-Instanzen sein.
- Artefakte: Dies sind physische Stücke von Informationen, wie ausführbare Code, Datendateien oder Bibliotheken.
- Kommunikationspfade: Die Netzwerkverbindungen, die es Knoten ermöglichen, Daten auszutauschen.
Beim Modellieren dieser Elemente muss Sicherheitskontext auf jeden Knoten angewendet werden. Ein generischer Serverknoten ist nicht ausreichend. Das Modell sollte zwischen einem öffentlich zugänglichen Webserver und einem internen Datenbankserver unterscheiden. Der Unterschied liegt in der erforderlichen Sicherheitsposition für jeden.
🔒 Sichern von Knoten und Hardware
Knoten sind die physischen oder virtuellen Endpunkte, an denen Software ausgeführt wird. In einem sicherheitsorientierten Modell erfordert jeder Knoten spezifische Attribute hinsichtlich seiner Verstärkung und Zugriffssteuerung.
Physische und logische Knoten
Bereitstellungsmodelle verwechseln physische Hardware oft mit logischen Instanzen. Die Sicherheitsmodellierung muss diese trennen:
- Physische Knoten: Diese stellen tatsächlich vorhandene Hardware wie Server oder IoT-Geräte dar. Sicherheitsaspekte umfassen physische Zugriffssteuerung, Manipulationsschutz und Umweltkontrollen.
- Logische Knoten: Diese stellen virtuelle Maschinen, Container oder Cloud-Funktionen dar. Hier liegen die Sicherheitsaspekte auf Isolation, Hypervisor-Sicherheit und Laufzeitumgebungen.
Hardware-Sicherheitsmodule (HSM)
Kritische Systeme verlassen sich oft auf spezialisierte Hardware für kryptografische Operationen. In dem Diagramm sollten diese explizit als dedizierte Knoten modelliert werden. Dies verdeutlicht, dass die Schlüsselverwaltung nicht im Software-Speicher stattfindet, sondern in einer sicheren Hardware-Grenze.
Status der Serververstärkung
Jeder Serverknoten sollte Metadaten zu seiner Sicherheitskonfiguration tragen. Dazu gehören:
- Betriebssystemversion und Patches.
- Aktive Firewall-Regeln auf dem Knoten.
- Status von Antivirus- oder Endpunkt-Schutz.
- Aktivierte Protokollierungsfunktionen für Audit-Logs.
Durch die Anmerkung dieser Details können Architekten sicherstellen, dass kein Knoten in der endgültigen Infrastruktur unpatched oder unüberwacht bleibt.
💾 Schutz von Artefakten und Datenspeichern
Artifakte sind die Dateien und Komponenten, die auf Knoten bereitgestellt werden. Nicht alle Artefakte haben dasselbe Risikoprofil. Einige enthalten sensible Daten, während andere öffentliche Bibliotheken sind. Bei der Sicherheitsmodellierung ist eine Unterscheidung dieser Artefakte anhand ihrer Sensibilität und Integritätsanforderungen erforderlich.
Dateneinstufung
Datenbanken innerhalb des Bereitstellungsmodells müssen entsprechend den Einstufungsstufen gekennzeichnet werden. Häufige Kategorien sind:
- Öffentlich: Keine Sicherheitsmaßnahmen außer der Verfügbarkeit.
- Intern: Nur innerhalb des Organisationsnetzwerks zugänglich.
- Vertraulich: Erfordert Verschlüsselung und strenge Zugriffssteuerung.
- Eingeschränkt: Sehr sensible Daten, die regulatorischen Anforderungen unterliegen.
Verschlüsselung im Ruhezustand
Beim Modellieren von Datenbanken sollte die Darstellung angeben, ob die Daten im gespeicherten Zustand verschlüsselt sind. Dies ist entscheidend für die Einhaltung von Vorschriften und den Datenschutz. Wenn ein Knoten eingeschränkte Daten enthält, sollte die Artefakt-Speicherung mit einem Verschlüsselungssymbol oder einer Notiz versehen werden.
Berücksichtigen Sie die folgenden Szenarien:
- Datenbank-Server: Sollte Voll-Datenträger-Verschlüsselung oder Spalten-Ebene-Verschlüsselung für sensible Felder anzeigen.
- Dateiserver: Kann Verschlüsselung für bestimmte Dokumenttypen erfordern.
- Cache-Server: Enthält häufig Sitzungstoken; erfordert strenge Speicherisolation.
Integrität der Artefakte
Es ist entscheidend sicherzustellen, dass der bereitgestellte Code nicht manipuliert wurde. Bereitstellungsmodelle sollten Mechanismen zur Überprüfung der Artefakte widerspiegeln, wie beispielsweise digitale Signaturen oder Prüfsummen. Dadurch wird sichergestellt, dass nur vertrauenswürdige Software auf den Knoten ausgeführt wird.
🔗 Sichern von Kommunikationspfaden
Die Verbindungen zwischen Knoten sind oft die schwächste Stelle in einem System. Daten, die diese Pfade durchlaufen, sind anfällig für Abhörung, Manipulation oder Dienstverweigerung. Das Bereitstellungsdiagramm muss die für die Kommunikation verwendeten Sicherheitsprotokolle explizit definieren.
Protokollspezifikation
Generische Linien zwischen Knoten sind mehrdeutig. Jede Verbindung sollte das Protokoll und die Sicherheitsebene angeben:
- HTTPS/TLS: Erforderlich für Webverkehr und API-Aufrufe.
- SSH: Für sichere remote Administration.
- IPSec: Für Site-to-Site-Tunneling.
- Unverschlüsseltes TCP: Sollte vermieden werden und im Fall der Unvermeidbarkeit als Risiko hervorgehoben werden.
Portverwaltung
Offene Ports auf einem Knoten definieren seine Angriffsfläche. In der Darstellung sollten Administratoren dokumentieren, welche Ports externen Netzwerken gegenüber offenstehen im Vergleich zu internen Netzwerken. Dies hilft dabei, unnötige Expositionen zu identifizieren.
Wichtige Überlegungen beinhalten:
- Eingangs-Ports: Wo tritt der Datenverkehr in den Knoten ein?
- Ausgangs-Ports: Wo verlässt der Datenverkehr den Knoten?
- Verwaltungs-Ports:Ports, die zur Verwaltung verwendet werden, sollten niemals dem öffentlichen Internet ausgesetzt werden.
Bandbreite und Rate Limiting
Sicherheit beinhaltet auch Verfügbarkeit. Denial-of-Service-Angriffe zielen auf Kommunikationspfade ab. Das Modell sollte Rate-Limiting-Richtlinien berücksichtigen. Obwohl dies nicht immer als Diagrammelement dargestellt wird, sollte die Architektur Lastverteilungseinheiten oder Firewalls berücksichtigen, die Datenfluten abmildern.
🛡️ Definition von Vertrauensgrenzen und Zonen
Vertrauensgrenzen sind entscheidend bei der Modellierung von Bereitstellungen. Sie definieren, wo Vertrauen endet und Überprüfung beginnt. Das Überschreiten einer Vertrauensgrenze erfordert Authentifizierung und Autorisierung. Die Visualisierung dieser Zonen hilft den Stakeholdern zu verstehen, wo Sicherheitsprüfungen stattfinden.
Netzwerksegmentierung
Knoten sollten in logische Sicherheitszonen gruppiert werden:
- DMZ (Demilitarisierte Zone):Dienste mit öffentlichem Zugang, die von internen Ressourcen isoliert sind.
- Internes Netzwerk:Vertrauenswürdige Infrastruktur für die zentrale Geschäftslogik.
- Verwaltungsnetzwerk:Dediziertes Netzwerk für administrative Aufgaben, getrennt vom Nutzerverkehr.
- Quarantänezone:Für Systeme, die aufgrund von Sicherheitsrisiken isoliert werden müssen.
Vertrauensstufen
Jede Zone repräsentiert eine unterschiedliche Vertrauensstufe. Daten, die von einer Zone mit geringem Vertrauen in eine Zone mit hohem Vertrauen gelangen, müssen einer strengen Prüfung unterzogen werden. Das Bereitstellungsdiagramm sollte den Datenfluss über diese Grenzen hinweg und die beteiligten Sicherheitsgates darstellen.
Firewall-Regeln
Firewalls sind die Durchsetzungsstellen für diese Zonen. Im Modell sollten Firewalls als Knoten oder Gateways zwischen Zonen dargestellt werden. Regeln sollten zusammengefasst werden, um anzuzeigen, welcher Datenverkehr zulässig ist.
| Zone | Vertrauensniveau | Zugriffssteuerung | Verschlüsselung erforderlich |
|---|---|---|---|
| Öffentliches Internet | Nicht vertrauenswürdig | Nur Whitelist | Ja (TLS 1.2+) |
| DMZ | Niedrig | Eingeschränkter Eingang | Ja |
| Internes Netzwerk | Mittel | Rollenbasiert | Optional (intern) |
| Verwaltungszone | Hoch | MFA erforderlich | Ja (Stark) |
🆔 Modellierung von Authentifizierung und Autorisierung
Sicherheit geht nicht nur um die Hardware; es geht darum, wer und was auf die Ressourcen zugreifen kann. Authentifizierung (wer Sie sind) und Autorisierung (was Sie tun können) müssen zusammen mit der Infrastruktur modelliert werden.
Identitätsanbieter
Eine zentralisierte Identitätsverwaltung sollte dargestellt werden. Wenn das System einen bestimmten Identitätsanbieter für die Authentifizierung verwendet, sollte dieser Knoten mit allen abhängigen Diensten verknüpft werden. Dies zeigt die Abhängigkeit und möglichen Einzelpunkt des Ausfalls auf.
Authentifizierungsmechanismen
Jeder Knoten oder Dienst sollte die Authentifizierungsmethode angeben, die er unterstützt:
- Einmalige Anmeldung (SSO): Für an Benutzer gerichtete Anwendungen.
- API-Schlüssel: Für die Kommunikation zwischen Diensten.
- Zertifikate: Für die Kommunikation zwischen Maschinen.
- OAuth/OIDC: Für die delegierte Autorisierung.
Autorisierungsrichtlinien
Die Autorisierungslogik sollte in den Notizen zum Bereitstellungsmodell dokumentiert werden. Zum Beispiel könnte ein Datenbankknoten Lesezugriff vom Anwendungsserver zulassen, aber Schreibzugriff verweigern. Diese Berechtigungen definieren die Sicherheit des Datenflusses.
⚖️ Compliance- und Vorschriftenabdeckung
Viele Branchen arbeiten unter strengen regulatorischen Rahmenbedingungen. Bereitstellungsdiagramme müssen diese Anforderungen widerspiegeln, um rechtliche Compliance zu gewährleisten. Die Nichtberücksichtigung von Compliance kann zu architektonischem Verschuldung und rechtlichen Strafen führen.
Wichtige Vorschriften
Je nach Branche gelten bestimmte Standards:
- DSGVO: Erfordert den Schutz von Daten und die Möglichkeit zur Löschung von Daten innerhalb der Infrastruktur.
- HIPAA: Fordert strenge Kontrollen über den Zugriff auf Gesundheitsdaten und deren Speicherung.
- PCI-DSS: Regelt, wie Zahlungskarten-Daten behandelt und gespeichert werden.
- SOC 2: Fokussiert sich auf Sicherheit, Verfügbarkeit und Verarbeitungsintegrität.
Datenspeicherung
Einige Vorschriften verlangen, dass Daten innerhalb bestimmter geografischer Grenzen verbleiben müssen. Das Bereitstellungsmodell sollte die physische Lage der Knoten angeben. Dadurch wird sichergestellt, dass Daten keine Grenzen überschreiten, was gegen lokale Gesetze verstieße.
Audit-Protokolle
Compliance erfordert oft das Protokollieren. Das Diagramm sollte zeigen, wo Protokolle erzeugt und wo sie gespeichert werden. Protokollspeicherknoten müssen von den Betriebsknoten getrennt sein, um Manipulationen zu verhindern.
🐛 Schwachstellenidentifikation in Diagrammen
Ein gut strukturiertes Bereitstellungsdiagramm kann als Werkzeug zur Schwachstellenidentifikation dienen. Durch die Visualisierung des Systems können Architekten Schwachstellen erkennen, bevor der Code geschrieben wird.
Einzelne Ausfallpunkte
Wenn ein kritischer Knoten keine Sicherung oder Redundanz hat, stellt er ein Risiko dar. Das Diagramm sollte Hochverfügbarkeitskonfigurationen hervorheben. Clustering und Lastverteilung sollten sichtbar sein, um Resilienz zu zeigen.
Offenliegende Verwaltungschnittstellen
Verwaltungschnittstellen (wie SSH oder RDP) sind häufige Einstiegsstellen für Angreifer. Wenn diese im Diagramm gegenüber dem Internet offenliegen, ist dies ein rotes Flag. Sie sollten über einen Bastion-Host oder Sprungknoten geleitet werden.
Unverschlüsselte Kanäle
Jede Linie im Diagramm ohne Verschlüsselungsangabe stellt ein potenzielles Risiko dar. Sicherheitsüberprüfungen sollten sich auf diese Linien konzentrieren und Verschlüsselungs-Upgrades verlangen.
🧠 Integration von Bedrohungsmodellierung
Die Modellierung der Bereitstellung ist eine Voraussetzung für die formale Bedrohungsmodellierung. Sobald die Infrastruktur abgebildet ist, können Teams Methoden wie STRIDE anwenden, um Bedrohungen zu identifizieren, die spezifisch für die Architektur sind.
Bedrohungs-Kategorien
Weisen Sie die folgenden Bedrohungen den Diagrammelementen zu:
- Fälschung: Kann ein Angreifer eine Instanz oder einen Benutzer vortäuschen?
- Manipulation: Kann Daten im Transit oder im Ruhezustand verändert werden?
- Verweigerung: Können Benutzer durchgeführte Aktionen bestreiten?
- Informationsexposition: Wird vertrauliche Daten in Protokollen oder im Speicher offengelegt?
- Verweigerung des Dienstes: Kann das System überlastet werden?
- Privilegien-Erhöhung: Kann ein Benutzer höheren Zugriff erlangen, als ihm gewährt wurde?
Analyse des Datenflusses
Verfolgen Sie den Datenfluss im Diagramm. Wo entsteht vertrauliche Daten? Wo endet sie? An welchen Stellen wird sie verändert? Jeder Veränderungspunkt ist ein potenzielles Sicherheitsrisiko.
🔄 Aufrechterhaltung der Sicherheitsintegrität
Ein Bereitstellungsdiagramm ist kein statisches Dokument. Die Infrastruktur ändert sich, Patches werden angewendet und neue Dienste werden hinzugefügt. Das Modell muss sich weiterentwickeln, um die Sicherheitsintegrität aufrechtzuerhalten.
Versionskontrolle
Bereitstellungsmodelle sollten zusammen mit dem Codebase versioniert werden. Dadurch können Teams Architekturänderungen im Zeitverlauf vergleichen und Sicherheitsupdates überprüfen.
Automatisierte Überprüfung
Moderne Werkzeuge können das Diagramm anhand von Sicherheitsrichtlinien überprüfen. Wenn ein neuer Knoten ohne Verschlüsselung hinzugefügt wird, sollte das Werkzeug dies markieren. Dadurch wird sichergestellt, dass das Modell genau und sicher bleibt.
Regelmäßige Audits
Regelmäßige Überprüfungen des Bereitstellungsmodells sind notwendig. Sicherheitsteams sollten prüfen, ob die physische Infrastruktur dem logischen Modell entspricht. Abweichungen zwischen beiden erzeugen Sicherheitslücken.
📝 Zusammenfassung der Best Practices
Die Integration von Sicherheit in die UML-Bereitstellungsmodellierung ist eine strategische Notwendigkeit. Sie verlagert Sicherheit von einer reaktiven Prüfung hin zu einem proaktiven Gestaltungselement. Durch die Einhaltung dieser Richtlinien können Teams Architekturen schaffen, die von Grund auf sicher sind.
Wichtige Erkenntnisse für die Umsetzung sind:
- Knoten annotieren: Definieren Sie den Sicherheitsstatus für jeden Server und jedes Gerät.
- Pfade beschriften: Legen Sie Protokolle und Verschlüsselung auf allen Verbindungen fest.
- Zonen definieren: Markieren Sie vertrauenswürdige Grenzen und Segmentierung deutlich.
- Authentifizierung modellieren: Zeigen Sie, wie Identität und Zugriff verwaltet werden.
- Compliance abbilden: Stellen Sie sicher, dass regulatorische Anforderungen sichtbar sind.
- Regelmäßig aktualisieren: Halten Sie das Diagramm mit der Umgebung synchron.
Sicherheit ist ein kontinuierlicher Prozess. Das Bereitstellungsdiagramm ist die Karte für diese Reise. Eine klare, genaue und sicherheitsorientierte Karte stellt sicher, dass die Reise von Anfang bis Ende sicher bleibt.
