IAM aws

L'une des étapes incontournables d'Amazon Web Service est de bien comprendre le service IAM (Identity and Access Management). C'est l'un des services les plus importants car il permet de gérer les utilisateurs ou services qui peuvent avoir accès à votre compte AWS. Nous allons l'étudier ensemble.

Introduction

IAM permet de donner des droits très fins à un utilisateur, un utilisateur pouvant d'ailleurs être une machine. L'idée est de donner par exemple accès aux services S3 seulement en lecture pour un utilisateur défini uniquement pendant 1h le 2 janvier.

C'est le point central de votre sécurité, il permet de gérer l'ensemble des accès sécurisés de votre business.

AWS nous donne aussi la définition de ce qu'IAM n'est pas :

• Il ne permet pas de gérer les permissions de vos applications. IAM ne sert que pour les permissions de vos services AWS.
• IAM n'est pas un OS de management d'identités type LDAP ou active directory.

Les principes

Utilisateur racine (Root User)

Lors de la création de votre compte AWS, vous avez créé un compte racine (Root User). C'est le compte avec le plus de permissions possible, il est le propriétaire du compte, il peut s'il le souhaite supprimer le compte.

Attention, ce compte étant le compte principal, il faut absolument qu'il soit fortement sécurisé avec un Multi-Factor Application (double authentification).

Il est déconseillé d'utiliser ce user tous les jours, car il a énormément d'accès. C'est un peu comme être en ROOT sur votre machine UNIX toute la journée. Le mieux est de créer un utilisateur IAM, comme vous allez pouvoir le voir dans le chapitre suivant.

Utilisateur IAM

Un utilisateur IAM représente une personne physique ou une application. Vous devez créer un utilisateur différent pour tous les membres de votre équipe qui doivent utiliser des services AWS. Il est important de correctement séparer leurs droits, afin de permettre de sécuriser chaque service de votre compte AWS.

Un utilisateur peut se créer via la console AWS ou directement en CLI. Mais ça, nous le verrons plus tard.

Comme évoqué précédemment, il est donc possible de définir des droits très précis pour un utilisateur identifié. Si vous souhaitez qu'un utilisateur ait les mêmes droits qu'un autre, la notion de groupe est importante.

Groupes

Un groupe est un object qui permet de définir des droits pour un ensemble d'utilisateurs. L'idée est d'avoir un groupe d'utilisateurs ayant exactement les mêmes droits, cela permet de centraliser vos configurations. L'un des groupes est par exemple 'developpeur'. Vous pouvez alors donner des droits spécifiques à tous vos développeurs.

Rôles

Les rôles permettent de donner acccès à des services spécifiques pendant un temps donné. Ils ont quatre usages différents :

• Donner des accès à un autre compte AWS
• Donner des accès à un compte externe
• Donner des accès à vos services à une application EC2 ou autre
• Donner des accès à un système de fédération

Accès entre compte (Cross-account)

Le Cross-account permet de donner des accès à un utilisateur venant d'un autre compte AWS. On le met souvent en place pour qu'une société externe puisse avoir accès à un bucket par exemple.

Compte externe

Comme pour le cross-account, cela permet de donner des accès à une personne via son identité :

• Google
• Facebook
• Amazon

Accès à un service

Il est souvent nécessaire de donner un accès a des services AWS pour une application installée sur un autre service AWS. Par exemple si une machine EC2 doit avoir accès à un bucket en lecture. Il serait possible de le faire via l'API, mais cela est plus compliqué pour les développeurs et demanderait d'envoyer la clé sur l'ensemble des machines. Avec ce système il suffit de donner le rôle lors de l'installation des machines pour que l'accès soit ouvert.

Fédération

La fédération permet de donner l'accès aux utilisateurs de votre provider d'identité via l'utilisation d'une configuration SAML 2.0 que vous transmettez à AWS. Cela permet d'utiliser vos utilisateurs Active Directory ou LDAP par exemple.

Authentification

Il existe 3 types d'authentification sur IAM.

La première, Username/Password, est la plus simple elle permet de se connecter via un login/password. IAM conseille de mettre en place une politique de mot de passe personnalisé. Elle est principalement utilisé pour la console AWS. Vous pouvez alors choisir plusieurs options :

• Nombre de caractères
• Nombre de caractères numériques
• Changement de mot de passe tous les X jours
• etc ...

La seconde est access key/secret key. Il s'agit d'une paire clé/secret qui permet de se connecter au SDK AWS. Cela vous permet d'utiliser AWS cli ainsi que l'api REST disponible par AWS.

La dernière est un mélange de access key et de session key. Elle est utilisée dans le cas des rôles et permet à l'utilisateur de se servir des services AWS via l'api REST.

Autorisation

Une fois l'authentification effectuée sur IAM, il faut donner des accès à vos utilisateurs. C'est dans ce cadre que l'autorisation est appliquée. Il s'agit alors de donner des accès spécifiques à chaque utilisateur. Pour ce faire nous utilisons les "policies" qui permettent de donner des droits très précis sur les services.

Policies

Il existe déjà beaucoup de "policies" crées par AWS. Vous pouvez choisir très rapidement des "policies" du type :

• Lecture sur Bucket
• Écriture Lambda

Mais il est possible de créer sa propre "policies". Pour cela il faut créer un objet JSON. Cet objet doit contenir les infos suivantes :

• Effect qui contient la valeur Allow ou Deny
• Resource qui contient l'ARN de la ressource utilisée sur la "policy"
• Action qui est une liste d'actions possibles representée par Service:Action
• Condition qui permet de mettre une condition à notre "policy", exemple "l'IP est..."

Cela pourrait donner un objet tel que :

{
	"Version": "2012-10-17",
	"Statement": [{
		"Sid": "Stmt2649856320145",
		"Effect": "Allow",
		"Action": [
			"s3:GetObject",
			"s3:ListBucket"
		],
		"Condition": {
			"IpAddress": {
				"aws:SourceIp": "192.168.0.1"
			}
		},
		"Resource": [
			"arn:aws:s3::my_public_bucket/*"
		]
	}]
}

Une fois votre "policy" créé, vous pouvez la mettre soit sur un utilisateur IAM, soit sur un groupe.

Autres features

Bien sûr, IAM propose d'autres fonctionnalités très importantes. La première est la gestion du MFA (Multi-factor authentification), qui permet d'utiliser une autre source d'authentification pour un utilisateur IAM. Vous pouvez très facilement ajouter la double authentification via Authenticator Google.

La seconde fonctionnalité est la rotation des clés d'accès. Le vieillissement d'une clé d'accès augmente l'insécurité, elle peut ne plus être utilisée ou alors être utilisée sur des machines anciennes. Via AWS il est possible de générer une nouvelle clé pour un utilisateur IAM. Cela permet de désactiver l'ancienne et d'en créer une nouvelle avec les mêmes droits.

La troisième est l'intégration des SAML type authentification Facebook, Google... Vous trouverez la documentation ici La dernière est de résoudre les multi-permissions. C'est AWS qui s'occupe de calculer la bonne permission en utilisant l'ensemble des policies configurées pour l'utilisateur.

Voilà, on a fait le tour. J'espère que cet article vous aura été utile et vous aura permis de mieux cerner IAM !