Resource Access Management:Prevent the confused deputy problem with external IDs

Fonctionnement de l'attaque

Prenons l'exemple d'un fournisseur tiers nommé Deputy, qui gère des ressources cloud (telles que l'audit des journaux, le suivi des coûts ou la surveillance de la sécurité) pour de nombreux comptes clients. Chaque client crée un rôle RAM dans son propre compte, désigne Deputy_Account en tant qu'entité de confiance et accorde au rôle les autorisations requises.

Sans identifiants externes, la politique d'approbation se présente comme suit :

• Le client A indique à Deputy : « Assumez le rôle acs:ram::CustomerA_AccountId:role/MonitorRole pour accéder à mon compte. »

• Un attaquant, également inscrit au service de Deputy, lui demande : « Assumez le rôle acs:ram::CustomerA_AccountId:role/MonitorRole pour accéder à mon compte. »

Comme Deputy ne dispose d'aucun moyen de vérifier pour quel compte il agit légitimement, il assume le rôle du client A à la demande de l'attaquant, lui donnant ainsi accès aux ressources de ce dernier. Il s'agit du problème du député confus : une entité de confiance est trompée et effectue des opérations non autorisées pour le compte d'une entité malveillante. RAM propose les identifiants externes pour prévenir ce risque. Pour plus d'informations, consultez la rubrique AssumeRole.

Fonctionnement des identifiants externes

1. Deputy génère un identifiant externe unique et aléatoire pour chaque client. Cet identifiant n'est pas secret : sa valeur sécuritaire réside dans son unicité et son association à un client spécifique, et non dans sa confidentialité. Toute personne disposant des autorisations nécessaires pour consulter le rôle peut voir l'identifiant externe.

2. Chaque client ajoute l'identifiant externe à la politique d'approbation du rôle RAM que Deputy assumera. La politique d'approbation exige que tout appelant présente cet identifiant externe lors de l'assumption du rôle.

3. Lorsque Deputy appelle AssumeRole pour assumer le rôle d'un client, il transmet l'identifiant externe attribué à ce client. Si l'identifiant est absent ou ne correspond pas à celui défini dans la politique d'approbation, l'appel échoue. Cette mesure bloque la tentative de l'attaquant, même si celui-ci fournit le bon ARN de rôle.

Configuration des identifiants externes

Dans cet exemple, le fournisseur tiers est Deputy (compte Deputy_Account), le compte client est Customer_Account et l'identifiant externe que Deputy a attribué à ce client est abcd1234.

1. Dans Customer_Account, créez un rôle RAM avec Deputy_Account comme entité de confiance et accordez au rôle les autorisations requises.

   Pour plus d'informations, consultez les rubriques Create a RAM role for a trusted Alibaba Cloud account et Grant permissions to a RAM user.

2. Modifiez la politique d'approbation du rôle RAM pour ajouter une condition ExternalId. Cette condition exige que tout appelant fournisse abcd1234 comme identifiant externe.

   {
     "Statement": [
       {
         "Action": "sts:AssumeRole",
         "Effect": "Allow",
         "Principal": {
           "RAM": [
             "acs:ram::<deputy-accountId>:root"
           ]
         },
         "Condition": {
           "StringEquals": {
             "sts:ExternalId": "abcd1234"
           }
         }
       }
     ],
     "Version": "1"
   }

   Pour plus d'informations, consultez la rubrique Edit the trust policy of a RAM role.

3. Lorsque Deputy assume le rôle pour accéder aux ressources de Customer_Account, il fournit abcd1234 comme identifiant externe. Plus précisément, il définit le paramètre ExternalId sur abcd1234 dans la requête AssumeRole.

   Pour plus d'informations, consultez la rubrique AssumeRole.

4. Deputy utilise le jeton STS (Security Token Service) renvoyé par AssumeRole pour accéder aux ressources dans Customer_Account.

Vérification de la configuration

Après avoir ajouté la condition ExternalId, vérifiez que la protection est active en tentant d'appeler AssumeRole sans identifiant externe. L'appel doit échouer avec une erreur d'accès refusé. En cas de succès, la condition n'a pas été appliquée correctement. Vérifiez la politique d'approbation et confirmez que sts:ExternalId apparaît bien dans le bloc Condition.

Remarques d'utilisation

• Générez un identifiant externe par compte client. Utilisez une chaîne aléatoire pour éviter toute prévisibilité.

• Les identifiants externes ne sont pas confidentiels. Leur valeur sécuritaire repose sur l'unicité et l'association, et non sur le secret. Ne comptez pas sur la confidentialité de l'identifiant externe comme mesure de sécurité.

Références

Use a RAM role to grant permissions across Alibaba Cloud accounts