Cette page est réservée aux clients existants du service S3 Glacier utilisant Vaults et l'original REST API de 2012.
Si vous recherchez des solutions de stockage d'archives, nous vous conseillons d'utiliser les classes de stockage S3 Glacier dans Amazon S3, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval et S3 Glacier Deep Archive. Pour en savoir plus sur ces options de stockage, consultez les sections Classes de stockage S3 Glacier
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Signature des requêtes
S3 Glacier vous impose d'authentifier chaque demande que vous envoyez en la signant. Pour signer une demande, vous calculez une signature numérique à l’aide d’une fonction de hachage cryptographique. Un hachage cryptographique est une fonction qui renvoie une valeur de hachage unique basée sur l’entrée. L’entrée de la fonction de hachage contient le texte de la demande et votre clé d’accès secrète. La fonction de hachage renvoie une valeur de hachage que vous incluez dans la demande comme votre signature. La signature fait partie de l’en-tête Authorization de votre demande.
Après avoir reçu votre demande, S3 Glacier recalcule la signature en utilisant la fonction de hachage et l'entrée que vous avez utilisées pour signer la demande. Si la signature obtenue correspond à la signature de la demande, S3 Glacier traite cette dernière. Sinon, la demande est rejetée.
S3 Glacier prend en charge l'authentification avec AWS Signature Version 4. Le processus de calcul d’une signature peut être divisé en trois tâches :
-
Tâche 1 : créer une demande canonique
Réorganisez votre HTTP demande dans un format canonique. L'utilisation d'une forme canonique est nécessaire, car S3 Glacier utilise la même forme canonique lorsqu'il recalcule une signature à comparer à celle que vous avez envoyée.
-
Tâche 2 : créer une chaîne de connexion
Créez une chaîne que vous utiliserez comme une des valeurs d’entrée pour votre fonction de hachage cryptographique. La chaîne, appelée la chaîne de connexion, est une concaténation du nom de l’algorithme de hachage, de la date de la demande, d’une chaîne d’informations d’identification et de la demande convertie sous forme canonique de la tâche précédente. La chaîne d'étendue des informations d'identification elle-même est une concaténation d'informations de date, de AWS région et de service.
-
Créez une signature pour votre demande à l’aide d’une fonction de hachage cryptographique qui accepte deux chaînes d’entrée : votre chaîne de connexion et une clé dérivée. La clé dérivée est calculée en commençant par votre clé d'accès secrète et en utilisant la chaîne de portée des informations d'identification pour créer une série de codes d'authentification des messages basés sur le hachage ()HMACs. Notez que la fonction de hachage utilisée dans cette étape de signature n'est pas l'algorithme de hachage arborescent utilisé dans S3 Glacier APIs pour télécharger les données.
Exemple de calcul de signature
L'exemple suivant vous guide à travers les détails de la création d'une signature pour Création de coffre (PUT vault). L’exemple peut être utilisé comme référence pour vérifier votre méthode de calcul de signature. Pour plus d'informations, consultez la section Signature AWS API des demandes dans le guide de IAM l'utilisateur.
Dans cet exemple il est supposé que :
-
L'horodatage de la demande est
Fri, 25 May 2012 00:24:53 GMT. -
Le point de terminaison est la région USA Est (Virginie du Nord),
us-east-1.
La syntaxe générale de la demande (JSONcorps compris) est la suivante :
PUT /-/vaults/examplevault HTTP/1.1 Host: glacier.us-east-1.amazonaws.com Date: Fri, 25 May 2012 00:24:53 GMT Authorization:SignatureToBeCalculatedx-amz-glacier-version: 2012-06-01
La forme canonique de la demande calculée pour Tâche 1 : Créer une demande canonique est :
PUT /-/vaults/examplevault host:glacier.us-east-1.amazonaws.com x-amz-date:20120525T002453Z x-amz-glacier-version:2012-06-01 host;x-amz-date;x-amz-glacier-version e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
La dernière ligne de la demande canonique est le hachage du corps de la demande. Notez également la troisième ligne vide dans la demande canonique. Cela est dû au fait qu'il n'existe aucun paramètre de requête pour celaAPI.
La chaîne de connexion pour la tâche 2 : créer une chaîne de connexion est :
AWS4-HMAC-SHA256 20120525T002453Z 20120525/us-east-1/glacier/aws4_request 5f1da1a2d0feb614dd03d71e87928b8e449ac87614479332aced3a701f916743
La première ligne de la chaîne de connexion est l'algorithme, la deuxième ligne est l'horodatage, la troisième ligne est les informations d'identification, et la dernière ligne est un hachage de la demande canonique issu de la tâche 1 : créer une demande canonique. Le nom du service à utiliser dans les informations d'identification est glacier.
Pour la tâche 3 : créer une signature, la clé dérivée peut être représentée sous la forme :
derived key = HMAC(HMAC(HMAC(HMAC("AWS4" + YourSecretAccessKey,"20120525"),"us-east-1"),"glacier"),"aws4_request")
Si la clé d'accès secrète wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY est utilisée, la signature calculée est :
3ce5b2f2fffac9262b4da9256f8d086b4aaf42eba5f111c21681a65a127b7c2a
L’étape finale consiste à construire l’en-tête Authorization. Pour la clé d'accès de la démonstration AKIAIOSFODNN7EXAMPLE, l'en-tête (avec les sauts de ligne ajoutés pour faciliter la lecture) est :
Authorization: AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20120525/us-east-1/glacier/aws4_request, SignedHeaders=host;x-amz-date;x-amz-glacier-version, Signature=3ce5b2f2fffac9262b4da9256f8d086b4aaf42eba5f111c21681a65a127b7c2a
Calcul des Signatures pour les opérations de streaming
Chargement d'archive (POST archive) et Partie chargement (PUT uploadID) sont des opérations de streaming qui exigent d'inclure un en-tête supplémentaire x-amz-content-sha256 lors de la signature et de l'envoi de votre demande. Les étapes de signature pour les opérations de streaming sont identiques à celles des autres opérations, mais comprennent aussi l'ajout de l'en-tête de streaming.
Le calcul de l'en-tête de diffusion x-amz-content-sha256 est basé sur le SHA256 hachage de l'ensemble du contenu (charge utile) à télécharger. Notez que ce calcul est différent de l'SHA256arbre hash (Calcul des totaux de contrôle). Hormis les cas triviaux, la valeur de hachage SHA 256 des données de charge utile sera différente du hachage SHA256 arborescent des données de charge utile.
Si les données de charge utile sont spécifiées sous forme de tableau d'octets, vous pouvez utiliser l'extrait de code Java suivant pour calculer le hachage. SHA256
public static byte[] computePayloadSHA256Hash2(byte[] payload) throws NoSuchAlgorithmException, IOException { BufferedInputStream bis = new BufferedInputStream(new ByteArrayInputStream(payload)); MessageDigest messageDigest = MessageDigest.getInstance("SHA-256"); byte[] buffer = new byte[4096]; int bytesRead = -1; while ( (bytesRead = bis.read(buffer, 0, buffer.length)) != -1 ) { messageDigest.update(buffer, 0, bytesRead); } return messageDigest.digest(); }
De même, en C#, vous pouvez calculer le SHA256 hachage des données de charge utile comme indiqué dans l'extrait de code suivant.
public static byte[] CalculateSHA256Hash(byte[] payload) { SHA256 sha256 = System.Security.Cryptography.SHA256.Create(); byte[] hash = sha256.ComputeHash(payload); return hash; }
Exemple de calcul de signature pour le streaming API
L'exemple suivant explique en détail comment créer une signature pour Chargement d'archive (POST archive) l'un des deux types de diffusion APIs dans S3 Glacier. Dans cet exemple il est supposé que :
-
L'horodatage de la demande est
Mon, 07 May 2012 00:00:00 GMT. -
Le point de terminaison est la région USA Est (Virginie du Nord), us-east-1.
-
La charge utile du contenu est une chaîne « Bienvenue dans S3 Glacier ».
La syntaxe générale de la demande (y compris le JSON corps) est illustrée dans l'exemple ci-dessous. Notez que l'en-tête x-amz-content-sha256 est inclus. Dans cet exemple simplifié, le paramètre x-amz-sha256-tree-hash et le paramètre x-amz-content-sha256 ont la même valeur. Cependant, ce n'est pas le cas pour les téléchargements d'archives supérieures à 1 Mo.
POST /-/vaults/examplevault HTTP/1.1 Host: glacier.us-east-1.amazonaws.com Date: Mon, 07 May 2012 00:00:00 GMT x-amz-archive-description: my archive x-amz-sha256-tree-hash: SHA256 tree hash x-amz-content-sha256: SHA256 payload hash Authorization:SignatureToBeCalculatedx-amz-glacier-version: 2012-06-01
La forme canonique de la demande calculée pour la tâche 1 : créer une demande canonique est illustrée ci-dessous : Notez que l'en-tête de streaming x-amz-content-sha256 est inclus avec sa valeur. Cela signifie que vous devez d'abord lire la charge utile et calculer le SHA256 hachage, puis calculer la signature.
POST /-/vaults/examplevault host:glacier.us-east-1.amazonaws.com x-amz-content-sha256:726e392cb4d09924dbad1cc0ba3b00c3643d03d14cb4b823e2f041cff612a628 x-amz-date:20120507T000000Z x-amz-glacier-version:2012-06-01 host;x-amz-content-sha256;x-amz-date;x-amz-glacier-version 726e392cb4d09924dbad1cc0ba3b00c3643d03d14cb4b823e2f041cff612a628
Le reste du calcul de la signature suit les étapes décrites dans Exemple de calcul de signature. L'en-tête Authorization qui utilise la clé d'accès secrète wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY et la clé d'accès AKIAIOSFODNN7EXAMPLE est illustré ci-dessous (avec des sauts de ligne ajoutés pour faciliter la lecture) :
Authorization=AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20120507/us-east-1/glacier/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-glacier-version, Signature=b092397439375d59119072764a1e9a144677c43d9906fd98a5742c57a2855de6
