SharePoint Datenklassifizierung

10. Türchen

Um gleich zu Anfang eine wahrscheinlich sehr große Erwartungshaltung zu dämpfen, eine automatische Klassifizierung von Dokumenten in SharePoint ist mit nativen Mitteln aktuell praktisch nicht möglich. Wir können nur PowerShell Skripte schreiben oder 3rd Party Anbieter verwenden. Daher soll euch der heutige Beitrag nur einen Workaround liefern, wie ihr dennoch identifizieren könnt, welche Daten in die Cloud können und welche nicht.

Ein nützliches Feature, das mit der SharePoint Enterprise Edition geliefert wird, nennt sich eDiscovery. Der eigentliche Zweck ist, dass eine SharePoint Farm nach bestimmten Suchbegriffen abgesucht wird. Alle gefundenen Treffer können nicht nur protokolliert werden, sondern die dazugehörigen Daten können auch direkt exportiert werden oder vor Änderungen geschützt werden, damit sie in ihrer originalen Form erhalten bleiben. Diese Daten könnte man dann als Beweis in einem Rechtsstreit verwenden, um z.B. bei einer Patentsverletzung zu zeigen, dass man schon länger an einer entsprechenden Lösung arbeitet, weit bevor ein Konkurrent ein Patent angemeldet hat.

Die eDiscovery beruht auf der SharePoint Suche und damit können wir nicht nur die offensichtlichen Begriffe, wie Dokumententitel, suchen, sondern auch nach dem wirklichen Inhalt der Dokumente. Dies ist entscheidend, um beispielsweise Dokumente zu identifizieren, die in ihrer Fußzeile das Wort „vertraulich“ als Indiz für die Sensibilität stehen haben.

Erstellung einer eDiscovery Query:

Bevor wir unsere Farm nach sensiblen Daten absuchen können, müssen wir eine Site Collection mit der Enterprise Vorlage „eDiscovery Center“ erstellen. Auf dieser Seite können wir dann einen neuen Fall erstellen. Jeder Fall, der aus eDiscovery Sets, Queries und Exporten bestehen kann, stellt dann im Prinzip eine Art Sub-Seite dar.

Für unser Szenario zur Vorbereitung auf eine Office 365 Migration sind die Queries interessant.

Im sich dann öffnenden Fenster ist erst einmal der Suchbegriff wichtig und die Quelle, in der gesucht werden soll. Bei der Quelle können wir einzelne Site Collections angeben. Bequemer ist direkt die Root-Site, da sie auch die Suchergebnisse aller Site Collections dieser Web Application beinhaltet. In der 2013er Version sehen wir aber leider nur eine Komplettanzahl und nicht sortiert nach Site Collection. Um also wirklich unsere Query-Ergebnisse pro Site Collection sehen zu können, müssten wir also leider in der Tat jede Site Collection einzeln zum Scope hinzufügen.

In SharePoint 2016 wurde das besser umgesetzt, da man hier als Quelle angeben kann, dass alles durchsucht werden soll.

Auswertung der Ergebnisse:

In SharePoint 2016 wird in den Ergebnissen bereits schön aufgeschlüsselt, in welcher Site Collection viele der Dokumente liegen, die unseren Suchbegriff beinhalten (siehe Screenshot oben). Dies ist im Prinzip genau das, was wir brauchen.

1. Sichere Daten: Suchen wir nach explizit sicheren Daten, also mit dem Suchbegriff „Öffentlich“ oder „Nicht vertraulich“, so erhalten wir solche Site Collections, welche wir für die Migration „verpacken“ können (siehe morgiges Türchen – ups, jetzt hab ich’s verraten… 😉 )
2. Sensible Daten: Suchen wir hingegen nach Dateien, die vertrauliche Informationen enthalten, wie z.B. „vertraulich“ oder „Gehaltsnachweis“, dann erhalten wir die Site Collections, die wir lieber noch On-Premises belassen sollten und wenden darauf gleich entsprechende Data Lost Prevention (DLP) Policies an, damit die Mitarbeiter sensibilisiert werden, dass es sich um sensitive Daten handelt (siehe mein Blogbeitrag zu Governance und Compliance mit dem neuen SharePoint 2016 – DLP im Compliance Center).

Diese schöne Übersicht haben wir leider nicht in SharePoint 2013. Da empfehle ich, die Ergebnisse zu exportieren (was aber auch in SharePoint 2016 möglich ist).

Die Ergebnisse, also die gefundenen Dateien, kann man direkt exportieren und sie anschließend in ein FileShare Online Migrationspaket verpacken, wie gestern in der FileShare zu O365 High Speed Migration erklärt. Ich persönlich finde, dass dieser Ansatz aber zusätzliche Komplexität erzeugt, weil so einzelne Dateien in der Cloud liegen, andere wieder nicht, die zuvor gemeinsam an einem Ort lagen. Daher dient dieser Workaround nur für sehr spezielle Szenarien.

Interessanter ist jedoch die Möglichkeit, den Report zu exportieren. Damit erhalten wir eine CSV-Liste, die uns alle gefunden Dokumente anzeigt. So können wir, wie schon einen Schritt zuvor mit SharePoint 2016, die Site Collections identifizieren, deren Inhalte entweder noch nicht oder doch schon in die Cloud migriert werden können – je nach Suchbegriff.

Empfehlung:

Diese Workarounds funktionieren ab SharePoint 2010. (Die PowerShell High Speed Migration funktioniert aber erst ab SharePoint 2013 Inhalten). Mit SharePoint 2016 kommen die einfachere Verwaltung sowie DLP Queries hinzu, die uns die Vorbereitung auf eine Online Migration weiter vereinfachen. Nichts desto trotz ist dieser Ansatz nur für sehr eingeschränkte Migrationsszenarien nützlich. Stattdessen empfehle ich hier den Microsoft FastTrack Service oder noch besser 3rd Party Anbieter. weil diese noch weniger Einschränkungen haben und direkte Migrationspfade auch ab SharePoint 2007 bieten.

Für einen Überblick der gespeicherten Daten in meiner Farm und damit etwas mehr Licht in meinen „Dark Data“ kann ich diesen Ansatz dennoch empfehlen als erste Vorbereitung auf eine Online Migration. Denn wenn ich damit sichere Daten und Site Collections identifiziert habe, kann ich diese bereits in die Cloud über die High Speed Migration API migrieren. Wie man diese bestimmten Inhalte oder eine gesamte Farm in die Cloud migriert, erfahren wir morgen.

Happy „SharePointing“!

Zur O365Adventskalender Übersicht