Politiques gérées et politiques en ligne - AWS Identity and Access Management

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Politiques gérées et politiques en ligne

Lorsque vous définissez les autorisations pour une identité dansIAM, vous devez décider d'utiliser une politique AWS gérée, une politique gérée par le client ou une politique intégrée. 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.

AWS politiques gérées

Une politique gérée par AWS est une politique autonome qui est créée et gérée par AWS. Une politique autonome signifie qu'elle possède son propre nom de ressource Amazon (ARN) qui inclut le nom de la politique. Par exemple, il arn:aws:iam::aws:policy/IAMReadOnlyAccess s'agit d'une politique AWS gérée. Pour plus d'informations surARNs, voirIAM ARNs. Pour obtenir la liste des politiques AWS gérées pour Services AWS, consultez la section stratégies AWS gérées.

AWS les politiques gérées vous permettent d'attribuer facilement les autorisations appropriées aux utilisateurs, aux IAM groupes et aux 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 AWS gérées. AWS met à jour de temps en temps les autorisations définies dans une politique AWS gérée. Dans ce cas AWS , la mise à jour affecte toutes les entités principales (, IAM groupes et IAM rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'un nouveau AWS service est lancé ou que de nouveaux API appels sont disponibles pour des services existants. Par exemple, la politique AWS gérée appelée ReadOnlyAccessfournit un accès en lecture seule à toutes Services AWS les ressources. Lors du AWS lancement d'un nouveau service, AWS met à jour la ReadOnlyAccesspolitique pour ajouter des autorisations en lecture seule pour le nouveau service. Les autorisations mises à jour s'appliquent à toutes les entités du principal auxquelles la politique est attachée.

Politiques de AWS gestion de l'accès complet : elles définissent les autorisations pour les administrateurs de services en accordant un accès complet à un service. En voici quelques exemples :

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

Politiques de AWS gestion de l'accès partiel : elles fournissent des niveaux d'accès spécifiques Services AWS sans autoriser les autorisations de niveau d'accès liées à la gestion des autorisations. En voici quelques exemples :

Politiques de AWS gestion des fonctions : 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. L'un des principaux avantages de l'utilisation des politiques relatives aux fonctions professionnelles est qu'elles sont maintenues et mises à jour au AWS fur et à mesure que de nouveaux services et API opérations sont introduits. Par exemple, la fonction AdministratorAccessjob fournit un accès complet et une délégation d'autorisations à chaque service et ressource qu'il contient AWS. Nous vous recommandons de n'utiliser cette politique que pour l'administrateur de compte. Pour les utilisateurs expérimentés qui ont besoin d'un accès complet à tous les services, à l'exception de l'accès limité à IAM et aux Organisations, utilisez la fonction PowerUserAccessjob. Pour obtenir la liste et la description des politiques de fonctions professionnelles, consultez la page AWS politiques gérées pour les fonctions professionnelles.

Le schéma suivant illustre les politiques AWS gérées. Le diagramme montre trois politiques AWS gérées : AdministratorAccessPowerUserAccess, et AWS CloudTrailReadOnlyAccess. Notez qu'une seule politique AWS gérée peut être attachée à des entités principales dans différentes entités principales Comptes AWS, et à différentes entités principales dans une seule Compte AWS.

Schéma des politiques AWS gérées

Politiques gérées par le client

Vous pouvez créer vos propres politiques autonomes Compte AWS que vous pouvez associer aux entités principales (IAMgroupes et IAM rôles). 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. À l'instar des politiques AWS gérées, lorsque vous attachez une stratégie à une entité principale, vous accordez à l'entité les autorisations définies dans la stratégie. 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é IAM dotée de son propre nom de ressource Amazon (ARN) qui inclut le nom de la politique. Notez que la même stratégie peut être attachée à plusieurs entités principales. Par exemple, la même stratégie DynamoDB-Books-App est attachée à deux rôles différents. IAM

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

Diagramme de politiques gérées par le client

Politiques en ligne

Une politique intégrée est une stratégie créée pour une seule IAM identité (un utilisateur, un groupe d'utilisateurs ou un rôle). Les politiques intégrées maintiennent une one-to-one relation 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.

Diagramme de politiques en ligne