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

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

Considérez une somme de contrôle comme une empreinte 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 les sommes de contrôle de la manière suivante :

  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 à une version de secret :

    • Secret Manager renvoie les données secrètes avec 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 vous 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 en tant qu’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 les sommes de contrôle fonctionnent 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.

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

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

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

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

Lorsque 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})

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, le SecretPayload renvoyé 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 de secret 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.

Étape suivante