Azure: Basiswissen für Administratoren

Zugriffskontrolle und Rollen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Das Azure-Portal bietet rollenbasierte Zugriffskontrolle. Grundsätzlich folgt es dem Schema "Owner, Member, Visitor", es kann jedoch auch erweitert und modifiziert werden.
09:08

Transkript

Wenn ich eine Cloud betreibe, dann brauche ich natürlich auch ein rollenbasiertes Zugriffsmodell, was es mir erlaubt, auf der Ebene von Ressourcengruppen oder auf der Ebene von bestimmten virtuellen Maschinen et cetera Lese- beziehungsweise Vollzugriff zu vergeben. Das ist früher eine Schwäche des sogenannten Classic Portals gewesen, das ich jetzt einfach mal als separaten Tab aufgemacht habe. Dort gibt es keinen basierten Rollenzugriff, hier kann ich lediglich Administratoren benennen, das heißt, innerhalb dieses Classic Portals bin ich entweder Gott oder ich bin niemand. Das ist im Resource-Manager deutlich besser gelöst worden, und das zeige ich Ihnen jetzt mal wie das hier grundsätzlich funktioniert. Eine Berechtigung wird im Azure Resource-Manager Portal ähnlich gehandhabt wie in einem Fileserver, sprich, wenn ich auf einer oberen Ebene eine Berechtigung setze, dann wird diese runtervererbt. Grundsätzlich kann ich im Resource-Manager auf der obersten Ebene, nämlich auf der Ebene des Abonnements oder der Subscription, eine Berechtigung vergeben. Das heißt, ich klicke auf Hinzufügen, wähle ein Konto aus dem Azure Active Directory aus, definiere eine Rolle, und dann wird das Ganze an alles übertragen, was innerhalb dieser Subscription befindlich ist. Aber nicht so schnell -- gucken wir uns ein paar andere Details an. Im Azure Active Directory selbst habe ich natürlich, wie bereits erwähnt, Konten, auf die ich berechtigen kann. Das heißt, ich habe hier meine Kontoliste mit unterschiedlichen Benutzern, die ich mir anlegen kann, die sind entweder Cloud-nativ oder sind vom Domaincontroller mittels Azure AD Connect in mein Azure AD hineinsynchronisiert worden. Das ist die zweite Möglichkeit, es gibt auch die Möglichkeit, hier einen sogenannten Gastbenutzer hinzuzufügen, das heißt, ich lade jemanden ein auf Basis seiner Email-Adresse, und dann muss dieser Nutzer, wenn er die Einladung annimmt, auf seine Email-Adresse einen Microsoft-Account erstellen und kann dann entsprechend Services aus diesem Azure-Portal konsumieren. Im Azure AD selbst haben wir eine etwas abgewandelte Form des rollenbasierten Zugriffs, wenn wir uns das anschauen, und zwar unter dem Bereich des Accounts selber, wenn ich mir also ein bestimmtes Konto aufmache, wie den "globaladmin" meinetwegen, dann haben wir hier die sogenannte Verzeichnisrolle. Diese Verzeichnisrolle legt fest, ob es sich um einen Benutzer oder einen Global Administrator beziehungsweise eingeschränkte Administrationsrechte handelt, die ich miteinander kombinieren kann. Das heißt, ein Konto kann in dem Fall nicht Benutzer und Globaler Administrator zugleich sein, das ist hier bewusst getrennt worden. Azure AD ist nicht in Ressourcengruppen verschachtelt oder beinhaltet, das ist getrennt. Dementsprechend gibt es bei den Ressourcengruppen nochmal ein ähnliches, aber anderes Modell. Das heißt, auf der Ebene der Ressourcengruppe kann ich hier auf die Zugriffssteuerung zugreifen und hier auf Basis der in meinem Azure AD-Mandanten vorhandenen Konten eine Berechtigung zuweisen, und standardmäßig haben wir hier den Besitzer, den Mitwirkenden, und den Leser. Nehmen wir uns mal Leser, wir erklären später worum es sich dabei genau handelt, das heißt, wir vergeben jetzt einen Lesezugriff für den Karl Schlau auf Basis von der Ressourcengruppe Nummer 11. Das ist hinzugefügt worden, und das bedeutet jetzt natürlich, dass der Karl Schlau Lesezugriff bekommen hat auf alles, was sich innerhalb dieser Ressourcengruppe befindet, also auch auf diese VM names "DC1". Gucken wir in die Zugriffssteuerung, müssten wir auch hier den Karl Schlau wieder als Leser für diese bestimmte Ressource sehen, was der Fall ist. Soweit zum Prinzip der Vererbung. Als Nächstes gucken wir uns die Bedeutung von Besitzer und Mitwirkender, sowie dem Leser einmal etwas genauer an in der Dokumentation für die ersten Schritte mit der rollenbasierten Zugriffssteuerung im Azure-Portal. Dazu scrollen wir ein bisschen weiter nach unten und sehen dann hier den Besitzer. den Mitwirkenden und den Leser und können dahinter nachvollziehen, was diese Rollen eigentlich bedeuten. Das heißt, der Besitzer verfügt über vollständigen Zugriff auf alle Ressourcen, einschließlich des Rechts, Leute einzuladen, beziehungsweise Zugriff zu delegieren. Das kann der Mitwirkende nämlich nicht, das ist der einzige Unterschied zwischen dem Mitwirkenden und dem Besitzer. Lesezugriff versteht sich von selbst. Als wir vorhin eine Berechtigung gesetzt haben, ist Ihnen sicherlich auch schon aufgefallen, dass es eine Vielzahl von unterschiedlichen Rollen gibt, die man theoretisch verwenden kann. Das heißt, wenn ich eine Rolle zuweise, gibt es nicht nur den Besitzer, den Mitwirkenden und den Leser, sondern es gibt noch ganz andere Rollen, wie, zum Beispiel, den DevTest-Labs-Benutzer, beziehungsweise den Log Analytics-Leser, und diese Rollen sind dokumentiert in diesem Artikel hier: "Integrierte Rollen für die rollenbasierte Zugriffssteuerung in Azure". Das heißt, hier reden wir von sogenannten integrierten Rollen, die standardmäßig in jedem Azure-Mandanten vorhanden sind, die man benutzen kann, um ein least-privilege Prinzip auf unterschiedliche Dienste abzubilden, wie, zum Beispiel, auf das Lesen von Überwachungsdaten, auf das Mitwirken auf eine SQL-DB Instanz, das heißt, diese Rollen sind servicespezifiziert, um auf diese Art und Weise nach bestimmten Services ein least-privilege Prinzip abzudecken. Sollten Sie mit diesen Standardrollen oder den sogenannten "Integrierten Rollen" nicht hinkommen in Ihrem Betrieb, was relativ selten vorkommt, gibt es die Möglichkeit, auch eigene benutzerdefinierte Rollen zu generieren auf Basis von PowerShell, beziehungsweise des Command-Line Interfaces. Es geht damit los, dass Sie sich erstmal über ein JSON Objekt die entsprechende Berechtigungsstruktur zusammenbauen, wie es hier dokumentiert ist. Anschließend müssen Sie das, was Sie sich zusammengebaut haben, über die PowerShell, in dem Fall in ihren Azure-Mandanten hineindeployen, um auf diese Art und Weise ihre benutzerdefinierten Berechtigungsprinzipien in den Mandanten hineinzukonfigurieren. Damit wäre ich allerdings am Anfang etwas vorsichtig. Das ist wirklich etwas für Profis, denn, wie gesagt, das Thema Berechtigung ist nicht unwichtig, da kann man natürlich auch Dinge mit kaputt machen. Dementsprechend meine Empfehlung, sofern Sie nicht ganz spezielle Anforderungen haben, halten Sie sich an das Prinzip Besitzer, Mitwirkender, und Leser. Das Problem mit Item-Level-Permissions, ich nenne das jetzt einfach mal so, das kennen Sie vom Fileserver oder auch von Sharepoint, kann natürlich dazu führen, dass es relativ schnell unübersichtlich wird, wer eigentlich worauf berechtigt ist. Wenn Sie ihren Azure-Mandanten zusätzlich absichern möchten, können Sie lieber folgendes machen: Es gibt für Azure Active-Directory einen nativen Dienst namens "Privileged Identity Management", und damit können Sie Administratorenkonten grundsätzlich deaktivieren, beziehungsweise abschalten, und diese müssen dann On-Demand aktiviert werden, wenn bestimmte Changes durchgeführt werden sollen. Dann muss gegebenenfalls nochmal ein Approval durch einen Kollegen erfolgen, das heißt, wir haben ein schönes Vier-Augen-Prinzip, und man kann auch Regeln anhängen, dass der Aktivierungszeitraum für diesen Account dann automatsch nach 2-3 Stunden, je nachdem wie man das definiert, verfällt. Genauso arbeitet übrigens auch der Microsoft-Support, wenn es Third-Level-Supporttickets gibt für Azure, dann wird genau nach diesem Prinzip mit dieser Technologie verfahren. Ein zweiter Ansatz ist das sogenannte "Azure AD Identity Protection". Das ist ein Service, der über einen Machine-Learning-Mechanismus permanent die Logins gegen das Azure AD analysiert und die Augen und Ohren offen hält, im Hinblick auf ungewöhnliches Nutzerverhalten. Wenn, zum Beispiel, ein Nutzer sich plötzlich über Panama City mit einer anonymen IP-Adresse anmeldet, dann wird dies in Echtzeit getrackt, und dann kann im System automatisch auf risikobasierte Richtlinien darauf reagiert werden, entweder wird dieser Account sofort gesperrt, beziehungsweise, wird beim nächsten Login aufgefordert sein Kennwort zu ändern oder wird aufgefordert, sich über eine Multi-Faktor-Authentifizierung, also über einen separaten SMS-Code zu authentifizieren, dass es sich wirklich um diese Person handelt. Das heißt, über die standardmäßig vorhandenen Funktionalitäten des rollenbasierten Zugriffs kann man über Privileged Identity Management und Identity Protection den Azure-Mandanten, der über Azure Active Directory authentifiziert wird, zustätzlich absichern.

Azure: Basiswissen für Administratoren

Lernen Sie das Wichtigste, was Sie als IT-Adminstrator über die Möglichkeiten von Azure wissen müssen.

4 Std. 2 min (31 Videos)
Derzeit sind keine Feedbacks vorhanden...
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:07.09.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!