Caso di studio illustrativo dell'organizzazione con sede nell'UE

Mentre i dettagli delle varie funzionalità sono informativi, è utile illustrare l'implementazione degli ambienti con esempi. Negli esempi seguenti, introduciamo il concetto di utente sub-SC.

Un utente SC secondario ha le seguenti caratteristiche:

• Direttamente correlato all'entità cliente per organizzazione o trattato e ha una relazione governativa o commerciale con l'entità cliente.
• Contenuto completamente all'interno dell'UE ed è soggetto almeno agli stessi requisiti di protezione e sovranità dei dati dell'entità cliente stessa.
• Non sono semplicemente gruppi organizzativi all'interno del cliente stesso, ma sono entità a sé stanti. Potrebbe trattarsi di una divisione governativa o di una controllata di un'entità aziendale commerciale. Potrebbero avere un superset di requisiti relativi alla protezione e alla classificazione dei dati, ma non possono scendere al di sotto dei requisiti minimi dell'entità cliente stessa. Ad esempio, se un cliente di esempio ha mantenuto un set di compartimenti e risorse per se stesso, ma ha fornito agli utenti del sotto-SC l'accesso, il cliente manterrebbe il controllo sulle risorse distribuite dall'utente del sotto-SC in conformità con il particolare quadro legale dell'utente del sotto-SC.

Questo case study utilizza una situazione ipotetica in cui il cliente desidera fornire un set di servizi cloud a un set di organizzazioni controllate o utenti SC secondari, inclusa la possibilità per tali utenti SC secondari di ospitare i propri servizi che interagiscono con i servizi globali forniti dal cliente stesso. Il cliente controllerebbe la tenancy in termini di costi, assegnazione dei compartimenti all'interno della tenancy complessiva e creazione di gruppi globali per la gestione della tenancy. Tuttavia, ogni sotto-SC avrebbe il proprio ambiente definito dagli spazi del compartimento di cui è "proprio" e completamente controllato dalla propria base utenti e che fornisce tramite un dominio di Identity. All'interno dei compartimenti figlio o "radice" di ogni sotto-SC, è possibile creare compartimenti aggiuntivi e distribuire risorse.

I compartimenti SC secondari saranno esclusivi di ogni utente SC secondario, senza che altri utenti SC secondari abbiano visibilità sulla struttura, sulle risorse o sulle attività del compartimento di altri utenti SC secondari. I log di audit e altre attività di audit e conformità vengono eseguiti a livello di cliente, ma sono resi visibili per ogni dominio di Identity, filtrati in base al singolo compartimento "radice" e limitati in base all'appartenenza all'identità per garantire la visibilità. Ciò consentirebbe sia al cliente che al singolo utente del sub-SC di verificare in modo indipendente costi, conformità e rilevamento delle minacce. Le risorse create sarebbero a discrezione sia del cliente (per i propri compartimenti) che di ogni utente sub-SC e potrebbero essere limitate dalle funzioni Quote e budget del compartimento OCI nel cloud sovrano dell'UE.

Modello di sicurezza di esempio

Il modello di sicurezza per questo esempio è illustrato nel diagramma seguente:

Descrizione dell'immagine iam-security-model.png

iam-security-model-oracle.zip

Qui, il cliente stabilisce una tenancy e crea sia un set di compartimenti per uso personale (i compartimenti "Divisione") che un set di compartimenti base da utilizzare da ciascun membro sub-SC. Quando ogni utente SC secondario si registra per utilizzare le risorse all'interno della tenancy, viene creato un dominio di Identity attorno al compartimento di livello superiore specifico creato per l'utente SC secondario. L'utente SC secondario potrebbe quindi federare la propria base di utenti al proprio dominio di Identity individuale e allocare le autorizzazioni indipendentemente da quelle allocate dal cliente. Questi domini potrebbero operare come entità quasi indipendenti, con relazioni definite sulla base di un accordo congiunto.

Caso d'uso protezione dati

L'utente sub-SC avrebbe diverse opzioni non esclusive per avviare la protezione dei dati utilizzando EU Sovereign Cloud. In primo luogo sarebbe semplicemente quello di utilizzare il modello di protezione dei dati esistente illustrato sopra. Il dominio di Identity sub-SC è temporaneo nell'intera tenancy; in altre parole, poiché il dominio di Identity è una risorsa a livello di tenancy, le opzioni di accesso sono disponibili in entrambe le aree in base ai criteri stabiliti per l'intera tenancy.

Anche i compartimenti seguono questo modello. Ciò consente a ogni utente sub-SC di eseguire la replica dei dati utilizzando le singole risorse create all'interno dei propri compartimenti, in due aree dati, per fungere da destinazioni o origini di replica. Ciò consente l'utilizzo di modelli attivi/attivi e attivi/passivi di protezione dei dati, a seconda della capacità delle singole applicazioni implementate dal sub-SC e della tolleranza RTO/RPO di quelle che non possono funzionare in attivo/attivo. La protezione dei dati sarebbe indipendente e isolata dal punto di vista di altri utenti sub-SC. Il cliente può osservare i servizi di base perché la replica esiste, ma non osservando i dati stessi. I servizi di backup e/o snapshot sono disponibili per l'uso da parte dell'utente SC secondario (nel caso di storage a blocchi e storage degli oggetti) e vengono localizzati nel dominio di Identity/Compartimento di ogni utente SC secondario, inaccessibile da altri utenti SC secondari.

In alternativa, ogni utente SC secondario può utilizzare risorse di terze parti o locali (entro i confini fisici dell'ambiente SC secondario) come destinazioni per la protezione dei dati. Ciò avverrebbe mediante la creazione di connessioni VPN FastConnect o CPE private ai compartimenti sotto il controllo dell'utente secondario SC. La connessione dati sarebbe completamente isolata dall'altro utente SC secondario e dal cliente poiché ogni punto di connessione esisterebbe esclusivamente all'interno della struttura del dominio di Identity/Compartimento dell'utente SC secondario stesso. Questo modello consentirebbe la protezione e l'estrazione dei dati a terzi, al di fuori del controllo del cliente, in un archivio di dati locale situato all'interno dei confini fisici dell'ambiente sub-SC o in una combinazione di essi, a seconda delle esigenze del singolo utente sub-SC.

Descrizione dell'immagine security_structure_overview.png

security_structure_overview-oracle.zip