DataPrivacy & SecurityBanking

Zero-Trust-Architektur für den Datenzugriff im Unternehmen: Was CDOs wirklich verstehen müssen

Zero Trust gehört inzwischen zum Standardrepertoire in Security-Diskussionen, doch die meisten Erklärungen enden am Netzwerkperimeter und erreichen nie die Datenebene, auf der CDOs tatsächlich arbeiten. Dieser Artikel zeigt, wie Zero Trust konkret auf den Datenzugriff angewendet wird, wo es gut funktioniert und wo es Reibung erzeugt, mit der Führungskräfte rechnen sollten.

🎙️

Podcast anhören

4 min

Zero Trust ist eines dieser Konzepte, die so oft wiederholt werden, dass sie an Bedeutung verlieren. Netzwerkteams beschreiben damit Perimeterkontrollen. Security-Anbieter verkaufen damit Identity-Produkte. Und irgendwo dazwischen sitzen CDOs und versuchen herauszufinden, was das eigentlich für die Datenumgebungen bedeutet, die sie verantworten. Die Verwirrung ist nachvollziehbar: Zero Trust entstand als Prinzip der Netzwerksicherheit, formuliert von John Kindervag bei Forrester im Jahr 2010, und die Datenebene war in der Umsetzung des Modells immer zweitrangig. 2026, wo Unternehmen verteilte Datenplattformen über Cloud-Provider, SaaS-Anwendungen und On-Premise-Systeme hinweg betreiben, ist aus dieser Lücke ein echtes Governance-Risiko geworden.

Warum das speziell für einen CDO relevant ist

Ein CDO ist anders exponiert als ein CISO, wenn der Datenzugriff versagt. Ein CISO denkt an Breach-Vektoren. Ein CDO denkt daran, wer auf welche Daten zugegriffen hat, ob diese Person zu diesem Zeitpunkt autorisiert war, ob der Zugriff protokolliert wurde und ob er sich gegenüber einer Aufsichtsbehörde oder dem Board erklären lässt. Das sind ebenso Compliance- und Governance-Fragen wie Security-Fragen.

Es geht um Konkretes. Unter der DSGVO ist der Nachweis, dass der Zugriff auf personenbezogene Daten kontrolliert und zweckgebunden erfolgte, eine rechtliche Pflicht und keine Best Practice. In Sektoren wie Financial Services haben Aufsichtsbehörden, darunter die britische FCA und die Europäische Bankenaufsichtsbehörde, Data Lineage und Nachvollziehbarkeit von Zugriffen zu expliziten aufsichtsrechtlichen Erwartungen gemacht. Wenn ein Data Analyst in einer Bank einen Kundendatensatz ohne dokumentierte geschäftliche Begründung abfragt, ist das nicht nur ein Security-Ereignis. Es ist ein Compliance-Ereignis, das eine aufsichtsrechtliche Nachfrage auslösen kann.

Zero Trust auf der Datenebene gibt CDOs ein Framework, um das direkt anzugehen, statt sich auf Kontrollen auf Netzwerkebene zu verlassen, die nicht zwischen einem autorisierten Nutzer mit einer legitimen Query und demselben Nutzer beim Exfiltrieren von Daten an einen externen Ort unterscheiden.

Wie Zero Trust auf der Datenebene tatsächlich funktioniert

Das Kernprinzip von Zero Trust ist einfach: Kein Nutzer, kein Gerät und kein System ist standardmäßig vertrauenswürdig, unabhängig davon, ob es sich innerhalb oder außerhalb des Unternehmensnetzwerks befindet. Jede Zugriffsanfrage wird im Moment ihres Auftretens gegen eine Reihe kontextbezogener Signale geprüft, und Zugriff wird nur für das Nötige und nur so lange wie nötig gewährt.

Auf den Datenzugriff angewendet bedeutet das vier praktische Mechanismen.

Der erste istAttribute-Based Access Control (ABAC). Statt statische Rollen wie „Analyst“ oder „Admin“ zu vergeben und diesen Rollen weitreichende Berechtigungen mitzugeben, prüft ABAC jede Zugriffsanfrage gegen eine Kombination von Attributen: Identität des Nutzers, Abteilung, Sensitivitätsklassifikation der angefragten Daten, Uhrzeit, verwendetes Gerät und Standort. Ein Data Engineer in London, der während der Arbeitszeit ein verwaltetes Laptop nutzt, bekommt vielleicht Lesezugriff auf einen Produktionsdatensatz. Derselbe Engineer, der um Mitternacht von einem unbekannten Netzwerk aus ein nicht verwaltetes Gerät nutzt, wird blockiert oder in eine Prüfschleife geleitet.

Der zweite ist dynamische Policy-Durchsetzung. Zugriffsrichtlinien werden nicht einmal gesetzt und dann vergessen. Sie reagieren in Echtzeit auf Kontextänderungen. Googles BeyondCorp-Modell, das Google intern aufgebaut und später als BeyondCorp Enterprise produktisiert hat, ist dafür das am besten dokumentierte Beispiel aus der Praxis. Google hat Details der internen Umsetzung ab 2014 in einer Reihe von Papers veröffentlicht, und das Modell hat geprägt, wie große Unternehmen über kontinuierliche Authentifizierung denken.

Der dritte ist Verschlüsselung auf Datenebene mit zugriffsgebundenen Schlüsseln. In diesem Modell werden sensible Datensätze nicht nur at rest verschlüsselt, sondern mit Schlüsseln, die dynamisch ausgegeben werden und ablaufen. Der Zugriff auf die Daten erfordert sowohl Authentifizierung als auch einen gültigen Key Grant. Plattformen wie Immuta und BigID (beides kommerzielle Anbieter, deren veröffentlichte Benchmarks entsprechend zu lesen sind) haben Produktlinien rund um dieses Modell für Cloud-Datenumgebungen aufgebaut.

Der vierte ist lückenloses Access Logging mit Anomalieerkennung. Jede Query, jeder Export, jeder API-Call an einen Datenservice wird in ein unveränderliches Log geschrieben. Die Anomalieerkennung sucht dann nach Mustern, die vom Baseline-Verhalten abweichen: ein Nutzer, der normalerweise aggregierte Queries fährt und plötzlich Einzelfalldaten zieht, oder eine Anwendung, die in einer Stunde das Zehnfache ihrer üblichen Anfragen stellt.

Konkret: Stellen Sie sich eine Gesundheitsorganisation vor, die ihre Analytics-Umgebung auf Snowflake betreibt. Unter einem Zero-Trust-Modell für den Datenzugriff würde die Anfrage eines Data Scientist auf einen Patientenkohorten-Datensatz eine Policy-Prüfung auslösen, die seine Rolle prüft, das konkrete Studienprotokoll, dem er zugeordnet ist, ob dieses Protokoll eine IRB-Genehmigung hat und ob der Zugriff in das genehmigte Studienfenster fällt. Die Query läuft, aber es werden nur die für dieses Protokoll zugelassenen Felder zurückgegeben. Der Zugriff wird mit der Protokoll-ID protokolliert. Endet die Studie, wird der Zugriff automatisch entzogen. Kein IT-Ticket nötig und kein manuelles Audit, um Compliance nachzuweisen.

Wann man es einsetzt und wann nicht: die ehrlichen Tradeoffs

Zero Trust auf der Datenebene funktioniert gut in Umgebungen, in denen Daten sensibel sind, Zugriffsmuster durch den fachlichen Kontext definiert werden und die regulatorische Aufmerksamkeit hoch ist. Financial Services, Healthcare und jede Organisation, die personenbezogene Daten in großem Umfang verarbeitet, sind natürliche Kandidaten.

Reibung entsteht in Umgebungen, in denen Zugriffsmuster explorativ und im Voraus schwer zu definieren sind. Data-Science-Teams mit offener Forschungsarbeit müssen Datensätze oft erst durchsehen, bevor sie wissen, was sie brauchen. Jede explorative Query durch eine ABAC-Policy-Engine zu zwingen, bremst entweder die Arbeit aus oder treibt Forscher in Schattenumgebungen, in denen sie Kopien der Daten außerhalb des kontrollierten Systems ablegen. Beide Ergebnisse sind schlimmer als das Problem, das die Policy lösen sollte.

Auch die Implementierungskosten sind real. Ein ausgereiftes Zero-Trust-Modell für den Datenzugriff erfordert ein Datenklassifizierungsprogramm, das tatsächlich funktioniert (in den meisten Organisationen ist die Klassifizierungsabdeckung unvollständig), eine Policy-Management-Schicht, die nicht zum Bottleneck wird, und Integrationsarbeit über jede Datenplattform in der Umgebung hinweg. Organisationen, die das umsetzen wollen, ohne zuerst ihren Datenkatalog in Ordnung zu bringen, landen typischerweise bei einem Flickenteppich von Kontrollen, die Compliance-Theater erzeugen statt echter Governance.

Der praktische Weg, den die meisten großen Unternehmen 2026 gehen, ist gestuft: strenge Zero-Trust-Kontrollen zuerst auf die Datendomänen mit der höchsten Sensitivität anwenden, dort die operative Routine aufbauen und die Abdeckung schrittweise ausweiten. Überall gleichzeitig anzufangen führt selten irgendwo zu funktionierenden Kontrollen.

Ein CDO, der Zero Trust auf der Datenebene versteht, kann etwas, das ein Netzwerk-Security-Team nicht kann: Zugriffskontrolle direkt mit Data-Governance-Ergebnissen, regulatorischem Reporting und geschäftlicher Verantwortung verbinden. In dieser Verbindung liegt der eigentliche Wert des Modells.

Mehr dazu

Die Lektionen, die diesen Artikel weiterführen, frei zugänglich.

  1. 1Datenklassifizierung & Zugriffskontrolle: der Zero-Trust-Ansatz für DatenData Governance & Compliance
  2. 2Data lineage & Metadata-Management: wissen, wo Ihre Daten geboren wurdenData Governance & Compliance
  3. 3DSGVO in der Praxis: die 10 häufigsten Fehler von CDOsData Governance & Compliance
  4. 4Insider threats und Shadow IT: die Risiken, die in keinem Datenstrategie-Papier stehenData Governance & Compliance
  5. 5CDO in Financial Services: Wenn Regulierung Ihre Architektur istDatenstrategie & die Rolle des CDO

Artikel gelesen?

Bestätigen Sie Ihre Lektüre, um XP zu sammeln und Ihr Radar zu füttern.