Datensouveränität und Sicherheit: Warum sensible Daten nicht in die öffentliche Cloud gehören

• Bewertung der Datensensibilität
• Datensouveränität und Jurisdiktion
• Datenklassifizierung und Risikoverteilung
• Cloud-Servicemodelle und Verteilung der Verantwortung
• Regulatorische Anforderungen
• On-Premises-Infrastruktur
• Hybridmodell
• Zertifizierungen und Auditberichte
• Wie Sie sich entscheiden

Bewertung der Datensensibilität

Bei der Bewertung der Datensensibilität reicht es nicht aus, lediglich den Inhalt zu betrachten, da auch die Folgen eines potenziellen Sicherheitsvorfalls eine wesentliche Rolle spielen. Fertigungsunterlagen können einen entscheidenden Wettbewerbsvorteil darstellen, während die Nichtverfügbarkeit einer Betriebsdatenbank die Produktion selbst ohne eine einzige kompromittierte Datei lahmlegen kann. Zur Bewertung gehören daher mögliche finanzielle Schäden, die Auswirkungen auf die Kunden sowie der Zeitraum, den ein Unternehmen auf das betreffende System verzichten kann.

Wenn eine öffentliche Cloud ordnungsgemäß konzipiert und konfiguriert ist, kann sie das gleiche oder sogar ein höheres Schutzniveau bieten als die eigene Infrastruktur. Große Anbieter investieren erhebliche Mittel in die Absicherung von Rechenzentren, in Monitoring und die Abwehr groß angelegter Angriffe. Ein Unternehmen ersetzt jedoch einen Teil der direkten Kontrolle durch ein Vertragsverhältnis, sodass es genau verstehen muss, was der Anbieter tatsächlich garantiert und welche Sicherheitsbereiche in der Verantwortung des Kunden verbleiben.

Datensouveränität und Jurisdiktion

Datensouveränität beginnt mit der Kontrolle über den gesamten Lebenszyklus der Daten. Die Datenresidenz beschreibt, in welchem Land oder in welcher Region sich die primäre Datenbank befindet. Datensouveränität reicht weiter und umfasst sowohl die rechtliche als auch die technische Kontrolle über Informationen – von ihrer Entstehung bis zu ihrer endgültigen Löschung. Ein europäisches Rechenzentrum ist ein wichtiger Parameter, verrät für sich allein jedoch nicht, von wo aus der technische Support arbeitet oder wo Sicherheitskopien erstellt werden.

Ein Teil der Informationen kann die gewählte Region verlassen, ohne dass es sich dabei um den eigentlichen Inhalt von Dokumenten oder Datenbanken handelt. Diagnoseprotokolle, Benutzerkennungen und Betriebsmetadaten können sensible Details über interne Systeme preisgeben. Vor Vertragsunterzeichnung muss daher geklärt werden, wie der Dienst auch mit diesen Nebendaten umgeht und welche Subunternehmer an der Verarbeitung beteiligt sind.

Rechtliche Anforderungen können nicht nur vom Standort des Rechenzentrums abhängen, sondern auch vom Hauptsitz des Anbieters und der eingebundenen Subunternehmer. Bei sensiblen Daten ist es zudem wesentlich, ob der Fernzugriff eines Support-Mitarbeiters vorab genehmigt und im Nachhinein nachvollzogen werden kann. Wenn ein Anbieter seine Administratorzugriffe oder die gesamte Kette von Subunternehmern nicht darlegen kann, kann ein Unternehmen nur schwer nachweisen, dass es das Risiko im Griff hat.

Verwaltung von Verschlüsselungsschlüsseln

Einer der wesentlichen Parameter der Datensouveränität ist das Schlüsselmanagement, mit dem verschlüsselte Daten gesperrt und wieder freigegeben werden. Vereinfacht gesagt funktionieren sie wie der Schlüssel zu einem Tresor: Wer sie besitzt, kann Daten entschlüsseln oder den Zugriff darauf sperren. Werden die Schlüssel ausschließlich vom Cloud-Anbieter generiert und verwahrt, verlässt sich das Unternehmen vollkommen auf dessen Prozesse und Berechtigungen. Manche Dienste ermöglichen es daher einer Organisation, ihre Schlüssel selbst zu verwalten und bei Bedarf für ungültig zu erklären. Doch auch diese Lösung garantiert nicht automatisch, dass der Anbieter niemals mit Daten in unverschlüsselter Form arbeitet, da die Informationen während der eigentlichen Verarbeitung innerhalb der Cloud-Infrastruktur temporär entschlüsselt werden können. Entscheidend ist daher die gesamte Architektur des Dienstes und nicht allein der Speicherort der Schlüssel.

Datenklassifizierung und Risikoverteilung

Über die geeignete Umgebung entscheidet das Ausmaß der Folgen eines Vorfalls. Eine einheitliche Cloud-Strategie für alle Unternehmenssysteme mag administrativ bequem sein, entspricht jedoch oft nicht dem tatsächlichen Risiko. Öffentliche Marketingunterlagen erfordern nicht denselben Schutz wie Patientendaten, Quellcodes oder Konstruktionsunterlagen für ein neues Produkt. Das höchste Maß an Isolation ist für Daten sinnvoll, deren Verlust einen schweren und nur schwer wiedergutzumachenden Schaden verursachen würde.

Das Risiko beschränkt sich nicht nur auf Datenlecks, da auch eine unbefugte Manipulation schwerwiegende Konsequenzen haben kann. Ein verfälschtes Laborergebnis, ein geänderter Fertigungsparameter oder ein manipulierter Finanzeintrag kann größeren Schaden anrichten als deren Veröffentlichung. Bei operativen Systemen entscheidet die Verfügbarkeit, da ein mehrstündiger Ausfall mehr kosten kann als die gesamte Infrastruktur.

Eine sorgfältige Datenklassifizierung hilft zudem dabei, das Budget anhand des tatsächlichen Risikos zu verteilen. Ein Unternehmen muss nicht für jede Anwendung die teuerste Umgebung aufbauen, sondern kann Investitionen auf wenige kritische Systeme konzentrieren. Weniger sensible Dienste können weiterhin die Flexibilität der öffentlichen Cloud nutzen, ohne dass die wertvollsten Unternehmenswerte automatisch dorthin verlagert werden.

Cloud-Servicemodelle und Verteilung der Verantwortung

Die Verteilung der Sicherheitsverpflichtungen ist nicht bei jeder Cloud gleich:

• Bei Infrastructure as a Service, also IaaS, verwaltet der Anbieter das Rechenzentrum, die physischen Server und die Virtualisierungsebene. Der Kunde ist in der Regel für das Betriebssystem, dessen Updates, die Anwendungen und die Konfiguration der Netzwerkregeln verantwortlich.
• Bei Platform as a Service, bezeichnet als PaaS, übernimmt der Anbieter zusätzlich die Verwaltung der Betriebsumgebung.
• SaaS verschiebt diese Grenze noch weiter, da der Anbieter die gesamte Anwendung betreibt.

Die unterschiedliche Verteilung der Verantwortung zeigt sich am deutlichsten beim Auftreten und bei der Untersuchung eines Sicherheitsvorfalls. Für die unbeabsichtigte Freigabe eines Speichers genügt eine einzige Fehlkonfiguration seitens des Kunden, obwohl die Plattform selbst wie vorgesehen funktioniert. Ein Angreifer kann den robusten Schutz des Rechenzentrums auch über ein kompromittiertes Administratorkonto umgehen. Bei jedem Dienst muss daher eindeutig geregelt sein, welche Kontrollen der Anbieter durchführt und was das interne Sicherheitsteam regelmäßig überprüfen muss.

Regulatorische Anforderungen

DSGVO

Regulierung verwandelt eine technische Entscheidung in ein Risiko für die Unternehmensführung. Aus Sicht der DSGVO ist nicht der eigentliche Speicherort personenbezogener Daten auf einem eigenen Server oder in der öffentlichen Cloud ausschlaggebend, sondern ein Schutzniveau, das dem Risiko der jeweiligen Verarbeitung angemessen ist. Die Organisation muss einen geeigneten Auftragsverarbeiter auswählen und angemessene technische sowie organisatorische Maßnahmen treffen. Bei Übermittlungen außerhalb des Europäischen Wirtschaftsraums bedarf es zudem einer gültigen Rechtsgrundlage sowie einer Prüfung des tatsächlichen Schutzniveaus.

Die Höhe der Höchststrafe bedeutet nicht, dass jedes fehlerhaft konfigurierte Cloud-Projekt automatisch mit Bußgeldern in dreistelliger Millionenhöhe endet. Dennoch macht sie deutlich, dass die Abhängigkeit von einem externen Dienstleister zu den Themen gehört, die auch der Geschäftsführung stets präsent sein müssen. Bei der Auswahl einer Lösung müssen Vertragsbedingungen, Notfallpläne und die Fähigkeit zum Anbieterwechsel sorgfältig geprüft werden.

DORA für den Finanzsektor

Für den Finanzsektor bringt die seit dem 17. Januar 2025 geltende DORA-Verordnung eine weitere Ebene von Anforderungen mit sich. Sie konzentriert sich auf die digitale operationale Stabilität und die Risiken im Zusammenhang mit Drittanbietern von Informations- und Kommunikationstechnologien. Eine Bank, Versicherung oder eine andere regulierte Institution muss daher auch die Konzentration kritischer Prozesse bei einem einzelnen Partner und die Auswirkungen eines möglichen Ausfalls im Blick behalten.

On-Premises-Infrastruktur

Eine On-Premises-Infrastruktur wird in den Räumlichkeiten des Unternehmens oder in Einrichtungen betrieben, die sich unter direkter Kontrolle der Organisation befinden. Das Sicherheitsteam kann Netzwerksegmente präzise abgrenzen, Fernzugriffe einschränken und Änderungen unabhängig von den Möglichkeiten eines öffentlichen Dienstes steuern. Dieses Modell bietet den größten Mehrwert dort, wo ein Unternehmen betriebliche Unabhängigkeit benötigt oder hochsensible Daten in einer isolierten Umgebung vorhalten muss.

Mit einem höheren Maß an Kontrolle geht die Verantwortung für den gesamten Lebenszyklus der eigenen Infrastruktur einher. In das Budget fließen nicht nur die Anschaffungskosten für Server und Speichersysteme ein, sondern auch deren regelmäßige Erneuerung, der Energieverbrauch und Wartungsverträge. Ein wesentlicher Kostenfaktor ist das Fachpersonal, das die Infrastruktur kontinuierlich aktualisiert, überwacht und im Ernstfall nach einem Vorfall wiederherstellen kann.

Die bloße Unterbringung eines Servers im eigenen Haus garantiert noch keine höhere Sicherheit, wenn Administration und Zugriffskontrollen vernachlässigt werden. Veraltete Systeme oder zu weitreichende Administratorrechte können ein konzentriertes Sicherheitsrisiko darstellen. On-Premises ist dann sinnvoll, wenn das Unternehmen eine professionelle Verwaltung gewährleisten kann und über ausreichende Kapazitäten für Ausfälle sowie kurzzeitige Lastspitzen verfügt.

Backups und Wiederherstellung des Betriebs

Die Widerstandsfähigkeit der eigenen Umgebung gegen Ransomware wird durch unveränderliche oder Offline-Backups erheblich gesteigert, auf die ein kompromittiertes Konto keinen Zugriff hat. Angreifer versuchen nämlich häufig, sowohl die Produktionsdaten als auch die regulär angebundenen Backups zu löschen. Ein derart isoliertes Backup kann darüber entscheiden, ob das Unternehmen den Betrieb aus eigener Kraft wiederherstellen kann oder den Forderungen der Angreifer ausgeliefert bleibt.

Eine verlässliche Wiederherstellung lässt sich nicht allein durch die bloße Existenz einer Sicherungskopie belegen, da Probleme meist erst beim tatsächlichen Wiederherstellungsvorgang zutage treten. Eine Organisation muss regelmäßig prüfen, ob die Daten lesbar sind und ob sich daraus die kritischen Systeme innerhalb der geforderten Zeit wieder in Betrieb nehmen lassen. Ein regelmäßiger Test kann beschädigte Backups, fehlende Systemabhängigkeiten oder Verfahren, die sich in der Praxis als zu langsam erweisen, rechtzeitig aufdecken.

Hybridmodell

Die Kombination mehrerer Umgebungen stellt für viele Unternehmen einen praktischen Weg dar, um die Kontrolle über sensible Daten mit der Flexibilität von Cloud-Diensten in Einklang zu bringen. Eine kritische Datenbank oder das Identitätsmanagementsystem kann in der eigenen Infrastruktur verbleiben, während die öffentliche Cloud die Kunden-Website, Analyseaufgaben oder temporäre Lastspitzen abdeckt. Eine Private Cloud bietet darüber hinaus Automatisierung und eine flexiblere Ressourcenzuweisung in einer dedizierten Umgebung.

Der Nutzen eines Hybridmodells hängt davon ab, ob die Architektur den beabsichtigten Informationsfluss auch tatsächlich einhält. Eine in der Cloud betriebene Anwendung könnte regelmäßig die interne Datenbank kopieren und somit die ursprüngliche Sicherheitsabsicht untergraben. Das Konzept muss daher vorab festlegen, welche Daten das Unternehmensnetzwerk verlassen dürfen, ob sie vor der Übertragung gefiltert werden müssen und wie jeder Zugriff protokolliert wird.

Mit der Verteilung der Systeme auf mehrere Umgebungen steigen auch die Anforderungen an eine einheitliche Verwaltung und Sicherheitsüberwachung. Das Team benötigt eine zentrale Übersicht über Anmeldungen und verdächtige Ereignisse auf beiden Seiten. Ohne diesen ganzheitlichen Blick bleibt ein Teil eines Angriffs womöglich nur in der Cloud sichtbar und ein anderer innerhalb des Unternehmensnetzwerks, sodass die Zusammenhänge nicht rechtzeitig erkannt werden.

Zertifizierungen und Auditberichte

Sicherheitszertifizierungen und Auditberichte erleichtern die Überprüfung eines Anbieters, ihr Name allein gibt jedoch noch keinen Aufschluss darüber, was tatsächlich geprüft wurde. Ein Zertifikat bezieht sich mitunter lediglich auf ein bestimmtes Rechenzentrum, eine Niederlassung oder einen Teilbereich eines Dienstes. Ein Unternehmen muss daher den genauen Geltungsbereich des Audits anfordern und prüfen, ob dieser sowohl das Produkt als auch die Region abdeckt, die genutzt werden sollen.

Eine andere Art von Nachweis stellt der SOC 2-Bericht dar, der auf einer unabhängigen Bewertung ausgewählter Sicherheits- und Betriebskontrollen einer Organisation basiert. Bei der Auswertung ist es wichtig zu prüfen, ob es sich um einen Typ-I-Bericht handelt, der die Konzeption der Kontrollen zu einem bestimmten Stichtag bewertet, oder um einen Typ-II-Bericht, der deren Wirksamkeit über einen längeren Zeitraum hinweg untersucht. In der Automobilindustrie kann zudem TISAX relevant sein – ein branchenspezifischer Mechanismus zur Bewertung und zum Austausch von Ergebnissen aus Informationssicherheitsaudits zwischen Herstellern, Zulieferern und weiteren Partnern. Seine Aussagekraft hängt vom konkreten Prüfungsumfang und dem zugewiesenen TISAX-Label ab.

Jedes Marketingversprechen bezüglich einer Zertifizierung muss durch ein gültiges Dokument und einen präzise abgegrenzten Geltungsbereich gestützt sein. Die Verwendung eines zertifizierten Kryptomoduls bedeutet nicht automatisch die Zertifizierung des gesamten Produkts, und die Zertifikate eines Anbieters decken nicht zwingend alle angebotenen Dienste ab. Eindeutige Formulierungen schützen den Kunden vor Fehlentscheidungen und den Anbieter vor Versprechen, die er nicht belegen kann.

Sechs Fragen, die vor einer Entscheidung stehen sollten

• Welcher Schaden entsteht durch ein Leck, eine Manipulation oder eine längere Nichtverfügbarkeit der Daten?
• Wo befinden sich die Primärdaten, Backups und Betriebsmetadaten?
• Wer kann technisch auf die Daten zugreifen und wer verwaltet die Verschlüsselungsschlüssel?
• Welche Subunternehmer sind an der Bereitstellung des Dienstes beteiligt?
• Wie schnell lässt sich das System wiederherstellen oder zu einem anderen Anbieter migrieren?
• Kann das Unternehmen seine Entscheidung gegenüber der Geschäftsführung, Kunden oder Regulierungsbehörden belegen?

Wie Sie sich entscheiden

Wenn ein Unternehmen auf eine der genannten Fragen keine eindeutige Antwort hat, ergibt sich daraus eine konkrete Aufgabe für den Vertrag, die technische Architektur oder interne Prozesse. Die öffentliche Cloud muss damit noch nicht automatisch ausgeschlossen sein, offene Punkte müssen jedoch vor der Migration geklärt werden. Eine nachträgliche Änderung der Verschlüsselung, des Exportformats oder des Datenstandorts ist in der Regel erheblich teurer als ein von Beginn an sauber konzipiertes Projekt.

Sensible Daten erfordern eine Umgebung, die den potenziellen Folgen eines Sicherheitsvorfalls angemessen ist. Die öffentliche Cloud kann ein hohes Maß an Sicherheit und betrieblicher Flexibilität bieten, das Unternehmen muss jedoch die Grenzen seiner Kontrolle und die genaue Aufteilung der Verantwortlichkeiten kennen. On-Premises und das Hybridmodell haben ihren größten Wert dort, wo betriebliche Unabhängigkeit, gesetzliche Vorgaben oder die Kosten eines Datenverlusts die Vorteile einer schnellen Bereitstellung überwiegen.

Die Wahl zwischen Public Cloud, On-Premises-Infrastruktur und einem Hybridmodell ist keine Frage technischer Trends, sondern eine direkte Folge davon, wie ein Unternehmen die Auswirkungen eines potenziellen Vorfalls bewertet. Die entscheidenden Variablen bleiben stets dieselben: Wer die Verschlüsselungsschlüssel verwaltet, unter welche Jurisdiktion die Daten fallen, wie der Vertrag dies regelt und was bei einem Ausfall oder einem Anbieterwechsel geschieht. Eine solide aufgebaute Architektur muss weder die teuerste noch die komplizierteste sein – sie muss jedoch dem tatsächlichen Risiko entsprechen und nicht bloß der betrieblichen Bequemlichkeit. Die teuersten Anpassungen sind immer jene, um die sich ein Unternehmen erst nach der Migration kümmern muss.

Peter Vnuk

Technologien sind für mich sowohl Beruf als auch Hobby – am meisten beschäftige ich mich mit Smartphones, Notebooks, Audiotechnik, künstlicher Intelligenz und allem, was hi-tech ist. Ich rezensiere gerne Neuheiten, verfolge futuristische Trends und versuche, die zukünftige Entwicklung von Technologien abzuschätzen. Science-Fiction und Visionen zukünftiger Welten faszinieren mich – sie sind oft auch eine Inspiration für reale technologische Fortschritte. Beruflich beschäftige ich mich zudem mit Videospielen und der Gaming-Branche. Und wenn ich mal nicht arbeite, entspanne ich gerne bei einem guten Spiel, einem qualitativ hochwertigen Bier oder beim Erstellen von Tech-Memes auf Facebook.