Controllo dell'accesso in Autonomous Database sull'infrastruttura Exadata dedicata

Quando si configura Autonomous Database su un'infrastruttura Exadata dedicata, è necessario assicurarsi che gli utenti cloud abbiano accesso a utilizzare e creare solo i tipi di risorse cloud appropriati per eseguire le proprie attività lavorative. Inoltre, devi assicurarti che solo il personale e le applicazioni autorizzati abbiano accesso ai database autonomi creati su un'infrastruttura dedicata. In caso contrario, corri il rischio di un consumo "irrequieto" delle risorse dedicate dell'infrastruttura o di un accesso inappropriato ai dati mission-critical.

Prima di iniziare a creare e utilizzare le risorse cloud che forniscono la funzione di infrastruttura dedicata, è necessario formulare un piano di controllo dell'accesso e quindi istituire creando le risorse IAM (Identity and Access Management) e di rete appropriate. Di conseguenza, il controllo dell'accesso all'interno di un Autonomous Database viene implementato a vari livelli:
  • Oracle Cloud User Access Control
  • Controllo dell'accesso client
  • Controllo dell'accesso utente al database

Argomenti correlati

Controllo dell'accesso degli utenti Oracle Cloud

Puoi controllare l'accesso degli utenti Oracle Cloud nella tua tenancy alle risorse cloud che compongono la distribuzione di Autonomous Database sull'infrastruttura Exadata dedicata.

Utilizzare il servizio Identity and Access Management (IAM) per assicurarsi che gli utenti cloud abbiano accesso per creare e utilizzare solo i tipi appropriati di risorse di Autonomous Database per eseguire le proprie attività lavorative. Per istituire controlli dell'accesso per gli utenti cloud, definire criteri che concedono a gruppi specifici di utenti diritti di accesso specifici a tipi specifici di risorse in compartimenti specifici.

Il servizio IAM offre diversi tipi di componenti che consentono di definire e implementare una strategia di accesso utente cloud sicura:

  • Compartimento: raccolta di risorse correlate. I compartimenti sono un componente fondamentale di Oracle Cloud Infrastructure per organizzare e isolare le tue risorse cloud.

  • Gruppo: raccolta di utenti che hanno tutti bisogno dello stesso tipo di accesso a un determinato set di risorse o compartimento.

  • Gruppo dinamico: tipo speciale di gruppo che contiene risorse che corrispondono alle regole definite dall'utente. Pertanto, l'appartenenza può cambiare in modo dinamico quando vengono create o eliminate risorse corrispondenti.

  • Criterio: gruppo di istruzioni che specificano chi può accedere alle risorse e come. L'accesso viene concesso a livello di gruppo e compartimento. Ciò significa che si scrive un'istruzione dei criteri che fornisce a un gruppo specifico un tipo specifico di accesso a un tipo specifico di risorsa all'interno di un compartimento specifico.

Istruzioni criteri e criteri

Lo strumento principale utilizzato per definire il controllo dell'accesso per gli utenti cloud è il criterio, una risorsa IAM (Identity and Access Management) contenente istruzioni dei criteri che specificano l'accesso in termini di "Chi", "Come", "Cosa" e "Dove".

Il formato di un'istruzione criterio è:
Allow 
  group <group-name> 
  to <control-verb> 
  <resource-type> 
  in compartment <compartment-name>

  • group <group-name> specifica "Chi" fornendo il nome di un gruppo IAM esistente, una risorsa IAM a cui è possibile assegnare singoli utenti cloud.

  • to <control-verb> specifica il "Come" utilizzando uno dei seguenti verbi di controllo predefiniti:

    • inspect: la possibilità di elencare le risorse del tipo specificato, senza accesso a informazioni riservate o metadati specificati dall'utente che potrebbero far parte di tale risorsa.
    • read: inspect oltre alla possibilità di ottenere i metadati specificati dall'utente e la risorsa effettiva.
    • use: read più la possibilità di utilizzare le risorse esistenti, ma non di crearle o eliminarle. Inoltre, "lavora con" significa operazioni diverse per diversi tipi di risorse.
    • manage: tutte le autorizzazioni per il tipo di risorsa, comprese la creazione e l'eliminazione.

    Nel contesto della funzione di infrastruttura dedicata, un amministratore della flotta può manage container database autonomi, mentre un amministratore del database può solo use creare database autonomi.

  • <resource-type> specifica il "Cosa" utilizzando un tipo di risorsa predefinito. Di seguito sono riportati i valori del tipo di risorsa per le risorse dell'infrastruttura dedicata.

    • exadata-infrastructures
    • autonomous-container-databases
    • autonomous-databases
    • autonomous-backups

    Poiché le risorse dell'infrastruttura dedicata utilizzano le risorse di rete, alcune delle istruzioni dei criteri create faranno riferimento al valore del tipo di risorsa virtual-network-family. Inoltre, è possibile creare istruzioni dei criteri che fanno riferimento al valore del tipo di risorsa tag-namespaces se nella tenancy viene utilizzata l'applicazione di tag.

  • in compartment <compartment-name> specifica il "Dove" fornendo il nome di un compartimento IAM esistente, una risorsa IAM in cui vengono create le risorse. I compartimenti sono un componente fondamentale di Oracle Cloud Infrastructure per organizzare e isolare le risorse cloud.

Per i dettagli dei criteri per Autonomous Database, fare riferimento ai criteri IAM per Autonomous Database sull'infrastruttura Exadata dedicata.

Per informazioni sul funzionamento del servizio IAM e dei relativi componenti e su come utilizzarli, vedere Panoramica di Oracle Cloud Infrastructure Identity and Access Management. Per risposte rapide alle domande più comuni su IAM, consulta le domande frequenti su Identity and Access Management.

Best practice per la pianificazione e l'istituzione dei controlli degli accessi

Quando pianifichi e istituisci i controlli dell'accesso per la funzione di infrastruttura dedicata, dovresti prendere in considerazione queste best practice.

  • Crea una VCN separata che contenga solo subnet private. In quasi tutti i casi, i database autonomi creati su infrastrutture dedicate ospitano dati sensibili all'azienda e normalmente accessibili solo dall'interno della rete privata dell'azienda. Anche i dati condivisi con partner, fornitori, consumatori e clienti vengono messi a loro disposizione attraverso canali regolamentati e sicuri.

    Pertanto, l'accesso alla rete fornito a tali database dovrebbe essere privato della tua azienda. Puoi assicurarti questo risultato creando una VCN che utilizza subnet private e una VPN IPSec VPN o FastConnect per connetterti alla rete privata della tua azienda. Per informazioni sull'impostazione di tale configurazione, vedere Scenario B: Private Subnets with a VPN nella Documentazione di Oracle Cloud Infrastructure.

    Per ulteriori informazioni sulla protezione della connettività di rete ai database, vedere Modalità di protezione della rete nella documentazione di Oracle Cloud Infrastructure.

  • Creare almeno due subnet. È necessario creare almeno due subnet: una per le risorse del cluster VM Autonomous Exadata e dell'Autonomous Container Database e una per le risorse associate ai client e alle applicazioni di Autonomous Database.

  • Creare almeno due compartimenti. È necessario creare almeno due compartimenti: uno per l'infrastruttura Exadata, il cluster VM Autonomous Exadata e le risorse Autonomous Container Database e uno per le risorse Autonomous Database.

  • Creare almeno due gruppi. È necessario creare almeno due gruppi: uno per gli amministratori della flotta e uno per gli amministratori del database.

Controllo dell'accesso client

Il controllo dell'accesso client viene implementato in Autonomous Database controllando il controllo dell'accesso di rete e le connessioni client.

Controllo dell'accesso di rete

Il controllo dell'accesso di rete ai database autonomi viene definito quando si imposta e si configura la distribuzione dedicata di Oracle Autonomous Database. Il modo in cui si esegue questa operazione dipende dal fatto che la distribuzione dedicata sia in Oracle Public Cloud o Exadata Cloud@Customer:

  • In Oracle Public Cloud è possibile definire il controllo dell'accesso di rete utilizzando i componenti del servizio di networking. Puoi creare una rete cloud virtuale (VCN) contenente subnet private in cui i database autonomi sono accessibili dalla rete. Inoltre, puoi creare regole di sicurezza per consentire un particolare tipo di traffico in entrata o in uscita agli indirizzi IP di una subnet.

    Per informazioni dettagliate sulla creazione di queste risorse, eseguire Lab 1: Prepare Private Network for OCI Implementation in Oracle Autonomous Database Dedicated for Fleet Administrators.

  • In Exadata Cloud@Customer, definire i controlli di accesso alla rete specificando una rete client all'interno del data center e registrandola in una risorsa di rete cluster VM all'interno della risorsa dell'infrastruttura Exadata.

Zero Trust Packet Routing (ZPR)

SI APPLICA A: Applicabile solo Oracle Public Cloud

Oracle Cloud Infrastructure Zero Trust Packet Routing (ZPR) protegge i dati sensibili da accessi non autorizzati tramite criteri di sicurezza basati su intenti scritti per le risorse, ad esempio un cluster VM Exadata Autonomous (AVMC) a cui si assegnano gli attributi di sicurezza.

Gli attributi di sicurezza sono etichette utilizzate da ZPR per identificare e organizzare le risorse. ZPR applica i criteri a livello di rete ogni volta che viene richiesto l'accesso, indipendentemente dalle potenziali modifiche o configurazioni errate dell'architettura di rete. ZPR si basa sulle regole del gruppo di sicurezza di rete (NSG) e della lista di controllo di sicurezza (SCL) esistenti. Affinché un pacchetto raggiunga una destinazione, deve superare tutte le regole NSG e SCL e i criteri ZPR. La richiesta viene eliminata se una regola o un criterio NSG, SCL o ZPR non consente il traffico.

È possibile proteggere le reti con ZPR in tre passaggi:

  1. Creare gli artifact ZPR, ovvero spazi dei nomi degli attributi di sicurezza e attributi di sicurezza.

  2. Scrivere i criteri ZPR per connettere le risorse utilizzando gli attributi di sicurezza. ZPR utilizza un linguaggio ZPL (ZPR Policy Language) e applica limitazioni all'accesso alle risorse definite. In qualità di cliente di Autonomous Database on Dedicated Exadata Infrastructure, puoi scrivere criteri basati su ZPL nella tua tenancy per assicurarti che i dati provenienti da AVMC siano accessibili solo da utenti e risorse autorizzati.

  3. Assegnare gli attributi di sicurezza alle risorse per abilitare i criteri ZPR.

Nota

Evita di inserire informazioni riservate durante l'assegnazione di descrizioni, tag, attributi di sicurezza o nomi descrittivi alle risorse cloud tramite la console di Oracle Cloud Infrastructure, l'API o l'interfaccia CLI.

Per ulteriori informazioni, consulta la Guida introduttiva a Zero Trust Packet Routing.

Per applicare gli attributi di sicurezza ZPR a un AVMC, sono disponibili le opzioni riportate di seguito.

Per aggiungere correttamente gli attributi di sicurezza ZPR a un AVMC, è necessario definire i criteri IAM riportati di seguito.

allow group <group_name>
to { ZPR_TAG_NAMESPACE_USE, SECURITY_ATTRIBUTE_NAMESPACE_USE }
in tenancy
allow group <group_name>
to manage autonomous-database-family
in tenancy
allow group <group_name>
to read security-attribute-namespaces
in tenancy
liste di controllo dell'accesso (ACL)

Per una maggiore sicurezza, è possibile abilitare le liste di controllo dell'accesso (ACL, Access Control List) nelle distribuzioni dedicate Oracle Public Cloud ed Exadata Cloud@Customer. Un'ACL fornisce ulteriore protezione al database consentendo solo al client con indirizzi IP specifici di connettersi al database. Puoi aggiungere indirizzi IP singolarmente o in blocchi CIDR. Sono supportati sia gli IP/CIDR basati su IPv4 che IPv6. Ciò consente di formulare un criterio di controllo dell'accesso con filtro limitando l'accesso di rete di Autonomous Database ad applicazioni o client specifici.

Facoltativamente, è possibile creare una ACL durante il provisioning del database o in qualsiasi momento successivo. È anche possibile modificare un'ACL in qualsiasi momento. L'abilitazione di una lista ACL con una lista vuota di indirizzi IP rende il database inaccessibile. Per i dettagli, vedere Imposta lista di controllo dell'accesso per un Autonomous Database dedicato.

Tenere presenti le informazioni riportate di seguito sull'uso di una ACL con Autonomous Database.
  • La console del servizio Autonomous Database non è soggetta alle regole ACL.
  • Oracle Application Express (APEX), i servizi RESTful, SQL Developer Web e Performance Hub non sono soggetti ad ACL.
  • Durante la creazione di un Autonomous Database, se l'impostazione di una ACL non riesce, anche il provisioning del database non riesce.
  • L'aggiornamento di una ACL è consentito solo se il database si trova nello stato Disponibile.
  • Il ripristino di un database non sovrascrive le ACL esistenti.
  • La duplicazione di un database, completo e metadati, avrà le stesse impostazioni di controllo dell'accesso del database di origine. Se necessario, è possibile apportare modifiche.
  • Il backup non è soggetto alle regole ACL.
  • Durante un aggiornamento ACL, tutte le operazioni di Autonomous Container Database (CDB) sono consentite, ma le operazioni di Autonomous Database non sono consentite.
Web Application Firewall (WAF)

Per i controlli di rete avanzati che vanno oltre le liste di controllo dell'accesso, Oracle Autonomous Database supporta l'utilizzo di Web Application Firewall (WAF). WAF protegge le applicazioni dal traffico Internet dannoso e indesiderato. WAF è in grado di proteggere qualsiasi endpoint che si interfaccia con Internet, offrendo un'applicazione coerente delle regole in tutte le applicazioni di un cliente. WAF ti consente di creare e gestire regole per le minacce a Internet, tra cui Cross-Site Scripting (XSS), SQL Injection e altre vulnerabilità definite da OWASP. Le regole di accesso possono essere limitate in base all'area geografica o alla firma della richiesta. Per i passi su come configurare WAF, vedere la Guida introduttiva ai criteri Web Application Firewall.

Controllo connessione client

Oracle Autonomous Database implementa il controllo della connessione client con l'autenticazione basata su certificati TLS 1.2 e TLS 1.3 standard per autenticare una connessione client. Tuttavia, TLS 1.3 è supportato solo su Oracle Database 23ai o versioni successive.

Per impostazione predefinita, Autonomous Database utilizza i certificati autofirmati. Tuttavia, puoi installare il certificato lato server firmato dalla CA dalla console di Oracle Cloud Infrastructure (OCI). Per portare il proprio certificato, è innanzitutto necessario creare il certificato utilizzando il servizio di certificati Oracle Cloud Infrastructure (OCI), come dimostrato nella sezione relativa alla creazione di un certificato. Questi certificati devono essere firmati e devono essere in formato PEM, ovvero la loro estensione file deve essere solo .pem, .cer o .crt. Per ulteriori dettagli, consulta la sezione relativa alla gestione dei certificati in Autonomous Database dedicato.

Controllo accesso utente database

Oracle Autonomous Database configura i database creati per utilizzare la funzione di gestione utenti standard di Oracle Database. Viene creato un account utente amministrativo, ADMIN, utilizzato per creare ulteriori account utente e per fornire controlli dell'accesso per gli account.

La gestione utenti standard offre un set affidabile di funzioni e controlli, ad esempio privilegi di sistema e oggetto, ruoli, profili utente e criteri delle password, che consentono di definire e implementare una strategia di accesso utente sicura del database nella maggior parte dei casi. Per istruzioni dettagliate, vedere Creazione e gestione degli utenti del database.

Per informazioni di base sulla gestione utente standard, vedere Account utente in Oracle Database Concepts. Per informazioni dettagliate e indicazioni, vedere Managing Security for Oracle Database Users nel manuale Oracle Database 19c Security Guide o Oracle Database 23ai Security Guide.

Se la tua strategia di accesso degli utenti al database richiede più controlli di quelli forniti dalla gestione degli utenti standard, puoi configurare il tuo database autonomo in modo che utilizzi uno dei seguenti strumenti per soddisfare requisiti più rigorosi.
Strumento Descrizione
Database Vault

Oracle Database Vault è preconfigurato e pronto per essere utilizzato negli Autonomous Database. È possibile utilizzare i potenti controlli di sicurezza per limitare l'accesso ai dati delle applicazioni da parte degli utenti con privilegi del database, riducendo il rischio di minacce interne ed esterne e rispondendo ai requisiti di conformità comuni.

Per ulteriori dettagli, consulta la sezione relativa alla protezione dei dati in funzioni di sicurezza di Autonomous Database.

IAM (Oracle Cloud Infrastructure Identity and Access Management)

È possibile configurare Autonomous Database in modo che utilizzi l'autenticazione e l'autorizzazione di Oracle Cloud Infrastructure Identity and Access Management (IAM) per consentire agli utenti IAM di accedere a un Autonomous Database con le credenziali IAM. Per utilizzare questa opzione con il database, fare riferimento a Usa autenticazione IAM (Identity and Access Management) con Autonomous Database.

Token di accesso OAuth2 di Azure

È possibile gestire centralmente gli utenti di Oracle Autonomous Database in un servizio Microsoft Azure Active Directory (Azure AD) con l'aiuto dei token di accesso di Azure oAuth2. Questo tipo di integrazione consente all'utente di Azure AD di accedere a un'istanza di Oracle Autonomous Database. Gli utenti e le applicazioni di Azure AD possono eseguire il login con le credenziali SSO (Single Sign On) di Azure AD per ottenere un token di accesso OAuth2 di Azure AD da inviare al database.

Per ulteriori informazioni sull'integrazione di Microsoft Azure Active Directory con i database, vedere Autenticare e autorizzare gli utenti di Microsoft Azure Active Directory per Autonomous Database.

Microsoft Active Directory (CMU-AD)

Se si utilizza Microsoft Active Directory come repository utente, è possibile configurare gli Autonomous Database in modo da autenticare e autorizzare gli utenti di Microsoft Active Directory. Questa integrazione consente di consolidare il repository degli utenti continuando a implementare una rigorosa strategia di accesso degli utenti al database, indipendentemente dal fatto che si utilizzi la gestione degli utenti standard, Database Vault, Real Application Security o Virtual Private Database.

Per ulteriori informazioni sull'integrazione di Microsoft Active Directory con i database, vedere Microsoft Active Directory con Autonomous Database.

Kerberos

Kerberos è un sistema di autenticazione sicuro di terze parti che si basa su segreti condivisi. Si presume che la terza parte sia sicura e fornisce funzionalità Single Sign-On, storage centralizzato delle password, autenticazione del database link e maggiore sicurezza del PC. Lo fa tramite un server di autenticazione Kerberos.

Il supporto di Autonomous Database per Kerberos offre i vantaggi del Single Sign-On e dell'autenticazione centralizzata degli utenti Oracle. Per ulteriori informazioni, vedere Autenticare gli utenti di Autonomous Database con Kerberos.

Kerberos con CMU-AD

L'autenticazione Kerberos può essere configurata sopra CMU-AD per fornire l'autenticazione Kerberos CMU-AD per gli utenti di Microsoft Active Directory.

Per fornire l'autenticazione Kerberos CMU-AD per gli utenti di Microsoft Active Directory, è possibile abilitare l'autenticazione Kerberos a monte di CMU-AD impostando type su CMU durante l'abilitazione dell'autenticazione esterna, come illustrato nell'esempio descritto in Abilita autenticazione Kerberos su Autonomous Database.

Real Application Security e Virtual Private Database

Oracle Real Application Security (RAS) fornisce un modello dichiarativo che abilita i criteri di sicurezza che comprendono non solo i business object protetti, ma anche i principal (utenti e ruoli) che dispongono delle autorizzazioni per operare su tali business object. RAS è più sicuro, scalabile e conveniente rispetto al suo predecessore, Oracle Virtual Private Database.

Con Oracle RAS, gli utenti dell'applicazione vengono autenticati sia nel livello dell'applicazione che nel database. Indipendentemente dal percorso di accesso ai dati, i criteri di sicurezza dei dati vengono applicati nel kernel del database in base alla sessione nativa dell'utente finale nel database. I privilegi assegnati all'utente controllano il tipo di operazioni (selezione, inserimento, aggiornamento ed eliminazione) che possono essere eseguite su righe e colonne degli oggetti di database.

Per ulteriori informazioni su Oracle RAS, vedere Introducing Oracle Database Real Application Security nel manuale Oracle Database 19c Real Application Security Administrator's and Developer's Guide o Oracle Database 23ai Real Application Security Administrator's and Developer's Guide.

Oracle Autonomous Database supporta anche Oracle Virtual Private Database (VPD), il predecessore di Oracle RAS. Se già conosci e utilizzi Oracle VPD, puoi configurarlo e utilizzarlo con i tuoi database autonomi.

Per ulteriori informazioni su Virtual Private Database, vedere Using Oracle Virtual Private Database to Control Data Access nella Oracle Database 19c Security Guide o nella Oracle Database 23ai Security Guide.

Gestione degli accessi privilegiati (PAM)

Il livello di sicurezza di Oracle relativo alla gestione degli accessi e dei privilegi degli utenti nei prodotti e servizi è documentato in Oracle Access Control.

Autonomous Database on Dedicated Exadata Infrastructure è progettato per isolare e proteggere i servizi clienti e i dati del database da accessi non autorizzati. Autonomous Database separa i compiti tra il cliente e Oracle. Il cliente controlla l'accesso agli schemi di database. Oracle controlla l'accesso all'infrastruttura e ai componenti software gestiti da Oracle.

Autonomous Database sull'infrastruttura Exadata dedicata è progettato per proteggere i dati per un uso autorizzato dal cliente e per proteggere i dati da accessi non autorizzati, incluso impedire l'accesso ai dati dei clienti da parte dei membri dello staff di Oracle Cloud Ops. Le misure di sicurezza progettate per proteggersi dall'accesso non autorizzato ai dati dell'infrastruttura Exadata, delle VM Autonomous e del database Oracle includono le seguenti:

  • I dati Oracle Database sono protetti dalle chiavi Oracle TDE ( Transparent Data Encryption).
  • Il cliente controlla l'accesso alle chiavi di cifratura TDE e può scegliere di memorizzare tali chiavi in un sistema di gestione delle chiavi Oracle Key Vault esterno.
  • Oracle Database Vault è preconfigurato per impedire agli utenti con privilegi di accedere ai dati dei clienti in Autonomous Database.
  • I clienti possono scegliere di approvare l'accesso operatore tramite l'iscrizione al servizio di controllo dell'accesso operatore.
  • Tutti gli accessi degli operatori si basano sull'autenticazione a più fattori dell'hardware FIPS 140-2 livello 3, implementata con un hardware YubiKey implementato con i dispositivi approvati da Oracle.
  • Tutte le azioni dell'operatore vengono registrate a livello di comando e possono essere inviate al servizio di log OCI o a un SIEM del cliente quasi in tempo reale.

  • Oracle Operations Access Control garantisce che gli account utente utilizzati dalle operazioni e dal personale di supporto di Oracle Cloud per monitorare e analizzare le prestazioni non possano accedere ai dati in Autonomous Database. Il personale addetto alle operazioni e al supporto di Oracle Cloud non ha accesso ai dati nell'Autonomous Database. Quando si crea un Autonomous Container Database, Autonomous Database su un'infrastruttura Exadata dedicata abilita e configura la funzione di controllo delle operazioni di Oracle Database Vault per impedire agli utenti comuni di accedere ai dati in Autonomous Database creati nel container database.

    È possibile confermare che Operations Control è attivo immettendo questa istruzione SQL in un Autonomous Database:
    SELECT * FROM DBA_DV_STATUS;
    Lo stato di APPLICATION CONTROL indica che il controllo operazioni è attivo.

    Nota

    Operations Control era precedentemente noto come Application Control.

Il PAM viene implementato anche con Database Vault per la protezione dei dati, come discusso nelle funzioni di sicurezza di Autonomous Database.