Struttura di sicurezza IAM

Un vantaggio fondamentale dell'adozione del cloud è la scalabilità, che consente alle aziende di iniziare in piccolo e crescere in grande. Rispetto alle infrastrutture tradizionali, l'utilizzo dell'automazione consente di distribuire le risorse in pochi minuti anziché in giorni, il che può portare a una maggiore innovazione. Senza un adeguato controllo, un ambiente cloud può diventare troppo complesso e non gestibile in termini di sicurezza e costi, mettendo a rischio la tua organizzazione.

Prima di creare più risorse cloud in Oracle Cloud Infrastructure (OCI), ti consigliamo di impostare un modello di sicurezza IAM (Identity and Access Management). Una versione iniziale di un modello di sicurezza può aiutare la tua organizzazione a mitigare i rischi di gestione separando compiti e risorse, guidando il successo della crescita futura.

Nota: prima di aggiungere più risorse cloud, definire un modello di sicurezza IAM che copra la tenancy, la struttura del compartimento e così via.

In OCI, l'isolamento delle risorse è integrato, a partire dalle seguenti risorse:

• Tenancy
• Dominio di identità
• Struttura compartimento
• Criteri IAM

Organizzazione e tenancy

Quando ci si iscrive a OCI, Oracle crea una tenancy per l'utente. La tenancy contiene le entità IAM in uso, ad esempio utenti, gruppi, compartimenti, alcuni criteri e altre risorse OCI. Puoi anche inserire criteri e risorse nei compartimenti all'interno della tenancy. Per ulteriori informazioni, vedere Gestione organizzazione e Gestione dell'accesso alle risorse.

Considerare la tenancy come il più alto livello di confine della sicurezza

• La tenancy è il contenitore più alto che ospita le risorse OCI ed è anche indicato come compartimento radice.
• Tutti i controlli dell'accesso delle risorse OCI sono dettati dai criteri IAM, in cui la tenancy è il livello più alto che è possibile assegnare ai criteri IAM. Le regole di governance di OCI Organization Management possono controllare le aree consentite, la quota di servizi e le tag per le tenancy figlio, ma non hanno alcun controllo sui criteri IAM. È possibile concedere l'accesso tra le tenancy creando criteri IAM cross-tenancy. In questo caso, gli amministratori che concedono e accettano le tenancy devono creare istruzioni dei criteri speciali che indicano in modo esplicito le risorse a cui è possibile accedere e condividere.

Nota: il compartimento radice è il livello superiore della gerarchia di criteri IAM e i criteri IAM non possono ereditare tra le tenancy. Per ulteriori informazioni, vedere Funzionamento dei criteri e Criteri cross-tenancy.

Sfrutta più tenancy per scalare il tuo business oltre i limiti

• Ogni tenancy OCI viene creata con un set di limiti del servizio configurati da Oracle. Sebbene gli utenti possano richiedere un aumento del limite del servizio, non hanno il controllo diretto sui limiti.
• Per evitare interruzioni del servizio, gli utenti possono controllare la distribuzione dell'uso assegnando quote del servizio ai compartimenti in base alle esigenze.
• Gli utenti possono scalare oltre i limiti del servizio hardware sfruttando una nuova tenancy a cui è assegnato un proprio set di limiti durante la creazione.

È possibile aggiungere tenancy all'organizzazione utilizzando Organization Management e fare in modo che le tenancy utilizzino i crediti della sottoscrizione finanziata principale. Puoi quindi creare una tenancy isolata per creare i tuoi carichi di lavoro senza prenotare un nuovo ordine.

I tipi di tenancy includono i tipi riportati di seguito.

• Tenancy padre: associata alla sottoscrizione con fondi primari, che può analizzare e generare report in ogni tenancy. Ogni organizzazione può avere una sola tenancy padre. È tipico utilizzare la tenancy padre per scopi di gestione in cui le operazioni di sviluppo, finance e IT potrebbero dovervi accedere. In questo caso, si consiglia di non ospitare applicazioni o servizi all'interno di questa tenancy.
• Tenancy figlio: tenancy che utilizzano da una sottoscrizione che non è la propria. Le tenancy figlio possono essere create come interamente nuove tenancy oppure le tenancy esistenti possono essere invitate a entrare a far parte della tenancy padre e a far parte della stessa organizzazione.

Nota: si consiglia di non ospitare applicazioni o servizi all'interno della tenancy padre, soprattutto se utilizzata a scopo di gestione. Per ulteriori informazioni, vedere OCI Blog-Use Organizations (Organizzazioni blog-uso OCI) per gestire centralmente i costi.

Considerazioni per la struttura delle tenancy

Prendere in considerazione le seguenti informazioni per le tenancy:

• Fatturazione e gestione dei costi: la condivisione di un unico impegno consente di ridurre le eccedenze dei costi e consente la fatturazione consolidata.
• Isolamento dell'ambiente: quando è necessaria un'elevata autonomia operativa con un rigoroso isolamento delle risorse, è possibile utilizzare una tenancy come limite di livello superiore per isolare gli ambienti. Poiché ogni tenancy viene fornita con un set distinto di risorse e regole IAM, le impostazioni di sicurezza e governance vengono amministrate separatamente. L'amministrazione separata supporta il massimo grado di autonomia operativa.
• Overhead di gestione: più tenancy consentono l'autonomia operativa con un forte livello di isolamento, ma comportano costi generali di gestione. Se non è necessario un elevato livello di isolamento, ad esempio per la conformità alle normative, prendere in considerazione l'uso dei domini di identità e dei compartimenti.
• Residenza delle risorse IAM: ogni tenancy ha la propria area di origine, che contiene le informazioni sull'account Oracle Cloud e le risorse di identità nel dominio di identità IAM predefinito.
  • Il dominio predefinito viene sempre replicato in tutte le aree a cui è sottoscritto il tenant. Quando un amministratore esegue la sottoscrizione a un'altra area, solo il dominio predefinito viene replicato in tale area. L'area di origine del dominio predefinita è l'area di origine della tenancy, che non può essere modificata.
  • I domini di Identity secondari (non predefiniti) possono avere la propria area di origine, ma solo all'interno del set di aree a cui è sottoscritta la tenancy. I domini di Identity secondari possono anche essere replicati nelle aree all'interno del set di aree a cui è sottoscritta la tenancy.

Limitazioni per le tenancy

Considera le seguenti limitazioni per le tenancy:

• L'area di origine contiene le informazioni sull'account e le risorse di identità e non può essere modificata dopo il provisioning della tenancy. Per ulteriori informazioni, vedere Area Home.
• Quando viene creata una tenancy figlio, la tenancy non viene federata automaticamente ai domini di Identity Oracle Identity Cloud Service/OCI. Per ulteriori informazioni, vedere Creazione di una nuova tenancy figlio.
• Le tenancy che utilizzano le sottoscrizioni Pay As You Go o Free Tier non possono aggiungere nuove tenancy figlio. Per ulteriori informazioni, vedere Creazione di una nuova tenancy figlio.
• La tenancy padre-figlio è una struttura a livello singolo e non supporta una gerarchia a più livelli.

Casi d'uso di esempio per le tenancy

Considerare i seguenti casi d'uso di esempio per avere tenancy separate:

• SaaS service provider per ospitare tenancy dedicate per clienti regolamentati
• Requisiti di residenza delle risorse IAM dalle leggi sulla privacy e sulla sicurezza dei dati.
• Per fusioni e acquisizioni (M&A), le aziende che devono mantenere l'autonomia operativa con processi di gestione delle identità e di assunzione separati.
• Per gli hackathon e i proof of concept (PoC), la possibilità di avviare progetti innovativi in una tenancy di livello gratuito e basata su progetti e quindi applicare all'organizzazione più ampia tabelle di prezzi negoziate e una migliore visibilità sui costi.
• Requisiti normativi come la separazione degli ambienti di produzione e non di produzione.

Decisioni chiave di progettazione per le tenancy

Prendi decisioni chiave sulla progettazione in base alle seguenti informazioni:

• Casi d'uso accettati per ridimensionare l'adozione OCI con tenancy e organizzazioni separate
• Modelli operativi della tenancy, ad esempio il processo per richiedere una nuova tenancy, la proprietà della tenancy, i costi e la gestione del budget

Per ulteriori informazioni, vedere Gestione dell'organizzazione e Gestione della tenancy.

Impedisci ad altri di creare un account Oracle Cloud con il tuo nome di dominio pubblico

Per applicare una governance efficace, alcune aziende potrebbero dover avere il controllo centralizzato della creazione di nuovi account cloud in un business group.

Puoi registrare il tuo nome di dominio pubblico con OCI tramite Domain Management, che impedisce ad altri di richiedere tale dominio in futuro per utilizzare nuovi account cloud. È possibile reindirizzare i nuovi tentativi di iscrizione utente che utilizzano un indirizzo di posta elettronica aziendale da tale dominio verificato.

Ad esempio, se qualcuno che utilizza OCI tenta di creare una tenancy con "companyA.com" nel dominio di posta elettronica, il tentativo viene impedito e viene indirizzato invece a OCI.

Di conseguenza, con la gestione dei domini, le grandi aziende possono controllare più facilmente i propri ambienti conoscendo chi sta creando tenancy e applicando i criteri aziendali alle tenancy. Puoi verificare in tutta sicurezza la proprietà dei tuoi domini e controllare più facilmente la spesa e la gestione delle risorse.

In genere, questo aspetto viene coperto nella tenancy padre come parte della capacità di gestione centrale. È necessaria l'assistenza dell'amministratore del dominio pubblico per aggiungere il record TXT fornito da OCI per verificare la proprietà del dominio. Il completamento di questo processo di verifica del dominio può richiedere fino a 72 ore.

Nota: è possibile impedire ad altri di creare un account Oracle Cloud con il dominio verificato mediante Gestione dominio. In Notifica Oracle viene inviata una notifica se qualcuno tenta di creare un account con il dominio.

Nota: è possibile bloccare altre linee di business per creare i propri account abilitando questa funzione se si condivide un dominio. Si consiglia di abilitare questa funzione utilizzando il team di amministrazione centrale e la comunicazione corretta con le parti interessate correlate, ad esempio le linee di business interessate.

Decisioni chiave di progettazione per struttura tenancy

Per ulteriori informazioni, vedere Gestione dell'organizzazione e Gestione della tenancy.

Domini di identità IAM

Un dominio di identità è un contenitore per la gestione dei ruoli e degli utenti, la federazione e l'assegnazione ruoli degli utenti, la protezione dell'integrazione delle applicazioni tramite le configurazioni Single Sign-On (SSO) e l'amministrazione del provider di identità basata su SAML/OAuth. Il dominio rappresenta una popolazione di utenti in OCI e le configurazioni e le impostazioni di sicurezza associate, ad esempio l'autenticazione a più fattori (MFA).

È possibile creare e gestire più domini di Identity, ad esempio un dominio per lo sviluppo e uno per l'ambiente di produzione. Ogni dominio può avere requisiti di identità e sicurezza diversi per proteggere le applicazioni e i servizi OCI.

L'uso di più domini di Identity offre diversi vantaggi. Avendo domini di Identity separati, gli utenti che lavorano in un dominio di Identity non influiscono sul lavoro degli utenti in un altro dominio di Identity.

L'uso di più domini di Identity può agevolare la gestione dell'isolamento del controllo amministrativo su ciascun dominio di Identity. Sono necessari più domini di Identity, ad esempio, quando gli standard di sicurezza impediscono agli ID utente per lo sviluppo di esistere nell'ambiente di produzione. Vengono utilizzati più domini anche quando è necessario che amministratori diversi abbiano il controllo su vari ambienti.

Considerazioni sulla progettazione per i domini di Identity

Durante la progettazione della struttura IAM, tenere presenti le informazioni riportate di seguito.

• Necessità di separare gli ID utente e gli amministratori tra ambienti e carichi di lavoro. Ad esempio:
  • Produzione rispetto agli ambienti di sviluppo
  • Carichi di lavoro rivolti al personale rispetto ai carichi di lavoro rivolti al cliente
  • Dipendenti rispetto ai collaboratori
• Gli amministratori possono creare tutti i domini di Identity secondari consentiti dai limiti del servizio.
• È possibile eseguire l'upgrade del dominio di Identity predefinito o secondario a un tipo di dominio diverso. Ogni tipo di dominio di Identity è associato a funzioni e limiti degli oggetti diversi.

Le informazioni riportate di seguito riepilogano le differenze chiave tra il dominio di Identity predefinito e i domini di Identity secondari.

Casi d'uso di esempio per i domini di Identity

Considerare i casi d'uso di esempio riportati di seguito per avere domini di Identity separati.

• Utilizzo della separazione dell'ambiente in quanto alcuni standard di sicurezza e normative di settore richiedono la separazione degli utenti tra ambienti di produzione e sviluppo, impedendo l'accesso dallo sviluppo alla produzione.
• Separare gli utenti esterni, ad esempio clienti e collaboratori esterni, dalle identità dei dipendenti.

Suggerimenti per i domini di Identity

Segui questi suggerimenti durante la configurazione dei tuoi domini:

• Utilizzare domini di Identity diversi per ogni popolazione di utenti.
• Utilizzare il dominio di Identity predefinito per l'amministrazione a livello di tenancy. Utilizza i domini di Identity secondari per i servizi di amministrazione e platform as a service (PaaS) specifici dell'ambiente per avere maggiore controllo sul funzionamento del dominio, come il ciclo di vita, l'area home e la replica.
• Inizia a utilizzare il dominio di Identity gratuito/Oracle Apps per gli scenari solo per il cloud ed esegui l'upgrade a Premium/Oracle Apps Premium per ottenere limiti superiori o per supportare casi d'uso avanzati. Ad esempio:
  • Esegui l'autenticazione alle applicazioni Oracle on premise o ospitate nel cloud.
  • Utilizzare la sincronizzazione bidirezionale con Active Directory o altri sistemi IAM.
  • Utilizza le moderne funzionalità AuthN/AuthZ come l'autenticazione senza password, i token hardware FIDO2 e le soluzioni di sicurezza adattiva.
• Creare un dominio di Identity esterno secondario per i casi d'uso consumer e non dipendenti che richiedono le risorse seguenti:
  • Login social, password self-service dell'utente, gestione del profilo e consenso alle condizioni d'uso.
  • Identity as a service con funzionalità complete (IDaaS) per la scalabilità di milioni di utenti.
  • Nessun accesso alla gestione delle abilitazioni OCI. Alcuni esempi includono la gestione dell'accesso alle risorse OCI e le funzioni IAM rivolte al personale per il provisioning in applicazioni di terze parti che utilizzano il catalogo applicazioni e la sincronizzazione di Active Directory.

Decisioni chiave di progettazione per i domini di Identity

• Approva i casi d'uso accettabili per avere domini di Identity secondari aggiuntivi per le isolazioni IAM.
• Decidere l'area di origine del dominio IAM, che non può essere modificata dopo la creazione.
• Decidere se una delle principali funzioni IAM è obbligatoria, AD esempio la sincronizzazione bidirezionale con LDAP/AD tramite bridge, EBS Asserter e proxy RADIUS.
• Decidere la proprietà e l'amministrazione del dominio IAM dell'utente esterno se sono necessarie funzioni quali il login social, la password self-service dell'utente e la gestione del profilo.

Per ulteriori informazioni, vedere Tipi di dominio di Identity IAM.

Compartimenti e struttura di applicazione di tag per criteri IAM con concessione completa

Utilizzare compartimenti e tag per organizzare e isolare le risorse per il controllo dell'accesso.

Informazioni di base sui criteri IAM

• Il criterio IAM è un'istruzione che specifica chi può accedere alle risorse OCI di cui dispone l'azienda e in che modo.

• Poiché OCI non concede l'accesso per impostazione predefinita, la tua organizzazione ha bisogno di almeno un criterio per iniziare a gestire il controllo delle tue risorse. Ogni criterio è composto da una o più istruzioni che seguono la seguente sintassi di base:

  Consenti <subject> a <verb> <resource-type> in <location> dove <conditions>

• Le informazioni riportate di seguito descrivono i tre gruppi principali di criteri IAM.

• Poiché la modifica dell'accesso per i servizi OCI e il gruppo dinamico può causare interruzioni dei servizi se non vengono gestiti correttamente, si consiglia di rilasciare questi tipi di modifiche tramite una tenancy/un ambiente canary per evitare di introdurre interruzioni della produzione.
• È possibile concedere controlli dell'accesso organizzando le risorse con compartimenti e tag.

Considerazioni sulla progettazione per i compartimenti e le tag

Quando si impostano compartimenti e tag, tenere presenti le informazioni riportate di seguito.

• Compartimenti:

  • I compartimenti sono a livello di tenancy e si estendono in tutte le aree. Quando crei un compartimento, il compartimento è disponibile in ogni area a cui è sottoscritta la tenancy.
  • È possibile creare compartimenti secondari all'interno di altri compartimenti per creare gerarchie con profondità fino a sei livelli. Un sottocompartimento eredita le autorizzazioni di accesso dai compartimenti al di sopra di esso nella gerarchia.

  

  • Il compartimento è una delle unità obbligatorie per la concessione del controllo dell'accesso. È possibile perfezionare ulteriormente il compartimento in base alle clausole condizionali.

• Tag: è possibile utilizzare il controllo dell'accesso basato su tag per definire i criteri di accesso che si estendono su compartimenti, gruppi e risorse. L'uso del controllo dell'accesso basato su tag può aiutarti a evitare la duplicazione dei criteri IAM, a garantire coerenza e a ridurre al minimo il sovraccarico di gestione.

  Attenzione: le chiavi di tag definite non fanno distinzione tra maiuscole e minuscole, mentre i valori di tag definiti fanno distinzione tra maiuscole e minuscole. Ad esempio, "ENV" e "ENV" sono la stessa chiave tag. "DEV" e "DEV" sono valori di tag distinti.

• Criterio IAM condizionale:

  • La corrispondenza delle condizioni non fa distinzione tra maiuscole e minuscole, il valore della tag fa distinzione tra maiuscole e minuscole e alcuni tipi di risorse consentono la denominazione con distinzione tra maiuscole e minuscole. Considerare ad esempio la seguente istruzione:

    Un utente in Group A può accedere alle risorse nei compartimenti con la tag Operations.Project= 'sample'. L'utente può anche accedere alle risorse nei compartimenti con la tag Operations.Project= 'Sample'.

    >allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'sample'
    

  • Prendere in considerazione l'uso di valori predefiniti nelle tag definite se viene adottato il controllo dell'accesso basato su tag. Vedere Utilizzo dei valori predefiniti.

  • Tutti i servizi OCI supportano le variabili dei criteri request.principal.compartment, request.principal.group e target.resource.compartment.tag. Tuttavia, non tutti i servizi supportano la variabile del criterio target.resource.tag. Vedere Servizi supportati.

    Per le funzioni avanzate dei criteri IAM condizionali, vedere Controllo dell'accesso basato su tag e Controllo dell'accesso basato sul tempo.

Consigli per i compartimenti e le tag

Utilizzare i suggerimenti riportati di seguito durante l'impostazione di compartimenti e tag.

• Crea e designa compartimenti per categorie specifiche di risorse. Inoltre, scrivere i criteri IAM per consentire l'accesso alle risorse solo per i gruppi di utenti che richiedono l'accesso.
• Dividi i carichi di lavoro di produzione e quelli non di produzione in compartimenti separati.
• Crea e utilizza compartimenti figlio per isolare le risorse per più livelli organizzativi. Scrivere criteri separati per ogni livello di compartimento.
• Consenti solo agli utenti autorizzati di spostare i compartimenti in compartimenti padre diversi e di spostare le risorse da un compartimento a un altro. Scrivere le politiche appropriate per applicare questa restrizione.
• Limitare il numero di risorse di ogni tipo che è possibile creare in un compartimento impostando le quote a livello di compartimento.
• Limitare le risorse che un principal dell'istanza può gestire specificando un compartimento nel criterio IAM.
• Assegna tag alle risorse per organizzarle e identificarle in base alle tue esigenze aziendali.
  • Utilizza compartimenti e tag per semplificare la gestione degli accessi. Allinea la progettazione del compartimento OCI alle strutture del reparto o del progetto. Per ulteriori informazioni, vedere Gestione dei compartimenti.
  • Se viene adottato il controllo dell'accesso basato su tag, assicurarsi di disporre dei controlli appropriati per stabilire chi può applicare le tag.
  • Dopo aver applicato i criteri, tenere presente che l'applicazione di tag a un gruppo, a un utente o a una risorsa può concedere l'accesso alle risorse.
• Mantenere il minor numero possibile di compartimenti. Ciò rende meno complicata la navigazione nella console OCI.
• Non combinare con la sicurezza della rete. I compartimenti hanno un impatto limitato sul carico di lavoro effettivo.

Più ambienti

Di seguito sono riportate alcune strategie di isolamento dell'ambiente di esempio per la progettazione delle strutture dell'ambiente. La tua organizzazione potrebbe aver bisogno di una combinazione di queste strategie.

Nota: il diagramma non è un'architettura di riferimento, ma fornisce casi d'uso di esempio per la progettazione.

• Tipo 0: questo isolamento dell'ambiente non implica alcuna condivisione delle risorse. In genere si tratta della nostra struttura di tenancy per il massimo livello di isolamento delle risorse. Oltre al motivo aziendale strategico menzionato in precedenza, potrebbe essere necessario questo tipo di ambiente per supportare i processi di gestione delle modifiche. Ad esempio, potresti aver bisogno di un ambiente di test o canary per consentire al team della piattaforma cloud di implementare modifiche a livello di tenancy per evitare di introdurre enormi interruzioni ai team delle applicazioni tutto in una volta.
• Tipo 1: questo isolamento dell'ambiente condivide un numero minimo di risorse nel compartimento radice, ad esempio i criteri di abilitazione dei servizi OCI e gli amministratori con accesso non frequente. Con un compartimento dedicato e un dominio di Identity aggiuntivo, puoi avere più ambienti altamente separati all'interno di una singola tenancy che dispongono di un provider di identità, di un criterio di accesso e di risorse cloud propri.
• Tipo 2: questo isolamento dell'ambiente condivide alcuni servizi chiave selettivi, ad esempio il dominio di Identity e la connessione rapida, per migliorare l'efficienza a livello di costi e amministrazione. Viene in genere utilizzato per ambienti non di produzione, ad esempio UAT, SIT e DEV. Alcune organizzazioni accettano anche le procedure per gli ambienti di produzione e pre-produzione.
• Tipo 3: questo isolamento dell'ambiente condivide tutti i servizi della piattaforma di base, ad esempio i servizi di sicurezza e di rete. In genere viene utilizzato per gestire carichi di lavoro di natura simile con criteri di controllo comuni.
• Tipo 4: questo isolamento dell'ambiente condivide le infrastrutture dei carichi di lavoro, ad esempio middleware, OKE e DB, in più istanze dell'applicazione.

Best practice IAM

Per informazioni aggiornate sulle procedure ottimali IAM, vedere Best practice per la gestione di identità e accessi. I vantaggi includono:

• Non utilizzare il gruppo di amministratori di dominio e l'utente predefiniti con il ruolo di amministratore del dominio di Identity per le attività quotidiane. Creare invece un amministratore separato per la gestione di risorse specifiche in OCI.
• Controllare periodicamente chi fa parte del gruppo di amministratori del dominio predefinito e chi dispone del ruolo di amministratore del dominio di Identity nel dominio predefinito. Gli utenti appartenenti a questi due gruppi sono amministratori privilegiati e possono gestire tutte le risorse in OCI.
• Utilizzare il dominio predefinito come dominio iniziale. Non solo gli utenti del dominio predefinito possono accedere o gestire le risorse in OCI, ma gli utenti di un dominio secondario possono anche accedere e gestire tutte le risorse OCI.
• Crea altri domini secondari per vari casi d'uso come la segmentazione delle identità (consumatore rispetto ai dipendenti), la separazione dell'ambiente (sviluppo, test, produzione) e i requisiti di residenza dei dati (creazione di un dominio in una determinata area geografica).
• Si consiglia di utilizzare un dominio secondario per soddisfare i severi requisiti di residenza dei dati. Con i domini secondari, è possibile scegliere le aree geografiche in cui si desidera replicare un dominio.

Visualizza altro

• Migliori prassi per Identity and Access Management (IAM) nell'infrastruttura Oracle Cloud

• Isolare risorse e controllare l'accesso
• Implementazione della convenzione di denominazione per le risorse OCI mediante l'applicazione di tag