Les policies IAM

Le service IAM utilise des ressources appelées policies. Ce sont ces dernières qui vont déterminer le champ d'action autorisé.

Le formalisme d'une policy

Les policies AWS sont écrites en json.

Les policies utilisent des ARNs. Un ARN est un Amazon Resource Name, il s'agit d'un identifiant unique créé par amazon. Chaque service à sa propre structure, néanmoins, la structure de base reste toujours la même. Toutes les ressources créées sur AWS ont un ARN, parfois masqué.

Une policy AWS est basée sur 5 champs, optionnels ou obligatoire :

• Un champ "effect" : Ce champ est obligatoire, il permet d'indiquer si le bloc autorise ou interdit des actions.
• Un champ "action": Ce champ est obligatoire, il indique les verbes autorisés, combiné avec les ressources
• Un champ "resource": Ce champ est obligatoire, c'est lui qui va indiquer les ressources autorisées, à noter que le wildcard ('*') est autorisé pour former le nom des ressources
• Un champ "conditions": Ce champ est facultatif, il permet d'indiquer des conditions supplémentaires
• Un champ "sid": Ce champ est facultatif, il permet d'indiquer un identifiant pour faciliter les sessions de debug, je recommande fortement de l'indiquer. A noter que cette identifiant est unique au sein de la même policy.

Voici par exemple une policy autorisant à créer un bucket s3 nommé "demo-bucket-tferdinandnet" :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "mapolicyS3",
      "Action": [
        "s3:CreateBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::demo-bucket-tferdinandnet"
    }
  ]
}

Comme vous pouvez le voir dans l'exemple ci-dessus, ma policy porte aussi deux informations obligatoires au plus haut niveau de la structure de mon json :

• Le champ "version": Ce champ indique la version de la configuration utilisée, ce point est utile dans le cas où la syntaxe des policies changeait demain, car il assure la rétrocompatibilité
• Le champ "statement" : C'est ici que nous allons indiquer notre policy

Les différents types de policy IAM

Identity-based VS resource-based

Il existe deux catégories de policies AWS, les "identity based" et les "resource based", les premières vont s'appliquer aux ressources IAM décrites plus haut.

Les secondes s'appliquent sur certains services Amazon. Par exemple S3 utilise des policies "resource based" qui permettent d'indiquer qui à le droit d'accéder à mes objets. Ces dernières étant spécifiques à chaque service AWS, je reviendrais dessus lorsque nous les utiliseront.

Il existe à ce jour 3 types de policies IAM en Identity based. Chaque type de policy a sa portée, et il est important de les maitriser pour exploiter la pleine puissance de l'IAM.

Les inline policies

Il est possible de créer des policies dites "inline", ces dernières sont directement rattachées à la ressource sur laquelle vous la définissez (par exemple un utilisateur), et ne peuvent pas être partagées entre plusieurs ressources.

C'est le niveau de policy le plus spécifique.

Les managed policies

Le second type de policy est les managed policies. Ce sont sans doute les policies que nous allons manipuler le plus durant ce tutoriel.

Les managed policies sont créées de la même manière que les inline, mais elles peuvent être rattachées à de nombreuses ressources simultanément.

Ces policies sont le meilleur moyen de factoriser les autorisations et d'éviter le maintien de nombreuses inline policies en parallèle et donc d'éviter les risques de divergences.

Les AWS managed policies

Petite variante des précédentes, les AWS managed policies sont des policies génériques, créée par AWS sur tous les comptes. Elles peuvent elles aussi être utilisées de nombreuses fois en même temps.

La différence majeure réside dans le fait qu'il est impossible de modifier ces policies, seul AWS le peut.

Le principe des boundaries

Afin d'éviter les élévations de droits, il est possible de définir en supplément des policies des notions de boundaries.

De quoi s'agit-il ? Il s'agit de mettre un policy "barrière" autour d'un objet pour éviter les élévations de droit.

Par exemple, je peux autoriser un utilisateur à créer d'autres utilisateurs, mais en imposant l'utilisation d'une boundary, de cette manière les utilisateurs qu'il pourra créer n'auront jamais plus de droits que lui, quelle que soit la policy qu'il leur définit.

Il faut voir les boundary comme un tamis, seules les permissions qui passent la policy de la ressource et la boundary en même temps seront appliquées.

A noter que seules les policy "managed" peuvent être utilisées pour ce faire, comme indiqué précédemment les inline policies sont spécifiques à une ressource.

Nous exploiterons ce concept durant nos tutoriels, encore une fois, pas de panique.

Page suivante : Utilisateurs et Rôles