Mandantenübergreifend mit einer IAM-Integration auf eine Datenbank zugreifen
Benutzer und Gruppen in einem Mandanten können auf autonome KI-Datenbankinstanzen in einem anderen Mandanten zugreifen, wenn Policys in beiden Mandanten dies zulassen.
Mandantenübergreifender Zugriff für IAM-Benutzer auf DBaaS-Instanzen
Der mandantenübergreifende Zugriff auf eine Oracle Cloud Infrastructure-(OCI-)DBaaS-Instanz ähnelt einem einzelnen Mandantenszenario, mit der Ausnahme, dass Mandanteninformationen für Mappings und Tokenanforderungen erforderlich sind und eine Policy in beiden Mandanten erforderlich ist, um diesen mandantenübergreifenden Datenbankressourcenzugriff zu ermöglichen.
Die folgende Abbildung veranschaulicht den Prozess für einen mandantenübergreifenden Zugriff auf eine OCI DBaaS-Instanz.

Beschreibung der Abbildung db_cross_tenancy.png
Der mandantenübergreifende Prozess lautet wie folgt:
-
Die Policy ist in beiden Mandanten erforderlich, um den mandantenübergreifenden Zugriff zu genehmigen und zuzulassen.
-
Der IAM-Principal (Benutzer oder Anwendung) fordert ein DB-Token für eine mandantenübergreifende Ressource an.
-
Die
db-tokenwird zurückgegeben und für den Zugriff auf die Datenbank in einem anderen Mandanten verwendet -
Die Datenbank führt eine mandantenübergreifende Gruppenabfrage für die Benutzergruppen durch und ordnet den Principal dem globalen Schema und optionalen globalen Rollen zu.
Sie müssen den Benutzermandanten für dieselben Regionen abonnieren, in denen sich die Datenbanken befinden. Beispiel: Wenn sich die Datenbanken im Datenbankmandanten in den Regionen PHX und IAD befinden, müssen Sie den Benutzermandanten für diese Regionen abonnieren. Dies ist nicht die Hauptregion, sondern nur die zusätzlichen abonnierten Regionen im Benutzermandanten.
Policys Konfigurieren
Sie müssen Policys sowohl im Benutzermandanten als auch im Datenbankressourcenmandanten erstellen, um mandantenübergreifenden Datenbankzugriff zu ermöglichen.
Quellbenutzermandanten konfigurieren
Zwei Policys sind erforderlich, um mandantenübergreifenden Zugriff im Benutzermandanten zu ermöglichen.
Die erste Policy besteht darin, dass eine Benutzermandantengruppe auf eine Datenbank in einem anderen Mandanten zugreifen kann. Mit der zweiten Policy kann eine Datenbank im Datenbankmandanten Gruppeninformationen im Benutzermandanten abfragen.
-
Wählen Sie in der OCI-Konsole Identität und Sicherheit aus.
-
Wählen Sie unter Identität die Option Policys aus.
-
Klicken Sie auf Policy erstellen, und wählen Sie im Policy Builder Manuellen Editor anzeigen aus.
-
Verwenden Sie die
DEFINE-Anweisung, um das Lesen der tatsächlichen Policys zu erleichtern.Beispiel:
DEFINE tenancy database_tenancy as ocid1.tenancy.OCID -
Bestätigen Sie die Mandantengruppe
domainA/xt_db_users, um database_connections im Mandantendatabase_tenancyzu verwenden.Dadurch können Benutzer der Gruppe
xt_db_usersindomainAauf jede Datenbank im Mandantendatabase_tenancyzugreifen.ENDORSE group domainA/xt_db_users to use database-connections in tenancy database_tenancy -
Mit der
ADMIT-Anweisung können Sie eine Admit-Policy erstellen, damit jede Datenbank im Datenbankmandanten Gruppeninformationen für bestimmte IAM-Benutzer im Benutzermandanten abfragen kann.ADMIT any-user of tenancy database_tenancy to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy
Ressourcenmandanten der Zieldatenbank konfigurieren
Der Datenbankmandant benötigt Übereinstimmungs-Policys, um den Zugriff auf die Benutzer aus dem Benutzermandanten zu ermöglichen. Außerdem müssen seine eigenen Datenbanken Gruppeninformationen im Benutzermandanten abfragen können
-
Wählen Sie in der OCI-Konsole Identität und Sicherheit aus.
-
Wählen Sie unter Identität die Option Policys aus.
-
Klicken Sie auf Policy erstellen, und wählen Sie im Policy Builder Manuellen Editor anzeigen aus.
-
Verwenden Sie
DEFINE, um die Fehlerbehebung und das Lesen der Policys zu erleichtern.DEFINE tenancy user_tenancy as ocid1.tenancy.OCID DEFINE group xt_db_users as ocid1.group.defg -
Verwenden Sie
ADMIT, um eine Admit-Policy im Mandanten zu erstellen, die mit der Endorse-Policy aus dem Benutzermandanten übereinstimmt.Die Admit-Policy muss mit der Policy
ENDORSEim Benutzermandanten übereinstimmen, damit Benutzer aus deruser_tenancyauf Datenbanken in diesem Mandanten zugreifen können.ADMIT group xt_db_users of tenancy user_tenancy to use database-connections in tenancy -
Erstellen Sie eine Freigabe-Policy, die mit der im Benutzermandanten erstellten Zulassungs-Policy übereinstimmt.
Mit der Freigabe-Policy können Datenbanken im Datenbankmandanten Gruppeninformationen aus der user_tenancy abfragen.
ENDORSE any-user to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy user_tenancy
Wenn Sie any-user verwenden, können Sie die erforderlichen Policys leicht verstehen. Oracle empfiehlt jedoch, neben oder anstelle von any-user stärkere Constraints zu verwenden. Mit der Option any-user kann jeder Principal oder jede Ressource Benutzergruppen in der user_tenancy abfragen. Im Idealfall sollten Sie dies darauf beschränken, dass nur die Datenbankressourcen (Resource Principals) die Gruppenabfragen erstellen können. Dazu können Sie den Policys eine WHERE-Klausel hinzufügen oder eine dynamische Gruppe hinzufügen, die sie auf die Mitglieder der dynamischen Gruppe beschränkt. Die Definition jeder möglichen Methode zur Angabe dynamischer Gruppen und Policys liegt außerhalb des Geltungsbereichs dieses Themas. Weitere Informationen finden Sie aus diesen Quellen:
Policy-Beispiele für mandantenübergreifenden Zugriff
Beispiele hierfür sind die Verwendung einer WHERE-Klausel zur Verfeinerung der mandantenübergreifenden Konfiguration und andere Methoden zur Ausführung dieses Konfigurationstyps.
Sie können eine WHERE-Klausel hinzufügen, um die Datenbankressourcen einzuschränken, die für die mandantenübergreifende Gruppenabfrage zulässig sind:
ADMIT any-user of tenancy db_tenancy to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy where request.principal.type = 'dbsystem'Mit dieser Admit-Policy kann jeder Base Database Service (Ressourcentyp: dbsystem) in der db_tenancy die Gruppeninformationen eines Benutzers aus dem Benutzermandanten abfragen. Die Ressourcentypnamen sind in der folgenden Tabelle aufgeführt.
Eine ähnliche Methode zum Erstellen einer Policy besteht darin, den Ressourcentyp für autonome KI-Datenbank einer dynamischen Gruppe hinzuzufügen:
dynamic group: db_principals any {resource.type = 'autonomousdatabase'}In diesem Beispiel wird eine dynamische Gruppe anstelle von any-user verwendet:
ADMIT dynamic group db_principals of tenancy db_tenancy to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancySie können auch alle Resource Principals mit resource.compartment.id in einem Compartment hinzufügen. Dadurch können jedoch auch andere Nicht-Datenbank-Resource Principals die mandantenübergreifende Gruppenabfrage ausführen.
Datenbankschemas und -rollen Benutzern und Gruppen in einem anderen Mandanten zuordnen
Wenn Sie diesen Zuordnungstyp ausführen, müssen Sie die Mandanten-OCID zu den Zuordnungsinformationen hinzufügen, damit die Datenbank weiß, dass es sich um mandantenübergreifenden Zugriff handelt.
Trennen Sie die Mandanten-OCID mit einem vollständigen Doppelpunkt, wenn Sie die Anweisungen CREATE USER und CREATE ROLE in SQL*Plus verwenden.
-
So führen Sie die Zuordnung mit der Anweisung
CREATE USERaus:Die folgenden Beispiele zeigen die exklusive und gemeinsame Schemazuordnung mit Principals und Gruppen in Standard- und Nicht-Standarddomains. Wenn Sie Standarddomains verwenden, müssen Sie keinen Domainnamen angeben.
CREATE USER schema1 IDENTIFIED GLOBALLY AS 'IAM_PRINCIPAL_NAME=ocid1.tenancy.OCID:example_domain/peter.fitch@oracle.com'; CREATE USER schema2 IDENTIFIED GLOBALLY AS 'IAM_PRINCIPAL_NAME=ocid1.tenancy.OCID:peter.fitch@oracle.com'; CREATE USER qa_db_user_group IDENTIFIED GLOBALLY AS 'IAM_GROUP_NAME=ocid1.tenancy.OCID:example_domain/xt_db_users'; CREATE USER qa_sales_user_group IDENTIFIED GLOBALLY AS 'IAM_GROUP_NAME=ocid1.tenancy.OCID:sales_users'; CREATE USER xt_ip_user IDENTIFIED GLOBALLY AS 'IAM_PRINCIPAL_OCID=ocid1.instance.region1.sea.OCID'; GRANT CREATE SESSION TO xt_ip_user; CREATE USER xt_iam_dg IDENTIFIED GLOBALLY AS 'IAM_GROUP_NAME=ocid1.tenancy.region1.OCID:sales_principals'; GRANT CREATE SESSION TO xt_iam_dg; -
So führen Sie die Zuordnung mit der Anweisung
CREATE ROLEaus:Die folgenden Beispiele zeigen die globale Rollenzuordnung mit Gruppen in Standard- und Nicht-Standarddomains. Wenn Sie Standarddomains verwenden, müssen Sie keinen Domainnamen angeben.
CREATE ROLE globalrole1 IDENTIFIED GLOBALLY AS 'IAM_GROUP_NAME=ocid1.tenancy.abcdef:example_domain/xt_db_users'; CREATE ROLE globalrole2 IDENTIFIED GLOBALLY AS 'IAM_GROUP_NAME=ocid1.tenancy.abcdef:sales_users';
Datenbankclients für mandantenübergreifenden Zugriff konfigurieren
Sie können einige Datenbankclients direkt konfigurieren.
Der Datenbankmandant muss in der Verbindungszeichenfolge oder in sqlnet.ora identifiziert werden, wenn der Client so konfiguriert ist, dass das Zugriffstoken direkt aus OCI IAM abgerufen wird. Überprüfen Sie die clientspezifische Dokumentation auf bestimmte Parameterwerte (JDBC-thin, ODP.NET-core, managed).
Mandantenübergreifende Token mit der OCI-Befehlszeilenschnittstelle anfordern
Sie müssen den Parameter --scope zum Befehlszeilenschnittstellenbefehl von Oracle Cloud Infrastructure (OCI) hinzufügen, um eine db-token für eine mandantenübergreifende Anforderung abzurufen. Wenn sich die Datenbank, auf die Sie zugreifen, in einer anderen Region als die Hauptregion des Benutzermandanten befindet, muss die Region auch mit dem Parameter "-region" zum OCI-CLI-Befehl hinzugefügt werden.
Weitere Informationen zur Verwendung der optionalen Parameter des Befehls oci get finden Sie unter Optionale Parameter.
Sie können den Geltungsbereich für den gesamten Mandanten festlegen oder ihn auf ein Compartment oder eine Datenbank im Mandanten begrenzen. Beim Scoping für mandantenübergreifende Compartments oder Datenbanken müssen Sie nicht auch die Mandanteninformationen hinzufügen, da die Compartment- und Datenbank-OCIDs in OCI eindeutig sind.
Bestimmte Clients können die Token direkt von MSEI anfordern. Informationen zum Festlegen der Parameter zum Abrufen der MSEI-Zugriffstoken OAuth2 finden Sie in der entsprechenden Dokumentation.