Für Healthtech-Unternehmen kann ein einziger fehlender Nachweis einen Deal zunichtemachen. Krankenhausverbünde, Krankenkassen und Großkunden verlangen SOC 2, bevor sie überhaupt mit der Sicherheitsprüfung eines Anbieters beginnen – kein Bericht, kein Vertrag. In genau dieser Lage befand sich ein schnell wachsendes Healthtech-Unternehmen: ein starkes Produkt, echte Nachfrage bei den Kunden, aber eine Compliance-Lücke, die zwischen ihnen und ihrer nächsten großen Partnerschaft stand.
Herausforderung
Das Unternehmen hatte bereits ein funktionierendes Produkt auf AWS und einen wachsenden Kundenstamm aufgebaut, aber die Software war von Anfang an nicht auf Compliance ausgelegt. Protokollierung, Zugriffskontrollen, Verschlüsselungspraktiken und das Lieferantenmanagement waren organisch gewachsen, um Funktionen schnell bereitzustellen – nicht um einen Auditor zufriedenzustellen. Das Unternehmen war bereit, Großkunden anzugehen, aber SOC 2 erwies sich immer wieder als Blockade, noch bevor diese Gespräche überhaupt beginnen konnten. Ohne einen vorliegenden Bericht gerieten Sicherheitsüberprüfungen ins Stocken, bevor sie überhaupt anfingen.
Damit standen wir vor einem altbekannten Problem: Compliance nachträglich in ein System einzubauen, das nie dafür konzipiert wurde – und das unter realem Zeitdruck, ohne die restliche Roadmap auszubremsen.
Der Ansatz
Wir haben mit einer Bereitschaftsprüfung begonnen, um zu sehen, wie groß die Lücke zwischen den bestehenden Praktiken und den Kontrollanforderungen von SOC 2 tatsächlich war.
Neben einer Reihe kleinerer Feststellungen brachte die Bereitschaftsprüfung sieben wesentliche Lücken ans Licht, die sofortige Aufmerksamkeit erforderten.
- Logischer Zugriff (CC6.1, Logische Zugriffskontrollen): Alle Umgebungen (Dev, Staging und Produktion) liefen im selben AWS-Konto, ohne jegliche Trennung voneinander.
- IAM-Hygiene (CC6.2 und CC6.3, Bereitstellung von Benutzerzugriffen und Prinzip der geringsten Rechte): Im Laufe der Zeit hatten sich ungenutzte Benutzer und Rollen angesammelt, und die Berechtigungsgrenzen waren nicht klar definiert.
- Verschlüsselung und Sicherungen (CC6.1 und A1.2, Verschlüsselung und Verfügbarkeit/Wiederherstellung): Die Daten waren im Ruhezustand (Data at Rest) verschlüsselt, aber die Wiederherstellung von Sicherungen (Backups) war noch nie tatsächlich getestet worden.
- Infrastruktur als Code / IaC (CC8.1, Änderungsmanagement): IaC war nicht vollständig automatisiert, und die bereitgestellte Infrastruktur wich von dem ab, was der Code tatsächlich beschrieb (Infrastructure Drift).
- Bereitstellungs-Nachvollziehbarkeit / Deployment-Traceability (CC8.1, Änderungsmanagement): Es war nicht immer klar, welche Anwendungsversion in einer bestimmten Umgebung lief, was auf Lücken im Design der CI/CD-Pipeline hinwies.
- Protokollierung und Überwachung (CC7.1 und CC7.2, Systembetrieb): CloudTrail, AWS Config und Security Hub waren in der gesamten Umgebung nicht vollständig konfiguriert.
- Erfassung von Nachweisen / Evidence Gathering (CC4.1, Überwachungsaktivitäten): Es gab keinen durchgängigen Prozess zur Erfassung und Verwaltung der Nachweise, die ein Auditor benötigen würde, um Kontrollen über die Zeit hinweg zu überprüfen.
Die Lösungen
Nachdem wir das Gesamtbild hatten, haben wir in den folgenden Monaten jede Lücke systematisch abgearbeitet.
Logischer Zugriff
Alle drei Umgebungen – Dev, Staging und Produktion – liefen ursprünglich in einem einzigen AWS-Konto ohne echte Trennung voneinander. Das bedeutete, dass eine Fehlkonfiguration oder eine zu weit gefasste Berechtigung in einer Umgebung auf eine andere übergreifen konnte – genau die Art von Risiko, die CC6.1 abfangen soll.
Eine vollständige Trennung war der ideale Zielzustand, aber die Migration der Produktion aus dem Hauptkonto war kein einfaches Unterfangen. Die Produktion umfasste den aktiven EKS-Cluster, RDS-Instanzen und alles, was daran hing. Eine vollständige Konto-Migration für dieses Ökosystem hätte ein reales Risiko dargestellt und Monate gekostet, die wir mit Blick auf den Zeitplan für den Deal nicht hatten. Deshalb haben wir eine pragmatische Entscheidung getroffen: Wir haben Dev und Staging in eigene, separate Konten verschoben. Das hat den Großteil des Risikos einer gegenseitigen Beeinträchtigung zwischen den Testumgebungen und der Produktion beseitigt. Die Produktion blieb für diese Phase im Hauptkonto, ergänzt durch strengere Zugriffskontrollen und eine darüber gelagerte Überwachung als Ausgleich.
Das verschaffte uns schnell eine spürbare Isolierung, ohne unter Zeitdruck eine hochriskante Produktionsmigrations einzugehen.
IAM-Hygiene
Der Zugriff wurde zuvor über einzelne IAM-Benutzer verwaltet. Das bedeutete Zugangsdaten, die regelmäßig ausgetauscht werden mussten, keinen zentralen Ort, um zu sehen, wer worauf Zugriff hatte, und Berechtigungsgrenzen, die im Laufe der Zeit abgewichen waren, wenn Personen hinzukamen, das Unternehmen verließen oder ihre Rollen wechselten. Das stellt eine direkte Lücke hinsichtlich CC6.2 und CC6.3 dar, da es keinen sauberen Weg gab nachzuweisen, dass Zugriffe konsistent bereitgestellt, überprüft oder entzogen wurden.
Wir haben die Benutzerverwaltung auf den IAM Identity Center umgestellt und ihn mit Okta integriert, das der Kunde bereits nutzte. So lag die Identitätsverwaltung an einem zentralen Ort, anstatt über AWS hinweg dupliziert zu werden. Die Bereitstellung und Entziehbarkeit von Benutzern (Provisioning und Deprovisioning) wurden über SCIM zwischen Okta und dem Identity Center automatisiert. Dadurch richtete sich der Zugriff nach dem tatsächlichen Beschäftigungsstatus einer Person, anstatt sich darauf zu verlassen, dass jemand nach dem Ausscheiden daran dachte, einen IAM-Benutzer zu löschen.
Für nicht-menschliche Zugriffe, wie die zuvor für CI/CD genutzten IAM-Benutzer, haben wir Deployments auf eine OIDC-basierte Rollenübernahme (Role Assumption) über GitHub Actions umgestellt. Diese wurden genau auf die minimalen Berechtigungen beschränkt, die jede Pipeline tatsächlich benötigte, anstatt auf breite, langlebige Zugangsdaten zu setzen.
All das – die Konfiguration des Identity Centers, die SCIM-Integration und die OIDC-Rollen – wurde über Terraform definiert und verwaltet. Dadurch wurde das Zugriffsmodell selbst überprüfbar und versionskontrolliert, anstatt manuell in der Konsole konfiguriert zu werden.
Verschlüsselung und Backups
Die Daten waren bereits im Ruhezustand (at rest) verschlüsselt, was einen Teil von CC6.1 abdeckte. Allerdings wurde die Wiederherstellung von Backups noch nie tatsächlich getestet, und es gab kein Multi-Region-Resilienzkonzept, auf das man sich berufen konnte. Ein Auditor möchte nicht nur sehen, dass Backups existieren; er fordert den Nachweis, dass die Wiederherstellung tatsächlich funktioniert und die Daten einen regionalen Ausfall überstehen.
Wir haben Multi-Region-Backups für RDS und DynamoDB aktiviert, sodass sowohl die primären relationalen Daten als auch die NoSQL-Workloads über einen dokumentierten Wiederherstellungspfad außerhalb einer einzelnen AWS-Region verfügten. Darüber hinaus haben wir einen regelmäßig wiederkehrenden Wiederherstellungstest eingerichtet. So wurde die Wiederherstellung wiederholt bewiesen, anstatt nur anzunehmen, dass sie funktioniert, weil ein Backup-Job erfolgreich durchgelaufen ist.
Infrastructure as Code
Für die Produktionsumgebung haben wir die bestehenden Ressourcen direkt in den Terraform-State importiert, anstatt alles von Grund auf neu aufzubauen und Ausfallzeiten oder Konfigurationsabweichungen zu riskieren. Das brachte die Produktion unter IaC-Verwaltung, ohne die Live-Umgebung zu beeinträchtigen, und schloss die Drift-Lücke ohne zusätzliche Migrationsrisiken.
Für Entwicklungs- und Staging-Umgebungen haben wir dieselben Terraform-Module wie für die Produktion verwendet, diese jedoch über Umgebungsvariablen parametrisiert, um die Ressourcen für untere Umgebungen passend zu skalieren. Das bescherte uns eine konsistente, replizierte Infrastruktur über alle drei Umgebungen hinweg aus einer einzigen Codebasis – anstelle von separaten, manuell gepflegten Konfigurationen, die mit der Zeit schleichend voneinander abweichen könnten.
Wir haben IaC-Deployments so automatisiert, dass sie über Pipelines mit Freigabeprozessen (Approvals) ausgeführt werden.
Rückverfolgbarkeit von Deployments
Wir haben ArgoCD eingeführt und GitOps-Praktiken in der gesamten Pipeline verankert, sodass der Soll-Zustand jeder Umgebung in Git lag, anstatt manuell oder inkonsistent angewendet zu werden. Jedes Image wurde beim Build in GitHub mit einer SemVer-Struktur passend zur jeweiligen Umgebung getaggt. Das verschaffte uns eine klare, unveränderliche Verbindung zwischen einem spezifischen Commit, seinem Build-Artefakt und dem, was zu jedem beliebigen Zeitpunkt tatsächlich in einer Umgebung lief.
Zudem ermöglichte uns das ein ordnungsgemäßes Rollback: Um auf einen früheren Zustand zurückzukehren, musste ArgoCD lediglich wieder auf einen früheren Git-Commit verwiesen werden, anstatt ein altes Deployment manuell zu rekonstruieren. In Kombination schloss dies die Lücke bei der Rückverfolgbarkeit und lieferte dem Auditor einen klaren, überprüfbaren Pfad vom Code bis in die Produktion.
Protokollierung und Überwachung
CloudTrail, AWS Config und Security Hub waren über die verschiedenen Umgebungen hinweg nicht vollständig konfiguriert. Das bedeutete eine eingeschränkte Einsicht in Kontoaktivitäten, Konfigurationsänderungen und potenzielle Bedrohungen – eine direkte Lücke im Hinblick auf CC7.1 und CC7.2 für die Systemüberwachung.
Wir haben CloudTrail für alle Konten aktiviert, um eine vollständige Aktivitätsprotokollierung zu gewährleisten, AWS Config eingeschaltet, um Konfigurationsabweichungen (Drift) zu verfolgen und zu melden, und GuardDuty für eine kontinuierliche Bedrohungserkennung bereitgestellt. All diese Daten flossen im Security Hub zusammen, was uns eine zentrale Ansicht aller Ergebnisse und Warnmeldungen über die gesamte Umgebung hinweg verschaffte, anstatt jeden Dienst separat prüfen zu müssen.
Beweiserhebung (Evidence Gathering)
Wir haben Vanta eingebunden, um die automatisierte Beweiserhebung kontinuierlich über AWS, GitHub und Okta hinweg durchzuführen. So wurden Nachweise direkt bei ihrer Entstehung erfasst, anstatt im Nachhinein rekonstruiert zu werden. Das gab uns während des gesamten Beobachtungszeitraums einen Echtzeit-Einblick in den Compliance-Status und bedeutete, dass wir mit bereits geordneten Nachweisen in das Audit gingen, anstatt sie unter Zeitdruck zusammenzusuchen.
Ergebnisse und Vorteile
In den ersten zwei bis drei Monaten haben wir die sieben wesentlichen Lücken geschlossen und die zugrunde liegende Infrastruktur neu aufgebaut. Von da an ging das Unternehmen in einen sechsmonatigen Beobachtungszeitraum über. In dieser Phase liefen Überwachung, Incident Response, Zugriffsüberprüfungen und Beweiserhebung kontinuierlich ab und wurden als Nachweis dafür dokumentiert, dass die Kontrollen im Zeitverlauf effektiv funktionierten und nicht nur auf dem Papier existierten.
Am Ende dieses Zeitfensters bestand das Unternehmen sein SOC 2 Type II-Audit – etwa neun Monate nach Beginn der Bereitschaftsprüfung (Readiness Assessment). Was zuvor ein Hindernis war, das dem Unternehmen bei Verträgen mit Großkunden im Weg stand, wurde zu einem Nachweis, der Sicherheitsprüfungen vorantrieb, anstatt sie ins Stocken geraten zu lassen.