In questa sezione vengono descritti i meccanismi di sicurezza specifici offerti dal prodotto.
Di seguito sono elencati i principali problemi che preoccupano gli utenti che dispongono di agenti che supportano la cifratura.
Divulgazione di informazioni in violazione dei criteri
Perdita o danneggiamento dei dati
Ritardo inaccettabile nel ripristino dei dati in caso di errore irreversibile (ad esempio, in sede di continuità aziendale)
Modifica dei dati non rilevata.
Gli obiettivi delle funzioni di sicurezza di Oracle Key Manager sono riportati di seguito.
Protezione dei dati cifrati dalla divulgazione.
Riduzione dell'esposizione agli attacchi.
Offerta di affidabilità e disponibilità sufficientemente alte.
In questa sezione della guida per la sicurezza viene offerta una panoramica di alto livello delle minacce che il sistema è progettato per affrontare e di come si combinano le singole funzioni di sicurezza per impedire gli attacchi.
Le funzioni di sicurezza fondamentali che offrono questa protezione sono riportate di seguito.
Autenticazione: garantisce che solo le persone autorizzate ottengano l'accesso al sistema e ai dati.
Autorizzazione: controllo dell'accesso ai privilegi e ai dati del sistema. Questo controllo dell'accesso si basa sull'autenticazione per garantire che ai singoli utenti sia consentito solo l'accesso appropriato.
Controllo: consente agli amministratori di rilevare i tentativi di violazione del meccanismo di autenticazione e i tentativi o le violazioni al controllo dell'accesso.
Per ulteriori informazioni sugli aspetti correlati alla sicurezza e all'autenticazione in Oracle Key Manager, consultare Oracle Key Manager Version 2.x Security and Authentication White Paper all'indirizzo:
L'architettura di Oracle Key Manager offre l'autenticazione reciproca tra tutti gli elementi del sistema: da KMA a KMA, dall'agente alla KMA e dall'interfaccia GUI o CLI di Oracle Key Manager alla KMA per le operazioni dell'utente.
Ciascun elemento del sistema (ad esempio, un nuovo agente di cifratura) deve essere iscritto nel sistema tramite la creazione di un ID e una passphrase in OKM che vengono quindi inseriti nell'elemento da aggiungere. Ad esempio, quando si aggiunge un'unità nastro al sistema, l'agente e la KMA eseguono automaticamente un protocollo challenge-response basato sulla passphrase condivisa che consente all'agente di ottenere il certificato dall'autorità di certificazione root (CA, Certificate Authority), nonché una nuova coppia di chiavi e un certificato firmato per l'agente. Una volta ottenuti il certificato CA root, il certificato dell'agente e una coppia di chiavi, l'agente può eseguire il protocollo TLS (Transport Layer Security) per tutte le comunicazioni successive con le KMA. Tutti i certificati sono X.509.
OKM si comporta come un'autorità di certificazione root per generare un certificato root utilizzato dalle KMA per derivare (autofirmare) i certificati utilizzati da agenti, utenti e nuove KMA.
Di seguito sono elencati i tipi di controllo dell'accesso disponibili.
Controllo dell'accesso basato su utenti e ruoli
Protezione del quorum.
Oracle Key Manager consente di definire più utenti, ciascuno con un ID utente e una passphrase diversi. A ciascun utente vengono assegnati uno o più ruoli predefiniti. Questi ruoli determinano le operazioni consentite a un utente in un sistema Oracle Key Manager. Di seguito sono elencati i ruoli disponibili.
Security Officer: esegue le operazioni di configurazione e gestione di Oracle Key Manager.
Operator: esegue la configurazione dell'agente e le operazioni quotidiane.
Compliance Officer: definisce i gruppi di chiavi e controlla l'accesso dell'agente a tali gruppi.
Backup Operator: esegue le operazioni di backup.
Auditor: visualizza gli audit trail del sistema.
Quorum Member: visualizza e approva le operazioni di quorum in sospeso.
Durante il processo QuickStart viene definito un Security Officer, che configura una KMA in un cluster di OKM. In seguito, un utente deve eseguire il login al cluster come Security Officer utilizzando l'interfaccia GUI di Oracle Key Manager per definire ulteriori utenti. Il Security Officer può scegliere di assegnare più ruoli a un determinato utente e può anche scegliere di assegnare un determinato ruolo a più utenti.
Per ulteriori informazioni sulle operazioni consentite da ciascun ruolo e su come un Security Officer crea gli utenti e assegna loro i ruoli, consultare il manuale Oracle Key Manager Administration Guide incluso nella libreria della documentazione di Oracle Key Manager all'indirizzo:
http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto
Questo controllo dell'accesso basato sul ruolo supporta i ruoli operativi elencati nel documento Special Publication (SP) 800-60 del National Institute of Standards and Technology (NIST) per distinguere le funzioni operative.
Alcune operazioni sono sufficientemente critiche per richiedere un livello di sicurezza aggiuntivo. Queste operazioni includono l'aggiunta di una KMA a un cluster di OKM, lo sblocco di una KMA, la creazione di utenti e l'aggiunta di ruoli agli utenti. Per implementare questa funzione di sicurezza, il sistema utilizza un insieme di credenziali di suddivisione della chiave oltre all'accesso basato sul ruolo descritto in precedenza.
Le credenziali di suddivisione della chiave sono costituite da un insieme di coppie di ID utente e passphrase, insieme al numero minimo di queste coppie necessario al sistema per consentire il completamento di determinate operazioni. Le credenziali di suddivisione della chiave vengono anche denominate "quorum" e il numero minimo "soglia di quorum".
Oracle Key Manager consente di definire un massimo di 10 coppie di ID utente/passphrase per la suddivisione della chiave e una soglia. Esse vengono definite durante il processo QuickStart, quando si configura la prima KMA in un cluster di OKM. Gli ID utente e le passphrase per la suddivisione della chiave sono diversi da quelli utilizzati per il login al sistema. Quando un utente tenta di eseguire un'operazione che richiede l'approvazione in base al quorum, prima che il sistema esegua questa operazione, è necessario che venga approvata in base alla soglia definita di utenti e passphrase per la suddivisione della chiave.
Ciascuna KMA registra gli eventi di controllo per le operazioni eseguite, incluse quelle effettuate da agenti, utenti e altre KMA nel cluster di OKM. Le KMA registrano gli eventi di controllo anche ogni volta che un agente, un utente o un'altra KMA non riesce a eseguire l'autenticazione. Gli eventi di controllo che indicano una violazione della sicurezza vengono annotati. Una mancata autenticazione è un esempio di evento di controllo che indica una violazione della sicurezza. Se nel cluster di OKM vengono identificati agenti SNMP, le KMA inviano SNMP INFORM anche a tali agenti SNMP in caso di violazione della sicurezza. Se la funzione di syslog remoto è configurata, una KMA inoltrerà anche questi messaggi di controllo ai server configurati. Vedere Syslog remoto.
Per poter visualizzare gli eventi di controllo, è prima necessario che l'utente esegua correttamente il login al cluster di OKM e disponga di un ruolo assegnato.
Le KMA gestiscono i propri eventi di controllo. Le KMA rimuovono gli eventi di controllo precedenti in base ai termini e ai limiti (numerici) impostati per la conservazione. Se necessario, il Security Officer può modificare questi termini e limiti di conservazione.
In Oracle Key Manager sono disponibili altre funzioni di sicurezza. Per ulteriori informazioni su queste e altre funzioni di OKM, consultare il documento Oracle Key Manager Overview all'indirizzo:
Il protocollo di comunicazione tra un agente e una KMA, un utente e una KMA oppure una KMA e un'altra KMA è lo stesso. In ogni caso, il sistema utilizza la passphrase per l'entità che avvia la comunicazione per eseguire un protocollo challenge-response. In caso di successo, all'entità viene fornito un certificato e la chiave privata corrispondente. Il certificato e la chiave privata possono stabilire un canale TLS (Transport Layer Security) (socket sicuri). Viene eseguita l'autenticazione reciproca; ciascuna estremità di una connessione esegue l'autenticazione dell'altra parte. Le KMA di OKM 3.1+ utilizzeranno sempre TLS 1.2 per il relativo traffico di replica peer to peer.
Le KMA dispongono di un Hardware Security Module, ordinato separatamente. Tale Hardware Security Module, una scheda SCA (Sun Cryptographic Accelerator) 6000, era conforme alla certificazione FIPS 140-2 livello 3 e fornisce chiavi di cifratura AES (Advanced Encryption Standard) a 256 bit (questo certificato è scaduto il 31/12/2015 e non è stato rinnovato; un HSM alternativo verrà fornito nelle release successive). La scheda SCA 6000 supporta una modalità di funzionamento conforme alla certificazione FIPS 140-2 livello 3 e viene sempre utilizzata in questa modalità in OKM. Quando il cluster di OKM opera in modalità conforme alla certificazione FIPS, le chiavi di cifratura nascondono il limite di cifratura della scheda SCA 6000. La scheda SCA 6000 utilizza un generatore di numeri casuali approvato in base alla certificazione FIPS, come specificato in FIPS 186-2 DSA Random Number Generator, utilizzando SHA-1 per la creazione delle chiavi di cifratura.
Quando una KMA non è configurata con una scheda SCA 6000, la cifratura viene eseguita utilizzando il token SCF (Solaris Cryptographic Framework) PKCS#11. SCF è configurato in modalità FIPS 140 in base ai più recenti criteri di sicurezza Solaris FIPS 140-2 pubblicati.
Oracle Key Manager utilizza la funzionalità AES Key Wrapping (RFC 3994) con le chiavi di cifratura a 256 bit per proteggere le chiavi simmetriche quando vengono create, memorizzate sulla KMA, trasmesse agli agenti o nei file di trasferimento della chiave.
Quando viene inizializzata la prima KMA di un cluster di OKM, la KMA genera un grande pool di chiavi. Quando vengono aggiunte ulteriori KMA al cluster, le chiavi vengono replicate nelle nuove KMA e possono essere quindi utilizzate per la cifratura dei dati. Ciascuna KMA aggiunta al cluster genera un pool di chiavi e le replica nelle altre KMA del cluster. Tutte le KMA generano le nuove chiavi necessarie per mantenere la dimensione del pool di chiavi in modo che siano sempre disponibili chiavi per gli agenti. Per richiedere una nuova chiave, un agente contatta una KMA nel cluster e la richiede. La KMA estrae una chiave dal pool di chiavi e la assegna al gruppo di chiavi predefinito dell'agente e all'unità dati. La KMA replica quindi questi aggiornamenti al database attraverso la rete sulle altre KMA nel cluster. In seguito, l'agente può contattare un'altra KMA nel cluster per recuperare la chiave. La trasmissione nella rete di materiale correlato alla chiave in testo leggibile non è mai consentita.
In dicembre 2013, il National Institute of Standards and Technology (NIST) ha conferito il certificato di convalida FIPS 140-2 livello 1 n. 2061 per il modulo Oracle Solaris Kernel Cryptographic Framework in Solaris 11. In gennaio 2014, NIST ha conferito il certificato FIPS 140-2 livello 1 n. 2076 per Oracle Solaris Userland Cryptographic Framework con SPARC T4 e SPARC T5. La KMA di Oracle Key Manager 3.1.0 è ora basata su Solaris 11.3 che è ancora in fase di test di convalida per FIPS 140-2. Oracle Solaris Kernel Cryptographic Framework in una KMA di Oracle Key Manager 3.1.0 viene configurato in base a quanto riportato nel documento Oracle Kernel Cryptographic Framework Security Policy. Allo stesso modo, anche la KMA viene configurata in base a quando riportato nel documento Oracle Solaris Userland Cryptographic Framework with SPARC T4 and SPARC T5 Security Policy. OKM effettuerà l'aggiornamento ai più recenti criteri di sicurezza Solaris non appena diventeranno disponibili.