Présentation de la gestion des accès : autorisations et politiques

La partie de gestion de l'accès d'AWS Identity and Access Management (IAM) vous aide à définir ce qu'une entité principal est autorisée à faire dans un compte. Une entité principal est une personne ou une application qui est authentifiée à l'aide d'une entité IAM (utilisateur ou rôle). La gestion des accès est souvent appelée autorisation. Vous gérez les accès dans AWS en créant des politiques et en les attachant à des identités IAM (utilisateurs, groupes d'utilisateurs ou rôles) ou des ressources AWS. Une politique est un objet dans AWS qui, lorsqu'il est associé à une identité ou à une ressource, définit les autorisations de ces dernières. AWS évalue ces politiques lorsqu'un principal utilise une entité IAM (utilisateur ou rôle) pour envoyer une demande. Les autorisations dans les politiques déterminent si la demande est autorisée ou refusée. La plupart des politiques sont stockées dans AWS en tant que documents JSON. Pour plus d'informations sur les types de politiques et les utilisations, veuillez consulter Politiques et autorisations dans IAM.

Politiques et comptes

Si vous gérez un seul compte dans AWS, vous y définissez les autorisations à l'aide de politiques. Si vous gérez des autorisations sur plusieurs comptes, la gestion des autorisations pour vos utilisateurs est plus compliquée. Vous pouvez utiliser des rôles IAM, des politiques basées sur les ressources ou des listes de contrôle d'accès (ACL) pour des autorisations entre comptes. Toutefois, si vous possédez plusieurs comptes, nous vous recommandons d'utiliser le service AWS Organizations pour vous aider à gérer ces autorisations. Pour plus d'informations, reportez-vous à la section Présentation d'AWS Organizations du Guide de l'utilisateur Organizations.

Politiques et utilisateurs

Les utilisateurs IAM sont des identités dans le service. Lorsque vous créez un utilisateur IAM, il ne peut accéder à rien dans votre compte tant que vous ne lui en donnez pas l'autorisation. Vous accordez des autorisations à un utilisateur en créant une politique basée sur l'identité, qui est attachée à l'utilisateur ou à un groupe auquel l'utilisateur appartient. L'exemple suivant illustre une politique JSON qui autorise l'utilisateur à exécuter toutes les actions Amazon DynamoDB (dynamodb:*) sur le tableau Books dans le compte 123456789012 de la région us-east-2.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "dynamodb:*",
    "Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books"
  }
}

Une fois cette politique attachée à votre utilisateur IAM, seul ce dernier dispose des autorisations DynamoDB. La plupart des utilisateurs disposent de plusieurs politiques qui une fois réunies constituent leurs autorisations.

Les actions ou ressources qui ne sont pas autorisées explicitement sont refusées par défaut. Par exemple, si la politique précédente est la seule attachée à un utilisateur, ce dernier est autorisé à exécuter des actions DynamoDB uniquement sur le tableau Books. Les actions sur toutes les autres tables sont interdites. De même, l'utilisateur n'est pas autorisé à exécuter des actions dans Amazon EC2, Amazon S3 ou dans n'importe quel autre service AWS. Cela s'explique car les autorisations permettant d'utiliser ces services ne sont pas incluses dans la politique.

Politiques et groupes

Vous pouvez organiser les utilisateurs IAM en groupes IAM et attacher une politique à un groupe. Dans ce cas, les utilisateurs disposent toujours de leurs propres informations d'identification, mais tous les utilisateurs d'un groupe détiennent les autorisations qui sont attachées à ce groupe. Utilisez des groupes pour faciliter la gestion des autorisations et de suivre nos Bonnes pratiques de sécurité dans IAM.

Plusieurs politiques accordant différentes autorisations peuvent être attachées à des utilisateurs ou des groupes. Dans ce cas, les autorisations des utilisateurs sont calculées sur la combinaison des politiques. Mais le principe de base s'applique toujours : si l'utilisateur n'a pas reçu une autorisation explicite pour une action et une ressource, il ne dispose pas de cette autorisation.

Utilisateurs fédérés et rôles

Les utilisateurs fédérés n'ont pas d'identités permanentes dans votre Compte AWS de la même manière que les utilisateurs IAM. Pour attribuer des autorisations à des utilisateurs fédérés, vous pouvez créer une entité appelée rôle et définir des autorisations pour le rôle. Quand un utilisateur fédéré se connecte à AWS, l'utilisateur est associé au rôle et reçoit les autorisations qui sont définies dans le rôle. Pour de plus amples informations, veuillez consulter Création d'un rôle pour un fournisseur d'identité tiers (fédération).

Politiques basées sur les ressources et politiques basées sur l'identité

Les politiques basées sur l'identité sont des politiques d'autorisations que vous pouvez attacher à une identité IAM, tel qu'un utilisateur, un groupe ou un rôle IAM. Les politiques basées sur les ressources sont des politiques d'autorisations que vous attachez à une ressource, telle qu'un compartiment Amazon S3 ou une politique d'approbation de rôle IAM.

Les politiques basées sur l'identité contrôlent les actions que peut effectuer l'identité, sur quelles ressources et dans quelles conditions. Les politiques basées l'identité peuvent être classées comme suit :

• Politiques gérées : politiques autonomes basées sur une identité que vous pouvez attacher à plusieurs utilisateurs, groupes et rôles dans votre Compte AWS. Vous pouvez utiliser deux types de politiques gérées :

  • Politiques gérées par AWS : politiques gérées qui sont créées et gérées par AWS. Si vous n'êtes pas encore familiarisé avec les politiques, nous vous recommandons de commencer par utiliser des politiques gérées par AWS.

  • Politiques gérées par le client : politiques gérées que vous créez et gérez dans votre Compte AWS. Les politiques gérées par le client offrent davantage de précision sur vos politiques que les politiques gérées par AWS. Vous pouvez créer, modifier et valider une politique IAM dans l'éditeur visuel ou en créant le document de politique JSON directement. Pour plus d'informations, consultez Création de politiques IAM et Modification de politiques IAM.

• Politiques en ligne : politiques que vous créez et gérez, et qui sont intégrées directement à un utilisateur, groupe ou rôle. Dans la plupart des cas, nous vous déconseillons d'utiliser des politiques en ligne.

Les politiques basées sur les ressources contrôlent les actions qu'un principal spécifique peut effectuer sur cette ressource et dans quelles conditions. Les politiques basées sur les ressources sont des politiques en ligne et il n'y a pas de politiques basées sur des ressources gérées. Pour permettre un accès comptes multiples , vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que principal dans une politique basée sur les ressources.

Le service IAM prend en charge un seul type de politique basée sur les ressources, nommé politique d'approbation de rôle, qui est attaché à un rôle IAM. Étant donné qu'un rôle IAM est à la fois une identité et une ressource qui prend en charge les politiques basées sur les ressources, vous devez associer une politique d'approbation et une politique basée sur une identité à un rôle IAM. Les politiques d'approbation définissent quelles entités principaux (comptes, utilisateurs, rôles et utilisateurs fédérés) peuvent endosser le rôle. Pour en savoir plus sur la façon dont les rôles IAM sont différents d'autres politiques basées sur les ressources, veuillez consulter Différence entre les rôles IAM et les politiques basées sur les ressources.

Pour connaître les services qui prennent en charge les politiques basées sur les ressources, voir Services AWS qui fonctionnent avec IAM. Pour en savoir plus sur politiques basées sur les ressources, voir Politiques basées sur l'identité et Politiques basées sur une ressource.