Microsoft Cloud Deutschland

(Dieser Artikel stammt ursprünglich aus Ralfs Blog . It is also available in English !)

Microsoft bietet zusätzlich zu den mehr als 100 weltweiten Rechenzentren ab 2016 seine Azure, Office365 und Dynamic CRM Cloud Dienste auch aus Rechenzentren in Deutschland an. Das allein würde den Namen “Microsoft Cloud Deutschland” noch nicht rechtfertigen, und so richtig neu oder innovativ wäre das auch nicht. Das Einzigartige an dem Konstrukt ist, dass Microsoft quasi den Schlüssel (physisch und virtuell) abgibt, und zwar an ein deutsches Unternehmen, die T-Systems, einer Tochter der Deutsche Telekom, das die Rolle des deutschen Datentreuhänders einnehmen wird. Microsoft sperrt sich als quasi selbst aus, was den Zugriff auf Kundendaten betrifft. Wie das funktioniert? Nun, das schauen wir uns in den folgenden Absätzen etwas genauer an.

Alle Berechtigungen werden über ein rollenbasiertes Zugriffsmodell oder bekannter unter Role Based Access Control (RBAC) abgehandelt. Diese Rollen beziehen sich zum einen auf Funktionen (Leser, Teilnehmer, Administrator), zum anderen auch auf Bereiche (Server, Postfächer, Ressourcengruppen etc.). Hat man beispielsweise in Azure eine Ressourcengruppe definiert und gefüllt, sagen wir mit 2 VMs, etwas Storage, einem Netzwerk, einer externen IP, so kann mittels RBAC einem Benutzer die Administrator-Rolle für diese Ressourcengruppe zugewiesen werden. Diese Rechte wirken sich dann eben nur auf die gruppierten Ressourcen aus, nicht aber auf andere Bereiche, zum Beispiel weitere Server in anderen Gruppen, oder gar Postfächer anderer Mitarbeiter.

Standardmäßig hat Microsoft keinerlei Rechte in den Kundenbereichen. Erst wenn für einen bestimmten Anlass (Supportanfrage etc.) ein Zugriff benötigt wird, wird er – auf Antrag – dem Mitarbeiter gewährt, aber auch nur für eine bestimmte Zeit (hier kommt noch ein weiteres Feature ins Spiel, JIT, also Just-in-Time) und nur auf den benötigten Bereich. Und genau diese Rechtegewährung nimmt der Datentreuhänder vor, nicht Microsoft. Aus eigenem Antrieb hat Microsoft keine Möglichkeit, sich selbst diese Rechte zuzuweisen. Die Protokollierung dieser Rechtezuweisung findet in einem Bereich statt, auf den Microsoft ebenfalls keinen Zugriff hat. Zusätzlich hat der Datentreuhänder die Möglichkeit, sich in die Session aufzuschalten und direkt zu kontrollieren, was der Supportingenieur da so treibt.

Diese Rechtegewährung betrifft übrigens auch den physischen Zugang zu den Rechenzentren: Auch hier ist eine Genehmigung des Datentreuhänders notwendig, und zusätzlich wird ein Mitarbeiter des Datentreuhänders als Begleitung dem Microsoft-Mitarbeiter oder dem Auftragnehmer nicht von der Seite weichen und ihn in die Serverräume begleiten.

Für alle diese Fälle, in denen ein Microsoft-Mitarbeiter in Kontakt mit Kundendaten kommen könnte, bedarf es also eines Anlasses, eines definierten Bereiches, und eines definierten Zeitraumes, um den Zugriff durch den Datentreuhänder freigeschaltet zu bekommen.

Also nochmal in der Zusammenfassung:

• Hat Microsoft Zugriff auf Kundendaten? Ja, aber nur bei einem konkreten Anlass, nur auf einen definierten Bereich und nur für eine bestimmte Zeit. Und die Entscheidung darüber liegt alleinig beim deutschen Datentreuhänder.
• Kann sich Microsoft auch ohne den Datentreuhänder oder den Kunden Zugang zu den Kundendaten verschaffen? Nein!

So. Jetzt zu den etwas technischeren Fragen, zum Beispiel: wo liegen die Daten überall rum? Die Antwort ist recht einfach: Nur in diesen beiden Rechenzentren in Deutschland. Der Datenaustausch zwischen den beiden Rechenzentren (wobei jetzt mal die Zeit gekommen wäre, von Regionen zu sprechen, also von Germany Central und Germany Northeast) findet über eine eigene, von einem deutschen Provider gemietete Leitung statt, was verhindert, dass Datenpakete nach außerhalb von Deutschland geroutet werden. Es findet auch keine zusätzliche Replikation oder Backup in andere Rechenzentren, ah, sorry, Regionen statt, selbst das Azure Active Directory wird nur zwischen den beiden deutschen Regionen repliziert. Lediglich so eine Art Mini-Indextabelle wird zwischen allen Regionen repliziert, damit diese beiden deutschen Regionen keine Standalone-Lösung sind, sondern nach wie vor Teil der globalen Microsoft Azure Cloud. Diese Indextabelle hilft Azure, die Region zur Subscription zu finden (basierend auf dem Domainnamen (der ist ja eh öffentlich) und die Anfrage auf das entsprechende deutsche Rechenzentrum zu verweisen. Also keinerlei Benutzerdaten! Keine Passwörter, auch nicht als Hash oder Hash-Hash. Aus diesem Mechanismus folgt übrigens nebenbei, dass es einen Tenant nur entweder in der globalen Azure Cloud geben kann oder in der “Microsoft Cloud Deutschland”…

Zertifikate? Zugegeben, das wäre ein Weg, sich Zugang zu verschaffen, aber auch daran wurde gedacht. Zur Erklärung: Alle Kommunikation zwischen den Infrastrukturen innerhalb der Azure Cloud finden verschlüsselt mit SSL/TLS statt. Und wer hindert also Microsoft, sich einfach ein Zertifikat auszustellen und damit auf Daten zuzugreifen? Naja, auch hier: Für den Einsatz von SSL-Zertifikaten in der “Microsoft Cloud Deutschland” kommt eine externe Zertifizierungsstelle zum Einsatz. Das heißt: Microsoft beantragt ein Zertifikat für zum Beispiel einen neuen Dienst, und die Zertifizierungsstelle erstellt das Zertifikat.

Klingt gut? Stimmt! Klingt wirklich gut!