Résoudre les problèmes de chiffrement transparent des données

Sélectionnez une version de la documentation :

Cette page explique comment résoudre les problèmes liés au chiffrement transparent des données (TDE) dans AlloyDB Omni.

Récupérer les journaux de dépannage

Pour résoudre les problèmes liés au TDE, vous pouvez collecter des journaux en fonction de votre type de déploiement.

Collectez les journaux systemd pour le service AlloyDB Omni et filtrez les messages liés au TDE :

sudo journalctl -u alloydbomni18 | grep "TDE"

Les journaux peuvent contenir des entrées semblables à celles-ci :

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

Scénarios d'erreur

Cette section décrit les scénarios d'erreur courants liés au TDE et fournit des corrections suggérées.

Erreurs JWT (HashiCorp Vault)

Si vous constatez des échecs d'authentification ou d'initialisation HashiCorp Vault dans les journaux collectés, ils sont souvent liés à des problèmes de jeton Web JSON (JWT).

Description

Vous pouvez voir des erreurs semblables à celles-ci :

Erreur Description Motif
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 3, error message: JWT cannot be empty JWT introuvable ou vide Le jeton JWT est manquant ou vide.
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. Format JWT incorrect Le jeton JWT n'est pas au format de sérialisation compacte JWS correct.
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 expiré Le jeton JWT a expiré.
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"] Signature JWT non valide Le serveur Vault n'a pas pu vérifier la signature du jeton JWT.
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 9, error message: Failed to get Vault configuration parameter 'VAULT_JWT' Problème d'autorisation AlloyDB Omni n'est pas autorisé à lire le fichier de jeton JWT ou la variable d'environnement VAULT_JWT n'est pas définie.

Pour résoudre les problèmes liés au JWT :

  1. Récupérez le JWT actif :

    Vérifiez que le chemin d'accès au jeton JWT est défini dans la configuration de votre environnement ou de votre service, par exemple dans override.conf :

    cat PATH_TO_JWT_FILE

    Remplacez PATH_TO_JWT_FILE par le chemin d'accès à votre jeton JWT sur l'hôte.

  2. Examinez la structure JWT : assurez-vous que le jeton est valide et qu'il est conforme au format de sérialisation compacte JWT.

  3. Vérifiez l'état du jeton : assurez-vous qu'il est actif et qu'il n'a pas expiré.

Erreurs d'identifiants CipherTrust (Thales CipherTrust Manager)

Si vous constatez des échecs d'authentification ou d'initialisation Thales CipherTrust Manager dans les journaux collectés, ils sont généralement dus à des identifiants utilisateur manquants ou non valides (username et password).

Description

Vous pouvez voir des erreurs semblables à celles-ci :

Erreur Description Motif
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 3, error message: CipherTrust user cannot be empty Nom d'utilisateur manquant La variable d'environnement CIPHERTRUST_USER ou la clé username dans le secret Kubernetes est vide.
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 3, error message: CipherTrust password cannot be empty Mot de passe manquant La variable d'environnement CIPHERTRUST_PASSWORD ou la clé password dans le secret Kubernetes est vide.
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'		 Variable d'environnement non définie La variable d'environnement CIPHERTRUST_USER ou CIPHERTRUST_PASSWORD est manquante.
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 16, error message: CipherTrust request failed with HTTP code: 401 Identifiants incorrects Le username ou le password a été refusé par le point de terminaison d'authentification Thales CipherTrust Manager (/api/v1/auth/tokens).

Vérifiez que CIPHERTRUST_USER et CIPHERTRUST_PASSWORD sont configurés dans /etc/systemd/system/alloydbomni18.service.d/override.conf :

systemctl show alloydbomni18 -p Environment

Erreurs d'URL KMS

Si la base de données ne parvient pas à s'initialiser ou à démarrer, cela peut être dû à une URL de clé de chiffrement de clé (KEK) de service de gestion des clés (KMS) mal configurée.

Description

Vous pouvez voir des erreurs semblables à celles-ci :

Erreur Description Motif
TDE: Failed to register Key Store with URL: KMS_URL, error code: 12, error message: Unsupported key store type Type de keystore non compatible Se produit lorsque le protocole d'URL KEK n'est pas vault ou ciphertrust. Par exemple, si vous utilisez http:// ou https:// au lieu de vault:// ou ciphertrust://, ou si vous omettez complètement le schéma.
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		 Format d'adresse KMS non valide Se produit lorsque la partie de l'adresse KMS de l'URL est mal formatée. Par exemple, si elle inclut à nouveau le schéma de protocole, tel que vault://https://vault.example.com:8200/... ou 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 Format de chemin d'accès à la clé non valide Se produit lorsque la partie du chemin d'accès de l'URL KMS est mal formée. Le chemin d'accès doit commencer par une barre oblique / et ne doit pas se terminer par une barre oblique.
TDE: Failed to register Key Store with URL: KMS_URL, error code: 13, error message: curl_easy_perform() failed: Could not resolve hostname Échec de la résolution du nom d'hôte Se produit lorsque le nom d'hôte KMS dans l'URL KEK ne peut pas être résolu. Cela peut se produire si l'URL est mal formée ou s'il existe un problème de configuration DNS.
  • Vérifiez le schéma d'URL KEK : assurez-vous que l'URL commence par vault:// (pour HashiCorp Vault) ou ciphertrust:// (pour Thales CipherTrust Manager). N'utilisez pas https:// comme préfixe.
    • Correct (Vault): vault://vault.example.com:8200/v1/secret/data/key
    • Correct (CipherTrust): ciphertrust://ciphertrust.example.com:443/api/v1/vault/secrets/key
    • Incorrect: https://vault.example.com:8200/v1/secret/data/key
  • Vérifiez le format de l'adresse : assurez-vous que l'hôte et le port sont correctement spécifiés immédiatement après le préfixe vault:// ou ciphertrust://.
  • Vérifiez le format du chemin d'accès : assurez-vous que le chemin d'accès commence par / et ne comporte pas de barre oblique à la fin (par exemple, utilisez /v1/secret/data/key pour HashiCorp Vault ou /api/v1/vault/secrets/key pour Thales CipherTrust Manager, sans barre oblique à la fin /).
  • Vérifiez la résolution de l'hôte : assurez-vous que le nom d'hôte KMS spécifié dans l'URL est correct et qu'il peut être résolu à partir du serveur de base de données.

KEK non encodé en base64

Si la KEK stockée dans votre KMS externe n'est pas correctement encodée en base64, AlloyDB Omni ne parvient pas à la décoder lors de la récupération. Cela l'empêche de décompresser les clés de chiffrement de données (DEK) locales et provoque un échec de démarrage.

Description

Vous pouvez voir des erreurs semblables à celles-ci dans les journaux de diagnostic de la base de données (postgresql.log) :

Erreur Description Motif
TDE: Failed to read KEK, error code: 13, error message: Error decoding base64 key string Erreur lors du décodage de la chaîne de clé base64 Se produit lorsque le gestionnaire de clés tente de décoder le secret récupéré à partir du KMS à l'aide de base64, mais que la chaîne n'est pas un base64 valide.
  • Récupérez la valeur KEK : récupérez et inspectez la valeur KEK directement à partir de votre KMS (HashiCorp Vault ou Thales CipherTrust Manager).
  • Mettez à jour la valeur dans le KMS : assurez-vous que la KEK stockée dans votre KMS est encodée en base64. Si elle est stockée en tant que binaire brut ou texte brut, mettez à jour la valeur dans le KMS avec son équivalent encodé en base64.
    1. Convertissez la clé brute en base64 : 
      echo -n "RAW_KEY" | base64
       Remplacez <var>RAW_KEY</var> par la valeur de votre clé non encodée.
    2. Mettez à jour le secret dans votre KMS avec la chaîne encodée en base64 générée.

Version KEK manquante dans le KMS

L'erreur de version KEK manquante se produit lorsqu'AlloyDB Omni tente de décompresser les DEK locales à l'aide d'une version historique spécifique de la KEK, mais que cette version est supprimée, détruite ou manquante dans le KMS externe. Cela se produit le plus souvent lors des opérations de restauration de sauvegarde ou de l'initialisation de la réplique de secours.

Description

Vous pouvez voir des erreurs semblables à celles-ci dans les journaux de diagnostic de la base de données (postgresql.log) :

Erreur Description Motif
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: ..."		 Version de clé manquante ou détruite La version KEK demandée est manquante, supprimée ou définitivement détruite dans le KMS.
  • Vérifiez la version KEK dans le KMS : assurez-vous que la version KEK demandée est présente et active (non supprimée ni détruite) dans votre KMS.
  • Restaurez la version KEK manquante : restaurez ou annulez la suppression de la version KEK demandée dans votre KMS si elle a été supprimée, mais pas détruite.
  • Gérez les clés détruites : si la version de clé demandée est définitivement détruite dans votre KMS, les données ou la sauvegarde chiffrées sous cette version ne sont plus récupérables.

Certificats TLS ou SSL incorrects ou manquants

L'erreur de certificat TLS ou certificat SSL incorrect ou manquant se produit lorsqu'AlloyDB Omni ne parvient pas à établir une connexion TLS sécurisée avec votre service de gestion des clés externe (HashiCorp Vault ou Thales CipherTrust Manager), car des certificats sont manquants, expirés, non fiables ou mal configurés.

Description

Vous pouvez voir des erreurs semblables à celles-ci dans les journaux de diagnostic de la base de données (postgresql.log) :

Erreur Description Motif
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		 Échec de la validation du certificat du serveur KMS Le certificat du serveur KMS ne peut pas être validé à l'aide du certificat CA fourni.
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 Problème de certificat SSL local Se produit si un certificat client est requis et présente des problèmes.

Pour résoudre les problèmes de validation TLS, assurez-vous que les certificats appropriés sont fournis, montés et lisibles par l'utilisateur postgres.

Linux s'attend à ce que les certificats soient fournis au chemin d'accès spécifié dans la variable d'environnement VAULT_CERT_PATH (pour HashiCorp Vault) ou CIPHERTRUST_CERT_PATH (pour Thales CipherTrust Manager).

  1. Vérifiez que VAULT_CERT_PATH ou CIPHERTRUST_CERT_PATH est correctement défini dans votre environnement ou remplacement de service :

    systemctl show alloydbomni18 -p Environment

  2. Vérifiez que les fichiers de certificat existent et sont lisibles par l'utilisateur postgres :

    ls -la CERT_PATH

    Assurez-vous que les noms de fichiers ca.crt, tls.crt et tls.key sont présents et qu'ils disposent d'autorisations de lecture pour l'utilisateur postgres.

Remplacez CERT_PATH par le chemin d'accès au répertoire des certificats TLS sur votre hôte (par exemple, /tde-tls).