Nota

Approfondisci i criteri di Oracle Cloud Infrastructure Identity and Access Management basati su tag

Introduzione

I criteri di Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) sono la pietra angolare di un ambiente cloud solido e sicuro. Forniscono un meccanismo potente e flessibile per controllare l'accesso alle risorse OCI, assicurando che solo gli utenti e i servizi autorizzati possano eseguire azioni specifiche sulle risorse designate.

Alla base, un criterio IAM OCI è un set di istruzioni dichiarative scritte in una sintassi leggibile che impone a chi può accedere a cosa e in con quali condizioni. Questi criteri consentono alle organizzazioni di applicare il principio del privilegio minimo, concedendo agli utenti e ai servizi solo le autorizzazioni necessarie per eseguire i task e altro ancora. Ciò riduce al minimo i rischi per la sicurezza mantenendo l'efficienza operativa.

I criteri IAM OCI vengono applicati a vari livelli della gerarchia OCI, inclusi compartimenti, tenancy e risorse specifiche, rendendoli altamente adattabili a strutture organizzative complesse. Grazie all'ereditarietà dei criteri e alla compartimentazione di OCI, gli amministratori possono stabilire controlli granulari personalizzati in base ai requisiti specifici di sicurezza e operativi. Per ulteriori informazioni sui criteri OCI, vedere Guida introduttiva ai criteri.

In questo tutorial, analizzeremo l'importanza dell'ottimizzazione delle politiche, esploreremo le best practice per perfezionare le politiche per ottenere risultati ottimali ed evidenzieremo scenari in cui l'ottimizzazione delle politiche può essere sfruttata al massimo del suo potenziale.

Obiettivi

Prerequisiti

Demistifica componenti e sintassi dei criteri

Per ottimizzare in modo efficace i criteri IAM OCI, è essenziale comprenderne la struttura e i componenti chiave. I criteri in OCI definiscono le autorizzazioni specificando chi (principal), cosa (action) su cosa (resource) e dove (scope). Analizziamo in dettaglio:

Componenti chiave di un criterio IAM OCI

Suggerimento bonus: Informazioni sui set - Interrompere il concetto nei criteri IAM OCI

I set-intersezione nei criteri IAM OCI vengono utilizzati per concedere l'accesso solo quando si verifica una sovrapposizione tra due set di valori. Ciò garantisce che le autorizzazioni vengano concesse in modo dinamico in base all'appartenenza al gruppo, alle tag delle risorse o ad altri attributi, invece di codificare utenti o gruppi specifici nei criteri.

Modello di criteri IAM OCI per larga scala

I criteri IAM OCI sono una delle parti fondamentali della protezione dei carichi di lavoro su OCI. È fondamentale essere in grado di scalare e supportare un grande carico di lavoro per i nostri clienti. Ecco perché abbiamo creato un modello criteri che richiede un numero ridotto di criteri, entro i limiti dei criteri di OCI, che funzionano per qualsiasi dimensione del carico di lavoro. Di seguito sono riportati alcuni dei motivi per adottare il modello criteri scalabile. Per ulteriori informazioni, vedere IAM con limiti dei domini di Identity.

Il tuning dei criteri IAM OCI è un task fondamentale per mantenere un ambiente cloud sicuro, scalabile ed efficiente pur rispettando i limiti dei criteri di OCI. Ecco perché questo processo è essenziale:

Il ruolo dell'applicazione di tag nella gestione dei criteri

L'applicazione di tag è una funzione potente in OCI che migliora notevolmente la gestione dei criteri abilitando il controllo dettagliato delle risorse. Le tag sono etichette di metadati, rappresentate come coppie chiave-valore, che possono essere collegate alle risorse. Aiutano a organizzare, gestire e applicare il controllo dell'accesso su larga scala, soprattutto in ambienti cloud complessi con più team e progetti. Per ulteriori informazioni, vedere Panoramica sull'applicazione di tag.

Come l'applicazione di tag migliora la gestione dei criteri

  1. Semplifica l'identificazione delle risorse: i tag forniscono un modo unificato per classificare le risorse in base ad attributi quali progetti, ambienti, proprietari o reparti. Ciò semplifica il processo di applicazione di criteri a sottoinsiemi specifici di risorse.

    Esempio: l'applicazione di tag alle risorse con Project: ProjectX abilita i criteri di accesso mirati.

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

  2. Abilita l'applicazione dei criteri dinamici: i criteri basati sulle tag si adattano alla modifica degli attributi delle risorse. Ad esempio, se una nuova istanza è contrassegnata con Environment: Production, eredita automaticamente i criteri definiti per gli ambienti di produzione.

    Criterio di esempio:

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

  3. Semplifica la governance multiprogetto e multi-team: i tag consentono di isolare l'accesso associando le risorse a team o progetti specifici. Ciò riduce la complessità durante la gestione delle autorizzazioni tra più gruppi.

  4. Semplifica l'automazione: i tag possono guidare flussi di lavoro automatizzati per la creazione, il monitoraggio e la gestione del ciclo di vita delle risorse. Ad esempio, gli script di tracciamento dei costi possono recuperare tutte le risorse contrassegnate con CostCenter: Marketing per generare note spese dettagliate.

  5. Migliora la gestione dei costi e il reporting: i tag consentono l'attribuzione granulare dei costi a progetti, reparti o ambienti specifici. Ciò consente alle organizzazioni di tenere traccia delle spese e ottimizzare i budget in modo più efficace.

Tag Governance: Controllo della gestione dei tag

Per mantenere la coerenza, l'affidabilità e la sicurezza nella gestione delle policy, la creazione e la modifica dei tag devono essere strettamente controllate. La governance garantisce che i tag vengano applicati correttamente e siano allineati agli standard organizzativi. Limitare la gestione delle tag a un set specifico di individui o gruppi è un elemento chiave per mantenere il controllo, la coerenza e la sicurezza all'interno dell'ambiente cloud di un'organizzazione.

Criteri IAM OCI basati su tag per casi d'uso reali

Ora con tutto ciò che hai imparato in precedenza, lavoriamo sul tuning delle policy IAM OCI per i principi utente e i principi delle istanze nei casi d'uso reali. Ma prima di farlo, ci sono alcune politiche comuni che ogni cliente richiederà indipendentemente dal suo caso d'uso.

Ridimensiona criteri IAM OCI per i principal utente

Modello criteri OCI IAM: in questo modello criteri, l'obiettivo è scrivere un numero ridotto di criteri più gestibili che vengono informati dai dati (tag nel nostro caso), anche noti come controllo dell'accesso basato su attributi. Faremo riferimento alle tag assegnate al compartimento delle risorse di destinazione o di destinazione per il controllo dell'accesso come tag di autorizzazione.

Tag autorizzazione: definire la tag di autorizzazione per ogni combinazione Verbo (azione) + Tipo di risorsa nella tenancy. Definiscono un'autorizzazione univoca da assegnare a un gruppo di utenti per le risorse di destinazione. L'elenco non è una volta impostato e completato. Iniziare con un numero ridotto di tag di autorizzazione. Una volta ottenuto un handle sul modello criteri, è possibile aggiungere ulteriori tag di autorizzazione. Per questa esercitazione verrà creato uno spazio di nomi tag di autorizzazione come mgmt. Inoltre, verrà creato uno spazio di nomi tag (chiameremo questo infosec) con una chiave tag denominata gname.

  1. Per la struttura del compartimento seguente con quattro tipi di risorse e per assegnare autorizzazioni di gestione e utilizzo per tali risorse, verranno create tag di autorizzazione.

    Tag di autorizzazione

  2. Per ogni autorizzazione da assegnare a una destinazione (nella maggior parte dei casi, i compartimenti), creare un gruppo. Le tag di autorizzazione vengono assegnate alle risorse (utilizzando le tag predefinite del compartimento) e ai compartimenti delle risorse. Il valore della tag è il gruppo che deve disporre dell'autorizzazione specificata per la risorsa di destinazione.

    Gruppi di tag autorizzazione

  3. Una volta definite le tag di autorizzazione, è possibile scrivere i criteri. Il risultato finale è che sarà necessario un solo criterio per ogni tag di autorizzazione definito nella tenancy. Lo stesso criterio per l'autorizzazione specificata funzionerà nell'intera tenancy.

    Criteri tag autorizzazione

  4. Quando inseriamo più carichi di lavoro, se ci sono più tipi di risorse da gestire, potrebbe essere necessario aggiungere ulteriori tag e criteri di autorizzazione per tali tag di autorizzazione. In caso contrario, è sufficiente assegnare tag di autorizzazione esistenti al nuovo carico di lavoro con un gruppo di utenti che devono disporre dell'accesso. Non è necessario scrivere nuovi criteri per il nuovo carico di lavoro.

Questo approccio rimarrà coerente in tutti gli esempi discussi qui, fungendo da base per la definizione dei gruppi e dei criteri IAM OCI.

Esempio 1: compartimento per ogni applicazione

Passo 1: ottenere una comprensione completa della panoramica aziendale del cliente

CompanyA è un'azienda tecnologica in crescita che sviluppa e distribuisce più applicazioni cloud native per i propri clienti. Ogni applicazione si rivolge a un segmento di clienti specifico, con severi requisiti di sicurezza e conformità. Per garantire isolamento, scalabilità e controllo dell'accesso efficiente, CompanyA organizza le proprie risorse OCI utilizzando un approccio strutturato alla compartimentazione.

Passo 2: progettare la struttura del compartimento per il carico di lavoro

Come descritto, CompanyA segue il modello criteri IAM OCI per il ridimensionamento dei criteri IAM OCI. Hanno creato compartimenti separati per le loro applicazioni per mantenere l'isolamento delle risorse.

Caso d'uso 1

Nota: solo gli amministratori devono essere in grado di gestire lo spazio di nomi tag mgmt e infosec.

Passo 3: Progettare le seguenti tag di autorizzazione di tipo Verb+Resource Combinazione

Creare gruppi in OCI.

  1. Eseguire il login al dominio IAM OCI con un account di amministrazione che dispone del privilegio per creare i gruppi.

    Home OCI

  2. Andare a Identità e sicurezza e fare clic su Domini in Identità.

    Domini

  3. Selezionare il compartimento e fare clic sul dominio per il quale si desidera creare i gruppi.

    Seleziona domini

  4. Fare clic su Gruppi.

    Gruppi

  5. Definire i gruppi in base alle tag di autorizzazione. (Facoltativo) aggiungere gli utenti a tali gruppi.

    Crea gruppi

Nota: sarà necessario creare gruppi per una combinazione univoca di autorizzazione e destinazione. Se lo stesso gruppo funzionale di utenti (NetworkAdmin) richiede l'accesso per gestire la rete in tutte le destinazioni, è necessario un solo gruppo per gestire l'accesso in tutte le destinazioni.

Di seguito sono riportate le tag di autorizzazione e i gruppi IAM OCI per tali tag. Attenersi alla procedura precedente per creare gruppi per ciascuna tag di autorizzazione definita.

  1. Compartimento radice: il compartimento radice funge da livello di gestione di livello superiore. Dove avremo i nostri gruppi di amministratori contrassegnati con tag di autorizzazione. Di seguito sono riportate le tag.

    • Amministratori: autorizzazione manageall per la gestione complessiva della tenancy.
    • UseAdministrators: autorizzazione useall per l'accesso alle risorse nella tenancy.
    • Auditor: autorizzazione readall con accesso in sola lettura alle risorse per il monitoraggio in tutta la tenancy.

  2. Modello di compartimento per applicazione: CompanyA dispone di più applicazioni basate su cloud. Verrà creato un compartimento padre separato per ogni applicazione. Esaminiamo come questo modello si applica all'applicazione 1 (App1) e all'applicazione 2 (App2) come compartimenti padre.

    • Applicazione 1 (App1): un'applicazione rivolta al cliente ospitata su OCI.

      • Compartimento di rete: compartimento per tutte le risorse correlate alla rete, ad esempio VCN, subnet e così via. Ora, consente di creare le tag di autorizzazione e i rispettivi gruppi IAM OCI.
        • App1NetworkAdmin: tag di autorizzazione delle risorse managenetwork per i tecnici che gestiscono le risorse di rete per App1.
        • App1NetworkUser: la tag di autorizzazione delle risorse usenetwork per gli sviluppatori che necessitano di un accesso limitato alle configurazioni di rete di App1.
        • App1NetworkReader: tag di autorizzazione delle risorse readnetwork per gli auditor che verificano l'impostazione di rete di App1.
      • Compartimento di computazione: compartimento per le istanze di computazione. Ora, consente di creare le tag di autorizzazione e i rispettivi gruppi IAM OCI.
        • App1ComputeAdmin: tag di autorizzazione delle risorse managecompute per gli amministratori di sistema che eseguono il provisioning e il ridimensionamento delle istanze di computazione per il backend App1.
        • App1ComputeUser: tag di autorizzazione delle risorse usecompute per gli sviluppatori che distribuiscono e testano i servizi backend di App1.
        • App1ComputeReader: tag di autorizzazione delle risorse readcompute per gli auditor che monitorano l'uso delle risorse di computazione per App1.
      • Compartimento dati: compartimento per le risorse correlate al database e allo storage. Ora, consente di creare le tag di autorizzazione e i rispettivi gruppi IAM OCI.
        • App1DataAdmin: tag di autorizzazione delle risorse managedb per gli amministratori di database che gestiscono Oracle Autonomous Databases e OCI Object Storage per App1.
        • App1DataUser: tag di autorizzazione delle risorse usedb per i data scientist che accedono ai set di dati per l'analisi in relazione a App1.
        • App1DataReader: tag di autorizzazione delle risorse readdb per gli auditor che esaminano le configurazioni del database di App1.

    • Applicazione 2 (App2): sistema ERP (Enterprise Resource Planning) interno per le operazioni dell'azienda.

      Nota: anche in questo caso, seguiremo lo stesso approccio alla struttura del compartimento e creeremo compartimento di rete, compartimento di computazione e compartimento dati nel compartimento App2 padre. Per evitare la ridondanza, prenderemo nota delle tag di autorizzazione e dei gruppi IAM OCI per App2.

      • Compartimento rete:

        • App2NetworkAdmin: tag di autorizzazione delle risorse managenetwork.
        • App2NetworkUser: tag di autorizzazione delle risorse usenetwork.
        • App2NetworkReader: tag di autorizzazione delle risorse readnetwork.

      • Compartimento di computazione:

        • App2ComputeAdmin: tag di autorizzazione delle risorse managecompute.
        • App2ComputeUser: tag di autorizzazione delle risorse usecompute.
        • App2ComputeReader: tag di autorizzazione delle risorse readcompute.

      • Compartimento dati:

        • App2DataAdmin: tag di autorizzazione delle risorse managedb.
        • App2DataUser: tag di autorizzazione delle risorse usedb.
        • App2DataReader: tag di autorizzazione delle risorse readdb.

Nota: applicare una tag di autorizzazione a una destinazione (la destinazione può essere una risorsa o un compartimento) per stabilire quale gruppo disporrà dell'autorizzazione specifica per la destinazione per App1 e App2.

Passo 4: scrivere i criteri IAM OCI per tali tag di autorizzazione

I criteri per CompanyA verranno creati utilizzando lo stesso approccio descritto qui: Have less be More - Scalabilità dei criteri IAM OCI per i gruppi. Per questo motivo, creare uno spazio di nomi tag (chiameremo questo infosec) con una chiave tag denominata gname.

  1. Eseguire il login al dominio IAM OCI con un account di amministrazione che dispone del privilegio per creare i criteri.

    Home OCI

  2. Andare a Identità e sicurezza e fare clic su Criteri in Identità.

    Criteri

  3. Selezionare il compartimento radice, quindi fare clic su Crea criterio.

    Creare i criteri

  4. Immettere Nome, Descrizione per il criterio e aggiungere anche Istruzioni criteri. Fare clic su Crea.

    • Criterio di tutte le risorse:

      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)

      Istruzioni criteri

      Nota: seguire la stessa procedura per definire tutti i criteri indicati di seguito e aggiungere le rispettive istruzioni dei criteri.

    • Criteri Cloudguard:

      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)

    • Criteri di rete:

      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)

    • Criterio di computazione:

      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)

    • Criterio database:

      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)

Esempio 2: compartimento per ogni cliente/tenant

Passo 1: ottenere una comprensione completa della panoramica aziendale del cliente

CompanyB Solutions è un ISV (Independent Software Vendor) leader del settore che fornisce applicazioni SaaS basate su tenant nell'infrastruttura cloud, nella gestione dei dati e negli analytics. CompanyB serve più clienti in tutti i settori, offrendo soluzioni trasparenti, sicure e scalabili. Il loro successo dipende dall'utilizzo di OCI con una struttura compartimentale ben progettata per gestire le risorse in modo efficiente, rispettando al contempo i requisiti di sicurezza e compliance.

Passo 2: progettare la struttura del compartimento per il carico di lavoro

CompanyB ha isolato i carichi di lavoro per i propri clienti e ha creato un compartimento secondario dedicato. Inoltre, dispongono di un compartimento di rete, di storage condiviso e di un compartimento di database. Anche CompanyB segue il modello criteri IAM OCI per il ridimensionamento dei criteri IAM OCI.

Caso d'uso 2

Passo 3: Progettare seguendo le tag di autorizzazione di tipo Verb+Resource Combinazione

Per creare gruppi, vedere Esempio 1 Passo 3. Sarà necessario creare gruppi per tutte le tag di autorizzazione definite di seguito.

  1. Compartimento radice - Governance centralizzata: il componente radice funge da livello centrale per la supervisione di tutte le risorse e le attività nella tenancy OCI. Dove avremo i nostri gruppi di amministratori contrassegnati con tag di autorizzazione. Di seguito sono riportate le tag.

    • Amministratori: autorizzazione manageall per la gestione complessiva della tenancy.
    • UseAdministrators: autorizzazione useall per l'accesso alle risorse nella tenancy.
    • Auditor: autorizzazione readall con accesso in sola lettura alle risorse per il monitoraggio in tutta la tenancy.

  2. Compartimento di rete - Backbone of Operations: il compartimento di rete supporta l'infrastruttura di cloud networking di CompanyB, abilitando la connettività tra tutte le risorse. Sono incluse le reti cloud virtuali (VCN), le subnet, i gateway e i load balancer. Definiamo le tag di autorizzazione e i relativi gruppi IAM OCI.

    • NetworkAdmin: tag di autorizzazione delle risorse managenetwork per i tecnici che gestiscono le risorse di rete per CompanyB.
    • NetworkUser: tag di autorizzazione delle risorse usenetwork per gli sviluppatori che necessitano di un accesso limitato alle configurazioni di rete di CompanyB.
    • NetworkReader: tag di autorizzazione delle risorse readnetwork per gli auditor che verificano l'impostazione di rete di CompanyB.

  3. Compartimento tenant - Compartimenti isolati per carichi di lavoro dei clienti diversi: il compartimento dei tenant è strutturato per isolare le risorse e i carichi di lavoro per ogni client (tenant). Ciò garantisce che CompanyB offra servizi sicuri e privati pur mantenendo l'efficienza operativa.

    • Compartimento tenant 1: il tenant 1 rappresenta un importante client enterprise che utilizza CompanyB per i servizi di sviluppo e registrazione delle applicazioni. Di seguito sono riportate le tag di autorizzazione e i rispettivi gruppi IAM OCI.

      • t1devadmin: l'autorizzazione delle risorse manageappdev per il team di sviluppo per il tenant 1 dispone dei privilegi amministrativi per configurare e distribuire applicazioni personalizzate.
      • t1devuser: l'autorizzazione risorsa useappdev per monitorare e regolare le risorse dell'applicazione. Gli sviluppatori del tenant 1 utilizzano queste risorse per lo sviluppo e il test quotidiani.
      • t1logsadmin e t1devuser: l'autorizzazione delle risorse managelogs e uselogs per i ruoli di registrazione e monitoraggio garantisce che gli amministratori configurino i servizi di registrazione mentre i log degli accessi degli sviluppatori eseguano il debug e l'ottimizzazione delle applicazioni.
      • t1devadmin e t1devuser: le autorizzazioni delle risorse managecspm e usecspm per il tenant 1 si concentrano anche sulle impostazioni di sicurezza, con la possibilità di monitorare e correggere i rischi per la sicurezza.

    • 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. Questo approccio consente a CompanyB di mantenere una governance coerente, soddisfacendo al contempo le esigenze specifiche dei tenant.

    • Compartimento condiviso - Risorse centralizzate per tutti i tenant: il compartimento condiviso include risorse quali database e storage degli oggetti che più tenant utilizzano, ma rimangono logicamente separate per privacy e sicurezza.

      • Compartimento del database:
        • dbadmin: l'autorizzazione delle risorse managedb per gli amministratori di database dell'azienda gestisce i database condivisi utilizzati da tutti i tenant, inclusi provisioning, ridimensionamento e applicazione di patch.
        • dbuser: l'autorizzazione risorsa usedb per gli utenti specifici del tenant accede ai rispettivi schemi o servizi di database.
        • dbreader: l'autorizzazione delle risorse readdb per gli auditor dispone dell'accesso in sola lettura per garantire che le configurazioni del database siano conformi ai criteri di sicurezza.
      • Compartimento di storage: lo storage degli oggetti OCI viene gestito centralmente, con bucket dedicati per ogni tenant:
        • osadmin: autorizzazione di risorsa manageobject responsabile della gestione delle risorse di storage degli oggetti condivisi.
        • osuser: useobject l'autorizzazione delle risorse di storage specifiche del tenant (o, ad esempio, t1osur, t2osur, t3osur) garantisce che i tenant accedano solo ai rispettivi bucket.
        • osreader: l'autorizzazione delle risorse readobject per i team di conformità esamina le configurazioni di storage e i pattern di utilizzo.

Passo 4: scrivere i criteri IAM OCI per tali tag di autorizzazione

Per creare criteri, vedere Esempio 1 Passo 4. Sarà necessario creare i criteri seguenti.

Esempio 3: struttura compartimento grande azienda

Passo 1: ottenere una comprensione completa della panoramica aziendale del cliente

CompanyC Solutions, un'organizzazione multinazionale specializzata in soluzioni software innovative, ha deciso di migrare i propri carichi di lavoro mission-critical su OCI. L'azienda opera in settori altamente regolamentati come finance e sanità, dove sicurezza, compliance e scalabilità sono della massima importanza.

Passo 2: progettare la struttura del compartimento per il carico di lavoro

Esaminiamo ora la struttura del compartimento per CompanyC, che segue il modello criteri IAM OCI per il ridimensionamento dei criteri IAM OCI.

Caso d'uso 3

Passo 3: Progettare le seguenti tag di autorizzazione di tipo Verb+Resource Combinazione

Per creare gruppi, vedere Esempio 1 Passo 3. È necessario creare gruppi per tutti i tag di autorizzazione seguenti.

  1. Compartimento radice - Governance centralizzata: il componente radice funge da livello centrale per la supervisione di tutte le risorse e le attività nella tenancy OCI. Dove avremo i nostri gruppi di amministratori contrassegnati con tag di autorizzazione. Di seguito sono riportate le tag.

    • Amministratori: autorizzazione manageall per la gestione complessiva della tenancy.
    • UseAdministrators: autorizzazione useall per l'accesso alle risorse nella tenancy.
    • Auditor: autorizzazione readall con accesso in sola lettura alle risorse per il monitoraggio in tutta la tenancy.

  2. Compartimento del sistema: il compartimento per l'hosting di carichi di lavoro di produzione mission-critical che influiscono direttamente sulle operazioni aziendali e sugli utenti finali. Ogni applicazione dispone di un sottocompartimento dedicato per l'isolamento delle risorse e la gestione ottimizzata. Definiamo le tag di autorizzazione e i relativi gruppi IAM OCI.

    • NetworkAdmin: tag di autorizzazione delle risorse managenetwork per i tecnici che gestiscono le risorse di rete per CompanyC.
    • NetworkReader: tag di autorizzazione delle risorse readnetwork per gli auditor che verificano l'impostazione di rete di CompanyC.
    • ComputeAdmin: tag di autorizzazione delle risorse managecompute per gli amministratori di sistema che eseguono il provisioning e il ridimensionamento delle istanze di computazione per CompanyC.
    • ComputeReader: tag di autorizzazione delle risorse readcompute per gli auditor che monitorano l'uso delle risorse di computazione per CompanyC.
    • StorageReader: manageobject autorizzazione delle risorse per consentire ai team di amministrazione dello storage di gestire le configurazioni dello storage.
    • StorageReader: l'autorizzazione delle risorse readobject per i team di conformità esamina le configurazioni di storage e i pattern di utilizzo.
    • SecurityAdmin: l'autorizzazione delle risorse managecspm per Compartment PROD è incentrata anche sulle impostazioni di sicurezza, con la possibilità di monitorare e correggere i rischi per la sicurezza.

    Ora andremo avanti e definiremo le tag di autorizzazione e i rispettivi gruppi IAM OCI per i compartimenti secondari specifici dell'applicazione. Nell'interesse del tempo, abbiamo unito e definito le autorizzazioni per tutti e 3 i diversi compartimenti dell'applicazione.

    • Compartimenti delle applicazioni:
      • PRApp1NetAdmin, PRApp2NetAdmin e PRApp3NetAdmin: l'amministratore IAM OCI raggruppa i gruppi con la tag di autorizzazione delle risorse managenetwork per i tecnici che gestiscono le risorse di rete rispettivamente per App1, App2 e App3.
      • PRApp1NetUser, PRApp2NetUser e PRApp3NetUser: l'amministratore IAM OCI raggruppa con la tag di autorizzazione delle risorse usenetwork per i tecnici che gestiscono le risorse di rete rispettivamente per App1, App2 e App3.
      • PRApp1ComputeAdmin, PRApp2ComputeAdmin e PRApp3ComputeAdmin: l'amministratore IAM OCI raggruppa con la tag di autorizzazione delle risorse managecompute per i tecnici che gestiscono le istanze di OCI Compute rispettivamente per App1, App2 e App3.
      • PRApp1ComputeUser, PRApp2ComputeUser e PRApp3ComputeUser: l'amministratore IAM OCI raggruppa i gruppi con la tag di autorizzazione delle risorse usecompute per i tecnici che utilizzano le istanze di OCI Compute rispettivamente per App1, App2 e App3.
      • PRApp1StorageAdmin, PRApp2StorageAdmin e PRApp3StorageAdmin: l'amministratore IAM OCI raggruppa i gruppi con tag di autorizzazione delle risorse manageobject per i tecnici che gestiscono lo storage degli oggetti OCI rispettivamente per App1, App2 e App3.
      • PRApp1StorageUser, PRApp2StorageUser e PRApp3StorageUser: l'amministratore IAM OCI raggruppa i gruppi con tag di autorizzazione delle risorse useobject per i tecnici che utilizzano lo storage degli oggetti OCI rispettivamente per App1, App2 e App3.

  3. Compartimento NPROD: dedicato agli ambienti di staging, sviluppo e garanzia della qualità. Questo compartimento è strutturato in modo simile a PROD per garantire la coerenza. Definiamo le tag di autorizzazione e i relativi gruppi IAM OCI.

    • NetworkAdmin: tag di autorizzazione delle risorse managenetwork per i tecnici che gestiscono le risorse di rete per CompanyC.
    • NetworkReader: tag di autorizzazione delle risorse readnetwork per gli auditor che verificano l'impostazione di rete di CompanyC.
    • ComputeAdmin: managecompute tag di autorizzazione delle risorse per gli amministratori di sistema che eseguono il provisioning e il ridimensionamento delle istanze di OCI Compute per CompanyC.
    • ComputeReader: tag di autorizzazione delle risorse readcompute per gli auditor che monitorano l'uso delle risorse di OCI Compute per CompanyC.
    • StorageReader: manageobject autorizzazione delle risorse per consentire ai team di amministrazione dello storage di gestire le configurazioni dello storage.
    • StorageReader: l'autorizzazione delle risorse readStorage per i team di conformità esamina le configurazioni di storage e i pattern di utilizzo.
    • SecurityAdmin: l'autorizzazione delle risorse managecspm per Compartment NPROD è incentrata anche sulle impostazioni di sicurezza, con la possibilità di monitorare e correggere i rischi per la sicurezza.

    Analogamente, ora andremo avanti e definiremo le tag di autorizzazione e i rispettivi gruppi IAM OCI per i compartimenti secondari specifici dell'applicazione.

    • Compartimenti delle applicazioni:
      • NPApp1NetAdmin, NPApp2NetAdmin e NPApp3NetAdmin: l'amministratore IAM OCI raggruppa con la tag di autorizzazione delle risorse managenetwork per i tecnici che gestiscono le risorse di rete rispettivamente per App1, App2 e App3.
      • NPApp1NetUser, NPApp2NetUser e NPApp3NetUser: l'amministratore IAM OCI raggruppa con la tag di autorizzazione delle risorse usenetwork per i tecnici che gestiscono le risorse di rete rispettivamente per App1, App2 e App3.
      • NPApp1ComputeAdmin, NPApp2ComputeAdmin e NPApp3ComputeAdmin: l'amministratore IAM OCI raggruppa con la tag di autorizzazione delle risorse managecompute per i tecnici che gestiscono le istanze di OCI Compute rispettivamente per App1, App2 e App3.
      • NPApp1ComputeUser, NPApp2ComputeUser e NPApp3ComputeUser: l'amministratore IAM OCI raggruppa i gruppi con la tag di autorizzazione delle risorse usecompute per i tecnici che utilizzano le istanze di OCI Compute rispettivamente per App1, App2 e App3.
      • NPApp1StorageAdmin, NPApp2StorageAdmin e NPApp3StorageAdmin: l'amministratore IAM OCI raggruppa i gruppi con tag di autorizzazione delle risorse manageobject per i tecnici che gestiscono lo storage degli oggetti OCI rispettivamente per App1, App2 e App3.
      • NPApp1StorageUser, NPApp2StorageUser e NPApp3StorageUser: l'amministratore IAM OCI raggruppa i gruppi con tag di autorizzazione delle risorse useobject per i tecnici che utilizzano lo storage degli oggetti OCI rispettivamente per App1, App2 e App3.

  4. Compartimento condiviso: il compartimento condiviso ospita le risorse per il monitoraggio, ad esempio i servizi OCI di log e Cloud Guard. Ha anche chiavi per la crittografia e la decifrazione che vengono utilizzate da più tenant, garantendo al contempo la segregazione logica per mantenere la privacy e la sicurezza. Tutti gli amministratori delle applicazioni che richiedono l'accesso a questi servizi verranno aggiunti ai gruppi IAM OCI creati per questi servizi. Definiamo le tag di autorizzazione e i rispettivi gruppi IAM OCI.

    • Compartimenti Oracle Cloud Guard:

      • cspmAdmin: l'amministratore IAM OCI raggruppa i gruppi con la tag di autorizzazione delle risorse managecspm per gli amministratori che gestiscono Oracle Cloud Guard per i compartimenti PROD e Non PROD.
      • cspmUser: IAM OCI raggruppa i gruppi con la tag di autorizzazione delle risorse usecspm per i tecnici che utilizzano/monitoraggio di Oracle Cloud Guard per i compartimenti PROD e Non PROD.
      • cspmReader: IAM OCI raggruppa i gruppi con la tag di autorizzazione delle risorse readcspm per i tecnici che leggono Oracle Cloud Guard per i compartimenti PROD e Non PROD.

    • Compartimenti di log OCI:

      • logsAdmin: l'amministratore IAM OCI raggruppa i gruppi con la tag di autorizzazione delle risorse managelogs per gli amministratori che gestiscono OCI Logging per i compartimenti PROD e Non PROD.
      • logsUser: IAM OCI raggruppa i gruppi con la tag di autorizzazione delle risorse uselogs per i tecnici che utilizzano/monitoraggio di OCI Logging per i compartimenti PROD e Non PROD.
      • logsReader: IAM OCI raggruppa con la tag di autorizzazione delle risorse readlogs per i tecnici che leggono OCI Logging per i compartimenti PROD e Non PROD.

    • Compartimenti chiavi:

      • kmsAdmin: l'amministrazione dei gruppi IAM OCI con la tag di autorizzazione delle risorse managekeys per gli amministratori che gestiscono il vault di chiavi per i compartimenti PROD e Non PROD.
      • kmsUser: IAM OCI raggruppa i gruppi con la tag di autorizzazione delle risorse usekeys per i tecnici che utilizzano/monitoraggio del vault di chiavi per i compartimenti PROD e Non PROD.
      • kmsReader: IAM OCI raggruppa con la tag di autorizzazione delle risorse readkeys per i tecnici che leggono il vault di chiavi per i compartimenti PROD e Non PROD.

  5. Compartimento del campo di gioco: un ambiente flessibile e isolato per la sperimentazione, lo sviluppo e i test. Questo compartimento non è legato a vincoli di produzione o conformità, il che lo rende ideale per l'innovazione. Qui avremo un solo gruppo di amministratori IAM OCI per il compartimento molto figlio e forniremo i privilegi di gestione a tutte le risorse OCI necessarie per i requisiti di test.

    • Compartimenti di sviluppo:

      • DevAdmin: amministrare i gruppi IAM OCI con l'autorizzazione delle risorse managenetwork, managecompute, manageobject, managekeys, managelogs per gli amministratori dello sviluppo per eseguire il test della nuova implementazione nel compartimento dello sviluppo.

    • Compartimenti di test:

      • TestAdmin: amministrare i gruppi IAM OCI con l'autorizzazione delle risorse managenetwork, managecompute, manageobject, managekeys, managelogs per gli amministratori dello sviluppo per eseguire il test della nuova implementazione nel compartimento di test.

    • Compartimenti di test delle prestazioni:

      • PerfTestAdmin: amministrare i gruppi IAM OCI con l'autorizzazione delle risorse managenetwork, managecompute, manageobject, managekeys, managelogs per gli amministratori dello sviluppo per eseguire il test della nuova implementazione nel compartimento di test delle prestazioni.

Passo 4: scrivere i criteri IAM OCI per tali tag di autorizzazione

Per creare criteri, vedere Esempio 1 Passo 4. È necessario creare i criteri seguenti.

Nota: per questo scenario ogni volta che si inserisce un nuovo carico di lavoro:

Modello di autorizzazione basato su tag per il controllo dell'accesso granulare

Finora, tutti gli esempi, abbiamo discusso di creare autorizzazioni di gestione, utente o lettura per una famiglia di risorse. Tuttavia, la maggior parte dei clienti richiede un controllo dell'accesso granulare per seguire il modello con privilegi minimi. Il tutorial si concentra sulla comprensione del modello criteri, motivo per cui abbiamo parlato di un caso d'uso semplice. Tuttavia, vorrei fare un esempio di quattro persone di rete e di come puoi progettare tag di autorizzazione granulari e criteri IAM OCI per queste quattro persone.

Definiremo networkowner, networkadmin, networkoperator e networkuser come quattro tag nel compartimento di rete. Per tali tag, assegneremo i nomi dei gruppi che hanno accesso al compartimento di rete.

Ridimensiona i criteri IAM OCI per i principal delle istanze

Esempio 1: controllo dell'accesso a istanze multi-tenant per lo storage condiviso e i segreti in OCI

Passo 1: ottenere una comprensione completa della panoramica aziendale del cliente

XYZ Cloud Solutions è un provider SaaS che offre un Document Management System (DMS) ospitato su OCI. La piattaforma serve più clienti aziendali, ognuno dei quali richiede un rigoroso isolamento dei propri dati, sfruttando al contempo un'infrastruttura condivisa.

Requisiti cliente:

Passo 2: progettare la struttura del compartimento per il carico di lavoro

Esaminiamo ora la struttura del compartimento per le soluzioni cloud XYZ, che segue il modello criteri IAM OCI per il ridimensionamento dei criteri IAM OCI.

Caso d'uso istanza 1

Passo 3: creare gruppi IAM OCI

Per garantire una gestione degli accessi sicura e isolata in un ambiente multi-tenant OCI, verranno definiti i criteri riportati di seguito.

Nota: questi gruppi e i criteri IAM OCI sono già stati creati come descritto in precedenza nella sezione Criteri IAM OCI comuni.

Passo 4: creare criteri IAM OCI per i gruppi definiti

Criteri di accesso alle risorse tenant: per mantenere l'isolamento dei dati, le risorse tenant devono essere in grado solo di accedere ai propri segreti e allo storage degli oggetti.

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

Se anche i principi dell'istanza del tenant richiedono l'autorizzazione per creare nuovi oggetti, è possibile creare nomi di bucket con lo stesso nome del nome del tenant e utilizzare la tag nome del tenant per eseguire il confronto con il nome del bucket.

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

Esempio 2: controllo dell'accesso con filtro per l'accesso ai dati multi-servizio in un modello di storage OCI condiviso

Passo 1: ottenere una comprensione completa della panoramica aziendale del cliente

XYZ Corp è un'azienda in rapida crescita specializzata in soluzioni di trasformazione digitale. Con una presenza globale, XYZ Corp opera in più region e sfrutta OCI per ospitare applicazioni strategiche, gestire i dati e garantire una collaborazione perfetta tra i team.

Requisiti cliente:

Passo 2: progettare la struttura del compartimento per il carico di lavoro

Esaminiamo ora la struttura del compartimento per XYZ Corp, che segue il modello criteri IAM OCI per il ridimensionamento dei criteri IAM OCI.

Caso d'uso istanza 2

Passo 3: creare gruppi IAM OCI

Per garantire una gestione degli accessi sicura e isolata in un ambiente multi-tenant OCI, verranno definiti i criteri riportati di seguito.

Nota: i gruppi e i criteri IAM InfoSec e Terraform-Runner sono già stati creati come descritto in precedenza nella sezione Policy IAM OCI comuni.

Passo 4: creare criteri IAM OCI per i gruppi definiti

Criteri di accesso alle risorse tenant: per mantenere l'isolamento dei dati, le risorse tenant devono essere in grado solo di accedere ai propri segreti e allo storage degli oggetti.

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’}

Conferme

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti gratuiti sulla formazione su Oracle Learning YouTube channel. Inoltre, visita education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

Per la documentazione del prodotto, visita l'Oracle Help Center.