Sicherheitsthemen in Azure begegnen dem Administrator gleich mehrfach. Angefangen beim Protokollieren, um zu sehen, wo Systeme  verwundbar sind, bis hin zur Definition von administrativen Rollen, um Aktivitäten einzelnen Mitarbeitern zu gestatten. Dies ist in der Cloud besonders wichtig, denn im lokalen Rechenzentrum lassen sich physische Server nicht mit wenigen Mausklicks löschen, in Azure sehr wohl. Die meisten größeren IT-Landschaften setzen daher auf ein Rollenkonzept. Dies hilft dabei, die Infrastruktur zu schützen, und bietet dem Admin Sicherheit bei seiner täglichen Arbeit.

Eine gute Beschreibung eines solchen Verwaltungsmodells bietet Microsoft. Es teilt die Administration in drei Ebenen ein und je nach dem, was ein Administrator beabsichtigt, bedient er sich eines Benutzerkontos der jeweiligen Ebene, das die entsprechenden Berechtigungen bietet. Ebene 0, auch T0 genannt, hat die umfangreichsten Rechte. Bezogen auf das Active Directory wäre dies die Gruppe "Organisations-Admins". Konten der Ebene T1 administrieren Server und Applikationen und Konten der Ebene T2 besitzen die Rechte, die für die Datenpflege vonnöten sind. Der Administrator meldet sich dann je nachdem, was er beabsichtigt, mit dem entsprechenden Konto an.

Im besten Fall findet sich dieses Modell auch in Ihrem Namenskonzept wieder, sodass zum Beispiel Herr Müller das Konto "adm-mueller.0" als "Organisations-Admin" (oder "Enterprise Admin" in einem englischsprachigen AD) nutzt. Für alle anderen Arbeiten bedient er sich des Kontos "adm-mueller.2". So ist bereits auszuschließen, dass der hochprivilegierte Kontext missbraucht wird. Mit mehreren Konten zu hantieren, bereitet auf den ersten Blick Mühe und nervt, bietet dafür aber Schutz. Beziehen Sie nun Elemente aus Azure in ihre IT-Landschaft mit ein, gilt es, bestehende Gruppen- und Rollendefinitionen in Richtung Azure zu erweitern.

Lokale Konten für die Cloudadministration
In etablierten IT-Landschaften existieren je nach Aufgabengebiet entsprechende Berechtigungsgruppen. So gibt es Gruppen für die Serveradministration bis hin zur Rufbereitschaft. Egal, ob Sie nun Microsoft 365 oder Azure für IaaS einsetzen: Benutzerkonten und Gruppen, die den Zugriff innerhalb der Clouddienste regeln, befinden sich immer im entsprechenden Azure AD. Microsoft hat Azure AD Ende 2023 in Entra ID umbenannt.

Selbstverständlich können Sie die administrativen Gruppen ebenfalls in Entra ID anlegen, jedoch hätte so der Administrator zwei Orte, an denen er User- und Gruppenpflege betreibt – das lokale Active Directory und in der Cloud. Das ist aufwendig und kaum zu managen. Zum Glück geht das einfacher und lässt sich per Entra ID Connect automatisieren. Hierdurch haben Sie die Möglichkeit, Benutzerkonten (und natürlich Gruppen) aus dem lokalen AD (on-premises) mit dem Entra ID zu synchronisieren. Diese Vorgehensweise ist in erster Linie für Microsoft 365 gedacht, um bei größerer Anzahl Benutzer diese in die Cloud zu transferieren, um ihnen dort Lizenzen für Applikationen zuzuordnen.

Aber auch wenn Sie kein Microsoft 365 einsetzen, kann es hilfreich sein, auf die Synchronisation zu setzen, und sei es nur, um administrative Konten in die Cloud zu spiegeln, um sie im nächsten Schritt dort für Ressourcen zu berechtigen. Dies bietet den Vorteil, dass Benutzergruppen nur an zentraler Stelle, nämlich im lokalen Active Directory, zu pflegen sind – so wie bisher. Lediglich für die Cloud relevante, neue Aspekte wie Änderungen am Namenskonzept oder auch neue Gruppen, weil in Azure andere Objekte existieren und die Tätigkeiten verschieden sind, wären anzupassen.

Es ist daher überaus sinnvoll, sich im Vorfeld über die Gruppen und Definitionen klar zu werden. Danach haben Sie nichts weiter zu tun, als im lokalen AD die Admins in die Gruppen zu packen, den Rest erledigt Entra ID Connect im Zuge der Synchronisation. Wie ein Entra-ID-Connect-Server eingerichtet wird, kann uns hier aus Platzgründen nicht weiter beschäftigen. Eine Beschreibung von Microsoft zu diesem Thema finden Sie hier.

Ressourcenhierarchie und Vererbung
Gehen wir davon aus, dass Ihr Entra ID Connect eingerichtet ist, sieht das an einem Beispiel wie folgt aus: Angenommen Sie haben die Gruppe "ROL-ResGrp-Admin" im lokalen Active Directory und möchten diese für die Verwaltung aller virtueller Maschinen in Azure einsetzen. Damit Sie diese in Azure anwenden können, ist die Erfüllung von zwei Voraussetzungen erforderlich. Zum einen muss die Gruppe im Entra ID Ihres Azure-Abonnements vorhanden sein. Was sich logisch anhört, ist keinesfalls selbstverständlich – besonders, wenn Sie Microsoft 365 und Azure separat erworben haben. Mehr dazu später.

Zum anderen ist es wichtig, dass der Gruppe in Azure innerhalb des Abonnements die jeweiligen Rechte eingeräumt sind. Hierzu gibt es eine Vererbungshierarchie, ähnlich wie im Dateisystem. Weisen Sie Berechtigungen für ein Abonnement zu, was in der Vererbungshierarchie sehr weit oben ist, hat dies Auswirkungen auf alle Objekte in dem Abo. Eine Ressourcengruppe ist Teil eines Abos und es können durchaus mehrere vorhanden sein. Vergeben Sie nun Berechtigen für Ressourcengruppen, könnten zum Beispiel zwei Administratorteams die virtuellen Computer in der jeweiligen Ressourcengruppe managen, da die Rechte nur dort gelten.

Dies ist ein sehr leistungsstarker Mechanismus und erfordert gründliche Planung. Nicht nur bei der Vergabe von Berechtigungen, auch beim Anlegen der Objekte in Azure. Getrennte Admin-Bereiche können nämlich ein Grund sein, VMs auf verschiedene Ressourcengruppen zu verteilen. Bild 1 zeigt die Berechtigungen für eine VM. Alle hier eingetragenen Benutzer stammen aus dem synchronisierten On-Premises-Active-Directory, das in unserem Beispiel den Domänennamen "kbcorp.de" hat. Eine Ausnahme in der Liste ist der Besitzer "Klaus Bierschenk". Hierbei handelt es sich um das erste Konto des Abonnements, das gleichzeitig "Globaler Admin" ist. In der Spalte "Scope" sehen Sie, ob die Berechtigung auf eine Ressource vergeben ist oder ob sie vererbt wurde. Auf diese Art lassen sich für alle zu administrierenden Objekte in Azure wie auch beispielsweise "Virtuelle Netzwerke" Berechtigungen vergeben. Selektieren Sie hierfür jeweils den Link "Zugriffssteuerung (IAM)" in der Befehlsleiste und behalten Sie die Vererbung im Auge.

ln/dr/Klaus Bierschenk

Im zweiten Teil der Workshopserie schildern wir, wie Sie auf der Kommandozeile für den Security-Feinschliff sorgen und den Azure-Login absichern.