Informazioni sull'architettura e sulle best practice OCI

EU Sovereign Cloud offre ai clienti OCI le seguenti funzionalità esclusive:

• Protezione dei dati mediante protezione dei servizi e replica dei dati
• Accedi ai modelli tramite rete virtuale
• Modelli di sicurezza tramite IAM
• Audit della modellazione e della governance della conformità

Ciascuno di questi modelli fornisce meccanismi specifici che, complessivamente, offrono ai clienti le funzionalità per rafforzare la sovranità del proprio ambiente cloud.

Protezione dei dati

La protezione dei dati all'interno di EU Sovereign Cloud viene affrontata da diverse prospettive:

• Accesso: limitazione dell'accesso ai dati per impedire l'uso non autorizzato.
• Replica dei dati intracomunitari: creazione di copie dei dati in due diverse posizioni fisiche (regioni) pur rimanendo entro i confini dell'UE.
• Il percorso di replica non lascia l'UE: la connessione di replica tra le region è completamente contenuta nella trasmissione dei dati UE tra le region di EU Sovereign Cloud si verifica su una spina dorsale dedicata stabilita per EU Sovereign Cloud e non lascia l'UE durante il transito.
• Chiavi di cifratura locali: l'archiviazione e la cifratura dei dati vengono gestite tramite chiavi generate da EU Sovereign Cloud gestite all'interno dell'UE o con chiavi fornite dal cliente. Le chiavi fornite dal cliente sono memorizzate all'interno di un servizio di gestione delle chiavi (KMS) che risiede fisicamente all'interno dell'UE ed è completamente controllato dal cliente.
• Autorità di certificazione locali: con il servizio OCI Certificates, i tenant possono eseguire tutte le azioni associate all'emissione e alla gestione dei certificati. Ciò include l'importazione di un'autorità di certificazione root (CA) di terze parti che può essere distribuita internamente alle risorse all'interno di EU Sovereign Cloud, senza attraversare Internet. Questi certificati possono quindi essere applicati a SSL e altri usi per stabilire una crittografia forte e verificabile localmente tra i siti.

Introduzione alla protezione dei dati

Per iniziare a utilizzare i metodi di protezione dei dati, effettuare le operazioni riportate di seguito.

• Utilizza Oracle Cloud Stacks per creare un'infrastruttura standardizzata in due aree dati EU Sovereign Cloud.
• Crea un collegamento tra più aree per l'infrastruttura utilizzando i gateway di instradamento dinamico (DRG) per connettere le reti regionali in modo sicuro.
• Stabilisci la replica tra entrambi i siti utilizzando strumenti quali Data Guard, replica tra più aree dello storage degli oggetti e strumenti di replica basati su applicazioni per proteggere i dati ospitati nel cloud sovrano dell'UE.
• Crea un vault OCI all'interno del cloud sovrano dell'UE per scoprire segreti e chiavi fondamentali e replica il vault nella seconda area dati.
• Caricare i certificati nel servizio OCI Certificates e utilizzare l'endpoint del servizio per il caricamento e la convalida dei certificati.

Replica dati in un'altra posizione

Una delle strategie più comuni per garantire la protezione dei dati è quella di replicare i dati in un'altra posizione per lo storage a lungo termine utilizzando un sito caldo / caldo.

Idealmente, la replica avviene su un collegamento il più diretto possibile alla fonte e potrebbe essere utilizzata sia per la protezione dei dati che per le comunicazioni tra siti per ottimizzare il costo del collegamento. Nel caso dell'UE, il collegamento dati stesso non dovrebbe avere un percorso che consenta ai dati di uscire dall'UE.

Descrizione dell'immagine mad-fra-region.png

mad-fra-region-oracle.zip

EU Sovereign Cloud offre meccanismi di protezione dei dati e servizi OCI che possono aiutarti a soddisfare i requisiti di replica e transito dei dati. Oracle ha stabilito le region di dati EU Sovereign Cloud con parità di servizio che ti consente di eseguire il mirroring dell'implementazione sia dello storage che delle applicazioni. Lo storage e le applicazioni possono essere replicati nell'altra area dati di EU Sovereign Cloud tramite un collegamento backbone dedicato, con la certezza che le funzionalità e i servizi disponibili sono gli stessi. Questa spina dorsale dedicata viene utilizzata anche per il traffico di gestione tra le region di EU Sovereign Cloud e una grande parte della larghezza di banda è disponibile per l'uso da parte dei tenant all'interno di EU Sovereign Cloud. In tutti i casi, il traffico dati dei clienti che scorre su questa spina dorsale è isolato da altri realm e da altre aree che non fanno parte di EU Sovereign Cloud.

Cifra dati

La cifratura dei dati e/o la memorizzazione delle chiavi di cifratura utilizzate per vari scopi all'interno di un determinato sistema sono anche aspetti critici delle strategie di protezione dei dati. Oracle offre una soluzione KMS localizzata che gestisce le chiavi che possono essere utilizzate per la cifratura dello storage dei dati all'interno di EU Sovereign Cloud e memorizza le chiavi che possono essere recuperate a livello di programmazione per l'uso all'interno delle applicazioni o, ad esempio, nei meccanismi di cifratura dei dati a livello di istanza.

Il servizio OCI Vault fornisce questa funzione. Vault può essere implementato come un KMS basato su software multi-tenant o come moduli HSM dedicati. In entrambi i casi, Vault si trova esclusivamente all'interno del realm del cloud sovrano per l'UE e Oracle non ha la possibilità di accedere alle chiavi o ai segreti memorizzati nel vault software o nell'HSM dedicato. Le attività di crittografia dei dati si trovano anche esclusivamente all'interno dell'EU Sovereign Cloud, con ogni region che mantiene la propria implementazione indipendente del Vault. Gli algoritmi di cifratura delle chiavi supportati da OCI Vault includono l'Advanced Encryption Standard (AES), l'algoritmo Rivest-Shamir-Adleman (RSA) e l'algoritmo di firma digitale della curva ellittica (ECDSA). I clienti possono creare e utilizzare chiavi simmetriche AES e chiavi asimmetriche RSA per la cifratura e la decifrazione oppure utilizzare chiavi asimmetriche RSA o ECDSA per la firma dei messaggi digitali.

Cifra connessioni ai consumer di dati

È anche importante considerare non solo la crittografia dei dati in archivio, ma anche la capacità di crittografare le connessioni ai consumatori di dati, in particolare su protocolli come HTTPS.

In molti casi, i certificati x.509 vengono gestiti tramite origini esterne o tramite server dedicati che generano certificati locali da utilizzare internamente. EU Sovereign Cloud offre il servizio OCI Certificates che consente ai clienti di creare certificati locali per applicazioni interne ed esterne, importare bundle di certificazioni di terze parti per la distribuzione e gestire le certificazioni installate nel servizio, come la rotazione delle chiavi. Tutti i task associati alla gestione dei certificati (aggiunta, rotazione, eliminazione e così via) possono essere eseguiti da un servizio centrale interamente situato all'interno di EU Sovereign Cloud.

Integrazione con OCI Load Balancer

L'integrazione con il servizio OCI Load Balancer consente ai clienti di associare senza problemi un certificato TLS emesso o gestito da OCI Certificates alle risorse che richiedono certificati. Le applicazioni o i server non integrati con il servizio Certificati possono fornire una struttura API per recuperare i certificati ritenuti appropriati dai criteri IAM della tenancy. La centralizzazione dei certificati in una fonte affidabile basata sull'UE offre la possibilità di gestire i certificati a livello locale e garantisce che i clienti all'interno di EU Sovereign Cloud possano localizzare la crittografia all'interno dell'UE.

Modello di accesso

I meccanismi già integrati nell'architettura OCI consentono inoltre a EU Sovereign Cloud di fornire un efficace filtro dei pacchetti di rete, controlli degli accessi, connettività diretta e, in definitiva, un modo efficace per limitare l'accesso alle risorse e alle applicazioni distribuite solo agli indirizzi di rete situati nell'UE.

Introduzione al modello di accesso

Per iniziare a implementare rapidamente un modello di accesso, effettuare le operazioni riportate di seguito.

• Implementa un progetto di rete cloud virtuale (VCN) utilizzando un approccio di difesa approfondita. Utilizzare le subnet pubbliche nella VCN solo se necessario per l'accesso esterno.
• Creare una DMZ per filtrare il traffico utilizzando subnet pubbliche e private.
• Utilizza il servizio OCI Network Firewall (NFW) per controllare e monitorare l'accesso alle subnet critiche, incluse tutte quelle pubbliche.
• Crea liste di sicurezza per subnet per limitare l'accesso intra-subnet.
• Implementa i gruppi di sicurezza di rete (NSG) in ogni istanza/endpoint per controllare strettamente la fonte di accesso.
• Abilita periodicamente i log di flusso della VCN per eseguire l'audit del traffico.
• Implementa il DNS (Domain Name System) OCI per controllare la risoluzione degli indirizzi e filtrare i domini DNS indesiderati senza influire su quelli accettati.
• Utilizzare le connessioni punto, ad esempio FastConnect e Configurazione CPE, per stabilire backhauls amministrativi che non utilizzano la rete Internet pubblica.

Uso di liste di sicurezza, gruppi di sicurezza di rete e firewall di rete

Le funzionalità dei servizi OCI nativi come NFW (Network Firewall), SL (Security Lists) e NSG (Network Security Groups), combinati con i log di flusso della rete cloud virtuale (VCN), forniscono efficaci meccanismi per prevenire e rilevare gli accessi da punti di origine non appartenenti all'Unione Europea.

Uno dei metodi principali per garantire che gli intervalli specifici dell'UE di indirizzi IP pubblici abbiano accesso alle risorse è l'utilizzo di una combinazione di SL, NSG e NFW. In background, tutti gli accessi alle istanze/risorse collegate alle subnet OCI sono "deny all" per impostazione predefinita. Questo criterio impedisce anche l'intercomunicazione delle istanze nella stessa subnet. L'accesso deve essere concesso in modo esplicito per avviare e rispondere alle connessioni in base alle risorse all'interno di una determinata subnet o tra subnet nella VCN. Il modo principale per farlo è attraverso SL. Si tratta di definizioni a livello di subnet della connettività consentita che è possibile specificare in base all'intervallo di protocolli, porte e CIDR. Le connessioni che non rientrano negli intervalli definiti vengono eliminate in silenzio. I gruppi NSG eseguono alcuni degli stessi task, ma vengono applicati al livello VNIC (Virtual NIC) e non alla subnet nel suo complesso. Utilizzando una combinazione di SL e NSG, un cliente EU Sovereign Cloud può creare una zona soggetta a restrizioni di accesso alle risorse che accetta solo indirizzi di determinati intervalli di IP pubblici dell'UE. Se il cliente estende tali limiti a singole risorse, ad esempio load balancer, istanze di computazione, bastion e così via, è possibile implementare un pattern di accesso mirato per soddisfare le esigenze dell'organizzazione. Infine, i gruppi NSG e SL sono bidirezionali, il che significa che sia le regole di connettività interna che esterna possono essere stabilite indipendentemente l'una dall'altra. Con questa funzione, anche se viene effettuata una connessione in entrata, sia per progettazione che per una configurazione errata delle regole in entrata, la connessione esterna deve ancora essere consentita per poter stabilire l'intera sessione.

Implementare una "porta anteriore" per le risorse su VCN

EU Sovereign Cloud offre anche un servizio firewall di rete basato su Palo Alto che consente l'implementazione di una varietà di servizi e restrizioni come "porta d'ingresso" per le risorse presenti sulle reti VCN, come ad esempio:

• Filtro di rete con conservazione dello stato

  Il filtro di rete con conservazione dello stato crea regole di filtro di rete con conservazione dello stato che consentono o negano il traffico di rete in base all'IP di origine (IPv4 e IPv6), all'IP di destinazione (IPv4 e IPv6), alla porta e al protocollo.

• Filtro URL personalizzato e FQDN

  Il filtro URL personalizzato e FQDN limita il traffico in entrata e in uscita a una lista specificata di nomi di dominio completamente qualificati (FQDN), inclusi caratteri jolly e URL personalizzati.

• IDPS (Intrusion Detection and Prevention)

  L'IDPS (Intrusion Detection and Prevention) monitora la rete per rilevare attività dannose e impedisce al traffico di rete sospetto di raggiungere la rete interna.

• Ispezione SSL

  L'ispezione SSL decifra e ispeziona il traffico cifrato TLS con il supporto ESNI per rilevare le vulnerabilità della sicurezza. Encrypted Server Name Indication (ESNI) è un'estensione TLSv1.3 che cifra l'indicazione SNI (Server Name Indication) nell'handshake TLS.

• Ispezione del traffico della subnet Intra-VCN

  L'ispezione del traffico della subnet intra-VCN instrada il traffico tra due subnet VCN tramite un firewall di rete.

• Ispezione del traffico tra VCN

  L'ispezione del traffico tra le VCN instrada il traffico tra due VCN tramite un firewall di rete.

Descrizione della figura access-model-arch.png

access-model-arch-oracle.zip

Nel diagramma sopra, ci sono cinque scenari:

1. L'NFW rifiuta la connessione in base al set di regole definito dal cliente e il tentativo di connessione viene registrato.
2. Il NFW accetta la connessione e instrada la connessione all'istanza appropriata nella subnet protetta. SL consente questa connessione da questa subnet e il gruppo NSG sull'istanza dispone di una regola che consente le connessioni da NFW.
3. L'istanza nella subnet A tenta una connessione a un'istanza. Mentre SL consente le connessioni dalla subnet A, il gruppo NSG dell'istanza impedisce la connessione.
4. L'istanza nella subnet A tenta un'altra connessione a un'istanza diversa. Qui, sia la SL che la NSG consentono la connessione
5. L'istanza nella subnet B tenta una connessione a un'istanza. Alla subnet B non è stato concesso l'accesso alla subnet protetta, pertanto non è consentita alcuna connessione, indipendentemente dal gruppo NSG dell'istanza.

Controllo e determinazione della risoluzione appropriata dei nomi

Inoltre, la capacità di controllare e determinare le fonti di risoluzione dei nomi appropriate è un meccanismo in grado di determinare la connettività e fornire la risoluzione dei nomi e il relay in modo deterministico agli endpoint DNS definiti.

L'ambiente EU Sovereign Cloud eredita il servizio DNS OCI, consentendoti di controllare rigorosamente entrambi gli endpoint utilizzati all'interno di EU Sovereign Cloud, nonché le fonti a cui vengono inoltrate le richieste. Il servizio DNS OCI esegue questa operazione suddividendo l'endpoint del listener DNS dall'inoltro, con un motore di regole incorporato tra i due. Ciò consente di definire regole set sulla direzione delle richieste DNS, potenzialmente a diversi inoltratori in base al dominio richiesto. La richiesta di lookup del dominio che si ritiene sia al di fuori del set di regole o la selezione di più inoltratori che puntano a origini DNS diverse, a seconda del risultato del modulo di gestione delle regole, restituirà la risposta NX_DOMAIN per reindirizzamenti nulli mirati. I clienti possono essere molto consapevoli della risposta alla risoluzione DNS sia del cloud sovrano interno dell'UE che del cloud sovrano esterno dell'UE e fornire un meccanismo di filtro.

Descrizione dell'immagine valid-vs-invalid-dns-request.png

valid-vs-invalid-dns-request-oracle.zip

Offri ai clienti del cloud sovrano dell'UE un accesso all'ambiente meno limitato

I clienti EU Sovereign Cloud potrebbero avere un accesso all'ambiente meno limitato rispetto ai consumatori pubblici dei servizi forniti dai proprietari di tenancy EU Sovereign Cloud. Questo tipo di accesso viene eseguito dagli stessi tipi di connessione diretta presenti nel cloud pubblico OCI.

• FastConnect

  FastConnect è un collegamento MPLS (Multiprotocol Label Switch) diretto ai punti di presenza del cloud sovrano dell'UE. Questi collegamenti non sono condivisi con nessun altro consumatore di EU Sovereign Cloud e sono dedicati alla particolare tenancy a cui sono assegnati

• Customer Premises Equipment (CPE)

  CPE è un modello di connettività VPN che consente ai clienti di implementare una connettività privata a larghezza di banda inferiore, in stile ufficio remoto, a EU Sovereign Cloud senza dover investire nell'infrastruttura necessaria per i collegamenti MPLS dedicati.

Mentre le connessioni sono dirette, tutti i meccanismi di controllo degli accessi rimangono in vigore. Pertanto, la connettività su un collegamento FastConnect è ancora soggetta ai set di regole definiti da SL e NSG e può essere monitorata da NFW con regole diverse, basate sull'origine o sulle destinazioni della connessione, rispetto a quelle applicate alle risorse pubbliche. L'uso di uno o entrambi questi tipi di connessione consente ai tenant EU Sovereign Cloud di stabilire una connettività diversa e la combinazione dei metodi di controllo dell'accesso (SL, NSG) e NFW fornisce un meccanismo per controllare e monitorare strettamente l'accesso alle risorse dell'ambiente.

Queste funzionalità di accesso consentono agli utenti di EU Sovereign Cloud di creare "giardini murati" di risorse da utilizzare esclusivamente all'interno dell'UE, come mostrato qui:

Descrizione dell'immagine walled-garden.png

giardino-murato-oracle.zip

La rete NFW fornisce il supporto di primo livello per il rilevamento, il rifiuto e la registrazione dell'accesso, mentre le librerie forniscono una restrizione di secondo livello per l'accesso alle risorse all'interno di una determinata sottorete. I gruppi NSG limitano ulteriormente l'accesso in base alla risorsa. Sia gli SL che i gruppi NSG possono avere set di regole bidirezionali che limiterebbero gli intervalli di indirizzi IP/porte in uscita. In questo caso particolare, tuttavia, i dati, la manutenzione e l'amministrazione verranno forniti alla risorsa tenant tramite la connessione FastConnect, anch'essa limitata dalle librerie SL e dai gruppi NSG. I set di regole definiti all'interno di entrambe le funzioni si applicano anche alle connessioni tramite FastConnect. La risoluzione delle connessioni in uscita, sia per l'avvio che per convalidare l'appartenenza al dominio delle connessioni in entrata, viene eseguita tramite una combinazione di listener/forwarder DNS che puntano a origini di risoluzione DNS specifiche. Insieme, queste funzionalità consentono la creazione di un portale di servizi di accesso pubblico e controllato, con gestione e manutenzione dei dati eseguiti "fuori banda" e limitati all'UE.

Modello di sicurezza

OCI utilizza il servizio Identity and Access Management (IAM) per fornire sicurezza sulla gestione "del cloud". IAM si concentra sul garantire che gli operatori delle tenancy all'interno di un determinato realm possano essere limitati nelle loro azioni all'interno della tenancy.

Introduzione al modello di sicurezza

Per iniziare a utilizzare il modello di sicurezza, effettuare le operazioni riportate di seguito.

• Crea modelli di accesso alla sicurezza per "gestire il cloud" rispetto a quelli necessari per "gestire il cloud". Crea un numero limitato di utenti sicuri in Identity and Access Management (IAM) per la gestione del cloud.
• Implementare la federazione delle identità per unificare l'accesso organizzativo. Utilizza gruppi separati per EU Sovereign Cloud all'interno della federazione per limitare l'accesso alle persone con sede nell'UE.
• Mantieni le identità uniche tra gli account IAM EU Sovereign Cloud e non EU Sovereign Cloud. Ciò riduce la confusione degli amministratori durante l'amministrazione degli ambienti.
• Crea compartimenti OCI per le risorse di cui è stato eseguito il provisioning in base ai limiti funzionali e organizzativi.
• Creare domini di Identity per le organizzazioni secondarie in modo da amministrare autonomamente gli ambienti locali.
• Crea un ambiente "sub-sovereign cloud" (sub-SC) con Cloud Guard per monitorare i criteri IAM.

Informazioni sul modello di sicurezza

Il servizio IAM non viene utilizzato dal personale OCI e non è disponibile durante alcuna fase delle operazioni cloud. Tutte le azioni limitate da IAM vengono applicate a livello di tenancy. Sebbene il personale OCI utilizzi un sistema di gestione delle identità e degli accessi per gestire il piano di controllo, non fornisce alcun accesso di gestione o operativo direttamente alle tenancy dei clienti.

Descrizione dell'immagine security_structure_overview.png

security_structure_overview-oracle.zip

IAM si estende solo al realm in cui esiste la tenancy stessa. In questo caso particolare, EU Sovereign Cloud opera all'interno di un unico realm attualmente costituito da regioni fisicamente situate all'interno dell'UE. Pertanto, qualsiasi account creato all'interno delle tenancy EU Sovereign Cloud può operare solo sulla gestione delle risorse all'interno del realm stesso e può operare solo sulle risorse all'interno dell'UE. Gli account utente non dispongono di contesto esterno al realm e, anche se un utente dispone di credenziali utente identiche in un altro realm, non esiste un contesto in entrata all'interno di EU Sovereign Cloud.

Gli account operativi EU Sovereign Cloud sono completamente isolati all'interno del realm. La combinazione dell'architettura dei realm di OCI, del supporto e delle operazioni residenti nell'UE e della struttura della persona giuridica dell'UE applica in modo nativo l'isolamento del realm del cloud sovrano dell'UE. Non è necessaria alcuna configurazione aggiuntiva per l'utente finale per garantire che EU Sovereign Cloud funzioni indipendentemente da altri realm OCI.

Descrizione dell'immagine iam-2-user.png

iam-2-utente-oracle.zip

IAM offre sia account locali, gestiti all'interno del realm, sia account federati collegati a Identity Cloud Service (IDCS) o ad altri meccanismi di federazione SAML2. L'accesso ai componenti di distribuzione e gestione della tenancy EU Sovereign Cloud può essere strettamente controllato e consente solo agli account sottoposti a verifica in base all'UE di gestire l'ambiente. Inoltre, poiché si tratta di un sistema di gestione degli account federato, è possibile utilizzare la stessa federazione utilizzata per EU Sovereign Cloud per accedere alle risorse di calcolo distribuite all'interno della tenancy. Ciò significa creare un ambiente unificato in cui sia possibile distribuire un metodo di accesso completamente verificabile sia nella gestione "del cloud" che nelle risorse "nel cloud".

Descrizione dell'immagine idp-vs-iam.png

idp-vs-iam-oracle.zip

Oltre alle funzionalità degli account federati, EU Sovereign Cloud offre la possibilità di creare domini di Identity (ID) all'interno della tenancy. Un ID è essenzialmente il partizionamento dello spazio IAM, con un set secondario di amministratori designati che non hanno visibilità nel livello superiore del dominio e possono creare un proprio set di criteri di accesso e controllare le proprie risorse. Il proprietario di livello superiore della tenancy può comunque influenzare il controllo sulla risorsa complessiva e sull'amministrazione IAM. La combinazione dell'ID con un compartimento di livello superiore (non radice) consentirebbe ai membri di un ID di creare un ambiente completo che non conosce nessuno degli ambienti che lo circondano. Con questa serie di strumenti, un'organizzazione all'interno dell'UE potrebbe creare quello che chiameremo un ambiente "sub-SC". Vale a dire, un ambiente che mantiene le proprietà della tenancy originale, ma consente la creazione di un ambiente secondario con i propri criteri e restrizioni di appartenenza.

Il concetto di sottoSC è descritto ulteriormente nei casi di studio illustrativi di seguito. L'ambiente sub-SC può anche essere limitato, controllato e controllato implementando Cloud Guard nella tenancy. Quando viene applicato in questa situazione, Cloud Guard può impedire ai compartimenti assegnati a un determinato SC secondario e controllati da un set di utenti definiti all'interno di un dominio di Identity di eseguire azioni che sarebbero contrarie a garantire la protezione continua dei dati ospitati e/o di eseguire azioni che violerebbero i criteri di sicurezza all'interno dell'ambiente. Oltre a Cloud Guard, EU Sovereign Cloud offre Security Zones, che forniscono set di criteri templati e mirati ai compartimenti che possono essere applicati in modo uniforme. Le zone di sicurezza possono essere implementate e vengono spesso implementate per aumentare le configurazioni Cloud Guard.

L'inventario dei servizi State, Content e EU Sovereign Cloud non viene pubblicizzato in alcun modo al di fuori del realm.

Audit e governance

Le funzionalità e le funzionalità di EU Sovereign Cloud forniscono misure attive per garantire che il personale con sede nell'UE gestisca l'ambiente e che i dati siano protetti e rimangano all'interno dell'UE. Tuttavia, senza meccanismi per rivedere tali misure e documentare la conformità, è difficile fornire garanzie a entità esterne.

Introduzione all'audit e alla governance

Per iniziare a utilizzare le attività di audit e governance, effettuare le operazioni riportate di seguito.

• Utilizza il servizio di audit OCI per monitorare e generare azioni di applicazione dei modelli di governance e compliance.
• Implementare il servizio OCI Logging Analytics per eseguire l'analitica avanzata sui dati generati dal servizio OCI Audit.
• Crea criteri utilizzando Threat Intelligence e Cloud Guard per prevenire in modo proattivo le azioni e l'accesso da parte di attori indesiderati.
• Utilizza il servizio di applicazione tag OCI per creare uno spazio di nomi tag corrispondente alla struttura organizzativa e/o ai modelli di costo. Contrassegnare tutte le risorse con coppie chiave/valore dagli spazi di nomi per l'audit e/o il riaddebito.
• Impostare le quote all'interno delle tenancy e dei compartimenti per evitare il consumo delle risorse in fase di esecuzione.
• Utilizza i servizi OCI Budgets and Cost Analysis per prevedere, monitorare e controllare i costi.

Informazioni su servizi e funzioni per il monitoraggio del rispetto dei requisiti di sovranità dei dati

OCI offre servizi e funzionalità aggiuntivi che i clienti possono utilizzare per monitorare il rispetto dei requisiti di sovranità dei dati della tua organizzazione. I controlli e la gestione dei costi possono essere utilizzati come strumento per verificare la conformità alla spesa delle risorse, rilevare le minacce e garantire che le tenancy rimangano entro specifiche stabilite.

I seguenti servizi OCI possono essere utilizzati in EU Sovereign Cloud per implementare strategie di audit e governance:

• Audit

  OCI Audit registra il tempo, l'origine, il target e il tipo di azione per i servizi OCI disponibili nel cloud sovrano dell'UE. Attività quali la creazione di istanze di computazione, le operazioni VCN e altre vengono registrate affinché le persone designate possano monitorare e sottoporre a audit l'ambiente impostato in EU Sovereign Cloud.

• Logging Analytics

  Questa funzione consente al cliente di acquisire i log raccolti utilizzando il servizio di audit e creare viste e visualizzazioni diverse per soddisfare i requisiti organizzativi. È inoltre possibile includere log di altre origini per fornire una visione completa dell'ambiente per l'audit e l'analisi completi.

• Informazioni sulle minacce (con Cloud Guard)

  Threat Intelligence riceve input da varie origini e gestisce i dati per fornire linee guida da cui intraprendere azioni per il rilevamento e la prevenzione delle minacce in Cloud Guard e in altri servizi OCI. Cloud Guard ti consente di implementare azioni standardizzate ("ricette") in grado di rispondere in modo proattivo a potenziali minacce.

• Definizione tag

  Mentre le voci precedenti sono meccanismi attivi per prevenire, rilevare e agire sulle minacce attive, altri elementi di controllo e conformità si concentrano sul monitoraggio dell'utilizzo e dei costi. EU Sovereign Cloud offre meccanismi per assegnare tag alle risorse al momento del provisioning e per correggere i valori e il formato delle tag prima dell'assegnazione. È possibile eseguire query su queste tag tramite l'API, generare report nella registrazione e nella fatturazione dei costi e agire utilizzando i criteri IAM associati a risorse e istanze specifiche. Utilizza l'applicazione di tag per assegnare più tag alla stessa risorsa ed esaminare il consumo di risorse da più prospettive. Ad esempio, una risorsa di calcolo può avere una tag che indica l'uso generale della risorsa, un gruppo che utilizza la risorsa (ad esempio, sviluppo), un centro di costo per la risorsa o qualsiasi altra dimensione che potrebbe essere di interesse.

• Quota compartimento

  È possibile impostare le quote di risorse in base al compartimento in cui si trova la risorsa. Le quote possono limitare il numero e/o l'ambito della risorsa definita nella definizione della quota a un determinato compartimento, area o AD.

• Budget

  I budget sono uno strumento che consente ai clienti di impostare avvisi in base a un limite di spesa corrente, a un massimale di spesa predittivo o a entrambi, in base all'intento dell'avviso. Basa gli avvisi di budget sulle tag di registrazione dei costi, sul compartimento, sulla risorsa o su entrambi.

• Analisi costi

  Lo strumento Analisi costi consente di suddividere i costi di consumo correnti tra le dimensioni. Visualizza i costi attraverso una combinazione di vettori quali tenancy, region cloud sovrano per l'UE, compartimenti e tag delle risorse, nonché su risorse, servizi e SKU specifici consumati. I report possono essere filtrati in base alle singole risorse, se applicabile. Questo strumento consente inoltre di prevedere l'utilizzo futuro in base ai modelli di consumo passati. I dati sono estendibili ai dashboard e accessibili tramite le API. È inoltre possibile schedulare un report dei costi in modo che venga eseguito con cadenza regolare e consegnare i risultati a un bucket dell'area di memorizzazione degli oggetti. Questi report possono essere memorizzati per riferimento cronologico ed esportati in un data warehouse per l'analisi e l'elaborazione delle tendenze a lungo termine.