Politiques basées sur l'identité ou sur la ressource

Dans AWS, les permissions proviennent de politiques associées à deux emplacements : une identité (utilisateur, groupe ou rôle) ou une ressource (comme un compartiment S3 ou une clé KMS). Savoir quel type s'applique et comment ils se combinent est essentiel pour l'examen, car l'accès entre comptes dépend entièrement de cette distinction.

Une politique fondée sur l'identité est associée à un principal IAM et définit ce que ce principal peut faire. Elle ne comporte aucun élément Principal, car le principal est celui auquel elle est associée. Ces politiques peuvent être gérées par AWS, gérées par le client ou intégrées, et constituent le moyen le plus courant d'accorder des permissions.

Une politique fondée sur une ressource est associée directement à une ressource et comporte un élément Principal indiquant qui est autorisé à y accéder. Parmi les exemples figurent les politiques de compartiment S3, les politiques de clé KMS, les politiques de file d'attente SQS et les politiques de fonction Lambda. Elles précisent à la fois qui (Principal) et quoi (Action) pour cette ressource unique.

Cette politique de compartiment S3 accorde à un autre compte un accès en lecture. Le Principal désigne le compte de confiance, ce que seule une politique fondée sur une ressource peut faire.

Au sein d'un même compte, les politiques fondées sur l'identité et celles fondées sur une ressource se combinent par union : une requête est autorisée si l'une ou l'autre l'accorde (et si rien ne la refuse). Ainsi, un objet S3 peut être accessible si la politique de l'utilisateur ou celle du compartiment l'autorise. Il suffit que l'un des deux côtés ouvre l'accès.

Pour un accès entre comptes, la règle est plus stricte : les deux côtés doivent l'autoriser. Le principal doit disposer d'une politique fondée sur l'identité qui autorise l'action et la politique fondée sur la ressource de l'autre compte doit accorder l'accès à ce principal. Si l'une des deux moitiés manque, la requête est refusée. Cette distinction est très souvent évaluée à l'examen.

Les politiques de confiance des rôles sont techniquement une forme de politique fondée sur une ressource. C'est pourquoi l'acceptation d'un rôle entre comptes nécessite la politique de confiance ainsi que la permission d'identité sts:AssumeRole de l'appelant. Reconnaître la politique de confiance comme une politique fondée sur une ressource aide à unifier votre modèle mental de l'attribution des accès.

Tous les services ne prennent pas en charge les politiques fondées sur une ressource. Parmi les principaux services concernés figurent : S3, KMS, SQS, SNS, Lambda, Secrets Manager et ECR. Lorsqu'un service ne prend pas en charge ces politiques, l'accès entre comptes doit plutôt être accordé par l'acceptation d'un rôle. L'examen peut vérifier si une approche donnée est même possible pour un service donné.

Utilisez les politiques fondées sur l'identité pour les permissions générales du type « cette équipe peut effectuer ces opérations ». Utilisez les politiques fondées sur une ressource lorsque vous devez accorder l'accès à un principal externe précis, activer le partage entre comptes avec un service compatible ou définir des permissions qui restent associées à la ressource elle-même.

Comme l'accès peut provenir de l'un ou l'autre côté, l'audit exige de vérifier les deux. IAM Access Analyzer examine les politiques fondées sur une ressource afin de trouver les ressources partagées en externe ou publiquement. La simulation de politiques et les données du dernier accès sont utiles pour le côté de l'identité. Une vérification complète ne se limite jamais à un seul type.

L'accès au sein d'un même compte repose sur une union (l'une ou l'autre politique peut l'autoriser), tandis que l'accès entre comptes exige que la politique d'identité et la politique de ressource l'autorisent toutes les deux. Les politiques d'identité ne comportent pas de Principal ; les politiques de ressources, si. Faites correspondre le type de politique au scénario et souvenez-vous des services qui prennent en charge les politiques fondées sur une ressource.

Testez votre capacité à raisonner sur les types de politiques.

Les politiques fondées sur l'identité sont associées aux principaux et ne comportent pas d'élément Principal ; les politiques fondées sur une ressource sont associées aux ressources et désignent un Principal. L'accès au sein d'un même compte est une union des deux ; l'accès entre comptes exige que les deux l'autorisent. Seuls certains services (S3, KMS, SQS, SNS, Lambda, Secrets Manager et ECR) prennent en charge les politiques de ressources ; sinon, utilisez l'acceptation d'un rôle.