Kein Schutzwall ist undurchdringlich. Entscheidend ist deshalb, was nach einem erfolgreichen Eindringen passiert: Wer Daten nur verschlüsselt vorfindet, kann sie nicht ohne Weiteres verwerten. Ende-zu-Ende-Verschlüsselung, ein vom Anbieter getrenntes Schlüsselmanagement und präzise Zugriffsrechte machen Datensouveränität damit zu einem zentralen Baustein der Cyberresilienz.

Illustration Absmeier foto ki designer

Bild: Mehrschichtige Sicherheitsarchitektur schützt verschlüsselte Cloud-Daten auch bei erfolgreichen Angriffsversuchen.

Management Summary

Cyberresilienz beginnt nach dem Durchbruch: Unternehmen müssen nicht nur Angriffe abwehren, sondern auch deren Auswirkungen technisch begrenzen.
Verschlüsselung braucht klare Schlüsselhoheit: Entscheidend ist, ob ausschließlich autorisierte Kundenseiten die Inhalte entschlüsseln können.
Der Datenstandort allein reicht nicht: Rechtsraum, Anbieterzugriff, Subdienstleister und Herausgabepflichten gehören gemeinsam in die Risikobewertung.
Berechtigungen bestimmen den Schadensradius: Least Privilege, kurze Freigabezeiten und ein schneller Rechteentzug reduzieren die Folgen kompromittierter Konten.
Nutzbarkeit ist ein Sicherheitsfaktor: Sichere Zusammenarbeit muss einfach genug sein, um Schatten-IT und unkontrollierte Datenwege zu vermeiden.

Auch gute Sicherheitskonzepte können nicht ausschließen, dass Angreifer eine Schutzbarriere überwinden. Für Unternehmen und Organisationen stellt sich deshalb eine zentrale Frage. Wie lässt sich die Kontrolle über sensible Daten auch dann bewahren, wenn ein Cyberangriff erfolgreich ist? Genau hier treffen Cyberresilienz und Datensouveränität aufeinander. Denn ein erfolgreicher Zugriff auf ein System sollte und muss nicht automatisch bedeuten, dass Angreifer auch die darin enthaltenen Informationen lesen können.

Cyberresilienz ist schon lange nicht mehr nur ein Sicherheitsthema, sondern auch regulatorisch relevant. Im ENISA Threat Landscape (ETL) unterstreicht die EU-Agentur für Cybersicherheit, dass Unternehmen neben der Prävention auch die Auswirkungen erfolgreicher Angriffe begrenzen und ihre Resilienz stärken sollten.[1] Auch NIS-2 folgt diesem Gedanken. Das BSI-Gesetz verpflichtet die erfassten Einrichtungen dazu, geeignete Maßnahmen zu ergreifen, um Sicherheitsvorfälle zu vermeiden und gleichzeitig ihre Auswirkungen so gering wie möglich zu halten.[2][3]

Diese Resilienzanforderung ist eng mit Datensouveränität verknüpft. Denn wie widerstandsfähig ein Unternehmen im Umgang mit seinen sensiblen Daten ist, hängt auch davon ab, wie viel Kontrolle es über deren Verarbeitung und Zugriff behält. Wie weit diese Kontrolle reicht, bestimmt wesentlich die Sicherheitsarchitektur der eingesetzten Cloud-Lösung.

Was kann ein Angreifer bei einem erfolgreichen Zugriff lesen?

Cloudbasierte Lösungen laufen häufig auf der Infrastruktur internationaler Hyperscaler. Für viele Unternehmen ist das wirtschaftlich und technisch sinnvoll, wirft mit Blick auf die Datenkontrolle aber zusätzliche Fragen auf. Denn auch in ausgelagerten, globalen Cloud-Umgebungen sollten Unternehmen nachvollziehen können, wie ihre Daten geschützt und verarbeitet werden und wer darauf zugreifen kann. Regulatorische Vorgaben können dies verlangen – unabhängig davon ist diese Transparenz eine wichtige Voraussetzung, um Risiken und Datenkontrolle selbst beurteilen zu können. Dafür ist zunächst wichtig, in welcher Form die eingesetzten Lösungen Informationen in der Cloud verschlüsseln und verarbeiten und wer sie entschlüsseln kann.

Bei einer serverseitigen Verschlüsselung werden Daten erst durch den Cloud-Anbieter verschlüsselt, nachdem sie in dessen Cloud-Umgebung übertragen wurden. Bei einer Ende-zu-Ende-Verschlüsselung erfolgt die Verschlüsselung dagegen clientseitig auf dem Endgerät der jeweiligen Nutzer. Die Daten bleiben dadurch während der Speicherung und Übertragung durchgängig verschlüsselt und können erst auf einem autorisierten Endgerät wieder entschlüsselt werden.

Wer kann die Daten entschlüsseln?

Neben der Art der Verschlüsselung ist für die Datenkontrolle relevant, wer über die für die Entschlüsselung notwendigen kryptografischen Schlüssel verfügt. Darüber entscheidet das Schlüsselmanagement. Dabei ist zu unterscheiden, welche Nutzer zum Entschlüsseln berechtigt sind und wer technisch grundsätzlich dazu in der Lage ist. Bei vielen Cloud-Diensten hat auch der Anbieter technisch die Möglichkeit, auf Klartextdaten zuzugreifen, etwa weil er die entsprechenden Schlüssel verwaltet oder Daten innerhalb der Infrastruktur verarbeitet. Dies ist z. B. bei Architekturen der Fall, in denen Funktionen wie Suche oder Vorschau einen serverseitigen Zugriff auf Klartextdaten erfordern. Damit besteht eine zusätzliche Zugriffsebene außerhalb der unmittelbaren Kontrolle des Anwenderunternehmens. Für Datensouveränität ist somit auch relevant, ob ein Cloud-Anbieter technisch vom Zugriff auf sensible Informationen ausgeschlossen werden kann. Bei einer Zero-Knowledge-Architektur verfügt der Anbieter im regulären Betrieb nicht über die kryptografischen Schlüssel, die für die Entschlüsselung von Kundendaten erforderlich sind und kann Inhalte daher nicht im Klartext einsehen.

Das Zusammenspiel aus Ende-zu-Ende-Verschlüsselung und Zero Knowledge verankert damit einen wesentlichen Teil der Datensouveränität technisch in der Cloud-Lösung und schützt sensible Inhalte auch dann, wenn ein Angreifer Zugriff auf gespeicherte Dateien und Daten während der Übertragung oder Teile der zugrunde liegenden Infrastruktur erlangen. Ohne die zugehörigen Schlüssel erhalten sie lediglich verschlüsselte Daten statt lesbarer Inhalte.

Was kann ein Cloud-Anbieter bei einer rechtlichen Herausgabepflicht offenlegen?

Eine weitere Ebene von Datensouveränität betrifft den Umgang mit rechtlichen Herausgabepflichten. Auch hier setzt die Architektur einer Cloud-Lösung technische Grenzen dafür, auf welche Inhalte ein Anbieter im Ernstfall überhaupt zugreifen oder sie offenlegen kann.

Das bekannteste Beispiel ist der US CLOUD Act. Er kann Anbieter, die der US-Gerichtsbarkeit unterliegen, unter bestimmten Voraussetzungen zur Herausgabe von Daten verpflichten, auch wenn diese in Europa gespeichert sind.[4] Vergleichbare gesetzliche Instrumente gibt es auch in anderen Staaten, etwa den Investigatory Powers Act in Großbritannien[5] oder den Telecommunications and Other Legislation Amendment (Assistance and Access) Act in Australien[6]. Für Unternehmen bedeutet dies, dass ein europäischer Datenstandort allein noch keine Datensouveränität schafft. Vor allem zwei Fragen sind in diesem Kontext relevant. Welchem Rechtsraum unterliegt ein Anbieter und welche Daten kann er im Fall eines Herausgabeverlangens überhaupt im Klartext bereitstellen?

Wie begrenzen klar definierte Zugriffsrechte Risiken im Arbeitsalltag?

Risiken für die Datenkontrolle entstehen nicht nur extern. Auch im Arbeitsalltag müssen Unternehmen klar steuern können, wer auf welche Informationen zugreifen darf. Eingesetzte Cloud-Lösungen sollten diese Berechtigungen präzise abbilden. Denn vergebene Rechte sind nicht statisch. Projekte starten und enden, Verantwortlichkeiten verschieben sich, externe Partner kommen hinzu, Mitarbeitende wechseln ihre Rolle oder verlassen das Unternehmen.

Diese Veränderungen müssen sich auch bei der Vergabe von Zugriffsrechten jederzeit spiegeln lassen. Nutzerinnen und Nutzer sollten nur auf die Informationen zugreifen können, die sie für ihre jeweilige Aufgabe benötigen. Ändern sich Rollen oder Zuständigkeiten, müssen sich Berechtigungen feingranular vergeben, anpassen oder entziehen lassen.

Dieser Aspekt hat auch eine Sicherheitsdimension. Wird ein Benutzerkonto oder ein entsperrtes Endgerät kompromittiert, bestimmen die vergebenen Rechte mit darüber, auf welche Daten ein Angreifer zugreifen kann. Lassen sich Berechtigungen kurzfristig entziehen, können Unternehmen weitere Zugriffe unterbinden und den möglichen Schaden begrenzen.

Wie lässt sich Datensouveränität in der Zusammenarbeit einfach umsetzen?

Nicht zuletzt hängt Datensouveränität auch davon ab, ob sich Sicherheitsvorgaben in der täglichen Zusammenarbeit einfach einhalten lassen. Sind Abläufe zu umständlich, weichen Nutzerinnen und Nutzer eventuell auf private Postfächer, offene Freigabelinks oder nicht freigegebene Anwendungen aus. Damit verlagern sich sensible Daten schnell in eine Schatten-IT, in der Verschlüsselung und Zugriffsregeln nicht mehr greifen. Zu komplizierte Sicherheitsprozesse können damit selbst zum Sicherheitsrisiko werden.

Für mittelständische Unternehmen ist deshalb besonders wichtig, ob sich eine Cloud-Lösung ohne zusätzliche Infrastruktur, aufwendige Anpassungen oder eigens dafür benötigte IT-Spezialisten in bestehende Abläufe integrieren lässt. Dann ist Datensouveränität auch mit begrenzten IT-Ressourcen umsetzbar.

Datensouveränität stärkt Cyberresilienz

Cyberresilienz entsteht nicht allein durch die Abwehr von Angriffen. Sie wird auch durch Datensouveränität gestärkt. Denn diese trägt dazu bei, dass Unternehmen die Kontrolle über sensible Daten selbst im Angriffsfall bewahren. Ist diese Kontrolle bereits technisch in der Architektur einer Cloud-Lösung verankert und einfach nutzbar, lässt sich Datensouveränität unabhängig von Unternehmensgröße und auch mit begrenzten IT-Ressourcen unkompliziert umsetzen und so die Cyberresilienz stärken.

Oliver Jäger, Chief Commercial Officer bei Tresorit

infografik (c) ki designer

Praxistipps für mehr Datensouveränität und Cyberresilienz

Daten klassifizieren: Erfassen Sie zunächst, welche Daten im Unternehmen verarbeitet werden, welchen Schutzbedarf sie haben und welchen gesetzlichen oder vertraglichen Vorgaben sie unterliegen. Definieren Sie für jede Datenklasse verbindliche Regeln für Speicherung, Übertragung, Freigabe, Aufbewahrung und Löschung. Praxisbeispiel: Ein Maschinenbauer teilt seine Informationen in öffentlich, intern, vertraulich und streng vertraulich ein. Konstruktionspläne dürfen ausschließlich verschlüsselt in einem freigegebenen europäischen Cloud-Bereich gespeichert und nur mit namentlich benannten Projektmitgliedern geteilt werden.
Schlüsselmodell prüfen: Dokumentieren Sie lückenlos, wer kryptografische Schlüssel erzeugt, speichert, verteilt, rotiert, sperrt und wiederherstellt. Klären Sie außerdem, ob der Cloud-Anbieter technisch auf die Schlüssel zugreifen kann und wie bei Personalwechseln oder einem Notfall verfahren wird. Praxisbeispiel: Ein Finanzdienstleister verwaltet die Hauptschlüssel in einem eigenen Hardware-Sicherheitsmodul. Schlüssel werden turnusmäßig rotiert; ein Vier-Augen-Verfahren regelt Wiederherstellung und Notfallzugriff.
Anbieterzugriff hinterfragen: Prüfen Sie technisch und vertraglich, ob Beschäftigte des Providers, Supportteams oder Subdienstleister Klartextdaten einsehen können. Verlangen Sie nachvollziehbare Angaben zu privilegierten Zugriffen, Protokollierung, Freigabeverfahren und Benachrichtigungspflichten. Praxisbeispiel: Vor Vertragsabschluss lässt sich ein Unternehmen bestätigen, dass Supportzugriffe nur nach Freigabe, zeitlich begrenzt und vollständig protokolliert erfolgen. Die Sicherheitsabteilung kontrolliert die Zugriffsprotokolle quartalsweise.
Ende-zu-Ende-Verschlüsselung priorisieren: Verschlüsseln Sie besonders schützenswerte Inhalte bereits auf dem Endgerät, sodass sie während Übertragung und Speicherung nicht im Klartext beim Anbieter vorliegen. Prüfen Sie, welche Funktionen dadurch eingeschränkt werden können, etwa serverseitige Suche, Vorschau oder gemeinsame Bearbeitung. Praxisbeispiel: Eine Kanzlei verschlüsselt Mandantenakten vor dem Upload. Nur die zuständigen Anwältinnen und Anwälte besitzen die Berechtigung zur Entschlüsselung; allgemeine Administratoren können die Inhalte nicht lesen.
Least Privilege umsetzen: Vergeben Sie Zugriffsrechte ausschließlich nach Aufgabe und Rolle, begrenzen Sie Sonderrechte zeitlich und überprüfen Sie Berechtigungen regelmäßig.[8] Vermeiden Sie Sammelkonten und entfernen Sie nicht mehr benötigte Rechte unmittelbar. Praxisbeispiel: Ein externer Berater erhält für vier Wochen Zugriff auf einen einzelnen Projektordner. Nach Ablauf endet die Berechtigung automatisch; ein Datenexport und die Weitergabe von Freigabelinks sind deaktiviert.
Notfallentzug testen: Legen Sie fest, wie kompromittierte Konten, aktive Sitzungen, Freigabelinks, API-Token und registrierte Geräte kurzfristig gesperrt werden. Testen Sie den Ablauf regelmäßig und messen Sie, wie lange die vollständige Sperrung tatsächlich dauert. Praxisbeispiel: In einer vierteljährlichen Übung meldet die Personalabteilung den Verlust eines Dienstgeräts. Das Sicherheitsteam sperrt das Konto, beendet Sitzungen, widerruft Links und entzieht dem Gerät innerhalb von 15 Minuten den Zugriff.
Cloud-Nachweise auswerten: Fordern Sie aktuelle C5-Testate, Auditberichte und Informationen zu Subdienstleistern an.[7] Lesen Sie nicht nur das Testat, sondern bewerten Sie Abweichungen, Einschränkungen, Prüfzeitraum und Verantwortlichkeiten des Kunden. Praxisbeispiel: Ein Einkaufsteam prüft jährlich gemeinsam mit Informationssicherheit und Datenschutz den C5-Bericht des Providers. Eine festgestellte Abweichung beim Berechtigungsreview wird mit Frist und Nachweis in den Lieferantenmaßnahmenplan aufgenommen.
Rechtsräume erfassen: Bewerten Sie nicht nur den Standort des Rechenzentrums, sondern auch Konzernsitz, Supportstandorte, Subdienstleister und mögliche gesetzliche Herausgabepflichten.[4][5][6] Halten Sie fest, welche Stelle im Ernstfall auf welche Daten technisch zugreifen könnte. Praxisbeispiel: Ein mittelständisches Unternehmen erstellt für jeden Cloud-Dienst eine Rechtsraum-Matrix. Anbieter mit außereuropäischer Konzernstruktur müssen zusätzlich darlegen, ob sie Kundendaten überhaupt im Klartext herausgeben könnten.
Wiederherstellung isolieren: Halten Sie Sicherungen unveränderlich oder logisch vom Produktivsystem getrennt und schützen Sie die Administration mit separaten Identitäten. Definieren Sie Wiederanlaufziele und testen Sie regelmäßig, ob Daten vollständig, schnell und ohne kompromittierte Bestandteile zurückgespielt werden können. Praxisbeispiel: Ein Produktionsbetrieb speichert tägliche Sicherungen in einem getrennten Konto mit unveränderlicher Aufbewahrung. Bei einer halbjährlichen Übung wird ein vollständiger Dateibestand in einer isolierten Umgebung wiederhergestellt und auf Schadcode geprüft.
Sichere Wege vereinfachen: Gestalten Sie Freigaben, mobile Nutzung und externe Zusammenarbeit so unkompliziert, dass Beschäftigte keine privaten Postfächer, offenen Links oder ungeprüften Apps benötigen. Bieten Sie verständliche Standardprozesse und kurze Hilfestellungen direkt im Arbeitsablauf an. Praxisbeispiel: Statt großer E-Mail-Anhänge nutzt ein Projektteam einen freigegebenen, verschlüsselten Datenraum. Externe Partner erhalten personalisierte Links mit Ablaufdatum und Mehrfaktor-Authentifizierung; die Projektleitung kann Zugriffe jederzeit widerrufen.

FAQ: Datensouveränität und Cyberresilienz

Was bedeutet Datensouveränität in der Cloud?
Datensouveränität bezeichnet die tatsächliche Kontrolle darüber, wo und wie Daten verarbeitet werden, wer darauf zugreifen kann und wer die kryptografischen Schlüssel kontrolliert. Dazu gehören technische, organisatorische, vertragliche und rechtliche Aspekte.
Reicht ein Rechenzentrum in Deutschland oder der EU aus?
Der Speicherort ist nur ein Faktor. Zusätzlich sind der Rechtsraum des Anbieters, mögliche Zugriffe von Konzernunternehmen oder Subdienstleistern sowie die technische Fähigkeit zur Entschlüsselung zu bewerten.
Was unterscheidet serverseitige von Ende-zu-Ende-Verschlüsselung?
Bei serverseitiger Verschlüsselung kann der Anbieter die Daten innerhalb seiner Infrastruktur verarbeiten und verfügt häufig über Schlüsselzugriff. Bei echter Ende-zu-Ende-Verschlüsselung entstehen Klartext und Schlüssel grundsätzlich nur an autorisierten Endpunkten.
Was ist mit Zero Knowledge gemeint?
Zero Knowledge beschreibt bei Cloud-Diensten eine Architektur, in der der Anbieter die für Kundendaten erforderlichen Entschlüsselungsschlüssel im regulären Betrieb nicht besitzt. Die konkrete Umsetzung und mögliche Metadatenzugriffe müssen dennoch geprüft werden.
Welche Rolle spielt NIS 2?
Artikel 21 der NIS-2-Richtlinie verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen.[3] Dazu zählen unter anderem Kryptografie, Zugriffskontrolle, Business Continuity, Lieferkettensicherheit und die Bewertung der Wirksamkeit von Maßnahmen.[2][3]
Was bedeutet der US CLOUD Act für europäische Unternehmen?
Er stellt klar, dass Anbieter unter US-Gerichtsbarkeit auf gültige rechtliche Anordnung Daten in ihrem Besitz, Gewahrsam oder ihrer Kontrolle herausgeben müssen – unabhängig vom Speicherort.[4] Ob lesbare Inhalte vorliegen, hängt auch von der technischen Architektur und Schlüsselhoheit ab.
Schützt Ende-zu-Ende-Verschlüsselung vollständig vor Datenabfluss?
Sie reduziert vor allem das Risiko, dass abgefangene oder beim Anbieter entwendete Inhalte lesbar sind. Kompromittierte Endgeräte, gestohlene Zugangsdaten, Metadaten, Fehlkonfigurationen und berechtigte Nutzerkonten bleiben relevante Risiken.
Warum ist Least Privilege wichtig?
Weil kompromittierte Konten nur auf die Ressourcen zugreifen können, für die Rechte bestehen. NIST Zero Trust fordert, Vertrauen nicht allein aus Netzwerkstandort oder Eigentum abzuleiten, sondern Authentifizierung und Autorisierung vor Ressourcenzugriffen durchzusetzen.[8]
Was sagt ein BSI-C5-Testat aus?
Der C5 beschreibt Mindestanforderungen für sicheres Cloud Computing und schafft Transparenz über Kontrollen eines Cloud-Dienstes.[7] Ein Testat ersetzt jedoch nicht die eigene Risikoanalyse; Kunden sollen Prüfberichte regelmäßig anfordern und auswerten.[7]
Welche Fragen gehören in eine Cloud-Ausschreibung?
Gefragt werden sollten unter anderem Verschlüsselungsumfang, Schlüsselinhaber, Administrationszugriffe, Identitäts- und Rollenmodell, Protokollierung, Datenlöschung, Backup-Isolation, Rechenzentrums- und Supportstandorte, Subdienstleister, Offenlegungsprozesse, Exit-Verfahren und aktuelle Prüfberichte.

Quellen

[1] ENISA, Threat Landscape 2026: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2026

[2] BSI, NIS-2-Risikomanagementmaßnahmen: https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/NIS-2-Infopakete/NIS-2-Risikomanagementmassnahmen/NIS-2-Risikomanagementmassnahmen.html

[3] EUR-Lex, Richtlinie (EU) 2022/2555: https://eur-lex.europa.eu/eli/dir/2022/2555?locale=de

[4] U.S. Department of Justice, CLOUD Act Resources: https://www.justice.gov/criminal/cloud-act-resources

[5] UK Legislation, Investigatory Powers Act 2016: https://www.legislation.gov.uk/ukpga/2016/25/contents

[6] Australian Federal Register of Legislation, Assistance and Access Act 2018: https://www.legislation.gov.au/C2018A00148/latest

[7] BSI, Kriterienkatalog C5: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html

[8] NIST SP 800-207, Zero Trust Architecture: https://csrc.nist.gov/pubs/sp/800/207/final

Management Summary, FAQ und Bild wurden mit Hilfe von KI erstellt

75 Artikel zu „Cyberresilienz Datensouveränität“

Business | Business Process Management | Geschäftsprozesse | Infrastruktur | IT-Security | News | Rechenzentrum | Strategien

Datenresidenz und Datensouveränität im Zeitalter der KI

3. September 2026

Datenresidenz allein reicht im KI-Zeitalter nicht mehr aus. Wer Souveränität ernst nimmt, muss Speicherort, Rechtszuständigkeit, operative Kontrolle, Verschlüsselung, Provider-Abhängigkeiten und Governance-End-to-End zusammendenken. Für IT-Entscheider wird Datensouveränität damit von einer Compliance-Frage zur strategischen Architekturentscheidung. Management Summary Datenresidenz ist nicht Datensouveränität: Der Standort eines Rechenzentrums beantwortet nicht die entscheidende Frage, wer rechtlich, technisch und operativ Zugriff auf…