IAM

Policy Documents

Document JSON permettant de définir les permissions :

• version (obligatoire)
• tableau de statements
  • Effet (Allow/Deny)
  • Action - liste des actions possibles
  • Ressource - ARN de la ressource à laquelle l’action est liée

Il est possible d’utiliser des wildcards (*) dans les champs Action et Ressource

Types de policies :

• Identity-based: attachées à une identité IAM donc un utilisateur (mauvaise pratique), groupe ou rôle
• Ressource-based: attachées directement à une ressource AWS (bucket S3 par exemple)

Dans un Policy Document, un Deny explicite est prioritaire par rapport à un Allow global

Trust Policies

Un rôle IAM comporte une trust policy, qui détermine qui a le droit d’assumer ce rôle. Elle est définie via le champ Principal.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "lambda.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Identifiants permanents

Les identifiants sont permanents car il n’y a pas de mécanisme automatique pour changer le mot de passe et des clés

Users: personne physique (pas de partage de compte)

Groups: fonction (contient des utilisateurs)

Roles: utilisation interne de AWS

Les utilisateurs héritent des permissions de leurs groupes

Les nouveaux utilisateurs n’ont pas de permission par défaut

Access key id et Secret access key permettent une connexion via le CLI

Bonnes pratiques

• Appliquer le principe du moindre privilège : ajouter le minimum de permissions possibles
• Sécuriser le compte root en activant le MFA
• Activer les logs CloudTrail
• Utiliser les policies managées autant que possible