Freigeben über

Verschlüsselung für SharePoint und OneDrive, Microsoft Teams und Exchange

  • Artikel

Microsoft 365 ist eine äußerst sichere Umgebung, die umfassenden Schutz auf mehreren Ebenen bietet: Physische Rechenzentrumssicherheit, Netzwerksicherheit, Zugriffssicherheit, Anwendungssicherheit und Datensicherheit.

SharePoint und OneDrive

Alle Kundendateien in SharePoint werden durch eindeutige Schlüssel pro Datei geschützt, die immer exklusiv für einen einzelnen Mandanten sind. Die Schlüssel werden entweder vom SharePoint-Dienst erstellt und verwaltet, oder wenn Kundenschlüssel von Kunden verwendet, erstellt und verwaltet werden. Wenn eine Datei hochgeladen wird, wird die Verschlüsselung von SharePoint im Kontext der Uploadanforderung ausgeführt, bevor sie an Azure Storage gesendet wird. Wenn eine Datei heruntergeladen wird, ruft SharePoint die verschlüsselten Kundendaten basierend auf dem eindeutigen Dokumentbezeichner aus Azure Storage ab und entschlüsselt die Kundendaten, bevor sie an den Benutzer gesendet werden. Azure Storage hat keine Möglichkeit, die Kundendaten zu entschlüsseln oder zu identifizieren oder zu verstehen. Die gesamte Verschlüsselung und Entschlüsselung erfolgt in denselben Systemen, die die Mandantenisolation erzwingen, die Microsoft Entra ID und SharePoint sind.

Mehrere Workloads in Microsoft 365 speichern Daten in SharePoint, einschließlich Microsoft Teams, das alle Dateien in SharePoint speichert, und OneDrive, das SharePoint für die Speicherung verwendet. Alle in SharePoint gespeicherten Kundendaten werden verschlüsselt (mit einem oder mehreren AES-256-Bit-Schlüsseln) und wie folgt über das Rechenzentrum verteilt. (Jeder Schritt dieses Verschlüsselungsprozesses wird fips 140-2 Level 2 überprüft. Weitere Informationen zur FIPS 140-2-Konformität finden Sie unter FIPS 140-2 Compliance.)

  • Jede Datei wird je nach Dateigröße in einen oder mehrere Blöcke aufgeteilt. Jeder Block wird mit einem eigenen eindeutigen AES-256-Bit-Schlüssel verschlüsselt.

  • Wenn eine Datei aktualisiert wird, wird das Update auf die gleiche Weise behandelt: Die Änderung wird in einen oder mehrere Blöcke aufgeteilt, und jeder Block wird mit einem separaten eindeutigen Schlüssel verschlüsselt.

  • Diese Blöcke – Dateien, Dateiteile und Aktualisierungsdelta – werden als Blobs in Azure Storage gespeichert, die nach dem Zufallsprinzip auf mehrere Azure-Speicherkonten verteilt werden.

  • Der Satz von Verschlüsselungsschlüsseln für diese Segmente von Kundendaten wird selbst verschlüsselt.

    • Die Schlüssel, die zum Verschlüsseln der Blobs verwendet werden, werden in der SharePoint-Inhaltsdatenbank gespeichert.
    • Die Inhaltsdatenbank wird durch Datenbankzugriffssteuerungen und Verschlüsselung ruhender Daten geschützt. Die Verschlüsselung erfolgt mithilfe von Transparent Data Encryption (TDE) in Azure SQL-Datenbank. (Azure SQL Database ist ein universeller relationaler Datenbankdienst in Microsoft Azure, der Strukturen wie relationale Daten, JSON, räumliche und XML unterstützt.) Diese Geheimnisse befinden sich auf der Dienstebene für SharePoint, nicht auf Mandantenebene. Diese Geheimnisse (manchmal auch als master Schlüssel bezeichnet) werden in einem separaten sicheren Repository gespeichert, das als Schlüsselspeicher bezeichnet wird. TDE bietet Sicherheit im Ruhezustand sowohl für die aktive Datenbank als auch für die Datenbanksicherungen und Transaktionsprotokolle.
    • Wenn Kunden den optionalen Schlüssel angeben, wird der Kundenschlüssel in Azure Key Vault gespeichert, und der Dienst verwendet den Schlüssel zum Verschlüsseln eines Mandantenschlüssels, der zum Verschlüsseln eines Standortschlüssels verwendet wird, der dann zum Verschlüsseln der Schlüssel auf Dateiebene verwendet wird. Im Wesentlichen wird eine neue Schlüsselhierarchie eingeführt, wenn der Kunde einen Schlüssel bereitstellt.

  • Die zuordnung, die zum erneuten Zusammenstellen der Datei verwendet wird, wird in der Inhaltsdatenbank zusammen mit den verschlüsselten Schlüsseln getrennt von dem master Schlüssel gespeichert, der für die Entschlüsselung erforderlich ist.

  • Jedes Azure-Speicherkonto verfügt über eigene eindeutige Anmeldeinformationen pro Zugriffstyp (Lesen, Schreiben, Aufzählen und Löschen). Jeder Satz von Anmeldeinformationen wird im sicheren Schlüsselspeicher aufbewahrt und regelmäßig aktualisiert. Wie oben beschrieben, gibt es drei verschiedene Arten von Speichern, die jeweils über eine unterschiedliche Funktion verfügen:

    • Kundendaten werden als verschlüsselte Blobs in Azure Storage gespeichert. Der Schlüssel zu jedem Segment von Kundendaten wird verschlüsselt und separat in der Inhaltsdatenbank gespeichert. Die Kundendaten selbst enthalten keinen Hinweis darauf, wie sie entschlüsselt werden können.
    • Die Inhaltsdatenbank ist eine SQL Server-Datenbank. Sie enthält die Zuordnung, die erforderlich ist, um die in Azure Storage gespeicherten Kundendatenblobs zu finden und neu zu erstellen, sowie die Schlüssel, die zum Verschlüsseln dieser Blobs erforderlich sind. Der Schlüsselsatz wird jedoch selbst verschlüsselt (wie oben erläutert) und in einem separaten Schlüsselspeicher gespeichert.
    • Der Schlüsselspeicher ist physisch von der Inhaltsdatenbank und dem Azure-Speicher getrennt. Sie enthält die Anmeldeinformationen für jeden Azure-Speichercontainer und den master Schlüssel für den Satz verschlüsselter Schlüssel in der Inhaltsdatenbank.

Jede dieser drei Speicherkomponenten – der Azure-Blobspeicher, die Inhaltsdatenbank und der Schlüsselspeicher – ist physisch getrennt. Die Informationen in einer der Komponenten sind allein unbrauchbar. Ohne Zugriff auf alle drei Ist es unmöglich, die Schlüssel für die Blöcke abzurufen, die Schlüssel zu entschlüsseln, um sie nutzbar zu machen, die Schlüssel mit den entsprechenden Blöcken zu verknüpfen, jeden Block zu entschlüsseln oder ein Dokument aus seinen bestandteilen Blöcken zu rekonstruieren.

BitLocker-Zertifikate, die die physischen Datenträgervolumes auf Computern im Rechenzentrum schützen, werden in einem sicheren Repository (dem SharePoint-Geheimnisspeicher) gespeichert, das durch den Farmschlüssel geschützt ist.

Die TDE-Schlüssel, die die Pro-Blob-Schlüssel schützen, werden an zwei Speicherorten gespeichert:

  • Das sichere Repository, das die BitLocker-Zertifikate enthält und durch den Farmschlüssel geschützt ist. Und
  • In einem sicheren Repository, das von Azure SQL-Datenbank verwaltet wird.

Die Anmeldeinformationen, die für den Zugriff auf die Azure-Speichercontainer verwendet werden, werden auch im SharePoint-Geheimnisspeicher gespeichert und bei Bedarf an jede SharePoint-Farm delegiert. Bei diesen Anmeldeinformationen handelt es sich um Azure Storage SAS-Signaturen mit separaten Anmeldeinformationen, die zum Lesen oder Schreiben von Daten verwendet werden, und deren Richtlinie angewendet wird, sodass sie alle 60 Tage automatisch ablaufen. Unterschiedliche Anmeldeinformationen werden zum Lesen oder Schreiben von Daten (nicht beides) verwendet, und SharePoint-Farmen erhalten keine Berechtigungen zum Aufzählen.

Hinweis

Für Office 365 US Government-Kunden werden Datenblobs in Azure U.S. Government Storage gespeichert. Darüber hinaus ist der Zugriff auf SharePoint-Schlüssel in Office 365 US-Regierung auf Office 365 Mitarbeiter beschränkt, die speziell überprüft wurden. Mitarbeiter des Betriebs von Azure U.S. Government haben keinen Zugriff auf den SharePoint-Schlüsselspeicher, der zum Verschlüsseln von Datenblobs verwendet wird.

Weitere Informationen zur Datenverschlüsselung in SharePoint und OneDrive finden Sie unter Datenverschlüsselung in SharePoint und OneDrive.

Auflisten von Elementen in SharePoint

Listenelemente sind kleinere Blöcke von Kundendaten, die ad hoc erstellt werden oder die sich innerhalb einer Website dynamischer befinden können, z. B. Zeilen in einer vom Benutzer erstellten Liste, einzelne Beiträge in einem SharePoint-Blog oder Einträge auf einer SharePoint-Wiki-Seite. Listenelemente werden in der Inhaltsdatenbank (Azure SQL-Datenbank) gespeichert und mit TDE geschützt.

Verschlüsselung von Daten während der Übertragung

In OneDrive und SharePoint gibt es zwei Szenarien, in denen Daten in die Rechenzentren gelangen und diese verlassen.

  • Clientkommunikation mit dem Server : Für die Kommunikation mit SharePoint und OneDrive über das Internet werden TLS-Verbindungen verwendet.
  • Datenverschiebung zwischen Rechenzentren : Der Hauptgrund für das Verschieben von Daten zwischen Rechenzentren ist die Georeplikation, um die Notfallwiederherstellung zu ermöglichen. Beispielsweise werden SQL Server-Transaktionsprotokolle und BLOB-Speicher-Deltas entlang dieser Pipe übertragen. Obwohl diese Daten bereits über ein privates Netzwerk übertragen werden, sind sie mit der best-in-class-Verschlüsselung weiter geschützt.

Exchange

Exchange verwendet BitLocker für alle Postfachdaten, und die BitLocker-Konfiguration wird unter BitLocker für Verschlüsselung beschrieben. Die Verschlüsselung auf Dienstebene verschlüsselt alle Postfachdaten auf Postfachebene.

Zusätzlich zur Dienstverschlüsselung unterstützt Microsoft 365 den Kundenschlüssel, der auf der Dienstverschlüsselung basiert. Der Kundenschlüssel ist eine von Microsoft verwaltete Schlüsseloption für die Exchange-Dienstverschlüsselung, die auch in der Roadmap von Microsoft enthalten ist. Diese Verschlüsselungsmethode bietet einen erhöhten Schutz, den BitLocker nicht bietet, da sie die Trennung von Serveradministratoren und den kryptografischen Schlüsseln ermöglicht, die für die Entschlüsselung von Daten erforderlich sind, und da die Verschlüsselung direkt auf die Daten angewendet wird (im Gegensatz zu BitLocker, das die Verschlüsselung auf dem logischen Datenträgervolume anwendet), bleiben alle Kundendaten, die von einem Exchange-Server kopiert wurden, verschlüsselt.

Der Bereich für die Exchange-Dienstverschlüsselung sind Kundendaten, die in Exchange im Ruhezustand gespeichert werden.

Microsoft Teams

Teams verwendet TLS und MTLS zum Verschlüsseln von Chatnachrichten. Der gesamte Datenverkehr zwischen den Servern erfordert MTLS, und zwar unabhängig davon, ob die Daten innerhalb des internen Netzwerks verbleiben oder den internen Netzwerkumkreis verlassen.

In dieser Tabelle sind die protokolle zusammengefasst, die von Teams verwendet werden.

Datenverkehrstyp Verschlüsselt von
Server-zu-Server MTLS
Client-zu-Server (z. B. Chat und Anwesenheit) TLS
Medienflüsse (z. B. Audio- und Videofreigabe von Medien) TLS
Audio- und Videofreigabe von Medien SRTP/TLS
Signalisierung TLS

Medienverschlüsselung

Der Mediendatenverkehr wird mit Secure RTP (SRTP) verschlüsselt, einem Profil von Real-Time Transport Protocol (RTP), das Vertraulichkeit, Authentifizierung und Replay-Angriffsschutz für RTP-Datenverkehr bietet. SRTP verwendet einen Sitzungsschlüssel, der mithilfe eines sicheren Zufallszahlengenerators generiert wird und über den SIGNAL-TLS-Kanal ausgetauscht wird. Client-zu-Client-Mediendatenverkehr wird über eine Client-zu-Server-Verbindungssignalisierung ausgehandelt, aber beim direkten Wechsel von Client zu Client mithilfe von SRTP verschlüsselt.

Teams verwendet ein auf Anmeldeinformationen basierendes Token für den sicheren Zugriff auf Medienrelays über TURN. Medienrelays tauschen das Token über einen TLS-gesicherten Kanal aus.

FIPS

Teams verwendet FIPS-konforme Algorithmen (Federal Information Processing Standard) für den Austausch von Verschlüsselungsschlüsseln. Weitere Informationen zur Implementierung von FIPS finden Sie unter Federal Information Processing Standard (FIPS) Publication 140-2.