GitLab Dedicated: Compliance für eine neue regulatorische Ära

Durchsetzungsmaßnahmen wie NIS2 sind keine Frage künftiger Planung mehr: Der NIS360-Bericht der Agentur der Europäischen Union für Cybersicherheit (ENISA) bestätigt, dass Aufsichtsbehörden die Cybersicherheitsreife in kritischen Sektoren bereits aktiv bewerten. Die Behörde bewegt sich von Beratung und Orientierungshilfe hin zu aktiver Aufsicht, Prüfung und Rechenschaftspflicht. Das ist das regulatorische Umfeld, in dem europäische Unternehmen heute agieren.

Multi-Tenant-Cloud-Plattformen reduzieren den Betriebsaufwand, platzieren Quellcode und Pipelines aber auf gemeinsam genutzter Infrastruktur, die Regulierungsbehörden inzwischen genau prüfen. Self-Managed-Lösungen bieten Isolation, verlagern die Verantwortung für Update-Zyklen, Sicherheitspatches und Disaster-Recovery-Tests (DR-Tests) aber auf ein bereits ausgelastetes Platform-Team. Beide Bereitstellungsoptionen lassen Lücken beim Risikomanagement, bei der Datenhoheit und bei der Bereitstellung von Audit-Nachweisen.

Dieser Beitrag zeigt, wie GitLab Dedicated (eine vollständig isolierte Single-Tenant-SaaS-Lösung, bereitgestellt in der bevorzugten AWS-Region und von GitLab gehostet und verwaltet) diese Herausforderungen löst und dabei hilft, mit sich entwickelnden Compliance-Anforderungen Schritt zu halten.

"NatWest Group führt GitLab Dedicated SaaS ein, damit unsere Ingenieurinnen und Ingenieure eine gemeinsame Cloud-Engineering-Plattform nutzen können. So liefern wir neue Ergebnisse für Kund(inn)en und Kolleg(inn)en – schnell, häufig und sicher. Dazu gehören hochwertige automatisierte Tests, bedarfsgerechte Infrastruktur und ein durchgehend automatisierter Deployment-Prozess."

– Adam Leggett, Platform Lead for Engineering Platforms, NatWest Group

Regulierung treibt Veränderung voran

In der Europäischen Union treiben zentrale Regulierungen die Notwendigkeit eines anderen Plattformansatzes voran. Diese Regulierungen laufen an einer Entscheidung zusammen, die die meisten Unternehmen bereits vor deren Einführung getroffen haben: die Plattform, auf der ihre Entwickler(innen) aufbauen. Diese Entscheidung trägt heute Audit-Konsequenzen, die es vorher nicht gab.

1. Digital Operational Resilience Act (DORA), seit Januar 2025 EU-weit im Finanzsektor in Kraft, verpflichtet Finanzinstitute, kritische Technologie widerstandsfähig zu halten, übermäßige Abhängigkeit von einzelnen Anbietern zu vermeiden und die Meldung von Vorfällen zu stärken.
2. NIS2-Richtlinie, verabschiedet im Dezember 2022, verpflichtet wesentliche und wichtige Sektoren, Cybersicherheit zu stärken, Technologie-Lieferketten abzusichern und bedeutende Vorfälle EU-weit rasch an die zuständigen Behörden zu melden.
3. Datenschutz-Grundverordnung (DSGVO), anwendbar seit Mai 2018, verpflichtet Organisationen, personenbezogene Daten zu schützen, Speicherort und Zugriffsberechtigte zu dokumentieren und für jede Nutzung eine gültige Rechtsgrundlage sicherzustellen.

Gemeinsam genutzte Infrastruktur und operatives Risiko

Auf Multi-Tenant-Plattformen bedeuten gemeinsam genutzte Ausführung, Runner und Storage, dass eine einzelne CVE oder Fehlkonfiguration mehrere Tenants gleichzeitig betreffen kann. Bei Self-Managed-Deployments konzentriert sich das Risiko intern: Secrets und Zugangsdaten sammeln sich an und werden nicht regelmäßig rotiert, während manuelle, durch Vorfälle ausgelöste Änderungen zu Abweichungen von Infrastructure-as-Code-Baselines führen und die tatsächliche Angriffsfläche vor Audits verschleiern.

GitLab Dedicated kodifiziert den Betrieb

Site Reliability Engineers (SREs) verwalten die GitLab-Dedicated-Instanz in einem isolierten AWS-Konto, standardmäßig ohne direkten Zugriff auf Kundenumgebungen. Alle betrieblichen Änderungen laufen über automatisierte, freigabegesteuerte Workflows innerhalb einer definierten Control Plane, nicht durch direkten Eingriff ins laufende System. CI/CD-Variablen und Runner-Token lassen sich in einem selbst festgelegten Rhythmus rotieren, was Konfigurationsabweichungen reduziert und die operative Angriffsfläche durch kodifizierte Prozesse eng unter Kontrolle hält.

Disaster Recovery ist für jede GitLab-Dedicated-Instanz standardmäßig eingebaut. Jede Dedicated-Kundeninstanz verfügt über eine sekundäre Region, die ein Backup vorhält. Gehostete Runner lassen sich ebenfalls in der Region der Instanz betreiben. GitLab Geo sorgt für asynchrone, kontinuierliche Replikation zwischen den beiden Standorten. Die Deployment-Architektur zielt darauf ab, die Auswirkungen regionaler Cloud-Ausfälle zu minimieren und die Geschäftskontinuität für unsere Kund(inn)en aufrechtzuerhalten. GitLab Dedicated bietet Disaster Recovery mit folgenden Recovery-Objectives:

• Recovery Time Objective (RTO). Der Service wird innerhalb von acht Stunden oder weniger in der sekundären Region wiederhergestellt.
• Recovery Point Objective (RPO). Der Datenverlust ist auf maximal vier Stunden der jüngsten Änderungen begrenzt, abhängig davon, wann der Störfall relativ zum letzten Backup eintritt.

Datenhoheit und kundengesteuerte Sicherheit

Für DSGVO und Datenhoheit brauchen Auditor(inn)en Klarheit: Datenstandort, Zugriffsverantwortung und ob Runner-Traffic genehmigte Regionen verlässt. Bei Multi-Tenant-Plattformen kontrolliert der Anbieter diese Punkte, und Daten können Grenzen überschreiten. Bei Self-Managed-Deployments müssen Storage-Richtlinien, Schlüsselverwaltung und Netzwerk-Routing selbst definiert werden, damit alles innerhalb der gewählten Region bleibt.

GitLab Dedicated bringt Isolation mit Kontrolle

Die Regionswahl bei der Bereitstellung bindet Object Storage, Artefakte und Compute-Daten an die gewählte AWS-Region. Zusätzlich wird eine sekundäre Failover-Region gewählt, sodass die einzige regionsübergreifende Bewegung die explizit aktivierte Replikation zwischen diesen beiden Regionen ist. Kund(inn)en in der Europäischen Union können beide Regionen innerhalb der eigenen Jurisdiktion halten. GitLab steuert das Failover anhand festgelegter RTO- und RPO-Ziele.

Bring-your-own-key (BYOK) stellt kundenverwaltete Schlüssel bereit, sodass GitLab bei einem Widerruf des Schlüssels nicht auf verschlüsselte Daten zugreifen kann. AWS PrivateLink erstellt einen VPC-Endpunkt im eigenen Konto. Der Traffic zwischen dem eigenen Netzwerk, CI/CD-Jobs und GitLab Dedicated bleibt auf dem privaten Backbone von AWS.

Eine Einschränkung gilt für alle großen Cloud-Anbieter gleichermaßen und lässt sich auf der Infrastrukturebene nicht lösen: Als US-Unternehmen unterliegt Amazon Web Services weiterhin US-Recht, einschließlich des Clarifying Lawful Overseas Use of Data (CLOUD) Act, der die Herausgabe von Daten erzwingen kann, unabhängig davon, wo Server physisch stehen.

BYOK beseitigt das Risiko auf GitLab-Ebene, da GitLab keine Schlüssel besitzt und die Kundendaten nicht entschlüsseln kann. Das ändert aber nichts an den Pflichten von AWS nach US-Recht. Organisationen mit strengen Anforderungen an die Jurisdiktion sollten dem verbleibenden Risiko zusätzlich zu den Infrastrukturkontrollen mit rechtlichen und vertraglichen Mechanismen begegnen: Auftragsverarbeitungsverträgen, Transfer Impact Assessments und dokumentierter Rechtsgrundlage für Datenübermittlungen.

Lücken bei Audit-Nachweisen

Bei Multi-Tenant-SaaS liegen Logs und Vorfallsdaten auf gemeinsam genutzter Infrastruktur, weshalb Auditor(inn)en für mandantenspezifische Nachweise auf die Hilfe des Anbieters angewiesen sind. Bei Self-Managed-Deployments liegt das Hauptrisiko für Audits in CVE-Exposition durch verzögerte Upgrades. Ein Rückstand bei Releases belässt bekannte Schwachstellen in der Umgebung, in der der Quellcode liegt – gegenüber Auditor(inn)en schwerer zu rechtfertigen als einfache Kapazitätsengpässe.

GitLab Dedicated vereinfacht die Compliance

Die SREs von GitLab Dedicated halten die Instanz nach einem vordefinierten monatlichen Upgrade-Rhythmus aktuell, ohne dass ein Ticket im Backlog des eigenen Platform-Teams entsteht. Die Instanz läuft auf dem N-1-Minor-Release und erhält jeden Monat ein Minor- und zwei Patch-Releases innerhalb eines festen wöchentlichen Wartungsfensters, mit Notfallwartung außerhalb dieses Fensters für S1-Sicherheitsprobleme.

Über das Self-Service-Portal GitLab Trust Center lassen sich die aktuellsten Compliance-Unterlagen und Assurance-Artefakte zu GitLab Dedicated abrufen, zum Beispiel der aktuelle DORA-Prüfbericht von Schellman. Dank vorgefertigter Prüfberichte und zentral gepflegter Nachweise müssen Compliance- und Sicherheitsteams nicht mehr für jede regulatorische Einreichung oder jährliche Prüfung jahrelange Self-Managed-Konfigurationshistorien zusammensetzen oder Daten aus gemeinsam genutzten Aufzeichnungen extrahieren. Das schafft einen wiederholbaren Weg zur Audit-Bereitschaft bei minimalem Betriebsaufwand.

Dieser interaktive Demo-Durchlauf zeigt, wie GitLab die Verwaltung und den Betrieb einer Dedicated-Instanz vereinfacht.

Der Umstieg auf GitLab Dedicated

Ein Umstieg auf GitLab Dedicated bringt mehr Auswahl und mehr Kontrolle durch ein sicheres, compliance-konformes Single-Tenant-SaaS. Infrastruktur-Patching, Verfügbarkeitsnachweise und DR-Tests wandern in den Audit-Bereich von GitLab, sodass das eigene Team die Anwendungsebene dokumentiert und belegt, statt für jede Einreichung Infrastruktur-Nachweise neu aufzubauen.

Jetzt eine Demo buchen, um zu erfahren, wie GitLab Dedicated die eigenen Sicherheits- und Compliance-Anforderungen erfüllen kann.