Zum Inhalt springen
Beta

Sicherheit und Compliance

In 1 Trail

Zuletzt aktualisiert am

Sicherheit und Compliance definieren die Leitplanken für Migrationsentscheidungen in Design, Landing Zones und Umsetzung.

Ziel ist es, Vorgaben in technisch erzwungene Kontrollen und kontinuierlich erzeugbare Nachweise zu übersetzen.

Nutzen Sie diese semantische Karte als strukturierten Einstieg in alle Themen dieses Moduls.

Seitlich wischen, um das ganze Diagramm zu sehen
Sicherheit und Compliance Wählen Sie einen Themencluster und springen Sie direkt zur passenden Unterseite. Sicherheit und ComplianceWählen Sie einen Themencluster und springen Sie direkt zur passenden Unterseite.Steuerung und MigrationsbetriebsmodellBetriebsmodell und SteuerungBetriebsmodell und SteuerungRollen, Prüfpunkte, Verantwortung und EntscheidungenÜbergang in die CloudÜbergang in die CloudKontrollübersetzung und neue VerantwortungenSicherheitsarchitektur und Design-BasisArchitekturmusterArchitekturmusterBoundary-zentriert und Zero Trust kombiniertSicherheitsgrundsätzeSicherheitsgrundsätzeVerbindliche Basiskontrollen je BereichCompliance-Nachweise und SouveränitätKontrollen und NachweiseKontrollen und NachweisePräventive, detektive Kontrollen und EvidenzSouveränität und CSF-AbgleichSouveränität und CSF-AbgleichCSF-Abgleich, ES3 und PrüfbarkeitZero-Trust-VertiefungFünf Fokusbereiche für Umsetzung und Kontrollen.Zero Trust für MenschenZero Trust für MenschenIdentitätslebenszyklus, privilegierte Zugriffe, HygieneZero Trust für GeräteZero Trust für GeräteGerätezustand, Endpunkt-Härtung, sichere AdministrationZero Trust für NetzeZero Trust für NetzeSegmentierung, Verkehrsrichtlinien, KonnektivitätZero Trust für WorkloadsZero Trust für WorkloadsLaufzeit-Härtung, Least Privilege, IsolationZero Trust für DatenZero Trust für DatenKlassifizierung, Verschlüsselung, Schlüssel, Aufbewahrung

Sicherheit und Compliance sind kein später Härtungsschritt, sondern prägen Architekturentscheidungen von Beginn an:

  • Architektur zuerst: Vertrauensgrenzen, Modell für das Netzwerk und Identitätskontrollen lassen sich spät nur mit hohem Aufwand nachziehen.
  • Kontinuierliche Lieferung: Fehlende Pflichtkontrollen blockieren Freigaben und verlangsamen Migrationswellen.
  • Nachweise von Anfang an: Compliance-Nachweise müssen laufend erzeugt und dürfen nicht spät rekonstruiert werden.
  • Gemeinsame Verantwortung: Jeder Design-Strang braucht die Sicht von Sicherheit und Compliance.

Wie das Modul Design und Landing Zones unterstützt

Abschnitt betitelt „Wie das Modul Design und Landing Zones unterstützt“
  • Design-Perspektive: Architektur, Prinzipien für Kontrollen und Governance-Modell definieren.
  • Landing-Zone-Perspektive: Prinzipien in Platform- und Application-Landing-Zones umsetzen.

Dieses Modul bildet die verbindliche Grundlage für beide Kontexte.

  • Von statischen Grenzen zu dynamischen Bereichen: Projekte und Services verändern sich schneller als klassische Zonen.
  • Von manuellen Freigaben zur Durchsetzung von Richtlinien: Kontrollen müssen automatisierbar und testbar sein.
  • Von isolierten Protokollen zu zusammenführbarer Telemetrie: Audit-, Plattform- und Applikationssignale gehören zusammen.
  • Von Fokus auf Infrastruktur zu gemeinsamen Plattformfähigkeiten: Identität, Schlüssel, Observability und Governance sind Plattformfähigkeiten.
  • Architektur mit Fokus auf das Netzwerk: Hub-and-Spoke-Routing, zentrale Firewalls und Segmentierung.
  • Zero-Trust-orientierte Architektur: Explizite Identität, starke Authentifizierung, Ende-zu-Ende-Verschlüsselung und Least Privilege.

In der Praxis braucht der Zielzustand oft beide Ansätze mit klaren Kriterien für den Einsatz je Workload-Klasse.

In vielen Programmen sind Regelkonformität (Compliance) und digitale Souveränität zentrale Treiber der Migration:

  • Rechtliche und Residency-Anforderungen: Region- und Entscheidungen zum Daten-Standort beeinflussen Architektur und Kontrollen.
  • Operative Souveränitätsziele: Governance, Portabilität und Transparenz reduzieren Abhängigkeitsrisiken.
  • EU Cloud Sovereignty Framework (CSF): Nutzen Sie ein CSF-orientiertes Kontroll- und Mapping-Modell für Nachweise und die Steuerung des Reifegrads.

Compliance bei der Migration: Was bleibt, was ändert sich

Abschnitt betitelt „Compliance bei der Migration: Was bleibt, was ändert sich“

Bei einer Migration von On-Premises in die Cloud bleibt die Compliance-Verpflichtung des Unternehmens inhaltlich bestehen.

Was sich ändert, ist die Art der Umsetzung, der Nachweise und der Betriebsprozesse.

  • Was bleibt gleich: Rechtliche Vorgaben, interne Richtlinien, Prüfbarkeit und Verantwortlichkeit.
  • Was ändert sich: Kontrollen werden stärker automatisiert, Nachweise kontinuierlich erzeugt und Verantwortlichkeiten zwischen Plattform und Teams neu geschnitten.

Typische Compliance-Kategorien in der Migration:

  • Datenschutz und Speicherort von Daten: Anforderungen an Daten, Orte für die Speicherung und klare Grenzen für Zugriffe.
  • Zugriff und Berechtigungen: Prinzipien für Rollen, Trennung von Aufgaben und privilegierte Zugriffe.
  • Protokollierung und Nachweise: Anforderungen an Vollständigkeit, Aufbewahrung und gute Auswertung.
  • Betriebssicherheit und Notfallfähigkeit: Anforderungen an Verfügbarkeit, Wiederherstellung und klare Reaktion im Störfall.
  • Lieferanten und Verträge: Anforderungen an Provider, vertragliche Regeln und überprüfbare Zusicherungen.

Wie STACKIT die Compliance-Erfüllung konkret unterstützt

Abschnitt betitelt „Wie STACKIT die Compliance-Erfüllung konkret unterstützt“
  • Geprüfte Grundlage für Sicherheit: Zertifizierte Rechenzentren und etablierte Sicherheitsstandards schaffen eine belastbare Grundlage für regulatorische Anforderungen.
  • C5 als prüfbarer Nachweis: Das C5-Testat bietet strukturierte Nachweise zu zentralen Bereichen wie Risiko, Betrieb, Zugriff, Verschlüsselung und Umgang mit Vorfällen.
  • Transparenz für Audits: Prüfberichte und dokumentierte Kontrollen unterstützen interne Revision, externe Audits und die eigene Analyse von Risiken.
  • Unterstützung in der Umsetzung: Guidance für Architektur, Rollenmodell und Zuordnung von Kontrollen hilft, Compliance-Anforderungen für den Cloud-Betrieb umzusetzen.
  • Shared Responsibility bleibt zentral: STACKIT stellt Plattformkontrollen und Nachweise bereit, das Unternehmen verantwortet weiterhin Konfiguration, Berechtigungen und die Einordnung von Daten.

Betriebsmodell und Steuerung

Definieren Sie Rollen, Entscheidungsrechte, Verantwortlichkeiten und verbindliche Prüfpunkte für Sicherheit und Compliance.

Modul öffnen

Architekturmuster

Definieren Sie, wo netzwerkzentrierte Kontrollen zwingend sind und wo Zero Trust priorisiert wird.

Modul öffnen

Sicherheitsgrundsätze nach Security by Design

Definieren Sie Basisanforderungen für Identität, Netzwerk, Workloads und Datenschutz.

Modul öffnen

Kontrollen und Nachweise

Definieren Sie präventive und detektive Kontrollen sowie automatisierte Evidenzbereitstellung.

Modul öffnen

Übergang von On-Premises in die Cloud

Klären Sie, welche Sicherheitsannahmen und Betriebspraktiken in der Cloud angepasst werden müssen.

Modul öffnen

Digitale Souveränität und CSF-Abgleich

Übersetzen Sie Souveränitäts- und CSF-Anforderungen in Architektur, Kontrollen und Nachweise.

Modul öffnen