Governance und Compliance mit dem neuen SharePoint 2016 – DLP mit eDiscovery

Die Integration von lokalen und Cloud IT-Infrastrukturen ermöglicht neue Wege, wie Mitarbeiter – ob intern oder extern – zusammenarbeiten können. Das Stichwort ist HYBRID HYBRID HYBRID. Da Prozesse hierdurch nahtloser ablaufen können, wird die Abarbeitung von Aufgaben effizienter. Allerdings erfordern diese neuen Möglichkeiten auch mehr Verantwortung bei der Informations-Governance und Compliance. Damit wir diesen Herausforderungen eines hybriden SharePoint auch gerecht werden können, stellt Microsoft neue Schutzfunktionen in SharePoint 2016 und dem neuen O365 bereit.

Wir wollen uns daher in den nächsten Beiträgen anschauen, was diese neuen Funktionen können und was sie für unser Business bedeuten. Heute beginnen wir mit den neuen DLP (Data Lost Prevention – Schutz vor Datenverlust) Queries im eDiscovery und unterteilen die Serien generell in drei Punkte:

1. DLP mit eDiscovery
2. DLP im neuen Compliance Center
3. Aufbewahrungsregeln mit dem Compliance Center

Wenn Sie diese Überschriften lesen, fallen Ihnen vielleicht auch das schon lange existierende eDiscovery Center, die Site Policies oder das Records Management ein. Die Unterscheidung möchte ich kurz klar stellen.

eDiscovery:
Die eDiscovery kommt hauptsächlich aus dem ameriaknischen Raum, weil es dort oft vor Gericht um Patentstreitigkeiten und ähnliches geht. Da immer mehr digitalisiert ist, dienen auch immer häufiger solche Daten als Beweis vor Gericht. Mit der eDiscovery können wir so unseren gesamten SharePoint – und seit SP2013 auch den mit Oauth verbundenen Exchange und Project Server – nach bestimmten Stichwörtern durchsuchen und als „Legal Hold“ exportieren und als Beweis einreichen.

Site Policies:
Dies sind angewandte Richtlinien, bzw. Workflows auf die gesamten Seite, mit denen man Seiten, die eine eingestellte Zeit nicht mehr genutzt wurden, automatisch löschen lassen kann.

Records Management:
Diese Lösung setzt bei den Site Policies an und bezieht sich auf Dokumente und Objekte innerhalb der Seiten. Es ist im Prinzip eine Archivierung von Objekten, die eine bestimmte Zeit nicht genutzt wurden, aber beispielsweise zu Revisionszwecke noch aufbewahrt werden müssen. Solche Objekte werden dann entweder ganzheitlich in ein Record Center verschoben oder in der ursprünglichen Liste oder Bibliothek schreibgeschützt vorgehalten.

Aufbewahrungsregeln im Compliance Center:
Diese Funktion ist eine Erweiterung zu den Site Policies, die man so nun auch auf einzelne Objekte anwenden kann. Zudem kann man solche neuen Regeln nun standardmäßig bestimmten Seitenvorlagen zuweisen. Beispielsweise können für Projektseiten eine Aufbewahrung von 6 Monaten definiert werden, währenddessen die Besitzer jeder Team-Seite erst nach 24 Monaten ohne Modifikation an die nahende Löschung erinnert werden.

Data Lost Prevention (Verhinderung von Datenverlus):
Diese Funktionalität ist ganz neu in SharePoint 2016 und ergänzt die bisherigen Lösungen, sodass Unternehmen nun eine ganzheitliche Strategie entwickeln können, wie sie mit sensitiven Informationen im SharePoint umgehen möchten. Es ist also kein Ersatz der Lebenszyklus-Prozesse, sondern vielmehr eine Möglichkeit, die eigenen Daten gegen Datenschutzrichtlinien zu identifizieren und zu schützen.

Die DLP macht sich die SharePoint Suche zur Nutze und greift zum Identifizieren der Inhalte auf den Index zurück. Dabei wird der Inhalt gegen definierte Richtlinien, z.B. Kreditkarteninformationen, geprüft. Aber dabei soll es nicht bleiben. Für Exchange und O365 kann man bereits aus 80 verschiedenen Test-Vorlagen wählen (https://technet.microsoft.com/de-de/library/jj150541%28v=exchg.160%29.aspx?f=255&MSPPError=-2147217396). Für SharePoint 2016 OnPremise (Release Candidate) stehen uns derzeit leider nur zehn zur Vefrügung. Es ist aber zu erwarten, dass wir auch alle diese Richtlinien zur RTM oder spätestens zu einem Service Pack in der OnPremise Version erhalten werden.

Schauen wir uns nun diese Richtlinien genauer an. In der Beschreibung der PCI DSS finden wir, dass es Kreditkarteninformationen schützen soll. Auf der oben erwähnten Seite finden wir dazu folgendes:

Wir sehen, dass die DLP nach Mustern und bestimmten Schlüsselwörtern prüft. Ein sehr wahrscheinlicher Fund wird aber erst dann protokoliert, wenn bestimmte Kriterien innerhalb von 300 Zeichen gefunden wurden, in diesem Fall ist es die Prüfung der Kreditkartennummer per Luhn-Algorhythmus, der Name der Kreditkartenfirma und des Ablaufdatums. Der Vorteil daran ist, dass nur Dokumente erfasst werden, die wirklich gegen die Unternehmensrichtlinien verstoßen. Zum Beispiel ist ein Dokument, was darüber informiert, welche Kreidtkartenfirmen akzeptiert werden, sicherlich in Ordnung, wohingegen ein Dokument mit mehr als 10 Kreditkartennummern inklusive Kreditfirma und Ablaufdatum deutlich sensibler ist und dementsprechend auch so behandelt werden sollte. Die DLP hilft dabei.

Discovery vs. Policy
Bevore wir uns nun die DLP im eDiscovery anschauen, möchte ich noch kurz den Unterschied zwischen Discovery und Policy erklären.

Discovery (Offenlegung):
Aus meiner Erfahrung haben die wenigsten Firmen einen kompletten Überblick ihrer Daten. Besonders dann, wenn es um potentiell sensible Daten geht. Die Discovery ist dafür perfekt geeignet, um mithilfe von DLP Queries die bestehenden Inhalte zu scannen und der Firma einen Übebrlick darüber zu geben, in welchen Bereichen die Anwendung von Policies (Richtlinien) sinnvoll ist.

Policy:
Eine Richtlinien ist dann die logische Folge der Discovery. Haben wir also erkannt, dass sich auf bestimmten Seiten sensible Daten befinden und Unbefugte darauf Zugriff haben könnten, so wenden wir auf diese Bereiche eine Richtlinie an, damit der Zugriff auf bestehende und neu hinzugefügte Dokument beschränkt wird. Datenschutzbeauftragte können darüber hinaus noch Tipps zur Vermeidung eines Verstoßes, Email-Benachrichtigungen und das Blocken von Inhalten konfigurieren, sobald gegen eine Regel verstoßen wird. Aber dazu später mehr...

1. DLP mit eDiscovery

Kommen wir nun zur Anwendung der DLP mit dem eDiscovery Center. Als Vorraussetzung brauchen wir folgendes:

a)      Konfigurierte Search Service Application
b)      Beispieldatei mit Kreditkarteninformationen
c)      Crawl der entsprechenden Bereiche, wo die obigen Dateien liegen
d)      Site Collection mit der eDiscovery Center Vorlage

a) Konfigurierte Search Sevrice Application
Wie oben bereits erwähnt, basieren die DLP Funktionalitäten auf der SharePoint Suche.
Vorteil:
- Wir brauchen keine zusätzlichen neuen Services und Werkzeuge installieren
Nachteile:
- Echtzeit-Überwachung ist nicht möglich
- In O365 können wir den Crawl nicht forcieren

b) Wir laden unsere Beispieldokumente an einen entsprechenden Ort in SharePoint
Die Datei CC_Many.docx enthält mehrere Kreidtkarteninformationen, während die CC_One.docx nur eine enthält. Dies wird später noch eine Rolle spielen.

c) Wir navigieren zur Search Service Application und starten einen Crawl
Nachdem dieser Crawl durchgelaufen ist, wird auch unsere DLP Query auf die Informationen zugreifen können.

d) Als letzte Vorbereitung benötigen wir eine neue Site Collection mit dem eDiscovery Center als Vorlage

Nachdem unser neues eDiscovery Center erstellt wurde, wollen wir eine neue DLP Query erstellen. Übrigens, Sie können mehrere eDiscovery Center in Ihrer Farm anlegen. So können Sie Beispielsweise auch diese Aufgaben deligieren und enstprechenden Datenbesitzer können ihre Regeln selbst auf ihre Bereiche erstellen und anwenden

.

Anlegen einer DLP Query im eDiscovery Center

Bei der Auswahl der derzeit nur zehn Standard-Regeln nehmen wir die „UK Financial Data“. Der Hintergrund ist, dass diese Regel verschiedene Prüfungen anwendet und wir dies sehr schön in den Ergebnissen sehen werden.

Sehr wichtig bei dieser Auswahl ist auch noch die Konfiguration der Fundhäufigkeit. Standardmäßig werden neun Funde angezeigt. Findet die Regel also nur fünf Übereinstimmungen in einem Dokument, so wird es auch nicht als sensibel eingestuft. Dies ist eine sehr schöne manuelle Anpassung, die der Administrator zu der automatischen Gewichtung vornehmen kann.

Auf der nächsten Seite wird es spannend. Wir sehen oben links die Query, in der zu erkennen ist, dass drei verschiedene Prüfungen durchgeführt werden. Diese können wir auch manuell anpassen und somit die Häufigkeit der Funde von neun auf eins herunter setzen oder auch einzelne Checks entfernen bzw. hinzufügen. Derzeit gibt es noch keine aktuelle Liste der Checks, welche bereits unterstützt werden. Nehmen Sie jedoch eine, die noch nicht unterstützt wird, so erhalten wir beim Ausführen der Query einen Fehler.

Unter der Query-Box können wir den Bereich definieren, in dem gesucht werden soll. Dies kann entweder der gesmate SharePoint oder nur ein bestimmter Bereich sein. Ich habe die Site Collection "Accounting" gewählt.

Wichtig: Der Benutzer, der die Query ausführt, muss Lesezugriff auf alle SharePoint Seiten haben bzw. auf die Seiten, für die er Ergebnisse erhalten möchte.

Im nächsten Screenshot sehen wir in den Staistiken, welche der Prüfungen zu einem Ergebnis geführt haben. Wir können auch erkennen, dass diese Prüfungen nicht nur einzelnd, sondern auch in Kombination durchgeführt werden. Diese Statistiken helfen, meine Queries auf mein Unternehmen anzupassen, um bestmögliche Treffer zu erhalten. Im darauffolgenden ähnlichen Screenshot ist hingegen zu erkennen, dass ich die Häufigkeit der Kreditkartenfunde auf eins gesetzt habe und wir daher auch mehr Ergebnisse erhalten, denn die CC_One.docx ist nun mit dabei. Mit einem Mouse-Over über den Titel der Datei – übrigens der wahre Titel innerhalb des Dokuments wird angezeigt und nicht „CC_One.docx“ – kann ich mir weitere Metadaten dazu anzeigen lassen.

----------

Neben der Query selbst, können wir auch die Suche anhand des Zeitraums und Autor weiter eingrenzen, wenn wir möchten (oben rechts). Nun möchten wir jedoch die Ergebniss exportieren. Dazu klicken wir am unteren Ende des Dialogs auf Export und deifnieren, was in dem Export inkludiert werden soll. Wir können hierbei definieren, ob alle Versionen von gefundenen SharePoint Dokumenten und ob verschlüsselte oder nicht bekannte Dateitypen exportiert werden sollen.

Klickt man dann auf Download Results oder Download Report, so bekommen wir leider noch eine Fehlermeldung des eDiscovery Donwload Managers in dem Release Candidate. Die Application Logs des Event Viewers deuten auf ein Schema-Problem hin. Ich gehe mal davon aus, dass dies noch bis zur RTM gelöst wird, da es in der Online-Version problemlos funktioniert.

FYI:
Description: The element 'Source' in namespace 'https://schemas.microsoft.com/Discovery/ExportConfigSchema' has invalid child element 'SearchEverything' in namespace 'https://schemas.microsoft.com/Discovery/ExportConfigSchema'. List of possible elements expected: 'Endpoint, Custodians' in namespace 'https://schemas.microsoft.com/Discovery/ExportConfigSchema'.
Type: System.Xml.Schema.XmlSchemaValidationException
StackTrace:    at Microsoft.Office.Client.Discovery.ExportConfig.ValidateXmlManifest(Stream configStream)
  at Microsoft.Office.Client.Discovery.ExportConfig.Initialize(Stream configStream)
  at Microsoft.Office.Client.Discovery.SharePointExportServerFacade.get_ExportConfig()
  at Microsoft.Office.Client.Discovery.SettingsForm.LoadExportConfig()

Ein Export von SharePoint Online aus dem aktuellen O365 sieht folgendermaßen aus:

Darin werden die Seiten - und darin die Subseiten und Bibliotheken - aufgelistet, in denen ein Fund für eine entsprechende Query protokolliert wurde. Wenn Microsoft den obigen Fehler behoben hat, werden die Protokolle für SharePoint 2016 sicher ähnlich aussehen.

Das soll ein erster Überblick über die neuen DLP Funktionalitäten im eDiscovery Center sein. Sobald sich etwas mit der RTM und Public Release ändert, werde ich den Beitrag aktualisieren. In den nächsten Tagen schauen wir uns dann die DLP im Compliance Center genauer an.

Wenn Sie weitere Informationen teilen möchten, dann freue ich mich über einen Kommentar. Gefällt Ihnen der Betrag, denn freue ich mich über ein 5-Star Rating.

Herzlichen Dank und viel Spaß beim SharePointen.