Immer wieder stoßen wir auf Kundenumgebungen in denen mit geteilten Accounts gearbeitet wird. Auf diese Weise ist einerseits nicht nachvollziehbar wer Änderungen durchgeführt hat und andererseits gibt es keine sinnvolle Umsetzung einer Abstufung von Berechtigungen. Wir führen dann meist ein einfaches oder auch komplexes Berechtigungsmodell auf Basis von Role Based Access Control ein. Aber wie fängt man damit an?
RBAC in Azure bietet die Möglichkeit sowohl einfache als auch sehr komplexe Berechtigungsstrukturen aufzubauen. Hierbei sind einige Punkte bei der Einführung zu beachten, damit ein erfolgreicher Einsatz gewährleistet werden kann, ohne die Produktivität zu reduzieren. Dieser Artikel soll zeigen wie Sie vom einfachen Modell kommend sich weiterentwickeln können. RBAC kennen die meisten schon aus dem Active Directory, in dem mit Hilfe von Gruppen und Berechtigungen abgebildet wird welcher Benutzer was tun darf.
Role Based Access Control (RBAC) – der einfache Start mit Standardrollen
Wenn man mit RBAC beginnt, hilft zunächst ein Blick auf die drei Standardrollen in Azure: Owner, Contributor und Reader (in deutsch: Besitzer, Mitwirkender und Leser). Diese bieten bereits eine erste, kleine Möglichkeit der Rechtekontrolle.
Owner / Besitzer
Der Owner hat die weitreichendsten Berechtigungen. Benutzer mit dieser Rolle dürfen alles, inkl. der Vergabe von Berechtigungen.
Contributor / Mitwirkender
Der Contributor ist ebenfalls sehr mächtig. Er darf Ressourcen jeglicher Art anlegen, ändern und löschen. Die Rechtevergabe unterliegt ihm aber nicht.
Reader / Leser
Der Reader darf vorhandene Ressourcen ansehen.
Diese drei Rollen können wiederum auf drei Ebenen angewandt werden. Im gezeigten Schaubild sind noch zwei weitere Ebenen enthalten. Diese dienen der Verwaltung im EA Portal und existieren auch nur dort. Im Rahmen dieses Artikels erfolgt keine weitere Betrachtung dieser Ebenen.
Subscription Ebene
Berechtigungen, die auf der Ebene der Subscription vergeben werden, werden weitervererbt. Das ist einerseits erfreulich, weil nicht jede Berechtigung einzeln auf jede Ressource oder Ressourcengruppe vergeben werden muss. Andererseits birgt dies auch die Gefahr, dass unerwünschte Berechtigungen entstehen, weil man die Vererbung nicht unterbrechen. Auf der Ebene der Subscription versuchen wir daher so wenigen Personen (bzw. Accounts) wie möglich Berechtigungen zu erteilen. Aber es empfiehlt sich speziell gesicherte “Break Glass Accounts” einzurichten, für die man im Notfall “die Scheibe einschlagen kann, um die Tür zu öffnen”.
Ressourcengruppen Ebene
Die Vergabe von Berechtigungen auf der Ebene von Ressourcengruppen ist die einfachste Variante, eine angemessene Berechtigungsstruktur aufzubauen. Aber auch hier kann man auf Limitierungen stoßen, weil bspw. der Netzwerk-Administrator keinen Zugriff auf alle Ressourcen hat.
Ressourcen Ebene
Die Rechtevergabe auf der Ebene von einzelnen Ressourcen wird meist nur in Einzelfällen eingesetzt. Sinnvoll ist dies z.B. für stark abzusichernde Ressourcen, wie Key Vaults, in denen Zertifikate und Passwörter/Keys gespeichert werden können.
Bevor Sie jetzt anfangen die Benutzer in diese Rollen und Ebenen zu verteilen, empfiehlt es sich im führenden Identity System, z.B. im Active Directory, on Premises-Gruppen für diese Rollen-Ebenen-Kombinationen anzulegen und diese schließlich im Azure Access Management zu hinterlegen. So bleibt die Hoheit der Identitäten an einer zentralen Stelle erhalten.
Role Based Access Control (RBAC) – erweiterte Rollen zur Granulierung
Neben den drei Standardrollen gibt es auch noch einige weitere Rollen, die von Microsoft für die Erfüllung bestimmter Tätigkeiten in Azure vorgesehen sind. So gibt es beispielsweise den “Virtual Machine Contributor”, der über alle notwendigen Berechtigungen für die Administration von virtuellen Maschinen verfügt. Diese Rollen können dadurch gut für IT-Abteilungen eingesetzt werden, die auf bestimmte Tätigkeiten spezialisiert sind. Dadurch erhalten diese Benutzer gezielt die Berechtigungen, die sie zur Durchführung ihres Jobs brauchen, aber auch nicht mehr.
RBAC Custom Roles für die, die es ganz genau haben möchten
Für speziell angepasste Rollen bieten sogenannte Custom Roles die Möglichkeit Berechtigungen zu individualisieren. Dazu kann man mit Hilfe von PowerShell eine bestehende Rolle herunterladen, die Berechtigungsparameter im JSON File anpassen oder ergänzen und es anschließend wieder in das Portal übertragen.
Hinweise zu RBAC
Bei genauerer Betrachtung der Berechtigungen, fallen einige Dinge auf, die man im Blick haben sollte. Hier daher ein kleiner Auszug dessen, worauf man achten sollte:
- Locks (Sperren) von Ressourcen (z.B. gegen versehentliches Löschen von Ressourcen) dürfen nur von einem Owner entfernt werden.
- App Registrations erhalten per Default die Contributor Berechtigung auf die gesamte Subscription. Das sollte nach dem Anlegen einschränkt werden.
- Reader dürfen auch Daten herunterladen, z.B. aus Storage Accounts, SQL, Images, etc.
Fazit
RBAC bietet die Möglichkeit, ein feingranuliertes Rechtemodell in der Cloud zu etablieren. Diese Möglichkeit sollte auch genutzt werden, um seine Umgebung so sicher wie möglich zu gestalten. Selbstverständlich gehören neben Role Based Access Control dazu auch weitere Schutzmaßnahmen, aber diese Möglichkeit sollte man nicht außer Acht lassen. Benötigen Sie Unterstützung beim Aufsetzen eines neuen Tenants oder haben bereits einen, den man einmal prüfen oder anpassen sollte? Dann kommen Sie auf die Profis von aConTech zu. Wir helfen Ihnen gerne.