Risolvere i problemi relativi alla crittografia trasparente dei dati

Select a documentation version:

Questa pagina descrive come risolvere i problemi relativi alla crittografia dei dati trasparente (TDE) in AlloyDB Omni.

Recuperare i log di risoluzione dei problemi

Per risolvere i problemi relativi a TDE, puoi raccogliere i log a seconda del tipo di deployment.

Raccogli i log systemd per il servizio AlloyDB Omni e filtra i messaggi relativi a TDE:

sudo journalctl -u alloydbomni18 | grep "TDE"

I log potrebbero contenere voci simili alle seguenti:

  • TDE: TdeContext initialization failed
  • TDE: Vault server unreachable
  • TDE: CipherTrust request failed
  • TDE: Certificate expired

Scenari di errore

Questa sezione descrive gli scenari di errore TDE comuni e fornisce le correzioni suggerite.

Errori JWT (HashiCorp Vault)

Se nei log raccolti vengono visualizzati errori di autenticazione o inizializzazione di HashiCorp Vault, spesso sono correlati a problemi con JSON Web Token (JWT).

Descrizione

Potresti visualizzare errori simili ai seguenti:

Errore Descrizione Motivo
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 3, error message: JWT cannot be empty JWT non trovato o vuoto Il token JWT è mancante o vuoto.
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 3, error message: Invalid JWT format. Expected JWS compact serialization (three dot-separated segments: header, payload, and signature) with base64url encoded values. Formato JWT non valido Il token JWT non è nel formato di serializzazione compatto JWS corretto.
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 3, error message: Vault request failed with HTTP code: 400, Vault errors: ["error validating token: invalid expiration time (exp) claim: token is expired"] JWT scaduto Il token JWT è scaduto.
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 3, error message: Vault request failed with HTTP code: 400, Vault errors: ["error validating token: error verifying token signature: failed to verify id token signature"] Firma JWT non valida Il server Vault non è riuscito a verificare la firma del token JWT.
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 9, error message: Failed to get Vault configuration parameter 'VAULT_JWT' Problema di autorizzazione AlloyDB Omni non dispone dell'autorizzazione per leggere il file del token JWT oppure la variabile di ambiente VAULT_JWT non è impostata.

Per risolvere i problemi relativi a JWT:

  1. Recupera il JWT attivo:

    Verifica che il percorso del token JWT sia definito nella configurazione dell'ambiente o del servizio, ad esempio in override.conf:

    cat PATH_TO_JWT_FILE

    Sostituisci PATH_TO_JWT_FILE con il percorso del token JWT sull'host.

  2. Esamina la struttura JWT: assicurati che il token sia valido e conforme al formato di serializzazione compatto JWT.

  3. Verifica lo stato del token: assicurati che il token sia attivo e non sia scaduto.

Errori delle credenziali CipherTrust (Thales CipherTrust Manager)

Se nei log raccolti vengono visualizzati errori di autenticazione o inizializzazione di Thales CipherTrust Manager, in genere sono causati da credenziali utente mancanti o non valide (username e password).

Descrizione

Potresti visualizzare errori simili ai seguenti:

Errore Descrizione Motivo
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 3, error message: CipherTrust user cannot be empty Nome utente mancante La variabile di ambiente CIPHERTRUST_USER o la chiave username nel secret di Kubernetes è vuota.
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 3, error message: CipherTrust password cannot be empty Password mancante La variabile di ambiente CIPHERTRUST_PASSWORD o la chiave password nel secret di Kubernetes è vuota.
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 9, error message: Failed to get CipherTrust configuration parameter 'CIPHERTRUST_USER'
Or
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 9, error message: Failed to get CipherTrust configuration parameter 'CIPHERTRUST_PASSWORD'		 Variabile di ambiente non impostata Manca la variabile di ambiente CIPHERTRUST_USER o CIPHERTRUST_PASSWORD.
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 16, error message: CipherTrust request failed with HTTP code: 401 Credenziali non valide Il username o la password sono stati rifiutati dall'endpoint di autenticazione di Thales CipherTrust Manager (/api/v1/auth/tokens).

Verifica che CIPHERTRUST_USER e CIPHERTRUST_PASSWORD siano configurati in /etc/systemd/system/alloydbomni18.service.d/override.conf:

systemctl show alloydbomni18 -p Environment

Errori dell'URL KMS

Se il database non riesce a inizializzarsi o ad avviarsi, potrebbe essere dovuto a un URL della chiave di crittografia (KEK) di Key Management Service (KMS) configurato in modo errato.

Descrizione

Potresti visualizzare errori simili ai seguenti:

Errore Descrizione Motivo
TDE: Failed to register Key Store with URL: KMS_URL, error code: 12, error message: Unsupported key store type Tipo di keystore non supportato Si verifica quando il protocollo dell'URL KEK non è vault o ciphertrust. Ad esempio, se utilizzi http:// o https:// anziché vault:// o ciphertrust:// oppure se ometti completamente lo schema.
TDE: Failed to register Key Store with URL: KMS_URL, error code: 3, error message: Invalid Vault address format. Expected hostname or hostname:port
Or
TDE: Failed to register Key Store with URL: KMS_URL, error code: 3, error message: Invalid CipherTrust address format. Expected hostname or hostname:port		 Formato dell'indirizzo KMS non valido Si verifica quando la parte dell'indirizzo KMS dell'URL non è formattata correttamente. Ad esempio, se include di nuovo lo schema del protocollo, come vault://https://vault.example.com:8200/... o ciphertrust://https://ciphertrust.example.com:443/....
TDE: Failed to read KEK, error code: 3, error message: Invalid key path format. Must start with '/', not end with '/', and contain only valid characters Formato del percorso della chiave non valido Si verifica quando la parte del percorso dell'URL KMS non è valida. Il percorso deve iniziare con una barra / e non deve terminare con una barra finale.
TDE: Failed to register Key Store with URL: KMS_URL, error code: 13, error message: curl_easy_perform() failed: Could not resolve hostname Errore di risoluzione del nome host Si verifica quando non è possibile risolvere il nome host KMS nell'URL KEK. Questo può accadere se l'URL non è valido o se si verifica un problema di configurazione DNS.
  • Verifica lo schema dell'URL KEK: assicurati che l'URL inizi con vault:// (per HashiCorp Vault) o ciphertrust:// (per Thales CipherTrust Manager). Non utilizzare https:// come prefisso.
    • Corretto (Vault): vault://vault.example.com:8200/v1/secret/data/key
    • Corretto (CipherTrust): ciphertrust://ciphertrust.example.com:443/api/v1/vault/secrets/key
    • Non corretto: https://vault.example.com:8200/v1/secret/data/key
  • Controlla il formato dell'indirizzo: assicurati che l'host e la porta siano specificati correttamente immediatamente dopo il prefisso vault:// o ciphertrust://.
  • Verifica la formattazione del percorso: assicurati che il percorso inizi con / e non abbia una barra finale (ad esempio, utilizza /v1/secret/data/key per HashiCorp Vault o /api/v1/vault/secrets/key per Thales CipherTrust Manager, senza una barra finale /).
  • Verifica la risoluzione dell'host: assicurati che il nome host KMS specificato nell'URL sia corretto e che possa essere risolto dal server del database.

KEK non codificata in Base64

Se la KEK archiviata nel KMS esterno non è codificata correttamente in Base64, AlloyDB Omni non riesce a decodificarla al momento del recupero. In questo modo, non è possibile eseguire il wrapping delle chiavi di crittografia dei dati (DEK) locali e si verifica un errore di avvio.

Descrizione

Potresti visualizzare errori simili ai seguenti nei log di diagnostica del database (postgresql.log):

Errore Descrizione Motivo
TDE: Failed to read KEK, error code: 13, error message: Error decoding base64 key string Errore durante la decodifica della stringa della chiave Base64 Si verifica quando il gestore delle chiavi tenta di decodificare il secret recuperato dal KMS utilizzando Base64, ma la stringa non è un Base64 valido.
  • Recupera il valore KEK: recupera e ispeziona il valore KEK direttamente dal KMS (HashiCorp Vault o Thales CipherTrust Manager).
  • Aggiorna il valore in KMS: assicurati che la KEK archiviata nel KMS sia codificata in Base64. Se è archiviata come testo binario o normale non elaborato, aggiorna il valore nel KMS con il relativo equivalente codificato in Base64.
    1. Converti la chiave non elaborata in Base64: 
      echo -n "RAW_KEY" | base64
       Sostituisci <var>RAW_KEY</var> con il valore della chiave non codificata.
    2. Aggiorna il secret nel KMS con la stringa codificata in Base64 generata.

Versione KEK mancante in KMS

L'errore relativo alla versione KEK mancante si verifica quando AlloyDB Omni tenta di eseguire il wrapping delle DEK locali utilizzando una versione storica specifica della KEK, ma questa versione viene eliminata, eliminata definitivamente o non è presente nel KMS esterno. Questo è più comune durante le operazioni di ripristino del backup o l'inizializzazione della replica di standby.

Descrizione

Potresti visualizzare errori simili ai seguenti nei log di diagnostica del database (postgresql.log):

Errore Descrizione Motivo
TDE: Failed to read KEK, error code: 5, error message: Vault request failed with HTTP code: 404, Response body: {... "destroyed":true, "version":4 ...}
Or
TDE: Failed to read KEK, error code: 5, error message: CipherTrust request failed with HTTP code: 404, CipherTrust error: "NCERRResourceNotFound: ..."		 Versione della chiave mancante o eliminata La versione KEK richiesta è mancante, eliminata o eliminata definitivamente nel KMS.
  • Verifica la versione KEK in KMS: assicurati che la versione KEK richiesta sia presente e attiva (non eliminata o eliminata definitivamente) nel KMS.
  • Ripristina la versione KEK mancante: ripristina o annulla l'eliminazione della versione KEK richiesta nel KMS se è stata eliminata ma non eliminata definitivamente.
  • Gestisci le chiavi eliminate: se la versione della chiave richiesta viene eliminata definitivamente nel KMS, i dati o il backup criptati con questa versione non sono recuperabili in modo permanente.

Certificati TLS o SSL non validi o mancanti

L'errore relativo a certificati TLS o SSL non validi o mancanti si verifica quando AlloyDB Omni non riesce a stabilire una connessione TLS sicura al KMS esterno (HashiCorp Vault o Thales CipherTrust Manager) perché i certificati sono mancanti, scaduti, non attendibili o configurati in modo errato.

Descrizione

Potresti visualizzare errori simili ai seguenti nei log di diagnostica del database (postgresql.log):

Errore Descrizione Motivo
TDE: Failed to read KEK, error code: 13, error message: curl_easy_perform() failed: SSL peer certificate or SSH remote key was not OK
Or
TDE: Failed to read KEK, error code: 13, error message: curl_easy_perform() failed: Peer certificate cannot be authenticated with given CA certificates		 Verifica del certificato del server KMS non riuscita Non è possibile verificare il certificato del server KMS utilizzando il certificato CA fornito.
TDE: Failed to register Key Store with URL: KMS_URL, error code: 13, error message: curl_easy_perform() failed: Problem with the local SSL certificate Problema con il certificato SSL locale Si verifica se è richiesto un certificato client e si verificano problemi.

Per risolvere i problemi di verifica TLS, assicurati che i certificati corretti siano forniti, montati e leggibili dall'utente postgres.

Linux prevede che i certificati vengano forniti nel percorso specificato nella variabile di ambiente VAULT_CERT_PATH (per HashiCorp Vault) o CIPHERTRUST_CERT_PATH (per Thales CipherTrust Manager).

  1. Verifica che VAULT_CERT_PATH o CIPHERTRUST_CERT_PATH sia impostato correttamente nell'override dell'ambiente o del servizio:

    systemctl show alloydbomni18 -p Environment

  2. Verifica che i file dei certificati esistano e siano leggibili dall'utente postgres:

    ls -la CERT_PATH

    Assicurati che i nomi file ca.crt, tls.crt e tls.key siano presenti e che abbiano le autorizzazioni in lettura per l'utente postgres.

Sostituisci CERT_PATH con il percorso della directory dei certificati TLS sull'host (ad esempio, /tde-tls).