Assurance de l'intégrité des données

Cette page explique comment utiliser les sommes de contrôle pour maintenir et vérifier l'intégrité des données de votre secret lorsque vous ajoutez et accédez à des versions de secret.

Considérez une somme de contrôle comme une empreinte digitale unique pour vos données. Il s'agit d'un code court généré à partir des données secrètes à l'aide de l'algorithme CRC32C. Si un seul bit de vos données secrètes change, la somme de contrôle change également. Cela permet à Secret Manager de détecter toute modification ou corruption accidentelle.

Secret Manager utilise des sommes de contrôle de différentes manières :

  1. Lorsque vous ajoutez une version de secret :

    • Secret Manager calcule la somme de contrôle CRC32C de vos données secrètes.

    • Cette somme de contrôle est stockée avec les données secrètes.

  2. Lorsque vous accédez à la version d'un secret :

    • Secret Manager renvoie les données secrètes ainsi que leur somme de contrôle.

    • Vous pouvez utiliser cette somme de contrôle pour vérifier que les données que vous avez reçues sont exactement les mêmes que celles stockées dans Secret Manager.

Pour s'assurer que la somme de contrôle est compatible avec la structure SecretPayload, la somme de contrôle des données secrètes doit être calculée à l'aide de l'algorithme CRC32C et encodée sous forme d'entier décimal. La réponse SecretVersion inclut un champ indiquant si le serveur a bien reçu et validé cette somme de contrôle.

L'exemple suivant montre comment fonctionnent les sommes de contrôle dans Secret Manager :

API

Ces exemples utilisent curl pour illustrer l'utilisation de l'API. Vous pouvez générer des jetons d'accès avec gcloud auth print-access-token. Sur Compute Engine ou GKE, vous devez vous authentifier avec le champ d'application cloud-platform.

Calculez la somme de contrôle des données secrètes stockées dans un fichier de données à l'aide de gcloud storage hash. La somme de contrôle doit être convertie au format décimal. Elle est encodée en tant qu'int64 dans le proto SecretPayload. 

$ gcloud storage hash "/path/to/file.txt" --hex

Si les données secrètes sont transmises sur la ligne de commande, calculez la somme de contrôle comme suit : 

$ gcloud storage hash --hex cat <(echo ${SECRET_DATA})

Encodez en base64 les données du secret et enregistrez-les comme variable d'interface système.

$ SECRET_DATA=$(echo "seCr3t" | base64)

Appelez l'API à l'aide de curl.

$ curl "https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id:addVersion" \
    --request "POST" \
    --header "authorization: Bearer $(gcloud auth print-access-token)" \
    --header "content-type: application/json" \
    --data "{\"payload\": {\"data\": \"${SECRET_DATA}\", \"data_crc32c\": $CHECKSUM}}"

Lorsque vous accédez à la version du secret, la SecretPayload renvoyée contient les données ainsi que leur somme de contrôle. Voici un exemple de réponse :

{
  "name": "projects/PROJECT_ID/secrets/SECRET_ID/versions/VERSION_ID",
  "payload": {
    "data": "YQo=",
    "dataCrc32c": "163439259"
  }
}

Dans la console, lorsque vous ajoutez une version de secret, la somme de contrôle est automatiquement calculée lorsque vous saisissez une valeur pour le secret.

Les versions secrètes chiffrées avec des clés de chiffrement gérées par le client (CMEK) et créées avant le 16 juillet 2021 ne comportent pas de sommes de contrôle stockées.

Étapes suivantes