So schaffst du eine sichere Datenkultur
Data Classification und Sensitivity Labels mit Microsoft Purview
Von: Emil Vinčazović
In einer Welt, in der Daten das neue Gold sind, stehen inbesondere Unternehmen in regulierten Branchen wie Banken und Versicherungen vor einer gewaltigen Herausforderung. Die schiere Menge an erzeugten und verarbeiteten Daten explodiert, während die regulatorischen Anforderungen, allen voran die DSGVO und die Norm ISO 27001, immer strenger werden. Wie behältst du also den Überblick über sensible Kundeninformationen, geistiges Eigentum oder interne Finanzdaten? Wie stellst du sicher, dass diese Informationen jederzeit angemessen geschützt sind, egal ob sie in einer E-Mail, einer SharePoint-Bibliothek oder einer lokalen Datenbank liegen?
Zudem ist Künstliche Intelligenz in aller Munde – man kann von einem regelrechten KI-Hype sprechen. Die EU hat darauf mit dem EU AI Act reagiert. Dieser besagt unter anderem, dass du nachweisen beziehungsweise nachvollziehen können musst, wie deine KIs trainiert wurden. Die manuelle Klassifizierung von Daten ist also längst keine tragfähige Lösung mehr. Sie ist nicht nur fehleranfällig und langsam, sondern in modernen Datenlandschaften schlicht unmöglich. Genau hier setzt Microsoft Purview an. In diesem Beitrag zeige ich dir detailliert auf, wie du mit automatisierten Data Classification und Sensitivity Labels eine dynamische, intelligente und vor allem skalierbare Datenschutzstrategie aufbaust, die den Namen auch verdient.
Unstrukturierte Daten sind eine tickende Zeitbombe
Stell dir das typische Szenario vor: Ein Mitarbeiter erstellt einen Finanzbericht mit hochsensiblen Quartalszahlen. Er speichert ihn auf einem schlecht gesicherten Team-Laufwerk, weil es gerade am einfachsten ist. Ein anderer Kollege arbeitet an einer Liste mit Kundendaten für ein Marketingprojekt und teilt sie per E-Mail mit einem externen Dienstleister, ohne die Daten zu verschlüsseln. Solche alltäglichen Vorgänge sind in vielen Unternehmen an der Tagesordnung. Das Problem ist nicht böser Wille, sondern mangelndes Bewusstsein und fehlende Werkzeuge. Die Konsequenzen können jedoch verheerend sein. Wir sprechen hier nicht nur von empfindlichen Bußgeldern im Rahmen der DSGVO, die bis zu vier Prozent des weltweiten Jahresumsatzes betragen können. Ein Datenleck führt unweigerlich zu Reputationsschäden, Vertrauensverlust bei Kunden und im schlimmsten Fall zum Verlust von Wettbewerbsvorteilen. Die manuelle Klassifizierung scheitert hier, weil sie den Faktor Mensch als schwächstes Glied in der Kette hat.
Microsoft Purview: Mehr als nur ein Scanner
Microsoft Purview ist nicht bloß ein Werkzeug zur Datenklassifizierung, sondern eine umfassende Data-Governance-Plattform, die dir eine 360-Grad-Sicht auf deine Daten ermöglicht. Bevor du überhaupt mit der Klassifizierung beginnst, hilft dir Purview dabei, eine vollständige Datenlandkarte zu erstellen. Purview scannt und katalogisiert Datenquellen in deiner gesamten hybriden Umgebung – von Microsoft 365 über Azure-Dienste bis hin zu lokalen SQL-Servern und sogar AWS S3-Buckets. Dieser Katalog zeigt dir nicht nur, wo deine Daten liegen, sondern auch, wie sie sich durch dein Unternehmen bewegen (Data Lineage). Damit bildet er die Grundlage für alles Weitere, denn erst mit diesem Wissen kannst du die Klassifizierung effektiv und zielgerichtet einsetzen.
Die automatisierte Klassifizierung im Detail
Der Weg zur automatisierten Klassifizierung folgt einem klaren Ablauf. Ich erkläre dir Schritt für Schritt, wie die Implementierung funktioniert.
1. Erkennungsmethoden meistern
Zuerst musst du Purview beibringen, welche Informationen für dein Unternehmen sensibel sind. Hierfür stehen dir mehrere, sich ergänzende Methoden zur Verfügung. Deine erste Verteidigungslinie bilden die Sensitive Information Types (SITs). Microsoft liefert über 200 vordefinierte SITs für gängige Datentypen wie Kreditkartennummern, IBANs, Reisepassnummern oder länderspezifische Gesundheitsinformationen. Diese erkennen Daten nicht nur anhand einfacher Muster, beispielsweise einer 16-stelligen Zahl, sondern nutzen auch kontextuelle Prüfungen wie Prüfsummenalgorithmen, etwa den Luhn-Algorithmus für Kreditkarten, und Schlüsselwörter in der Nähe. Du kannst diese SITs auch anpassen oder komplett eigene mit XML-Definitionen und regulären Ausdrücken erstellen, um firmenspezifische Formate wie Mitarbeiter-IDs oder Projektnummern zu erkennen. Dementsprechend sind alle Use Cases abgedeckt und die SITs können klar definiert werden.
Für komplexere Anforderungen, insbesondere bei unstrukturierten Inhalten, kommen Trainable Classifiers ins Spiel. Während SITs gut für strukturierte Daten sind, glänzen Trainable Classifiers, wenn du Verträge, Rechnungen, Lebensläufe oder technische Spezifikationen erkennen willst. Du beginnst, indem du dem Classifier eine Sammlung von 50 bis 500 Beispieldokumenten, sogenannte Seed-Daten, zur Verfügung stellst. Das System analysiert diese und baut ein Vorhersagemodell auf. Anschließend testest du das Modell mit einer Mischung aus positiven und negativen Beispielen und gibst Feedback, um die Genauigkeit zu verbessern. Genau so, wie man es generell bei Klassifizierungsproblemen im Machine Learning macht. Dieser Prozess stellt sicher, dass die Erkennung hochpräzise ist und auf die spezifischen Dokumententypen deines Unternehmens zugeschnitten ist.
Für höchste Präzision, besonders im Umgang mit großen, strukturierten Datensätzen wie einer Kundendatenbank, ist Exact Data Match (EDM) die erste Wahl. Du exportierst die sensiblen Daten, zum Beispiel Kundennummern oder Sozialversicherungsnummern, in eine CSV-Datei, erstellst einen Hash-Wert davon und lädst diesen sicheren Hash in den Microsoft 365-Dienst hoch. Purview kann dann Dokumente und E-Mails durchsuchen und exakte Übereinstimmungen mit den Werten aus deiner Datenbank finden, ohne die Rohdaten selbst kennen zu müssen. Die Daten bleiben somit pseudonymisiert.
2. Die Macht der Sensitivity Labels
Nachdem du weißt, was du schützen musst, legst du mit Sensitivity Labels fest, wie der Schutz aussehen soll. Ein Label ist ein Container für Schutzmaßnahmen, die du granular steuern kannst. Dazu gehören visuelle Markierungen, bei denen du Kopf- und Fußzeilen oder Wasserzeichen, beispielsweise Vertraulich, auf Dokumente anwenden kannst, um das Bewusstsein der Benutzer zu schärfen. Das Herzstück des Schutzes bilden Verschlüsselung und Zugriffskontrolle. Du kannst festlegen, dass ein Dokument verschlüsselt wird, sobald das Sensitivity Label angewendet wird. Die Zugriffsrechte sind dabei direkt an das Label gekoppelt. So kannst du definieren, dass nur Mitglieder einer bestimmten Abteilung das Dokument öffnen dürfen oder dass externe Benutzer lediglich Leserechte haben, aber nicht drucken oder weiterleiten können. Diese Rechte bleiben auch dann bestehen, wenn die Datei das Unternehmen verlässt. Darüber hinaus ermöglicht das Container-Management, Labels nicht nur auf Dateien und E-Mails, sondern auch auf Container wie SharePoint-Seiten, Microsoft Teams oder Microsoft 365-Gruppen anzuwenden. (Lies dir hierzu gerne meinen Beitrag Fabric und Purview – Das Dream-Team für deine Datenplattform durch). Ein Team kann zum Beispiel mit einem Label Streng Vertraulich so konfiguriert werden, dass es keine externen Gäste zulässt und die Freigabeoptionen stark einschränkt.
3. Die Automatisierung orchestrieren – Auto-Labeling Policies
Hier fügt sich nun alles zusammen. Mit Auto-Labeling Policies wendest du die definierten Labels automatisch auf Basis der erkannten sensiblen Inhalte an. Dabei hast du zwei Möglichkeiten: Service-side Auto-Labeling läuft im Hintergrund auf Diensten wie SharePoint Online und Exchange Online und scannt Daten im Ruhezustand. Im Gegensatz dazu funktioniert Client-side Auto-Labeling in Echtzeit direkt in den Office-Anwendungen auf dem Computer des Benutzers. Wenn ein Benutzer beispielsweise eine Sozialversicherungsnummer in ein Word-Dokument tippt, kann eine Richtlinie ein Label empfehlen oder sogar automatisch anwenden. Eine der wichtigsten Funktionen ist der Simulationsmodus. Bevor du eine Auto-Labeling-Richtlinie aktivierst und potenziell Tausende von Dokumenten änderst, kannst du sie im Simulationsmodus laufen lassen. Purview zeigt dir dann genau, welche Dateien betroffen wären und welches Label angewendet würde. Das gibt dir Sicherheit, um Regeln zu optimieren, bevor du sie produktiv schaltest. (Außerdem ersparst du dir so den Aufschrei verärgerter Kollegen, sollte mal etwas nicht auf Anhieb klappen).
Best Practices für eine erfolgreiche Implementierung
Die Technologie ist nur die halbe Miete. Eine erfolgreiche Einführung erfordert eine klare Strategie. Zuerst solltest du ein Klassifizierungsschema entwickeln. Bevor du das erste Label erstellst, definiere ein klares und verständliches Schema mit maximal vier bis fünf Vertraulichkeitsstufen, zum Beispiel Öffentlich, Intern, Vertraulich oder Streng Vertraulich. Beschreibe für jede Stufe klar, was sie bedeutet und für welche Daten sie gilt. Anschließend ist es ratsam, ein Pilotprojekt zu starten. Wähle eine Abteilung oder einen Geschäftsprozess mit klaren Anwendungsfällen aus. Nutze diesen Piloten, um Erfahrungen zu sammeln, deine Sensitive Information Types und Trainable Classifiers zu trainieren und das Feedback der Benutzer einzuholen. Es ist wichtig, Automatisierung mit Benutzerinteraktion zu kombinieren. Verlasse dich nicht zu 100 Prozent auf die Automatisierung. Konfiguriere Richtlinien so, dass sie in Zweifelsfällen ein Label empfehlen, aber dem Benutzer die endgültige Entscheidung überlassen. Das erhöht die Akzeptanz und hilft, die Modelle weiter zu trainieren. Bedenke stets, dass Data Governance ein kontinuierlicher Prozess ist. Deine Datenlandschaft und die regulatorischen Anforderungen ändern sich ständig. Plane regelmäßige Überprüfungen deiner Richtlinien, analysiere die Berichte im Purview Compliance Portal und passe deine Konfiguration an neue Gegebenheiten an.
Eine verantwortungsvolle Datenkultur
Die automatisierte Datenklassifizierung mit Microsoft Purview ist für Unternehmen in regulierten Branchen kein optionales Add-on, sondern eine strategische Notwendigkeit. Sie transformiert den Datenschutz von einer reaktiven, manuellen Belastung zu einem proaktiven, intelligenten und integrierten Prozess. Indem du Purview nutzt, um deine Daten zu verstehen, zu klassifizieren und zu schützen, minimierst du nicht nur die Risiken von Datenlecks und Compliance-Verstößen. Du schaffst auch eine Grundlage für Vertrauen bei deinen Kunden und legst den Grundstein für eine verantwortungsvolle Datenkultur im gesamten Unternehmen. Es ist an der Zeit, das Datenchaos endgültig zu beenden und die volle Kontrolle zurückzugewinnen.
Der Videokurs zum Blogbeitrag
Neben diesen Fachbeitrag stellt Emil Vinčazović in seiner Videokurs-Serie über Microsoft Fabric, das Tool und dessen Einsatzmöglichkeiten praxisorientiert vor.
Nach einem Einblick in die All-in-One-Lösung zur Datenanalyse von Microsoft führt Data-Science-Experte Emil Vinčazović dich durch Data Factory, Synapse Data Enginieering, Synapase Data Warehouse, Synapse Data Science, Synapse Real-Time Intelligence und Power BI.
Diese Beiträge könnten dich auch interessieren:
Der Beitrag Etwas weniger magisch, aber leichter zu lernen erschien zuerst auf heise academy Blog.
]]>Der Beitrag Frameworks – braucht’s die eigentlich noch? erschien zuerst auf heise academy Blog.
]]>Frameworks – braucht’s die eigentlich noch?
Von Brennpunkten in der IT-Landschaft und neuen Interpretationen alter Probleme
Von: Katja Potensky
Ich bin zwar nicht bekannt dafür, aus der Bibel zu zitieren, aber hin und wieder passt eine Passage einfach:
Es gibt nichts neues unter der Sonne. – Prediger 1,9
Daran fühlte ich mich letzte Woche erinnert bei einer Diskussion zur Frage, ob es Frameworks noch brauche. Du kannst dir sicher vorstellen, wie lebhaft solch ein Diskurs geführt wird. In den folgenden Absätzen möchte ich die verschiedenen Blickwinkel sowie meine Two Cents zum Thema Frameworks mit euch teilen.
Was ist überhaupt ein Framework?
Ein Framework ist eine Sammlung von Software mit einer zugehörigen Sammlung an Kompromissen. – Peter Kröner
Diese Definition kam zu Beginn der angesprochenen Diskussion auf und ich halte sie für die erste sinnvolle überhaupt. Denn sie deutet bereits darauf hin, dass wir es hier nicht mit einer rein technischen Fragestellung zu tun haben. Dennoch möchte ich den technischen Blickwinkel als Ausgangspunkt wählen.
Worin liegt der technische Bedarf?
Gibt es einen technischen Bedarf für C oder Java? Warum programmieren wir nicht alle einfach Assembler? Der Bedarf richtet sich nicht nur nach den Zielen, sondern auch nach den Aufwänden. Man wollte irgendwann nicht mehr in Assembler programmieren, also haben schlaue Menschen begonnen, die typischen Aufgaben zu abstrahieren und irgendwann kam unter anderem C dabei raus. Später hat sich herausgestellt, dass man auch in C viele wiederkehrende Aufgaben lösen musste, also hat sich über ein paar Umwege Java ergeben. Du siehst also, das Ganze ist ein iterativer Prozess.
Auf solchem Wege wurde auch die Aufgabe, ein buntes Kästchen im Browser zu bauen, in das man etwas reintippen kann, immer mehr abstrahiert. Diese Abstraktionen wurden zu den Frameworks, die wir heute kennen. Mittlerweile sind wiederum viele bis alle typischen Aufgaben zum Erstellen einer BLOBA (Boring Line-of-Business Application), bei denen ein Framework in den letzten zehn Jahren geholfen hat, durch Erweiterungen der Webstandards ohne größere oder sogar mit weniger Problemen umsetzbar.
Ich rate hier dringend dazu, auf MDN die Liste der HTML-Elemente alle paar Jahre durchzugehen, genauso wie die Liste der Web-APIs. Dialoge, Dropdowns oder auch die meisten Validierungen sollte man im Jahr 2024 wirklich nicht mehr mit einer teuren Component Library umsetzen.
Auch wenn es um das Thema Bundling und CI/CD geht, lohnt sich ein Blick über den Tellerrand. Gerade hier führt der Einsatz schwergewichtiger Lösungen gerne zu unvorhergesehenen Problemen.
Tipp: „Code is a liability, not an asset“ gilt auch für jenen Code, den wir nicht selbst schreiben. Wenn sich Abhängigkeiten ungünstig verhalten, ist meistens das einzige, was wir heutzutage tun können, einen Bug Report zu erstellen und die Ohren steif zu halten. Oder hast du schon mal probiert, eine geforkte Version von Angular auszurollen? ;)
Aber gut, dieses Argument schaut auf die bisherigen Umstände. Was ist, wenn wir in die Zukunft blicken?
Der Blick nach vorne
Gehen wir rein theoretisch davon aus, dass Angular, React, Vue etc. ihre Repositories und Packages löschen und wir alle unsere BLOBAs mit HTML und gezielt eingesetztem Javascript bauen.
Einer der Trends unserer Zeit ist ganz klar KI, man kann heutzutage im Browser mittels WebGPU Zugriff auf die GPU erlangen. Jetzt wäre es nicht allzu weit hergeholt, dass für diverse Use-Cases auf vielen Websites Chatbots implementiert werden sollen. Und zwar auf so vielen, dass es sich zur Vereinfachung des Anwendungsfalls auszahlt, Libraries darum herum zu schreiben. Vielleicht kommen auch Bezahlmöglichkeiten mittels Payment Request API dazu und ein paar andere Dinge, die so typisch werden, dass wir wiederum eine Reihe von Libraries unter der Annahme von gewissen Kompromissen auf eine spezifische Art und Weise verbinden, die wir gut finden… und prompt haben wir unser nächstes Framework geschaffen.
Wir können also davon ausgehen, dass es immer (neue) Frameworks geben wird. Denn so wunderbar die Webstandards sind, sie können und sollen eben nicht meinungsgetrieben sein. Selbst die Gamepad API existiert, weil es ausreichend Bedarf dafür gab und nicht umgekehrt. Neue Bedürfnisse sollten nicht durch Webstandards verprobt werden, sondern durch Libraries und Frameworks. Aber wer würde solche neuen Frameworks wohl verwenden?
„Apes together strong“
Wie viele Frameworks, die uns geholfen haben Formulare und Seitennavigationen zu bauen, gibt es wohl?
2011 habe ich einige JS-Files geschrieben, die mittels beliebiger Attribute an HTML-Elementen diese Elemente um eine beliebige Funktionalität erweitern können. Das weiß kaum jemand, da ich diese Idee zum einen nicht verbreitet habe. Zum anderen wurde ich ein paar Wochen später mit AngularJS konfrontiert und dachte mir: „Hey, die Idee hatte schon jemand.“ Also habe ich meinen eigenen Code verworfen und stattdessen AngularJS eingesetzt, weil es zum damaligen Zeitpunkt genau das tat, was ich zum damaligen Zeitpunkt brauchte. Es gibt Ideen, um die Menschen sich versammeln, und das hat gleich mehrere Auswirkungen.
Brennpunkte
Egal ob man diesen Ansatz gut findet oder nicht, egal ob man React oder Angular mag – durch die Existenz von Frameworks bilden sich gewissermaßen Brennpunkte in der IT-Landschaft. Orte, an denen Menschen zusammen kommen, ihre Ideen einbringen und Richtlinien rund um die vermeintlich korrekte (idiomatische) Verwendung der jeweiligen Lösung erarbeiten.
Diese Richtlinien mögen uns gefallen oder nicht, sie ermöglichen einen effizienteren Austausch in Projekten und ein schnelleres Onboarding von neuen Personen. Durch die kontinuierliche Anwendung dieser Richtlinien werden sie innerhalb gewisser Grenzen laufend verbessert. Aber was, wenn man an diese Grenzen stößt und sich nicht damit abfinden will?
Dissonanz
Zu Deutsch: Unstimmigkeit, Missklang. Stell dir vor, du kannst nicht damit leben, dass AngularJS die Änderungen an Objekten periodisch und recht teuer auf den Bildschirm bringt. Ganz egal, wie viel optimiert wird, hier ist das grundlegende Konzept das Problem und irgendwann stößt man an die Grenzen des technisch Möglichen.
Wenn das ein Knockout-Kriterium ist, muss man besagten Brennpunkt verlassen, zurück ans Zeichenbrett und von Null auf neue Wege gehen. Das mag erst mal unglaublich schwer klingen, aber man hat einige gewaltige Vorteile dabei: Man weiß, was das Problem ist, wie man es nicht löst und was die Erwartungshaltungen sind.
Und nach ein paar Monaten Hin und Her, Recherche und Trial-and-Error hat man dann wahrscheinlich einen Weg, um den Anwendungsfall, an dem die vorige Idee gebrochen ist, besser umzusetzen. Um es mit den Worten von Soichiro Honda zu sagen:
„Racing improves the breed.“
Die Frage ist dann eher, ob das, was wir jetzt besser machen können, die Verbesserung überhaupt verdient hat.
Ein alter Hut?
Sind Frameworks also bloß immer neue Interpretationen von ewig alten Problemen? Nun, irgendwie schon, aber irgendwie auch nicht. Mir fällt hierzu eine Anekdote ein. Ich fand Liebeslieder immer kitschig und sinnlos, bis ich mal einen Musiker bei einer Show sagen hörte: „Natürlich wurden die Worte ‚I love you‘ schon tausende Male vertextet, natürlich ist jedes Liebeslied irgendwie gleich. Aber vielleicht, nur vielleicht, wurde es ja noch nicht mit den selben Gefühlen gesungen, die du dabei spürst. Und selbst wenn, warum sollte dich das davon abhalten, ‚I love you‘ zu sagen?“
Vielleicht können wir darüber hinweg sehen, welches Framework technisch besonders ausgefeilt ist, und einfach das verwenden, das am besten zur aktuellen Situation passt. Und wenn die aktuelle Situation bloß erfordert, eine Reihe von Formularen zu erstellen, könnte man ‚I love you‘ mal ganz ohne jegliche Schnörkel sagen. Denn der größte Brennpunkt in der IT-Landschaft sind immer noch die Webstandards.
Über die Autorin: Katja Potensky
Katja ist Software Engineer bei adesso und seit 2012 in einem professionellen Setting tätig. Sie lässt sich nicht auf einzelne Aspekte eines Systems limitieren, und hat von daher schon eine Vielzahl an Projekten in unterschiedlichsten Rollen und Teamgrößen umgesetzt. Aus der Arbeit mit unterschiedlichsten Webtechnologien hat sich ein fundierter Anspruch an Codequalität und korrektes Programmverhalten entwickelt den sie auch weitergeben möchte. Sie brennt für Code der leicht zu lesen ist und nicht bedingt die halbe Codebase im Kopf zu behalten um zu verstehen was “da gerade passiert”.
