4.2 - Concevoir, mettre en oeuvre et dépanner l'autorisation (politiques d'identité et de ressource, ABAC, frontières de permissions, Access Denied)
L'objectif 4.2 de l'AWS Certified Security Specialty couvre l'octroi des permissions justes et le diagnostic des refus qui en découlent. Tout part de l'évaluation des politiques : un Deny explicite, où qu'il se trouve, l'emporte toujours, une Service Control Policy et une frontière de permissions ne font que plafonner ce qu'une politique d'identité peut accorder et n'accordent jamais rien elles-mêmes, et un appel inter-comptes exige un Allow à la fois dans la politique de ressource et dans la politique d'identité de l'appelant. Tu attaches une frontière de permissions pour qu'un chef d'équipe crée des rôles qui ne dépasseront jamais la lecture seule, tu restreins encore une session avec une politique de session au moment de l'AssumeRole, et tu exprimes le contrôle d'accès par attributs avec aws:ResourceTag, aws:RequestTag et aws:TagKeys pour que les ingénieurs ne gèrent que les instances taguées à leur équipe. Les politiques de ressource se resserrent avec aws:PrincipalOrgID, aws:PrincipalOrgPaths, s3:prefix et aws:SourceVpce, tandis que l'accès KMS suit son propre chemin : la politique de clé décide, kms:ViaService limite l'usage à un service, et un grant prête une permission temporaire et révocable sans toucher à la politique de clé. Le dépannage passe par le décodage d'un message d'échec d'autorisation encodé, les variables de politique comme le nom d'utilisateur, le simulateur de politiques, IAM Access Analyzer et les données de dernier accès. Attends-toi à des scénarios Access Denied et à des questions sur le contrôle qui exprime une règle.
Frontière de permissions ou SCP qui autorise s3:* mais politique d'identité vide = le principal ne peut rien faire, un plafond n'accorde jamais. Rôle admin en échec sur une ressource chiffrée = la politique de clé KMS ne l'autorise pas. Message d'échec d'autorisation encodé = le décoder avec sts decode-authorization-message.
Questions d'entraînement
1. Une politique d'identite IAM autorise s3:GetObject sur un bucket, mais la politique de bucket refuse explicitement cette action pour ce principal. Que se passe-t-il quand le principal appelle GetObject ?
- L'acces est autorise, car les politiques d'identite priment sur celles de ressource
- L'acces est autorise, car les deux politiques sont evaluees independamment et l'une l'autorise
- L'acces est refuse (bonne réponse)
- L'acces depend de la politique attachee le plus recemment
Un Deny explicite, ou qu'il se trouve dans l'evaluation, l'emporte toujours, quelle que soit sa source. Il n'y a aucune priorite des politiques d'identite sur celles de ressource : AWS reunit toutes les politiques applicables, et un seul Deny explicite annule tous les Allow. L'ordre d'attachement n'entre jamais en compte.
2. Une Service Control Policy attachee a une unite d'organisation refuse ec2:RunInstances hors de eu-west-1. Un compte de cette UO a un administrateur portant la politique AdministratorAccess. Que peut faire cet administrateur ?
- Lancer des instances dans toutes les regions, puisque AdministratorAccess donne un acces complet
- Lancer des instances partout apres avoir detache la SCP depuis le compte membre
- Lancer des instances dans toutes les regions, car les SCP ne s'appliquent qu'aux utilisateurs IAM et pas aux roles
- Lancer des instances uniquement dans eu-west-1 (bonne réponse)
Une SCP definit le plafond de permissions d'un compte : elle n'accorde jamais rien, elle ne fait que limiter. AdministratorAccess ne peut pas depasser ce plafond, les SCP se gerent depuis le compte de gestion et ne peuvent pas etre detachees depuis un compte membre, et elles s'appliquent a tous les principaux du compte, roles compris. L'utilisateur root d'un compte membre y est egalement soumis.
3. Vous voulez qu'une politique IAM ne s'applique que si l'appelant s'est authentifie avec un facteur multiple. Quelle cle de condition exprime cela ?
- aws:SecureTransport
- aws:MultiFactorAuthPresent (bonne réponse)
- aws:PrincipalServiceNamesList
- aws:TokenIssueTime
aws:MultiFactorAuthPresent vaut vrai quand la requete a ete signee avec des identifiants obtenus via MFA. aws:SecureTransport indique seulement si TLS a ete utilise, aws:PrincipalServiceNamesList liste les principaux de service a l'origine d'un appel, et aws:TokenIssueTime donne l'anciennete des identifiants temporaires plutot que la maniere dont ils ont ete obtenus.
4. Un developpeur doit pouvoir transmettre un role a une instance EC2 sans pouvoir attacher n'importe quel role. Quelle permission controle cela ?
- ec2:AssociateIamInstanceProfile seul, sans autre restriction
- sts:AssumeRole sur tous les roles du compte
- iam:CreateRole limite par une frontiere de permissions
- iam:PassRole restreint a des ARN de roles precis (bonne réponse)
iam:PassRole est le garde qui decide quels roles un principal peut confier a un service, et restreindre sa Resource a des ARN precis est ce qui empeche l'escalade de privileges. Associer un profil sans limiter PassRole laisserait le developpeur attacher un role administrateur, AssumeRole concerne le fait d'assumer soi-meme un role, et CreateRole la creation de roles plutot que leur transmission.
5. Un chef d'equipe peut creer des roles IAM pour son escouade, mais aucun role qu'il cree ne doit depasser un acces en lecture seule. Quelle fonctionnalite impose ce plafond ?
- Une frontiere de permissions exigee sur chaque role qu'il cree (bonne réponse)
- Une Service Control Policy appliquee a toute l'organisation
- Un groupe IAM contenant les roles, avec une politique de lecture seule attachee au groupe
- Une politique de session transmise au moment ou chaque role est assume
Une frontiere de permissions plafonne ce qu'une identite creee pourra jamais faire, et l'on peut obliger le createur a en attacher une via une condition sur iam:PermissionsBoundary. Une SCP plafonnerait le compte entier plutot que les seuls roles de cette equipe, les groupes IAM ne peuvent pas contenir de roles, et les politiques de session ne valent que pour une session et ne peuvent pas etre imposees a la creation.
6. Vous devez donner a une fonction Lambda l'acces a exactement une table DynamoDB, sans possibilite d'atteindre les autres. Ou doit vivre la restriction ?
- Dans les variables d'environnement de la fonction, qui nomment la table autorisee et sont lues au demarrage
- Dans le code applicatif, qui verifie le nom de la table avant chaque appel et journalise tout ecart
- Dans l'element Resource de la politique du role d'execution, nommant l'ARN de la table (bonne réponse)
- Dans une politique de point de terminaison VPC attachee au sous-reseau ou la fonction fait ses appels reseau
Seule la politique IAM est appliquee par AWS lui-meme, donc restreindre Resource a l'ARN de la table fait echouer tout autre appel quoi que fasse le code. Les variables d'environnement et les verifications applicatives sont indicatives et disparaissent des que le code change ou est compromis, et les politiques de point de terminaison s'attachent au point de terminaison, pas a un sous-reseau.