Hallo zusammen und willkommen zurück.
Im heutigen Video werden wir nun über die Architektur des Identitätskontos sprechen.
Heutzutage gibt es also in den meisten Organisationen, die Sie sehen werden, zwei Haupttypen von Architektur, die im
Allgemeinen sehr verbreitet sind.
Das erste ist die Architektur des Identitätskontos, und das zweite basiert auf Single Sign-On, und daher
ist es wichtig, dass wir sie verstehen.
Und im heutigen Video wird unser Hauptaugenmerk auf der Identitätskontoarchitektur liegen.
Das ist also nicht nur aus Prüfungssicht wichtig, sondern auch aus
Produktionssicht.
Bevor wir nun fortfahren und mehr über diese Art von Architektur erfahren, ist es wichtig,
dass wir einen Schritt zurückgehen, um zu verstehen, welche Art von Architektur Organisationen in den
früheren Tagen, als sie an Bedeutung gewannen, im Allgemeinen verwendeten .
In früheren Zeiten haben Sie also gesehen, dass die meisten Organisationen ein einziges Konto hatten.
Alle Ressourcen, alle Server, die erstellt wurden, befanden sich also nur in einem einzigen Konto.
In solchen Fällen war die Verwaltung also sehr einfach und jeder Benutzer, der Zugriff auf ein diverses Konto benötigte, hatte einen
einzigen Satz aus Benutzername und Passwort sowie einen einzigen Satz aus Zugang und geheimem Schlüssel.
Und im Allgemeinen war dieses Konto geteilt.
Es gab eine Aufteilung nach Regionen.
Eine Region wurde für die Entwicklungsumgebung verwendet, die zweite Region wurde für die Produktionsumgebung verwendet.
Die Entwickler hatten also Zugriff auf eine Region der Entwicklungsumgebung und das Sicherheitsteam des Teams hatte Zugriff sowohl auf die
Entwicklung als auch auf die Produktion.
Das war also in der Anfangszeit allgemein sehr verbreitet.
Und tatsächlich werden Sie heutzutage in vielen der kleinen Startups immer noch eine solche Art von Architektur finden, die
häufig verwendet wird.
Wenn die Organisationen jetzt groß werden und Hunderte von Servern haben, ist eine auf einem einzelnen Konto basierende Architektur
nicht sehr geeignet, und Sie müssen auch bei Ihren IAM-Richtlinien sehr vorsichtig sein.
Sie haben beispielsweise einen neuen Entwickler zu Ihrem Konto hinzugefügt und ihm versehentlich Zugriff auf die Easy
to Instanz gewährt, aber Sie haben vergessen, den Zustand der Region der Entwicklungsumgebung anzugeben.
Was also passieren wird, ist, dass der Entwickler sowohl Zugang zu den Entwicklungs- als auch zu
den Produktionsregionen hier drüben hat.
Das schafft also wiederum gewisse Herausforderungen, und Sie müssen innerhalb Ihrer IAM-Richtlinien sehr vorsichtig sein, und daher
ist es wichtig, dass Sie eine bessere Architektur mit besserer Isolierung haben, wenn Ihre
Organisation groß wird.
Eine bessere Architektur, die heutzutage im Allgemeinen häufig verwendet wird, ist also ein individuelles Konto
pro Funktion.
Sie müssen also ein Konto für die Entwicklungsumgebung für die Bereitstellung eines Kontos für die Produktion berücksichtigen.
Falls der Entwickler also Zugriff auf den Ort haben möchte, an dem er Tests durchführen möchte, kann er Zugriff
auf die Entwicklungsumgebung erhalten.
Nun, obwohl dies eine großartige Art von Architektur ist, bringt sie ihre eigene Herausforderung mit sich.
Eine der größten Herausforderungen, die Sie sehen werden, besteht darin, dass jeder Benutzer für jedes Konto
einen anderen Benutzernamen und ein anderes Passwort sowie für jedes Konto einen anderen Zugangssatz und einen anderen geheimen Schlüssel hat.
Nehmen wir zum Beispiel an, dass ein Sicherheitsteam jetzt alle diese drei Konten überwachen
muss.
Ein Mitglied des Sicherheitsteams möchte sich also beim Entwicklungskonto anmelden.
Er wird seinen eigenen Benutzernamen und sein eigenes Passwort haben, wenn er einige Operationen über einen anderen Zugangssatz ausführen möchte
und geheime Schlüssel erforderlich sind.
Wenn Sie also beispielsweise 100 haben, haben viele Organisationen Hunderte von Konten.
In solchen Fällen ist es sehr schwierig, 100 verschiedene Benutzernamen und Passwörter, 100 verschiedene
Zugriffs- und Geheimschlüssel zu haben.
Um dies zu überwinden, haben Sie also eine Architektur des Identitätskontos.
Was also in einer auf Identitätskonten basierenden Architektur passiert, ist, dass alle IAM-Benutzer in einem zentralen Datenbankkonto
gespeichert werden, das Sie als Identitätskonto bezeichnen können.
Sie können sich auf ein zentrales Konto beziehen oder auch einen anderen Namen vergeben.
Wenn Sie also im Diagramm im Identitätskonto sehen, dass alle IAM-Benutzer gespeichert sind, und Sie eine
Konfiguration so erstellen, dass sich die Benutzer des Identitätskontos bei der Entwicklungsumgebung anmelden können, können sie
sich direkt bei der Produktionsumgebung anmelden, ohne eine zu haben separater Satz von Anmeldeinformationen.
Also noch einmal, es ist nicht so, dass sich jeder Benutzer anmelden kann, um eine Einführung zu entwickeln.
Alles hängt von der Richtlinie ab, die Sie auf Benutzerebene hinzufügen.
Er kann sich entweder bei der Entwicklung anmelden, sich entweder bei der Produktion anmelden oder beides.
Das ist also die Grundidee des Identitätskontos.
Es wird nur ein Satz Anmeldeinformationen verwendet.
Für jedes der Konten werden kein separater Benutzername und kein separates Passwort erstellt.
Machen wir also mit diesem Basisset eine kurze Demo.
Für die heutige Demo habe ich nun zwei geöffnete Registerkarten und in jedem Schritt haben wir ein separates Konto.
Also auf dieser Registerkarte, Nummer eins, wenn Sie sehen, dass es sich um eine Identität handelt.
Dies ist also das Identitätskonto und die Registerkarte Nummer zwei wird als Produktion bezeichnet.
Das ist also ein.
Einführungskonto.
Nein.
Im Identitätskonto sehen Sie, dass sich ein Benutzer von Alice angemeldet hat.
Nehmen wir nun an, der Alice-Benutzer möchte auf das Produktionskonto zugreifen.
In diesem Fall, wie wir es besprechen, muss der ALICE-Benutzer, da wir
eine Identitätskonto-Basisarchitektur haben, nicht im Produktionskonto erstellt werden, wenn die Zugriffsberechtigung vorhanden ist, der Alice-Benutzer
kann sich direkt beim Produktionskonto anmelden.
Also vom Identitätskonto, was Alice-Benutzer tun kann, kann sie den Anmeldelink bereitstellen, wenn Sie sehen, dass es sich
um einen mit dem Produktionskonto verknüpften Signaturlink handelt, und die Produktionskontonummer ist ebenfalls angegeben und
endet mit vier, sieben, sechs, drei.
Sobald der ALICE-Benutzer dies hinzufügt, wird die Basiskonfiguration für den Rollenwechsel angezeigt, und es muss nur noch die
Rolle gewechselt werden.
Und jetzt sehen Sie, dass sich der Alice-Benutzer beim Produktionskonto angemeldet hat.
Sie können von hier aus sogar sehen, dass Sie einen Bindestrich sehen, gefolgt von der
Kontonummer, und wenn Sie in die Kontonummer schauen, endet sie mit vier, sieben, sechs, drei, und wenn
Sie in einen zweiten Reiter schauen, der zum Produktionskonto gehört, endet auch diese mit vier, sieben, sechs drei.
Nehmen wir nun an, der Alice-Benutzer hat die entsprechende Arbeit im Produktionskonto abgeschlossen.
Dann kann der Alice-Benutzer fortfahren und zurückwechseln, und jetzt ist Alice zurück zum Identitätskonto.
Nehmen wir später an, Alice möchte einige Tests im Entwicklungskonto durchführen, ähnlich wie sie
zum Produktionskonto gewechselt ist.
Der Ansatz bleibt ähnlich.
Jetzt noch eine Sache.
Da Alice zum Produktionskonto gewechselt war, bleibt die Rollengeschichte hier, wenn sie es noch einmal
tun möchte.
Sie muss also nur auf die Produktion klicken.
Sobald der Benutzer also klickt, kehrt er zum Produktionskonto zurück.
Gut.
Ich hoffe also, dass Sie die Architektur des Identitätskontos auf hohem Niveau verstanden haben.
Unabhängig davon, wie viele Konten vorhanden sind, haben Sie 100 Konten, 200 Konten usw. Es ist egal.
Alles, was Sie tun müssen, ist, dem Benutzer im Identitätskonto Zugriff zu gewähren, damit sich der Benutzer
beim Identitätskonto anmelden kann und sich von hier aus bei allen anderen Konten anmelden kann, abhängig von der
Berechtigung, die der Benutzer hat.
Nun, auf hoher Ebene, wenn Sie die praktische Architektur diskutieren, gibt es drei Schritte, die im
Allgemeinen erforderlich sind.
Erstens muss der Benutzer im Konto erstellt werden.
Ein Konto ist nichts anderes als das Identitätskonto.
Zweitens müssen Sie auch eine kontoübergreifende Rolle im Konto erstellen.
B Nehmen wir also an, der Alice-Benutzer hat sich beim Produktionskonto angemeldet.
Was ist nun der Zugriff, den der Alice-Benutzer haben wird?
Wird sie Zugang zu einer Drei haben?
Wird sie Zugriff auf die E2-Instanz haben und so weiter?
All diese Dinge werden also in dieser spezifischen kontoübergreifenden Rolle definiert.
Und drittens erlauben Sie den Benutzern, zur Rolle von Konto B zu wechseln.
Sie erteilen dem Benutzer also im Identitätskonto die Erlaubnis, dass er je nach mündlicher Genehmigung zu
einem Entwicklungs-, Produktions- oder einem anderen Konto wechseln kann.
Diese Hinweise können also mit dieser praktischen Architektur leicht verstanden werden.
Sie haben ein Identitätskonto.
Alle IAM-Benutzer sind vorhanden, Sie haben eine kontoübergreifende IAM-Rolle in jedem Konto, in dem die Benutzer eine
direkte Verbindung über das Identitätskonto herstellen sollen, und dann können die Benutzer die Rollenoperation ausführen, um eine
Verbindung zu diesem bestimmten Konto herzustellen.
Jetzt sehen Sie im Konto b, dass Sie eine Berechtigung für den S3-Bucket im Konto haben.
C Sie haben die Erlaubnis von easy zu instanzieren.
Wenn sich also ein Benutzer bei Konto C angemeldet hat, hat der Benutzer nur Zugriff auf E zwei und keine anderen Dienste.
Lassen Sie mich Ihnen das auch schnell zeigen.
Lassen Sie uns jetzt im Konto der Produktion schnell das IAM öffnen, und hier habe ich eine Rolle
der C-Bindestrich-Produktion.
Wenn Sie also bemerkt hätten, dass dieser Benutzer diese Rolle verwendet hat, die C-Bindestrich-Produktion ist.
Was ist nun die Berechtigung, die diese Rolle hat?
Die einzige angehängte Berechtigung ist der S3-Nur-Lese-Zugriff.
Wenn also ein Alice-Benutzer versucht, den einfach zu bedienenden Dienst hier zu öffnen, sehen Sie sofort, dass Sie eine Fehlermeldung erhalten.
Die einzige Berechtigung, die Alice hat, ist also der S3-Zugriff.
Wenn Sie also versuchen, das S3 zu öffnen.
Sie sehen, alle Eimer erscheinen als Kriegergitter.
Dies ist also ein allgemeiner Überblick über die Architektur von Identitätskonten.
Und im nächsten Video werden wir weitermachen und es aus praktischer Sicht untersuchen, damit unser Verständnis solide
und klar ist.
Damit schließe ich das heutige Video.