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.
FAQ
Une demande présignée peut-elle être utilisée plusieurs fois ? Est-ce un risque pour la sécurité ?
Oui, une signature figurant dans une demande présignée peut être utilisée plusieurs fois. La question de savoir s'il s'agit d'un risque de sécurité est une question contextuelle. D'autres méthodes d'accès aux services AWS autorisent également la répétition. Un utilisateur ou une charge de travail disposant AWS d'informations d'identification peut envoyer de nombreuses demandes Services AWS, et chacune de ces demandes peut être dupliquée.
Si votre cas d'utilisation ne nécessite qu'une seule exécution, vous devez mettre en œuvre d'autres mécanismes pour appliquer l'usage unique. L'usage unique n'est pas une fonctionnalité des demandes présignées. En tant qu'ingénieur en sécurité, vous devez examiner les cas d'utilisation et les implémentations, mais dans de nombreux cas, une utilisation multiple convient à une utilisation acceptable.
Une autre personne que l'utilisateur prévu peut-elle utiliser une demande présignée ?
La signature d'une demande présignée peut être envoyée par toute personne en possession de cette signature. Il ne sera accepté que s'il passe d'autres formes de validation, telles que les contrôles du périmètre des données. Si la signature a expiré, si les informations d'identification ont expiré ou si les informations de signature n'ont pas accès aux ressources demandées, la demande sera refusée.
Il en va de même pour les autres méthodes d'authentification avec Services AWS. Les informations d'identification partagées de manière inappropriée autorisent un accès inapproprié. La meilleure pratique de base consiste à partager les informations d'identification et les signatures uniquement avec le public cible. Si vous ne pouvez pas faire confiance à votre public cible pour protéger les données privées et ne pas les partager avec d'autres, cela compromettra toute forme d'authentification.
Un utilisateur autorisé peut-il utiliser une demande présignée pour exfiltrer des données ?
La sécurisation des données nécessite des mesures énergiques. Permettre l'accès aux fins prévues tout en maintenant un périmètre de données nécessite une approche globale. L'accès au moindre privilège, le contrôle du périmètre des données et l'utilisation d'identifiants d'accès temporaires uniquement sont les meilleures pratiques générales applicables à la sécurisation des données. L'utilisation appropriée de ces contrôles limite également la capacité des utilisateurs à effectuer des actions par le biais des demandes présignées qu'ils génèrent.
Cela est dû au fait que l'accès fourni par une demande présignée est un sous-ensemble de l'accès accordé aux informations d'identification utilisées pour signer la demande. Dans ce contexte, les meilleures pratiques applicables à l'accès aux données s'appliquent généralement aux demandes présignées, mais les demandes présignées ne créent aucun nouvel accès aux données.
-
L'expiration maximale est limitée à l'expiration des informations de signature. Si les informations de signature sont révoquées, les signatures basées sur les informations d'identification ne sont plus valides.
-
Si les autorisations accordées au principal IAM associées aux informations d'identification de signature n'incluent pas l'exécution de l'action associée à la demande présignée, l'appel d'une demande présignée entraîne une réponse « accès refusé ». La réponse dépend de l'état actuel des autorisations au moment de l'invocation, qui n'a aucun rapport avec le moment où la signature de la demande présignée a été générée.
-
Les propriétés du principal sont évaluées en fonction du principal associé aux informations de signature.
-
Les propriétés d'une session de rôle sont évaluées en fonction de la session de rôle associée aux informations d'identification de signature.
-
Les propriétés du réseau sont évaluées en fonction de la façon dont la demande a été reçue, comme pour les demandes normales.
Dans ce contexte, l'examen des risques associés aux demandes présignées est limité aux domaines dans lesquels elles sont signées avec des informations d'identification différentes de celles de l'utilisateur et fournissent un accès qui ne faisait pas partie du principal de l'utilisateur. Cet examen doit être appliqué à la conception du service, à la charge de travail ou à la solution qui génère des signatures au nom d'un utilisateur, plutôt qu'à la capacité de demande présignée elle-même.
Puis-je refuser l'accès à partir d'une URL présignée si je pense qu'elle a été partagée de manière non autorisée ?
Oui. Cela nécessite d'invalider les informations d'identification avec lesquelles l'URL a été signée. Il existe plusieurs moyens d'y parvenir :
-
Supprimez les autorisations du principal IAM auquel appartiennent les informations d'identification. Si ce principal IAM n'a plus accès à la ressource et à l'opération pour lesquelles l'URL est signée, l'URL ne peut pas exécuter cette opération. Cela affecte toutes les utilisations correspondantes provenant de ce principal IAM.
-
Si les informations d'identification utilisées pour signer l'URL sont des AWS STS informations d'identification temporaires, vous pouvez révoquer les autorisations de session pour les informations d'identification temporaires émises avant une heure précise pour le principal IAM. Selon le cas d'utilisation, d'autres sessions valides peuvent être invalidées avant leur date d'expiration normale, mais les nouvelles sessions ne seront pas affectées. La révocation des autorisations de session invalide également celles URLs qui ont été signées à l'aide des informations d'identification associées à ces sessions, mais les nouvelles autorisations URLs associées aux nouvelles sessions ne seront pas affectées.
-
Si les informations d'identification utilisées pour signer l'URL sont des informations d'identification permanentes, désactivez la clé d'accès. Cela affecte toutes les utilisations liées à ces informations d'identification.
