Les IAM Permissions boundaries AWS pour les nuls

Ce n’est un secret pour personne, dans l'écosystème AWS (Amazon Web Services), la gestion des accès et des autorisations est d’une importance capitale pour garantir la confidentialité, l'intégrité et la disponibilité des ressources cloud.

Dans AWS nous avons le service Identity and Access Management (IAM), qui permet aux utilisateurs de gérer l'accès aux ressources à l'aide de permissions. Cependant, la complexité de ces dernières peut parfois rendre cette tâche difficile.

C'est là qu'interviennent les IAM Permissions boundaries. Conçues pour renforcer la gestion des autorisations, elles offrent un moyen de définir des limites sur les permissions accordées aux utilisateurs et rôles IAM. Cependant, il faut s’assurer que l'entité qui a la boundary n'a pas le droit ni de retirer ni de modifier la boundary pour empêcher l’élévation de privilèges.

Dans cet article, nous allons voir en détail leur fonctionnement, comment les utiliser et les bonnes pratiques associées.

La base des bases d’IAM

Première question que vous vous posez certainement, qu'est-ce qu'Identity and Access Management (IAM) dans AWS ?

On l’a défini rapidement dans l’introduction, mais allons un peu plus loin. Avec IAM, les administrateurs peuvent créer et gérer des utilisateurs, des groupes et des rôles. On définit ensuite des permissions pour contrôler qui peut accéder à quelles ressources AWS et comment.

Les permissions IAM sont des documents JSON qui définissent les autorisations. Elles spécifient quelles actions peuvent être effectuées sur quelles ressources, et par qui. En les attachant aux utilisateurs, groupes ou rôles IAM, les administrateurs peuvent contrôler précisément les actions que chaque entité peut effectuer dans AWS.

Cet exemple montre comment vous pouvez créer une permission qui autorise l'accès total aux actions dans le service RDS ayant pour préfixe “test”:

{
 "Version": "2012-10-17",
 "Statement": [
     {
         "Effect": "Allow",
         "Action": "rds:*",
         "Resource": ["arn:aws:rds:*:123456789012:db:test*"]
     }
 ]
}

Leur gestion peut devenir complexe à mesure que le nombre d'utilisateurs, de groupes et de ressources AWS augmente. On peut rapidement “se prendre les pieds dans le tapis” si l’on contrôle finement les accès, les permissions IAM peuvent devenir redondantes ou contradictoires.

Les permissions boundaries à la rescousse

Les IAM Permissions boundaries sont un moyen de gérer les autorisations dans AWS mais en définissant des limites maximales sur les droits accordés aux utilisateurs et les rôles IAM. 

On peut voir ça comme une couche de sécurité supplémentaire en limitant les actions permises, même si une règle IAM les y autorise.

Lorsqu'une entité IAM est créée ou mise à jour, les boundaries définies pour celle-ci, agissent comme un filtre sur les permissions qui lui sont attachées. Si l’une d’entre elles autorise une action qui est en dehors des limites, alors cette action sera refusée pour l'entité concernée. En revanche, si elle n'autorise que des actions conformes aux Boundaries, celles-ci sont accordées normalement.

Source 

L’utilité de mettre en place des boundaries est lorsque l’on veut bénéficier de plusieurs sources de permissions ou déléguer des responsabilités à d'autres équipes, tout en respectant les limites des autorisations.

Le schéma ci-dessus l’illustre parfaitement. On a d’un côté, un développeur qui a attribué à sa lamba des permissions “un peu” trop étendues, lui permettant d’accéder à toutes les actions et ressources SSM. De l’autre côté, nous avons les équipes de Sécurité et Opérationnelles qui ont mis en place une boundary limitant les permissions du rôle que la lambda va assumer. Ici les fonctions pourront au maximum effectuer des actions “GetParameter” même si du côté des dev’ ils ont donné le droit de faire “ce qu’ils veulent” dans SSM.

Source

Quelques cas concrets d’utilisation 

Voici quelques cas d'utilisation où les boundaries peuvent être particulièrement utiles.

Les boundaries peuvent être utilisés pour limiter les autorisations des équipes ou des départements à des ressources spécifiques, garantissant ainsi une séparation claire des responsabilités et une meilleure gestion des accès.

On peut également utiliser les boundaries pour déléguer les tâches de gestion des permissions, telles que la création d'utilisateurs aux différentes entités IAM ou aux différents comptes AWS de l’organisation. Cela permet à d'autres membres de l’équipe d'effectuer des tâches IAM à votre place, le tout dans un périmètre que vous avez au préalable défini avec les boundaries.

Pour les comptes IAM sensibles, tels que ceux ayant accès à des données confidentielles ou à des ressources critiques, les boundaries peuvent être utilisées pour forcer des restrictions supplémentaires sur les actions autorisées. Réduisant ainsi les risques de compromission si l’on a bien pris le soin de verrouiller la modification de la boundary pour notre utilisateur.

Prenons l'exemple d'une entreprise qui souhaite limiter les autorisations de ses développeurs. Actuellement ils ont une policy qui leur permet d’avoir tous les droits sur les services S3, CloudWatch, EC2 et IAM. Cependant, en tant qu'administrateur, on ne souhaite pas que nos développeurs puissent créer des utilisateurs. Pour faire ça, nous allons attacher une permission boundary au rôle “dev” qui va limiter les permissions uniquement aux services S3, CloudWatch et EC2. Voici comment cela pourrait être mis en œuvre.

Première étape, définition d'une Permission Boundary qui limite l'accès aux ressources nécessaires pour le développement. On enregistrera ce document JSON dans un fichier, par exemple dev-boundary-permissions.json :

{
  “Version”: “2012-10-17”,
  “Statement”: [
 {
   “Effect”: “Allow”,
   “Action”: [
     “s3:*”,
     “cloudwatch:*”,
     “ec2:*”
   ],
   “Resource”: ”*”
 }
  ]
}

Deuxième étape, création d’une policy IAM basée sur le fichier JSON :

aws iam create-policy --policy-name dev-boundary-permissions-policy 
--policy-document file://dev-boudary-permissions.json

Troisième étape, attachement de la boundary au user “dev-user” :

aws iam put-user-permissions-boundary --permissions-boundary $(aws iam list-policies --query 
“Policies[?PolicyName==’dev-boundary-permissions-policy’].Arn” --output text) --user-name dev-user

En procédant ainsi on a une meilleure gestion des autorisations et une réduction des risques de sécurité en s’assurant que les développeurs ne pourront pas créer des utilisateurs IAM même s’ils ont une policy du style iam:*. car la boundary ne l'autorise pas.

Voici un schéma qui sera plus visuel, récapitulant ce que l’on a mis en place :

Ce processus peut tout à fait être automatisé via IaC avec des outils tels que Terraform. Voici un exemple d’application en reprenant l’exemple précédent : 

# Définition du document JSON de la Boundary
data "aws_iam_policy_document" "dev_boundary_permissions" {
  statement {
    effect = "Allow"
    actions = [
      "s3:*",
      "cloudwatch:*",
      "ec2:*",
    ]
    resources = ["*"]
  }
}

# Création de la policy IAM basée sur le document JSON
resource "aws_iam_policy" "dev_boundary_permissions_policy" {
  name   = "dev-boundary-permissions-policy"
  policy = data.aws_iam_policy_document.dev_boundary_permissions.json
}

# Attribution de la boundary à l'utilisateur
resource "aws_iam_user" "dev_user_with_boundary" {
  name = aws_iam_user.dev_user.name
  permissions_boundary = aws_iam_policy.dev_boundary_permissions_policy.arn
}

Trop est l’ennemi du bien

Les IAM Permissions Boundaries sont très utiles pour renforcer la sécurité et la gestion des accès dans AWS. Cependant, ça peut vite devenir un casse-tête à gérer, il est donc essentiel de les utiliser avec discernement. 

Pour ne pas se retrouver dans une situation ingérable, il est important de suivre quelques bonnes pratiques :

• Évitez de créer des Boundaries trop larges qui pourraient limiter les actions autorisées au point “d'empêcher” vos utilisateurs de travailler efficacement. Identifiez et définissez les besoins de chaque groupe d'utilisateurs ou de rôles,
• Avant de déployer des Boundaries dans un environnement de production, assurez-vous de les tester dans un environnement de test pour vérifier qu'elles fonctionnent correctement et qu'elles n'ont pas d'effets indésirables sur d’autres ressources ou sur vos utilisateurs,
• Assurez-vous que vos utilisateurs comprennent les Permissions Boundaries qui leur sont appliquées et les raisons derrière ces restrictions. Cette pratique vise à réduire les erreurs et les frustrations liées aux limitations d'accès.

Conclusion

Les IAM Permissions boundaries sont utiles pour renforcer la sécurité et la gestion des accès dans AWS. Elles permettent de définir des limites sur les autorisations accordées aux différentes entités IAM et de réduire les risques liés à une mauvaise configuration. Cependant, même si on ajoute des permissions boundaries à un user, celles-ci ne seront pas prises en compte si ce user est autorisé dans une resource-based policy.

Il est important de noter que les Boundaries ne sont qu'un élément s’inscrivant dans une stratégie de sécurité AWS. Elles doivent être utilisées en combinaison avec d'autres fonctionnalités. Nous pouvons citer les règles IAM traditionnelles, le chiffrement des données, les Service Control Policies (SCP) ou encore la surveillance des accès pour garantir une protection des ressources cloud.