Wer darf, ist nicht mehr die einzige Frage

Stell dir einen Account vor, der seit Monaten unauffällig arbeitet. Er gehört zu einem Praktikanten oder einem Service, liest ein paar Tabellen, exportiert hier und da einen Bericht, nichts Besonderes. Dann setzt über genau diesen Account jemand eine einzige Abfrage ab und zieht die komplette Kundendatenbank. Technisch war alles erlaubt. Der Zugang durfte lesen, und gelesen hat er. Trotzdem ist genau in diesem Moment möglicherweise ein Schaden entstanden, den die reine Zugriffskontrolle nicht aufhalten konnte.

Solche Geschichten sind keine Ausnahme. Das Tückische am Innentäter ist, dass er keine Spur hinterlässt, die nach Einbruch aussieht. Kein forcierter Login, keine ausgehebelte Firewall, keine Warnung, die anschlägt. Jeder einzelne Schritt steht genau im Rahmen dessen, was der Zugang darf, und ergibt für sich betrachtet ein sauberes Bild. Erst die Summe ergibt den Schaden, und die sieht niemand, der nur auf die Erlaubnis schaut. Seit KI-Helfer in die internen Abläufe einziehen, bekommt das eine neue Wucht, weil dieselben Rechte plötzlich mit einer ganz anderen Reichweite ausgeübt werden.

Die Frage „wer darf zugreifen?" beantwortet, wer an die Daten kommt. Sie sagt nichts darüber, wofür er sie dann verwendet.

Darin steckt die eigentliche Lücke. Wir haben gelernt, Zugriff an Identitäten zu binden: Dieser Mensch, diese Rolle, dieser Dienst darf dieses Datum sehen oder ändern. Das ist richtig und bleibt nötig. Aber es beantwortet nur die halbe Frage. Ob die Verwendung dem Zweck entspricht, für den wir die Daten einmal erhoben haben, steht auf einem anderen Blatt, und dieses Blatt führen die wenigsten.

Warum der KI-Helfer die Rechnung ändert

Die neuen Werkzeuge im Haus arbeiten im Kontext und mit den Berechtigungen des Menschen, der sie bedient. Sie haben also dieselben Rechte, aber deutlich mehr Fähigkeiten, Dinge schnell und in großem Umfang zu tun. Ein Zugang, der für einen einzelnen Menschen über Jahre völlig unkritisch war, bekommt eine andere Tragweite, sobald ein Assistent dahinter sitzt, der damit in Sekunden quer durch den Datenbestand geht.

Das Unbequeme daran ist, dass hier kein Angreifer am Werk sein muss. Es reicht ein hilfsbereiter Assistent, der eine Aufgabe zu wörtlich nimmt und zum Beantworten einer harmlosen Frage den halben Bestand durchleuchtet, weil ihm niemand gesagt hat, dass er das nicht soll. Die Grenze lag früher in der Trägheit des Menschen, der eben nicht mal eben zehntausend Datensätze von Hand durchsieht. Diese Trägheit fällt weg, und was übrig bleibt, ist die Frage, ob die Verwendung überhaupt vorgesehen war.

Damit stehen plötzlich Fragen im Raum, die vorher bequem im Hintergrund schlummern durften. Wer konsumiert die Daten eigentlich in all den neuen internen Tools, auf welche Werte bauen sie ihre Ergebnisse, und bedeuten diese Felder dort noch dasselbe, was sie bei der Erhebung bedeutet haben? Die Antwort darauf kennt man nur, wenn man die Herkunft der Daten kennt.

Weißt du, was du da vor dir hast?

Wer Daten verwendet, braucht ihre Herkunft, im Englischen Provenance (Datenherkunft). Das klingt akademisch, meint aber etwas sehr Praktisches: zu wissen, was man da eigentlich vor sich hat, bevor man darauf eine Entscheidung oder ein automatisiertes Ergebnis baut. Vier Fragen fassen das zusammen.

• Wie setzt sich dieser Wert zusammen? Kommt er direkt aus einer Quelle oder ist er aus mehreren berechnet, und über welche Schritte? Das ist die Linie der Herkunft, die Lineage.
• Wie aktuell ist er? Ein Wert von heute Morgen und ein Wert von vor einem halben Jahr sehen gleich aus, tragen aber ganz unterschiedliches Vertrauen.
• Was war der Zweck der Erhebung? Eine Adresse, die für den Versand erhoben wurde, ist nicht automatisch für ein Marketing-Scoring freigegeben.
• Nach welcher Definition? Ein Statusfeld bedeutet nur dann etwas, wenn alle, die es lesen, dasselbe darunter verstehen wie der, der es einmal gefüllt hat.

Die letzte Frage ist die heimtückischste, und sie lässt sich an einem Alltagsmoment zeigen. Du durchsuchst die Datenbank für eine neue Auswertung und findest ein Feld „aktiv", das genau zu passen scheint. Mit einem Assistenten wie Claude ist die Automatisierung darauf in einer halben Stunde gebaut, und sie liefert auf Anhieb hübsche Zahlen. Was du nicht siehst: Für den, der das Feld pflegt, bedeutet „aktiv" nicht das, was du annimmst. Vielleicht heißt es „in den letzten 24 Stunden gesehen" und gilt nur zusammen mit einem zweiten Feld, vielleicht ändert dieser Owner die Bedeutung irgendwann, ganz ohne dir Bescheid zu geben, weil er gar nicht weiß, dass jemand darauf aufsetzt.

Von da an läuft deine schöne Automatisierung auf einer Annahme, die nie stimmte oder leise gekippt ist. Der Geschäftsprozess, der auf diesen Zahlen entscheidet, wird vom Helfer zur Gefahr, und das Tückische ist die Reichweite. Es ist das Spiel der stillen Post: Jede Station reicht in bester Absicht weiter, was sie verstanden zu haben glaubt, und niemand lügt, trotzdem kommt am Ende etwas anderes an als am Anfang. Sobald ein weiteres Tool oder ein Kollege auf deinem Ergebnis aufbaut, wandert das Missverständnis transitiv durch die Kette, bis niemand mehr sagen kann, auf welcher ursprünglichen Bedeutung das Ganze eigentlich ruht. Schema-Drift ist deshalb kein reines Datenbankproblem mehr, sondern die Frage, ob eine ganze Kette von Automaten noch dieselbe Sprache spricht, und gerade die gut gemeinte, unkontrollierte Weiterverarbeitung macht sie gefährlich.

Die Frage, die der Zugriff offenlässt

Sobald man die Herkunft kennt, verschiebt sich die Sicherheitsfrage fast von selbst. Sie löst sich von der reinen Zugriffskontrolle und wandert hin zur zweckgebundenen Verwendung. Nicht mehr allein „wer darf an dieses Datum", sondern „für welchen Zweck darf dieses Datum verwendet werden, und passt die aktuelle Verwendung dazu".

Das ist kein neuer Gedanke, die Datenschutz-Grundverordnung nennt ihn Zweckbindung. Neu ist, dass er jetzt technisch greifbar wird. Solange nur Menschen mit den Daten arbeiteten, blieb Zweckbindung weitgehend eine Frage von Vertrauen und Stichproben. Mit Automaten, die gegen definierte Regeln laufen, lässt sich die Frage „passt diese Verwendung zum hinterlegten Zweck" an der Stelle stellen, an der der Zugriff tatsächlich passiert.

Das verlangt, dass Lesezugriffe genauso ernst genommen werden wie Schreibzugriffe. Wer verändern darf, steht meistens im Blick, weil ein falscher Schreibzugriff eine sichtbare Spur hinterlässt und die meisten Protokolle ohnehin festhalten, was warum geändert wurde. Ein Lesezugriff dagegen verändert nichts, taucht in keinem Änderungslog auf und ist genau deshalb der bequemere Weg für den Abfluss. Wer die Verwendung regeln will, muss das Lesen mit derselben Sorgfalt festhalten wie das Verändern, und zwar nicht nur, dass gelesen wurde, sondern was und wozu.

In der Praxis heißt das, jeden Zugriff mit demselben Satz Angaben zu versehen, ob er nun liest oder schreibt: wer, was, wofür und wann. So entsteht eine lückenlose Zugriffsspur, also ein Protokoll, das jeden einzelnen Zugriff mit seinem Zweck festhält. Das Feld „wofür" ist dabei das entscheidende, weil erst der mitgeschriebene Zweck später beantwortet, ob ein Zugriff zu dem passte, was eigentlich erlaubt war. Ein Export, der mit dem Zweck „Rechnungsstellung" protokolliert ist, lässt sich dann von einem Export unterscheiden, hinter dem gar kein Zweck steht, und genau diese Unterscheidung ist es, die man im Ernstfall braucht.

Eine solche Spur erlaubt noch etwas: zu erkennen, wenn ein Zugriff aus der Reihe fällt, obwohl er für sich genommen erlaubt war. Ein Account, der über Wochen dieselben paar Abfragen macht und plötzlich den halben Bestand durchleuchtet, ist ein Signal, lange bevor ein Schaden in der Bilanz auftaucht. Auffälligkeit geht dabei in beide Richtungen, denn genauso wichtig wie der plötzliche Ausschlag ist das Verstummen: ein Zugang, der eine tragende Rolle hatte und auf einmal schweigt, ist entweder kaputt oder wird umgangen.

Das Verstummen hat noch eine zweite Bedeutung, die leicht übersehen wird. Triffst du Entscheidungen auf einem Wert, den ein anderer Prozess regelmäßig aktualisiert, dann hängt deine Auswertung daran, dass dieser Prozess läuft. Steht er still, arbeitest du ohne es zu merken auf veralteten Daten weiter, und das kann deine Schlüsse genauso verfälschen wie ein falsch verstandenes Feld. Besonders heikel wird das, wenn der aktualisierende Prozess gar nicht deiner ist, weil du dich dann auf etwas verlässt, dessen Stillstand du selbst nicht siehst. Deshalb gehört zur Überwachung nicht nur die Frage, ob jemand zu viel zugreift, sondern auch, ob die Zulieferer, von denen deine Daten leben, überhaupt noch liefern.

Ihr habt die Antwort schon

An dieser Stelle kommt etwas ins Spiel, das viele bereits haben, ohne seinen Wert zu heben. Wer personenbezogene Daten verarbeitet, führt in aller Regel ein VVT (ein Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO), und in einem ISMS nach dem Vorbild der ISO 27001 ist dasselbe Inventar der zentrale Baustein. Dort steht, welche Daten zu welchem Zweck verarbeitet werden, wie lange und auf welcher Rechtsgrundlage. Genau die Angaben also, die Provenance und Zweckbindung brauchen.

Das Problem ist selten, dass dieses VVT fehlt. Das Problem ist, dass es als Word-Dokument in einem Ordner liegt, einmal für ein Audit geschrieben und danach von der Wirklichkeit überholt. Es beschreibt einen Zustand, den das System vielleicht nie wirklich hatte und ganz sicher nicht mehr hat.

Ein solches totes Dokument erfüllt die Form, aber nicht den Zweck, für den es eigentlich da ist. Und selbst die Prüfung übersteht es nicht zuverlässig, denn ein ernsthaftes ISO-27001-Audit fragt nicht in erster Linie, ob die Dokumente vollständig sind, sondern ob die beschriebenen Maßnahmen tatsächlich wirken. Vollständigkeit ist die Eintrittskarte, geprüft wird die Wirksamkeit. Ein VVT, das mit dem laufenden Betrieb nichts zu tun hat, fällt genau dort auf.

Für Regeln und Meldewege beschreiben wir dasselbe Muster im Artikel Compliance, die im Alltag antwortet: Eine Vorgabe wird nicht dadurch wirksam, dass sie existiert, sondern dadurch, dass ihr Wissen im entscheidenden Moment erreichbar ist. Für das VVT gilt es genauso, und die Lösung geht in dieselbe Richtung.

Vom toten Dokument zum lebenden Abbild

Die Brücke vom abgelegten Dokument zurück in den laufenden Betrieb lässt sich heute mit KI-Unterstützung schlagen, und zwar in genau der Richtung, in der KI stark ist: lesen, abgleichen, Abweichungen sichtbar machen. Ein Assistent mit reinem Lesezugriff kann das hinterlegte Inventar gegen das echte Schema der Datenbank halten und melden, wo beide auseinanderlaufen. Ein neues Feld, das niemand eingetragen hat. Ein Feld, das längst gelöscht sein müsste. Eine Tabelle, deren Zweck nirgends steht.

So wird aus der starren Momentaufnahme etwas, das mit der Datenbank mitwächst. Und sobald dieses Abbild stimmt, hört es auf, bloß zu dokumentieren. Es wird zu einer Instanz, die der Zugriffslogik eine zweite Angabe mitgibt, die sie vorher nie hatte: nicht nur, wer da liest, sondern wozu. Was sich damit bauen lässt, ist der eigentlich interessante Teil.

Wohin das Datum danach reist

Ob ein Zugang etwas lesen darf, ist die eine Ebene. Was danach mit dem Gelesenen geschieht, welches System es weiterverarbeitet und ob dessen Verständnis noch zur ursprünglichen Bedeutung passt, ist eine ganz andere. Eine Zugriffsregel endet im Moment des Lesens. Über die Reise, die ein Datum danach antritt, sagt sie nichts, und genau diese Reise ist es, die über den Schaden entscheidet.

Trennt man die beiden Ebenen sauber, öffnet sich ein Spielraum, den die reine Zugriffsfrage nie hatte. Am deutlichsten wird das, wenn man unterscheidet, ob gerade jemand etwas Neues erkundet oder ob ein fertiger Prozess seine Arbeit tut. Ein CRM mit euren Kundendaten zeigt beides nebeneinander.

In der Erkundung muss ein Mensch die Daten wirklich sehen. Eine Vertrieblerin, die entscheiden will, welche Kunden einen neuen Newsletter bekommen sollen, filtert nach Umsatz, nach Vertragsbestandteilen, nach Verhalten. Das ist ihre Aufgabe, und dafür braucht sie reichen Zugriff, gern auch mit einem KI-Assistenten an ihrer Seite, solange die Daten für genau diesen Zweck freigegeben sind. Bemerkenswert ist, was hier gerade nicht dazugehört: die E-Mail-Adresse. Zum Auswählen braucht sie niemand, also ist sie für diesen Zweck auch nicht freigegeben. Am Ende steht eine Auswahl, eine Entscheidung, welche Kunden angeschrieben werden, nicht aber deren Postfach.

Der Versand selbst ist dann kein Erkundungsschritt mehr, sondern ein fertiger Geschäftsprozess, und der sieht völlig anders aus. Es kann nicht sein, dass die Vertrieblerin dafür alle E-Mail-Adressen auf ihren Rechner zieht und von dort verschickt. Der Versandschritt läuft serverseitig und bekommt genau die Felder, die er jetzt braucht, Name und E-Mail der ausgewählten Kunden, und sonst nichts. Die Adresse taucht also erst dort auf, wo sie wirklich gebraucht wird, und er weiß nichts von Umsätzen und nichts von Verträgen, weil ihm diese Felder nie gegeben werden.

Das ist der Gewinn der sauberen Trennung. Der Versand bekommt Umsatz und Vertrag nie zu sehen, also kann er sie auch nicht preisgeben. Und weil die ausgewählten Empfänger als fester Teil des Prozesses feststehen, kann niemand versehentlich die falsche Liste erwischen. Die Sicherheit steckt damit in der Art, wie der Prozess gebaut ist, und hängt nicht daran, dass sich alle Beteiligten jederzeit korrekt verhalten.

Genau daraus entsteht eine Fähigkeit, die über das einzelne Beispiel hinaus zählt: serverseitige Prozessschritte sauber zu modellieren und zu betreiben, statt jeden Ablauf über die Arbeitsumgebung eines Menschen laufen zu lassen. Die Erkundung bleibt beim Menschen und seinen Werkzeugen, der wiederkehrende Prozess wandert dahinter, wo er nur die Felder sieht, die er für seinen einen Zweck braucht.

So kippt die ganze Logik der Sicherheit. Eine zweckgebundene Regel ist kein zusätzliches Schloss, das noch etwas mehr zusperrt. Sie ist eher ein Ventil, das Dinge durchlässt, die man vorher pauschal verboten hätte, weil man jetzt genau benennen kann, unter welcher Bedingung und mit welchen Feldern sie in Ordnung sind. Ein neues Werkzeug, das sonst an der Datenschutzfrage gescheitert wäre, bekommt einen klar umrissenen Korridor, in dem es arbeiten darf, und alles außerhalb bleibt zu.

So verschiebt sich auch, wofür das ISMS gut ist. Es dient nicht mehr dazu, am Ende eine Freigabe zu verweigern, sondern dazu, vorab den Korridor zu beschreiben, in dem ein neuer Prozess sofort loslegen kann. Die Freigabe hängt dann nicht mehr wochenlang in einer Mailschleife, weil die Bedingung schon formuliert ist und der Abgleich automatisch passiert. Sicherheit und Tempo stehen hier nicht gegeneinander, sie kommen aus derselben Quelle, weil derselbe hinterlegte Zweck beide trägt.

Was das für dich heißt

Die Frage, wer zugreifen darf, bleibt wichtig, aber sie reicht nicht mehr allein, und vermutlich reichte sie nie. Sobald ein Account nicht nur ein Mensch ist, sondern ein Assistent mit großer Reichweite dahinter, entscheidet sich der Schaden nicht am Zugriff, sondern an der Verwendung. Wer die Verwendung regeln will, muss wissen, woraus seine Daten bestehen und wofür er sie einmal erhoben hat, und genau diese Angaben trägt ein ISMS bereits, meist nur an der falschen Stelle, nämlich tot in einem Dokument.

Macht man dieses Wissen lebendig, bekommt Sicherheit eine zweite Möglichkeit neben dem pauschalen Verbot: einen klar umrissenen Weg zu beschreiben, auf dem ein Vorhaben arbeiten darf, während alles daneben weiterhin zu bleibt. Das macht manches möglich, was sonst vorsichtshalber ganz unterblieben wäre, ohne die Sicherheit zu senken.

Der Weg dahin beginnt nicht mit einem großen Projekt, sondern mit einer Frage an den eigenen Bestand: Woher kommen eure wichtigsten Daten, und wisst ihr noch, wofür ihr sie erhoben habt? Wenn die Antwort in einem Word-Dokument steht, das niemand mehr aufmacht, liegt dort euer Hebel. Ein VVT, das im Betrieb mitläuft, macht aus der Zugriffsfrage eine Verwendungsfrage, und genau diese Brücke zwischen eurem ISMS und eurem laufenden Betrieb gehen wir gern gemeinsam mit euch an.