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 bereits 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 [1]. 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.
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.