Hallo und willkommen zurück.
Im heutigen Video werden wir uns mit der attributbasierten Zugriffskontrolle, auch IBAC
genannt, beschäftigen.
Bevor wir nun mit unserem ABC-Lernen beginnen, ist es wichtig, dass wir zunächst die Grundlagen der Kunst verstehen.
Arabisch steht jetzt für die rollenbasierte Zugriffskontrolle.
Und bei dieser Art von Ansatz basiert die Zugangsbeschränkung auf der Rolle der Person innerhalb der Organisation.
Wenn wir nun über IAM an einem Ort diskutieren, implementieren wir unsere Unterstützung, indem wir verschiedene Richtlinien für verschiedene
Funktionen erstellen.
Sie sehen z. B., dass es zwei Benutzer gibt, die jeweils mit einer anderen Richtlinie verbunden sind.
Wir haben also erstens die DevOps-Richtlinie und zweitens die Sicherheitsrichtlinie.
Basierend auf den Einschränkungen oder Erlaubnissen, die Sie als Teil der Richtlinie hinzufügen, können die Benutzer bestimmte
Funktionen ausführen.
Dies ist also der rückenbasierte Ansatz.
Nun gibt es einige Herausforderungen, die mit diesem Ansatz verbunden sein können.
Gehen wir also der Sache auf den Grund.
Nehmen wir also an, Sie haben dieses Konto, und innerhalb dieses Kontos haben Sie zwei verschiedene Umgebungen.
Es gibt eine rote Umgebung und eine grüne Umgebung.
In beiden Fällen handelt es sich um Produktionsumgebungen.
Nehmen wir nun an, Sie verwenden ein typisches Outback-basiertes Modell und haben eine zentrale Richtlinie, die als DevOps-Richtlinie
mit Administrator-Zugriff aufgerufen wird und mit diesem Konto verknüpft ist.
Und Sie haben ein DevOps-Team, mit dem diese Richtlinie verbunden ist.
In diesem Stadium können wir leicht erkennen, dass das DevOps-Team in der Lage sein wird, alle Funktionen sowohl in roten als
auch in grünen Umgebungen auszuführen.
In größeren Unternehmen werden Sie feststellen, dass selbst innerhalb des DevOps-Teams bestimmte Teammitglieder für einen
bestimmten Teil der Infrastruktur verantwortlich sind.
Nehmen wir also an, dass dieses DevOps-Team zehn Mitglieder hat.
Fünf Mitglieder sind für die rote Umgebung zuständig, fünf Mitglieder für die grüne Umgebung.
Bei einem Ansatz mit einer zentralen Richtlinie wie dieser sind alle zehn Mitglieder in der Lage, Operationen
in allen Umgebungen durchzuführen, und das ist etwas, das Sie vielleicht nicht immer wollen.
Auf der Grundlage dieser Architektur hat das DevOps-Team also Zugriff auf die rote und die grüne Umgebung.
Was werden die Organisationen nun tun, um die Dinge zu trennen?
Sie werden fortfahren und zwei verschiedene Politiken schaffen.
Nehmen wir an, Sie haben eine Richtlinie Nummer eins für die rote Umgebung, Nummer zwei für die grüne Umgebung, und die
fünf Mitglieder des DevOps-Teams, die für die rote Umgebung verantwortlich sind, haben diese rote DevOps-Richtlinie
und die anderen fünf Mitglieder haben diese grüne DevOps-Richtlinie.
Und in dieser roten DevOps-Richtlinie erlauben Sie nur Berechtigungen für Rot in Grün, Sie erlauben nur Berechtigungen
für Grün.
Diese Art von Architektur ist also viel besser als die vorherige.
In größeren Organisationen gibt es jedoch, sagen wir mal, 20 oder 30 verschiedene DevOps-Teams oder vielleicht
Entwickler, Systemadministratoren usw. Was Sie tun müssen, ist, mehr und mehr Richtlinien
für jede Gruppe von Mitgliedern zu erstellen, die für eine bestimmte Umgebung verantwortlich sind.
Um dies zu vermeiden, können Sie die attributbasierte Zugriffskontrolle nutzen, die sich als wesentlich besserer
Ansatz erweisen kann.
Bevor wir nun über die APAC-Region sprechen, sollten wir die Grundlagen der Attribute überarbeiten.
Im Großen und Ganzen sind Attribute also nichts anderes als ein Schlüssel-Wert-Paar, das Sie mit einer bestimmten
Entität verknüpfen.
Es kann ein Benutzer sein, es kann einfach zu instanziieren sein, usw. An einer Stelle werden diese Attribute also als Tags bezeichnet.
Das ist also einfach zu verstehen.
Wenn wir nun über die attributbasierte Richtlinie sprechen, haben Sie einen einzigen Satz von Richtlinien.
Auch hier besteht keine Notwendigkeit für mehrere Richtlinien, und innerhalb dieser spezifischen Richtlinie wird es
eine primäre Genehmigung geben, die z. B. die Freigabe von Sternchen vorsieht.
Erlauben Sie also den Zugriff auf die Umgebung auf der Grundlage des Benutzerattributs.
In diesem Stadium wissen wir, dass Sie eine rote Umgebung und eine grüne Umgebung haben,
und Sie assoziieren das Attribut mit jedem Mitglied.
Das DevOps-Mitglied hat also ein rotes DevOps-Attribut.
Mitglied zwei hat das Attribut grün.
In einer solchen Richtlinie hat das DevOps-Mitglied 1 vollen Zugriff auf die rote Umgebung und das DevOps-Mitglied
2 vollen Zugriff auf die grüne Umgebung, vor allem aufgrund der Attribute, die Sie auf der Benutzerebene
hinzufügen, und auch aufgrund der Attribute, die Sie als Teil der Umgebungsebene hinzufügen.
Bei diesem Ansatz haben Sie also weniger Richtlinien, die viel einfacher zu pflegen sind.
Einer der wichtigsten und kritischsten Aspekte ist jedoch die Kennzeichnung.
Die Benutzer, die von Ihnen geschaffene Umgebung, all das muss gekennzeichnet werden.
Wenn wir nun über die Attribute für einen IAM-Benutzer sprechen, können Sie in diesem Screenshot sehen, dass wir eines haben.
Benutzer College Benutzer 101 und mit diesem Benutzer ist ein Tag verbunden.
Dieser Tag ist ein grünes Team.
Dies würde in der Regel bedeuten, dass, wenn alle Tags richtig gesetzt und die Richtlinien korrekt sind, dieses Mitglied
auch als DevOps-Mitglied betrachtet wird, da es ein grünes Team gibt und er in der Lage sein wird, auf die
grüne Umgebung zuzugreifen und alle Operationen durchzuführen.
Mit diesem Grundgerüst können wir nun die attributbasierte Zugriffskontrolle auf einer hohen Ebene überarbeiten.
E back ist eine Autorisierungsstrategie, die die Erlaubnis auf der Grundlage von Attributen definiert,
und wir haben gelernt, dass Attribute bei uns Tags sind.
Wenn Sie sich dieses spezielle Diagramm ansehen, habe ich es direkt aus der Dokumentation entnommen, so dass
Sie es leichter überarbeiten können, wenn Sie es durchgehen.
Sie sehen also, dass es drei verschiedene Umgebungen gibt.
Sie haben rot, gelb und blau und es gibt verschiedene Gruppen von Nutzern und Kunden, und mit jedem Nutzer und
Kunden ist ein bestimmtes Attribut verbunden.
Der Benutzer mit dem roten Attribut kann also auf die Ressourcen zugreifen, die wiederum das rote Attribut haben, d.h.
rote Umgebung, gelbe Umgebung, blaue Umgebung und so weiter.
Mit dieser Grundausstattung können wir nun eine kurze Demonstration durchführen, um zu verstehen, wie die Dinge funktionieren.
Für das heutige Video habe ich zwei EC, zwei Instanzen.
Die eine ist Teil der roten Umgebung.
Die zweite ist ein Teil der grünen Umgebung für die zweite Instanz der EG, die mit der roten Umgebung verbunden
ist.
Wenn Sie sich die Tags ansehen, ist das Thema hier rot.
Dies ist also der wichtige Hinweis.
Und was die grüne Umwelt betrifft, so ist das Team hier grün.
Ähnlich verhält es sich mit den IAM-Benutzern: Sie haben zwei Benutzer, Benutzer Null Eins, der einem grünen Team zugeordnet ist, und Benutzer
Null Zwei, der dem roten Team zugeordnet ist.
Wenn wir den Benutzer Null Eins öffnen und uns die Tags noch einmal ansehen, gibt es ein grünes Tag-Team
und für den Benutzer Zwei ein rotes Team.
Der Grundgedanke ist also, dass der Benutzer die in der IAM-Richtlinie definierten Operationen durchführen kann, wenn das
dem Benutzer zugeordnete Tag mit dem Tag übereinstimmt, das der Ressource zugeordnet ist,
z. B. EC two instance.
In diesem Stadium habe ich eine gemeinsame Gruppe namens DevOps-Gruppe, und in dieser Gruppe befinden sich die beiden
hinzugefügten Benutzer, und wenn Sie sich die Berechtigung ansehen, ist nur eine Richtlinie damit verbunden.
Wenn Sie sich mit dieser Politik befassen, lassen Sie sie mich jetzt bearbeiten.
Wenn Sie sich diese Richtlinie ansehen, haben Sie eine auf Start- und Stoppinstanz basierende Aktion, die erlaubt ist,
und Sie haben eine spezifische Bedingung, die auf dem Tag basiert.
Hier ist also das Team der Schlüssel.
Das heißt also, wenn das Team, das der roten Umgebung EC zwei zugeordnet ist, mit dem Team übereinstimmt, das dem IAM-Benutzer
zugeordnet ist, dann kann der Benutzer diese Reihe von Operationen durchführen.
Probieren wir es also schnell in einem anderen Browserfenster aus.
Ich melde mich jetzt schnell bei dem Benutzer an, der zum grünen Team gehört.
Wenn Sie nun zur EC-2-Konsole gehen, lassen Sie uns zu der entsprechenden Region wechseln.
Lassen Sie uns zu den Instanzen gehen.
Auch jetzt ist der Benutzer Null Eins mit einem grünen Team verbunden.
Wenn der Benutzer nun versucht, die mit dem roten Team verbundene Instanz sofort zu stoppen, sehen Sie, dass Sie auf
ähnliche Weise einen Fehler erhalten.
Wenn der Benutzer versucht, die mit einer grünen Umgebung verbundene Instanz zu stoppen, sehen Sie, dass sie einwandfrei funktioniert.
Also gut.
Ich hoffe, Sie haben damit verstanden, wie eine einzelne IAM-Richtlinie, die auf den Attributen basiert,
in einer größeren Umgebung viel besser skalierbar sein kann, wenn die Ressourcen richtig gekennzeichnet sind.
Bevor wir nun zum Schluss kommen, sollten wir noch das Tag, das mit dem Thema Grün in der grünen Umgebung verbunden ist,
manuell entfernen.
Einfach zu.
Daher werde ich diese spezielle Markierung einfach entfernen.
Die Instanz befindet sich in der Stopp-Phase, also warten wir noch einen Moment.
Wenn wir also die derzeit gestoppten Instanzen des Benutzers Null aktualisieren, der sowohl die Berechtigung zum Stoppen der Instanz
als auch zum Starten der Instanz hatte, Wenn dieser Benutzer nun versucht, die Instanz sofort zu starten, sehen Sie, dass
der Fehler vor allem deshalb aufgetreten ist, weil die Tags nicht übereinstimmen.
Der Einfachheit halber habe ich auch den Screenshot der IAM-Richtlinie beigefügt.
Wenn Sie also die Folien durchgehen, wird es viel einfacher zu verstehen, wie die Hintergrundrichtlinien
konfiguriert werden.
Bevor wir zum Schluss kommen, wollen wir noch auf die Vorteile des Airbags eingehen.
Der erste ist, dass Airbag weniger Richtlinien erfordert, vor allem, weil man keine unterschiedlichen Richtlinien für die verschiedenen
Aufgabenbereiche erstellen muss.
Sie können eine zentrale Richtlinie erstellen, und auf der Grundlage der Tags können die Berechtigungen automatisch verwaltet werden.
Zweitens können die Genehmigungen auf der Grundlage von Benutzerkennzeichen leicht erteilt und widerrufen werden, ähnlich wie wir
es gesehen haben, als wir das mit der EG zwei verbundene Kennzeichen die Genehmigung zum Betreten der EG entfernten.
Ähnlich verhält es sich, wenn ein Benutzer aus der grünen Umgebung nicht mehr in der grünen Umgebung arbeitet.
Ihm wurde eine andere Aufgabe zugewiesen.
Dann müssen Sie nur noch die grüne Umgebungsmarkierung des IM-Benutzers entfernen, und schon sind alle
Berechtigungen weg.
Und drittens erweist sich die attributbasierte Zugriffsrichtlinie auch als sehr nützlich, wenn Sie Benutzer aus dem Unternehmensverzeichnis
wie Active Directory haben und Berechtigungen für die US-Ressourcen zulassen oder verweigern
wollen.
Das ist also der grobe Überblick.
Und damit endet das heutige Video.