Prévention de l'adjoint confus entre services dansAWS OpsWorks CM - AWS OpsWorks

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 de l'adjoint confus entre services dansAWS OpsWorks CM

Le problème de l'adjoint confus est un problème de sécurité dans lequel une entité qui n'a pas l'autorisation d'effectuer une action peut contraindre une entité plus privilégiée à effectuer cette action. Dans AWS, l'emprunt d'identité entre services peut entraîner le problème de député confus. 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 avec des principaux de service qui ont eu accès aux ressources de votre compte.

Nous vous recommandons d'utiliser les clés de contexte de condition globale aws:SourceArn et aws:SourceAccount dans les politiques de ressources pour limiter les autorisations à la ressource octroyées par AWS OpsWorks CM à un autre service. Si la valeur aws:SourceArn ne contient pas l'ID du compte, tel qu'un ARN de compartiment Amazon S3, vous devez utiliser les deux clés de contexte de condition globale pour limiter les autorisations. Si vous utilisez les deux clés de contexte de condition globale et que la valeur aws:SourceArn contient l'ID de compte, la valeur aws:SourceAccount et le compte dans la valeur aws:SourceArn doivent utiliser le même ID de compte lorsqu'ils sont utilisés dans la même instruction de politique. Utilisez aws:SourceArn si vous souhaitez qu'une seule ressource soit associée à l'accès entre services. Utilisez aws:SourceAccount si vous souhaitez autoriser toute ressource de ce compte à être associée à l'utilisation entre services.

Pouraws:SourceArndoit être l'ARN d'unOpsWorksServeur CM Chef ou Puppet.

Le moyen le plus efficace de se protéger contre le problème du député confus consiste à utiliser leaws:SourceArnclé de contexte de condition globale avec l'ARN complet duAWS OpsWorks CMserveur. Si vous ne connaissez pas l'ARN complet ou si vous spécifiez plusieurs ARN de serveur, utilisez leaws:SourceArnclé de condition de contexte global avec des caractères génériques (*) pour les parties inconnues de l'ARN. Par exemple, arn:aws:servicename:*:123456789012:*.

La section suivante montre comment utiliser leaws:SourceArnetaws:SourceAccountClés de contexte de condition globales dansAWS OpsWorks CMafin de prévenir le problème du député confus.

Prévenir les exploits confus des adjoints dansAWS OpsWorks CM

Cette section explique comment vous pouvez aider à prévenir les exploits de député confus dansAWS OpsWorks CM, et inclut des exemples de stratégies d'autorisations que vous pouvez attacher au rôle IAM auquel vous utilisez pour accéderAWS OpsWorks CM. Afin de vous aider à optimiser la sécurité, nous vous recommandons d'ajouter leaws:SourceArnetaws:SourceAccountclés de condition des relations de confiance que votre rôle IAM entretient avec d'autres services. Les relations de confiance permettentAWS OpsWorks CMpour assumer un rôle pour effectuer des actions dans d'autres services nécessaires à la création ou à la gestion de votreAWS OpsWorks CMweb.

Pour modifier les relations de confiance à ajouteraws:SourceArnetaws:SourceAccountClés de condition
  1. Ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.

  2. Dans le panneau de navigation de gauche, choisissez Rôles.

  3. DansRecherche, recherchez le rôle que vous utilisez pour accéder àAWS OpsWorks CM. LeAWSle rôle géré estaws-opsworks-cm-service-role.

  4. Dans la pageRécapitulatifpour le rôle, choisissez leRelations d'approbationOnglet.

  5. Dans l'onglet Relations d'approbation, choisissez Modifier la relation d'approbation.

  6. DansDocument de stratégie, ajoutez au moins l'un desaws:SourceArnouaws:SourceAccountclés de condition de la stratégie. Utiliseraws:SourceArnpour restreindre la relation de confiance entre les services interservices (tels queAWS Certificate Manageret Amazon EC2) etAWS OpsWorks CMvers spécifiquesAWS OpsWorks CMserveurs, ce qui est plus restrictif. Additionaws:SourceAccountrestreindre la relation de confiance entre les services interservices etAWS OpsWorks CMaux serveurs d'un compte spécifique, ce qui est moins restrictif. Voici un exemple. Notez que si vous utilisez les deux clés de condition, les ID de compte doivent être identiques.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "opsworks-cm.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnEquals": { "aws:SourceArn": "arn:aws:opsworks-cm:us-east-2:123456789012:server/my-opsworks-server/EXAMPLEabcd-1234-efghEXAMPLE-ID" } } } ] }
  7. Lorsque vous avez fini d'ajouter des clés de condition, choisissezMise à jour de la politique.

Voici d'autres exemples de rôles qui limitent l'accès àAWS OpsWorks CMweb en utilisantaws:SourceArnetaws:SourceAccount.

Exemple : Accès àAWS OpsWorks CMweb dans une région spécifique

L'instruction de relation d'approbation de rôle suivante permet d'accéder à n'importe quelAWS OpsWorks CMdans la région USA Est (Ohio) (us-east-2). Notez que la région est spécifiée dans la valeur ARN deaws:SourceArn, mais la valeur de l'ID du serveur est un caractère générique (*).

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "opsworks-cm.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnEquals": { "aws:SourceArn": "arn:aws:opsworks-cm:us-east-2:123456789012:server/*" } } } ] }

Exemple : Ajout de plusieurs ARN de serveur àaws:SourceArn

L'exemple suivant montre comment limiter l'accès à un tableau de deuxAWS OpsWorks CMserveurs sous l'ID de compte 123456789012.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "opsworks-cm.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnEquals": { "aws:SourceArn": [ "arn:aws:opsworks-cm:us-east-2:123456789012:server/my-chef-server/unique_ID", "arn:aws:opsworks-cm:us-east-2:123456789012:server/my-puppet-server/unique_ID" ] } } } ] }