Techniques d’écriture de stratégies IAM avec principe de moindre privilège

Dans cet article, nous partageons deux techniques que nous avons utilisées pour écrire des stratégies AWS Identity and Access Management (IAM) avec moindre privilège. Si vous n’êtes pas familier avec la structure des stratégies IAM, je vous recommande vivement de lire Comprendre le fonctionnement d’IAM et Stratégies et autorisations dans IAM.

Le principe de moindre privilège consiste à n’accorder que les autorisations strictement nécessaires à l’exécution d’une tâche. Le moindre privilège est également l’une des nombreuses meilleures pratiques d’Amazon Web Services (AWS) Well-Architected qui peuvent vous aider à construire vos projets dans le cloud de façon sécurisée.

Par exemple, si vous avez une instance Amazon Elastic Compute Cloud (Amazon EC2) qui doit accéder à un bucket (ou compartiment, en français) Amazon Simple Storage Service (Amazon S3) pour obtenir des données de configuration, seule l’autorisation d’accès en lecture au bucket S3 spécifique qui contient les données concernées doit être positionnée.

Il existe plusieurs façons d’accorder l’accès à différents types de ressources, car certaines d’entre elles prennent en charge à la fois les stratégies basées sur leur nature, et les identités IAM. Cet article se concentre sur la façon dont vous pouvez utiliser les stratégies IAM pour accorder des autorisations restrictives aux principaux IAM afin de respecter les normes du moindre privilège.

Pour le Cloud AWS, un principal IAM peut être un utilisateur, un rôle ou un groupe. Ces identités démarrent sans autorisation et, au fur et à mesure, vous ajoutez des droits à l’aide d’une stratégie. Dans AWS, différents types de stratégies sont utilisées pour différentes raisons. Au travers de cet article, nous vous présentons des exemples de stratégies basées sur l’identité qui s’attachent aux principaux IAM Vous pouvez créer et attacher plusieurs stratégies basées sur l’identité à vos principaux IAM, et vous pouvez les réutiliser sur vos comptes AWS.

Il existe deux types de stratégies managées : Les stratégies managées par le client et les stratégies en ligne AWS :

• Les stratégies managées par le client sont créées et managées par vous, le client.
• Enfin, les stratégies en ligne managées par AWS sont fournies à titre d’exemple, ne peuvent pas être modifiées, mais peuvent être copiées, améliorées et enregistrées en tant que stratégies managées par le client.

Les principaux éléments qui constituent une stratégie sont :

• Effect : Indique si l’instruction va autoriser ou refuser une action;

• Action : Décrit une ou plusieurs actions spécifiques dont l’exécution sera autorisée ou refusée en fonction de Effect. Les actions d’API sont propres à chaque service. Par exemple, s3:CreateBucket fait référence à un appel API du service Amazon S3 il s’agit également d’une action IAM qui permet à un principal IAM de créer un bucket S3;

• NotAction : Peut être utilisé comme alternative à l’utilisation de Action. Cet élément permettra à un Principal IAM d’appeler toutes les actions d’API vers un service AWS spécifique, à l’exception des actions spécifiées dans cette liste;
• Resource : Spécifie les ressources (par exemple, un bucket S3 ou des objets) auxquelles la stratégie s’applique au format Amazon Resource Name (ARN);
• NotResource: Peut être utilisé à la place de l’élément Resource pour correspondre explicitement à toutes les ressources AWS, sauf celles exprimées;
• Condition : Permet de créer des expressions pour faire correspondre les clés et les valeurs des conditions de la stratégie aux clés et aux valeurs du contexte de requête envoyé par le principal IAM. Les clés de condition peuvent être spécifiques au service ou globales. Une clé de condition globale peut être utilisée avec n’importe quel service. Par exemple, une clé AWS:CurrentTime peut être utilisée pour autoriser l’accès en fonction de la date et de l’heure.

Commencer par l’éditeur de code

L’éditeur de code fourni par AWS est votre point de départ par défaut pour créer des stratégies d’identité IAM, pour observer tous les services, actions et conditions disponibles sans pour autant consulter forcément la documentation.

Si vous avez besoin d’implémenter une stratégie plus complexe avec de nombreux services, considérons celles managées par AWS comme point de départ des actions requises, puis utilisons l’éditeur de code pour affiner et vérifier les ressources et les conditions.

La stratégie dont nous allons parler tout au long de cet article consiste à accorder une fonction AWS Lambda l’autorisation d’obtenir des objets spécifiques Amazon S3 et de placer des éléments dans une table spécifique dans Amazon DynamoDB. Vous pouvez accéder à l’éditeur visuel de code lorsque vous choisissez Créer une politique sous Gestion des accès dans la console IAM, ou ajouter des stratégies lorsque vous affichez un rôle, un groupe ou un utilisateur, comme illustré dans la Figure 1. Si vous n’êtes pas familier avec la création de politiques, vous pouvez suivre les instructions complètes de la documentation IAM.

Figure 1 : Utilisez l’éditeur visuel pour créer une stratégie.

Commencez par choisir le premier service –Amazon S3– auquel accorder l’accès, comme indiqué dans la Figure 2. Vous ne pouvez choisir qu’un seul service à la fois, vous devrez donc ajouter DynamoDB par la suite.

Figure 2 : Sélectionnez le service S3.

Vous verrez alors une liste d’actions autorisées avec la possibilité d’en ajouter manuellement. Développez la liste de niveau d’accès Lire pour afficher toutes les actions de lecture prises en charge par le service Amazon S3. Vous pouvez désormais voir toutes les actions de niveau d’accès en lecture possibles (cf. Figure 3).

Figure 3 : Actions de niveau d’accès en lecture pour le service Amazon S3.

Pour obtenir un objet, cochez la case GetObject. En sélectionnant le « ? » à côté de l’action vous pouvez obtenir des indications supplémentaires, notamment une description, les types de ressources et les clés de condition, comme illustré dans la Figure 4.

Figure 4: Développez « Lire » dans le niveau d’accès, sélectionnez « GetObject », puis sélectionnez le « ? » à côté de « GetObject ».

Cliquez sur Ressources, vous verrez alors que l’éditeur a répertorié l’objet car il s’agit de la seule ressource prise en charge par l’action GetObject, comme illustré dans la Figure 5.

Figure 5 : Développez « Ressources ».

Sélectionnez Ajouter un ARN, afin d’ouvrir une boîte de dialogue qui vous aide à spécifier l’ARN des objets. Entrez un nom de bucket S3 -tel que doc-exemple-compartiment– puis le nom de l’objet. Pour le nom de l’objet, vous pouvez utiliser un caractère générique « * » comme suffixe. Par exemple, pour autoriser les objets commençant par alpha, vous devez entrer alpha* comme illustré dans la Figure 6. Il s’agit d’une étape importante.

Pour cette stratégie du moindre privilège, vous limitez ainsi l’accès à un bucket spécifique et à un préfixe d’objet particulier. Vous pourriez même spécifier un objet individuel en fonction de votre cas d’usage.

Figure 6 : Entrez le nom du bucket et celui de l’objet.

Si vous devez autoriser plusieurs ARN (bucket et objets), vous pouvez répéter l’étape précédente.

Figure 7a : ARN ajouté pour l’objet S3.

La dernière étape consiste à cliquer sur les Conditions de demande en bas de l’écran, puis à choisir Ajouter une condition. La boîte de dialogue Ajouter une condition de demande s’ouvre alors.

Sélectionnez la liste déroulante de la clé de condition pour lister les clés de condition. Vous verrez qu’il existe une condition s3:ExistingObjectTag/${key} qui, comme son nom l’indique, correspond à une balise d’objet existante.

Figure 7b: Sélection de la Clé de condition.

Vous pouvez utiliser cette clé de condition pour autoriser la demande GetObject uniquement lorsque la balise répond à votre condition. Cela signifie que vous pouvez appliquer des balises à vos objets avec une clé/valeur spécifique, et votre condition de stratégie doit correspondre à cette clé/valeur pour permettre l’exécution de l’action.

Lorsque vous utilisez des clés de condition avec plusieurs clés ou valeurs, vous pouvez utiliser des opérateurs de condition et une évaluation logique. Comme le montre la Figure 8, la balise tag-key est entrée directement en dessous de la clé de condition. Il s’agit de la clé de la balise à faire correspondre. Pour faire correspondre au moins une valeur de la demande à la clé de balise, dans le champ Qualificateur, sélectionnez Pour Pour toute valeur de la demande.

Notez que dans cet exemple, vous n’avez qu’une seule valeur dans la demande. Pour correspondre à la balise exactement, dans le champ Opérateur, sélectionnez StringEquals. Pour spécifier la valeur de la clé de la balise, assurez-vous que l’option Si existe n’est pas cochée. Pour Valeur, saisissez la valeur de la balise tag-value comme illustré dans la Figure 8.

Figure 8 : Condition de demande insérée.

C’est tout pour ajouter l’action S3, comme indiqué dans la Figure 9.

Figure 9 : Action S3 GetObject avec les ressources et les conditions configurées.

Vous devez maintenant ajouter les autorisations DynamoDB en sélectionnant Ajouter des autorisations supplémentaires. Sélectionnez Choisir un service, puis DynamoDB. Pour les actions, sélectionnez sous le niveau d’accès Écrire sur PutItem.

Figure 10 : Choisissez le niveau d’accès en écriture.

Dans Ressources, sélectionnez Ajouter un ARN. La boîte de dialogue qui s’affiche vous aidera à créer l’ARN comme elle l’a fait pour le service Amazon S3. Entrez la région, par exemple la région ap-southeast-2 ainsi que l’ID du compte, et le nom de la table. Si vous choisissez Ajouter, l’ARN de la ressource sera alors ajouté à votre stratégie.

Figure 11 : Entrez le nom de la région, du compte et de la table.

Il est maintenant temps d’ajouter des conditions. Sous Conditions de demande, sélectionnez Ajouter une condition.

Il existe de nombreuses conditions DynamoDB que vous pouvez utiliser, mais vous pouvez choisir dynamodb:LeadingKeys pour représenter la première clé, ou des clés de partition dans une table. Vous pouvez voir dans la documentation qu’un qualificatif de Pour toutes les valeurs de la demande est recommandé. Pour l’opérateur, vous pouvez utiliser StringEquals car votre chaîne doit correspondre exactement, puis une valeur peut utiliser un préfixe avec un caractère générique, tel que « alpha*», comme indiqué dans la Figure 12.

Figure 12 : Ajout d’une condition de demande.

En choisissant Ajouter, vous reviendrez sur l’éditeur principal de stratégie dans lequel vous pouvez choisir d’examiner la stratégie pour continuer. Entrez un nom et une description pour la stratégie, puis sélectionner Créer une stratégie. Vous pouvez maintenant attacher un role pour un test et examiner la stratégie ainsi créée (cf. Figure 13).

Figure 13 : Examiner une stratégie

Vous pouvez voir dans cet exemple qu’une stratégie peut disposer du moindre privilège en utilisant des ressources et des conditions spécifiques. Notez que parfois, lorsque vous utilisez la console, des autorisations supplémentaires sont nécessaires pour fournir des informations relatives à l’expérience de la console.

Commencer par les stratégies managées par AWS

Les stratégies managées par AWS peuvent être un bon point de départ pour voir les actions généralement associées à un service ou à une fonction particulière. Par exemple, vous pouvez attacher la stratégie AmazonS3ReadOnlyAccess à un rôle utilisé par une instance Amazon EC2 qui autorise un accès en lecture seule à tous les buckets Amazon S3 de votre compte, comme illustré en Fig 14.

Elle a pour effet d’autoriser l’accès, et deux actions qui utilisent des caractères génériques (*) permettent à leurs tours les actions Récupérer et Lister pour le service S3 – Dans cet exemple s3:GetObject et s3:ListAllMyBuckets -.

La ressource dispose d’un caractère générique pour autoriser tous les buckets S3 auxquels le compte a accès. Une caractéristique utile de cette stratégie est qu’elle autorise uniquement l’accès en lecture et l’énumération des éléments dans S3, mais pas à d’autres services ou types d’actions.

Figure 14 : Récapitulatif de la stratégie.

Créons notre propre stratégie IAM personnalisée afin de réduire au minimum les privilèges fournis. En commençant par l’élément action, vous pouvez utiliser la référence pour Amazon S3 pour voir toutes les actions, une description de ce que fait chaque action, le type de ressource pour chaque action et les clés de condition pour chaque action. Imaginons maintenant que cette stratégie soit utilisée par une instance Amazon EC2 pour récupérer un objet de configuration d’application à partir d’un bucket S3. En regardant les descriptions des actions commençant par Get, vous pouvez constater que la seule action dont nous avons réellement besoin est GetObject. Vous pouvez ensuite utiliser l’élément de ressource pour restreindre une action à un ensemble d’objets préfixés par une configuration dans un bucket spécifique.

"Effect": "Allow",
         "Action": "s3:GetObject",
         "Resource": "arn:aws:s3::: <doc-exemple-compartiment>/<config*>"

Maintenant que vous avez réduit la portée de ce que cette stratégie peut faire pour les actions de service et les ressources, vous pouvez ajouter un élément de condition qui utilise le contrôle d’accès basé sur les attributs (ABAC) pour définir des conditions basées sur des attributs, dans le cas présent, une balise de ressource.

Dans cet exemple, lorsque vous lisez des objets à partir d’un seul bucket, vous pouvez définir des conditions spécifiques afin de réduire davantage la portée des autorisations accordées à un principal IAM. Il existe une condition s3:ExistingObjectTag que vous pouvez utiliser pour autoriser la demande GetObject uniquement lorsque la balise d’objet répond à votre condition. En d’autres termes, vous pouvez alors mettre des balises sur vos objets avec une clé-valeur spécifique, auquel votre condition de stratégie IAM doit correspondre pour permettre à l’action d’API de s’exécuter correctement. Lorsque vous utilisez des clés de condition avec plusieurs clés ou valeurs, vous pouvez utiliser des opérateurs de condition et une logique d’évaluation. Vous pouvez constater que pour toutes les valeurs de la demande teste au moins un membre de l’ensemble de valeurs de demande et au moins un membre de l’ensemble de valeurs de clé de condition. Vous pouvez également utiliser des clés de condition globales qui s’appliquent à tous les services :

"Effect": "Allow",
         "Action": "s3:GetObject",
         "Resource": "arn:aws:s3:::<doc-exemple-compartiment>/<config*>",
         "Condition": {
                "ForAnyValue:StringEquals": {
                    "s3:ExistingObjectTag/<tag-key>": "<tag-value>"
            }

Dans l’exemple de stratégie précédent, l’élément de condition n’autorise les autorisations s3:GetObject que si l’objet est identifié avec une balise tag-key et une valeur tag-value. Pendant que vous effectuez des tests, vous pouvez identifier les erreurs dans vos stratégies personnalisées en utilisant le simulateur de stratégie IAM ou en consultant les messages d’erreur enregistrés dans les journaux AWS CloudTrail.

Conclusion

Dans cet article, nous avons présenté deux techniques différentes que vous pouvez utiliser pour créer des stratégies de moindre privilège pour IAM. Vous pouvez adapter ces méthodes pour créer des ensembles d’autorisations AWS Single Sign-On et des stratégies de contrôle de service (SCP) AWS Organizations. Commencer par des stratégies managées est une stratégie utile lorsqu’une stratégie gérée fournie par AWS existe déjà pour votre cas d’utilisation, puis pour réduire la portée de ce qu’elle peut faire par le biais des autorisations. Nous avons tendance à utiliser le plus souvent l’éditeur visuel pour modifier les stratégies, car cela évite de rechercher la ressource et les conditions pour chaque action. Nous vous suggérons de commencer par consulter les stratégies que vous utilisez déjà. Commencez par les stratégies qui accordent des autorisations excessives, comme l’exemple de stratégie Administrateur, et associez-les au cas d’utilisation des utilisateurs ou des éléments qui ont besoin d’un accès. Utilisez les dernières informations consultées, les meilleures pratiques IAM, et consultez les meilleures pratiques AWS Well-Architected et l’outil AWS Well-Architected.

Article original rédigé en anglais par Ben Potter, Partner Migration Program Lead chez AWS, et traduit par Sébastien Butreau, Partner Solutions Architect dans l’équipe AWS France, LinkedIn.