Und willkommen zurück in diesem Video, das wir über die Querstrom-Luftangriffe in vielen
Organisationen diskutieren werden.
Bestimmte Blogs müssen zentralisiert werden.
Und einer der Dienste, in denen die Blogs im Allgemeinen zentralisiert sind, ist ein Geschichtsbuch.
Nehmen wir also an, es gibt drei Atabay-Zweitkonten.
Werden jetzt in einer Währung sein, da es sich um eine Währung handelt.
Sie haben mehrere Instanzen Ihrer Produktion, die jetzt ausgeführt werden.
Im Rahmen der Beschwerde müssen Sie alle Protokolle, die Teil der U. S. zwei Instanzen müssen für
die nächsten sieben Jahre gespeichert werden.
Wo werden Sie das jetzt speichern?
Eine Möglichkeit besteht darin, entweder Sie erstellen ein Geschichtsbuch, es kann gespeichert werden.
Die Protokolle in dieser Geschichte buchen es erneut, erstellen ein Zertifikat in einem Währungsspeicher, alle Protokolle im
Konto dazu und so weiter.
Nun, das wird funktionieren, aber es ist nicht wirklich skalierbar.
Heutzutage haben Organisationen Hunderte von Konten und dieser Ansatz, einen freien Markt in einem lokalen Idalis-Konto
zu schaffen, ist nicht der beste Ansatz.
Was Sie also tun werden, desto besser ist es, wenn Sie ein zentrales Konto haben, das der Kontobereich ist.
Sie erstellen hier einen Dreier-Bucket und alle Protokolle aller anderen Konten können in diesem zentralen S3-Bucket
gespeichert werden.
Beachten Sie jedoch, dass diese Protokolle auch Protokolle anderer Dienste wie Cloud Trail, Cloud Watch,
Anwendungsprotokolle, Systemprotokolle usw. enthalten können.
Im Allgemeinen passiert in Unternehmen, dass, wenn Sie eine S. A. M. Lösungen, die Sicherheitsangriffe
usw. erkennen, diese S. A. M. Systeme sind nicht direkt mit einzelnen Konten verbunden.
Sie sind mit dem S3-Bucket eines zentralen Kontos verbunden und von einem Drei-Bucket unterscheiden sich alle
erforderlichen Protokolle von allen anderen Konten, die als Teil der Organisation verfügbar sind.
Um dies zu erreichen, müssen Sie nun drei Buckets erstellen, die den Zugriff von mehreren verschiedenen
Konten ermöglichen.
Und wie das geht, werden wir heute mit besprechen.
Wissen Sie, wann immer Sie den Bucket-Zugriff für Konto S3 entwerfen, wird empfohlen, eine
Bucket-Richtlinie zu erstellen.
Was also passieren wird, ist, dass wir der Einfachheit Rechnung tragen.
Sie haben also Al-Ghamdi, das zentrale Konto, und Konto B, auf dem die beiden
einfachen Instanzen der Produktionsumgebung ausgeführt werden.
Sie möchten also, dass das Konto B die Daten in den drei Buckets der Buchhaltung speichert.
Die empfohlene Methode besteht darin, eine neue Bucket-Richtlinie zu erstellen und diese Bucket-Richtlinie, wie sie besagt, Konto B
erlauben, Protokolle an die Dezentralisierung des Buckets zu übertragen.
Sobald Sie also diese Bucket-Richtlinie dem zentralistischen Bucket zuordnen, wird dieser Bucket fortfahren und die Übertragung der Protokolle
ermöglichen, wenn man bedenkt, dass sie von Konto B stammen. Dies ist also eine Übersicht auf sehr
hoher Ebene.
Sehen wir uns nun an, wie genau diese Bucket-Richtlinie aussieht.
Dies ist also der einfache Screenshot einer Bucket-Richtlinie.
Wenn Sie nun in dieser Bucket-Richtlinienaktion sehen, sind drei Aktionen zulässig.
Sie müssen widersprechen, Objekt setzen und Objekt setzen ist.
Im Grunde möchten Sie also, dass das Konto die Daten überträgt und den Bucket zentralisiert.
Sie möchten verschiedene Dinge wie den Löschvorgang auch nicht wirklich.
Andernfalls können wir annehmen, dass eine der beiden Instanzen in Aktion mit einem kompromittierten Angreifer
im Wesentlichen alle Daten aus demselben Bucket löschen kann.
Insbesondere beim Entwerfen eines Cross-Accounts, einer Drei-Bucket-Richtlinie, ist es sehr wichtig,
nur minimal erforderliche Aktionen zuzulassen.
Dies ist sehr wichtig.
Gut.
Aktion ist also großartig, Objekt zu platzieren und Objekte hier zu platzieren.
Das ist für die Zeit in Ordnung.
Wir sind jetzt im tiefen Prinzip.
Dies ist ein sehr wichtiger Teil.
Sie geben den Bereich des Kontos B an, sodass Sie die Kontonummer gefolgt von der Route haben.
In solchen Fällen kann also jeder Benutzer des Kontos B oder eines beliebigen i. e. mit Indien verstrickt sind, können über die
richtige Politik nachdenken, die ihnen sagt, dass sie diese drei Operationen an der Ressource durchführen können, die
der zentrale Strathbogie-Auftrag ist.
Dies ist also die grundlegende Bucket-Richtlinie.
Lassen Sie uns also eines tun.
Lassen Sie uns beides ausprobieren, um die Dinge genauer zu besprechen.
So ähnlich wie die Architektur, die wir für die heutige Demo besprochen haben, werden wir zwei Konten haben.
Sie haben jetzt Konten und Konto B in meinem Chrome-Browser. Ich habe einen Landkreis, daher betrachten wir diesen als
unseren Landkreis.
Und ich habe noch ein Konto, das Teil meines Firefox-Browsers ist, und wir werden es so betrachten, wie es sein
wird.
Am Ende des Videos sollten wir also in der Lage sein, die Protokolle von Konto B auf den zentralisierten Brustkorb von Konto A zu
verschieben.
Lassen Sie uns also zuerst den zentralistischen Haushalt erstellen.
Lassen Sie uns also in meinem Chrome-Browser einen neuen erstellen.
Nennen wir es einmal meinen Gabey Labs Bindestrich Central, dann lass uns weitermachen und einen perfekten Solares drei
Bucket erstellen.
Wenn Sie sich nun die Berechtigungen hier ansehen, gehen wir noch einmal nach unten.
In der Bucket-Richtlinie sehen Sie ab sofort, dass Sie nicht wirklich über eine Bucket-Richtlinie verfügen.
Das bedeutet, dass die anderen Konten ihre Daten nicht an die zentrale Buchung übertragen können.
Was wir also brauchen, ist, dass hier eine Bucket-Richtlinie aktiviert wird.
Lassen Sie uns also eines tun.
Fahren wir fort und fügen eine Bucket-Richtlinie hinzu.
Es war uns also egal, wie zentral die Drei-Bucket-Richtlinie ist, die wir zur Verfügung haben, und wir haben darüber bereits
gesprochen.
Sie haben also drei Aktionen und innerhalb der Ressource haben Sie den Namen der drei Buckets.
Nun, ein wichtiger Teil, den wir besprechen, ist, dass Sie Ihre Kontonummer des Kontos hinzufügen müssen, das
die Sperren zu diesem zusätzlichen Bucket schiebt, mit dem diese Richtlinie verknüpft ist.
Lassen Sie mich also von meinem Firefox aus die Kontonummer kopieren, und ich werde einmal
Staatsprüfer sein.
Dann kopieren wir die Bucket-Richtlinie und lassen Sie mich gleich mit Ihnen sprechen.
So sieht es also aus.
Lassen Sie uns fortfahren und die Änderung speichern.
Perfekt.
Wurde eine Drei-Bucket-Richtlinie erfolgreich hinzugefügt?
Groß.
Damit ist unser erster Teil fertig.
Der zweite Teil bezieht sich nun auf die verantwortliche Konfiguration.
Für dieses Beispiel haben wir nun zwei Instanzen verwendet, aber es kann auch ein Amusa sein.
Nehmen wir an, ich bin ein Benutzer von Konto B und möchte einige kritische Rechenzentrumslisten hochladen, bei denen der Endbenutzer auch in der
Lage sein sollte.
Für das heutige Video erstellen wir zu Testzwecken einen neuen AYAM-Benutzer.
Kommen wir also schnell zum Enddienst von Konto B und
innerhalb.
Lassen Sie uns der Einfachheit halber einen neuen Benutzer erstellen.
Wir nennen das einfach.
Benutzer werden dem Benutzer programmgesteuerte Zugriffsberechtigungen erteilen.
Lassen Sie uns dies ab sofort vermeiden und erstellen Sie den Benutzer.
Perfekt.
Jetzt, nur um unseren Testzweck zu vereinfachen, habe ich auch eine einfache Haltung zu Amazon Linux.
Und innerhalb dieses einfachen Vorgangs, da ich einen neuen Benutzer und einen Benutzernamen erstelle, werden die
Qualitäten von Lezzies Orleck sein und wir werden den Benutzer auf Konto B umstellen und innerhalb dieses Benutzers den
geheimen Zugriff von Kadian assoziieren.
Sehen wir uns also die Dabbler-Konfiguration an.
Ich füge den Zugriffsschlüssel hinzu.
Lassen Sie uns einen geheimen Zugriffsschlüssel und den Regionsnamen behalten.
Nehmen wir einfach die Standardregion von zwei USD und sogar unser Bucket ist nahezu perfekt.
Unser Konto ist also mit den eingerichteten Zugangsdaten verknüpft.
Wenn Sie zu diesem Zeitpunkt ein Estriol durchführen, sollten Sie den benötigten Zugriff sehen, hauptsächlich
weil mit diesem Konto keine IAM-Richtlinie verknüpft ist.
Der zweite wichtige Teil dieser Architektur besteht nun darin, dass die IBM-Einheit, vielleicht bin ich Benutzer oder Ambro, auch die Berechtigung haben
muss, die Daten zu pushen, um die Neubudgetierung zu zentralisieren.
Es ist nicht so, dass Sie die Bucket-Richtlinie im zentralisierten Rivergate und allen IAM-Entitäten im Konto zugelassen
haben.
Das werden wir schaffen.
Die Police muss auch mit dem geänderten Konto verknüpft werden.
Wir müssen also eine neue IAM-Richtlinie für den IAM-Benutzer erstellen, den wir erstellt haben und sein
werden.
Und was uns diese Richtlinie ermöglicht.
Auch hier sind die Reaktionen Get Object, Put Object und Put Object hier und hier spezifizieren wir dezentral
und arbeiten daran.
Ich hoffe, Sie haben die Bedeutung der Akronymrichtlinie verstanden.
Wir werden also fortfahren und dies und die Richtlinie hierher kopieren und diese IAM-Richtlinie dem Konto zuordnen,
das Amusa lautet.
Lassen Sie uns den Benutzer hier öffnen.
Fügen wir eine neue Inline-Richtlinie hinzu, die an Jason geht.
Ich habe die Richtlinie hier festgelegt.
Lassen Sie uns eine Überprüfungsrichtlinie erstellen und der Name des Cross-Accounts von Liz' Rolltreppe lautet drei, und wir erstellen eine
Richtlinie.
Perfekt.
Damit sind nun alle notwendigen Konfigurationen für Account und achonwa abgeschlossen.
Also lassen Sie uns die Dinge testen.
Also lade ich zunächst einige Beispieldaten in den Attribut-Bucket der Buchhaltung hoch.
Dies ist also etwas, das wir direkt von der Konsole aus tun können.
Lass uns das tun.
Ich definiere die Datei.
Sie können einfach jede temporäre Datei hinzufügen, die Sie in Ihrem System haben.
Perfekt.
Die Datei wird also im zentralen Bucket hinzugefügt.
Da wir nun innerhalb der Bucket-Richtlinie das Gate-Objekt zugelassen haben, bedeutet dies im Grunde die Unermesslichkeit
des Kontos.
Wir sollten in der Lage sein, die Daten aus der Historie zu holen.
Also vom Konto aus probieren wir es aus.
Ich sage, der Ort ist drei.
Versuchen Sie, die Daten zu kopieren, mit denen DataDot bezahlt werden soll, und das Budget ist wahrscheinlich weniger zentral und wird hier
der Inhalt sein.
Und Sie sehen, dass der Download-Vorgang einwandfrei funktioniert.
Wenn ich also einen kleinen Bereich mache, müssen wir für DataDot bezahlen.
Diese Dinge funktionieren wie erwartet.
Versuchen wir auch, einige Daten von Ihnen hochzuladen.
Lassen Sie uns also eine neue Datei erstellen, ich nenne sie Punkttext von Konto B und versuchen wir, diese Datei als
drei strikte Konto B zu kopieren, und wir möchten sie in mein linkes Bindestrichzentrum einfügen.
Und Sie sehen, der Upload funktioniert auch einwandfrei.
Wenn ich jetzt die Seite hier aktualisiere, sollten Sie sehen, dass Sie den Punkt berücksichtigt haben und auch verfügbar sind.
Groß.
Ich hoffe, Sie haben damit einen allgemeinen Überblick über den Workflow hinter dem Erfolg von Corozal-Inhalten
verstanden.
Aber in diesem Stadium sind wir noch nicht fertig.
Das ist ein sehr wichtiger Teil, der auch untersucht werden muss.
Darüber werden wir im kommenden Video ausführlich diskutieren.
Aber ich werde Ihnen nur kurz das Problem geben, mit dem Sie in dieser Architektur konfrontiert werden.
Was nun passiert ist, ist, dass beide Dateien Teil dieses Buckets sind, aber die Berechtigungen, die
diesen beiden Dateien zugeordnet sind, sind völlig unterschiedlich.
Schauen wir uns das Konto jetzt schnell an.
Seien Sie schmutzig, wenn ich fortfahre und versuche, diese Datei herunterzuladen.
Sie sehen, ich erhalte die Nachricht "Zugriff verweigert".
Sehr interessant in ähnlicher Weise sind die Dateien, die vom Konto selbst hochgeladen wurden.
Wenn ich versuche, diese Datei herunterzuladen, versuchen wir das.
Sie sehen, der Dateidownload funktioniert einwandfrei.
Der Hauptgrund, warum dies nicht funktioniert, ist also, dass dieses Dateikonto finanziert oder B mit dem Konto B verknüpft ist
und die nächste Datei, die für DataDot bezahlt werden soll, jetzt mit dem Konto A verknüpft ist, obwohl ich einen
administrativen Zugriff auf Konto E habe, dies bedeutet nicht, dass ich Berechtigungen habe oder Dateien,
die von dem Konto hochgeladen wurden, daher ausführlich besprochen werden.
Es ist jedoch sehr wichtig zu wissen, dass ich bei der Implementierung in einer Produktionsumgebung
dieses Problem gesehen habe, bei dem mehrere Teams in einem zentralen S3-Bucket zusammenarbeiten und das andere Team
alle seine Daten in Hunderten von Gigabyte hochlädt.
Und später stellen sie fest, dass auf alle Daten, die in den zentralen S3-Bucket hochgeladen wurden, keiner der
Benutzer aus unserem Landkreis zugreifen konnte.
Dies war also ein bisschen mühsam und wir werden darüber diskutieren, warum dies passiert und wie dies am besten gelöst werden kann.
Damit endet also das heutige Video.