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.

Exemples de scénarios d'utilisation des dernières informations consultées

Vous pouvez utiliser les dernières informations consultées pour prendre des décisions concernant les autorisations que vous accordez à vos entités IAM ou AWS Organizations. Pour en savoir plus, consultez Ajustement des autorisations dans AWS à l’aide des dernières informations consultées.

En tant qu'administrateur, il vous appartient d'équilibrer l'accessibilité et le principe du moindre privilège requis pour votre entreprise.

Utilisation des informations pour réduire les autorisations d'un groupe IAM

Vous pouvez utiliser les dernières informations consultés pour réduire les autorisations de groupe IAM et inclure uniquement les services dont vos utilisateurs ont besoin. Cette méthode est une étape importante dans l'attribution du moindre privilège au niveau service.

Par exemple, Paulo Santos est l'administrateur responsable de la définition des autorisations utilisateur AWS pour Example Corp. Cette société vient de commencer à utiliser AWS, et l'équipe de développement logiciel n'a pas encore défini quels services AWS elle utilisera. Paulo souhaite accorder à l'équipe l'autorisation d'accéder uniquement aux services dont elle a besoin, mais comme cela n'est pas encore défini, il leur attribue temporairement les autorisations utilisateur. Ensuite, il utilise les dernières informations consultées pour réduire les autorisations du groupe.

Paulo crée une politique gérée nommée ExampleDevelopment à l'aide du texte JSON suivant. Puis, il l'attache à un groupe appelé Development et ajoute tous les développeurs au groupe.

{

    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessToAllServicesExceptPeopleManagement",
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RequiredIamAndOrgsActions",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}

Paulo décide d'attendre 90 jours avant d'afficher les dernières informations consultées pour le groupe Development à l'aide de la AWS Management Console. Il affiche la liste des services que les membres du groupe ont consultés. Il apprend que les utilisateurs ont accédé à cinq services au cours de la dernière semaine : AWS CloudTrail, Amazon CloudWatch Logs, Amazon EC2, AWS KMS et Amazon S3. Ils ont accédé à quelques autres services lorsqu'ils évaluaient AWS pour la première fois, mais ne l'ont plus fait depuis.

Paulo décide pour réduire les autorisations de la politique de façon à inclure uniquement ces cinq services et les actions IAM et Organizations requises. Il modifie la politique ExampleDevelopment à l'aide du texte JSON suivant.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessToListedServices",
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "kms:*",
                "cloudtrail:*",
                "logs:*",
                "ec2:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RequiredIamAndOrgsActions",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}

Pour réduire davantage les autorisations, Paulo peut consulter les événements du compte dans AWS CloudTrail Event history (Historique des événements). Là, il peut afficher les informations détaillées des événements qu'il peut utiliser pour réduire les autorisations de la politique et inclure uniquement les actions et les ressources dont les développeurs ont besoin. Pour de plus amples informations, veuillez consulter Affichage des événements dans la console CloudTrail dans le Guide de l'utilisateur AWS CloudTrail.

Utilisation des informations pour réduire les autorisations d'un utilisateur IAM

Vous pouvez utiliser les dernières informations consultées pour réduire les autorisations d'un utilisateur IAM individuel.

Par exemple, Martha Rivera est un administrateur informatique qui doit s'assurer que les employés de son entreprise ne disposent pas d'autorisations AWS trop élevées. Dans le cadre d'un contrôle de sécurité régulier, elle passe en revue les autorisations de tous les utilisateurs IAM. L'un des ces utilisateurs est un développeur d'applications nommé Nikhil Jayashankar, qui occupait précédemment le rôle d'ingénieur sécurité. Dans la mesure où ses tâches ont évolué, Nikhil est à la fois membre du groupe app-dev et du groupe security-team. Le groupe app-dev pour son nouveau poste octroie des autorisations à plusieurs services, notamment Amazon EC2, Amazon EBS, Auto Scaling, Amazon S3, Route 53 et Elastic Transcoder. Le groupe security-team de son ancien poste accorde les autorisations à IAM et CloudTrail.

En tant qu’administrateur, Martha se connecte à la console IAM, sélectionnez Utilisateurs, le nom nikhilj, puis l’onglet Dernier accès.

Martha vérifie la colonne Last Accessed (Dernière consultation) et remarque que Nikhil n'a pas consulté récemment IAM, CloudTrail, Route 53, Amazon Elastic Transcoder, et un certain nombre d'autres services AWS. Nikhil a accédé à Amazon S3. Martha choisit S3 dans la liste des services et apprend que Nikhil a effectué quelques actions Amazon S3 List au cours des deux dernières semaines. Au sein de son entreprise, Martha confirme que Nikhil n'a plus de raison professionnelle d'accéder à IAM et à CloudTrail, car il n'est plus membre de l'équipe de sécurité interne.

Martha est maintenant prête à agir sur le service et des dernières information consultées relatives à l'action. Toutefois, à la différence du groupe de l'exemple précédent, un utilisateur IAM comme nikhilj peut être soumis à plusieurs politiques et appartenir à plusieurs groupes. Martha doit procéder avec précaution pour éviter de modifier par inadvertance l'accès de nikhilj ou d'autres membres du groupe. En plus d'apprendre quel accès Nikhil doit avoir, elle doit déterminer comment ces autorisations lui sont accordées.

Martha choisit l'onglet Autorisations, où elle consulte les politiques attachées directement à nikhilj et celles attachées à partir d'un groupe. Elle développe chaque politique et affiche le récapitulatif de la politique pour savoir quelle politique autorise l'accès aux services que Nikhil n'utilise pas :

Martha décide de supprimer la politique gérée IAMFullAccess AWS attachée directement à nikhilj. Elle supprime également l'appartenance de Nikhil au groupe security-team. Ces deux actions suppriment l'accès superflu à IAM et à CloudTrail.

Les autorisations de Nikhil d'accéder à Route 53 et Elastic Transcoder sont octroyées par le groupe app-dev. Bien que Nikhil n'utilise pas ces services, il se peut que d'autres membres le fassent. Martha examine les dernières informations consultées pour le groupe app-dev et apprend que plusieurs membres ont récemment accédé à Route 53 et Amazon S3. Mais aucun membre du groupe n'a accédé à Elastic Transcoder au cours de la dernière année. Supprime du groupe la politique App-Dev-ElasticTranscoder gérée par le client.

Martha passe ensuite en revue les dernières informations consultées pour la politique App-Dev-ElasticTranscoder gérée par le client. Elle apprend que la politique n'est pas attachée à d'autres identités IAM. Elle vérifie au sein de son entreprise que la politique ne sera pas nécessaire à l'avenir, puis elle la supprime.

Utilisation des informations avant de supprimer des ressources IAM

Vous pouvez utiliser les dernières informations consultées avant de supprimer une ressource IAM, afin de vous assurer qu'un certain délai s'est écoulé depuis qu'une personne a utilisé la ressource pour la dernière fois. Cela s'applique aux utilisateurs, groupes, rôles et politiques. Pour de plus amples informations sur ces actions, veuillez consulter les rubriques suivantes :

Utilisation des informations avant de modifier des politiques IAM

Vous pouvez passer en revue les dernières informations consultées d'une identité IAM (utilisateur, groupe ou rôle), ou d'une politique IAM avant de modifier une politique qui affecte la ressource. Ceci est important, car vous ne souhaitez pas supprimer l'accès pour une personne qui l'utilise.

Par exemple, Arnav Desai est un développeur et administrateur AWS chez Example Corp. Lorsque son équipe a commencé à utiliser AWS, elle a octroyé à tous les développeurs un accès « utilisateur de pouvoir » les autorisant à accéder pleinement à tous les services, à l'exception d'IAM et Organizations. À titre de première étape vers l'attribution du moindre privilège, Arnav souhaite utiliser l’interface AWS CLI pour passer en revue les politiques gérées de son compte.

Pour ce faire, Arnav recense d'abord dans son compte les politiques d'autorisation gérées par le client et qui sont attachées à une identité, à l'aide de la commande suivante :

aws iam list-policies --scope Local --only-attached --policy-usage-filter PermissionsPolicy

À partir de la réponse, il enregistre l'ARN de chaque politique. Arnav génère ensuite un rapport sur les dernières informations consultées pour chaque politique à l'aide de la commande suivante.

aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/ExamplePolicy1

Depuis cette réponse, il capture l'ID du rapport généré depuis le champ JobId. Arnav interroge ensuite la commande suivante jusqu'à ce que le champ JobStatus renvoie la valeur COMPLETED ou FAILED. Si la tâche a échoué, il capture l'erreur.

aws iam get-service-last-accessed-details --job-id 98a765b4-3cde-2101-2345-example678f9

Lorsque la tâche a le statut COMPLETED, Arnav analyse le contenu du tableau ServicesLastAccessed au format JSON.

 "ServicesLastAccessed": [
        {
            "TotalAuthenticatedEntities": 1,
            "LastAuthenticated": 2018-11-01T21:24:33.222Z,
            "ServiceNamespace": "dynamodb",
            "LastAuthenticatedEntity": "arn:aws:iam::123456789012:user/IAMExampleUser",
            "ServiceName": "Amazon DynamoDB"
        },

        {
            "TotalAuthenticatedEntities": 0,
            "ServiceNamespace": "ec2",
            "ServiceName": "Amazon EC2"
        },

        {
            "TotalAuthenticatedEntities": 3,
            "LastAuthenticated": 2018-08-25T15:29:51.156Z,
            "ServiceNamespace": "s3",
            "LastAuthenticatedEntity": "arn:aws:iam::123456789012:role/IAMExampleRole",
            "ServiceName": "Amazon S3"
        }
    ]

À partir de ces informations, Arnav apprend que la politique ExamplePolicy1 autorise l'accès à trois services : Amazon DynamoDB, Amazon S3 et Amazon EC2. L'utilisateur IAM nommé IAMExampleUser a récemment tenté d'accéder à DynamoDB le 1er novembre, et une personne a utilisé le rôle IAMExampleRole pour tenter d'accéder à Amazon S3 le 25 août. Il existe également deux autres entités qui ont tenté d'accéder à Amazon S3 au cours de cette année. Cependant, personne n'a tenté d'accéder à Amazon EC2 au cours de l'année écoulée.

Cela signifie qu'Arnav peut supprimer en toute sécurité les actions Amazon EC2 de la politique. Arnav souhaite vérifier le document JSON de la politique. Tout d'abord, il doit déterminer le numéro de version de la politique à l'aide de la commande suivante.

aws iam list-policy-versions --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1

Dans la réponse, Arnav recueille le numéro de version actuelle par défaut depuis le tableau Versions. Il utilise ensuite le numéro de version (v2) pour demander le document de politique JSON à l'aide de la commande suivante.

aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --version-id v2

Arnav stocke le document de politique JSON renvoyé dans le champ Document du tableau PolicyVersion. Dans le document de politique, Arnav recherche les actions dans l'espace de noms ec2. S'il ne reste pas d'actions d'autres espaces de noms dans la politique, il détache ensuite la politique des identités affectées (utilisateurs, groupes et rôles). Il supprime ensuite la politique. Dans ce cas, la politique inclut les services Amazon DynamoDB et Amazon S3. Par conséquent, Arnav supprime les actions Amazon EC2 du document et enregistre ses modifications. Il utilise ensuite la commande suivante pour mettre à jour la politique à l'aide de la nouvelle version du document et pour définir cette version en tant que version de politique par défaut.

aws iam create-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --policy-document file://UpdatedPolicy.json --set-as-default

La politique ExamplePolicy1 est maintenant mise à jour pour supprimer l'accès au service Amazon EC2 superflu.

Autres scénarios IAM

Les informations sur la date à laquelle une ressource IAM (utilisateur, groupe, rôle ou politique) a tenté pour la dernière fois d'accéder à un service peut vous aider lorsque vous exécutez l'une des tâches suivantes :

Utilisation des informations pour affiner les autorisations d'une unité d'organisation

Vous pouvez utiliser les dernières informations consultées pour affiner les autorisations d'une unité organisationnelle (UO) dans AWS Organizations.

Par exemple, John Stiles est un administrateur AWS Organizations. Il doit s'assurer que les employés possédant des Comptes AWS dans l'entreprise n'ont pas d'autorisations excessives. Dans le cadre d'un contrôle de sécurité périodique, il passe en revue les autorisations de son organisation. Son unité organisationnelle Development contient des comptes qui sont souvent utilisés pour tester les nouveaux services AWS. John décide d'examiner périodiquement le rapport concernant les services qui n'ont pas été consultés dans plus de 180 jours. Ensuite, il supprime des autorisations d'accès à ces services pour les membres de l'unité organisationnelle.

John se connecte à la console IAM avec les informations d'identification de son compte de gestion. Dans la console IAM, il localise les données Organizations de l'unité organisationnelle Development. Il passe en revue le tableau nommé Rapport d'accès aux services et détecte deux services AWS qui n'ont pas été consultés depuis plus de 180 jours au cours de sa période de référence. Il se souvient qu'il a ajouté des autorisations d'accès à Amazon Lex et AWS Database Migration Service pour les équipes de développement. John contacte les équipes de développement et vérifie qu'elles n'ont plus besoin de tester ces services.

John est maintenant prêt à agir sur les dernières informations consultées. Il choisit Edit in (Faire des modifications dans) AWS Organizations et le système lui rappelle que la stratégie de contrôle de service est attachée à plusieurs entités. Il choisit Continue (Continuer). Dans AWS Organizations, il passe en revue les cibles pour savoir quelles sont les entités Organizations auxquelles la stratégie de contrôle de service est attachée. Toutes les entités se trouvent dans l'unité organisationnelle Development.

John décide de révoquer l'accès aux actions Amazon Lex et AWS Database Migration Service dans la SCP NewServiceTest. Cette action supprime l'accès inutile aux services.