Vue d'ensemble des URL présignées

Une URL présignée est un type de requête HTTP reconnu par le service AWS Identity and Access Management (IAM). Ce qui différencie ce type de demande de toutes les autres AWS requêtes est le paramètre de requête X-Amz-Expires. Comme pour les autres demandes authentifiées, les demandes d'URL présignées incluent une signature. Pour les demandes d'URL présignées, cette signature est transmise dansX-Amz-Signature. La signature utilise les opérations cryptographiques Signature Version 4 pour coder tous les autres paramètres de demande.

Remarques

• La version 2 de Signature est actuellement en cours de dépréciation, mais elle est toujours prise en charge dans certains cas. Régions AWS Ce guide s'applique à la signature de Signature version 4.

• Le service de réception peut traiter les en-têtes non signés, mais le support pour cette option est limité et ciblé, conformément aux meilleures pratiques. Sauf indication contraire, supposons que tous les en-têtes doivent être signés pour qu'une demande soit acceptée.

Le X-Amz-Expires paramètre permet de traiter une signature comme valide avec un écart plus important par rapport à la date et à l'heure codées. D'autres aspects de la validité des signatures sont toujours évalués. Les identifiants de signature, s'ils sont temporaires, ne doivent pas être expirés au moment du traitement de la signature. Les identifiants de signature doivent être attachés à un directeur IAM disposant des autorisations suffisantes au moment du traitement.

Les URL présignées sont un sous-ensemble des demandes présignées

Une URL présignée n'est pas la seule méthode pour signer une demande pour une date future. Amazon S3 prend également en charge les requêtes POST, qui sont également généralement présignées. Une signature POST présignée autorise les téléchargements conformes à une politique signée et dont la date d'expiration est intégrée à cette politique.

Les signatures des demandes peuvent être datées du futur, bien que cela soit rare. Tant que les informations d'identification sous-jacentes sont valides, l'algorithme de signature n'interdit pas les rencontres futures. Cependant, ces demandes ne peuvent pas être traitées avec succès avant leur période de validité, ce qui rend les rencontres futures peu pratiques pour la plupart des cas d'utilisation.

Que permet une demande présignée ?

Une demande présignée ne peut autoriser que les actions autorisées par les informations d'identification utilisées pour signer la demande. Si les informations d'identification refusent implicitement ou explicitement l'action spécifiée par la demande présignée, la demande présignée est refusée lors de son envoi. Cela s'applique aux éléments suivants :

• Politiques de session associées aux informations d'identification

• Politiques associées au principal associé aux informations d'identification

• Politiques relatives aux ressources qui affectent la session ou le principal

• Politiques de contrôle des services qui affectent la session ou le principal

Motivations motivant l'utilisation de demandes présignées

En tant qu'ingénieur en sécurité, vous devez savoir ce qui pousse les créateurs de solutions à utiliser des URL présignées. Comprendre ce qui est nécessaire et ce qui est facultatif vous aidera à communiquer avec les créateurs de solutions. Les motivations peuvent inclure les suivantes :

• Pour prendre en charge un mécanisme d'authentification non IAM tout en bénéficiant de l'évolutivité d'Amazon S3. L'une des principales motivations est de communiquer directement avec Amazon S3 afin de bénéficier de l'évolutivité intégrée fournie par ce service. Sans cette communication directe, une solution devrait prendre en charge la charge de retransmission des octets envoyés PutObjectet des GetObjectappels. En fonction de la charge totale, cette exigence ajoute des difficultés de mise à l'échelle qu'un concepteur de solutions pourrait vouloir éviter.

  D'autres moyens de communication directe avec Amazon S3, tels que l'utilisation d'informations d'identification temporaires dans AWS Security Token Service (AWS STS) ou de signatures Signature Version 4 en dehors des URL, peuvent ne pas être adaptés à votre cas d'utilisation. Amazon S3 identifie les utilisateurs à l'aide AWS d'informations d'identification, tandis que les demandes présignées supposent une identification par des mécanismes autres que AWS les informations d'identification. Il est possible de combler cette différence tout en maintenant la communication directe pour les données grâce à des demandes présignées.

• Pour bénéficier de la compréhension native des URL d'un navigateur. Les URL sont comprises par les navigateurs, alors que les AWS STS informations d'identification et les signatures de la version 4 de la signature ne le sont pas. Cela est avantageux lors de l'intégration à des solutions basées sur un navigateur. Les solutions alternatives nécessitent plus de code, utilisent davantage de mémoire pour les fichiers volumineux et peuvent être traitées différemment par des extensions telles que les scanners de logiciels malveillants et de virus.

Comparaison avec les AWS STS informations d'identification temporaires

Les informations d'identification temporaires sont similaires aux demandes présignées. Ils expirent tous les deux, permettent de délimiter l'accès et sont couramment utilisés pour relier les informations d'identification non IAM à une utilisation nécessitant des informations d'identification AWS. 

Vous pouvez limiter une AWS STS identification temporaire à un seul objet et à une seule action S3, mais cela peut entraîner des problèmes de dimensionnement car les AWS STS API ont des limites. (Pour plus d'informations, consultez l'article Comment puis-je résoudre les erreurs de limitation des API ou de « débit dépassé » pour IAM et sur AWS STS le site Web AWS Re:Post.) En outre, chaque identifiant généré nécessite un appel d' AWS STS API, ce qui ajoute de la latence et crée une nouvelle dépendance susceptible d'affecter la résilience. Un AWS STS identifiant temporaire a également un délai d'expiration minimum de 15 minutes, tandis qu'une demande présignée peut prendre en charge des durées plus courtes (60 secondes, c'est pratique dans les bonnes conditions).

Comparaison avec les solutions basées uniquement sur les signatures

Le seul élément intrinsèquement secret d'une demande présignée est sa signature Signature Version 4. Si un client connaît les autres détails d'une demande et reçoit une signature valide correspondant à ces détails, il peut envoyer une demande valide. Sans signature valide, ce n'est pas possible.

Les URL présignées et les solutions utilisant uniquement des signatures sont cryptographiquement similaires. Cependant, les solutions basées uniquement sur les signatures présentent des avantages pratiques tels que la possibilité d'utiliser un en-tête HTTP au lieu d'un paramètre de chaîne de requête pour transmettre la signature (voir la section Journalisation des interactions et des mesures d'atténuation). Les administrateurs doivent également tenir compte du fait que les chaînes de requête sont généralement traitées comme des métadonnées, alors que les en-têtes sont moins souvent traités comme tels.

D'autre part, les AWS SDK fournissent moins de support pour la génération et l'utilisation directes de signatures. La création d'une solution basée uniquement sur les signatures nécessite davantage de code personnalisé. D'un point de vue pratique, l'utilisation de bibliothèques plutôt que de code personnalisé pour des raisons de sécurité est une bonne pratique générale. Le code des solutions utilisant uniquement des signatures doit donc faire l'objet d'une attention particulière.

Les solutions utilisant uniquement des signatures n'utilisent pas la chaîne de X-Amz-Expires requête et ne fournissent aucune période de validité explicite. IAM gère les périodes de validité implicites des signatures qui n'ont pas de date d'expiration explicite. Ces périodes implicites ne sont pas publiées. Ils ne changent généralement pas, mais ils sont gérés dans un souci de sécurité. Vous ne devez donc pas vous fier aux périodes de validité. Il y a un compromis entre le contrôle explicite de la date d'expiration et la gestion de l'expiration par IAM.

En tant qu'administrateur, vous préférerez peut-être une solution basée uniquement sur les signatures. Cependant, d'un point de vue pratique, vous devrez soutenir les solutions telles qu'elles ont été conçues.