Politiques gérées et politiques en ligne

Lorsque vous définissez les autorisations pour une identité dans IAM, vous devez décider si vous souhaitez utiliser une politique gérée par AWS, une politique gérée par le client ou une politique en ligne. Les rubriques suivantes contiennent d'autres informations sur chaque type de politique basée sur l'identité et sur la façon de les utiliser.

Politiques gérées par AWS

Une politique gérée par AWS est une politique autonome qui est créée et gérée par AWS. Une politique autonome correspond à une politique qui possède son propre Amazon Resource Name (ARN) comprenant le nom de la politique. Par exemple, arn:aws:iam::aws:policy/IAMReadOnlyAccess est une politique gérée par AWS. Pour plus d'informations sur les ARN, consultez ARN IAM. Pour obtenir une liste des politiques gérées par AWS pour Services AWS, consultez Politiques gérées par AWS.

Les politiques gérées par AWS vous permettent d’affecter des autorisations appropriées aux utilisateurs, groupes IAM et rôles. Plus rapide que d'écrire vous-même les politiques, cela inclut des autorisations pour de nombreux cas d'utilisation courants.

Vous ne pouvez pas modifier les autorisations définies dans les politiques gérées par AWS. AWS met parfois à jour les autorisations définies dans une politique gérée par AWS. Lorsque AWS effectue ce type de modification, la mise à jour affecte toutes les entités de principal (utilisateurs IAM, groupes IAM et rôles IAM) auxquelles la politique est attachée. Il est plus probable qu’AWS mette à jour une politique gérée par AWS lorsqu’un nouveau service AWS est lancé ou que de nouveaux appels d’API sont disponibles pour les services existants. Par exemple, la politique gérée par AWS appelée ReadOnlyAccess fournit un accès en lecture seule à l’ensemble des ressources et Services AWS. Lorsqu'AWS lance un nouveau service, AWS met à jour la politique ReadOnlyAccess afin d'ajouter des autorisations d'accès en lecture seule à ce nouveau service. Les autorisations mises à jour s'appliquent à toutes les entités du principal auxquelles la politique est attachée.

Politiques d’accès intégral à AWS : celles-ci définissent les autorisations pour les administrateurs de services en accordant un accès complet à un service. En voici quelques exemples :

Politiques gérées par AWS pour les utilisateurs expérimentés : celles-ci offrent un accès complet à Services AWS et aux ressources, mais ne permettent pas de gérer les utilisateurs et les groupes IAM. En voici quelques exemples :

Politiques d’accès partiel gérées par AWS : celle-ci fournissent des niveaux d’accès spécifiques aux Services AWS sans permettre les autorisations de niveau d’accès de gestion des autorisations. En voici quelques exemples :

Politiques gérées par AWS pour les fonctions professionnelles : ces politiques s’alignent étroitement sur les fonctions professionnelles couramment utilisées dans le secteur informatique et facilitent l’octroi d’autorisations pour ces fonctions professionnelles. L'un des avantages clés de l'utilisation des politiques de fonctions professionnelles vient du fait qu'elles sont gérées et mises à jour par AWS au fur et à mesure que de nouveaux services et de nouvelles opérations API sont ajoutés. Par exemple, la fonction professionnelle AdministratorAccess fournit un accès complet et une délégation d'autorisations pour chaque service et ressource dans AWS. Nous vous recommandons de n'utiliser cette politique que pour l'administrateur de compte. Pour les utilisateurs avancés qui ont besoin d'un accès complet à tous les services, mais d'un accès limité à IAM et Organizations, utilisez la fonction de tâche PowerUserAccess. Pour obtenir la liste et la description des politiques de fonctions professionnelles, consultez la page Politiques gérées par AWS pour les fonctions de tâches.

Le diagramme suivant illustre des politiques gérées par AWS. Il présente trois politiques gérées par AWS, à savoir AdministratorAccess, PowerUserAccess et AWSCloudTrail_ReadOnlyAccess. Notez qu'une politique gérée par AWS peut être attachée à des entités du principal de différents Comptes AWS, ainsi qu'à différentes entités du principal d'un même Compte AWS.

Politiques gérées par le client

Vous pouvez créer des politiques autonomes dans votre propre Compte AWS que vous pouvez lier à des entités de principal (utilisateurs IAM, groupes IAM et rôles IAM). Vous créez ces politiques gérées par le client pour vos cas d'utilisation spécifiques, et vous pouvez les modifier et les mettre à jour aussi souvent que vous le souhaitez. Comme les politiques gérées AWS, lorsque vous attachez une politique à une entité de principal, vous accordez à cette dernière les autorisations définies dans la politique. Lorsque vous mettez à jour les autorisations dans la politique, les changements sont appliqués à toutes les entités du principal auxquelles la politique est attachée.

Pour créer une politique gérée par le client, une bonne méthode consiste à commencer par copier une politique gérée par AWS. De cette façon, vous êtes sûr que la politique est correcte au départ ; il vous suffit ensuite de la personnaliser en fonction de votre environnement.

Le diagramme suivant illustre des politiques gérées par le client. Chaque politique est une entité dans IAM avec son propre Amazon Resource Name (ARN) dans lequel figure le nom de la politique. Notez qu'une même politique peut être attachée à plusieurs entités du principal. Par exemple, la politique DynamoDB-books-app est attachée à deux rôles IAM différents.

Pour plus d’informations, consultez Définition d’autorisations IAM personnalisées avec des politiques gérées par le client.

Politiques en ligne

Une politique en ligne est une politique créée pour une identité IAM (utilisateur, groupe d’utilisateurs ou rôle). Les politiques en ligne maintiennent une relation un-à-un stricte entre une politique et une identité. Elles sont supprimées lorsque vous supprimez l'identité. Vous pouvez créer une politique et l'intégrer dans une identité, soit lors de la création de l'identité, soit ultérieurement. Si une politique peut s'appliquer à plusieurs entités, il est préférable d'utiliser une politique gérée.

Le diagramme suivant illustre des politiques en ligne. Chaque politique fait partie intégrante de l'utilisateur, du groupe ou du rôle. Notez que deux rôles incluent la même politique (politique DynamoDB-books-app), sans toutefois partager une même politique. Chaque rôle possède sa propre copie de la politique.