Kann Microsoft meine Daten lesen?

Nach Geopolitik und Anbieter-Vertrauen kommen wir jetzt zur technischen Ebene: Cloud- und Infrastruktur

Was mit "lesen" technisch überhaupt gemeint ist

„Kann Microsoft meine Daten lesen?“

Die Frage klingt einfach. Technisch ist sie es nicht.

Was bedeutet „lesen“ in diesem Zusammenhang überhaupt?Geht es um einen einzelnen Mitarbeiter, der sich Dateien ansieht?Um automatisierte Prozesse?Um theoretische Zugriffspfade innerhalb einer Cloud-Architektur?

Und wer ist „Microsoft“?Ein Support-Mitarbeiter?Ein Administrator?Ein Entwickler?Ein automatisierter Dienst?

Bevor man Sicherheit bewertet, muss klar sein, worüber genau gesprochen wird. In der Cloud-Welt bedeutet „Daten liegen auf Microsoft-Servern“ nicht automatisch, dass sie für Menschen einsehbar sind. Zwischen physischem Speichern, logischem Zugriff und tatsächlichem Inhaltszugriff liegen mehrere technische Schutzschichten.

Wenn wir also prüfen wollen, ob Microsoft Daten „lesen“ kann, müssen wir die Frage zerlegen – in Architektur, Verschlüsselung, Isolation und administrative Zugriffsmöglichkeiten. Erst dann wird sie konkret.

Wo liegen meine Daten eigentlich?

Liegen alle Daten eines Tenants "auf einem Server"?

Wenn gefragt wird, ob Microsoft Daten „lesen“ kann, steht oft unausgesprochen ein bestimmtes Bild dahinter: Die Daten eines Unternehmens liegen als zusammenhängender Bestand auf einem Server – und wer Zugriff auf diesen Server hat, kann alles einsehen.

Technisch ist das nicht der Fall.

In einer Hyperscale-Cloud-Architektur werden Daten eines Tenants nicht als geschlossener Block gespeichert. Sie sind fragmentiert, verteilt, repliziert und logisch isoliert. Es existiert kein einzelner physischer Ort, an dem „alle Daten eines Unternehmens“ in lesbarer Form liegen.

Das hat direkte Auswirkungen auf die Kernfrage dieses Artikels:Zugriff bedeutet in der Cloud nicht, zu einem Server zu gehen und etwas zu öffnen. Zugriff ist ein definierter, kontrollierter Serviceprozess – über Identität, Autorisierung und Systemkomponenten hinweg. Erst wenn diese Ebenen zusammenspielen, entsteht eine lesbare Darstellung von Inhalten.

Die Vorstellung eines unmittelbaren, physischen Lesemechanismus greift deshalb zu kurz. Gleichzeitig ersetzt die verteilte Architektur keine Governance. Sie macht einfachen Zugriff unmöglich – sie definiert aber Prozesse, über die privilegierte Zugriffe technisch erfolgen können.

Damit verschiebt sich die Frage: Nicht „liegt es auf deren Servern?“, sondern „wie sind die Zugriffspfade gestaltet und abgesichert?“

Wie sind diese Zugriffspfade technisch geschützt?

Der Zugriff findet nicht an einem Ort statt, sondern über einen Prozess.

Daten eines Tenants liegen nicht gesammelt auf einem Server, den man betreten kann. Sie sind verteilt gespeichert, mehrfach repliziert und verschlüsselt abgelegt.

Um aus diesen verteilten Fragmenten eine lesbare Datei zu erzeugen, müssen mehrere technische Bedingungen gleichzeitig erfüllt sein.

Der Ablauf sieht – stark vereinfacht – so aus:

1. Identität: Eine eindeutig authentifizierte administrative Identität muss vorhanden sein.

2. Rolle und Berechtigung: Diese Identität muss eine konkrete Rolle besitzen, die den Zugriff überhaupt erlaubt.

3. Genehmigter Zugriffsvorgang: Der Zugriff erfolgt nicht dauerhaft, sondern im Rahmen eines definierten, genehmigten Workflows (z. B. Support- oder Incident-Prozess).

4. Schlüsselzugriff: Die passenden kryptographischen Schlüssel müssen verfügbar sein, um verschlüsselte Daten entschlüsseln zu können.

5. Service-Komponente: Ein interner Dienst setzt die verteilten Datenfragmente logisch wieder zusammen und stellt sie lesbar dar.

   
   

Erst wenn diese Elemente zusammenspielen, entsteht Klartext.

Fehlt eine dieser Ebenen, bleibt der Inhalt technisch nicht zugänglich.

Und wenn in Dir jetzt die Frage aufsteigt: "ABER Microsoft kann diesen Prozess doch sicher technisch umgehen?" --> Dann möchte ich dich ganz liebevoll zu meinem Blogartikel bzgl. Anbietervertrauen schicken. Denn dann versuchst Du gerade ein Vertrauensproblem auf der technischen Ebene zu lösen 😜.

Gibt es administrative Zugriffsmöglichkeiten?

Ja.

Ein Cloud-Anbieter kann eine Plattform dieser Größenordnung nicht betreiben, ohne privilegierte Eingriffsmöglichkeiten zu besitzen. Wartung, Incident-Analyse oder Support setzen administrative Fähigkeiten voraus.

Das bedeutet jedoch nicht automatisch Inhaltszugriff.

Administrative Plattformkontrolle umfasst zunächst:

• Infrastruktursteuerung

• Service-Konfiguration

• Systemdiagnose

• Betriebsüberwachung

  
  

Ein lesender Zugriff auf konkrete Kundendaten ist technisch davon getrennt.

Damit ein administrativer Vorgang bis auf Inhaltsebene reicht, müssen – wie zuvor beschrieben – mehrere Bedingungen erfüllt sein:

• Eine eindeutig authentifizierte privilegierte Identität

• Eine passende Rolle mit expliziter Berechtigung

• Ein genehmigter und protokollierter Zugriffsvorgang

• Zugriff auf die notwendigen kryptographischen Schlüssel

• Ein Dienst, der die verschlüsselten Datenfragmente wieder zusammensetzt

  
  

Ohne dieses Zusammenspiel entsteht kein Klartext.

Administrative Zugriffsmöglichkeiten existieren also –aber sie sind nicht gleichbedeutend mit freiem, unbegrenztem Leserechtsstatus.

Was physische Kontrolle wirklich bedeutet

„Die Server gehören Microsoft. Also kontrolliert Microsoft auch meine Daten.“

Dieser Gedanke liegt nahe. Er greift aber zu kurz.

Physische Kontrolle heißt: Microsoft betreibt die Rechenzentren und die zugrunde liegende Infrastruktur. Hardware, Netzwerk, Speicher – all das liegt in ihrer Verantwortung.

Doch aus physischem Besitz folgt kein automatischer Zugriff auf Inhalte.

Daten liegen nicht als lesbare Dateien auf einer einzelnen Maschine. Sie sind verteilt gespeichert, verschlüsselt abgelegt und logisch isoliert. Selbst wer Hardware kontrolliert, erhält dadurch keinen unmittelbaren Klartextzugang. Zwischen Infrastruktur und Inhalt liegen Identitätsprüfung, Rollenmodell und Schlüsselverwaltung.

Der Kern ist deshalb klar:

Physischer Besitz von Infrastruktur ist nicht gleichbedeutend mit inhaltlicher Verfügbarkeit von Daten.

Wer die Plattform betreibt, kontrolliert die Umgebung.Ob daraus Zugriff auf konkrete Inhalte entsteht, entscheidet jedoch die Architektur – nicht der Besitz der Server.

Zwischenfazit: Was auf dieser Ebene beantwortet werden kann - und was nicht

Auf technischer Ebene lässt sich beantworten:

• Wie Daten in einer Hyperscale-Cloud gespeichert werden

• Wie Zugriff grundsätzlich funktioniert

• Welche Hürden zwischen Infrastruktur und Inhalt liegen

• Dass physischer Besitz nicht automatisch Inhaltszugriff bedeutet

Was diese Ebene nicht beantwortet, ist eine andere Frage:

Wie viel Kontrolle habe ich als Kunde selbst? Welche zusätzlichen Schutzmechanismen kann ich aktivieren? Wie verhindere ich, dass selbst ein legitimer Prozess meine Daten lesbar macht?

Die Architektur definiert die Möglichkeiten. Das tatsächliche Schutzniveau entsteht durch die Konfiguration.

Und genau hier beginnt die Produktebene.

Im nächsten Teil geht es deshalb nicht mehr um die Cloud als solche –sondern um Microsoft Purview:

Was kann es? Wo liegen die Grenzen? Und ist es wirklich sicher??? ;)