Politiques de confiance et identités autorisées à utiliser un rôle

Une politique de confiance est le document associé à un rôle qui définit précisément quels principals sont autorisés à l’endosser. Elle joue le rôle de gardienne : même si une politique de permissions accorde un accès puissant, personne ne peut utiliser le rôle à moins d’être nommé dans la politique de confiance. À l’examen, les erreurs de politique de confiance sont une cause fréquente d’accès bloqués comme d’attributions excessives et dangereuses de permissions.

L’élément Principal d’une politique de confiance peut référencer :

• AWS — un compte, un utilisateur ou un ARN de rôle (Amazon Resource Name).
• Service — un service AWS tel que lambda.amazonaws.com.
• Federated — un fournisseur SAML ou un fournisseur d’identités Web.

Choisir le bon type de principal et être précis est essentiel pour éviter d’accorder une confiance plus large que prévu.

L’endossement intercomptes exige l’accord des deux parties. La politique de confiance du rôle dans le compte cible doit autoriser le principal appelant, et ce principal doit disposer d’une politique d’identité autorisant sts:AssumeRole sur l’ARN du rôle. L’absence de l’un ou l’autre de ces éléments bloque la demande. Cette négociation à deux volets constitue un piège classique de l’examen.

Cette politique de confiance permet à un rôle précis du compte 111122223333 d’endosser le rôle. Nommer un ARN exact plutôt que le compte entier est plus restrictif et plus sûr.

Indiquer un principal sous la forme arn:aws:iam::ACCOUNT:root signifie faire confiance à l’intégralité du compte : tout principal qui s’y trouve et qui possède également la permission sts:AssumeRole peut endosser le rôle. Cette confiance est large. Lorsque cela est possible, nommez l’ARN exact de l’utilisateur ou du rôle afin de respecter le moindre privilège et de réduire la surface de confiance.

Les politiques de confiance prennent en charge des blocs Condition qui restreignent qui peut endosser un rôle et dans quelles conditions. Les clés courantes comprennent sts:ExternalId (pour empêcher le problème du mandataire confus), aws:MultiFactorAuthPresent (pour exiger MFA) et aws:SourceIp. Les conditions permettent d’autoriser l’endossement uniquement dans des circonstances précises et vérifiables.

Une méthode puissante consiste à exiger MFA avant qu’un rôle sensible puisse être endossé. La condition de la politique de confiance vérifie que la session appelante a été authentifiée avec MFA. Ainsi, même un identifiant à longue durée de vie volé ne peut pas endosser le rôle privilégié sans le second facteur, ce qui augmente considérablement la difficulté pour les attaquants.

Certains rôles sont des rôles liés à un service, prédéfinis par AWS avec une politique de confiance que vous ne pouvez pas modifier. Ils permettent à un service de gérer des ressources en votre nom, avec exactement le niveau de confiance requis par AWS. Il est important de les reconnaître, car leurs permissions et leur confiance sont étroitement contrôlées et liées au cycle de vie du service.

Faire confiance à un principal interne (dans le même compte) présente généralement moins de risques que faire confiance à un compte externe ou à un fournisseur SaaS tiers. Pour une confiance externe, associez toujours un principal précis à des conditions telles que ExternalId. Considérez chaque déclaration de confiance externe comme un point d’entrée qu’un attaquant rêverait d’exploiter.

IAM Access Analyzer examine automatiquement les politiques de confiance et les politiques de ressources afin de trouver les rôles pouvant être endossés par des comptes externes ou par le public. Il signale les relations de confiance intercomptes ou publiques involontaires afin que vous puissiez les restreindre. L’examen des résultats d’Access Analyzer est un contrôle recommandé et pertinent pour l’examen, qui permet de détecter les relations de confiance trop larges.

Pour concevoir une relation de confiance sûre : nommez le principal le plus précis possible, ajoutez des conditions telles qu’ExternalId et MFA lorsque cela est approprié, privilégiez les rôles plutôt que la confiance envers la racine du compte et effectuez une revue avec Access Analyzer. Souvenez-vous que la politique de confiance répond à la question qui, tandis que les politiques de permissions répondent à la question quoi : les deux doivent être cohérentes pour que l’accès fonctionne tout en respectant le moindre privilège.

Vérifiez vos connaissances des politiques de confiance.

Une politique de confiance définit quels principals peuvent endosser un rôle et joue le rôle de gardienne, quelles que soient les politiques de permissions. L’endossement intercomptes nécessite une négociation à deux volets : la politique de confiance et la permission sts:AssumeRole de l’appelant. Privilégiez les ARN de principals précis à la racine du compte, ajoutez des conditions telles qu’ExternalId et MFA, et effectuez un audit avec IAM Access Analyzer.