Hinweis:

Ausführliche Informationen zu tagbasierten Oracle Cloud Infrastructure Identity and Access Management-Policys

Einführung

Oracle Cloud Infrastructure Identity and Access Management-(OCI IAM-)Policys sind der Eckpfeiler einer robusten und sicheren Cloud-Umgebung. Sie bieten einen leistungsstarken, flexiblen Mechanismus zur Kontrolle des Zugriffs auf OCI-Ressourcen, mit dem sichergestellt wird, dass nur autorisierte Benutzer und Services bestimmte Aktionen für bestimmte Ressourcen ausführen können.

Im Kern besteht eine OCI-IAM-Policy aus einer Reihe deklarativer Anweisungen, die in einer menschenlesbaren Syntax geschrieben sind, die vorgibt, wer auf was und unter welchen Bedingungen zugreifen kann. Mit diesen Policys können Unternehmen das Prinzip der geringsten Berechtigungen durchsetzen, indem sie Benutzern und Services nur die Berechtigungen erteilen, die sie zur Ausführung ihrer Aufgaben benötigen, und nicht mehr. Dadurch werden Sicherheitsrisiken minimiert und die Betriebseffizienz beibehalten.

OCI-IAM-Policys werden auf verschiedenen Ebenen der OCI-Hierarchie angewendet, einschließlich Compartments, Mandanten und bestimmten Ressourcen, sodass sie sich sehr an komplexe Organisationsstrukturen anpassen lassen. Mit der Policy-Vererbung und Compartmentisierung von OCI können Administratoren granulare Kontrollen einrichten, die auf ihre spezifischen Sicherheits- und Betriebsanforderungen zugeschnitten sind. Weitere Informationen zu OCI-Policys finden Sie unter Erste Schritte mit Policys.

In diesem Tutorial werden wir uns mit der Bedeutung der Richtlinienoptimierung befassen, die Best Practices für die Feinabstimmung von Richtlinien untersuchen, um optimale Ergebnisse zu erzielen, und Szenarien hervorheben, in denen die Richtlinienoptimierung in vollem Umfang genutzt werden kann.

Ziele

Voraussetzungen

Policy-Komponenten und -Syntax entmystifizieren

Um OCI IAM-Policys effektiv zu optimieren, ist es wichtig, ihre Struktur und Schlüsselkomponenten zu verstehen. Policys in OCI definieren Berechtigungen, indem sie angeben, wer (Principal), was (Aktion) was (Ressource) und wo (Geltungsbereich) ist. Im Folgenden wird dies ausführlicher beschrieben:

Schlüsselkomponenten einer OCI-IAM-Policy

Bonustipp: Sets-Intersect-Konzept in OCI-IAM-Policy verstehen

Mit dem Sets-Intersect in OCI-IAM-Policys wird nur dann Zugriff erteilt, wenn sich zwei Wertesets überschneiden. Dadurch wird sichergestellt, dass Berechtigungen dynamisch basierend auf Gruppenmitgliedschaft, Ressourcentags oder anderen Attributen erteilt werden, anstatt bestimmte Benutzer oder Gruppen in Policys hartcodieren zu müssen.

OCI-IAM-Policy-Modell für großen Umfang

OCI-IAM-Policys sind eines der grundlegenden Elemente zur Sicherung von Workloads auf OCI. Es ist entscheidend, eine große Arbeitslast für unsere Kunden skalieren und unterstützen zu können. Aus diesem Grund haben wir ein Policy-Modell erstellt, das eine kleine Anzahl von Policys innerhalb der Policy-Limits von OCI erfordert, die für jede Workload-Größe funktionieren. Im Folgenden finden Sie einige Gründe für die Einführung des skalierbaren Policy-Modells. Weitere Informationen finden Sie unter IAM mit Identitätsdomainlimits.

Das Tuning von OCI-IAM-Policys ist eine wichtige Aufgabe für die Aufrechterhaltung einer sicheren, skalierbaren und effizienten Cloud-Umgebung bei gleichzeitiger Einhaltung der Policy-Limits von OCI. Deshalb ist dieser Prozess unerlässlich:

Die Rolle von Tagging im Policy-Management

Tagging ist ein leistungsstarkes Feature in OCI, das das Policy-Management erheblich verbessert, indem eine fein granulierte Kontrolle über Ressourcen ermöglicht wird. Tags sind Metadatenlabels, die als Schlüssel/Wert-Paare dargestellt werden und an Ressourcen angehängt werden können. Sie helfen bei der Organisation, Verwaltung und Durchsetzung der Zugriffskontrolle in großem Maßstab, insbesondere in komplexen Cloud-Umgebungen mit mehreren Teams und Projekten. Weitere Informationen finden Sie unter Überblick über Tagging.

So verbessert Tagging das Policy-Management

  1. Vereinfacht die Ressourcenidentifizierung: Tags bieten eine einheitliche Möglichkeit, Ressourcen basierend auf Attributen wie Projekten, Umgebungen, Verantwortlichen oder Abteilungen zu kategorisieren. Dadurch wird die Anwendung von Policys auf bestimmte Teilmengen von Ressourcen vereinfacht.

    Beispiel: Durch Tagging von Ressourcen mit Project: ProjectX werden gezielte Zugriffs-Policys aktiviert.

    Allow group Developers to manage instances in tenancy where tag.Project = 'ProjectX'

  2. Dynamische Policy-Durchsetzung aktivieren: Policys, die auf Tags basieren, passen sich an sich ändernde Ressourcenattribute an. Beispiel: Wenn eine neue Instanz mit Environment: Production getaggt ist, erbt sie automatisch Policys, die für Produktionsumgebungen definiert sind.

    Beispiel-Policy:

    Allow group QA to inspect instances in tenancy where tag.Environment = 'Test'

  3. Optimierung der Governance für mehrere Projekte und Teams: Mit Tags können Sie den Zugriff isolieren, indem Sie Ressourcen bestimmten Teams oder Projekten zuordnen. Dies reduziert die Komplexität bei der Verwaltung von Berechtigungen über mehrere Gruppen hinweg.

  4. Erleichtert die Automatisierung: Tags können automatisierte Workflows für die Erstellung, Überwachung und das Lebenszyklusmanagement von Ressourcen fördern. Beispiel: Kostenverfolgungsskripte können alle Ressourcen abrufen, die mit CostCenter: Marketing getaggt sind, um detaillierte Spesenabrechnungen zu generieren.

  5. Verbessert Kostenmanagement und Reporting: Tags ermöglichen eine detaillierte Kostenzuordnung zu bestimmten Projekten, Abteilungen oder Umgebungen. Auf diese Weise können Unternehmen Ausgaben verfolgen und Budgets effektiver optimieren.

Tag-Governance: Tag-Management steuern

Um Konsistenz, Zuverlässigkeit und Sicherheit bei der Policy-Verwaltung zu gewährleisten, sollten die Erstellung und Änderung von Tags streng kontrolliert werden. Governance stellt sicher, dass Tags korrekt angewendet werden und den Organisationsstandards entsprechen. Die Beschränkung der Tagverwaltung auf eine bestimmte Gruppe von Einzelpersonen oder Gruppen ist ein Schlüsselelement für die Aufrechterhaltung der Kontrolle, Konsistenz und Sicherheit in der Cloud-Umgebung eines Unternehmens.

Tagbasierte OCI-IAM-Policys für Anwendungsfälle aus der Praxis

Lassen Sie uns jetzt mit all den oben genannten Informationen an der Optimierung von OCI IAM-Policys für Benutzerprinzipien und Instanzprinzipien in realen Anwendungsfällen arbeiten. Aber bevor wir das tun, gibt es einige allgemeine Richtlinien, die jeder Kunde unabhängig von seinem Anwendungsfall benötigt.

OCI-IAM-Policys für Benutzer-Principals skalieren

OCI IAM-Policy-Modell: In diesem Policy-Modell besteht das Ziel darin, eine kleine Anzahl verwaltbarer Policys zu schreiben, die durch Daten (in unserem Fall Tags) informiert werden und auch als attributbasierte Zugriffskontrolle bezeichnet werden. Wir referenzieren Tags, die der Zielressource oder dem Zielressourcen-Compartment für die Zugriffskontrolle zugewiesen sind, als Berechtigungstags.

Berechtigungstags: Definieren Sie Berechtigungstags für jede Kombination aus Verb (Aktion) und Ressourcentyp im Mandanten. Sie definieren eine eindeutige Berechtigung, die Sie einer Benutzergruppe für Zielressourcen zuweisen müssen. Die Liste ist nicht einmal festgelegt und fertig. Beginnen Sie mit einer kleinen Anzahl von Berechtigungs-Tags. Nachdem Sie ein Handle für das Policy-Modell erhalten haben, können Sie weitere Berechtigungstags hinzufügen. Für dieses Tutorial erstellen wir einen Berechtigungstag-Namespace als mgmt. Außerdem erstellen wir einen Tag-Namespace (wir nennen diesen infosec) mit einem Tagschlüssel namens gname.

  1. Für die folgende Compartment-Struktur mit vier Ressourcentypen und zum Zuweisen von Verwaltungs- und Verwendungsberechtigungen für diese Ressourcen erstellen wir Berechtigungstags.

    Berechtigungstags

  2. Erstellen Sie für jede Berechtigung, die Sie einem Ziel zuweisen müssen (in den meisten Fällen Compartments), eine Gruppe. Den Ressourcen (mit Compartment-Standardtags) und Ressourcen-Compartments weisen wir Berechtigungstags zu. Der Tagwert ist die Gruppe, der die Berechtigung für die Zielressource erteilt werden soll.

    Berechtigungstaggruppen

  3. Nachdem Berechtigungs-Tags definiert wurden, können Sie Policys schreiben. Das Endergebnis ist, dass nur eine Policy pro Berechtigungstag im Mandanten definiert werden muss. Die gleiche Policy für die angegebene Berechtigung wird im gesamten Mandanten ausgeführt.

    Berechtigungstag-Policys

  4. Wenn wir mehr Workloads integrieren, müssen Sie möglicherweise weitere Berechtigungstags und Policys für diese Berechtigungstags hinzufügen, wenn mehr Ressourcentypen verwaltet werden müssen. Andernfalls weisen Sie der neuen Workload nur vorhandene Berechtigungstags mit einer Gruppe von Benutzern zu, die Zugriff haben sollen. Wir müssen keine neuen Richtlinien für die neue Arbeitslast schreiben.

Dieser Ansatz bleibt in allen hier diskutierten Beispielen konsistent und dient als Grundlage für die Definition von OCI IAM-Gruppen und -Policys.

Beispiel 1: Compartment für jede Anwendung

Schritt 1: Verschaffen Sie sich ein umfassendes Verständnis des Geschäftsüberblicks des Kunden

CompanyA ist ein wachsendes Technologieunternehmen, das mehrere Cloud-native Anwendungen für seine Kunden entwickelt und bereitstellt. Jede Anwendung erfüllt ein bestimmtes Kundensegment mit strengen Sicherheits- und Complianceanforderungen. Um Isolation, Skalierbarkeit und effiziente Zugriffskontrolle sicherzustellen, organisiert CompanyA seine OCI-Ressourcen mit einem strukturierten Compartment-Ansatz.

Schritt 2: Compartment-Struktur für die Workload entwerfen

Wie beschrieben, folgt CompanyA dem OCI-IAM-Policy-Modell zur Skalierung ihrer OCI-IAM-Policys. Sie haben separate Compartments für ihre Anwendungen erstellt, um die Ressourcenisolation aufrechtzuerhalten.

Anwendungsfall 1

Hinweis: Nur Administratoren sollten den Tag-Namespace mgmt und infosec verwalten können.

Schritt 3: Entwerfen Sie die folgenden Berechtigungstags des Typs Verb+Resource Kombination

Erstellen Sie Gruppen in OCI.

  1. Melden Sie sich bei der OCI-IAM-Domain mit einem Admin-Account an, der über die Berechtigung zum Erstellen von Gruppen verfügt.

    OCI-Home

  2. Gehen Sie zu Identität und Sicherheit, und klicken Sie unter Identität auf Domains.

    Domains

  3. Wählen Sie das Compartment aus, und klicken Sie auf die Domain, für die Sie die Gruppen erstellen möchten.

    Domains wählen

  4. Klicken Sie auf Gruppen.

    Gruppen

  5. Definieren Sie Ihre Gruppen basierend auf den Berechtigungstags. (Optional) Fügen Sie Ihre Benutzer zu diesen Gruppen hinzu.

    Gruppen erstellen

Hinweis: Sie müssen Gruppen für eine eindeutige Kombination aus Berechtigung und Ziel erstellen. Wenn dieselbe funktionale Benutzergruppe (NetworkAdmin) Zugriff zum Verwalten des Netzwerks über alle Ziele hinweg benötigt, benötigen Sie nur eine Gruppe, um den Zugriff über alle Ziele hinweg zu verwalten.

Im Folgenden sind die Berechtigungstags und OCI-IAM-Gruppen für diese Tags aufgeführt. Führen Sie die oben genannten Schritte aus, um Gruppen für jedes der definierten Berechtigungstags zu erstellen.

  1. Root Compartment: Das Root Compartment dient als Managementschicht der obersten Ebene. Hier werden unsere Admin-Gruppen mit Berechtigungs-Tags getaggt. Die folgenden Tags sind:

    • Administratoren: manageall-Berechtigung zur Verwaltung der gesamten Mandantenverwaltung.
    • UseAdministrators: useall-Berechtigung für den mandantenübergreifenden Zugriff auf Ressourcen.
    • Auditor: readall-Berechtigung mit schreibgeschütztem Zugriff auf Ressourcen für die mandantenübergreifende Überwachung.

  2. Compartment-Modell pro Anwendung: CompanyA enthält mehrere cloudbasierte Anwendungen. Für jede Anwendung wird ein separates übergeordnetes Compartment erstellt. Sehen wir uns an, wie dieses Modell für Anwendung 1 (App1) und Anwendung 2 (App2) als übergeordnete Compartments gilt.

    • Anwendung 1 (App1): Eine kundenorientierte Anwendung, die auf OCI gehostet wird.

      • Netzwerk-Compartment: Compartment für alle netzwerkbezogenen Ressourcen wie VCN, Subnetze usw. Jetzt können Sie die Berechtigungstags und die zugehörigen OCI-IAM-Gruppen erstellen.
        • App1NetworkAdmin: managenetwork-Ressourcenberechtigungstag für Ingenieure, die Netzwerkressourcen für App1 verwalten.
        • App1NetworkUser: usenetwork-Ressourcenberechtigungstag für Entwickler, die begrenzten Zugriff auf Netzwerkkonfigurationen von App1 benötigen.
        • App1NetworkReader: readnetwork-Ressourcenberechtigungstag für Auditoren, die das Netzwerksetup von App1 prüfen.
      • Compute Compartment: Compartment für Compute-Instanzen. Jetzt können Sie die Berechtigungstags und die zugehörigen OCI-IAM-Gruppen erstellen.
        • App1ComputeAdmin: managecompute-Ressourcenberechtigungstag für Systemadministratoren, die Compute-Instanzen für das App1-Backend bereitstellen und skalieren.
        • App1ComputeUser: usecompute-Ressourcenberechtigungstag für Entwickler, die Backend-Services von App1 bereitstellen und testen.
        • App1ComputeReader: readcompute-Ressourcenberechtigungstag für Auditoren, die Compute-Ressourcennutzung für App1 überwachen.
      • Daten-Compartment: Compartment für datenbank- und speicherbezogene Ressourcen. Jetzt können Sie die Berechtigungstags und die zugehörigen OCI-IAM-Gruppen erstellen.
        • App1DataAdmin: managedb-Ressourcenberechtigungstag für Datenbankadministratoren, die autonome Oracle-Datenbanken und OCI Object Storage für App1 verwalten.
        • App1DataUser: usedb-Ressourcenberechtigungs-Tag für Data Scientists, die zur Analyse auf Datasets in Bezug auf App1 zugreifen.
        • App1DataReader: readdb-Ressourcenberechtigungstag für Auditoren, die Datenbankkonfigurationen von App1 prüfen.

    • Anwendung 2 (App2): Ein internes ERP-System (Enterprise Resource Planning) für die Vorgänge von CompanyA.

      Hinweis: Auch hier folgen wir demselben Compartment-Strukturansatz und erstellen Netzwerk-Compartment, Compute Compartment und Daten-Compartment unter dem übergeordneten Compartment App2. Um Redundanz zu vermeiden, notieren wir nur die Berechtigungstags und OCI-IAM-Gruppen für App2.

      • Netzwerk-Compartment:

        • App2NetworkAdmin: managenetwork-Ressourcenberechtigungstag.
        • App2NetworkUser: usenetwork-Ressourcenberechtigungstag.
        • App2NetworkReader: readnetwork-Ressourcenberechtigungstag.

      • Compute-Compartment:

        • App2ComputeAdmin: managecompute-Ressourcenberechtigungstag.
        • App2ComputeUser: usecompute-Ressourcenberechtigungstag.
        • App2ComputeReader: readcompute-Ressourcenberechtigungstag.

      • Daten-Compartment:

        • App2DataAdmin: managedb-Ressourcenberechtigungstag.
        • App2DataUser: usedb-Ressourcenberechtigungstag.
        • App2DataReader: readdb-Ressourcenberechtigungstag.

Hinweis: Wenden Sie ein Berechtigungstag auf ein Ziel an (das Ziel kann eine Ressource oder ein Compartment sein), um festzulegen, welche Gruppe diese spezifische Berechtigung für das Ziel für App1 und App2 hat.

Schritt 4: OCI-IAM-Policys für diese Berechtigungstags schreiben

Wir erstellen die Policys für CompanyA mit demselben Ansatz, der hier beschrieben wird: Haben Sie weniger als mehr - OCI-IAM-Policys für Gruppen skalieren. Erstellen Sie dazu einen Tag-Namespace (wir nennen diese infosec) mit einem Tagschlüssel namens gname.

  1. Melden Sie sich bei der OCI-IAM-Domain mit einem Admin-Account an, der über die Berechtigung zum Erstellen von Policys verfügt.

    OCI-Home

  2. Gehen Sie zu Identität und Sicherheit, und klicken Sie unter Identität auf Policys.

    Policys

  3. Wählen Sie das Root-Compartment, und klicken Sie auf Policy erstellen.

    Policys erstellen

  4. Geben Sie Name, Beschreibung zu Ihrer Policy ein, und fügen Sie die Policy-Anweisungen hinzu. Klicken Sie auf Erstellen.

    • Policy für alle Ressourcen:

      Allow any-user to manage all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageall)
Allow any-user to use all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useall)
Allow any-user to read all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readall)

      Policy-Anweisungen

      Hinweis: Führen Sie dasselbe Verfahren aus, um alle folgenden Policys zu definieren und die entsprechenden Policy-Anweisungen hinzuzufügen.

    • Cloudguard-Policy:

      Allow any-user to manage cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecspm)
Allow any-user to use cloud-guard-family in tenancy where
sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecspm)
Allow any-user to read cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcspm)

    • Netzwerkrichtlinie:

      Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork)
Allow any-user to use virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useetwork)
Allow any-user to read virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readnetwork)

    • Compute-Policy:

      Allow any-user to manage instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecompute)
Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecompute)
Allow any-user to read instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcompute)

    • Datenbank-Policy:

      Allow any-user to manage database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managedb)
Allow any-user to use database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usedb)
Allow any-user to read database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readdb)

Beispiel 2: Compartment für jeden Kunden/Mandanten

Schritt 1: Verschaffen Sie sich ein umfassendes Verständnis des Geschäftsüberblicks des Kunden

CompanyB Solutions ist ein führender unabhängiger Softwareanbieter (Independent Software Vendor, ISV), der mandantenbasierte SaaS-Anwendungen in den Bereichen Cloud-Infrastruktur, Datenmanagement und Analyse bereitstellt. CompanyB bedient mehrere Kunden branchenübergreifend und bietet nahtlose, sichere und skalierbare Lösungen. Ihr Erfolg hängt davon ab, dass OCI mit einer gut konzipierten Fachstruktur verwendet wird, um Ressourcen effizient zu verwalten und gleichzeitig die Sicherheits- und Complianceanforderungen einzuhalten.

Schritt 2: Compartment-Struktur für die Workload entwerfen

CompanyB hat die Workloads für ihre Kunden isoliert und ein dediziertes Unter-Compartment erstellt. Außerdem verfügen sie über ein Netzwerk-Compartment, einen Shared Storage und ein Datenbank-Compartment. Selbst CompanyB folgt dem OCI-IAM-Policy-Modell zur Skalierung ihrer OCI-IAM-Policys.

Anwendungsfall 2

Schritt 3: Entwurf nach Berechtigungstags des Typs Verb+Resource Kombination

Informationen zum Erstellen von Gruppen finden Sie in Beispiel 1, Schritt 3. Sie müssen Gruppen für alle unten definierten Berechtigungstags erstellen.

  1. Root Compartment - Centralized Governance: Die Root-Komponente fungiert als zentrale Schicht für die Überwachung aller Ressourcen und Aktivitäten im gesamten OCI-Mandanten. Hier werden unsere Admin-Gruppen mit Berechtigungs-Tags getaggt. Die folgenden Tags sind:

    • Administratoren: manageall-Berechtigung zur Verwaltung der gesamten Mandantenverwaltung.
    • UseAdministrators: useall-Berechtigung für den mandantenübergreifenden Zugriff auf Ressourcen.
    • Auditor: readall-Berechtigung mit schreibgeschütztem Zugriff auf Ressourcen für die mandantenübergreifende Überwachung.

  2. Netzwerk-Compartment - Backbone of Operations: Das Netzwerk-Compartment unterstützt die Cloud-Netzwerkinfrastruktur von CompanyB und ermöglicht die Konnektivität über alle Ressourcen hinweg. Dazu gehören virtuelle Cloud-Netzwerke (VCNs), Subnetze, Gateways und Load Balancer. Lassen Sie uns die Berechtigungstags und die entsprechenden OCI-IAM-Gruppen dafür definieren.

    • NetworkAdmin: managenetwork-Ressourcenberechtigungstag für Ingenieure, die Netzwerkressourcen für CompanyB verwalten.
    • NetworkUser: usenetwork-Ressourcenberechtigungstag für Entwickler, die begrenzten Zugriff auf Netzwerkkonfigurationen von CompanyB benötigen.
    • NetworkReader: readnetwork-Ressourcenberechtigungstag für Auditoren, die das Netzwerksetup von CompanyB prüfen.

  3. Mandanten-Compartment - Isolierte Compartments für verschiedene Kunden-Workloads: Das Mandanten-Compartment ist so strukturiert, dass Ressourcen und Workloads für jeden Client (Mandanten) isoliert werden. Dadurch wird sichergestellt, dass CompanyB sichere und private Services bereitstellt und gleichzeitig die betriebliche Effizienz aufrechterhält.

    • Compartment Mandant 1: Mandant 1 stellt einen wichtigen Enterprise-Client dar, der CompanyB für Anwendungsentwicklungs- und Logging-Services verwendet. Im Folgenden sind die Berechtigungstags und die jeweiligen OCI-IAM-Gruppen aufgeführt:

      • t1devadmin: Die Ressourcenberechtigung manageappdev für das Entwicklungsteam für Mandant 1 verfügt über administrative Berechtigungen zum Konfigurieren und Bereitstellen benutzerdefinierter Anwendungen.
      • t1devuser: useappdev-Ressourcenberechtigung zum Überwachen und Anpassen von Anwendungsressourcen. Die Entwickler von Tenant 1 nutzen diese Ressourcen für die tägliche Entwicklung und das Testen.
      • t1logsadmin und t1devuser: Die Ressourcenberechtigungen managelogs und uselogs für Logging- und Überwachungsrollen stellen sicher, dass Administratoren Logging-Services konfigurieren, während Entwickler auf Logs zugreifen, um Anwendungen zu debuggen und zu optimieren.
      • t1devadmin und t1devuser: managecspm- und usecspm-Ressourcenberechtigung für Mandant 1, da sie sich ebenfalls auf den Sicherheitsstatus konzentrieren und Sicherheitsrisiken überwachen und beheben können.

    • Tenant 2 and Tenant 3 Compartments: The structure for Tenant 2 and Tenant 3 mirrors that of Tenant 1, with roles like t2devadmin, t2devuser, t3devadmin, t3devuser, t2logsadmin and t3logsadmin ensuring that each tenant operates in a fully isolated environment. Mit diesem Ansatz kann CompanyB eine konsistente Governance aufrechterhalten und gleichzeitig auf bestimmte Mandantenanforderungen eingehen.

    • Gemeinsames Compartment - Zentralisierte Ressourcen für alle Mandanten: Das gemeinsam verwendete Compartment umfasst Ressourcen wie Datenbanken und Objektspeicher, die von mehreren Mandanten verwendet werden, aber aus Datenschutz- und Sicherheitsgründen logisch getrennt bleiben.

      • Datenbank-Compartment:
        • dbadmin: Die Ressourcenberechtigung managedb für die Datenbankadministratoren von CompanyB verarbeitet gemeinsam verwendete Datenbanken, die von allen Mandanten verwendet werden, einschließlich Provisioning, Skalierung und Patching.
        • dbuser: usedb-Ressourcenberechtigung für mandantenspezifische Benutzer, die auf ihre jeweiligen Datenbankschemas oder -services zugreifen.
        • dbreader: Die Ressourcenberechtigung readdb für Auditoren hat schreibgeschützten Zugriff, um sicherzustellen, dass Datenbankkonfigurationen den Sicherheits-Policys entsprechen.
      • Speicher-Compartment: OCI Object Storage wird zentral verwaltet, mit dedizierten Buckets für jeden Mandanten:
        • osadmin: Ressourcenberechtigung manageobject für die Verwaltung der Shared Object Storage-Ressourcen.
        • osuser: useobject Die mandantenspezifische Speicherressourcenberechtigung (oder t1osur, t2osur, t3osur) stellt sicher, dass Mandanten nur auf ihre jeweiligen Buckets zugreifen.
        • osreader: Die Ressourcenberechtigung readobject für Complianceteams prüft Speicherkonfigurationen und Nutzungsmuster.

Schritt 4: OCI-IAM-Policys für diese Berechtigungstags schreiben

Informationen zum Erstellen von Policys finden Sie in Beispiel 1, Schritt 4. Sie müssen die folgenden Policys erstellen.

Beispiel 3: Große Unternehmens-Compartment-Struktur

Schritt 1: Verschaffen Sie sich ein umfassendes Verständnis des Geschäftsüberblicks des Kunden

CompanyC Solutions, ein multinationales Unternehmen, das sich auf innovative Softwarelösungen spezialisiert hat, entschied sich für die Migration seiner geschäftskritischen Workloads zu OCI. Das Unternehmen ist in stark regulierten Branchen wie Finanzen und Gesundheitswesen tätig, in denen Sicherheit, Compliance und Skalierbarkeit von größter Bedeutung sind.

Schritt 2: Compartment-Struktur für die Workload entwerfen

Sehen wir uns jetzt die Compartment-Struktur für CompanyC an, die dem OCI-IAM-Policy-Modell zur Skalierung ihrer OCI-IAM-Policys folgt.

Anwendungsfall 3

Schritt 3: Entwerfen Sie die folgenden Berechtigungstags des Typs Verb+Resource Kombination

Informationen zum Erstellen von Gruppen finden Sie in Beispiel 1, Schritt 3. Sie müssen Gruppen für alle folgenden Berechtigungstags erstellen.

  1. Root Compartment - Centralized Governance: Die Root-Komponente fungiert als zentrale Schicht für die Überwachung aller Ressourcen und Aktivitäten im gesamten OCI-Mandanten. Hier werden unsere Admin-Gruppen mit Berechtigungs-Tags getaggt. Die folgenden Tags sind:

    • Administratoren: manageall-Berechtigung zur Verwaltung der gesamten Mandantenverwaltung.
    • UseAdministrators: useall-Berechtigung für den mandantenübergreifenden Zugriff auf Ressourcen.
    • Auditor: readall-Berechtigung mit schreibgeschütztem Zugriff auf Ressourcen für die mandantenübergreifende Überwachung.

  2. PROD-Compartment: Das Compartment für das Hosting geschäftskritischer Produktions-Workloads, die sich direkt auf Geschäftsabläufe und Endbenutzer auswirken. Jede Anwendung verfügt über ein dediziertes Sub-Compartment für Ressourcenisolation und optimierte Verwaltung. Lassen Sie uns die Berechtigungstags und die entsprechenden OCI-IAM-Gruppen dafür definieren.

    • NetworkAdmin: managenetwork-Ressourcenberechtigungstag für Ingenieure, die Netzwerkressourcen für CompanyC verwalten.
    • NetworkReader: readnetwork-Ressourcenberechtigungstag für Auditoren, die das Netzwerksetup von CompanyC prüfen.
    • ComputeAdmin: Berechtigungstag für managecompute-Ressourcen für Systemadministratoren, die Compute-Instanzen für CompanyC bereitstellen und skalieren.
    • ComputeReader: Berechtigungstag für readcompute-Ressourcen für Auditoren, die Compute-Ressourcennutzung für CompanyC überwachen.
    • StorageReader: manageobject-Ressourcenberechtigung für Speicheradministratorteams zur Verwaltung von Speicherkonfigurationen.
    • StorageReader: Die Ressourcenberechtigung readobject für Complianceteams prüft Speicherkonfigurationen und Nutzungsmuster.
    • SecurityAdmin: managecspm-Ressourcenberechtigung für Compartment PROD, da sie sich auch auf den Sicherheitsstatus konzentrieren und Sicherheitsrisiken überwachen und beheben können.

    Jetzt werden wir die Berechtigungstags und die entsprechenden OCI-IAM-Gruppen für anwendungsspezifische Sub-Compartments definieren. Im Interesse der Zeit haben wir Berechtigungen für alle 3 verschiedenen Anwendungs-Compartments zusammengeführt und definiert.

    • Anwendungs-Compartments:
      • PRApp1NetAdmin, PRApp2NetAdmin und PRApp3NetAdmin: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag managenetwork-Ressourcen für Ingenieure, die Netzwerkressourcen für App1, App2 bzw. App3 verwalten.
      • PRApp1NetUser, PRApp2NetUser und PRApp3NetUser: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag usenetwork-Ressourcen für Ingenieure, die Netzwerkressourcen für App1, App2 bzw. App3 verwalten.
      • PRApp1ComputeAdmin, PRApp2ComputeAdmin und PRApp3ComputeAdmin: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag für managecompute-Ressourcen für Ingenieure, die OCI Compute-Instanzen für App1, App2 bzw. App3 verwalten.
      • PRApp1ComputeUser, PRApp2ComputeUser und PRApp3ComputeUser: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag für usecompute-Ressourcen für Ingenieure, die OCI Compute-Instanzen für App1, App2 bzw. App3 verwenden.
      • PRApp1StorageAdmin, PRApp2StorageAdmin und PRApp3StorageAdmin: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag manageobject-Ressourcen für Ingenieure, die OCI Object Storage für App1, App2 bzw. App3 verwalten.
      • PRApp1StorageUser, PRApp2StorageUser und PRApp3StorageUser: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag für useobject-Ressourcen für Ingenieure, die OCI Object Storage für App1, App2 bzw. App3 verwenden.

  3. NPROD-Compartment: Für Staging-, Entwicklungs- und Qualitätssicherungsumgebungen dediziert. Dieses Compartment ist ähnlich aufgebaut wie PROD, um Konsistenz zu gewährleisten. Lassen Sie uns die Berechtigungstags und die entsprechenden OCI-IAM-Gruppen dafür definieren.

    • NetworkAdmin: managenetwork-Ressourcenberechtigungstag für Ingenieure, die Netzwerkressourcen für CompanyC verwalten.
    • NetworkReader: readnetwork-Ressourcenberechtigungstag für Auditoren, die das Netzwerksetup von CompanyC prüfen.
    • ComputeAdmin: Berechtigungstag für managecompute-Ressourcen für Systemadministratoren, die OCI Compute-Instanzen für CompanyC bereitstellen und skalieren.
    • ComputeReader: readcompute-Ressourcenberechtigungstag für Auditoren, die die OCI Compute-Ressourcennutzung für CompanyC überwachen.
    • StorageReader: manageobject-Ressourcenberechtigung für Speicheradministratorteams zur Verwaltung von Speicherkonfigurationen.
    • StorageReader: Die Ressourcenberechtigung readStorage für Complianceteams prüft Speicherkonfigurationen und Nutzungsmuster.
    • SecurityAdmin: managecspm-Ressourcenberechtigung für Compartment NPROD, da sie sich auch auf den Sicherheitsstatus konzentrieren und Sicherheitsrisiken überwachen und beheben können.

    Ebenso werden wir jetzt die Berechtigungstags und die entsprechenden OCI-IAM-Gruppen für anwendungsspezifische Sub-Compartments definieren.

    • Anwendungs-Compartments:
      • NPApp1NetAdmin, NPApp2NetAdmin und NPApp3NetAdmin: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag managenetwork-Ressourcen für Ingenieure, die Netzwerkressourcen für App1, App2 bzw. App3 verwalten.
      • NPApp1NetUser, NPApp2NetUser und NPApp3NetUser: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag usenetwork-Ressourcen für Ingenieure, die Netzwerkressourcen für App1, App2 bzw. App3 verwalten.
      • NPApp1ComputeAdmin, NPApp2ComputeAdmin und NPApp3ComputeAdmin: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag für managecompute-Ressourcen für Ingenieure, die OCI Compute-Instanzen für App1, App2 bzw. App3 verwalten.
      • NPApp1ComputeUser, NPApp2ComputeUser und NPApp3ComputeUser: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag für usecompute-Ressourcen für Ingenieure, die OCI Compute-Instanzen für App1, App2 bzw. App3 verwenden.
      • NPApp1StorageAdmin, NPApp2StorageAdmin und NPApp3StorageAdmin: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag manageobject-Ressourcen für Ingenieure, die OCI Object Storage für App1, App2 bzw. App3 verwalten.
      • NPApp1StorageUser, NPApp2StorageUser und NPApp3StorageUser: Admin-OCI-IAM-Gruppen mit dem Berechtigungstag für useobject-Ressourcen für Ingenieure, die OCI Object Storage für App1, App2 bzw. App3 verwenden.

  4. Gemeinsames Compartment: Das gemeinsam verwendete Compartment hostet Ressourcen für das Monitoring, wie Logging und Cloud Guard-OCI-Services. Es verfügt auch über Schlüssel für die Verschlüsselung und Entschlüsselung, die von mehreren Mandanten verwendet werden, während gleichzeitig eine logische Trennung zur Wahrung der Privatsphäre und Sicherheit gewährleistet wird. Alle Admins aus Ihren Anwendungen, die Zugriff auf diese Services benötigen, werden den erstellten OCI-IAM-Gruppen für diese Services hinzugefügt. Definieren Sie die Berechtigungstags und die entsprechenden OCI-IAM-Gruppen dafür.

    • Oracle Cloud Guard-Compartments:

      • cspmAdmin: Admin-OCI-IAM-Gruppen mit Berechtigungstag für managecspm-Ressourcen für Administratoren, die Oracle Cloud Guard für PROD- und Non PROD-Compartments verwalten.
      • cspmUser: OCI-IAM-Gruppen mit dem Berechtigungstag für usecspm-Ressourcen für Ingenieure, die Oracle Cloud Guard für PROD- und Non PROD-Compartments verwenden/überwachen.
      • cspmReader: OCI-IAM-Gruppen mit Berechtigungstag für readcspm-Ressourcen für Ingenieure, die Oracle Cloud Guard für PROD- und Non PROD-Compartments lesen.

    • OCI Logging-Compartments:

      • logsAdmin: Admin-OCI-IAM-Gruppen mit Berechtigungstag für managelogs-Ressourcen für Administratoren, die OCI Logging für PROD- und Nicht PROD-Compartments verwalten.
      • logsUser: OCI-IAM-Gruppen mit dem Berechtigungstag für uselogs-Ressourcen für Ingenieure, die OCI Logging für PROD- und Non PROD-Compartments verwenden/überwachen.
      • logsReader: OCI-IAM-Gruppen mit readlogs-Ressourcenberechtigungstag für Ingenieure, die OCI Logging für PROD- und Non PROD-Compartments lesen.

    • Schlüssel-Compartments:

      • kmsAdmin: Admin-OCI-IAM-Gruppen mit managekeys-Ressourcenberechtigungstag für Administratoren, die den Key Vault für PROD- und Non PROD-Compartments verwalten.
      • kmsUser: OCI-IAM-Gruppen mit dem Berechtigungstag für usekeys-Ressourcen für Ingenieure, die den Key Vault für PROD- und Non PROD-Compartments verwenden/überwachen.
      • kmsReader: OCI-IAM-Gruppen mit dem Berechtigungstag für readkeys-Ressourcen für Ingenieure, die den Key Vault für PROD- und Nicht PROD-Compartments lesen.

  5. Playground-Compartment: Eine flexible und isolierte Umgebung für Experimente, Entwicklung und Tests. Dieses Compartment ist nicht an Produktions- oder Compliance-Einschränkungen gebunden und daher ideal für Innovationen. Hier gibt es nur eine OCI-IAM-Admin-Gruppe für ein sehr untergeordnetes Compartment und erteilt allen OCI-Ressourcen, die für Testanforderungen erforderlich sind, die Verwaltungsberechtigungen.

    • Entwicklungs-Compartments:

      • DevAdmin: Admin-OCI-IAM-Gruppen mit der Ressourcenberechtigung managenetwork, managecompute, manageobject, managekeys, managelogs für Entwicklungsadministratoren zum Testen einer neuen Implementierung innerhalb des Entwicklungs-Compartments.

    • Test-Compartments:

      • TestAdmin: Admin-OCI-IAM-Gruppen mit der Ressourcenberechtigung managenetwork, managecompute, manageobject, managekeys, managelogs für Entwicklungsadministratoren zum Testen einer neuen Implementierung innerhalb des Test-Compartments.

    • Compartments für Performancetests:

      • PerfTestAdmin: Admin-OCI-IAM-Gruppen mit der Ressourcenberechtigung managenetwork, managecompute, manageobject, managekeys, managelogs für Entwicklungsadministratoren zum Testen einer neuen Implementierung innerhalb des Performancetest-Compartments.

Schritt 4: OCI-IAM-Policys für diese Berechtigungstags schreiben

Informationen zum Erstellen von Policys finden Sie in Beispiel 1, Schritt 4. Sie müssen die folgenden Policys erstellen.

Hinweis: Bei jedem Onboarding neuer Arbeitslasten für ein solches Szenario gilt Folgendes:

Tagbasiertes Berechtigungsmodell für granulare Zugriffskontrolle

In allen Beispielen haben wir bisher die Berechtigungen zum Erstellen von Verwaltungs-, Benutzer- oder Leseberechtigungen für eine Ressourcenfamilie besprochen. Die meisten Kunden benötigen jedoch eine granulare Zugriffskontrolle, um dem Modell mit den geringsten Berechtigungen zu folgen. Das Tutorial konzentriert sich auf das Verständnis des Policy-Modells, weshalb wir über einen einfachen Anwendungsfall gesprochen haben. Lassen Sie mich jedoch ein Beispiel für vier Netzwerkpersonen nehmen, und wie Sie granulare Berechtigungstags und OCI-IAM-Policys für diese vier Personas entwerfen können.

Wir definieren networkowner, networkadmin, networkoperator und networkuser als vier Tags im Netzwerk-Compartment. Für diese Tags weisen wir Gruppennamen zu, die Zugriff auf das Netzwerk-Compartment haben.

OCI-IAM-Policys für Instanz-Principals skalieren

Beispiel 1: Multi-Tenant-Instanzzugriffskontrolle für Shared Storage und Secrets in OCI

Schritt 1: Verschaffen Sie sich ein umfassendes Verständnis des Geschäftsüberblicks des Kunden

XYZ Cloud Solutions ist ein SaaS-Provider, der ein auf OCI gehostetes Dokumentenmanagementsystem (DMS) anbietet. Die Plattform bedient mehrere Unternehmenskunden, die jeweils eine strenge Isolierung ihrer Daten bei gleichzeitiger Nutzung einer gemeinsamen Infrastruktur erfordern.

Kundenanforderungen:

Schritt 2: Compartment-Struktur für die Workload entwerfen

Sehen wir uns jetzt die Compartment-Struktur für XYZ Cloud-Lösungen an, die dem OCI IAM-Policy-Modell zur Skalierung ihrer OCI IAM-Policys folgt.

Instanz-Anwendungsfall 1

Schritt 3: OCI-IAM-Gruppen erstellen

Um eine sichere und isolierte Zugriffsverwaltung in einer OCI-Mehrmandantenumgebung sicherzustellen, werden die folgenden Policys definiert für:

Hinweis: Diese Gruppen und OCI-IAM-Policys wurden bereits wie oben im Abschnitt Allgemeine OCI-IAM-Policys beschrieben erstellt.

Schritt 4: OCI-IAM-Policys für die definierten Gruppen erstellen

Mandantenressourcenzugriffs-Policys: Um die Datenisolierung aufrechtzuerhalten, sollten Mandantenressourcen nur auf ihre eigenen Secrets und den Objektspeicher zugreifen können.

Allow any-user to use object-family in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant
Allow any-user to use secret-family in compartment Tenants where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant

Wenn für die Mandanteninstanzprinzipien auch die Berechtigung zum Erstellen neuer Objekte erforderlich ist, können Sie Bucket-Namen mit demselben Namen wie der Mandantenname erstellen und das Mandantennamentag für den Vergleich mit dem Bucket-Namen verwenden.

Allow any-user to manage objects in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.bucket.name

Beispiel 2: Fein granulierte Zugriffskontrolle für den Multi-Service-Datenzugriff in einem gemeinsamen OCI-Speichermodell

Schritt 1: Verschaffen Sie sich ein umfassendes Verständnis des Geschäftsüberblicks des Kunden

XYZ Corp ist ein schnell wachsendes Unternehmen, das sich auf Lösungen für die digitale Transformation spezialisiert hat. Mit einer globalen Präsenz ist XYZ Corp in mehreren Regionen tätig und nutzt OCI für das Hosting kritischer Anwendungen, die Verwaltung von Daten und die Gewährleistung einer nahtlosen Zusammenarbeit zwischen Teams.

Kundenanforderungen:

Schritt 2: Compartment-Struktur für die Workload entwerfen

Sehen wir uns jetzt die Compartment-Struktur für XYZ Corp an, die dem OCI IAM-Policy-Modell zur Skalierung ihrer OCI IAM-Policys folgt.

Instanz-Anwendungsfall 2

Schritt 3: OCI-IAM-Gruppen erstellen

Um eine sichere und isolierte Zugriffsverwaltung in einer OCI-Mehrmandantenumgebung sicherzustellen, werden die folgenden Policys definiert für:

Hinweis: InfoSec und Terraform-Runner-Gruppen und IAM-Policys wurden bereits wie oben im Abschnitt Allgemeine OCI-IAM-Policys beschrieben erstellt.

Schritt 4: OCI-IAM-Policys für die definierten Gruppen erstellen

Mandantenressourcenzugriffs-Policys: Um die Datenisolierung aufrechtzuerhalten, sollten Mandantenressourcen nur auf ihre eigenen Secrets und den Objektspeicher zugreifen können.

Allow dynamic-group AdminInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}

Allow dynamic-group SalesInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}

Allow dynamic-group SupplyInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}

Allow any-user to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Shared’}

Allow dynamic-group AdminInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}

Allow dynamic-group SalesInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}

Allow dynamic-group SupplyInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}

Danksagungen

Weitere Lernressourcen

Sehen Sie sich andere Übungen zu docs.oracle.com/learn an, oder greifen Sie im Oracle Learning YouTube-Channel auf weitere kostenlose Lerninhalte zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.