To key or not to key – that is (not) the question!

OMG jetzt wird er poetisch!
Nun ja – ich greife ja öfter aktuelle Themen aus meinem Arbeitsalltag auf – und das Thema „Verschlüsselung“ und wie damit eine Organisation umgehen sollte, fühlt sich für mich oftmals poetisch und/oder philosophisch an.

Update: Mittlerweile ist dieser Artikel auch offiziell auf der Faktencheck Übersicht von Microsoft erschienen:
https://aka.ms/verschluesselung

Daher möchte ich das Thema mal aus meinem Blickwinkel beleuchten:

Agenda

1. Verschlüsseln von „was“ genau denn?
2. Verschlüsselungsoptionen bei M365
3. Microsoft Managed Key (MMK)
4. Customer Key (CK)
5. Bring your own key (BYOK)
6. Double Key Encryption (DKE)
7. Risiken von BYOK and beyond
8. Fazit
9. Anhang

Verschlüsseln von „was“ genau denn?

Oft höre ich: „wir müssen verschlüsseln!“ und meine Reaktion darauf ist dann immer: „was denn genau und warum?“ -> *Ruhe* -> „ähm…“

Das zeigt, dass hier viele Unklarheiten existieren.
Ganz allgemein gesprochen gibt es drei Ansatzpunkte für Verschlüsselung:

1. at rest / ruhende Daten
2. in transit / Daten während des Transfers
3. in use / Daten während der Verarbeitung

Und damit noch nicht genug, diese drei Themen lassen sich noch weiter unterteilen in z.B. „ist der Datenträger verschlüsselt und/oder ist das Datum als solches in sich verschlüsselt?“

Vor allem finde ich immer wieder spannend, dass die Verschlüsselungsthematik oftmals nur in Verbindung mit „ob/wie gehen wir in die Cloud“ hochgehoben wird.
Daher – und ihr kennt mich – bin ich da auch immer direkt und etwas unangenehm in dem ich frage:
„Ok, wie macht ihr das denn heute? Welche Verschlüsselung nutzt ihr für eure SQL Server? Und auf dem Netzwerk – macht ihr da IPSEC oder was anderes? Und wie schützt ihr eure Netzwerksegmente und vor allem insg. auch eure Identitäten?“
Ja, manchmal müssen Fragen auch weh tun, damit man danach dann gemeinsam an Lösungen arbeiten kann! #challengerapproach
Btw. wer auf meine Fragen keine Antwort hat, der darf gerne noch mal die DSGVO lesen, denn die macht da keinen Unterschied ob Cloud oder on-premises! ?

Aber zurück zu dem, was „eh da“ ist:
Bei der Nutzung von Microsoft Cloud Diensten ist IMMER folgendes sichergestellt und erlaubt daher grade bei dem Thema Verschlüsselung einen „Fast Start“ auch oder grade beim Thema DSGVO:

1. Data-in-transit: Netzwerkverschlüsselung: jegliche Verbindung von zwei Komponenten ist immer mind. durch TLS transport-verschlüsselt
2. Data-at-rest: Jeder Datenträger ist bei den Cloud Diensten IMMER verschlüsselt, z.B. mittels Bitlocker
3. Data-at-rest: Jeder Dienst verschlüsselt innerhalb der Tenantgrenze die Tenantdaten, also z.B. die Exchange Datenbank, die SharePoint Datenbank und dort gespeicherten Daten durch den MMK.

Gegen diese Verschlüsselung kann man sich auch nicht „wehren“ oder etwas falsch machen, weil wie gesagt, dies findet IMMER statt!

Verschlüsselungsoption bei Microsoft 365

Welche Möglichkeiten gibt es nun die Verschlüsselung zu erweitern?
Dabei möchte ich gar nicht so sehr auf die Technologie (z.B. Microsoft Information Protection), sondern mehr auf die verwendeten Schlüssel eingehen:

1. Data-in-Transit / Data-at-rest für dedizierten Content (Dateien, Emails):
   1. Microsoft Managed Key
   2. Bring-your-own-key (BYOK)
   3. Double Key Encryption (DKE)
2. Data-at-rest für Services/Service-Encryption:
   1. Microsoft Managed Key
   2. Customer Key

Ich werde in den nachfolgenden Absätzen die einzelnen Möglichkeiten durchgehen und beschreiben.

Microsoft Managed Key (MMK)

Bei dem Thema Microsoft Managed Key geht es im Grunde genommen darum, dass die Schlüsselverwaltung und alle damit verbundenen Verantwortungen bei Microsoft liegen.
Das bedeutet insb., dass alle Prozesse – sowohl technischer, als auch organisatorischer Natur – bei Microsoft liegen.

Prozesse welche hier u.a. eine Rolle spielen:

1. Bereitstellung
2. Verfügbarkeit
3. Sicherheit
4. Life-Cycle-Management, incl. Rollover, Revocation, etc.
5. Desaster Recovery

Man könnte es auch vereinfacht „Key as a Service“ (KaaS, nicht zu verwechseln mit dem niederländischen Pendant!) nennen.

Dieser KaaS lässt sich sowohl für die Service Encryption, als auch für die individuelle Verschlüsselung von Inhalten, also Emails und/oder Dokumenten jeglicher Art, verwenden.

Diese MMKs sind ein-eindeutig dem orginären Tenant zugeordnet und können – abgesichert durch entsprechende technische und organisatorische Maßnahmen (TOM) – auch nur in diesem Tenantkontext verwendet werden!

Ein Export ist ebenfalls durch TOMs (insb. Verwendung von zertifizierten HSMs) nicht möglich und der Gefahr von staatlichen Zugriffen begegnen wir durch vertragliche Zusicherungen im Data Privacy Addendum (DPA, Abschnitt „Disclosure of Processed Data“) und den daraus resultierenden Tätigkeiten und Maßnahmen.

Customer Key

Der „Customer Key“ bezieht sich ausschließlich auf die Service Encryption, also auf die Data-at-Rest der Services selber.

Customer Key kann als eine Form des Bring-your-own-Key (BYOK) angesehen werden, u.a. um Verwechslungen zu vermeiden wurde dieser Name eingeführt.

Das grobe Vorgehen bei CK/BYOK sieht so aus, dass Azure Key Vaults (AKV) benutzt werden (wegen Redundanz bitte mind. 2! 😉 ) um den Key bereitzustellen und dieser dann durch die Services konsumiert wird.

D.h., dass die „Steuerung“ des Schlüssels über AKV passiert und dementsprechend viele der o.g. Prozesse in die Verantwortung des AKV Owners, sprich des Microsoft Kunden wandert. Mit allen Vor- wie Nachteilen! (siehe unten)

Die Keys können dabei über AKV generiert werden, oder über vorhandene HSMs importiert werden. Bei der Verwendung von einer eigenen HSM steigt natürlich der Grad der Verantwortlichkeit weiter an (=> insb. Verfügbarkeit und das Keymanagement, Desaster Recovery auf der on-premises Seite!).

Um einen Customer Key zu nutzen müssen dann für die entsprechenden User sog. Data Encryption Policies erstellt und gemanaged werden.

Die genaue Vorgehensweise würde den Rahmen hier sprengen, ist aber hier nachzulesen. Spoiler: nicht mal eben so gemacht! 😉

Und noch ein Lizenz Hinweis: für die Nutzung von Customer Key (und auch DKE) wird eine entsprechende Lizenz innerhalb von „Information Protection and Government“, bzw. Office E5 oder Microsoft 365 E5 Compliance benötigt:

…und außerdem natürlich noch die Subscription Kosten für die AKVs!

Bring your own Key (BYOK)

Bei BYOK handelt es sich um die Steuerung des Schlüssels für die Verwendung von Microsoft Information Protection (MIP), also der eigentlichen Datei- bzw. Contentverschlüsselung.

Dies ist sehr ähnlich zu Customer Key, daher nur hier der Link auf die Dokumentation: der einzige Unterschied ist, dass der Key nicht der Service Encryption zugewiesen wird, sondern MIP/AIP.

Danach können dann die entsprechenden Inhalten, Dateien, Emails durch die vorgesehenen Label+Labelpolicies verschlüsselt werden. Das Vorgehen ist identisch mit dem Labeling/Verschlüsselung bei MMK, lediglich muss eben vorher die Schlüsselzuweisung erfolgt sein.

Eine per UI gesteuerte Auswahl des Schlüssels, wie es früher bei AIP über das Azure Portal möglich war, ist heute nicht mehr vorgesehen.

Double Key Encryption (DKE)

„Die Compliance Regeln erzwingen, dass wir für alles die stärkste Verschlüsselung verwenden und wir zwingend auch die Schlüsselverwaltung on-premises machen müssen.“
– nun, ich bin kein Rechtsanwalt, kann daher auch keine Rechtsberatung durchführen, aber meine persönliche Rechtsauffassung ist eine andere.

Die mir bekannten Gesetze und Verordnungen schreiben das imho nicht vor. Natürlich muss ich – durchaus auch abhängig von den von mir verwendeten Daten(typen/klassen) unterschiedliche Sicherheitsmechanismen zum Einsatz bringen, aber das o.g. Zitat gehört nicht zu meinem Verständnis der Erfüllung der rechtlichen Anforderungen.

Ja, es gibt compliance Anforderungen die besagen, dass das Schlüsselmanagement durch den Kunden zu bewerkstelligen ist – aber dafür ist CK/BYOK in den mir bekannten Fällen völlig ausreichend.

Die Dokumentation zu DKE sagt:

If your organizations have any of the following requirements, you can use DKE to help secure your content:

• You want to ensure that only you can ever decrypt protected content, under all circumstances.
• You have regulatory requirements to hold keys within a geographical boundary. All of the keys that you hold for data encryption and decryption are maintained in your data center.

Das bedeutet aber auch gleichzeitig, dass ich mir VORHER Gedanken darüber gemacht habe, was denn die tatsächlichen Anforderungen an meine Datenklassen sind
=> Ohne Datenklassifizierung ist ein sinnvoller Einsatz von DKE NICHT MÖGLICH!

Und ergänzend zu der Abbildung 4: die Notwendigkeit für DKE verschlüsselte Dokumente liegt in der Regel bei <1% der Daten – wenn überhaupt!

Denn, das organisatorische Risiko ist so dermaßen groß, dass man es sich nicht nur zwei, sondern eher 10 oder 100 mal überlegen sollte, ob man diesen Weg WIRKLICH einschlagen möchte!

Wichtig: Die Nutzung von DKE ist aktuell auch nur mit dem entsprechenden UL Client möglich und damit zum jetzigen Zeitpunkt auch nicht auf Systemen wie iOS oder Android möglich!

Die Lizenzanforderungen für DKE entsprechen denen von Customer Key (siehe Abb. 3).
Die zusätzlichen Kosten für HSMs, Security, Prozesse, Headcount, etc. sind allerdings die, die in diesem Fall relevant sind!

Außerdem – auch das wird gerne übersehen – hat die Verwendung von DKE weitreichende Einschränkungen zur Folge:

services that you can’t use with DKE encrypted content. For example:

• Transport rules including anti-malware and spam that require visibility into the attachment
• Microsoft Delve
• eDiscovery
• Content search and indexing
• Office Web Apps including coauthoring functionality

Any external applications or services that are not integrated with DKE through the MIP SDK will be unable to perform actions on the encrypted data.

Alleine auch diese Einschränkungen sind für viele Ziele, die für die Einführung von Cloud gesetzt wurden, das K-O! (Z.B. „bessere Zusammenarbeit“, „Synergieeffekte“, „Hybride Arbeitskonzepte“, …)

Risiken von BYOK and beyond

Tja, jetzt kommen wir zum ‚casus knaxus‘ wie eine meiner Lehrerinnen immer zu sagen pflegte.

Beim Lesen der vorangegangenen Abschnitte sollte schon ein gewisser Eindruck der Risiken entstanden sein und ich fasse diese mal zusammen:

1. Mit der Übernahme der Schlüsselverwaltung wird auch das Risiko von Microsoft zum Kunden übertragen. Insb. wenn die Schlüsselverwaltung durch HSMs gesteuert ‚von zu Hause‘ aus erfolgt.
2. Die Verwaltung von Schlüsselt erfordert ein erhebliches Maß an
   1. technischen Kenntnissen
   2. ausgeklügelte und vor allem auch getestete Prozessen für u.a. Desaster Recovery bzw. Desaster Response: „welche zwei Personen werden Samstagsnacht um 2:15h geweckt, wenn es ein Problem mit dem Schlüssel gibt und können aus zwei unabhängigen Safes die beiden Teile des Recovery Keys abholen und an einem Ort kombinieren um den Recovery Prozess zu starten?“
      D.h., dass insb. der Recovery Prozess eine ernstzunehmende Herausforderung für so gut wie jeden Kunden darstellt!
   3. Securitymaßnahmen zur Absicherung – physikalisch wie auch technologisch – der Schlüsselinfrastruktur.
      Alleine bei dem Punkt sollte in jedem Kopf die Alarmsirene losgehen!
      Die meisten Kunden sind (leider) noch nicht mal in der Lage sich vor Ransomware (btw. „kein Mitleid mit Ransomware!“) zu schützen, wie soll dann eine derart kritische Infrastruktur geschützt werden/sein?
   4. TOMs zur Eingrenzung von (unbeabsichtigtem) Fehlverhalten.
      Mitte November 2021 ist öffentlich geworden, dass dem BSI per Email ein private Key abhanden gekommen ist.
      Das alleine ist schon unschön und zeigt, dass hier offensichtlich notwendige TOMs fehlten um dies zu verhindern.
      Noch viel schlimmer ist aber, wie dann mit der Situation umgegangen wurde und zeigt mindestens eben so eindrücklich, dass der obige Punkt 2 nicht ausreichend berücksichtigt wurde, nämlich: „Was muss passieren, wenn mein Schlüssel kompromitiert wurde!?“
      => wenn noch nicht einmal das BSI in der Lage ist ihr Schlüsselmanagement sicher zu gestalten, … den Rest der Frage spare ich mir! 😉
   5. Backup!?
3. Sollte also etwas mit meinem Schlüssel, bzw. der Infrastruktur passieren, so dass ich nicht mehr in der Lage bin den Schlüssel wiederherzustellen, dann habe ich selber für eine Ransomware Situation gesorgt, nur mit dem Nachteil, dass ich niemandem Bitcoins für die Entschlüsselung schicken könnte (btw. das ist eh absolut nicht empfohlen!), selbst wenn ich wollte!

Fazit

Vor der Entscheidung der Form des Keymanagements sollte zwingend eine ausreichend bewusste Abwägung der Risiken erfolgen!
„Der Datenschützer hat irgendwo gelesen, dass es notwendig ist“ reicht hier bei weitem nicht für die Entscheidung für BYOK aus!

Es mag Situationen geben, die zu dem Schluss kommen „ja, ich muss es selber machen“ (Stichwort externe Compliance Anforderungen) – dann müssen aber auch die entsprechenden Risiken akzeptiert werden.

Ich glaube aber, dass in den meisten Fällen das unternehmerische Risiko und die notwendigen Aufwendungen bei einer BYOK Nutzung unterschätzt werden und daher auch nicht eingegangen werden sollten, denn das Risiko übersteigt den Nutzen um ein Vielfaches!

Für eine umfängliche Risikobetrachtung empfehle ich dringend auch die Einbeziehung des aktuellen Data Privacy Addendum (DPA) und die Nutzung der ggf. notwendigen Zusatzvereinbarung zur Übernahme der neuesten Version -> bitte in einem solchen Fall mit dem Account Team oder dem Lizenzgeber sprechen.

Microsoft wird Dritten Folgendes nicht bereitstellen: (a) einen direkten, indirekten, pauschalen oder uneingeschränkten Zugriff auf verarbeitete Daten; (b) für die Sicherung der verarbeiteten Daten verwendete Verschlüsselungsschlüssel für die Plattform, oder die Möglichkeit, eine solche Verschlüsselung zu umgehen; oder (c) den Zugang zu verarbeitete Daten, wenn Microsoft bekannt ist, dass diese Daten für andere als die in der betreffenden Anfrage Dritter angegebenen Zwecke verwendet werden sollen.

Microsoft DPA 09/2021

Anhang

Links

• Understanding Microsoft Information Protection Encryption Key Types – Microsoft Tech Community
• What is Double Key Encryption and how does it work – YouTube

Lizenzübersicht:

Supportete Plattformen