Dieser Artikel ist Teil unserer Serie über digitale Souveränität in Europa. Diesmal schauen wir auf das Sovereign Control Panel, das langsam in Azure auftaucht. Es befindet sich noch in der Preview, daher aktualisieren wir diesen Artikel, sobald Microsoft weitere Funktionen ergänzt.
Souveränitätskontrollen in Azure einzurichten ist nicht mehr besonders neu. Sie können Regionen mit Azure Policy einschränken, Customer Managed Keys vorschreiben, Confidential Computing für die Workloads einsetzen, die es brauchen, und die Umgebung auf einer Sovereign Landing Zone aufbauen.
Schwieriger wird es, wenn jemand Sie bittet nachzuweisen, dass all diese Kontrollen tatsächlich vorhanden sind.
Diese Nachweise verteilen sich meist über verschiedene Systeme wie Azure Policy, Defender for Cloud und die Konfiguration einzelner Ressourcen. Es mag alles vorhanden sein, aber jemand muss es vor einem Audit, einem Assessment oder einer Ausschreibung trotzdem zusammentragen und erklären, was es bedeutet.
Microsoft erkennt dieses Problem auch in der eigenen Dokumentation an. "Regulierte Organisationen wenden oft mehr Aufwand dafür auf nachzuweisen, dass Kontrollen vorhanden sind, als für die Umsetzung der Kontrollen selbst." Das Sovereign Control Panel soll genau diesen Teil erleichtern.
Eine einzige Sicht, mit neuem Namen
Als Microsoft vor gut einem Jahr seine Sovereign Public Cloud ankündigte, zusammen mit Data Guardian und External Key Management, hieß diese Funktionalität noch Regulated Environment Management. Diesen Namen haben auch wir in unserem früheren Artikel über Microsofts souveräne Lösungen verwendet.
Inzwischen hat Microsoft sie in Sovereign Control Panel, kurz SCP, umbenannt. Das ist bei der Suche nach Informationen nützlich zu wissen, denn ein großer Teil der vorhandenen Dokumentation und Berichterstattung nutzt weiterhin den alten Namen.
Die Idee ist recht geradlinig. Statt an mehreren Stellen in Azure nachzusehen, erhalten Sie einen Ort, an dem Sie die Souveränitätslage Ihrer Umgebung über Tenants, Verwaltungsgruppen, Abonnements und Ressourcen hinweg sehen.
Microsoft teilt das in drei Bereiche auf.
- Discover zeigt den aktuellen Zustand, einschließlich Themen wie Datenresidenz, Vertraulichkeit, operative Souveränität und Kontinuität.
- Control ist der Ort, an dem die geforderten Kontrollen und Ihre eigenen Souveränitätsregeln angewendet werden können.
- Act soll dabei helfen, Souveränitätsrisiken zu erkennen und mit Ressourcen umzugehen, die nicht mehr der erwarteten Konfiguration entsprechen.
Noch ein Compliance-Dashboard?
Für mich ist der interessanteste Teil nicht noch ein Compliance-Dashboard. Davon hat Azure bereits genug. Interessant ist, wie das Sovereign Control Panel seine Nachweise sammelt.
Azure Policy stützt sich stark auf Aliase. Wenn Azure eine bestimmte Ressourceneigenschaft nicht über einen Alias bereitstellt, kann Policy sie nicht sauber auswerten. Das heißt, Sie können am Ende eine Compliance-Sicht haben, die gut aussieht, während ein Teil der Konfiguration, auf die es Ihnen wirklich ankommt, nie geprüft wurde.
Das Sovereign Control Panel verlässt sich nicht nur auf die Ergebnisse von Azure Policy. Es kann die Ressourcenkonfiguration auch direkt auslesen. Das klingt nach einem kleinen Implementierungsdetail, ist aber wichtig. Es bedeutet, dass die Nachweise nicht auf das beschränkt sind, was Azure Policy heute zufällig versteht.
Damit ist es nützlicher, als einfach ein weiteres Dashboard über die Regulatory-Compliance-Sichten zu legen, die es in Azure Policy und Defender for Cloud bereits gibt. Microsoft verknüpft das Panel außerdem mit dem Cloud Sovereignty Framework der Europäischen Kommission und den SEAL-Stufen.
Hier gibt es eine wichtige Unterscheidung. SEAL bewertet einen Cloudanbieter anhand von acht Souveränitätszielen und 48 Kriterien. Dazu gehören Bereiche wie Rechtsprechung und Abhängigkeiten in der Lieferkette.
Das Sovereign Control Panel betrachtet die technische Konfiguration Ihrer Azure-Umgebung. Ein grünes Sovereign Control Panel kann also bei einem Assessment oder einer Ausschreibung nützliche Nachweise liefern, verleiht Ihrer Azure-Umgebung aber nicht plötzlich eine SEAL-Stufe.
Was Sie heute tatsächlich sehen
Wir können das Sovereign Control Panel bereits in unserem eigenen Azure-Tenant sehen. Das Overview-Blade erscheint als Sovereign Control Panel (Preview) und enthält derzeit einen Tab Get started und einen Tab Sovereign views. Azure macht die aktuellen Einschränkungen ebenfalls deutlich. Ein Banner weist darauf hin, dass der Dienst über ein Private-Preview-Programm verfügbar ist, derzeit auf EU-Regionen begrenzt ist und dass der Zugang zum vollständigen Funktionsumfang über Ihre Microsoft-Ansprechperson läuft.
Der Ausgangspunkt ist eine eigene Sovereign View. Sie bewertet Azure-Ressourcen anhand von Sovereign Policies zu Themen wie Datenresidenz und Verschlüsselung. Der Großteil der interessanteren Funktionen steckt noch hinter der Private Preview.
Auch wenn Microsoft das Modell aus Discover, Control und Act dokumentiert, würde ich Control und Act derzeit vor allem als Richtung verstehen, sofern Sie nicht tatsächlich in die Preview aufgenommen wurden.
Es ist weiterhin eine Private Preview
Die frühere Dokumentation von Microsoft, aus der Zeit, als der Dienst noch Regulated Environment Management hieß, gibt ebenfalls einen guten Hinweis darauf, was Organisationen vor der Nutzung vorweisen sollten.
Sie setzt eine Azure-Umgebung voraus, die um eine sinnvolle Verwaltungshierarchie herum aufgebaut ist, idealerweise mit einer Azure Landing Zone oder Sovereign Landing Zone. Sie erwartet außerdem ein Datenklassifizierungsmodell und dass Sie diese Klassifizierung auf Microsofts Sovereign Control Levels abbilden.
L1 konzentriert sich auf Residenz. L2 ergänzt Verschlüsselung mit Customer Managed Keys. L3 bringt Confidential Computing ins Spiel. Sie müssen außerdem wissen, wie das Key Management in Ihrer Umgebung funktionieren soll. Dieser letzte Punkt ist wichtig, denn das Sovereign Control Panel entwirft Ihr Souveränitätsmodell nicht für Sie.
Wenn Ihre Policies überwiegend im Audit Mode laufen, Klassifizierungen unklar sind und niemand die Ausnahmen wirklich verantwortet, macht das Panel genau das sichtbar. Es löst das zugrunde liegende Problem nicht. Und dort liegt vermutlich der größte Teil der eigentlichen Arbeit.
Eine Sovereign Landing Zone, Policy as Code und ein Klassifizierungsmodell, das fachliche Anforderungen in tatsächliche Azure-Kontrollen übersetzt, bleiben das Fundament. Das Sovereign Control Panel kann diese Kontrollen dann in etwas verwandeln, das Sie fortlaufend sehen, steuern und nachweisen können, statt die Nachweise jedes Mal neu aufzubauen, wenn jemand danach fragt.
Wenn Sie regulierte Workloads in europäischen Azure-Regionen betreiben, lohnt es sich meiner Meinung nach, Ihre Microsoft-Ansprechperson nach Zugang zur Preview zu fragen. Ich würde mir aber zuerst das Fundament ansehen. Ein besseres Dashboard wird erst dann wirklich nützlich, wenn die Umgebung darunter sauber entworfen wurde.
Vereinbaren Sie ein Gespräch mit DevOps Masterminds CTO Rinie Huijgen, oder kontaktieren Sie uns.
