Les fondamentaux d'IAM

Qui a le droit de faire quoi

Chaque action dans AWS revient à une seule question : cette identité a-t-elle le droit de faire cette chose sur cette ressource ? AWS Identity and Access Management, ou IAM, est le service qui y répond. IAM est l'endroit où vous décidez qui peut se connecter à votre compte et ce que chaque personne ou application est autorisée à faire une fois à l'intérieur.

C'est important parce qu'un compte AWS démarre avec une seule identité toute-puissante et rien d'autre. Le travail réel implique de nombreuses personnes et de nombreuses applications, chacune ayant besoin d'une part d'accès différente. IAM est la façon de distribuer ces parts en toute sécurité. Ce service pèse une bonne partie du domaine Sécurité et conformité à l'examen, donc les éléments de base présentés ici méritent d'être bien appris.

Ce qu'est IAM

IAM est un service web qui contrôle l'accès à vos ressources AWS. Il fait deux choses :

• L'authentification confirme qui émet une requête. Quand vous vous connectez avec un mot de passe ou qu'une application appelle AWS avec une clé, IAM vérifie ces informations d'identification face à une identité qu'il connaît.
• L'autorisation décide ce que cette identité peut faire. Une fois qu'AWS sait qui vous êtes, il vérifie vos autorisations pour voir si l'action précise demandée est permise.

Deux faits sur IAM sont des points faciles à l'examen. D'abord, IAM est un service global : les identités que vous créez ne sont pas liées à une région, donc vous ne choisissez jamais de région en créant un utilisateur ou un rôle. Ensuite, IAM lui-même est gratuit. Vous payez seulement les ressources AWS utilisées par vos identités, pas IAM.

Les éléments de base

IAM vous donne quatre éléments pour travailler. Maîtrisez-les et l'essentiel du thème se met en place.

Les utilisateurs IAM

Un utilisateur IAM est une identité pour une personne ou une application qui a besoin d'un accès à long terme à votre compte. Un utilisateur peut avoir un mot de passe pour se connecter à la console, des clés d'accès pour l'accès programmatique, ou les deux. Chaque utilisateur est une identité distincte avec ses propres informations d'identification, ce qui permet de savoir qui a fait quoi.

Les groupes IAM

Un groupe est un ensemble d'utilisateurs. Vous attachez des politiques au groupe, et chaque utilisateur qu'il contient hérite de ces autorisations. Les groupes simplifient la gestion des autorisations : placez vos développeurs dans un groupe Developers, attachez les bonnes politiques une seule fois, et les nouveaux développeurs obtiennent le même accès dès que vous les ajoutez. Un groupe n'est pas une identité avec laquelle vous pouvez vous connecter, il n'a pas d'informations d'identification, et vous ne pouvez pas imbriquer un groupe dans un autre.

Les rôles IAM

Un rôle est une identité que vous créez avec un ensemble d'autorisations, mais contrairement à un utilisateur il n'est pas lié à une personne et n'a ni mot de passe ni clés d'accès à long terme. À la place, un principal de confiance endosse le rôle et reçoit des informations d'identification de sécurité temporaires pour cette session. Les rôles permettent d'accorder un accès sans distribuer de clés permanentes. Parmi les usages courants : donner à une instance EC2 l'autorisation de lire depuis S3, laisser un compte AWS accéder à un autre, et accorder un accès à des utilisateurs qui ont déjà des identités en dehors d'AWS.

La différence entre un utilisateur et un rôle revient souvent à l'examen. Un utilisateur est une identité permanente avec ses propres informations d'identification. Un rôle est un chapeau temporaire qu'un principal enfile, le temps d'obtenir des informations d'identification de courte durée, puis retire.

Les politiques IAM

Une politique est un document, généralement écrit en JSON, qui liste des autorisations. Vous attachez des politiques à des utilisateurs, des groupes ou des rôles pour définir ce qu'ils peuvent faire. AWS fournit aussi des politiques gérées par AWS, des politiques prêtes à l'emploi pour les tâches courantes que vous attachez comme point de départ, à côté des politiques gérées par le client que vous écrivez vous-même.

Une instruction de politique simple comporte quelques parties clés :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-example-bucket"
    }
  ]
}

• Effect vaut Allow ou Deny.
• Action liste les opérations, comme s3:ListBucket.
• Resource nomme ce sur quoi les actions s'appliquent.

Vous n'avez pas besoin d'écrire du JSON à la main pour l'examen, mais vous devez reconnaître ces parties et savoir que c'est Effect qui fait qu'une instruction autorise ou bloque une action.

Comment une requête est évaluée

Quand un principal émet une requête, AWS la traite dans l'ordre.

1. Authentification. AWS fait correspondre les informations d'identification de la requête à un principal qu'il connaît : un utilisateur IAM, une session de rôle ou une identité fédérée.
2. Autorisation. AWS rassemble toutes les politiques qui s'appliquent et vérifie si l'action est autorisée.

La réponse par défaut est non. L'accès est refusé sauf si une politique l'autorise explicitement, et un Deny explicite dans n'importe quelle politique l'emporte toujours, même sur un Allow. Une requête aboutit donc seulement quand quelque chose l'autorise et que rien ne la refuse.

Politiques basées sur l'identité et sur les ressources

Les politiques prennent deux grandes formes, et les distinguer aide à l'examen.

Les politiques basées sur l'identité disent « cette identité peut faire ces choses ». Les politiques basées sur les ressources disent « ces principaux peuvent faire ces choses sur moi ». Un rôle est un cas particulier : il porte à la fois une politique d'autorisations et une politique d'approbation qui nomme qui a le droit de l'endosser.

Points clés pour l'examen

• IAM contrôle l'authentification (qui vous êtes) et l'autorisation (ce que vous pouvez faire).
• IAM est un service global et gratuit. Vous payez seulement les ressources utilisées par les identités.
• Quatre éléments de base : utilisateurs (une personne ou une application), groupes (un ensemble d'utilisateurs), rôles (endossables, informations d'identification temporaires) et politiques (autorisations en JSON).
• Un utilisateur a des informations d'identification à long terme ; un rôle s'endosse pour des informations d'identification temporaires. Retenez cette différence.
• Les groupes n'ont pas d'informations d'identification et ne peuvent pas être imbriqués.
• L'accès est refusé par défaut ; un Deny explicite l'emporte toujours sur un Allow.
• Les politiques basées sur l'identité s'attachent aux utilisateurs, groupes et rôles. Les politiques basées sur les ressources s'attachent à une ressource et nomment le principal.