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.
Prévention du député confus
Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner un problème de confusion chez les adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le service appelant) appelle un autre service (le service appelé). Le service appelant peut être manipulé et ses autorisations utilisées pour agir sur les ressources d’un autre client auxquelles on ne serait pas autorisé d’accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services auprès des principaux fournisseurs de services qui ont obtenu l'accès aux ressources de votre compte.
Nous recommandons d'utiliser les clés aws:SourceOrgID
contextuelles aws:SourceArn
aws:SourceAccount
,, et de condition aws:SourceOrgPaths
globale dans les politiques de ressources afin de limiter les autorisations qui accordent un autre service à la ressource. aws:SourceArn
À utiliser pour associer une seule ressource à un accès multiservice. aws:SourceAccount
À utiliser pour associer n'importe quelle ressource de ce compte à l'utilisation interservices. aws:SourceOrgID
À utiliser pour permettre à n'importe quelle ressource provenant de n'importe quel compte au sein d'une organisation d'être associée à l'utilisation interservices. aws:SourceOrgPaths
À utiliser pour associer toute ressource provenant de comptes situés dans un AWS Organizations chemin à l'utilisation interservices. Pour plus d'informations sur l'utilisation et la compréhension des chemins, voir Comprendre le chemin de l' AWS Organizations entité.
Le moyen le plus efficace de se prémunir contre le problème de confusion des adjoints consiste à utiliser la clé de contexte de la condition aws:SourceArn
globale avec l'intégralité ARN de la ressource. Si vous ne connaissez pas l'intégralité ARN de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de condition contextuelle aws:SourceArn
globale avec des caractères génériques (*
) pour les parties inconnues duARN. Par exemple, arn:aws:
. servicename
:*:123456789012
:*
Si la aws:SourceArn
valeur ne contient pas l'identifiant du compte, tel qu'un compartiment Amazon S3ARN, vous devez utiliser les deux aws:SourceAccount
et aws:SourceArn
limiter les autorisations.
Pour se protéger contre le problème de l'adjoint confus à grande échelle, utilisez la clé de contexte de condition globale aws:SourceOrgID
ou aws:SourceOrgPaths
avec l'ID de l'organisation ou le chemin de l'organisation de la ressource dans vos politiques basées sur les ressources. Lorsque vous ajoutez, supprimez et déplacez des comptes dans votre organisation, les politiques qui contiennent la clé aws:SourceOrgID
ou aws:SourceOrgPaths
incluront automatiquement les bons comptes et vous n'avez pas besoin de mettre manuellement à jour les polices.
Les politiques documentées pour autoriser l'accès aux CloudWatch journaux afin d'y écrire des données Étape 1 : créer une destination dans Kinesis Data Streams Étape 2 : créer une destination et Firehose montrent comment vous pouvez utiliser la clé aws SourceArn : global condition context pour éviter le problème de confusion des adjoints.