TD1 – Conception d’une stratégie IAM sécurisée

1. Concevoir une stratégie IAM cohérente
2. Appliquer le principe du moindre privilège
3. Comprendre les différences entre users, groupes et rôles
4. Industrialiser IAM avec Terraform

Vous intervenez comme ingénieur Cloud dans une startup.

L’infrastructure AWS existe déjà, mais aucun cadre de sécurité IAM n’a été défini.

Chaque développeur dispose actuellement de droits administrateur.

Un audit de sécurité impose :

- une refonte complète des accès - une gestion par rôles - une limitation stricte des permissions

Mettre en place une architecture IAM sécurisée pour :

- les administrateurs - les développeurs - les analystes

Le tout doit être :

- reproductible - versionné - automatisé avec Terraform

Vous devez respecter les règles suivantes :

- Aucun utilisateur ne doit avoir de droits administrateur globaux - Le principe du moindre privilège est obligatoire - Les permissions doivent être mutualisées (pas de duplication inutile) - Les accès doivent être compréhensibles et maintenables - Toute la configuration doit être réalisée avec Terraform

Documentation officielle :

- AWS IAM : concepts (users, groups, roles) - AWS IAM Policy JSON - Bonnes pratiques AWS IAM (least privilege)

Commandes utiles :

Fichier : `commandes/terraform.txt`

terraform init
terraform plan
terraform apply
terraform destroy

Vous devez produire une configuration Terraform permettant de :

1. Créer les entités suivantes :

1. 1 groupe Admin
2. 1 groupe Dev
3. 1 groupe Analyst

2. Définir des policies adaptées :

1. Admin : gestion complète de l’infrastructure
2. Dev : gestion EC2 uniquement
3. Analyst : lecture S3 uniquement

3. Associer correctement :

1. users → groupes
2. groupes → policies

4. Mettre en place au moins un rôle IAM pour un service AWS

Livrables attendus :

- code Terraform fonctionnel - structure claire des fichiers - justification des choix

Une mauvaise pratique courante consiste à utiliser :

- Action: “*” - Resource: “*”

Cette pratique est interdite dans ce TD.

Vous devez revoir votre architecture si :

- un utilisateur a trop de droits - une policy est trop large - des permissions sont dupliquées

Ajouter :

- une séparation environnement DEV / PROD - une restriction par ressource (ex : un seul bucket S3)

Un développeur doit pouvoir :

- lancer une instance EC2 - mais ne pas pouvoir supprimer une instance existante

Implémenter cette contrainte.

Vous devez être capable d’expliquer :

- votre architecture IAM - vos choix de policies - les compromis réalisés