Ressourcenhierarchie und

Vertrauensgrenzen
Save note
TranscriptNotesDownloadsDiscuss
Interactive Transcript - Enable basic transcript mode by pressing
the escape key
You may navigate through the transcript using tab. To save a note for a section of text press CTRL +
S. To expand your selection you may use CTRL + arrow key. You may contract your selection using
shift + CTRL + arrow key. For screen readers that are incompatible with using arrow keys for
shortcuts, you can replace them with the H J K L keys. Some screen readers may require using
CTRL in conjunction with the alt key
Play video starting at ::5 and follow transcript0:05
Bevor wir über die Steuerung des Zugriffs auf Dateien und Ressourcen sprechen,
sollten Sie zunächst die Hierarchie von GCP-Ressourcen verstehen.
Denken Sie an ein Projekt,
an dem Sie beteiligt waren.
Es muss nicht technologiebezogen sein.
Als Projektleiter haben Sie z. B. ausgearbeitet,
welche Ressourcen erforderlich sind
und wer am Projekt beteiligt sein soll.
Sie haben die projektbezogenen Dateien und Ordner organisiert,
damit sie für diejenigen zugänglich waren, die sie benötigten.
Die Nutzung von GCP-Diensten ist damit vergleichbar.
Beginnen wir mit dem Projekt selbst.
Projekte bilden die Basis für die Aktivierung und Nutzung von GCP-Funktionen
wie z. B. Verwalten von APIs, Aktivieren der Abrechnung,
Hinzufügen oder Entfernen von Mitarbeitern
oder Aktivieren anderer Google-Dienste.
Alle Ressourcen, die Sie für ein Projekt nutzen,
z. B. virtuelle Maschinen,
Cloud Storage-Buckets
oder Tabellen in BigQuery,
sind mit diesem Projekt in der Hierarchie verbunden.
Jedes Projekt ist ein eigener Bereich
und jede Ressource gehört zu genau <i>einem</i> Projekt.
Die Projekte Ihres Unternehmens können verschiedene Inhaber und Nutzer haben.
In Unternehmen wird meistens mehr als ein Cloud-Projekt ausgeführt.
Projekte können daher in Ordnern organisiert sein.
Ein Ordner kann Projekte, andere Ordner
oder eine Kombination aus beiden enthalten.
Projekte können also in eine Hierarchie gruppiert werden.
Ihr Unternehmen hat z. B. mehrere Abteilungen,
die jeweils eigene GCP-Ressourcen nutzen.
Mit Ordnern lassen sich diese Ressourcen nach Abteilungen gruppieren.
Sie ermöglichen zudem das Delegieren von Administrationsrechten.
So kann z. B. jedem Abteilungsleiter die volle Eigentümerschaft
aller GCP-Ressourcen seiner Abteilung zugewiesen werden.
Alle von Ihrer Organisation genutzten Ordner und Projekte
können unter einem Organisationsknoten zusammengefasst werden.
Hier ein Beispiel dafür,
wie Sie Ihre Ressourcen organisieren könnten:
Die erste Ordnerebene stellt die Hauptabteilungen der Organisation dar:
Abteilungen X und Y.
Da Ordner Projekte und andere Ordner enthalten können,
enthält der Ordner von Abteilung X weitere Unterordner,
die verschiedene Teams darstellen, z. B. die Teams A und B.
Jeder Teamordner kann weitere Unterordner enthalten,
die verschiedene Anwendungen darstellen, z. B. die Produkte 1 und 2.
Wir können sehen, dass der Ordner für Produkt 1 drei Projekte enthält.
Im Testprojekt können wir die drei zugehörigen Ressourcen sehen.
Diese Ressourcen gehören nur zum Testprojekt.
Auf Ebene von Projekten, Ordnern und Organisationsknoten
können Richtlinien definiert werden.
Bei einigen GCP-Ressourcen können Sie auch
Richtlinien für einzelne Ressourcen festlegen,
z. B. bei Cloud Storage-Buckets.
Richtlinien werden in der Hierarchie nach unten übernommen.
Ressourcen übernehmen die Richtlinien von ihrem übergeordneten Knoten.
Wenn Sie z. B. eine Richtlinie auf Organisationsebene festlegen,
wird sie automatisch von allen untergeordneten Projekten übernommen.
Diese Übernahme ist transitiv.
Das heißt, alle Ressourcen in diesen Projekten
übernehmen ebenfalls diese Richtlinie.
Wenn eine zweite Richtlinie auf Ordnerebene definiert wird,
übernehmen Ordner und Projekte unterhalb dieses Ordners
auch die zweite Richtlinie,
der Organisationsknoten aber nicht.
Eine wichtige Sache muss jedoch beachtet werden.
IAM-Richtlinien lassen Berechtigungen lediglich zu,
sie können sie aber nicht ablehnen.
Richtlinien, die in dieser Hierarchie auf hoher Ebene implementiert sind,
können keine Zugriffe verhindern, die auf niedrigerer Ebene gewährt werden.
Beispiel: Eine auf das Projekt "Bookshelf" angewendete Richtlinie
gibt der Nutzerin Pat das Recht, einen Cloud Storage-Bucket zu ändern.
Eine Richtlinie auf Organisationsebene besagt jedoch,
dass Pat Lesezugriff auf Cloud Storage-Buckets hat,
sie aber nicht ändern darf.
Die allgemeinere Richtlinie ist wirksam.
Sie sollten dies beim Festlegen Ihrer Richtlinien beachten.
Google Cloud bietet Cloud Identity and Access Management (IAM),
damit Sie diese Richtlinien bequem verwalten können.
IAM ist Thema im nächsten Video.