L'infrastruttura Exadata Cloud è gestita congiuntamente dal cliente e da Oracle ed è suddivisa in due aree di responsabilità.

I clienti controllano e monitorano l'accesso ai servizi clienti, incluso l'accesso di rete alle proprie VM (tramite OCI Virtual Cloud Networks e OCI Security Lists), l'autenticazione per accedere alle VM e l'autenticazione per accedere ai database in esecuzione nelle VM. Oracle controlla e monitora l'accesso ai componenti dell'infrastruttura gestita Oracle e la sicurezza fisica del server. Il personale Oracle non è autorizzato ad accedere ai servizi clienti, incluse le VM e i database dei clienti, a eccezione dei casi in cui i clienti non sono in grado di accedere alle VM dei clienti.

I clienti accedono ai database Oracle (DB) in esecuzione sull'infrastruttura Exadata Cloud tramite VCN client e di backup nei database in esecuzione nella VM del cliente utilizzando i metodi di connessione al database Oracle standard, ad esempio Oracle Net sulla porta 1521. Accesso del cliente alla VM che esegue i database Oracle tramite i metodi Oracle Linux standard, ad esempio ssh basato su token sulla porta 22.

Funzioni di sicurezza offerte dall'infrastruttura Exadata Cloud.

• Sicurezza fisica di Oracle Cloud

  I data center Oracle Cloud si allineano agli standard ANSI/TIA-942-A Tier 3 (disponibilità al 99,982%) o Tier 4 (disponibilità al 99,995%) e seguono una metodologia di ridondanza N2 ('N' sta per Need) per il funzionamento delle apparecchiature critiche. I data center che ospitano i servizi Oracle Cloud Infrastructure utilizzano fonti di alimentazione ridondanti e gestiscono i backup dei generatori in caso di interruzioni elettriche diffuse. Le sale server sono strettamente monitorate per la temperatura e l'umidità dell'aria e sono in atto sistemi antincendio. Il personale del data center viene formato in procedure di risposta agli incidenti e di escalation per affrontare gli eventi di sicurezza e disponibilità che potrebbero verificarsi. Per ulteriori informazioni, vedere: Oracle Cloud Infrastructure Security Guide. Per ulteriori dettagli sulla conformità dei data center di Oracle Cloud Infrastructure, consulta Oracle Cloud Compliance. Vedere anche: Oracle Corporate Security Practices: Data Security: Physical and Environmental Controls.

• Controlli di accesso ai data center Oracle

  Per garantire sistemi sicuri, i protocolli di accesso Oracle ai data center fisici sono i seguenti:

  • L'accesso fisico alle strutture per i data center è limitato a determinati dipendenti, appaltatori e visitatori autorizzati di Oracle.
  • Ai dipendenti Oracle, ai subappaltatori e ai visitatori autorizzati vengono rilasciati documenti di identificazione che devono essere indossati mentre si trovano in una sede Oracle.
  • I visitatori devono firmare il registro di un visitatore, essere accompagnati e/o osservati quando si trovano in una sede Oracle e/o essere vincolati dai termini di un accordo di riservatezza con Oracle.
  • La sicurezza monitora il possesso di chiavi/schede di accesso e monitora la possibilità di accedere alle strutture. Il personale che lascia l'impiego di Oracle deve restituire chiavi/carte e le chiavi/carte vengono disattivate al momento della cessazione.
  • La sicurezza autorizza tutte le riparazioni e le modifiche alle barriere di sicurezza fisiche o ai controlli di ingresso nelle sedi di servizio.
  • Oracle utilizza una miscela di agenti di sicurezza in loco o agenti di pattuglia 24/7, a seconda del livello di rischio/protezione della struttura. In tutti i casi, gli agenti sono responsabili delle pattuglie, della risposta agli allarmi e della registrazione degli incidenti di sicurezza.
  • Oracle ha implementato sistemi di controllo degli accessi elettronici gestiti centralmente con funzionalità di allarme intruso integrate. I registri di accesso sono conservati per un minimo di sei mesi. Inoltre, il periodo di conservazione per il monitoraggio e la registrazione delle telecamere a circuito chiuso varia da 30 a 90 giorni al minimo, a seconda delle funzioni e del livello di rischio dell'impianto.

  Per ulteriori dettagli sui controlli degli accessi al sito Oracle, vedere: Procedure di sicurezza aziendale Oracle: Oracle Access Control

• Isolamento del cliente dell'hypervisor

  L'hypervisor è il software che gestisce i dispositivi virtuali in un ambiente cloud, gestendo la virtualizzazione di server e rete. Negli ambienti di virtualizzazione tradizionali, l'hypervisor gestisce il traffico di rete, consentendo il flusso tra le istanze VM e tra le istanze VM e gli host fisici. Ciò aggiunge una notevole complessità e un sovraccarico computazionale nell'hypervisor. Gli attacchi di sicurezza informatica dimostrativi, come gli attacchi di fuga delle macchine virtuali, hanno evidenziato il rischio sostanziale che può derivare da questo progetto. Questi attacchi sfruttano la complessità dell'hypervisor consentendo a un utente malintenzionato di eseguire il "breakout" di un'istanza VM, accedere al sistema operativo sottostante e ottenere il controllo dell'hypervisor. L'attaccante può quindi accedere ad altri host, a volte non rilevati. Oracle Cloud Infrastructure riduce questo rischio disaccoppiando la virtualizzazione di rete dall'hypervisor.

  Per affrontare potenziali attacchi, Oracle ha implementato un'architettura incentrata sulla sicurezza utilizzando la virtualizzazione di rete isolata, elemento fondamentale dell'architettura dell'infrastruttura Oracle Cloud. Questa architettura blocca il malware nelle sue tracce con un SmartNIC progettato su misura per isolare e virtualizzare la rete. La virtualizzazione di rete isolata riduce i rischi limitando la superficie di attacco. Anche se un attore malintenzionato riesce con un attacco di escape VM su un singolo host, l'architettura virtuale è progettata in modo che l'attore non possa raggiungere altri host nell'infrastruttura cloud. L'attacco è effettivamente contenuto all'unico ospite. L'architettura di virtualizzazione della rete isolata sicura viene implementata in ogni data center di ogni area. A ogni tenant di Oracle Cloud Infrastructure vengono forniti i vantaggi di questa architettura incentrata sulla sicurezza.

  Figura 6-1 Virualizzazione della rete isolata riduce i rischi in Oracle Generation 2 Cloud

  
  Descrizione della "Figura 6-1 Virualizzazione della rete isolata riduce i rischi in Oracle Generation 2 Cloud"
• Sicurezza multi-tenant

  Coerentemente con la nostra filosofia di sicurezza di Defense in Depth, Multitenant ha un'architettura di isolamento completa.

  Ci sono quattro categorie principali, con diverse caratteristiche importanti in ogni categoria.

  1. Meccanismo di controllo dell'accesso
  2. Impedisci accesso amministratore non autorizzato
  3. Protezione dall'accesso diretto ai file di dati
  4. Isolamento risorse
  t

  Figura 6-2 Architettura di isolamento completa multi-tenant

  
  Descrizione della "Figura 6-2 Architettura di isolamento completa del multi-tenant"

• Difesa approfondita L'infrastruttura Exadata Cloud offre una serie di controlli per garantire riservatezza, integrità e disponibilità in tutto il servizio.

  In primo luogo, l'infrastruttura Exadata Cloud si basa sull'immagine del sistema operativo potenziata fornita da Exadata Database Machine (https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/exadata-security-overview.html). In questo modo, l'ambiente operativo principale viene protetto limitando l'immagine di installazione ai soli pacchetti software richiesti, disabilitando i servizi non necessari e implementando parametri di configurazione sicuri in tutto il sistema.

  Oltre a ereditare tutta la potenza della piattaforma matura di Exadata Database Machine, poiché l'infrastruttura Exadata Cloud esegue il provisioning dei sistemi per i clienti, nelle istanze del servizio vengono implementate ulteriori opzioni di configurazione predefinite sicure. Ad esempio, tutte le tablespace del database richiedono la cifratura dei dati trasparente (TDE), un'applicazione efficace delle password per gli utenti e i superutenti iniziali del database e regole avanzate di audit ed eventi.

  L'infrastruttura Exadata Cloud costituisce anche una distribuzione e un servizio completi, quindi è soggetta a audit esterni standard del settore come PCI, HIPPA e ISO27001. Questi requisiti di audit esterni impongono funzioni di servizio a valore aggiunto aggiuntive come la scansione antivirus, l'invio automatico di avvisi per modifiche impreviste al sistema e le scansioni giornaliere delle vulnerabilità per tutti i sistemi di infrastruttura gestiti da Oracle nella flotta.

• Privilegio minimo

  Gli standard di codifica di sicurezza Oracle richiedono che i processi software vengano eseguiti al livello minimo di privilegi per implementare le proprie funzionalità.

  Ogni processo e daemon deve essere eseguito come utente normale e senza privilegi a meno che non dimostri un requisito per un livello di privilegio più elevato. Questo aiuta a contenere eventuali problemi imprevisti o vulnerabilità allo spazio utente senza privilegi e non compromette un intero sistema.

  Questo principio si applica anche ai membri del team operativo Oracle che utilizzano singoli account denominati per accedere all'infrastruttura Exadata Cloud per la manutenzione o la risoluzione dei problemi. Solo quando necessario, utilizzeranno l'accesso controllato a livelli di privilegio più elevati per risolvere o risolvere un problema. La maggior parte dei problemi viene risolta attraverso l'automazione, quindi utilizziamo anche i privilegi minimi non consentendo agli operatori umani di accedere a un sistema a meno che l'automazione non sia in grado di risolvere il problema.

• Audit e responsabilità

  Se necessario, l'accesso al sistema è consentito, ma tutti gli accessi e le azioni vengono registrati e monitorati per la responsabilità.

  I log di audit dell'infrastruttura Exadata Cloud sono controllati da Oracle e utilizzati per scopi di monitoraggio e conformità della sicurezza. Oracle può condividere i log di audit pertinenti con i clienti in base a Oracle Incident Response Practices e all'Oracle Data Processing Agreement.

  Le funzionalità di audit vengono fornite in tutti i componenti dell'infrastruttura per garantire l'acquisizione di tutte le azioni. I clienti possono inoltre configurare l'audit per la configurazione di database e VM guest e scegliere di integrarli con altri sistemi di audit aziendali.

• Automatizzazione delle operazioni cloud

  Eliminando le operazioni manuali necessarie per eseguire il provisioning, applicare patch, gestire, risolvere i problemi e configurare i sistemi, l'opportunità di errore si riduce.

• Immagine del sistema operativo potenziata

  • Installazione minima del pacchetto:

    Vengono installati solo i pacchetti necessari per eseguire un sistema efficiente. Installando un set più piccolo di pacchetti, la superficie di attacco del sistema operativo viene ridotta e il sistema rimane più sicuro.

  • Configurazione sicura:

    Durante l'installazione vengono impostati molti parametri di configurazione non predefiniti per migliorare le impostazioni di sicurezza del sistema e del relativo contenuto. Ad esempio, SSH viene configurato per l'ascolto solo su determinate interfacce di rete, sendmail viene configurato per accettare solo connessioni localhost e durante l'installazione vengono implementate molte altre limitazioni simili.

  • Eseguire solo i servizi necessari:

    Qualsiasi servizio installato sul sistema, ma non necessario per il normale funzionamento, è disabilitato per impostazione predefinita. Ad esempio, mentre NFS è un servizio spesso configurato dai clienti per vari scopi applicativi, è disabilitato per impostazione predefinita in quanto non è necessario per le normali operazioni del database. I clienti possono scegliere di configurare facoltativamente i servizi in base alle proprie esigenze.

• Superficie di attacco ridotta a icona

  Come parte dell'immagine protetta, la superficie di attacco viene ridotta installando ed eseguendo solo il software necessario per fornire il servizio.

• Funzionalità di sicurezza aggiuntive abilitate (password grub, boot sicuro)

  • Sfruttando le funzionalità di immagine di Exadata, ExaDB-D dispone delle funzionalità integrate nell'immagine di base, come le password grub e l'avvio sicuro, oltre a molte altre.
  • Attraverso la personalizzazione, i clienti potrebbero voler migliorare ulteriormente il proprio livello di sicurezza con configurazioni aggiuntive.
• Metodi di accesso sicuro
  • Accesso ai database server tramite SSH mediante crittografie avanzate. Le cifrature deboli sono disabilitate per impostazione predefinita.
  • Accesso ai database tramite connessioni cifrate a Oracle Net. Per impostazione predefinita, i nostri servizi sono disponibili utilizzando canali cifrati e un client Oracle Net configurato per impostazione predefinita utilizzerà sessioni cifrate.
  • Accesso alla diagnostica tramite l'interfaccia Web Exadata MS (https).
• Audit e registrazione
  • Per impostazione predefinita, l'audit è abilitato per le operazioni amministrative e tali record di audit vengono comunicati ai sistemi interni OCI per la revisione e gli avvisi automatici quando necessario.

Diversi account utente gestiscono regolarmente i componenti dell'infrastruttura Exadata Cloud. Questi utenti sono obbligatori e non possono essere modificati.

In tutti i computer ExaDB-D, Oracle utilizza e consiglia il login SSH basato su token.

Esistono tre classi di utenti:

• Utenti predefiniti: Nessun privilegio di accesso
  
• Utenti predefiniti con accesso SHELL limitato
  Questi utenti vengono utilizzati per l'esecuzione di un task definito con login SHELL limitato. Questi utenti non devono essere rimossi poiché il task definito non riuscirà nel caso in cui vengano eliminati.
• Utenti predefiniti con autorizzazioni di login
  Questi utenti con privilegi vengono utilizzati per eseguire la maggior parte dei task nel sistema. Questi utenti non devono mai essere modificati o eliminati in quanto potrebbero avere un impatto significativo sul sistema in esecuzione.

Oltre a tutte le funzioni Exadata illustrate nelle funzioni di sicurezza di Oracle Exadata Database Machine, alle istanze dell'infrastruttura Exadata Cloud sono applicabili anche le impostazioni di sicurezza riportate di seguito.

• Distribuzione di database personalizzata con parametri non predefiniti.
  Il comando host_access_control consente di configurare le impostazioni di sicurezza Exadata:

  • Implementazione di criteri per la durata e la complessità delle password.
  • Definizione di criteri per il blocco dell'account e il timeout della sessione.
  • Limitazione dell'accesso root remoto.
  • Limitazione dell'accesso alla rete a determinati account.
  • Implementazione di un messaggio di avvio di avvertenza al login.
• account-disable: disabilita un account utente quando vengono soddisfatte determinate condizioni configurate.
• pam-auth: varie impostazioni PAM per le modifiche della password e l'autenticazione della password.
• rootssh: regola il valore PermitRootLogin in /etc/ssh/sshd_config, che consente o nega all'utente root di eseguire il login tramite SSH.
  • L'impostazione predefinita è PermitRootLogin e no.
  • PermitRootLogin=per l'automazione cloud è necessaria l'assenza di password per eseguire alcune operazioni di gestione del ciclo di vita. La disabilitazione del login root causerà il mancato funzionamento di tale funzionalità del servizio.
• session-limit: imposta il parametro * hard maxlogins in /etc/security/limits.conf, che rappresenta il numero massimo di login per tutti gli utenti. Questo limite non si applica a un utente con uid=0.

  L'impostazione predefinita è * hard maxlogins 10 ed è il valore sicuro consigliato.

• ssh-macs: specifica gli algoritmi MAC (Message Authentication Code) disponibili.
  • L'algoritmo MAC viene utilizzato nella versione 2 del protocollo per la protezione dell'integrità dei dati.
  • L'impostazione predefinita è hmac-sha1, hmac-sha2-256, hmac-sha2-512 sia per il server che per il client.
  • Valori sicuri consigliati: hmac-sha2-256, hmac-sha2-512 per server e client.
• password-aging: imposta o visualizza la durata della password corrente per gli account utente interattivi.
  • -M: numero massimo di giorni in cui è possibile utilizzare una password.
  • -m: numero minimo di giorni consentiti tra le modifiche della password.
  • -W: numero di giorni di avvertenza prima della scadenza di una password.
  • L'impostazione predefinita è -M 99999, -m 0, -W 7
  • --strict_compliance_only-M 60, -m 1, -W 7
  • Valori consigliati sicuri: -M 60, -m 1, -W 7

Elenco dei processi eseguiti per impostazione predefinita sulla VM del cliente, anche denominata DOMU, oppure VM guest e sistema operativo guest

• Agente VM dell'infrastruttura Exadata Cloud:

  Agente cloud per la gestione delle operazioni del ciclo di vita del database.

  • Viene eseguito come utente opc
  • La tabella dei processi la mostra in esecuzione come processo Java con i nomi jar: dbcs-agent-VersionNumber-SNAPSHOT.jar e dbcs-admin-VersionNumver-SNAPSHOT.jar.
• Agente di Oracle Trace File Analyzer:

  Oracle Trace File Analyzer (TFA) fornisce una serie di strumenti di diagnostica in un singolo bundle, semplificando la raccolta di informazioni diagnostiche sul database e sul clusterware Oracle, che a sua volta aiuta a risolvere i problemi quando si tratta di Oracle Support

  • Viene eseguito come utente root
  • Funziona come demone inizializzato (/etc/init.d/init.tfa)
  • Le tabelle dei processi mostrano un'applicazione Java (oracle.rat.tfa.TFAMain)
  • Viene eseguito come utenti root e exawatch.
  • Esegue come script di backgroud, ExaWatcher.sh e tutto il relativo processo figlio come processo Perl.
  • La tabella dei processi viene visualizzata come più applicazioni Perl.ExaWatcher:
• Database e GI (clusterware):
  • Viene eseguito come utenti dbmsvc e grid
  • La tabella dei processi mostra le seguenti applicazioni:
    • oraagent.bin, apx_* e ams_* come utente grid
    • dbrsMain e applicazioni Java: derbyclient.jar, weblogic.Server come utente oracle.
• Management Server (MS):

  Parte del software di immagini Exadata per la gestione e il monitoraggio delle funzioni di immagine.

  • Viene eseguito come dbmadmin.
  • La tabella dei processi la mostra in esecuzione come processo Java.

• Sicurezza della rete VM guest
  
• Requisiti di conformità
  

Funzionalità di sicurezza del database predefinite abilitate e utilizzate:

• La funzione TDE (Transparent Database Encryption) viene utilizzata per le tablespace di database create dagli strumenti di Oracle Database Cloud.
  • CDB$ROOT: la tablespace degli utenti è cifrata
  • PDB: tutte le tablespace cifrate
  • La password del wallet viene fornita durante la creazione iniziale del DB. È possibile modificare le password del wallet utilizzando dbaascli. I clienti devono modificare periodicamente questa password.
• Utenti nel database
  • Nessun utente aggiuntivo creato nel database.
  • Dopo la creazione del database, tutti gli utenti DB vengono bloccati ad eccezione di SYS, SYSTEM e DBSNMP.
  • L'audit è abilitato per le seguenti operazioni:
    • DATABASE LINK
    • PUBLIC DATABASE LINK
    • PUBLIC SYNONYM
    • DROP ANY PROCEDURE
    • PROCEDURE
    • ALTER SYSTEM
    • TRIGGER
    • CREATE DATABASE LINK
    • ALTER DATABASE LINK
    • CREATE PROCEDURE
    • ALTER SYSTEM
    • CREATE TRIGGER
    • CREATE ANY TRIGGER
    • SELECT ANY DICTIONARY
    • DB VERSION_11_2: EXEMPT REDACTION POLICY
    • DB VERSION_12_1 o DB VERSION_12_2: BECOME USER
    • DB VERSION_12_1: SESSION
    • Il profilo DBAASSECURE viene creato ed è impostato come profilo predefinito per l'account utente del database.

• Cifratura SQL*Net nativa per tutte le connessioni di rete: i parametri sqlnet.ora rilevanti impostati nell'infrastruttura Exadata Cloud per impostazione predefinita sono i seguenti:

  • SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)

  • SQLNET.ENCRYPTION_SERVER = requested

  • SQLNET.CRYPTO_CHECKSUM_SERVER = accepted

  • SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)

• Protocollo TCPS offerto per la connessione di rete al database sulla porta 2484 (wallet configurato in /var/opt/oracle/dbaas_acfs/grid/tcps_wallets). I parametri sqlnet.ora rilevanti impostati nell'infrastruttura Exadata Cloud per impostazione predefinita sono i seguenti:

  • SSL_CIPHER_SUITES = (SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
    SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

  • WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))

  • SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS = TRUE

  • SSL_VERSION = 1.2

• Registrazione listener remoto: i listener vengono eseguiti dalla home GI. Exadata Cloud Infrastructure distribuisce la versione di Grid Infrastructure descritta nel Documento Oracle Support 2333222.1 (Versioni software di Exadata Cloud Service). La configurazione predefinita dell'infrastruttura Exadata Cloud include il parametro listener.ora VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET combinato con REMOTE_REGISTRATION_ADDRESS_<SCANLISTENER>=<value> per limitare le registrazioni del listener remoto a scopo di sicurezza.
• Integrazione di OCI Vault: la chiave di cifratura TDE può essere memorizzata nel vault OCI (un sistema di gestione delle chiavi). Per ulteriori informazioni e istruzioni per configurare principal, vault e così via, vedere Chiavi gestite dal cliente nell'infrastruttura Exadata Cloud. Sono supportati sia i tipi di vault privati che quelli condivisi per l'integrazione di OCI Vault dell'infrastruttura Exadata Cloud. L'autenticazione utente DB non è integrata con OCI Vault.

Backup del sistema operativo/VM:

Oracle esegue un backup completo della VM guest ogni settimana e gestisce una o più copie di backup. Questi backup sono snapshot su disco completi della VM guest (file system del sistema operativo locale, non gruppi di dischi ASM che risiedono nello storage Exadata). Questo backup viene attivato a un'ora prestabilita ogni settimana. I backup vengono memorizzati localmente nel file dom0. I clienti possono richiedere a Oracle di ripristinare l'immagine della VM guest dal backup più recente inoltrando una richiesta di servizio (SR, Service Request) My Oracle Support (MOS). Oracle non può ripristinare file specifici dal backup dell'immagine. I clienti devono eseguire i backup a livello di file nella VM guest se richiedono la capacità di eseguire il ripristino di un singolo file.

Backup DB gestiti:

• Backup completo settimanale (livello 0)
• Backup incrementale in sequenza giornaliero (livello 1) in ciclo di sette giorni
• Backup automatici giornalieri a un'ora specifica impostata durante il processo di creazione della distribuzione del database

Il periodo di conservazione per i backup varia da 30 giorni (sul servizio di storage degli oggetti) a 7 giorni (sul servizio di storage locale)

Cifratura:

• Sia lo storage degli oggetti che lo storage locale: tutti i backup nello storage cloud vengono cifrati.
• Solo storage degli oggetti: tutti i backup nello storage cloud sono cifrati.

Tutti i backup possono essere configurati tramite l'interfaccia utente CP o l'API CP.

Tutti i backup vengono cifrati con la stessa chiave master utilizzata per la cifratura del wallet TDE (Transparent Data Encryption).

Solo gli strumenti automatizzati sono autorizzati ad accedere alle VM guest a scopo di automazione del ciclo di vita.

Un caso d'uso specifico si verifica quando la VM guest non è in grado di eseguire il boot. In questo caso, i clienti devono fornire l'autorizzazione per accedere alla VM guest a scopo di recupero. I dettagli per gestire questo scenario sono descritti nella sezione "Flussi di lavoro eccezioni" dei controlli di sicurezza di Exadata Cloud Service.

I clienti controllano e monitorano l'accesso al servizio clienti, incluso l'accesso di rete alle VM guest (tramite VLAN e firewall di livello 2 implementati nella VM guest), l'autenticazione per accedere alla VM guest e l'autenticazione per accedere ai database in esecuzione nelle VM guest. Oracle controlla e monitora l'accesso ai componenti dell'infrastruttura gestita da Oracle. Il personale Oracle non è autorizzato ad accedere ai servizi clienti, incluse le VM e i database guest.

PII (Personally Identifiable Information) queste informazioni sono considerate riservate e sensibili e devono essere protette per impedire l'uso non autorizzato delle informazioni personali ai fini di normative legali, responsabilità finanziarie e reputazione personale.

È necessario configurare un set di regole esplicite per impedire che le informazioni di identificazione personale (PII) vengano visualizzate nei dati.

Le regole predefinite di Application Performance Monitoring nascondono le informazioni di identificazione personale negli URL mediante il riconoscimento di valori monetari, numeri di conto bancario e date. Tuttavia, le regole predefinite acquisiscono solo informazioni di identificazione personale ovvie e non sono esaustive. È necessario valutare le regole predefinite e configurare ulteriormente le regole per garantire la corretta generazione di report nell'ambiente e assicurarsi che le informazioni di identificazione personale non vengano visualizzate nei dati.

Per ulteriori informazioni, vedere Nascondi informazioni di identificazione personale e Informazioni di sicurezza e di identificazione personale

Conservazione backup

Quando si abilita la funzione Backup automatico, il servizio crea backup incrementali giornalieri del database nello storage degli oggetti. Il primo backup creato è un backup di livello 0. Quindi, i backup di livello 1 vengono creati ogni giorno fino al fine settimana successivo. Ogni fine settimana, il ciclo si ripete, a partire da un nuovo backup di livello 0.

Se si sceglie di abilitare i backup automatici, è possibile scegliere uno dei seguenti periodi di conservazione preimpostati: 7 giorni, 15 giorni, 30 giorni, 45 giorni o 60 giorni. Il sistema elimina automaticamente i backup incrementali alla fine del periodo di conservazione scelto.

Per ulteriori informazioni, vedere Gestire il backup e il recupero del database su Oracle Exadata Database Service on Dedicated Infrastructure

Periodo di conservazione log di audit

Il servizio di audit OCI fornisce record delle operazioni API eseguite sui servizi supportati come elenco di eventi di log. Per impostazione predefinita, i record del servizio di audit vengono conservati per 365 giorni.

Per ulteriori informazioni, vedere Periodo di conservazione del log di audit

Conservazione log servizio

I servizi Oracle Cloud Infrastructure, come API Gateway, Eventi, Funzioni, Load Balancing, Object Storage e i log di flusso VCN emettono i log del servizio. Ciascuno di questi servizi supportati dispone di una risorsa Log che consente di abilitare o disabilitare il log per tale servizio. Per impostazione predefinita, la conservazione dei log è di 1 mese, ma può essere impostata fino a 6 mesi.

I gruppi di log possono essere utilizzati per limitare l'accesso ai log riservati generati dai servizi mediante il criterio IAM. Non devi fare affidamento su gerarchie compartimenti complesse per proteggere i tuoi log. Ad esempio, si supponga che il gruppo di log predefinito in un singolo compartimento sia il punto in cui vengono memorizzati i log per l'intera tenancy. Concedi l'accesso al compartimento agli amministratori dei log con il criterio IAM come normalmente faresti. Si supponga tuttavia che alcuni progetti contengano informazioni di identificazione personale (PII) e che tali log possano essere visualizzati solo da un gruppo selezionato di amministratori di log. I gruppi di log consentono di inserire i log che contengono PII in un gruppo di log separato, quindi di utilizzare il criterio IAM per limitare l'accesso a tutti gli amministratori di log tranne pochi.

Per ulteriori informazioni, vedere Log dei servizi e Gestione di log e gruppi di log

In alcuni casi, è possibile risolvere alcuni problemi solo eseguendo il login alla VM guest del cliente da parte di Oracle.

Di seguito sono riportate le situazioni in cui è necessario l'accesso alla VM guest e le procedure consigliate per l'accesso alla VM guest.

1. Situazioni in cui il database iniziale non è ancora stato creato e il cliente non dispone ancora dell'accesso SSH alla propria VM guest. Un esempio potrebbe essere la richiesta di servizio aperta dal cliente per risolvere i problemi relativi al motivo per cui il cliente non è in grado di creare un database iniziale. In questa situazione, il cliente non ha mai avuto accesso alla VM guest e non è stato ancora creato alcun database, pertanto non esistono dati del cliente nella VM guest.

   In base ai criteri di sicurezza associati al servizio ExaDB-D, il personale Oracle non è autorizzato ad accedere alla VM guest del cliente senza l'autorizzazione esplicita del cliente. Per garantire la conformità a questa policy, Oracle deve ottenere l'autorizzazione del cliente ad accedere alla VM guest ponendo la seguente domanda.

   "Per consentire a Oracle di risolvere il problema descritto in questa RS, abbiamo bisogno dell'autorizzazione esplicita del cliente che ci consente di eseguire il login alla VM guest del cliente. Fornendoci l'autorizzazione esplicita per accedere alla VM guest, l'utente conferma che non sono presenti dati riservati memorizzati nella VM guest del cliente o nei database associati. Il team di sicurezza del cliente autorizza Oracle ad accedere alla VM guest del cliente in modo che Oracle sia in grado di risolvere il problema. Ho l'autorizzazione esplicita per accedere alla VM guest?"

   Dopo una risposta affermativa da parte del cliente, il personale del supporto Oracle può eseguire il login alla VM guest del cliente per risolvere il problema.

2. Situazioni in cui un numero di database esiste nel sistema del cliente e il cliente ha accesso alla VM guest, ma ora il supporto deve eseguire il login alla VM guest per risolvere una delle numerose situazioni

   Si è verificato un errore (i nodi non vengono avviati a causa delle modifiche apportate alla VM guest, ad esempio gli accessi non esistenti in fstab, la necessità di eseguire fsck, la modifica alla configurazione Hugepage / sysctl o il backup lvm non sono stati completati correttamente, fstab contiene voci errate per gli accessi non esistenti, il cliente ha modificato le configurazioni o le autorizzazioni sshd nel file /etc/ssh/sshd_config e così via oppure semplicemente perché il cliente desidera che Oracle aiuti a risolvere il problema che sta affrontando.

   Questo caso è più grave del primo in quanto potrebbero esserci alcuni dati riservati nel file system o nel database delle VM guest del cliente. In questo caso, il nostro staff di supporto sarà tenuto a chiedere al cliente di aprire una nuova RS esplicita specificamente per ottenere questa autorizzazione con il seguente titolo e contenuto della RS.

   In base ai criteri di sicurezza associati al servizio ExaDB-D, il personale Oracle non è autorizzato ad accedere alla VM guest del cliente senza l'autorizzazione esplicita del cliente. Affinché Oracle sia conforme a questa policy, siamo tenuti a chiederti di aprire una nuova RS con la lingua esatta, come mostrato di seguito, concedendo a Oracle un'autorizzazione esplicita per accedere al guest VM.Please. Qualsiasi modifica alla lingua riportata di seguito potrebbe ritardare la risoluzione della tua RS.

   Nuovo titolo RS: richiesta di servizio che concede a Oracle l'autorizzazione esplicita per accedere a DomU di ExaDB-C@C con numero di serie AK AK99999999

   Nuovo contenuto della richiesta di servizio: stiamo aprendo questa richiesta di servizio per concedere a Oracle l'autorizzazione esplicita ad accedere al nostro sito Web DomU per consentire al supporto di risolvere il problema descritto in SR# 1-xxxxxxxx.

   Riconosciamo che, fornendo questa autorizzazione, siamo consapevoli del fatto che Oracle avrà accesso a TUTTI I FILE in DomU e accettiamo che non vi siano dati riservati

   file memorizzati in uno qualsiasi dei file system di DomU. Inoltre, accettiamo che il team di sicurezza dei clienti abbia autorizzato Oracle ad accedere al cliente DomU

   per risolvere il problema descritto nella richiesta di servizio precedente.

   Dopo una risposta affermativa da parte del cliente nella richiesta di servizio sopra riportata, il personale del supporto Oracle può eseguire il login alla VM guest del cliente per risolvere il problema.

Un elenco delle responsabilità di Oracle Cloud Operations e delle responsabilità dei clienti per varie operazioni per componenti

• KMS Integration (chiavi HSM)
  Oracle Exadata Database Service on Dedicated Infrastructure ha l'integrazione con il servizio OCI Vault per proteggere i dati in archivio per i suoi database. Gli utenti ora hanno il controllo per creare e gestire le chiavi principali TDE all'interno del vault OCI che proteggono i database Exadata.
• Utilizzo di algoritmi di cifratura non predefiniti per la cifratura della tablespace TDE