Conditions, caractères génériques et variables de politique

Au-delà de l’action et de la ressource, IAM offre des outils puissants pour rendre les politiques précises et dynamiques : les conditions, les caractères génériques et les variables de politique. Leur maîtrise vous permet d’accorder exactement l’accès nécessaire dans les circonstances appropriées, ce qui constitue l’essence du moindre privilège et un thème récurrent des examens.

Un bloc Condition contient un ou plusieurs tests qui doivent tous être vrais pour que la déclaration s’applique. Chaque test associe un opérateur à une clé de condition et à une valeur, par exemple StringEquals sur aws:PrincipalTag. Plusieurs clés dans un même bloc sont combinées par un ET ; plusieurs valeurs pour une même clé sont combinées par un OU.

Les clés de condition globales apparaissent constamment à l’examen :

• aws:SourceIp — restreindre selon la plage d’adresses IP de l’appelant.
• aws:SecureTransport — exiger TLS.
• aws:MultiFactorAuthPresent — exiger MFA.
• aws:PrincipalOrgID — restreindre à votre organisation.

Les clés propres aux services (comme s3:prefix) permettent un contrôle encore plus précis.

Un schéma classique consiste à refuser l’accès si la demande n’utilise pas TLS. Cette condition de politique de compartiment bloque tout appel non HTTPS et garantit que les données en transit sont toujours chiffrées. L’examen apprécie particulièrement cet exemple comme réponse à « exiger le chiffrement en transit pour S3 ».

Les opérateurs définissent la manière dont les valeurs sont comparées : StringEquals, StringLike (prend en charge les caractères génériques), IpAddress, DateGreaterThan, Bool et Null, entre autres. Ajouter IfExists à un opérateur le fait réussir lorsque la clé est absente. Choisir le bon opérateur est essentiel pour obtenir la logique attendue.

Les caractères génériques (* pour toute séquence, ? pour un caractère) rendent les politiques concises, mais peuvent accorder trop d’autorisations. s3:Get* couvre toutes les opérations de type lecture ; s3:* couvre tout dans S3. Utilisez le caractère générique le plus restreint qui répond au besoin et méfiez-vous des caractères génériques trop larges dans toute politique que vous examinez.

Les ARN de ressource acceptent également les caractères génériques, par exemple arn:aws:s3:::logs/2024/* pour limiter la portée à un préfixe. Une politique peut ainsi cibler un dossier ou un modèle sans répertorier chaque objet. Toutefois, une ressource définie uniquement par « * » accorde une portée à l’ensemble du compte ; demandez-vous donc toujours si une telle étendue est réellement nécessaire.

Les variables de politique insèrent le contexte de la demande au moment de l’évaluation à l’aide de la syntaxe ${...}. La plus utile est ${aws:username}, qui permet à une seule politique de donner à chaque utilisateur un accès limité à ses propres ressources. Les variables permettent à une politique réutilisable unique de se comporter différemment selon le principal, ce qui facilite élégamment la mise à l’échelle du moindre privilège.

Cette déclaration permet à chaque utilisateur de gérer uniquement les objets situés dans un dossier portant son nom d’utilisateur : un modèle puissant où une seule politique est utilisée pour tous.

Le contrôle d’accès basé sur les attributs (ABAC) utilise des balises dans les conditions, en comparant les balises du principal (aws:PrincipalTag) à celles d’une ressource (aws:ResourceTag). Lorsqu’elles correspondent, l’accès est accordé. ABAC s’adapte remarquablement bien : vous accordez l’accès selon les balises au lieu d’écrire une nouvelle politique pour chaque projet, une bonne pratique moderne mise en avant à l’examen.

Combinez ces outils de manière réfléchie : utilisez les conditions pour subordonner l’accès à MFA, à l’adresse IP, à TLS ou à l’appartenance à une organisation ; utilisez les caractères génériques avec parcimonie et précision ; utilisez les variables de politique et les balises pour appliquer à grande échelle le moindre privilège par principal. Ensemble, ils permettent à une politique bien conçue d’imposer un accès précis et contextuel à de nombreuses identités et ressources.

Testez les conditions et les variables.

Les conditions subordonnent les déclarations à des clés de contexte (aws:SourceIp, aws:SecureTransport, aws:MultiFactorAuthPresent, aws:PrincipalOrgID) à l’aide d’opérateurs comme StringLike et Bool. Les caractères génériques (* et ?) rendent les politiques concises, mais peuvent accorder trop d’autorisations. Les variables de politique comme ${aws:username} et l’ABAC basé sur les balises permettent d’appliquer à grande échelle le moindre privilège par principal.