Prévention interservices confuse des adjoints dans AWS 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 interservices confuse des adjoints dans AWS OpsWorks CM

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 la confusion des 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 avec des principaux de service qui ont eu accès aux ressources de votre compte.

Nous recommandons d'utiliser les clés de contexte de condition aws:SourceAccountglobale aws:SourceArnet les clés contextuelles dans les politiques de ressources afin de limiter les autorisations qui AWS OpsWorks CM accordent un autre service à la ressource. 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 l’association d’une ressource de ce compte à l’utilisation interservices.

La valeur de aws:SourceArn doit être l'ARN d'un serveur OpsWorks CM Chef ou Puppet.

Le moyen le plus efficace de se protéger contre le problème de confusion des adjoints consiste à utiliser la clé de contexte de condition aws:SourceArn globale avec l'ARN complet du AWS OpsWorks CM serveur. Si vous ne connaissez pas l'ARN complet ou si vous spécifiez plusieurs serveurs ARNs, utilisez la clé de condition de contexte aws:SourceArn globale 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 les touches de contexte de condition aws:SourceAccount globale aws:SourceArn et globale AWS OpsWorks CM pour éviter le problème de confusion des adjoints.

Empêchez les exploits d'adjoints confus dans AWS OpsWorks CM

Cette section décrit comment vous pouvez empêcher les exploits secondaires confus et inclut des exemples de politiques d'autorisation que vous pouvez associer au rôle IAM auquel vous accédez AWS OpsWorks CM. AWS OpsWorks CM Pour des raisons de sécurité, nous vous recommandons d'ajouter les clés de aws:SourceAccount condition aws:SourceArn et aux relations de confiance que votre rôle IAM entretient avec d'autres services. Les relations de confiance permettent AWS OpsWorks CM d'assumer un rôle pour effectuer des actions dans d'autres services nécessaires à la création ou à la gestion de vos AWS OpsWorks CM serveurs.

Pour modifier les relations de confiance afin d'ajouter aws:SourceArn et de aws:SourceAccount conditionner des clés
  1. Ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.

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

  3. Dans la zone de recherche, recherchez le rôle auquel vous souhaitez accéder AWS OpsWorks CM. Le rôle AWS géré estaws-opsworks-cm-service-role.

  4. Sur la page Résumé du rôle, choisissez l'onglet Relations de confiance.

  5. Dans l'onglet Trust relationships (Relations d'approbation), choisissez Edit trust relationship (Modifier la relation d'approbation).

  6. Dans le document de stratégie, ajoutez au moins l'une des clés de aws:SourceAccount condition aws:SourceArn ou à la politique. aws:SourceArnÀ utiliser pour restreindre la relation de confiance entre les services interconnectés (tels que AWS Certificate Manager Amazon EC2) et avec AWS OpsWorks CM des AWS OpsWorks CM serveurs spécifiques, ce qui est plus restrictif. Ajoutez aws:SourceAccount pour restreindre la relation de confiance entre les services interservices et AWS OpsWorks CM les 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, le compte IDs doit être le même.

    { "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 terminé d'ajouter des clés de condition, choisissez Mettre à jour la politique de confiance.

Vous trouverez ci-dessous d'autres exemples de rôles qui limitent l'accès aux AWS OpsWorks CM serveurs en utilisant aws:SourceArn etaws:SourceAccount.

Exemple : accès aux AWS OpsWorks CM serveurs d'une région spécifique

La déclaration de relation de confiance suivante permet d'accéder à tous AWS OpsWorks CM les serveurs de 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 que 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 limite l'accès à un ensemble de deux AWS OpsWorks CM serveurs 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" ] } } } ] }