Documentazione dell'infrastruttura Oracle Cloud

Accesso a un database cross-tenancy mediante un'integrazione IAM

Gli utenti e i gruppi in una tenancy possono accedere alle istanze di database DBaaS in un'altra tenancy se i criteri presenti in entrambe le tenancy lo consentono.

Argomento padre: Utilizzare l'autenticazione IAM (Identity and Access Management) con Autonomous Database

Informazioni sull'accesso cross-tenancy per gli utenti IAM alle istanze DBaaS

L'accesso cross-tenancy a un'istanza DBaaS di Oracle Cloud Infrastructure (OCI) è simile a un singolo scenario di tenancy, ad eccezione del fatto che le informazioni sulla tenancy sono necessarie per i mapping e le richieste di token e che in entrambe le tenancy è necessario un criterio per consentire l'accesso a questa risorsa del database cross-tenancy.

La figura seguente illustra il processo di accesso cross-tenancy a un'istanza DBaaS OCI.

Figura 3-1 Accesso cross-tenancy a un'istanza DBaaS OCI

Segue la descrizione della Figura 3-1
Descrizione della "Figura 3-1 Accesso cross-tenancy a un'istanza OCI DBaaS"

Il processo cross-tenancy è il seguente:

  1. Il criterio è necessario in entrambe le tenancy per approvare e ammettere l'accesso tra più tenancy.
  2. Il principal IAM (utente o applicazione) richiede un db-token per una risorsa cross-tenancy.
  3. Il valore db-token viene restituito e utilizzato per accedere al database in una tenancy diversa
  4. Il database eseguirà una query tra gruppi di tenancy per i gruppi dell'utente e mapperà il principal allo schema globale e ai ruoli globali facoltativi.

È necessario eseguire la sottoscrizione della tenancy utente alle stesse aree in cui si trovano i database. Ad esempio, se i database nella tenancy del database si trovano nelle aree PHX e IAD, è necessario sottoscrivere la tenancy utente a queste aree. Questa non è l'area di origine, ma solo le aree aggiuntive sottoscritte nella tenancy dell'utente.

Configurazione dei criteri

È necessario creare criteri sia nella tenancy utente che nella tenancy delle risorse del database per consentire l'accesso al database cross-tenancy.

Argomento padre: Accesso a un database cross-tenancy mediante un'integrazione IAM

Configurazione della tenancy dell'utente di origine

Sono necessari due criteri per consentire l'accesso cross-tenancy nella tenancy dell'utente.

Il primo criterio consiste nel consentire a un gruppo di tenancy utente di accedere a un database in una tenancy diversa. Il secondo criterio consente a un database nella tenancy del database di eseguire query sulle informazioni dei gruppi nella tenancy utente.
  1. Nella console OCI selezionare Identità e sicurezza.
  2. In Identità selezionare Criteri.
  3. Fare clic su Crea criterio e in Costruzione guidata criteri selezionare Mostra editor manuale.
  4. Utilizzare l'istruzione DEFINE per semplificare la lettura dei criteri effettivi.
    Ad esempio:
    DEFINE tenancy database_tenancy as ocid1.tenancy.OCID
  5. Girare il gruppo di tenancy domainA/xt_db_users per utilizzare database_connections nella tenancy database_tenancy.
    Ciò consente agli utenti del gruppo xt_db_users in domainA di accedere a qualsiasi database nella tenancy database_tenancy.
    ENDORSE group domainA/xt_db_users to use database-connections in tenancy database_tenancy
  6. Utilizzare l'istruzione ADMIT per creare un criterio di ammissione per consentire a qualsiasi database nella tenancy del database di eseguire query sulle informazioni dei gruppi per utenti IAM specifici nella tenancy utente.
    ADMIT any-user of tenancy database_tenancy to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy

Argomento padre: Configurazione dei criteri

Configurazione della tenancy delle risorse del database di destinazione

La tenancy del database avrà bisogno di criteri di corrispondenza per abilitare l'accesso agli utenti dalla tenancy utente e consentire ai propri database di eseguire query sulle informazioni dei gruppi nella tenancy utente

  1. Nella console OCI selezionare Identità e sicurezza.
  2. In Identità selezionare Criteri.
  3. Fare clic su Crea criterio e in Costruzione guidata criteri selezionare Mostra editor manuale.
  4. Utilizzare DEFINE per semplificare la risoluzione dei problemi e la lettura dei criteri.
    DEFINE tenancy user_tenancy as ocid1.tenancy.OCID
DEFINE group xt_db_users as ocid1.group.defg
  5. Usare ADMIT per creare un criterio di ammissione nella tenancy in modo che corrisponda al criterio di approvazione dalla tenancy utente.
    Il criterio di ammissione deve corrispondere al criterio ENDORSE nella tenancy utente in modo che possa consentire agli utenti di user_tenancy di accedere ai database in questa tenancy.
    ADMIT group xt_db_users of tenancy user_tenancy to use database-connections in tenancy
  6. Crea un criterio di approvazione, che corrisponderà al criterio di ammissione creato nella tenancy utente.
    Il criterio Endorse consentirà ai database nella tenancy del database di eseguire query sulle informazioni dei gruppi da user_tenancy.
    ENDORSE any-user to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy user_tenancy
Sebbene l'uso di any-user semplifichi la comprensione dei criteri richiesti, Oracle consiglia di utilizzare vincoli più rigidi in aggiunta o in luogo dell'uso di any-user. L'opzione any-user consentirà a qualsiasi principal o risorsa di eseguire query sui gruppi di utenti nel file user_tenancy. Idealmente, dovresti limitarlo a consentire solo alle risorse di database (principali risorse) di eseguire le query di gruppo. È possibile eseguire questa operazione aggiungendo una clausola WHERE ai criteri o aggiungendo un gruppo dinamico che la limiti ai membri del gruppo dinamico. La definizione di tutti i modi possibili per specificare i gruppi dinamici e i criteri non rientra nell'ambito di questo argomento. Puoi trovare ulteriori informazioni da queste fonti:

Argomento padre: Configurazione dei criteri

Esempi di criteri per l'accesso cross-tenancy

Gli esempi includono l'uso di una clausola WHERE per perfezionare la configurazione cross-tenancy e altri metodi per eseguire questo tipo di configurazione.

È possibile aggiungere una clausola WHERE per limitare le risorse di database consentite per eseguire la query del gruppo cross-tenancy: 

ADMIT any-user of tenancy db_tenancy to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy where request.principal.type = 'dbsystem'

Questo criterio di ammissione consente a qualsiasi servizio Base Database (tipo di risorsa: dbsystem) nel file db_tenancy di eseguire una query sulle informazioni di gruppo di un utente dalla tenancy utente. I nomi dei tipi di risorsa si trovano nella tabella riportata di seguito.

Un metodo simile può essere fatto mettendo lo stesso tipo di risorsa in un gruppo dinamico:

dynamic group: db_principals
any {resource.type = 'dbsystem', resource.type = 'vmcluster', resource.type = 'cloudvmcluster'}

Il gruppo dinamico nell'esempio precedente include istanze di database per Oracle Base Database Service (dbsystem), Oracle Exadata Cloud@Customer (vmcluster) e Oracle Exadata Database Service (cloudvmcluster).

In questo esempio viene utilizzato un gruppo dinamico anziché any-user: 

ADMIT dynamic group db_principals of tenancy db_tenancy to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy

È anche possibile aggiungere tutte le principal risorsa in un compartimento utilizzando resource.compartment.id. Tuttavia, ciò potrebbe consentire anche ad altri principal di risorse non del database di eseguire la query del gruppo di tenancy incrociata. La tabella seguente fornisce un mapping dei vari tipi di risorse con il nome della piattaforma DBaaS:

Nome piattaforma DBaaS Nome tipo di risorsa

ADB-S

autonomousdatabase

ADB-D (OPC)

cloudautonomousvmcluster*

DBS base

dbsystem

ExaCS

cloudvmcluster

ExaCC

vmcluster

* Le istanze ADBD precedenti potrebbero ancora utilizzare il tipo di risorsa autonomousexainfrastructure.

Argomento padre: Configurazione dei criteri

Mapping degli schemi e dei ruoli del database agli utenti e ai gruppi in un'altra tenancy

Quando si esegue questo tipo di mapping, è necessario aggiungere l'OCID tenancy alle informazioni di mapping in modo che il database riconosca che si tratta dell'accesso cross-tenancy.

Utilizzare i due punti per separare l'OCID della tenancy quando si utilizzano le istruzioni CREATE USER e CREATE ROLE in SQL*Plus.
  • Per utilizzare l'istruzione CREATE USER per eseguire il mapping, procedere come segue.
    Gli esempi riportati di seguito mostrano il mapping di schemi esclusivi e condivisi con principal e gruppi nei domini predefiniti e non predefiniti. Quando si utilizzano i domini predefiniti, non è necessario includere un nome di dominio.
    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;
  • Per utilizzare l'istruzione CREATE ROLE per eseguire il mapping, procedere come segue.
    Gli esempi riportati di seguito mostrano il mapping dei ruoli globali con i gruppi nei domini predefiniti e non predefiniti. Quando si utilizzano i domini predefiniti, non è necessario includere un nome di dominio. 
    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';

Configurazione dei client del database per l'accesso cross-tenancy

È possibile configurare direttamente alcuni client di database.

La tenancy del database deve essere identificata nella stringa di connessione o in sqlnet.ora se il client è configurato per ottenere direttamente il token di accesso da IAM OCI. Rivedere la documentazione specifica del client per valori di parametri specifici (JDBC-thin, ODP.NET-core, gestito).

Richiesta di token cross-tenancy mediante l'interfaccia della riga di comando OCI

È necessario aggiungere il parametro --scope al comando dell'interfaccia della riga di comando di Oracle Cloud Infrastructure (OCI) per ottenere un valore db-token per una richiesta cross-tenancy. Se il database a cui si sta accedendo si trova in un'area diversa da quella della home region della tenancy utente, è necessario aggiungere anche l'area al comando CLI OCI utilizzando il parametro --region.

Per ulteriori informazioni sull'uso dei parametri facoltativi del comando oci get, vedere Parametri opzionali.

Puoi applicarlo all'intera tenancy o includerlo nell'ambito di un compartimento o di un database nella tenancy. Quando si applica l'ambito per il compartimento o il database tra tenancy, non è necessario aggiungere anche le informazioni sulla tenancy perché gli OCID del compartimento e del database sono univoci in OCI.

Alcuni clienti possono richiedere i token direttamente da MSEI. Fare riferimento alla documentazione relativa all'impostazione dei parametri per ottenere i token di accesso MSEI OAuth2.