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.
Rambardes supplémentaires
Lorsque les demandes présignées sont utilisées de manière appropriée par les créateurs de solutions et les utilisateurs, elles fournissent un mécanisme sécurisé permettant aux utilisateurs d'accéder aux données. En outre, la possibilité de générer des demandes présignées ne fournit pas aux donneurs d'ordre un accès qu'ils n'avaient pas déjà.
Dans ce contexte, des contrôles supplémentaires sont-ils nécessaires ? La justification des contrôles supplémentaires ne repose pas sur la nécessité de refuser l'accès, mais sur la capacité de surveiller, d'approuver l'utilisation et de fixer des limites, et de réduire les risques d'erreurs des utilisateurs. De cette façon, vous pouvez contribuer à garantir que l'utilisation est appropriée et nécessaire.
Les rambardes suivantes vous aideront à atteindre cet objectif. Avant d'activer ces contrôles, vous souhaiterez peut-être déterminer l'utilisation existante en identifiant les demandes présignées. Cette identification vous aide à vous préparer à l'impact du garde-corps sur l'utilisation existante ou à planifier des exceptions si nécessaire.
Rambarde pour S3 : SignatureAge
L'une des caractéristiques déterminantes des demandes présignées est qu'elles décrivent un délai d'expiration. La signature de la demande contient une date. Cette date est transmise sous forme de paramètre de chaîne de X-Amz-Date requête pour les URL présignées, et sous forme d'en-tête Date ou x-amz-date pour un POST présigné.
Amazon S3 fournit une clé de condition, s3:SignatureAge, que vous pouvez utiliser pour limiter le délai maximum entre la date de signature et l'expiration effective de la demande. Cette condition ne peut jamais augmenter la durée de validité, mais elle peut la réduire.
Dans la politique suivante, la clé de s3:signatureAge condition limite les demandes présignées à 15 minutes de validité. Les exemples suivants utilisent tous 15 minutes pour limiter la validité à une période similaire à celle prise en charge par la signature standard.
La deuxième déclaration de la politique refuse tout accès à Signature Version 2. Cette version du protocole de signature est obsolète, mais elle est toujours prise en charge dans certains d'entre eux. Régions AWS Nous vous recommandons de le bloquer explicitement avant qu'il ne soit totalement obsolète.
Vous pouvez appliquer la politique suivante en tant que politique AWS Organizations de contrôle des services (SCP). Les utilisateurs peuvent toujours utiliser des demandes présignées et déployer des solutions qui dépendent de ces demandes, à condition que le délai entre la génération des signatures et leur utilisation soit inférieur à 15 minutes. Selon la mise en œuvre, cette limitation peut n'avoir aucun impact, rendre une solution inutilisable ou provoquer des échecs occasionnels qui peuvent être réessayés.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" } } }, { "Sid": "DenySignatureVersion2", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringEquals": { "s3:signatureversion": "AWS" } } } ] }
Exceptions
Si une solution nécessite un délai plus long avant son expiration et est donc affectée par la politique précédente, nous vous recommandons de fournir une méthode pour approuver les exceptions. Pour éviter d'énumérer les exceptions dans un SCP, utilisez aws : PrincipalTag, comme dans la politique suivante, pour gérer les exceptions de manière évolutive. D'autres AWS exemples, tels que les exemples de politique de périmètre des données AWS
Si vous implémentez une politique d'exception à l'aide deaws:PrincipalTag, vous devez contrôler l'accès aux balises de configuration sur les principes. Les balises de ce type peuvent provenir directement des principaux et peuvent être contrôlées par un SCP, comme dans cet exemple de contrôle des valeurs de balise pouvant être définiesaws:PrincipalTag est un sujet complexe. Toutefois, une organisation expérimentée dans l'utilisation du contrôle d'accès basé sur les attributs (ABAC) aura l'expérience et les contrôles nécessaires pour permettre une utilisation appropriée aws:PrincipalTag pour ce cas d'utilisation.
Dans l'exemple suivant, la aws:PrincipalTag condition crée une exception qui autorise tout principal auquel le nom tag (long-presigned-allowed) est attribué et défini surtrue. À cette exception près, la restriction relative à l'âge de signature n'est pas appliquée.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } } ] }
Politiques de compartiment
Vous pouvez appliquer des politiques de compartiment à tous les compartiments ou à certains d'entre eux en utilisant une politique, comme dans l'exemple suivant. Contrairement à un SCP, une politique de compartiment cible également l'utilisation principale du service. L'annexe A ne documente aucune utilisation prévue du principal service des demandes présignées, mais si vous souhaitez mettre en œuvre un contrôle afin de prouver cette limite, la politique suivante vous fournira ce contrôle. De plus, contrairement à un SCP, une politique de compartiment peut s'appliquer aux principaux de votre compte de gestion.
ABAC-based les exceptions fonctionnent dans les politiques de compartiment de la même manière qu'un SCP. L'un des objectifs d'une politique de compartiment peut être de s'appliquer aux directeurs extérieurs à l'organisation. Les exceptions ABAC doivent donc être limitées aux principes auxquels les contrôles ABAC s'appliquent.
Dans l'exemple suivant, la aws:PrincipalTag condition de la première instruction crée une exception pour un principal auquel le nom tag (long-presigned-allowed) est attribué et défini surtrue. À cette exception près, la restriction relative à l'âge de signature n'est pas appliquée. La deuxième déclaration applique cette restriction à tous les directeurs extérieurs à l' AWS
organisation propriétaire du bucket. La portée de cette deuxième instruction doit correspondre aux contrôles ABAC pour définir la balise nommée pour les principaux.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15MinWithExceptions", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } }, { "Sid": "DenyPresignedOver15MinutesOutsideOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" } } } ] }
Politiques de contrôle des ressources
Vous pouvez appliquer une politique aux compartiments à grande échelle en utilisant des politiques de contrôle des ressources (RCP). À l'instar des SCP et contrairement aux politiques relatives aux compartiments, les RCP ne ciblent pas l'utilisation principale du service. Les RCP affectent les principaux non liés au service, quel que soit le compte, mais ils n'affectent pas les ressources du compte de gestion. Pour plus d’informations, consultez la documentation AWS Organizations.
Comme pour les politiques relatives aws:PrincipalTags aux compartiments, si vous créez des exceptions pour les principaux, gardez à l'esprit l'étendue des contrôles ABAC sur le balisage des principaux.
Le RCP suivant limite l'utilisation des URL présignées dans tous les compartiments S3 d'une organisation en limitant l'âge des signatures à 15 minutes.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15MinWithExceptions", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::*/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true", } } }, { "Sid": "DenyPresignedOver15MinutesOutsideOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::*/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" } } } ] }
Rambarde pour S3:AuthType
Les URL présignées utilisent l'authentification par chaîne de requête, et les POST présignés utilisent toujours l'authentification POST. Amazon S3 prend en charge le refus des demandes en fonction du type d'authentification via la clé de condition s3:AuthType. REST-QUERY-STRINGest la s3:authType valeur des chaînes de requête et POST la s3:authType valeur de POST.
Vous pouvez appliquer la politique suivante en tant que SCP. La politique permet s3:authType d'autoriser uniquement l'authentification basée sur les en-têtes. Il configure également une méthode pour fournir des exceptions à des utilisateurs ou à des rôles individuels.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
Le refus des demandes en fonction du type d'authentification affecte toute solution ou fonctionnalité utilisant le type d'authentification refusé. Par exemple, le refus REST-QUERY-STRING empêche les utilisateurs d'effectuer des chargements ou des téléchargements depuis la console Amazon S3. Si vous souhaitez que les utilisateurs utilisent la console Amazon S3, n'utilisez pas ce garde-fou et ne faites pas d'exception pour les utilisateurs. D'autre part, si vous ne souhaitez pas que les utilisateurs utilisent la console Amazon S3, vous pouvez refuser l'accès REST-QUERY-STRING aux utilisateurs.
Vous refusez peut-être déjà aux utilisateurs l'accès direct aux ressources Amazon S3. Dans ce cas, un garde-fou pour le type d'authentification est redondant. Cependant, une instruction de s3:authType refus est utile pour la défense en profondeur, car les implémentations visant à refuser l'accès direct couvrent généralement de nombreuses instructions de contrôle, certaines avec des exceptions.
Les rôles utilisés pour les charges de travail n'ont généralement pas besoin d'accéder à une chaîne de requête ou POST d'authentification. Les exceptions sont les rôles qui prennent en charge les services conçus pour utiliser des demandes présignées. Vous pouvez créer des exceptions spécifiques pour ces rôles.
Vous pouvez également appliquer une politique de compartiment à tous les compartiments ou à certains d'entre eux en utilisant une stratégie telle que la suivante :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
Cette politique de compartiment a pour effet de refuser l'utilisation des UploadPartCopyAPI CopyObjectet pour effectuer des copies entre régions. Amazon S3 Replication n'est pas affectée car elle ne repose pas sur ces API.
Si vous souhaitez utiliser une politique de compartiment telle que la politique précédente tout en prenant en charge l'interrégion CopyObjectou UploadPartCopyl'API, ajoutez une condition aws:ViaAWSService similaire à la suivante :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" }, "Bool": { "aws:ViaAWSService": "false" }, } } ] }
Combinaison de garde-corps présignés et d'exceptions à d'autres garde-corps
Si vous ne prévoyez pas d'appliquer de garde-fou de manière générale à vos utilisateurs et à vos rôles, vous souhaiterez peut-être l'appliquer aux exceptions des autres barrières de sécurité courantes, afin que ces exceptions ne prennent pas en charge les demandes présignées.
Si vous avez des restrictions réseau mais que vous autorisez des exceptions pour des partenaires externes ou des cas d'utilisation particuliers, vous devez bloquer la chaîne de requête ou POST l'authentification lorsque ces exceptions sont appliquées, sauf si elles sont spécifiquement identifiées comme étant obligatoires.
Limitations de S3 : SignatureAge
Les administrateurs trouveront utile de mieux comprendre les implications des3:signatureAge. Chaque demande signée inclutX-Amz-Date, qui doit indiquer l'heure actuelle. Cette valeur est renseignée par le client et le signataire de la demande. AWS rejette les demandes dont les heures sont considérées comme non valides. Cependant, un signataire peut générer des signatures à l'avance pour une date future. Amazon S3 rejette les demandes qui spécifient une date future si elles sont envoyées trop longtemps à l'avance. Toutefois, si la demande n'est envoyée qu'au moment de la connexion à la signature, celle-ci peut être générée plus tôt et envoyée ultérieurement.
s3:signatureAgelimite l'âge maximum d'X-Amz-Dateune signature uniquement pour les demandes présignées. Les demandes dont l'âge est supérieur à l'âge spécifié sont refusées, même si leur date d'expiration X-Amz-Expires ou si une POST politique les aurait déclarées valides. s3:signatureAgene modifie pas la période de validité pour les demandes qui n'incluent pas d'expiration explicite. Il ne contrôle pas non plus la valeur de X-Amz-Date ce qu'un client utilise pour une signature.
Si l'horloge système est incorrecte ou si un client reporte intentionnellement ses demandes, il est possible que l'heure de signature ne corresponde pas à l'heure à laquelle la signature a été générée. Cela limite la mesure dans laquelle les solutions s3:signatureAge peuvent être contrôlées. Une solution qui utilise l'heure actuelle à laquelle elle génère des signatures est limitée comme prévu : les signatures restent valides pendant le nombre de millisecondes spécifié dans. s3:signatureAge Une solution qui n'utilise pas l'heure actuelle aura des limites différentes. L'une des restrictions est que les informations d'identification utilisées pour signer la signature doivent toujours être valides. En tant qu'administrateur, vous pouvez contrôler la validité maximale des informations d'identification temporaires émises. Vous pouvez autoriser la validité des informations d'identification jusqu'à 36 heures ou limiter leur validité à 15 minutes. L'expiration des informations d'identification temporaires ne dépend pas de la valeur deX-Amz-Date.
Les informations d'identification permanentes ne sont pas soumises à cette restriction. Il est recommandé d'utiliser uniquement des informations d'identification temporaires, et vous pouvez révoquer explicitement toute information d'identification permanente, ce qui invaliderait également toute signature basée sur cette identification.
Bien qu'il s3:signatureAge soit mesuré en millisecondes, il n'est pas pratique de le régler à moins de 60 secondes, même si votre horloge est bien synchronisée et que vous utilisez une faible latence. Les paramètres inférieurs à 60 secondes risquent de rejeter des demandes valides. Si vous vous attendez à des retards entre la génération des signatures et la soumission de la demande, ou à des problèmes de synchronisation des horloges, vous devez en tenir compte dans votre gestion des3:signatureAge.
Cibler les seaux à grande échelle
Les SCP et RCP peuvent être utilisés aws:PrincipalTag pour faire des exceptions pour les utilisateurs. Vous ne pouvez pas utiliser de balises sur un bucket pour contrôler l'accès par ce biaisaws:ResourceTag. Seules les balises d'objet sont utilisées pour le contrôle d'accès. Il n'est généralement pas évolutif d'ajouter une balise à chaque objet auquel vous souhaitez appliquer ce contrôle.
Une solution adaptée à de nombreux cas d'utilisation consiste à appliquer la politique et l'exception au niveau du compte, soit en modifiant les comptes auxquels s'applique le SCP ou le RCP, soit en utilisant aws : ResourceAccount, aws : ResourceOrgPaths ou aws : ResourceOrg ID. Par exemple, un SCP ou un RCP peut être appliqué à un ensemble de comptes de production.
Une autre solution consiste à utiliser une AWS Config règle personnalisée pour implémenter un contrôle de détection ou un contrôle réactif. L'objectif serait que chaque compartiment contienne une politique de compartiment avec le garde-corps approprié. En plus de tester le contenu d'une politique de compartiment, la AWS Config règle personnalisée peut récupérer les balises du compartiment et exclure le compartiment de la règle si le compartiment est étiqueté avec une valeur spécifique. Si cette règle échoue à son contrôle de conformité, elle peut soit marquer le compartiment comme non conforme, soit invoquer une correction pour ajouter le garde-fou à la politique du compartiment.
Note
Vous ne pouvez pas restreindre le contenu des balises des demandes à PutBucketTagging. Pour garder le contrôle sur la façon dont un bucket est étiqueté, vous devez limiter l'accès à PutBucketTagging et DeleteBucketTagging.
