Gestione TDE (Transparent Data Encryption)

Questa sezione comprende la gestione di Transparent Data Encryption (TDE) per la protezione dei dati del database. Include comandi per la gestione delle chiavi di cifratura e dei keystore, ad esempio dbaascli tde addSecondaryHsmKey per aggiungere chiavi HSM secondarie, dbaascli tde rotateMasterKey per ruotare la chiave master e dbaascli tde encryptTablespacesInPDB per cifrare le tablespace all'interno di un pluggable database. È inoltre possibile eseguire la conversione tra FILE e TDE basato su HSM (dbaascli tde fileToHsm, dbaascli tde hsmToFile), gestire le versioni delle chiavi e recuperare i dettagli delle chiavi con vari comandi. Questi strumenti garantiscono una gestione efficace della crittografia e la sicurezza dei dati.

dbaascli tde addSecondaryHsmKey

Per aggiungere una chiave HSM (KMS) secondaria alla configurazione HSM (KMS) esistente, utilizzare il comando dbaascli tde addSecondaryHsmKey.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde addSecondaryHsmKey --dbname <value> --secondaryKmsKeyOCID <value>
[--executePrereqs]

Parametri:

Parametro Descrizione
--secondaryKmsKeyOCID specifica la chiave KMS secondaria da aggiungere alla configurazione HSM (KMS) esistente
--dbname specifica il nome del database.
--executePrereqs eseguire i controlli dei prerequisiti e segnalare i risultati.

Domande frequenti:

D: Che cosa fa il comando dbaascli tde addSecondaryHsmKey?

R: il comando dbaascli tde addSecondaryHsmKey aggiunge una chiave HSM (KMS) secondaria alla configurazione HSM (KMS) esistente per un database Oracle Base Database Cloud@Customer.

D: Chi dovrebbe eseguire il comando dbaascli tde addSecondaryHsmKey?

R: Il comando deve essere eseguito come utente root.

Q: Su quale macchina dovrei eseguire il comando dbaascli tde addSecondaryHsmKey?

R: Per eseguire questo comando, è necessario connettersi a una virtual machine Oracle Base Database Cloud@Customer utilizzando SSH.

D: Dove posso trovare maggiori dettagli sulla connessione a una macchina virtuale per eseguire questo comando?

R: Per istruzioni sulla connessione, fare riferimento alla guida Connessione a una virtual machine con SSH.

D: Che cosa specifica l'opzione –secondaryKmsKeyOCID?

R: l'opzione --secondaryKmsKeyOCID specifica l'OCID (identificativo Oracle Cloud) della chiave KMS secondaria da aggiungere alla configurazione HSM (KMS) esistente.

D: Cosa fa l'opzione –dbname?

R: L'opzione --dbname consente di specificare il nome del database per il quale deve essere aggiunta la chiave KMS secondaria. Si tratta di un parametro facoltativo.

D: Cosa fa l'opzione –precheckOnly?

R: L'opzione --precheckOnly, se impostata su yes, esegue un controllo preliminare dell'operazione senza apportare modifiche effettive. I valori validi sono yes o no.

D: Posso eseguire il controllo preliminare solo senza apportare modifiche?

R: Sì, è possibile utilizzare l'opzione --precheckOnly yes per eseguire solo il controllo preliminare senza apportare modifiche.

D: Puoi dare un esempio di come eseguire questo comando per aggiungere una chiave HSM secondaria?

A: Di seguito è riportato un esempio.

dbaascli tde addSecondaryHsmKey --secondaryKmsKeyOCID ocid1.kms.key.oc1..example

D: Come si esegue il comando per un database specifico?

R: È possibile specificare il nome del database in questo modo:

dbaascli tde addSecondaryHsmKey --secondaryKmsKeyOCID ocid1.kms.key.oc1..example --dbname mydatabase

D: Come faccio a eseguire il comando solo con un controllo preliminare?

A: Per eseguire il controllo preliminare, utilizzare la seguente sintassi:

dbaascli tde addSecondaryHsmKey --secondaryKmsKeyOCID ocid1.kms.key.oc1..example --precheckOnly yes

D: Cosa devo fare se il comando fallisce?

R: assicurarsi di eseguire il comando come utente root e di aver eseguito la connessione alla virtual machine Oracle Base Database Cloud@Customer corretta. Inoltre, verificare l'OCID della chiave KMS e verificare se le autorizzazioni necessarie sono concesse.

D: Come posso verificare se ho l'OCID corretto per la chiave KMS secondaria?

R: è possibile recuperare l'OCID della chiave KMS dalla console di Oracle Cloud Infrastructure, nella sezione KMS (Key Management Service).

D: Quali autorizzazioni sono necessarie per aggiungere una chiave KMS secondaria?

R: È necessario disporre delle autorizzazioni appropriate in Oracle Cloud Infrastructure per le operazioni KMS, inclusa la possibilità di gestire le chiavi KMS per il compartimento pertinente.

D: Posso usare il comando dbaascli tde addSecondaryHsmKey senza specificare l'opzione –dbname?

R: Sì, l'opzione --dbname è facoltativa. Se omesso, il comando si applica a tutti i database che utilizzano la configurazione HSM (KMS) esistente.

D: Cosa succede se aggiungo una chiave KMS secondaria?

A: la chiave KMS secondaria verrà aggiunta alla configurazione esistente, fornendo un livello aggiuntivo di ridondanza della gestione delle chiavi di cifratura.

D: Posso rimuovere una chiave KMS secondaria una volta aggiunta?

R: No, una volta aggiunta una chiave KMS secondaria, non è possibile rimuoverla. È possibile ruotare o aggiornare le chiavi solo in futuro.

Esempio: dbaascli tde addSecondaryHsmKey

dbaascli tde addSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde addSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --precheckOnly yes

dbaascli tde changePassword

Per modificare la password di keystore TDE e la password di wallet DB per l'alias tde_ks_passwd, utilizzare il comando dbaascli tde changePassword.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde changePassword [--dbname <value>]
  {            [--prepareStandbyBlob <value> [--blobLocation <value>]]
               | [--standbyBlobFromPrimary <value>]
  }
  [--resume [--sessionID <value>]]

Parametri:

Parametro Descrizione
--dbname specifica il nome del database.
--prepareStandbyBlob specifica true per generare un file BLOB che contenga gli artifact necessari per eseguire l'operazione in un ambiente Data Guard.
--blobLocation percorso personalizzato in cui verrà generato il file dell'oggetto Blob di standby in un ambiente DG.
--standbyBlobFromPrimary Specificare la posizione del file dell'oggetto BLOB di standby preparato dal database primario. Questa operazione è obbligatoria solo per le operazioni in standby.
--resume per riprendere l'esecuzione precedente
--sessionID consente di riprendere un ID sessione specifico.

Domande frequenti:

D: Che cosa fa il comando dbaascli tde changePassword?

R: il comando dbaascli tde changePassword modifica la password del keystore TDE (Transparent Data Encryption) e la password del wallet del database per l'alias tde_ks_passwd.

D: Chi dovrebbe eseguire il comando dbaascli tde changePassword?

R: Il comando deve essere eseguito come utente root.

D: Quando dovrei usare il comando dbaascli tde changePassword?

A: utilizzare questo comando quando è necessario modificare la password del keystore TDE o la password del wallet DB per un database Oracle Base Database Cloud@Customer.

D: Cosa fa l'opzione –dbname?

R: l'opzione --dbname specifica il nome del database per il quale si desidera modificare la password del keystore TDE.

D: Cosa fa l'opzione –pdbName?

R: l'opzione --pdbName specifica il nome del pluggable database (PDB) per il quale è necessario modificare la password del keystore TDE. Questa opzione viene utilizzata per i database multi-tenant.

D: Puoi dare un esempio di come eseguire questo comando per un database specifico?

A: Di seguito è riportato un esempio per modificare la password del keystore TDE per un database specifico.

dbaascli tde changePassword --dbname mydatabase

D: Come eseguire il comando per un PDB specifico all'interno di un database multi-tenant?

R: È possibile specificare il nome del PDB utilizzando la seguente sintassi:

dbaascli tde changePassword --dbname mydatabase --pdbName mypdb

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde changePassword?

R: È necessario eseguire il comando come utente root e avere accesso alla virtual machine Oracle Base Database Cloud@Customer in cui è in esecuzione il database.

D: È necessario arrestare il database per modificare la password del keystore TDE?

R: No, non è necessario arrestare il database per modificare la password del keystore TDE.

D: Cosa devo fare se il comando fallisce?

R: assicurarsi di eseguire il comando come utente root e che il nome del database (--dbname) e il nome PDB (--pdbName, se applicabile) siano corretti.

D: Cosa succede se viene visualizzato un errore "password non valida" quando si modifica la password del keystore TDE?

R: Assicurarsi che la nuova password soddisfi i requisiti di complessità delle password del sistema e di immettere la vecchia password corretta, se richiesto.

D: Come verificare se la password del keystore TDE è stata modificata correttamente?

R: È possibile controllare i log del database o utilizzare le viste Oracle AI Database Vault and Key Management per verificare che la modifica della password del keystore TDE sia riuscita.

D: Posso modificare la password del keystore TDE per un database multi-tenant e tutti i PDB contemporaneamente?

R: No, il comando dbaascli tde changePassword deve essere eseguito per ogni PDB singolarmente se è necessario modificare la password per più PDB.

D: Cosa succede se dimentico la nuova password del keystore TDE?

A: se si dimentica la nuova password, potrebbe essere necessario ripristinare il keystore da un backup o seguire il processo di recupero di Oracle per reimpostarlo, a seconda dell'impostazione.

D: Posso automatizzare il processo di modifica della password del keystore TDE?

R: Sebbene il comando dbaascli tde changePassword stesso non sia progettato per l'automazione, è possibile eseguirne lo script come parte delle normali procedure di manutenzione del database, se necessario.

D: Con quale frequenza devo modificare la password del keystore TDE?

R: Oracle consiglia di modificare periodicamente la password del keystore TDE in base ai criteri di sicurezza dell'organizzazione. In genere, le procedure ottimali prevedono la rotazione regolare delle chiavi di cifratura e delle password del keystore.

Per modificare la password TDE in un ambiente non Data Guard

dbaascli tde changepassword --dbname
      <dbname>

Per modificare la password TDE in un ambiente Data Guard

  1. Modificare la password TDE nel database primario.

    dbaascli tde changepassword --dbname
      <dbname> --prepareStandbyBlob true --blobLocation
      <Location where blob file has to be generated>

  2. Copiare l'oggetto BLOB di standby creato nell'ambiente del database di standby.

  3. Modificare la password TDE nel database di standby

    dbaascli tde changepassword --dbname
     <dbname> --standbyBlobFromPrimary <Location of blob generated from
    primary>

dbaascli tde enableWalletRoot

Per abilitare il parametro spfile wallet_root per il database esistente, utilizzare il comando dbaascli tde enableWalletRoot.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde enableWalletRoot --dbname <value>
[--dbRestart <value>]
[--executePrereqs]
[--resume [--sessionID <value>]]

Parametri:

Parametro Descrizione
--dbname specifica il nome di Oracle AI Database.
--dbrestart specifica l'opzione di riavvio del database. I valori validi sono: rolling o full. Valore predefinito: rolling. Se non si passa l'argomento dbrestart, il database viene riavviato in modo rolling.
--precheckOnly esegue solo il controllo preliminare per questa operazione. I valori validi sono: yes o no
--resume per riprendere l'esecuzione precedente
--sessionID consente di riprendere un ID sessione specifico.

Domande frequenti:

D: Che cosa fa il comando dbaascli tde enableWalletRoot?

R: il comando dbaascli tde enableWalletRoot abilita il parametro wallet_root in spfile per un Oracle AI Database esistente in Oracle Base Database Cloud@Customer.

D: Chi dovrebbe eseguire il comando dbaascli tde enableWalletRoot?

R: Il comando deve essere eseguito come utente root.

Q: Su quale macchina dovrei eseguire il comando dbaascli tde enableWalletRoot?

R: Per eseguire questo comando, è necessario connettersi a una virtual machine Oracle Base Database Cloud@Customer utilizzando SSH.

D: Dove posso trovare le istruzioni per collegarmi alla macchina virtuale?

R: Per istruzioni sulla connessione, è possibile fare riferimento alla guida Connessione a una virtual machine con SSH.

D: Cosa fa l'opzione –dbRestart?

R: L'opzione --dbRestart specifica come riavviare il database dopo aver abilitato wallet_root. I valori validi sono:

D: Cosa fa l'opzione –dbname?

R: l'opzione --dbname consente di specificare il nome di Oracle AI Database per il quale deve essere abilitato il parametro wallet_root.

D: Cosa fa l'opzione –precheckOnly?

A: L'opzione --precheckOnly esegue un controllo preliminare dell'operazione senza apportare modifiche effettive. I valori validi sono yes o no.

D: Cosa succede se non si specifica l'opzione –dbRestart?

R: Se non si specifica l'opzione --dbRestart, il database verrà riavviato in sequenza per impostazione predefinita.

D: Puoi dare un esempio di come abilitare wallet_root per un database specifico?

A: Di seguito è riportato un esempio per abilitare wallet_root per un database denominato mydatabase.

dbaascli tde enableWalletRoot --dbname mydatabase

D: Come abilitare wallet_root e specificare un riavvio completo del database?

R: È possibile abilitare wallet_root con un riavvio completo del database utilizzando il seguente comando:

dbaascli tde enableWalletRoot --dbname mydatabase --dbRestart full

D: Come faccio a eseguire il comando solo con un controllo preliminare?

A: Per eseguire un controllo preliminare senza apportare modifiche, utilizzare la seguente sintassi:

dbaascli tde enableWalletRoot --dbname mydatabase --precheckOnly yes

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde enableWalletRoot?

R: È necessario eseguire il comando come utente root ed essere connessi alla virtual machine Oracle Base Database Cloud@Customer corretta.

D: È necessario riavviare il database per abilitare wallet_root?

R: Sì, il database dovrà essere riavviato in sequenza (impostazione predefinita) o completamente, a seconda dell'opzione scelta.

D: Cosa devo fare se il comando fallisce?

R: Assicurarsi di eseguire il comando come utente root e verificare che il nome del database (--dbname) sia corretto. Controllare eventuali errori di controllo preliminare se si utilizza --precheckOnly.

D: Cosa succede se il database non si riavvia dopo l'esecuzione del comando?

R: Verificare che sia stata utilizzata l'opzione di riavvio corretta (rolling o full) e controllare gli eventuali errori nei log del database. Potrebbe essere necessario riavviare manualmente il database se il riavvio automatico non riesce.

D: Come posso verificare se wallet_root è stato abilitato con successo?

R: È possibile verificare la modifica controllando spfile del database o utilizzando query Oracle SQL per confermare che il parametro wallet_root è abilitato.

D: Posso abilitare wallet_root senza riavviare il database?

R: No, il database deve essere riavviato per rendere effettiva la modifica. È possibile scegliere tra un riavvio in sequenza o un riavvio completo.

D: Qual è la differenza tra un riavvio in sequenza e completo del database?

A: un riavvio in sequenza riavvia il database un'istanza alla volta, consentendo al database di rimanere parzialmente disponibile durante l'operazione. Un riavvio completo arresta e riavvia l'intero database, causando un tempo di inattività completo.

D: Posso eseguire questo comando per più database contemporaneamente?

R: È necessario eseguire il comando dbaascli tde enableWalletRoot separatamente per ogni database su cui si desidera abilitare wallet_root.

D: In che modo l'abilitazione di wallet_root influisce sulla configurazione del keystore TDE esistente?

R: l'abilitazione di wallet_root aggiorna la posizione del keystore TDE nella nuova directory radice del wallet, semplificando la gestione di più keystore e wallet nei database Oracle AI.

Esempio: dbaascli tde enableWalletRoot

dbaascli tde enableWalletRoot --dbname db name --dbrestart rolling|full
dbaascli tde enableWalletRoot --dbname orcl
dbaascli tde enableWalletRoot --dbname orcl--dbrestart full

dbaascli tde encryptTablespacesInPDB

Per cifrare tutte le tablespace nel PDB specificato, utilizzare il comando dbaascli tde encryptTablespacesInPDB.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde encryptTablespacesInPDB --dbname <value> --pdbName <value>
[--executePrereqs]

Parametri:

Parametro Descrizione
--pdbName specifica il nome del PDB per cifrare tutte le tablespace.
--dbname specifica il nome di Oracle AI Database.
--executePrereqs eseguire i controlli dei prerequisiti e segnalare i risultati.

Domande frequenti:

D: Che cosa fa il comando dbaascli tde encryptTablespacesInPDB?

R: il comando dbaascli tde encryptTablespacesInPDB cifra tutte le tablespace nel pluggable database (PDB) specificato per un Oracle AI Database su Oracle Base Database Cloud@Customer.

D: Chi dovrebbe eseguire il comando dbaascli tde encryptTablespacesInPDB?

R: Il comando deve essere eseguito come utente root.

Q: Su quale macchina dovrei eseguire il comando dbaascli tde encryptTablespacesInPDB?

R: Per eseguire questo comando, è necessario connettersi a una virtual machine Oracle Base Database Cloud@Customer utilizzando SSH.

D: Dove posso trovare le istruzioni per il collegamento alla macchina virtuale?

R: per istruzioni sulla connessione, fare riferimento alla guida Connessione a una virtual machine con SSH.

D: Che cosa specifica l'opzione –pdbName?

R: L'opzione --pdbName specifica il nome del pluggable database (PDB) le cui tablespace devono essere cifrate.

D: Cosa fa l'opzione –dbname?

R: l'opzione --dbname consente di specificare il nome di Oracle AI Database a cui appartiene il PDB.

D: Cosa fa l'opzione –precheckOnly?

R: L'opzione --precheckOnly esegue un controllo preliminare dell'operazione di cifratura senza apportare modifiche effettive. I valori validi sono yes o no.

D: Cosa fa l'opzione –useSysdbaCredential?

A: l'opzione --useSysdbaCredential specifica se le credenziali SYSDBA devono essere utilizzate per l'operazione. I valori validi sono true o false.

D: È possibile fornire un esempio di come cifrare le tablespace in un PDB specifico?

A: Di seguito è riportato un esempio di cifratura di tutte le tablespace in un PDB denominato mypdb.

dbaascli tde encryptTablespacesInPDB --pdbName mypdb

D: Come cifrare le tablespace in un PDB specifico all'interno di un database?

A: utilizzare il comando seguente per specificare sia il PDB che il database:

dbaascli tde encryptTablespacesInPDB --pdbName mypdb --dbname mydatabase

D: Come faccio a eseguire un controllo preliminare senza eseguire la crittografia?

R: È possibile eseguire un controllo preliminare solo utilizzando la seguente sintassi:

dbaascli tde encryptTablespacesInPDB --pdbName mypdb --precheckOnly yes

D: Come si utilizzano le credenziali SYSDBA per cifrare le tablespace?

R: È possibile utilizzare le credenziali SYSDBA aggiungendo l'opzione --useSysdbaCredential true:

dbaascli tde encryptTablespacesInPDB --pdbName mypdb --useSysdbaCredential true

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde encryptTablespacesInPDB?

R: È necessario eseguire il comando come utente root e avere accesso alla virtual machine Oracle Base Database Cloud@Customer.

D: È necessario riavviare il database per cifrare le tablespace?

R: No, il comando non richiede il riavvio del database. La cifratura viene eseguita mentre il database è in linea.

D: Per cifrare le tablespace sono necessarie le credenziali SYSDBA?

R: Potrebbero essere necessarie credenziali SYSDBA per questa operazione se specificate utilizzando l'opzione --useSysdbaCredential.

D: Cosa devo fare se il comando fallisce?

R: assicurarsi di eseguire il comando come utente root e verificare che il nome del PDB (--pdbName) e il nome del database (--dbname) siano corretti. È inoltre possibile eseguire il comando con --precheckOnly yes per verificare la presenza di problemi prima di eseguire la cifratura completa.

D: Cosa devo fare se la crittografia delle tablespace non riesce?

R: Controllare i log del database e assicurarsi di disporre dei privilegi e delle risorse necessari per eseguire la cifratura. Potrebbe inoltre essere necessario verificare che lo spazio disponibile sia sufficiente per gestire il processo di cifratura.

D: Come faccio a verificare se le tablespace in un PDB sono cifrate?

R: è possibile eseguire una query sulle viste di database correlate alla cifratura, ad esempio V$ENCRYPTED_TABLESPACES, per verificare se la cifratura delle tablespace è riuscita.

D: Come faccio a verificare se il controllo preliminare è riuscito?

R: Se hai eseguito il comando con --precheckOnly yes, puoi controllare l'output per eventuali avvertenze o errori che indicano potenziali problemi con il processo di crittografia.

D: Posso cifrare le tablespace per più PDB contemporaneamente?

R: No, è necessario eseguire il comando dbaascli tde encryptTablespacesInPDB separatamente per ogni PDB.

D: È possibile cifrare parzialmente alcune tablespace in un PDB?

R: No, questo comando cifra tutte le tablespace all'interno del PDB specificato. Per la cifratura parziale, è necessario utilizzare comandi di gestione del database diversi.

D: La cifratura delle tablespace influisce sulle prestazioni del database?

R: La cifratura delle tablespace può avere un impatto temporaneo sulle prestazioni durante il processo di cifratura. Tuttavia, l'impatto dovrebbe essere minimo una volta completata la crittografia.

D: Posso annullare la crittografia delle tablespace?

R: No, una volta cifrate le tablespace, non è possibile annullare la cifratura. È possibile ruotare o ripetere la cifratura dei tasti solo se necessario.

D: Cosa succede se l'operazione viene interrotta durante il processo di crittografia?

A: Se l'operazione viene interrotta, potrebbe essere necessario rieseguire il comando. Il sistema riprenderà la cifratura da dove è stata interrotta ed è possibile verificarne lo stato utilizzando le viste del database.

Esempio: dbaascli tde encryptTablespacesInPDB

dbaascli tde encryptTablespacesInPDB --dbname dbname --pdbName pdb
dbaascli tde encryptTablespacesInPDB --dbname dbname --pdbName pdb --executePrereqs

dbaascli tde fileToHsm

Per convertire la cifratura TDE basata su FILE su HSM (KMS/OKV) in cifratura TDE basata su HSM (KMS/OKV), utilizzare il comando dbaascli tde fileToHsm.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde fileToHsm --kmsKeyOCID <value> --dbname <value>
[--skipPatchCheck <value>]
[--executePrereqs ]
[--primarySuc <value>]
{
    [--resume [--sessionID <value>]] | [--revert [--sessionID <value>]]
}
[--waitForCompletion <value>]

Parametri:

Parametro Descrizione
--kmsKeyOCID specifica l'OCID della chiave KMS da utilizzare per TDE. Applicabile solo se il valore KMS è selezionato per la TDE
--dbname specifica il nome del database
--skipPatchCheck salta la verifica di convalida per le patch richieste se il valore passato per questo argomento è true. Valori validi: true o false
--executePrereqs eseguire i controlli dei prerequisiti e segnalare i risultati.
--primarySuc specificare questa proprietà nel database in standby di un ambiente Data Guard dopo l'esecuzione riuscita del comando sul database primario.
--resume specifica di riprendere l'esecuzione precedente
--sessionID specifica di riprendere un ID sessione specifico
--revert specifica di eseguire il rollback dell'esecuzione precedente
--sessionID specifica di eseguire il rollback di un ID sessione specifico
--waitForCompletion specificare false per eseguire l'operazione in background. Valori validi: true o false.

Domande frequenti:

D: Qual è lo scopo del comando dbaascli tde fileToHsm?

R: il comando dbaascli tde fileToHsm viene utilizzato per convertire un TDE basato su FILE Transparent Data Encryption (TDE) in un TDE basato su Hardware Security Module (HSM), come KMS o OKV, in un ambiente Oracle AI Database Cloud Service.

D: Chi può eseguire il comando dbaascli tde fileToHsm?

R: Il comando deve essere eseguito come utente root.

D: Qual è lo scopo del parametro –kmsKeyOCID?

R: il parametro --kmsKeyOCID specifica l'OCID della chiave KMS che verrà utilizzato per la cifratura TDE durante la transizione dalla TDE basata su file a quella basata su HSM.

D: Che cosa fa il parametro –dbname?

R: il parametro --dbname specifica il nome del database per il quale si sta convertendo il TDE da basato su file a basato su HSM.

D: Posso saltare il controllo di convalida delle patch durante la conversione di TDE?

R: Sì, utilizzando il parametro --skipPatchCheck con il valore true, è possibile saltare il controllo di convalida per le patch richieste.

D: A cosa serve il parametro –executePrereqs?

R: Il parametro --executePrereqs consente di eseguire solo i controlli preliminari per il processo di conversione TDE senza eseguire la conversione effettiva. I valori validi sono yes o no.

D: Che cosa fa il parametro –primarySuc in un'impostazione Data Guard?

R: il parametro --primarySuc viene utilizzato in un ambiente Data Guard per indicare che il comando è stato eseguito correttamente nel database primario. Deve essere specificato nel database di standby dopo il completamento della conversione primaria.

D: Come posso riprendere una conversione TDE precedente?

R: È possibile riprendere una conversione TDE precedentemente incompleta utilizzando il parametro --resume. Facoltativamente, è possibile specificare un ID sessione specifico con --sessionID.

D: Come si ripristina una conversione TDE?

R: Per ripristinare una conversione TDE precedente, utilizzare il parametro --revert. È inoltre possibile fornire l'ID sessione specifico che si desidera ripristinare utilizzando --sessionID.

D: Come si specifica un ID sessione quando si riprende o si ripristina una conversione TDE?

R: È possibile utilizzare il parametro --sessionID per specificare l'ID della sessione che si desidera riprendere o ripristinare. Esempio: --resume --sessionID <ID> o --revert --sessionID <ID>.

D: Cosa succede se si imposta –waitForCompletion su falso?

R: Se si imposta --waitForCompletion su false, il processo di conversione TDE verrà eseguito in background e il prompt dei comandi verrà restituito immediatamente. Se impostato su true, il comando attenderà il completamento del processo prima di restituire il controllo all'utente.

D: Quali sono i valori validi per il parametro –waitForCompletion?

R: I valori validi sono true o false. L'impostazione su true rende il comando in attesa del completamento del processo; impostandolo su false, il processo viene eseguito in background.

D: Posso eseguire dbaascli TDE fileToHsm senza convertire immediatamente il TDE?

R: Sì, è possibile utilizzare il parametro --executePrereqs yes per eseguire solo i controlli preliminari per la conversione, senza apportare alcuna modifica al TDE.

D: In un ambiente Data Guard, come si gestisce il database di standby dopo aver convertito TDE sul database primario?

R: Dopo aver eseguito correttamente la conversione nel database primario, è necessario specificare --primarySuc quando si esegue il comando nel database di standby.

D: Cosa devo fare se il processo di conversione TDE fallisce?

R: Se il processo non riesce, è possibile utilizzare il parametro --resume per provare a riprendere da dove è stato interrotto. Se necessario, è possibile utilizzare il parametro --revert per eseguire il rollback delle modifiche apportate durante la sessione non riuscita.

Esempio: dbaascli tde fileToHsm –kmsKeyOCID

dbaascli tde fileToHSM --dbname dbname --kmsKeyOCID ocid1.key.oc1.eu-frankfurt-.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde fileToHSM --dbname dbname --kmsKeyOCID ocid1.key.oc1.eu-frankfurt-.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --executePrereqs
dbaascli tde fileToHSM --dbname dbname --kmsKeyOCID ocid1.key.oc1.eu-frankfurt-.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --resume

dbaascli tde getHsmKeys

Per ottenere i dettagli della chiave attiva TDE, utilizzare il comando dbaascli tde getHsmKeys.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde getHsmKeys
[--dbname]
[--infoFile]

Parametri:

Parametro Descrizione
--dbname specifica il nome del database
--infoFile specifica il percorso del file in cui verrà salvata la lista di OCID. Output in formato JSON

Domande frequenti:

D: Che cosa fa il comando dbaascli tde getHsmKeys?

R: il comando dbaascli tde getHsmKeys recupera i dettagli delle chiavi TDE (Transparent Data Encryption) attive dal modulo HSM (Hardware Security Module) per un database specificato.

D: Chi dovrebbe eseguire il comando dbaascli tde getHsmKeys?

R: Il comando deve essere eseguito come utente root.

Q: Su quale macchina dovrei eseguire il comando dbaascli tde getHsmKeys?

R: Per eseguire questo comando, è necessario connettersi a una virtual machine Oracle Base Database Cloud@Customer utilizzando SSH.

D: Dove posso trovare le istruzioni per il collegamento alla macchina virtuale?

R: Per istruzioni sulla connessione, fare riferimento alla guida Connessione a una virtual machine con SSH.

D: Cosa fa l'opzione –dbname?

R: L'opzione --dbname consente di specificare il nome di Oracle AI Database per il quale si desidera recuperare i dettagli della chiave TDE.

D: Cosa fa l'opzione –infoFile?

R: l'opzione --infoFile specifica il percorso del file in cui verrà salvata la lista degli OCID chiave (identificativi Oracle Cloud). L'output è in formato JSON.

D: Puoi dare un esempio di come recuperare i dettagli della chiave TDE per un database specifico?

A: Ecco un esempio per ottenere i dettagli della chiave TDE per un database denominato mydatabase:

dbaascli tde getHsmKeys --dbname mydatabase

D: Come si salvano i dettagli della chiave TDE in un file?

R: È possibile specificare un percorso file utilizzando l'opzione --infoFile per salvare l'output in formato JSON:

dbaascli tde getHsmKeys --dbname mydatabase --infoFile /path/to/output.json

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde getHsmKeys?

R: È necessario eseguire il comando come utente root ed essere connessi alla virtual machine Oracle Base Database Cloud@Customer.

D: Sono necessarie le credenziali SYSDBA per recuperare i dettagli della chiave TDE?

R: No, le credenziali SYSDBA non sono necessarie per eseguire il comando dbaascli tde getHsmKeys.

D: In quale formato vengono salvate le informazioni della chiave TDE quando si utilizza l'opzione –infoFile?

R: L'output viene salvato in formato JSON.

D: Quali informazioni sono incluse nei dettagli chiave TDE?

A: i dettagli includono gli OCID delle chiavi e altri metadati sulle chiavi di cifratura attive memorizzate nell'HSM per il database specificato.

D: Cosa devo fare se il comando non riesce a recuperare i dettagli chiave?

R: Assicurarsi di eseguire il comando come utente root e che il nome del database (--dbname) sia corretto. Controllare la connessione alla virtual machine Oracle Base Database Cloud@Customer.

D: Come faccio a verificare se il file di output è stato creato correttamente?

R: È possibile controllare il percorso del file specificato per il file JSON di output. Se il file non è presente, verificare che il percorso del file sia corretto e di disporre delle autorizzazioni di scrittura per la directory.

D: Cosa devo fare se il file di output è vuoto?

R: Assicurarsi che il database specificato contenga chiavi TDE attive e che il parametro --dbname sia corretto. Potrebbe inoltre essere necessario controllare se sono presenti errori nei log del database.

D: Posso recuperare i dettagli della chiave TDE per più database contemporaneamente?

R: No, è necessario eseguire il comando dbaascli tde getHsmKeys separatamente per ogni database.

D: Come posso utilizzare il file di output dell'opzione –infoFile in altre operazioni?

R: Poiché l'output è in formato JSON, è possibile analizzare il file a livello di programmazione o utilizzarlo come input per altri task di gestione del database o della cifratura.

D: È possibile ottenere i dettagli chiave TDE cronologici utilizzando questo comando?

R: No, il comando recupera solo i dettagli sulle chiavi attualmente attive nell'HSM.

D: Come faccio a verificare che le chiavi recuperate siano corrette?

R: Puoi verificare le chiavi facendo riferimento incrociato con la console di Oracle Cloud Infrastructure (OCI) o utilizzando le viste del database correlate alla gestione della crittografia.

Esempio: dbaascli tde getHsmKeys

dbaascli tde getHsmkeys --dbname dbname
dbaascli tde getHsmkeys --dbname dbname --infoFile infoFilePath

dbaascli tde getMkidForKeyVersionOCID

Per ottenere l'ID della chiave master associato all'OCID della versione della chiave KMS, utilizzare il comando dbaascli tde getMkidForKeyVersionOCID.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde getMkidForKeyVersionOCID --kmsKeyVersionOCID <value>
[--dbname <value>]
[--waitForCompletion <value>]

Parametri:

Parametro Descrizione
--kmsKeyVersionOCID specifica l'OCID della versione di chiave KMS da impostare
--dbname specifica il nome del database
--waitForCompletion specificare false per eseguire l'operazione in background. Valori validi: true o false.

Domande frequenti:

D: Qual è lo scopo del comando dbaascli tde getMkidForKeyVersionOCID?

R: il comando dbaascli tde getMkidForKeyVersionOCID recupera l'ID chiave master (MKID) associato a un OCID versione chiave KMS specifico negli ambienti Oracle AI Database Cloud Service.

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde getMkidForKeyVersionOCID?

A: È necessario:

D: Chi può eseguire il comando dbaascli tde getMkidForKeyVersionOCID?

R: Questo comando può essere eseguito solo dall'utente root.

D: Che cosa specifica il parametro –kmsKeyVersionOCID?

R: il parametro --kmsKeyVersionOCID specifica l'OCID della versione della chiave KMS per il quale si desidera recuperare l'ID chiave master (MKID) associato.

D: Che cosa specifica il parametro –dbname?

R: il parametro --dbname specifica il nome del database per il quale viene eseguita la query sull'OCID della versione della chiave KMS.

D: Il parametro –dbname è obbligatorio?

R: No, il parametro --dbname è facoltativo. Se non si specifica un nome di database, il comando recupererà MKID per il database predefinito nel sistema.

D: Cosa devo fare se non conosco l'OCID della versione della chiave KMS?

R: È necessario recuperare l'OCID della versione della chiave KMS dalla console di gestione o dal provider di servizi KMS prima di utilizzare questo comando. Senza di esso, il comando non può recuperare l'ID chiave master (MKID).

D: È possibile eseguire questo comando in un ambiente non Oracle Base Database Cloud@Customer?

R: No, questo comando è specifico per l'uso in un ambiente Oracle Base Database Cloud@Customer ed è necessario connettersi a una virtual machine utilizzando SSH per eseguirla.

D: Cosa succede se si esegue il comando senza specificare un nome di database utilizzando -dbname?

R: Se il parametro --dbname non viene fornito, il comando tenterà di recuperare MKID per il database predefinito configurato nel sistema.

D: Cosa devo fare se ho riscontrato un errore durante il recupero del MKID?

A: assicurarsi che:

D: Come posso connettermi alla virtual machine Oracle Base Database Cloud@Customer?

R: È possibile connettersi alla macchina virtuale tramite SSH. Fare riferimento alla documentazione di Oracle Base Database Cloud@Customer per i passi su come connettersi in modo sicuro.

Esempio: dbaascli tde getMkidForKeyVersionOCID

dbaascli tde getMkidForKeyVersionOCID --dbname dbname --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha

dbaascli tde getPrimaryHsmKey

Per ottenere la chiave HSM primaria (KMS) dalla configurazione HSM (KMS) esistente, utilizzare il comando dbaascli tde getPrimaryHsmKey.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde getPrimaryHsmKey
[--dbname]

Parametri:

Parametro Descrizione
--dbname specifica il nome del database

Domande frequenti:

D: Qual è lo scopo del comando dbaascli tde getPrimaryHsmKey?

A: il comando dbaascli tde getPrimaryHsmKey recupera la chiave HSM (Hardware Security Module) primaria dalla configurazione HSM (KMS) esistente in un ambiente Oracle AI Database.

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde getPrimaryHsmKey?

A: È necessario:

D: Chi può eseguire il comando dbaascli tde getPrimaryHsmKey?

R: Solo l'utente root può eseguire questo comando.

D: Che cosa specifica il parametro –dbname in questo comando?

R: il parametro --dbname specifica il nome del database per il quale si desidera recuperare la chiave HSM primaria.

D: Il parametro –dbname è obbligatorio?

R: No, il parametro --dbname è facoltativo. Se non specificato, il comando recupererà la chiave HSM primaria per il database predefinito nel sistema.

D: Cosa devo fare se non specifico un nome di database con -dbname?

R: Se il parametro --dbname non viene specificato, il comando tenterà di recuperare la chiave HSM primaria per il database predefinito configurato nel sistema.

D: È possibile eseguire questo comando in un ambiente non Oracle Base Database Cloud@Customer?

R: No, questo comando è stato progettato in modo specifico per l'uso in un ambiente Oracle Base Database Cloud@Customer ed è necessario essere connessi alla virtual machine utilizzando SSH per eseguirla.

D: Come posso connettermi alla virtual machine Oracle Base Database Cloud@Customer per eseguire il comando?

R: È possibile connettersi alla macchina virtuale tramite SSH. Per istruzioni su come connettersi in modo sicuro, fare riferimento alla documentazione di Oracle Base Database Cloud@Customer.

D: Cosa devo controllare se ho riscontrato un errore durante il recupero della chiave HSM primaria?

A: Se si verifica un errore, assicurarsi che:

D: È necessario arrestare il database per eseguire il comando dbaascli tde getPrimaryHsmKey?

R: No, il database non deve essere arrestato per eseguire questo comando. È possibile eseguirlo mentre il database è in esecuzione.

D: Qual è lo scopo di recuperare la chiave HSM primaria?

R: Il recupero della chiave HSM primaria consente di identificare la chiave HSM corrente utilizzata per la cifratura nella configurazione HSM (KMS) esistente del database.

Esempio: dbaascli tde getPrimaryHsmKey

dbaascli tde getPrimaryHsmKey --dbname dbname

dbaascli tde hsmToFile

Per convertire la cifratura TDE basata su HSM (KMS/OKV) in cifratura TDE basata su FILE, utilizzare il comando dbaascli tde hsmToFile.

Esegui il comando come utente root.

Sintassi:

dbaascli tde hsmToFile
[--dbname <value>]
{
    [--prepareStandbyBlob <value> [--blobLocation <value>]
   | [--standbyBlobFromPrimary <value>]
}
]
[--skipPatchCheck <value>]
[--executePrereqs ]
[--primarySuc <value>]
{
     [--resume [--sessionID <value>]] |
     [--revert [--sessionID <value>]]
}
[--waitForCompletion <value>]

Parametri:

Parametro Descrizione
--dbname specifica il nome del database
--prepareStandbyBlob specificare true per generare un file di oggetti BLOB che contenga gli artifact necessari per eseguire l'operazione in un ambiente Data Guard.
--blobLocation posizione della directory personalizzata in cui verrà generato il file dell'oggetto Blob di standby in un ambiente DG.
--standbyBlobFromPrimary Specificare la posizione del file dell'oggetto BLOB di standby preparato dal database primario. Questa operazione è obbligatoria solo per le operazioni in standby. ]
--skipPatchCheck salta la verifica di convalida per le patch richieste se il valore passato per questo argomento è true. Valori validi: true o false
--executePrereqs eseguire i controlli dei prerequisiti e segnalare i risultati.
--primarySuc specificare questa proprietà nel database in standby di un ambiente Data Guard dopo l'esecuzione riuscita del comando sul database primario.
--resume riprende l'esecuzione precedente
--sessionID specifica di riprendere un ID sessione specifico
--revert specifica di eseguire il rollback dell'esecuzione precedente
--sessionID specifica di eseguire il rollback di un ID sessione specifico
--waitForCompletion specifica false per eseguire l'operazione in background. Valori validi: true o false

Domande frequenti:

D: Qual è lo scopo del comando dbaascli tde hsmToFile?

R: il comando dbaascli tde hsmToFile viene utilizzato per convertire un TDE (Transparent Data Encryption) basato su Hardware Security Module (HSM) in un TDE basato su file negli ambienti Oracle AI Database Cloud Service.

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde hsmToFile?

A: È necessario:

D: Che cosa specifica il parametro –dbname?

R: il parametro --dbname specifica il nome del database per il quale si sta convertendo TDE da basato su HSM a basato su file.

D: Quando è richiesto il parametro –primaryDBWalletTar?

R: il parametro --primaryDBWalletTar è obbligatorio solo quando si esegue la conversione hsmToFile in un database di standby. Specifica il file tar del wallet del database primario.

D: Qual è lo scopo del parametro –skipPatchCheck?

R: il parametro --skipPatchCheck consente di saltare il controllo di convalida per le patch richieste. Impostare questo valore su true per saltare il controllo o su false per applicarlo.

D: Come si eseguono solo controlli preliminari per il processo di conversione senza eseguire la conversione effettiva?

R: È possibile utilizzare il parametro --executePrereqs e impostarlo su yes per eseguire solo i controlli preliminari. Impostare il valore su no per eseguire la conversione completa.

D: Che cosa fa il parametro –primarySuc in un ambiente Data Guard?

R: il parametro --primarySuc viene utilizzato in un'impostazione Data Guard per indicare che la conversione è stata eseguita correttamente nel database primario. Deve essere utilizzato quando si esegue la conversione nel database di standby.

D: Come posso riprendere una precedente conversione hsmToFile?

R: È possibile riprendere una conversione precedente utilizzando il parametro --resume. Facoltativamente, è possibile specificare l'ID sessione dell'esecuzione precedente con --sessionID.

D: Qual è lo scopo del parametro –revert?

R: Il parametro --revert viene utilizzato per eseguire il rollback di un processo di conversione avviato in precedenza in caso di errore o se è necessario annullare l'operazione.

D: Cosa succede se si imposta –waitForCompletion su falso?

R: Se si imposta --waitForCompletion su false, l'operazione verrà eseguita in background, consentendo di continuare altri task. Se impostato su true, il comando attenderà il completamento del processo prima di restituire il controllo all'utente.

D: Cosa devo fare se devo convertire il TDE in un database di standby in un'impostazione Data Guard?

R: In un'impostazione Data Guard, dopo aver convertito TDE nel database primario, è necessario eseguire il comando nel database di standby utilizzando il parametro --primaryDBWalletTar, specificando il file tar del wallet dal database primario e includendo --primarySuc.

D: Cosa devo fare se voglio saltare il controllo delle patch richieste durante la conversione?

R: È possibile saltare il controllo delle patch utilizzando il parametro --skipPatchCheck e impostandolo su true.

D: Come faccio a verificare se il sistema è pronto per la conversione hsmToFile senza apportare modifiche?

R: È possibile eseguire solo i controlli preliminari utilizzando il parametro --executePrereqs e impostandolo su yes.

D: Cosa devo fare se il processo di conversione viene interrotto?

R: È possibile utilizzare il parametro --resume per riavviare il processo da dove è stato interrotto. Facoltativamente, è possibile specificare un determinato ID sessione con --sessionID.

D: Cosa devo fare se il processo di conversione fallisce?

R: Se la conversione non riesce, è possibile eseguire il rollback del processo utilizzando il parametro --revert. Inoltre, esaminare eventuali messaggi di errore e controllare i log di sistema per ulteriori dettagli.

D: È possibile eseguire il comando dbaascli tde hsmToFile in un ambiente di database non di base?

R: questo comando è progettato per l'uso negli ambienti Oracle Base Database Cloud@Customer. Se non si utilizza Base Database, assicurarsi di trovarsi in un ambiente supportato per il corretto funzionamento del comando.

Esempio: dbaascli tde hsmToFile

dbaascli tde hsmToFile --dbname dbname
dbaascli tde hsmToFile --dbname dbname --executePrereqs
dbaascli tde hsmToFile --dbname dbname --resume

dbaascli tde listKeys

Per elencare le chiavi master TDE, utilizzare il comando dbaascli tde listKeys.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde listKeys
[--dbname <value>]
[--infoFilePath <value>]

Parametri:

Parametro Descrizione
--dbname specifica il nome del database
--infoFilePath specifica il percorso assoluto del file in cui verranno salvati i risultati.

Domande frequenti:

D: Qual è lo scopo del comando dbaascli tde listKeys?

R: il comando dbaascli tde listKeys viene utilizzato per elencare tutte le chiavi master TDE (Transparent Data Encryption) per un database specificato in un ambiente Oracle AI Database.

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde listKeys?

A: È necessario:

D: Che cosa fa il parametro –file nel comando dbaascli tde listKeys?

R: Il parametro --file specifica il percorso del file in cui deve essere salvata la lista delle chiavi principali TDE. Se questo parametro non viene fornito, i risultati verranno visualizzati direttamente nel terminale.

D: Che cosa specifica il parametro –dbname?

R: il parametro --dbname specifica il nome del database per il quale si desidera elencare le chiavi principali TDE.

D: Il parametro –file è obbligatorio?

R: No, il parametro --file è facoltativo. Se non viene fornito, l'elenco delle chiavi TDE verrà visualizzato nell'output del terminale invece di essere salvato in un file.

D: Il parametro –dbname è obbligatorio?

R: No, il parametro --dbname è facoltativo. Se non specificato, il comando elenca le chiavi principali TDE per il database predefinito configurato nel sistema.

D: Cosa devo fare se voglio salvare l'elenco delle chiavi in un file?

R: È necessario fornire il parametro --file insieme al percorso file desiderato. Ad esempio:

dbaascli tde listKeys --file /path/to/output.txt

D: Cosa succede se non si fornisce un nome di database con -dbname?

R: Se il parametro --dbname non viene fornito, il comando elenca le chiavi principali TDE per il database predefinito nel sistema.

D: È possibile utilizzare questo comando in ambienti diversi da Oracle Base Database Cloud@Customer?

R: questo comando è progettato in modo specifico per gli ambienti Oracle Base Database Cloud@Customer. Assicurarsi di essere connessi alla macchina virtuale appropriata per eseguirla.

D: Cosa devo fare se il comando non riesce a elencare le chiavi?

A: assicurarsi che:

D: Posso eseguire il comando dbaascli tde listKeys mentre il database è in esecuzione?

R: Sì, il comando può essere eseguito mentre il database è in esecuzione. Elenca semplicemente le chiavi principali TDE e non modifica lo stato del database.

D: Ho bisogno di autorizzazioni speciali per eseguire questo comando?

R: È necessario eseguire questo comando come utente root. Senza le autorizzazioni di root, non sarà possibile eseguire il comando.

D: Qual è lo scopo di elencare le chiavi principali TDE?

R: L'elenco delle chiavi principali TDE consente di rivedere le chiavi di cifratura utilizzate per proteggere i dati del database. È essenziale per il monitoraggio e la gestione delle impostazioni di crittografia.

D: Come posso connettermi alla virtual machine Oracle Base Database Cloud@Customer per eseguire il comando?

R: È possibile connettersi alla virtual machine utilizzando SSH. Per istruzioni su come stabilire una connessione sicura, fare riferimento alla documentazione Oracle Base Database Cloud@Customer.

Esempio: dbaascli tde listKeys

dbaascli tde listKeys --dbname dbname
dbaascli tde listKeys --dbname dbname --infoFilePath infoFilePath

dbaascli tde removeSecondaryHsmKey

Per rimuovere la chiave HSM (KMS) secondaria dalla configurazione HSM (KMS) esistente, utilizzare il comando dbaascli tde removeSecondaryHsmKey.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde removeSecondaryHsmKey --dbname <value>
[--confirmDeletion]
[--secondaryKmsKeyOCID]
[--executePrereqs]

Parametri:

Parametro Descrizione
--dbname specifica il nome del database.
--confirmDeletion se non specificato, l'utente riceverà un messaggio durante l'eliminazione di tutte le chiavi HSM (KMS) esistenti.
--secondaryKmsKeyOCID chiave KMS secondaria da rimuovere dalla configurazione HSM (KMS) esistente. Se non viene specificata, verranno rimosse tutti i KMS secondari.
--executePrereqs eseguire i controlli dei prerequisiti e segnalare i risultati.

Domande frequenti:

D: Qual è lo scopo del comando dbaascli tde removeSecondaryHsmKey?

A: il comando dbaascli tde removeSecondaryHsmKey viene utilizzato per rimuovere una chiave HSM (Hardware Security Module) secondaria dalla configurazione HSM (KMS) esistente in un ambiente Oracle AI Database.

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde removeSecondaryHsmKey?

A: È necessario:

D: Che cosa fa il parametro –force nel comando dbaascli tde removeSecondaryHsmKey?

R: Il parametro --force consente la rimozione della chiave HSM secondaria senza richiedere conferma all'utente. Se non specificato, il comando chiederà all'utente prima di eliminare le chiavi.

D: Che cosa specifica il parametro –secondaryKmsKeyOCID?

R: il parametro --secondaryKmsKeyOCID specifica l'OCID (identificativo Oracle Cloud) della chiave KMS secondaria che si desidera rimuovere dalla configurazione HSM esistente.

D: Che cosa fa il parametro –dbname?

R: il parametro --dbname specifica il nome del database per il quale viene rimossa la chiave HSM secondaria.

D: Qual è lo scopo del parametro –precheckOnly?

R: il parametro --precheckOnly, se impostato su yes, eseguirà solo i controlli preliminari per convalidare la disponibilità per l'operazione di rimozione senza rimuovere effettivamente la chiave HSM secondaria. Se impostato su no, viene eseguita l'operazione di rimozione completa.

D: Il parametro –force è obbligatorio?

R: No, il parametro --force è facoltativo. Se non viene specificato, il sistema chiederà conferma all'utente prima di procedere con la rimozione della chiave.

D: Il parametro –secondaryKmsKeyOCID è obbligatorio?

R: Sì, è necessario fornire --secondaryKmsKeyOCID per identificare la chiave HSM secondaria specifica che si desidera rimuovere dalla configurazione.

D: Il parametro –dbname è obbligatorio?

R: No, il parametro --dbname è facoltativo. Se non specificato, il comando tenterà di rimuovere la chiave HSM secondaria dal database predefinito nel sistema.

D: Cosa devo fare se voglio rimuovere la chiave HSM secondaria senza alcun prompt utente?

A: È necessario utilizzare il parametro --force per ignorare il prompt di conferma e rimuovere direttamente la chiave HSM secondaria:

dbaascli tde removeSecondaryHsmKey --force --secondaryKmsKeyOCID <value>

Q: Come posso verificare se il sistema è pronto a rimuovere la chiave HSM secondaria senza rimuoverla effettivamente?

R: È possibile utilizzare il parametro --precheckOnly impostato su yes per eseguire un controllo preliminare:

dbaascli tde removeSecondaryHsmKey --precheckOnly yes --secondaryKmsKeyOCID <value>

D: Cosa succede se non si fornisce un nome di database con -dbname?

R: Se il parametro --dbname non viene specificato, il comando tenterà di rimuovere la chiave HSM secondaria dal database predefinito configurato nel sistema.

D: Cosa devo controllare se il comando non riesce a rimuovere la chiave HSM secondaria?

A: assicurarsi che:

D: Cosa devo fare se l'operazione di rimozione fallisce in parte?

A: Se l'operazione non riesce, rivedere i log degli errori e provare a eseguire il comando con --precheckOnly per assicurarsi che il sistema sia pronto per l'operazione. Se necessario, correggere eventuali problemi prima di riprovare.

D: Posso eseguire il comando dbaascli tde removeSecondaryHsmKey mentre il database è in esecuzione?

R: Sì, il comando può essere eseguito mentre il database è in esecuzione, in quanto non richiede l'arresto del database.

D: Qual è lo scopo di rimuovere una chiave HSM secondaria?

R: La rimozione di una chiave HSM secondaria viene in genere eseguita quando la chiave non è più necessaria o quando si desidera gestire le chiavi di cifratura utilizzate nella configurazione TDE (Transparent Data Encryption).

D: Come posso connettermi alla virtual machine Oracle Base Database Cloud@Customer per eseguire il comando?

R: È possibile connettersi alla virtual machine utilizzando SSH. Per istruzioni su come stabilire una connessione sicura, fare riferimento alla documentazione Oracle Base Database Cloud@Customer.

Esempio: dbaascli tde removeSecondaryHsmKey

dbaascli tde removeSecondaryHsmKey --dbname dbname
dbaascli tde removeSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde removeSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --executePrereqs

dbaascli tde rotateMasterKey

Per ruotare la chiave master per la cifratura del database, utilizzare il comando dbaascli tde rotateMasterKey.

Prerequisiti:

Esegui il comando come utente root.

Sintassi:

dbaascli tde rotateMasterKey --dbname <value>
[--rotateMasterKeyOnAllPDBs]
[--pdbName <value>]
[--executePrereqs]
[--resume [--sessionID <value>]]
{
     [--prepareStandbyBlob <value> [--blobLocation <value>]]
     | [--standbyBlobFromPrimary <value>]
 }

Parametri:

Parametro Descrizione
--dbname specifica il nome di Oracle AI Database
--rotateMasterKeyOnAllPDBs specifica true per ruotare la chiave principale di tutti i PDB nel CDB. Valori validi: true o false
--pdbName specifica il nome del PDB
--executePrereqs esegue le verifiche dei prerequisiti e restituisce i risultati
--resume specifica di riprendere l'esecuzione precedente
--sessionID specifica di riprendere un ID sessione specifico
--prepareStandbyBlob specifica true per generare un file BLOB che contenga gli artifact necessari per eseguire l'operazione in un ambiente Data Guard
--blobLocation specifica la posizione della directory personalizzata in cui verrà generato il file BLOB di standby in un ambiente Data Guard
--standbyBlobFromPrimary specifica la posizione del file BLOB di standby preparato dal database primario. Questa operazione è obbligatoria solo per le operazioni in standby.

Domande frequenti:

D: Qual è lo scopo del comando dbaascli tde rotateMasterKey?

R: il comando dbaascli tde rotateMasterKey viene utilizzato per ruotare la chiave master utilizzata per la cifratura dei dati trasparente (TDE, Transparent Data Encryption) in un Oracle AI Database. Questo processo garantisce l'aggiornamento delle chiavi di cifratura per una maggiore sicurezza.

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde rotateMasterKey?

A: È necessario:

D: Che cosa specifica il parametro –dbname?

R: il parametro --dbname specifica il nome di Oracle AI Database per il quale si desidera ruotare la chiave di cifratura master.

D: Qual è lo scopo del parametro –rotateMasterKeyOnAllPDBs?

R: il parametro --rotateMasterKeyOnAllPDBs specifica se ruotare la chiave master per tutti i pluggable database (PDB) in un container database (CDB). I valori validi sono true o false.

D: Che cosa fa il parametro –pdbName?

R: il parametro --pdbName specifica il nome di un pluggable database (PDB) specifico se si desidera ruotare la chiave master per un PDB specifico anziché per tutti i PDB.

D: Che cosa fa il parametro –executePrereqs?

R: il parametro --executePrereqs esegue i controlli dei prerequisiti per verificare se l'ambiente è pronto per la rotazione della chiave master senza eseguire la rotazione effettiva.

D: Che cosa specifica il parametro –resume?

R: il parametro --resume viene utilizzato per riprendere un'operazione avviata in precedenza. È inoltre possibile fornire un ID sessione specifico utilizzando --sessionID per riprendere una determinata sessione.

D: Qual è lo scopo del parametro –prepareStandbyBlob?

R: il parametro --prepareStandbyBlob, se impostato su true, genera un file BLOB contenente gli artifact necessari per eseguire la rotazione della chiave master in un ambiente Data Guard.

D: Che cosa fa il parametro –blobLocation?

R: il parametro --blobLocation specifica un percorso di directory personalizzato in cui verrà generato il file BLOB di standby. Ciò è applicabile quando --prepareStandbyBlob è impostato su true.

D: Che cosa specifica il parametro –standbyBlobFromPrimary?

R: il parametro --standbyBlobFromPrimary specifica la posizione del file BLOB di standby generato dal database primario. Questo parametro viene utilizzato quando si esegue la rotazione della chiave master in un database di standby in un ambiente Data Guard.

D: Il parametro –rotateMasterKeyOnAllPDBs è obbligatorio?

R: No, il parametro --rotateMasterKeyOnAllPDBs è facoltativo. Se non viene specificata, la chiave master verrà ruotata solo per il database (o un PDB specifico) fornito nei parametri --dbname o --pdbName.

D: È richiesto il parametro –pdbName se si ruotano i tasti per un CDB?

R: No, il parametro --pdbName è richiesto solo se si desidera ruotare la chiave master per un pluggable database (PDB) specifico. È opzionale quando si ruota la chiave per l'intero CDB.

D: Devo usare i parametri –prepareStandbyBlob e –standbyBlobFromPrimary per i database standalone?

R: No, questi parametri sono rilevanti solo in un ambiente Data Guard in cui è coinvolto un database di standby.

D: Come posso ruotare la chiave master per tutti i PDB in un CDB?

R: Utilizzare il parametro --rotateMasterKeyOnAllPDBs impostato su true per ruotare la chiave master per tutti i PDB nel CDB. Ad esempio:

dbaascli tde rotateMasterKey --dbname CDB_NAME --rotateMasterKeyOnAllPDBs true

D: Come si esegue un controllo per verificare che il sistema sia pronto per la rotazione della chiave master senza eseguire l'operazione effettiva?

R: È possibile utilizzare il parametro --executePrereqs per eseguire i controlli dei prerequisiti. Verranno segnalati eventuali problemi che potrebbero impedire la rotazione della chiave master:

dbaascli tde rotateMasterKey --dbname DB_NAME --executePrereqs

D: Cosa devo fare se l'operazione è stata interrotta e voglio riprenderla?

R: È possibile utilizzare il parametro --resume per riprendere l'operazione precedentemente interrotta. Se si dispone di un ID sessione, fornire il parametro --sessionID:

dbaascli tde rotateMasterKey --dbname DB_NAME --resume --sessionID <value>

D: Come posso prepararmi alla rotazione delle chiavi in un ambiente Data Guard?

R: È necessario utilizzare il parametro --prepareStandbyBlob per generare un file BLOB contenente gli artifact necessari per la rotazione della chiave master in un ambiente di standby.

dbaascli tde rotateMasterKey --dbname DB_NAME --prepareStandbyBlob true --blobLocation /path/to/blob

D: Come si applica il file BLOB di standby dal database primario durante la rotazione delle chiavi in un database di standby?

A: utilizzare il parametro --standbyBlobFromPrimary per specificare la posizione del file BLOB preparato nel database primario:

dbaascli tde rotateMasterKey --dbname DB_NAME --standbyBlobFromPrimary /path/to/blob

D: Cosa devo controllare se la rotazione della chiave master non riesce?

A: assicurarsi che:

D: Cosa devo fare se l'operazione non viene completata correttamente in un ambiente Data Guard?

R: Assicurarsi che il file BLOB del database primario sia stato preparato correttamente utilizzando --prepareStandbyBlob, quindi utilizzare --standbyBlobFromPrimary per applicarlo al database di standby.

D: Posso eseguire il comando dbaascli tde rotateMasterKey mentre il database è in esecuzione?

R: Sì, il comando può essere eseguito mentre il database è in esecuzione. Tuttavia, si consiglia di eseguire in anticipo i controlli dei prerequisiti utilizzando l'opzione --executePrereqs.

D: Perché la rotazione della chiave master è importante?

R: La rotazione della chiave master migliora la sicurezza del database garantendo che le chiavi di cifratura utilizzate per la protezione dei dati vengano aggiornate periodicamente, riducendo il rischio di compromissione delle chiavi.

D: Devo riavviare il database dopo aver ruotato la chiave master?

R: No, il riavvio del database non è necessario dopo aver ruotato la chiave master. La rotazione della chiave avrà effetto immediato senza interruzioni del servizio.

dbaascli tde setKeyVersion

Per impostare la versione della chiave primaria da utilizzare in DB/CDB o PDB, utilizzare il comando dbaascli tde setKeyVersion.

Esegui il comando come utente root.

Sintassi:

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --dbname <value>
[--pdbName <value>]
[--masterKeyID <value>]
[--standbySuc]
[--executePrereqs]
[--waitForCompletion <value>]

Parametri:

Parametro Descrizione
--kmsKeyVersionOCID specifica l'OCID della versione chiave KMS da impostare.
--dbname specifica il nome del database.
--pdbName nome del PDB per l'utilizzo dell'OCID della versione della chiave.
--masterKeyID specifica l'ID della chiave master dell'OCID della versione della chiave specificata. Questa operazione è applicabile all'ambiente Data Guard.
--standbySuc specificare questa proprietà nel database primario dell'ambiente Data Guard dopo l'esecuzione riuscita del comando sul database in standby.
--executePrereqs eseguire i controlli dei prerequisiti e segnalare i risultati.
--waitForCompletion specificare false per eseguire l'operazione in background. Valori validi: true o false

Domande frequenti:

D: Qual è lo scopo del comando dbaascli tde setKeyVersion?

R: il comando dbaascli tde setKeyVersion viene utilizzato per impostare la versione della chiave di cifratura primaria da utilizzare per la cifratura dei dati trasparente (TDE, Transparent Data Encryption) in un database o in un pluggable database (PDB). Ciò consente di assegnare la versione specifica di una chiave KMS al database.

D: Quali sono i prerequisiti per l'utilizzo del comando dbaascli tde setKeyVersion?

R: È necessario eseguire il comando come utente root e assicurarsi di essere connessi a una virtual machine Oracle Base Database Cloud@Customer.

D: Che cosa specifica il parametro –kmsKeyVersionOCID?

R: il parametro --kmsKeyVersionOCID specifica l'OCID della versione della chiave KMS (identificativo Oracle Cloud) che si desidera impostare per il database o il PDB.

D: Che cosa specifica il parametro –dbname?

R: il parametro --dbname specifica il nome di Oracle AI Database per il quale verrà impostata la versione della chiave.

D: Qual è lo scopo del parametro –pdbName?

R: il parametro --pdbName specifica il nome del pluggable database (PDB) all'interno di un container database (CDB) in cui si desidera impostare la versione della chiave KMS specifica.

D: A cosa serve il parametro –masterKeyID?

R: il parametro --masterKeyID specifica l'ID della chiave master associato all'OCID della versione della chiave KMS specificato. Ciò è particolarmente importante in un ambiente Data Guard.

D: Qual è il ruolo del parametro –standbySuc?

R: il parametro --standbySuc viene utilizzato in un ambiente Data Guard. Specifica che questa proprietà deve essere impostata nel database primario dopo aver eseguito correttamente il comando nel database di standby.

D: Che cosa fa il parametro –executePrereqs?

R: il parametro --executePrereqs specifica se eseguire i controlli dei prerequisiti prima di eseguire l'operazione. I valori validi sono yes o no.

D: Che cosa controlla il parametro –waitForCompletion?

R: Il parametro --waitForCompletion determina se l'operazione verrà eseguita in modo sincrono (in attesa di completamento) o in modo asincrono (in background). I valori validi sono true o false.

D: Il parametro –pdbName è richiesto se si imposta la versione della chiave per un CDB?

R: No, il parametro --pdbName è richiesto solo se si sta impostando la versione della chiave per un pluggable database (PDB) specifico. È facoltativo se si sta impostando la versione della chiave per l'intero container database (CDB).

D: Il parametro –masterKeyID è necessario per gli ambienti non Data Guard?

R: No, il parametro --masterKeyID viene in genere utilizzato solo negli ambienti Data Guard. Per i database standalone, questo parametro non è obbligatorio.

D: Come si imposta la versione chiave per un database?

R: È possibile impostare la versione della chiave per un database eseguendo:

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --dbname <DB_NAME>

D: Come si imposta la versione della chiave per un PDB specifico?

R: Per impostare la versione della chiave per un pluggable database (PDB) specifico, utilizzare il parametro --pdbName insieme al nome del database:

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --dbname <DB_NAME> --pdbName <PDB_NAME>

D: Come posso assicurarmi che tutti i prerequisiti siano soddisfatti prima di impostare la versione chiave?

R: È possibile eseguire i controlli dei prerequisiti utilizzando il parametro --executePrereqs:

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --executePrereqs yes

D: Come si imposta la versione della chiave in un ambiente Data Guard?

A: In un ambiente Data Guard, è necessario:

Q: Come posso eseguire l'operazione in background senza aspettare che sia completata?

R: È possibile eseguire l'operazione in modo asincrono impostando --waitForCompletion su false:

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --waitForCompletion false

D: Cosa devo fare se la versione chiave non viene impostata?

A: assicurarsi che:

D: Che cosa devo controllare se l'operazione non viene completata correttamente in un ambiente Data Guard?

R: Assicurarsi che il parametro --masterKeyID sia specificato correttamente durante l'esecuzione del comando nel database di standby. Una volta completato in standby, il parametro --standbySuc deve essere utilizzato quando si esegue il comando sul database primario.

D: Posso eseguire il comando dbaascli tde setKeyVersion mentre il database è in esecuzione?

R: Sì, il comando può essere eseguito mentre il database è in esecuzione. Si consiglia tuttavia di eseguire in anticipo i controlli dei prerequisiti utilizzando --executePrereqs.

D: Perché è importante impostare la versione corretta della chiave KMS per un database?

R: L'impostazione della versione corretta della chiave KMS garantisce che il database stia utilizzando la versione appropriata della chiave di cifratura per TDE, che consente di mantenere la sicurezza dei dati e la conformità ai criteri organizzativi.

D: Cosa succede se si utilizza l'OCID della versione della chiave KMS errato?

R: Se si utilizza un OCID versione chiave KMS errato, la cifratura potrebbe non riuscire e il database non sarà in grado di utilizzare la chiave errata per le operazioni di cifratura. È necessario assicurarsi che venga fornito l'OCID della versione della chiave corretta.

D: Devo riavviare il database dopo aver impostato la versione chiave?

R: No, il riavvio del database non è necessario dopo aver impostato la versione della chiave. La nuova versione della chiave diventerà effettiva immediatamente senza richiedere un riavvio.

Esempio: dbaascli tde setKeyVersion

dbaascli tde setKeyVersion --dbname dbname --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha
dbaascli tde setKeyVersion --dbname dbname --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha --executePrereqs
dbaascli tde setKeyVersion --dbname dbname --pdbName pdb --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha

dbaascli tde setPrimaryHsmKey

Per modificare la chiave primaria HSM (KMS) per la configurazione HSM (KMS) esistente, utilizzare il comando dbaascli tde setPrimaryHsmKey.

Esegui il comando come utente root.

Sintassi:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <value> --dbname <value>
[--allStandbyPrepared]
[--bounceDatabase]
[--executePrereqs]
[--resume [--sessionID <value>]]

Parametri:

Parametro Descrizione
--primaryKmsKeyOCID specifica la chiave KMS primaria da impostare
--dbname specifica il nome del database.
--allStandbyPrepared specifica di confermare che l'esecuzione dell'operazione è riuscita in tutti i dati di standby.
--bounceDatabase specificare questo flag per eseguire il riavvio in linea del database per questa operazione
--executePrereqs eseguire i controlli dei prerequisiti e segnalare i risultati.
--resume per riprendere l'esecuzione precedente
--sessionID consente di riprendere un ID sessione specifico.

Domande frequenti:

D: Qual è lo scopo del comando dbaascli tde setPrimaryHsmKey?

R: il comando dbaascli tde setPrimaryHsmKey viene utilizzato per modificare la chiave HSM (Hardware Security Module) o KMS (Key Management Service) primaria in una configurazione HSM/KMS esistente per la cifratura dei dati trasparente (TDE).

D: Quali sono i prerequisiti per l'esecuzione del comando dbaascli tde setPrimaryHsmKey?

R: Il comando deve essere eseguito come utente root e l'ambiente deve essere una virtual machine Oracle Base Database Cloud@Customer.

D: Che cosa specifica il parametro –primaryKmsKeyOCID?

R: il parametro --primaryKmsKeyOCID specifica l'OCID (identificativo Oracle Cloud) della chiave KMS primaria da impostare per l'ambiente TDE.

D: Qual è la funzione del parametro –dbname?

R: il parametro --dbname specifica il nome di Oracle AI Database per il quale verrà impostata la chiave HSM/KMS primaria.

D: Che cosa fa il parametro –standbySuc?

R: il parametro --standbySuc viene utilizzato in un ambiente Data Guard. Specifica che il comando deve essere eseguito nel database primario dopo essere stato eseguito correttamente nel database di standby.

D: Qual è lo scopo del parametro –precheckOnly?

R: Il parametro --precheckOnly consente di eseguire solo i controlli preliminari per questa operazione. Convalida l'ambiente senza apportare modifiche effettive. I valori validi sono yes o no.

D: Che cosa controlla il parametro –bounceDatabase?

R: Il parametro --bounceDatabase specifica se il database deve essere riavviato (riavviato) in sequenza come parte dell'operazione. Ciò garantisce tempi di inattività minimi riavviando parti del database una alla volta.

D: Come si imposta la chiave KMS primaria per il database?

A: Per impostare la chiave KMS primaria, eseguire il comando seguente:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --dbname <DB_NAME>

Q: Come posso assicurare che l'operazione possa essere eseguita senza alcun problema?

A: eseguire l'operazione con il parametro --precheckOnly per verificare che tutti i prerequisiti siano soddisfatti:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --precheckOnly yes

D: Come si imposta la chiave KMS primaria in un ambiente Data Guard?

A: In primo luogo, eseguire il comando sul database di standby:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --dbname <DB_NAME>

Quindi, eseguire il comando sul database primario con il parametro --standbySuc:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --dbname <DB_NAME> --standbySuc yes

D: Come faccio a ridurre al minimo i tempi di inattività durante la modifica della chiave KMS primaria?

R: È possibile utilizzare il parametro --bounceDatabase per eseguire un riavvio in sequenza, riducendo al minimo i tempi di inattività:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --bounceDatabase

D: Il parametro –dbname è richiesto per tutti i database?

R: Sì, è necessario specificare il parametro --dbname per indicare il database di destinazione per il quale deve essere impostata la chiave KMS primaria.

D: È obbligatorio utilizzare il parametro –standbySuc in un ambiente Data Guard?

R: Sì, il parametro --standbySuc deve essere utilizzato quando si esegue il comando sul database primario dopo essere stato eseguito correttamente sul database di standby.

D: Posso saltare l'operazione di mancato recapito per il database?

R: Sì, se non si specifica il parametro --bounceDatabase, il database non verrà riavviato (riavviato) nell'ambito dell'operazione.

D: Cosa devo fare se il comando non riesce durante l'esecuzione?

A: Se il comando non riesce, assicurarsi che:

D: Cosa succede se l'operazione non riesce in un ambiente Data Guard?

R: Assicurarsi che il comando sia stato eseguito correttamente sul database di standby prima di eseguirlo sul database primario. Controllare la presenza di errori nei log ed eseguire di nuovo l'operazione con i parametri corretti.

D: Posso eseguire il comando dbaascli tde setPrimaryHsmKey su un database attivo?

R: Sì, il comando può essere eseguito mentre il database è attivo. Tuttavia, utilizzando il parametro --bounceDatabase, il database verrà riavviato in sequenza, riducendo al minimo l'impatto.

D: Come faccio a eseguire il comando in sequenza per evitare tempi di inattività completi?

A: utilizzare il parametro --bounceDatabase per eseguire un riavvio in sequenza del database durante la modifica della chiave KMS primaria:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --bounceDatabase

D: Qual è il significato di cambiare la chiave KMS primaria?

R: la modifica della chiave KMS primaria garantisce che il database utilizzi una chiave di cifratura aggiornata o diversa per la cifratura dei dati trasparente (TDE). Questa operazione può essere necessaria per motivi di sicurezza o conformità.

Q: Quanto spesso la chiave primaria del KMS dovrebbe essere ruotata o cambiata?

R: Sebbene non esista una regola rigorosa, le organizzazioni possono ruotare la chiave KMS primaria in base ai criteri di sicurezza, come gli intervalli di rotazione delle chiavi o i requisiti di conformità.

D: Cosa succede se la chiave KMS primaria è impostata in modo errato?

A: se è impostato l'OCID della chiave errato, le operazioni di cifratura del database potrebbero non riuscire e potrebbe essere necessario ripristinare la chiave corretta o correggere la configurazione impostando l'OCID della chiave KMS corretto.

D: È necessario riavviare il database dopo aver modificato la chiave KMS primaria?

R: No, non è necessario riavviare il database a meno che non si scelga di utilizzare il parametro --bounceDatabase, che riavvierà automaticamente il database per applicare la modifica.

Esempio: dbaascli tde setPrimaryHsmKey

dbaascli tde setPrimaryHsmKey --dbname dbname --primaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde setPrimaryHsmKey --dbname dbname --primaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --executePrereqs

stato tde dbaascli

Per visualizzare le informazioni sul keystore per il database specificato, utilizzare il comando dbaascli tde status.

Prerequisiti:

Eseguire il comando come utente oracle.

Sintassi:

dbaascli tde status --dbname dbname

Parametri:

Parametro Descrizione
--dbname specifica il nome del database che si desidera controllare.

L'output del comando include il tipo di keystore e lo stato del keystore.

Domande frequenti:

D: Che cosa fa il comando di stato tde dbaascli?

R: il comando dbaascli tde status visualizza informazioni sul keystore per un database specificato. Sono inclusi i dettagli sul tipo di keystore e sul relativo stato.

D: Chi dovrebbe eseguire il comando di stato tde dbaascli?

R: Il comando deve essere eseguito come utente oracle.

D: Dove dovrebbe essere eseguito il comando di stato tde dbaascli?

R: Il comando deve essere eseguito su una virtual machine Oracle Base Database Cloud@Customer. Per eseguire la utility, è necessario connettersi alla virtual machine tramite SSH.

D: Qual è la funzione del parametro –dbname?

R: il parametro --dbname specifica il nome del database per il quale verrà controllato lo stato del keystore TDE.

D: Quali informazioni restituisce il comando di stato tde dbaascli?

A: l'output del comando include il tipo di keystore (ad esempio basato su HSM o su file) e lo stato corrente del keystore, ad esempio se è aperto, chiuso o in qualche altro stato.

D: Come posso sapere se il keystore è aperto o chiuso utilizzando il comando di stato tde dbaascli?

R: Lo stato del keystore, incluso se è aperto o chiuso, fa parte dell'output restituito dal comando dbaascli tde status.

D: Come si controlla lo stato del keystore TDE per un database specifico?

A: Per controllare lo stato del keystore TDE per un database specifico, eseguire le operazioni riportate di seguito.

dbaascli tde status --dbname <DB_NAME>

D: Posso controllare lo stato del keystore per più database?

R: Sì, ma è necessario eseguire il comando separatamente per ogni database, specificandone il nome utilizzando il parametro --dbname.

D: Il comando di stato tde dbaascli può essere eseguito come utente root?

R: No, il comando deve essere eseguito come utente oracle, non come utente root.

D: Ho bisogno di autorizzazioni speciali per eseguire il comando di stato tde dbaascli?

R: Sì, è necessario disporre dei privilegi utente oracle ed essere connessi a una virtual machine Oracle Base Database Cloud@Customer per eseguire il comando.

D: Cosa devo fare se ricevo un errore durante l'esecuzione del comando di stato tde dbaascli?

R: Assicurarsi di eseguire il comando come utente oracle e verificare di disporre delle autorizzazioni necessarie e di essere connessi alla macchina virtuale corretta.

D: Come faccio a sapere quale tipo di keystore sta utilizzando il mio database?

A: il tipo di keystore, ad esempio basato su file o su HSM/KMS, viene visualizzato nell'output del comando dbaascli tde status.

D: Cosa devo fare se il keystore è chiuso?

A: se il keystore è chiuso, potrebbe essere necessario aprirlo manualmente, a seconda dell'operazione che si sta tentando di eseguire. Il processo esatto dipenderà dal tipo di keystore e dall'ambiente in uso.

D: È possibile visualizzare lo stato del keystore per un CDB (database contenitore) o un PDB (database collegabile)?

R: Sì, specificando il nome del database appropriato utilizzando il parametro --dbname, è possibile visualizzare lo stato del keystore sia per i CDB che per i PDB.

D: Che cosa significa se il comando restituisce un errore sulla connettività del database?

R: Questo potrebbe indicare un problema con la connessione al database o un problema con l'ambiente. Assicurarsi che il database sia in esecuzione e accessibile e verificare la connessione SSH alla virtual machine Oracle Base Database Cloud@Customer.

D: Cosa succede se il nome del database è errato?

R: Se il parametro --dbname specifica un database errato o inesistente, il comando non riuscirà e si riceverà un messaggio di errore che indica il problema.

D: Come risolvere i problemi se lo stato del keystore indica uno stato imprevisto?

A: se lo stato del keystore indica uno stato imprevisto, esaminare i log del database per ulteriori dettagli e controllare la configurazione del keystore per assicurarsi che sia impostato correttamente.

D: Posso automatizzare il controllo dello stato del keystore a scopo di monitoraggio?

R: Sì, è possibile eseguire lo script del comando dbaascli tde status per controllare periodicamente lo stato del keystore o integrarlo negli strumenti di monitoraggio del database.

D: Come faccio a verificare che Transparent Data Encryption (TDE) sia abilitato correttamente?

R: È possibile verificare che TDE sia abilitato correttamente controllando lo stato del keystore utilizzando il comando dbaascli tde status. Un keystore valido e aperto indica che TDE è configurato correttamente.

Esempio: stato tde dbaascli

dbaascli tde status --dbname dbname