Funzioni di sicurezza in Autonomous Database on Dedicated Exadata Infrastructure

In questo articolo vengono descritte le funzioni di sicurezza principali in Autonomous Database sull'infrastruttura Exadata dedicata.

Si noti che in questa sezione il termine "utente" viene generalmente utilizzato per indicare qualsiasi amministratore dell'organizzazione che ha la responsabilità di eseguire determinati task. In alcuni casi, questo è l'amministratore della flotta, in altri è l'amministratore del database.

Insieme alle funzioni di sicurezza standard di Oracle Database come l'analisi dei privilegi, la cifratura di rete, gli utenti gestiti centralmente, i ruoli applicazione sicuri, la protezione dei dati sensibili trasparenti e altre, l'Autonomous Database dedicato aggiunge Database Vault, Data Safe e altre funzioni di sicurezza avanzate senza costi aggiuntivi.

Di seguito sono riportati i modelli per le funzioni di sicurezza chiave di Autonomous Database dedicato.

Suggerimento

Nell'immagine seguente è possibile fare clic sulla funzione che si desidera esplorare ulteriormente.

Figura - Funzioni di sicurezza principali



Descrizione della "Figura - Funzioni chiave di sicurezza"

Argomenti correlati

Gestione configurazione

Basato su Oracle Cloud Infrastructure, Autonomous Database offre configurazioni di sicurezza standard e rafforzate in modo che tu e il tuo team non dovete spendere enormi quantità di tempo e denaro per gestire le configurazioni nella vostra flotta di database autonomi. Tutti gli account di servizio come SYS e System vengono ruotati ogni 90 giorni. Per ulteriori informazioni, consulta Configuration Management in Autonomous Database.

Le patch e gli aggiornamenti di sicurezza vengono eseguiti automaticamente, quindi non devi preoccuparti di mantenere la sicurezza aggiornata. Queste funzionalità proteggono database e dati altamente sensibili da vulnerabilità e violazioni di sicurezza costose e potenzialmente disastrose. Per ulteriori dettagli, consulta la sezione relativa alla manutenzione del servizio di Autonomous Database dedicato.

Cifratura dati

Autonomous Database memorizza tutti i dati in formato cifrato all'interno di Oracle Database. Solo gli utenti e le applicazioni autenticati possono accedere ai dati quando si connettono al database.

Autonomous Database utilizza una cifratura sempre attiva che protegge i dati in archivio e in transito. Per impostazione predefinita, tutti i dati memorizzati e le comunicazioni di rete con Oracle Cloud vengono cifrati. Impossibile disattivare la cifratura.

Per ulteriori informazioni sulla cifratura dei dati e sulle chiavi di cifratura master, fare riferimento a Cifratura dei dati in Autonomous Database dedicato.

Audit

Oracle Autonomous Database on Dedicated Exadata Infrastructure offre solide funzionalità di audit che ti consentono di monitorare chi ha fatto ciò sul servizio e su database specifici. Dati di log completi ti consentono di eseguire l'audit e monitorare le azioni sulle tue risorse, il che ti aiuta a soddisfare i requisiti di audit riducendo al contempo i rischi operativi e di sicurezza.

Per ulteriori dettagli, consulta Funzionalità di audit in Autonomous Database dedicato.

Controllo dell'accesso

Quando si configura la funzione dell'infrastruttura Exadata dedicata, è necessario assicurarsi che gli utenti cloud abbiano accesso all'uso e alla creazione solo dei 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.

La protezione dell'accesso ai dati e ai database che li contengono comprende diversi tipi di controllo dell'accesso. Per ulteriori dettagli, consulta Controllo dell'accesso in Autonomous Database dedicato.

Gestione dei certificati

Quando un client tenta di connettersi a un Autonomous Database tramite un servizio di connessione al database TCPS (TCP sicuro), Oracle Autonomous Database on Dedicated Exadata Infrastructure utilizza l'autenticazione basata su certificato TLS 1.2 e TLS 1.3 standard per autenticare la connessione. Tuttavia, TLS 1.3 è supportato solo su Oracle Database 23ai o versioni successive. Indipendentemente dal fatto che il client tenti di connettersi tramite un servizio di connessione al database TCPS o TCP, l'accesso del client al database è limitato dai diritti di accesso dell'utente del database utilizzato dal client per connettersi.

Certificato Oracle Managed Self-Signed

Per impostazione predefinita, Autonomous Database utilizza i certificati con firma automatica. Un certificato autofirmato è un certificato di sicurezza generato dal sistema.

Generazione del certificato

I certificati autofirmati gestiti da Oracle vengono generati automaticamente durante il provisioning di un cluster VM Autonomous Exadata (AVMC) e applicati a tutti i database creati in tale AVMC.

Gestione dei certificati

I certificati autofirmati vengono generati e associati automaticamente a un AVMC. Tuttavia, è necessario scaricare il wallet client di Autonomous Database prima di connettersi ai database. Con i certificati con firma automatica, la connessione ai database senza un wallet non è un'opzione. Per istruzioni sul download di un wallet per il database, fare riferimento alla sezione Scarica credenziali client.

A seconda del requisito, all'AVMC sono associati uno dei seguenti tipi di certificato:
  • Certificato SSL del database: certificato SSL per le connessioni al client del database.
  • Certificato SSL ODS: certificato SSL per le applicazioni Application Express (APEX).
Rotazione certificato

Per soddisfare le esigenze di conformità alla sicurezza della tua organizzazione, puoi ruotare i certificati autofirmati gestiti da Oracle utilizzando la console o l'API Oracle Cloud Infrastructure (OCI). Per istruzioni dettagliate, consulta la sezione relativa alla gestione dei certificati di sicurezza per una risorsa cluster VM Autonomous Exadata. Si chiama rotazione del certificato.

Per le nuove risorse AVMC (Autonomous Exadata VM Cluster) di cui è stato eseguito il provisioning, i certificati autofirmati gestiti da Oracle hanno una validità di 13 mesi dalla creazione. La rotazione di un certificato SSL mediante la console o l'API comporta la rotazione dei certificati lato server e lato client e la reimpostazione della validità a 13 mesi. Quando un certificato lato server o lato client gestito da Oracle non viene ruotato prima della scadenza, Oracle li ruota automaticamente e genera nuovi wallet.

Nel caso dei certificati SSL del database, la rotazione del certificato non invalida immediatamente il certificato esistente.

Entro due settimane dalla rotazione dei certificati, puoi connetterti ai tuoi database utilizzando il wallet client di Autonomous Database scaricato prima o dopo la rotazione dei certificati.

Dopo due settimane dalla rotazione del certificato:

  • Il wallet del database scaricato prima della rotazione del certificato è invalidato e non può essere utilizzato per connettersi ai database.
  • Il wallet del database scaricato entro due settimane dalla rotazione dei certificati rimane attivo e può essere utilizzato per connettersi ai database.
  • Per connettersi ai database è possibile utilizzare qualsiasi nuovo wallet del database scaricato dopo due settimane dalla rotazione dei certificati.

Parliamo di questo con un esempio:

Si consideri che un certificato SSL, ad esempio C1, sta per scadere e che il certificato è stato ruotato il 1° febbraio. Per due settimane dal 1 febbraio, che fino al 14 febbraio, il vecchio certificato (C1) è ancora disponibile per l'uso. È possibile continuare a utilizzare il vecchio certificato (C1) o scaricare un nuovo wallet di database per il certificato ruotato (C2) per le connessioni al database. Dopo due settimane dal 1° febbraio, ovvero dal 14 febbraio in poi, il vecchio certificato (C1) viene invalidato e non può essere utilizzato per le connessioni al database. È possibile continuare a utilizzare il wallet del database scaricato dopo la rotazione del certificato (C2) durante queste due settimane. È inoltre possibile scaricare un nuovo wallet del database e iniziare a utilizzarlo per le connessioni al database dopo due settimane dalla rotazione.

È inoltre possibile ruotare un certificato SSL del database entro due settimane dalla rotazione più recente. In questo scenario, il vecchio certificato (che sta per essere invalidato a causa della prima rotazione) viene disabilitato immediatamente. Il certificato successivo (risultato dalla prima rotazione) rimane attivo e un terzo certificato (risultato dalla seconda rotazione) sarà in attesa di attivazione per due settimane dalla seconda rotazione. Qualsiasi wallet del database scaricato prima che la prima rotazione venga invalidata subito dopo la seconda rotazione. È possibile continuare a connettersi al database con qualsiasi wallet del database scaricato dopo la prima rotazione fino a due settimane dalla seconda rotazione. Dopo il completamento di due settimane dalla seconda rotazione, è possibile connettersi ai database solo utilizzando un wallet client scaricato dopo la seconda rotazione, ovvero un wallet scaricato entro due settimane dalla seconda rotazione o successivamente.

Nell'esempio precedente, se si ruota di nuovo lo stesso certificato (C1) entro due settimane dal 1° febbraio, il certificato subisce una doppia rotazione. In questo caso, il vecchio certificato (certificato prima della prima rotazione, ovvero C1) viene invalidato immediatamente. Il certificato risultante dalla prima rotazione (C2) rimane attivo e un terzo certificato risultante dalla seconda rotazione, ad esempio C3, sarà in attesa di attivazione per due settimane dalla seconda rotazione. Dopo due settimane dalla seconda rotazione, viene invalidato anche il certificato risultante dalla prima rotazione (C2) e gli eventuali wallet di database scaricati prima della seconda rotazione non possono essere utilizzati per le connessioni al database. È possibile continuare a utilizzare il wallet del database scaricato dopo la rotazione del certificato (C3) durante queste due settimane. È inoltre possibile scaricare un nuovo wallet del database e iniziare a utilizzarlo per le connessioni al database dopo due settimane dalla seconda rotazione.

Nel caso dei certificati SSL ORDS, tutte le connessioni dell'applicazione esistenti andranno perse con la rotazione del certificato e si consiglia di riavviare ORDS. Il periodo di buffer di due settimane descritto sopra non si applica quando si ruota un certificato SSL ORDS.

Bring Your Own Certificate (BYOC)

Il modello BYOC (Bring Your Own Certificate) consente di utilizzare i certificati lato server firmati CA con gli Autonomous Database.

Generazione del certificato

Per portare il tuo certificato, devi prima creare il certificato utilizzando il servizio di certificati Oracle Cloud Infrastructure (OCI), come dimostrato in 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.

Installazione del certificato

Dopo aver creato il certificato lato server firmato con CA, è necessario installarlo con AVMC in modo che tutti i database in esso creati possano utilizzare questo certificato per connessioni sicure. L'associazione del certificato BYOC a un AVMC è facilitata dalla finestra di dialogo Gestisci certificati sulla console OCI. In questa finestra di dialogo, scegliere Bring Your Own Certificate e selezionare il certificato che si sarebbe creato in precedenza dall'elenco di selezione. Facoltativamente, è anche possibile specificare un certificato CA con un'autorità di certificazione e un bundle CA. Per istruzioni dettagliate, consulta la sezione relativa alla gestione dei certificati di sicurezza per una risorsa cluster VM Autonomous Exadata.

Gestione dei certificati
È possibile connettersi agli Autonomous Database associati a un lato server firmato dalla CA con o senza un wallet client di Autonomous Database.
  • Per connettersi al database utilizzando un wallet del database, è innanzitutto necessario scaricare le credenziali client dalla pagina Dettagli del database utilizzando la console OCI. Per istruzioni, fare riferimento a Scarica credenziali client.
  • Per connettersi al database senza un wallet client, è necessario assicurarsi che:
    • Le connessioni TLS unidirezionali sono abilitate a livello AVMC. Si tratta di un'impostazione definita utilizzando il parametro Listener in Opzioni avanzate durante il provisioning di AVMC. Per istruzioni, fare riferimento a Creare un cluster VM Autonomous Exadata.
    • Il certificato lato server firmato in CA viene firmato da un'autorità di certificazione pubblica ben nota, pertanto viene accettato come sicuro dal sistema operativo del client per impostazione predefinita.
Rotazione certificato

Per soddisfare le esigenze di conformità alla sicurezza della tua organizzazione, puoi ruotare i certificati lato server firmati dalla CA utilizzando la console o l'API Oracle Cloud Infrastructure (OCI). Per istruzioni dettagliate, consulta la sezione relativa alla gestione dei certificati di sicurezza per una risorsa cluster VM Autonomous Exadata.

È necessario ruotarli prima della data di scadenza, in caso contrario, i database su questo AVMC non saranno raggiungibili sulle porte TLS fino a quando non si fornisce un certificato valido. Tuttavia, è possibile continuare ad accedere ai database su una porta non TLS, ad esempio 1521.

Eventi certificato

Per la gestione dei certificati di sicurezza vengono pubblicati gli eventi riportati di seguito.
Evento Generato quando
sslcertificateexpiry.reminder Un cluster VM Autonomous Exadata determina la scadenza di un wallet in meno di sei (6) settimane. Questo evento viene segnalato al massimo una volta alla settimana. Questo evento viene attivato quando esiste una connessione che utilizza il wallet che sta per scadere.
sslcertificate.expired Certificato SSL scaduto. Tutti i wallet di Autonomous Database correlati a questo cluster VM Autonomous Exadata scadranno.
sslcertificaterotation.reminder Un certificato SSL ha più di 365 giorni e consiglia al cliente di ruotare il certificato. Dopo che un certificato SSL attraversa 365 giorni, questo promemoria è una volta alla settimana fino a quando non viene ruotato.
sslcertificate.rotated Il certificato SSL viene ruotato manualmente (mediante la console o l'API di Oracle Cloud Infrastructure) o automaticamente alla sua scadenza.

Suggerimento

Eseguire la sottoscrizione a questi eventi utilizzando il servizio di notifiche OCI per riceverli ogni volta che vengono pubblicati. Per ulteriori dettagli, vedere Creazione di una sottoscrizione.

Consulta la sezione relativa agli eventi per Autonomous Database sull'infrastruttura Exadata dedicata per una lista completa di eventi di Autonomous Database.

Protezione dati

La protezione dei dati è un aspetto fondamentale della sicurezza dei dati in qualsiasi database. Gli account di database con privilegi sono uno dei percorsi più comunemente utilizzati per accedere ai dati sensibili delle applicazioni nel database. Sebbene gli utenti con privilegi quali gli operatori ADMIN o Oracle abbiano bisogno di un accesso ampio e illimitato per facilitare la manutenzione del database, lo stesso accesso crea anche un punto di attacco per ottenere l'accesso a grandi quantità di dati.

Autonomous Database consente di implementare PAM (Privileged Access Management) utilizzando:

  • 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.

    È possibile distribuire controlli per bloccare l'accesso degli account con privilegi ai dati dell'applicazione e controllare le operazioni riservate all'interno del database. È possibile configurare percorsi sicuri per aggiungere ulteriori controlli di sicurezza all'accesso autorizzato ai dati e alle modifiche al database. Attraverso l'analisi runtime di privilegi e ruoli, è possibile aumentare la sicurezza delle applicazioni esistenti implementando i privilegi minimi e riducendo il profilo di attacco degli account di database. Database Vault protegge gli ambienti di database esistenti in modo trasparente, eliminando le modifiche delle applicazioni costose e dispendiose in termini di tempo.

    Oracle Database Vault risolve principalmente i problemi di sicurezza dei database riportati di seguito.

    • Accesso di account con privilegi amministrativi ai dati dell'applicazione: sebbene l'amministratore del database sia l'utente più potente e sicuro, questo amministratore non deve accedere ai dati dell'applicazione che risiedono nel database.

      I realm di Oracle Database Vault relativi agli schemi delle applicazioni, alle tabelle riservate e alle stored procedure forniscono controlli per evitare che gli account con privilegi vengano sfruttati da intrusi e addetti ai lavori per accedere ai dati sensibili delle applicazioni. Per ulteriori informazioni, vedere How Oracle Database Vault Protects Privileged User Accounts in Oracle Database 19c Administrator's Guide o Oracle Database 23ai Administrator's Guide.

    • Separazione dei compiti per l'accesso ai dati dell'applicazione: è possibile personalizzare la separazione dei controlli dei compiti di Oracle Database Vault e le organizzazioni con risorse limitate possono assegnare più responsabilità di Oracle Database Vault allo stesso amministratore, ma utilizzando account separati per ogni ruolo di separazione dei compiti per ridurre al minimo i danni al database se un account viene rubato e sfruttato. Per ulteriori informazioni, vedere How Oracle Database Vault Addresses Database Consolidation Concerns in Oracle Database 19c Administrator's Guide o Oracle Database 23ai Administrator's Guide.

    Prima di utilizzare Database Vault, vedere What to Expect After You Enable Oracle Database Vault nel manuale Oracle Database 19c Administrator's Guide o Oracle Database 23ai Administrator's Guide per comprendere l'impatto della configurazione e dell'abilitazione di Database Vault.

    Per informazioni su come configurare e abilitare Database Vault nel database autonomo, vedere Utilizzare Oracle Database Vault per gestire i privilegi utente del database.

    Suggerimento

    Per provare a configurare Database Vault, eseguire Lab 1: Protect Data With Database Vault nel workshop per gli amministratori della sicurezza di Oracle Autonomous Database Dedicated for Security.
  • Il PAM viene utilizzato anche per proteggere i dati per l'uso autorizzato dal cliente e per proteggere i dati da accessi non autorizzati, tra cui la prevenzione dell'accesso ai dati dei clienti da parte di Oracle Cloud Operations e del personale di supporto. 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. Per ulteriori informazioni, vedere Gestione degli accessi privilegiati.

Ricerca automatica e mascheramento dei dati riservati

Identificare i dati sensibili (come il numero di carta di credito, SSN) e mascherarli o proteggerli se necessario migliora la protezione dei dati e la sicurezza generale dei dati.

  • Oracle Autonomous Database on Dedicated Exadata Infrastructure supporta l'integrazione con il servizio Oracle Data Safe per aiutarti a valutare e proteggere i tuoi database. Oracle Data Safe ti aiuta a comprendere la sensibilità dei dati, valutare i rischi per i dati, mascherare i dati sensibili, implementare e monitorare i controlli di sicurezza, valutare la sicurezza degli utenti, monitorare l'attività degli utenti e risolvere i requisiti di conformità alla sicurezza dei dati nei database.

    Fornisce il seguente set di funzioni in un'unica console di gestione facile da usare:

    • La valutazione della sicurezza consente di valutare la sicurezza della configurazione del database.

    • La valutazione degli utenti consente di valutare la sicurezza degli utenti del database e di identificare gli utenti ad alto rischio.

    • La ricerca automatica dei dati consente di trovare i dati riservati nel database. Il mascheramento dei dati consente di mascherare i dati sensibili in modo che siano al sicuro per scopi non di produzione.

    • Audit attività consente di eseguire l'audit dell'attività degli utenti nel database in modo da poter monitorare l'uso del database ed essere avvisati di attività insolite del database.

    Per ulteriori informazioni sull'utilizzo di Data Safe, vedere Panoramica di Oracle Data Safe in Uso di Oracle Data Safe.

    Per utilizzare Oracle Data Safe per identificare e proteggere i dati riservati e regolamentati del tuo Autonomous Database, devi registrare il tuo database con Data Safe. Dopo aver registrato il database con Data Safe, è possibile passare alla console Data Safe direttamente dalla pagina Dettagli di Autonomous Database. Per ulteriori informazioni sulla registrazione del database, vedere Registrare o annullare la registrazione di un database dedicato con Data Safe.

  • Quando una query eseguita da un'applicazione in fase di esecuzione restituisce un set di risultati con informazioni riservate quali numeri di carta di credito o ID personali, Oracle Data Redaction consente di mascherare i dettagli riservati prima di restituire il set di risultati all'applicazione. È possibile implementare criteri per la protezione dati sensibili utilizzando il package PL/SQL DBMS_REDACT . Fare riferimento a DBMS_REDACT in Oracle Database 19c PL/SQL Packages and Types Reference o Oracle Database 23ai PL/SQL Packages and Types Reference.

Certificazione conformità normativa

Autonomous Database sull'infrastruttura Exadata dedicata soddisfa un ampio set di standard di conformità internazionali e specifici del settore, tra cui:

  • FedRAMP High-Federal Risk and Authorization Management Program (Stati Uniti) Solo regioni governative)
  • HIPAA-Health Insurance Portabilità e responsabilità
  • ISO/IEC 27001:2013 - Organizzazione internazionale per la standardizzazione 27001
  • ISO/IEC 27017:2015-Codice di condotta per i controlli di sicurezza delle informazioni basato su ISO/IEC 27002 per i servizi cloud
  • ISO/IEC 27018:2014-Codice di condotta per la protezione delle informazioni di identificazione personale (PII) nei cloud pubblici che agiscono come processori PII
  • PCI DSS-Payment Card Industry Data Security Standard è un insieme di requisiti volti a garantire che tutte le aziende che elaborano, memorizzano o trasmettono informazioni sulle carte di credito mantengano un ambiente sicuro
  • SOC 1 - Controlli sistema e organizzazione 1
  • SOC 2 - Controlli di sistema e organizzazione 2

Per ulteriori informazioni e un elenco completo delle certificazioni, consulta Oracle Cloud Compliance.