Seit der Einführung der Datenschutz-Grundverordnung (DSGVO) steht das Thema Verschlüsselung im Fokus. Welche technischen und organisatorischen Maßnahmen sich daraus ergeben, ist besonders für Menschen ohne technischen Hintergrund meist nicht einfach zu verstehen. Wir verraten euch in diesem Deep Dive, warum Verschlüsselung so wichtig ist und welche Optionen wir bei Microsoft bieten.
Was sind die Ziele von Verschlüsselung?
Die Sicherung von Informationen und Dokumenten ist heutzutage wichtiger als je zuvor. Um sich und die eigenen Daten umfangreich zu schützen, bedarf es klarer Zielsetzungen, z.B.:
- Schutz des geistigen Eigentums vor Missbrauch und Abfluss
- Schutz von personenbezogenen Daten
- Sicherstellung der Zugriffsrechte und damit Vertraulichkeit – sowohl extern als auch intern
- Schutz vor Manipulation oder Signierung von eigenen Inhalten und Daten
Jedes dieser Ziele hat zum Teil unterschiedliche, technische Maßnahmen zur Folge, die gegebenenfalls auch durch andere Maßnahmen als Verschlüsselung erreicht werden können. Sofern dies zutrifft, sollte eine Abwägung des Risikos einerseits und die Verhältnismäßigkeit der Maßnahmen andererseits vorgenommen werden.
Formen der Verschlüsselung
Bei der Verschlüsselung von Daten kommt es auf ein Zusammenspiel von Technologien und Maßnahmen an, die von der Art der Verwendung abhängig sind. Die Formen der Verschlüsselung werden grob in drei Kategorien unterteilt: Verschlüsselung des Transportes („in transit“), der gespeicherten Daten („at rest“) und bei der Verarbeitung („in use“).
Basis-Verschlüsselung bei der Nutzung von Microsoft Cloud-Diensten
Bei der Nutzung von Microsoft Cloud-Diensten sind verschiedene Verschlüsselungsmechanismen automatisch gegeben und stellen damit in vielen Fällen einfache, aber deutliche Verbesserungen gegenüber klassischen On-Premises-Systemen dar:
- „in transit“: Darunter verstehen wir Daten, die sich im Netzwerk bewegen und zu diesem Zeitpunkt nicht verarbeitet werden. Jede Datenverbindung, die sich zur und auch innerhalb der Microsoft Cloud bewegt, wird immer nach dem „Stand der Technik“ auf dem Netzwerklayer – mittels Transport Layer Security (TLS) – verschlüsselt. Das können auch Administrator*innen bei Standard-Diensten wie Microsoft Office 365 nicht verändern. Lediglich bei bestimmten IaaS/PaaS-Diensten von Microsoft Azure hat der Betreibende eine Konfigurationsmöglichkeit, z.B. bei der Bereitstellung eines Webservers über Microsoft Azure. Hier kann der Betreibende selbst entscheiden, ob dieser per SSL/TLS geschützt wird oder nicht.
- „at rest“: So bezeichnen wir alle nicht-flüchtig gespeicherten Daten, die beispielsweise als Datei auf einer Festplatte oder als Datum in einer Datenbank abliegen. Grundsätzlich sind alle physikalischen Festplatten in der Microsoft Cloud per Bitlocker verschlüsselt. Auch hier haben die Nutzer*innen keine Einflussmöglichkeiten. Abhängig von der verwendeten Anwendung sind die spezifischen Daten des Dienstes noch einmal (oder in manchen Fällen sogar mehrmals) zusätzlich verschlüsselt. Mit beispielsweise Microsoft Exchange Online oder Microsoft SharePoint Online sind die „Kundendaten“ oder „Tenantdaten“ immer mit einem eindeutig zugewiesenen Schlüssel verbunden, auf den niemand außerhalb des Tenants Zugriff hat.
- „in use“: Besonders anspruchsvoll ist die Verschlüsselung während der Nutzung oder Verarbeitung von Daten, da dies innovative Mechanismen und fortgeschrittene Hardware verlangt. Um diesen Vorgang zukünftig zu vereinfachen, arbeiten wir aktuell daran, diese Form der Verschlüsselung für alle Dienste bereitzustellen. Weitere Informationen zur Verschlüsselung während der Nutzung gibt es hier.
Schlüsselnutzung und -verwaltung der Basis-Dienste
Die Einflussnahme für Nutzer*innen ist bei der Basis-Verschlüsselung nur begrenzt. Aus diesem Grund verlagert sich das Risiko automatisch zu Microsoft und verschlankt so den Aufwand für diejenigen, die ihre Daten mit der Verschlüsselung schützen möchten. Denn bereits mit dem ersten Nutzenden in einem Microsoft Tenant wird die Verschlüsselungsarchitektur automatisch angelegt und die verwendeten Dienste darüber bereitgestellt – wie wir in unserem Data Protection Adendum zusichern. Dies garantiert auch eine Absicherung des Schlüssels vor Dritten.
Das bedeutet, dass die Kundendaten durch ein ausgeklügeltes Berechtigungssystems mit Hilfe des bereitgestellten Schlüssels abgesichert sind und nur Berechtigte auf die Daten zugreifen können. Trotz dieser Basisverschlüsselung sollten sich Tenantbesitzer vergewissern, dass alle technischen und organisatorischen Maßnahmen getroffen sind. Wenn Nutzer*innen beispielsweise einen Link mit sensiblen Informationen teilen, dann sind diese Daten nicht in Form dieser Verschlüsselung geschützt. Das kann dazu führen, dass die Daten zweckentfremdet und somit ein Datenschutzvorfall vorliegen würde. Denn nur die ursprüngliche Speicherung und der Weg zur nutzenden Person sind an dieser Stelle verschlüsselt, nicht aber die Datei selbst. Weitere Hinweise dazu findet ihr hier.
Tabelle 1: Schlüsseloptionen und Schlüsselaktionen
Weitere Informationen gibt es hier.
Schutz des Eigentums vor Missbrauch und Abwanderung
Um die Verschlüsselung des Transports von Daten zu erreichen, bietet Microsoft 365 Lösungen wie „Microsoft Purview Information Protection“ an. Mithilfe dieser Lösungen lassen sich einzelne Emails und Dateien zusätzlich verschlüsseln und mit einem erweiterten Zugriffs- und Berechtigungsmodell versehen. Dies bedeutet, dass die Dateien in sich verschlüsselt sind und dies auch mit Hilfe eines Mechanismus bleiben. Auch ein „speichern unter“, kopieren auf USB oder ein Weiterleiten per E-Mail entfernt die Verschlüsselung und die Berechtigungen nicht. Dieses Konzept geht also deutlich über klassische „Ende-zu-Ende“-Verschlüsselungen (E2E) per S/MIME oder PGP hinaus und bietet zusätzlich erweiterte Möglichkeiten der Data Loss Prevention an, die bei E2E normalerweise nicht gegeben sind. Für die Verschlüsselung wird ebenfalls der „Microsoft Managed Key“ (MMK) verwendet, für den Microsoft die Verantwortung trägt.
Der Unterschied zwischen Customer Managed Key und Bring Your Own Key (BYOK)
Wenn entweder externe Compliance-Vorschriften oder eigene Richtlinien vorliegen, dann erfordert dies eine Verwendung von „Bring Your Own Key“ (BYOK). Das bedeutet automatisch, dass die Verantwortung für den Betrieb beim Kunden liegt. Um dieser Verantwortung gerecht zu werden, sind entsprechende kundenseitige Vorgehensweisen und die damit verbundenen Prozessen erforderlich. In der Regel stellt dies für viele unserer Kunden nicht nur einen erheblichen Aufwand dar, sondern birgt auch das Risiko, Daten unbeabsichtigt unbrauchbar zu machen. Aus diesem Grund sind entsprechend ausgebildetes Personal und ausgereifte Prozesse erforderlich.
Bei Microsoft Cloud-Diensten unterscheiden wir zwischen zwei Formen von BYOK: Customer Managed Key (CMK) und Bring Your Own Key (BYOK). Die Unterscheidung liegt in der Natur der Nutzung: Bei Customer Managed Keys geht es um die Verschlüsselung ganzer Dienste, wie z.B. bei der Verschlüsselung von SharePoint Online oder Exchange Online Mailboxen. Von Bring Your Own Key sprechen wir hingegen, wenn dieser Schlüssel für die Verschlüsselung von einzelnen Daten, Dateien und E-Mails im Kontext von Microsoft Purview Information Protection verwendet wird.
Dabei sind die technischen Mechanismen bei beiden vergleichbar, die Konfiguration jedoch unterschiedlich. Technisch wird in beiden Fällen ein Azure Key Vault (AKV) genutzt. Dort werden entweder durch die Cloud-Mechanismen oder durch angeschlossene, eigene Hardware Security Module (HSM) ein entsprechender Schlüssel bereitgestellt. Über diesen AKV werden alle notwendigen Schlüsselprozesse gesteuert.
Was ihr zur Haltung von Schlüsseln in Azure Key Vault wissen müsst
Die Schlüssel werden in Hardware Security Module (HSM), die nach FIPS 140-2 Level 3 and eIDAS Common Criteria EAL4+ zertifiziert sind, gespeichert. Dabei sind die Schlüssel für Microsoft nicht exportierbar und durch die Hardware entsprechend geschützt. Die Nutzung eines MMK, CMK oder BYOK für die Entschlüsselung und den Zugriff von Daten durch Microsoft Support-Mitarbeitenden ist dabei strengsten technischen und organisatorischen Maßnahmen unterworfen. Diese besagen:
- Es muss einen durch den/die Kund*in initiierten Support-Fall geben
- Es muss einen dokumentierten und durch einen Freigabeprozess begleiteten Grund geben, der den Zugriff auf Kundendaten durch den Microsoft Support bedingt. Dieser Zugriff ist pro Anfrage/Freigabe auf max. 4 Stunden begrenzt. Dieser Prozess ist als „Lockbox Prozess“ bekannt. In der Praxis kommen solche Fälle sehr selten vor, da die Vielzahl von Support-Fällen ohne die Kenntnisnahme von Kundendaten behoben werden können.
- (Optional) Wer 2. noch durch eine eigene Freigabe erweitern möchte, kann dies durch den sog. „Microsoft Purview Customer Lockbox Prozess“ tun.
Zugriffsschutz vor allen, außer den eigenen Mitarbeitenden
Erfahrungsgemäß sind ca. < 5 Prozent aller Daten eines Unternehmens besonders schützenswert. Denn bei unberechtigtem Zugriff auf diese Daten kann gleich das Weiterbestehen eines ganzen Unternehmens gefährdet sein. Das macht den Aufwand und die Kosten für den Schutz dieser Daten groß.
Um Schäden vorzubeugen, bietet sich Double Key Encryption (DKE) von Microsoft an. Hierbei gilt es allerdings zu beachten, dass es beim Einsatz von DKE Einschränkungen sowohl bei den nutzbaren Diensten als auch bei den nutzbaren Clients/Apps gibt. So kann DKE nur auf aktuellen Windows-Systemen genutzt werden.
Tabelle 2: OS Supported:
Neben der Einschränkung des verwendeten Betriebssystems können zudem nur unterstütze Dokumententypen ( geschützt werden, keine E-Mails oder Fremdformate. DKE umfasst also Dateien und nicht Dienste. Hinzu kommt, dass wenn diese Dokumente zentral abgelegt werden – unabhängig ob in der Microsoft Cloud (SharePoint Online oder OneDrive for Business) oder On-Premises (SharePoint oder File Share) – vor allem die Kollaborationsmöglichkeiten wie gleichzeitiges Bearbeiten oder das Teilen mit externen Gästen sowie die Suche/Indizierung nicht gegeben sind.
Das führt zu einer erheblichen Einschränkung der Nutzung und so möglicherweise zur Unzufriedenheit der Nutzer*innen. Gleichzeitig besteht das Risiko, Ransomware selbst zu produzieren. Aus diesem Grund sollte DKE nur für den Schutz hochsensibler Dokumente genutzt werden. Auch die Bereitstellung der On-Premises Komponenten für den zweiten (also den „doppelten“) Schlüssel erfordert einen hohen technischen Aufwand. Wichtig dabei: die Notwendigkeit der Ausfallsicherheit und die Recovery-Möglichkeit.
Weiterführende Informationen gibt es hier:
- Understanding Microsoft Information Protection Encryption Key Types – Microsoft Tech Community
- Encryption in Microsoft 365 – Microsoft Purview | Microsoft Docs
- Service encryption – Microsoft Purview | Microsoft Docs
- Service encryption with Microsoft Purview Customer Key – Microsoft Purview | Microsoft Docs
- Double Key Encryption (DKE) – Microsoft Purview | Microsoft Docs
- Preparing for TLS 1.2 in Office 365 and Office 365 GCC – Microsoft Purview | Microsoft Docs
- Learn about data loss prevention – Microsoft Purview | Microsoft Docs
- Microsoft Purview Customer Lockbox Prozess
- Microsoft Data Protection Addendum
Weitere Beiträge der Serie
Alle Beiträge unserer Reihe „Faktencheck Datenschutz“ gibt es hier.
Ein Beitrag von Stephanus Schulte
Cloud Solutions Architect
