Nach meinem letzten Blog über Azure Policy möchte ich auch in diesem Beitrag das Thema Sicherheit behandeln, genauer gesagt die "Role-Based Access Control (RBAC), die Teil des Identity und Access Managements von Azure ist.
RBAC spart viel Zeit im Tagesgeschäft, da Zugriffsberechtigungen nach Rollen zugewiesen werden können und nicht nur einzelnen Personen. Nutzen Sie zur Zuweisung die bereits integrierten Rollen oder erstellen Sie individuelle Rollen, die an die unterschiedlichen Aufgabenbereiche Ihres Unternehmens angepasst sind wie beispielweise Kundendienst oder Vertrieb. Es können außerdem Regeln erstellt werden, was einen sehr granularen Zugriff erlaubt. Anstatt 20 verschiedene Rollen pro Person zu erstellen, können Sie also einer Abteilung eine Rolle zuweisen. Dabei kann eine Person mehrere Rollen haben.
RBAC wird in Azure bereitgestellt und ist damit kein besonderer Dienst oder Ressource, die in Azure integriert werden muss. Den Zugriff auf die RBAC erhalten Sie über den Menüpunkt "Access Control (IAM)".
Falls Sie in der Vergangenheit bereits mit einem Benutzer- und Gruppenmanagement gearbeitet haben, funktioniert Azure IAM ganz ähnlich. User können in Gruppen organisiert werden. Die passende Rolle wird den jeweiligen Gruppen oder einzelnen Benutzern zugewiesen. Hierzu müssen Sie eine der integrierten Rollen der gewünschten Gruppe zuordnen.
Jede dieser Rollendefinitionen hat gewisse Einschränkungen, die sich auf einen bestimmten Azure-API-Endpunkt beziehen. Im Tagesgeschäft sind die API-Endpunkte meist nicht relevant, allerdings ist das Verständnis dieser zum Erstellen benutzerdefinierter Rollen unerlässlich.
Mein Rat an dieser Stelle: Bleiben Sie möglichst im Standard; In der Regel können dabei 90% Ihrer Anforderungen erfüllt werden. Eine detaillierte Auseinandersetzung mit benutzerdefinierten Rollen macht nur Sinn, wenn Sie spezielle Anforderungen haben. Zum Beispiel eine Rolle, die von mehreren internen Anwendungen verwendet wird und die nur auf einen Teil der Funktionalität in Azure zugreifen müssen.
Bei einer neuen Azure-Subscription erstelle ich zu Beginn zwei Gruppen: Eine für Subscription Owner (auf Subscription Ebene) und eine für Resource Group Contributors (auf Resource Group Ebene). Subscription Owner erhalten die Rolle "Eigentümer", die sich auf die Subscription selbst bezieht. Resource Group Contributors wird die Rolle "Mitwirkender" zugeteilt, die individuell auf die Resource Groups bei deren Erstellung angewendet wird. Nur eine kleine Anzahl Personen (1-2) sollte dabei der Subscription Owner Gruppe zugewiesen werden.
Natürlich hat dieses Vorgehen, wie alles andere auch, seine Vor- und Nachteile. Änderungen auf der Subscription-Ebene sind meistens eine direkte Reaktion auf geschäftliche Anforderungen, während in den Ressourcengruppen selbst eher Änderungen in Bezug zum Tagesgeschäft oder zu Projekten vorgenommen werden. Aus Perspektive der Governance ist das zwar gut, doch entstehen dabei einige Nebeneffekte:
- Die Resource Contributors Group muss von einer Person in der Subscription Owner Group erstellt werden.
- Der Subscription Owner muss die Gruppe Resource Contributors der Resource Group zuweisen. Mit Hilfe der Azure Policy kann dieser Prozess automatisiert werden.
- Manchmal erfordert eine Ressourcenbereitstellung (durchgeführt von einer Person der Resoure Contributors Group), dass ein Ressourcenanbieter auf der Subscription-Ebene registriert wird. Bei der Installation wird normalerweise eine große rote Fehlermeldung angezeigt. Jemand aus der Subscription Owner Goup muss die Registrierung manuell vornehmen - normalerweise über Az CLI (Azure Command Line Interface).
Hilfreiche Links:
- Was ist die rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC)?
- Manuelle ein az command bereitstellen
- Ressourcenanbieter für Azure-Dienste
Einen Kommentar schreiben