Autoriser l'accès aux services avec IAM

Déployer des applications sur AWS

Dunieski Otano

Amazon Web Services Solutions Architect

La clé dans le commit

Une clé d'accès persistante est ajoutée au dépôt
Un bot de scan la trouve et fait exploser la facture
Les rôles et le moindre privilège évitent cela

Une clé d'accès AWS divulguée par erreur dans un commit, signalée comme risque de sécurité

Principaux IAM : utilisateurs, rôles et stratégies

Schéma IAM en trois colonnes : Principal (utilisateur, service ou rôle) à gauche, document de stratégie avec actions Allow/Deny au centre, rôle IAM avec identifiants temporaires de courte durée à droite

Principal : qui effectue la requête
Policy : document JSON accordant des autorisations
Role : ensemble d'autorisations qu'une entité peut assumer
Les rôles s'assument ; les utilisateurs détiennent des identifiants persistants

De bons identifiants programmatiques

Lambda : un rôle d'exécution accorde les autorisations
EC2 : un profil d'instance fournit les identifiants du rôle
ECS : des rôles de tâche limitent les autorisations par tâche
Aucune clé d'accès persistante dans le code ou la config

Trois services de calcul AWS utilisant des rôles sans clés persistantes : Lambda avec rôle d'exécution, EC2 avec profil d'instance, et ECS avec rôle de tâche, chacun montrant une rotation automatique des identifiants

AssumeRole et STS

STS AssumeRole : obtenir des identifiants temporaires pour un rôle
Utilisé pour l'accès cross-account
La stratégie de confiance définit qui peut assumer le rôle
Identifiants de courte durée, expiration automatique

Flux STS AssumeRole inter-comptes : l'appelant du compte A demande des identifiants à STS, la stratégie de confiance du rôle du compte B l'autorise, STS renvoie des identifiants temporaires à expiration automatique

Moindre privilège et structure d'une stratégie

Une déclaration de stratégie comporte trois parties obligatoires (Effect, Action et Resource) plus une Condition facultative :

{
  "Effect": "Allow",
  "Action": "dynamodb:PutItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders",
  "Condition": {
    "Bool": { "aws:SecureTransport": "true" }
  }
}

Où IAM s'arrête et où votre code commence

IAM : la couche service

Autorise les appels AWS API : ce rôle peut-il appeler cette opération ?
Ne peut pas imposer de règles par client ou par enregistrement

Votre code : la couche données

Vérifie l'utilisateur authentifié par rapport aux données demandées
Combinez les deux : IAM protège le service, votre code protège les données

Un rôle d'exécution à moindre privilège, en pratique

Rôle d'exécution Lambda minimal : unique autorisation DynamoDB PutItem accordée sur un seul ARN de table, sans caractères génériques sur l'action ni la ressource

Une Lambda doit écrire dans une table DynamoDB
Accorder dynamodb:PutItem uniquement sur l'ARN de cette table
Aucun caractère générique sur l'action ou la ressource
N'ajouter plus que si un appel réel est refusé

Passons à la pratique !

Déployer des applications sur AWS