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 commitée dans un dépôt
  • Un robot d'analyse la trouve et fait exploser la facture
  • Les rôles et le moindre privilège empêchent cela

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

Déployer des applications sur AWS

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

Diagramme IAM à trois colonnes : Principal (utilisateur, service ou rôle) à gauche, Document de stratégie avec actions Allow/Deny au centre, Rôle IAM avec justificatifs temporaires de courte durée à droite

  • Principal : qui fait la demande
  • Policy : document JSON accordant des permissions
  • Role : ensemble de permissions qu'une entité peut assumer
  • Les rôles sont assumés ; les utilisateurs détiennent des justificatifs persistants
Déployer des applications sur AWS

De bons justificatifs programmatiques

  • Lambda : un rôle d'exécution accorde les permissions
  • EC2 : un profil d'instance fournit les justificatifs du rôle
  • ECS : des rôles de tâche limitent les permissions 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, montrant chacun la rotation automatique des justificatifs

Déployer des applications sur AWS

AssumeRole et STS

  • STS AssumeRole : obtenir des justificatifs temporaires pour un rôle
  • Utilisé pour l'accès entre comptes
  • La stratégie d'approbation contrôle qui peut assumer le rôle
  • Les justificatifs sont de courte durée et expirent automatiquement

Flux STS AssumeRole entre comptes : l'appelant du compte A demande des justificatifs à STS, la stratégie d'approbation sur le rôle du compte B le permet, STS renvoie des justificatifs temporaires qui expirent automatiquement

Déployer des applications sur AWS

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 optionnelle :

{
  "Effect": "Allow",
  "Action": "dynamodb:PutItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders",
  "Condition": {
    "Bool": { "aws:SecureTransport": "true" }
  }
}
Déployer des applications sur AWS

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

IAM : la couche service

  • Autorise les appels d'API AWS : ce rôle peut‑il appeler cette opération ?
  • Ne peut pas imposer de règles par locataire ni par enregistrement

Votre code : la couche données

  • Vérifie l'utilisateur authentifié selon les données demandées
  • Utilisez les deux : IAM protège le service, votre code protège les données
Déployer des applications sur AWS

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

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

  • Une Lambda doit écrire dans une table DynamoDB
  • Accorder dynamodb:PutItem seulement sur l'ARN de cette table
  • Aucun caractère générique dans l'action ou la ressource
  • Ajouter plus seulement si un appel réel est refusé
Déployer des applications sur AWS

Passons à la pratique !

Déployer des applications sur AWS

Preparing Video For Download...