AWS IAM : Entre rêve et cauchemar

J’utilise professionnellement AWS depuis plus de 4 ans maintenant.

Pour faire un peu mon vieux, lorsque j’ai commencé sur AWS, les services et fonctionnalités suivantes n’existaient pas :

• Les ALB/NLB
• ACM
• ElasticSearch Service
• Les lambda dans les VPC ou avec durée supérieure à 5 minutes
• ECS/EKS/ECR

Durant ces 4 années, j’ai eu l’occasion de faire beaucoup d’IAM, indispensable pour déployer des solutions sécurisées sur Amazon.

IAM et least privilege

Le service IAM (Identity and Access Management) est le service d’AWS qui définit les utilisateurs ou rôles ainsi que les permissions qui leur sont associées.

En suivant les préceptes du well architected framework d’AWS, la bonne pratique est donc d’attribuer les droits les plus fins possibles pour que notre application fonctionne.

Pourquoi ça ? Plusieurs raisons ici :

• Si mon application venait à être compromise, je limite au maximum l’impact, car l’attaquant n’aura qu’un accès restreint à mon infrastructure.
• Cela peut me permettre de détecter un comportement anormal de celle-ci, si je vois beaucoup d’access denied pour le rôle de mon EC2 sur des API qu’il n’est pas censé exploiter
• C’est une bonne pratique d’hygiène générale dans un SI de limiter au maximum le périmètre accessible par une application

L’outillage mis à disposition

Afin de positionner des droits fins, AWS permet la création de policies pour indiquer le périmètre d'un utilisateur ou un rôle.

Cet outillage décrit, au format JSON, les droits à appliquer. Ce qui donne de manière très basique quelque chose de ce type :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "mapolicyS3",
      "Action": [
        "s3:CreateBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::demo-bucket-tferdinandnet"
    }
  ]
}

Comme vous pouvez le voir, les policies sont lisibles humainement et permette de faire un filtrage plus ou moins efficace sur l’ensemble des appels API et des ressources AWS.

Pour aider à la création de ces policies, AWS met à disposition plusieurs outils, notamment :

• le policy generator : https://awspolicygen.s3.amazonaws.com/policygen.html
• le policy simulator : https://policysim.aws.amazon.com/ (accessible uniquement une fois connecté à un compte AWS)

De plus, il existe une documentation des API, avec leur filtrage et schéma de nommage des ressources sur le site officiel : https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html

Donc tout est parfait ?

NON ! Il existe effectivement un certain nombre d’outils et de documentations sur AWS, qui répondront à une bonne partie des cas d’usage, tant que l’on n’essaie pas de faire vraiment du least privilège…

Pourquoi ça ?

Limites

Tout d’abord, je vais parler des limites sur AWS. Il faut savoir qu’il en existe deux types :

• Les soft limits : ces limites sont surtout là pour protéger le client d’une mauvaise utilisation d’AWS qui ferait flamber sa facture, et peuvent être modifiées à l’aide de ticket au support
• Les hard limits : Ces limites s’appliquent de manière identique à l’ensemble des comptes AWS, et ne peuvent en aucun cas être modifiées

Il faut savoir que les limites concernant l’IAM d’Amazon sont assez rapidement atteignables dès qu’on essaie de restreindre fortement les droits des ressources, car les policies deviennent vite très verbeuses.

À titre d’exemple, on peut mettre maximum 10 managed policies sur un rôle ou utilisateur, avec une limite de 6144 caractères pour chacune (sans comptabiliser les espaces), pour donner un exemple du least privilège sur un service "costaud" comme RDS peut dépasser allégrement les 10.000 caractères…

Pour plus d’information sur les limites, je vous invite à consulter la page associée : https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html

Hétérogénéité

Si les limites étaient le seul problème… On peut aussi parler de l’hétérogénéité des filtrages de ressource, certains se basent sur l’ARN, certains sur le nom de la ressource, certains sur un ID généré au moment de la création de cette dernière… Concernant ce cas, il est quasiment impossible de gérer des privilèges restreints, car pour restreindre le droit de création / modification de la ressource, il faut qu’elle existe déjà !

De même, les conditions disponibles ne sont pas toujours les mêmes, voire n’ont pas les mêmes noms. Un simple filtrage sur un tag (assez basique sur AWS) peut ne pas être possible en fonction des ressources, ou de l’appel API effectué.

Le support est aux fraises…

De par les soucis que j’ai remontés plus haut, j’ai eu à contacter le support à plusieurs reprises pour des anomalies que je n’arrivais pas à expliquer.

Outre le fait que j’ai eu le droit très fréquemment à "Ouais, mes vos policies sont compliquées", dans la plupart des cas, le support est au mieux inutile. Au pire, il répond à côté de mon besoin, ne comprenant pas que mon travail consiste à sécuriser les déploiements et infrastructures dans AWS…

Le support est le champion du wildcard (*), outil magique qu’on brandit quand on ne trouve pas. La solution du support est très souvent de passer le call API en ressource wildcard ou l’API elle-même.

Le souci est que dès lors, on ne fait plus de least privilege, on restreint certes, mais très loin du minimum…

Je pourrais aussi parler des tickets que j’ai ouverts dernièrement. C'était une fois de plus des bugs connus de l’IAM AWS ne pouvant être contournés qu’à coup de wildcard, sans qu’on nous fournisse une quelconque date de résolution…

En conclusion

On pourrait croire avec mes derniers paragraphes que je trouve l’IAM d’AWS complètement à côté de la plaque, pourtant ce n’est pas le cas.

Je suis conscient que le filtrage des ressources est quelque chose de complexe à appréhender et mettre en place, et Amazon est loin d’être un mauvais élève sur ce point.

Toutefois, je pense qu’Amazon gagnerait en indiquant de vrais exemples concrets de least privilege dans leur documentation au lieu d'insérer du wildcard partout. Cela crée de surcroît des tensions quand des gens comme moi veulent restreindre les droits vu que beaucoup d’utilisateurs ne comprennent pas pourquoi l’on s’éloigne des documentations AWS.

De plus, les limites sur l’IAM sont aberrantes et inutiles, elles poussent juste à donner des droits plus larges pour économiser les précieux caractères et complexifient leur automatisation.

La sécurité est un enjeu majeur pour les entreprises, espérons qu’AWS les entendent !