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.
Bonnes pratiques fondamentales
Les meilleures pratiques générales qui constituent des contrôles efficaces pour les autres demandes d' AWS API s'appliquent également aux demandes présignées. Cette section passe en revue deux des pratiques les plus pertinentes : le moindre privilège et les périmètres de données. Ces pratiques créent une profondeur de contrôle que d'autres pratiques étendent.
Application du principe du moindre privilège
La première étape pour limiter l'utilisation des demandes présignées consiste à limiter l'accès à Amazon S3 en général. Une URL présignée ne peut pas fournir d'accès à des ressources qui n'ont pas été accordées au principal qui a généré la signature de l'URL présignée. Il ne peut pas non plus donner accès à une ressource d'une manière qui n'a pas été accordée à ce mandant. En tant que tel, l'application des meilleures pratiques pour accorder le moins de privilèges à ces principaux constitue un garde-fou efficace.
Le processus de création d'une URL présignée est une opération algorithmique basée sur une norme publiée (Signature Version 4) pour la génération de signatures. Il n'est donc pas possible de limiter la génération d'URL présignées. Toutefois, pour être pertinente, une URL présignée doit être valide et fournir un accès aux ressources. La validité d'une URL présignée constitue donc également un garde-fou efficace.
Pour plus d'informations sur le moindre privilège, voir Accorder l'accès au moindre privilège dans le AWS Well-Architected cadre, pilier Sécurité.
Implémenter un périmètre de données
L'extension du moindre privilège consiste à maintenir un périmètre de données conforme aux besoins de votre entreprise. Les URL présignées sont compatibles avec les périmètres de données. Comme pour les autres demandes, la validité d'une demande d'URL présignée est évaluée au moment de la demande. Si les propriétés du réseau, de la ressource, de la session de rôle et du principal changent, elles sont évaluées au moment et en utilisant la méthode par laquelle une demande est reçue.
Supposons, par exemple, qu'un service exécuté dans un conteneur Amazon Elastic Kubernetes Service (Amazon EKS) signe une demande. La demande est ensuite envoyée depuis le système informatique personnel d'un utilisateur connecté à Internet. Dans ce cas, la SourceIp condition aws : évalue l'adresse IP publique visible de la demande depuis le système personnel de l'utilisateur, et non l'adresse IP du service dans le conteneur Amazon EKS.
De même, si les balises du principal ou de la ressource changent avant l'envoi de la demande, les valeurs mises à jour, et non les valeurs d'origine, s'appliqueront à la demande via les ResourceTag/tag-key conditions aws : PrincipalTag/tag-key et aws :.
