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](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html) pour un POST présigné. Amazon S3 fournit une clé de condition, [s3:SignatureAge](https://docs.aws.amazon.com/AmazonS3/latest/API/bucket-policy-s3-sigv4-conditions.html), 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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAWSSDK.html#UsingAWSSDK-sig2-deprecation), 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-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](https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/README.md), utilisent cette stratégie. Si vous implémentez une politique d'exception à l'aide de`aws: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éfinies](https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/service_control_policies/data_perimeter_governance_scp.json). Une balise de ce type peut également provenir de [balises de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html), définies par un fournisseur d'identité (IdP) ou lors de l'utilisation. AWS STS Le contrôle de l'accès à `aws: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)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 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 sur`true`. À 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services). [L'annexe A](appendix-a.md) 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 sur`true`. À 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)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html). À 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](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html#actions-not-restricted-by-rcps). 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](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html), et les POST présignés utilisent toujours l'authentification POST.](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-authentication-HTTPPOST.html) Amazon S3 prend en charge le refus des demandes en fonction du type d'authentification via la clé de [condition s3:AuthType](https://docs.aws.amazon.com/AmazonS3/latest/API/bucket-policy-s3-sigv4-conditions.html). `REST-QUERY-STRING`est 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 **UploadPartCopy**API **CopyObject**et 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 **CopyObject**ou **UploadPartCopy**l'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 de`s3:signatureAge`. Chaque demande signée inclut`X-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:signatureAge`limite l'âge maximum d'`X-Amz-Date`une 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:signatureAge`ne 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 de`X-Amz-Date`. Les informations d'identification permanentes ne sont pas soumises à cette restriction. Il est recommandé d'[utiliser uniquement des informations d'identification temporaires](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html), 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 de`s3: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 biais`aws:ResourceTag`. [Seules les balises d'objet sont utilisées pour le contrôle d'accès](https://docs.aws.amazon.com/AmazonS3/latest/userguide/tagging-and-policies.html). 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount), [aws : ResourceOrgPaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgpaths) ou [aws : ResourceOrg ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid). 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](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules.html) pour implémenter un [contrôle de détection](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-security-controls/detective-controls.html) ou un [contrôle réactif](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-security-controls/responsive-controls.html). 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](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketTagging.html). Pour garder le contrôle sur la façon dont un bucket est étiqueté, vous devez limiter l'accès à `PutBucketTagging` et [DeleteBucketTagging](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketTagging.html).