AWS Identity and Access Management
用户指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

查看用户活动以缩小策略范围

IAM 控制台提供了有关 IAM 用户和角色上次尝试访问 AWS 服务的时间的信息。此信息称为上次访问的服务相关数据。此数据可帮助您确定不必要的权限,以便您优化 IAM 策略以更好地遵循“最小特权”原则。也就是说应仅授予执行一项特定任务所需要的最低权限。

注意

近期活动通常指 4 小时内的活动。过去 365 天的访问顾问报告活动。

您可以获取 IAM 实体 (用户、组或角色) 上次通过 IAM 策略权限访问 AWS 服务的日期和时间。您可以使用此信息来识别您的 IAM 策略中未使用和最近未使用的权限。然后,您可以选择删除未使用的服务的权限,或将具有类似的使用模式的用户重新组织到一个组中,以帮助增强账户安全性。了解 IAM 实体上次使用权限的方式和时间可帮助您删除不必要的权限并轻松加强 IAM 策略。

重要

上次访问的服务相关数据包含访问 AWS API 的所有 尝试,而不仅仅是成功的尝试。这包括使用 AWS 管理控制台、AWS API (通过任何 SDK) 或任何命令行工具进行的所有访问尝试。在上次访问的服务相关数据中看到意外的条目并不意味着您的账户信息泄露,因为请求可能已被拒。请参阅您的 CloudTrail 日志并将其作为有关所有 API 调用以及它们是成功还是被拒绝的访问的信息的权威来源。有关更多信息,请参阅 使用 AWS CloudTrail 记录 IAM 事件

本主题介绍 IAM 服务上次访问数据的功能及其在 IAM 控制台中的用法。另外还介绍两种实用的场景,说明如何使用上次访问的服务相关数据从 IAM 策略中移除不必要的权限。

查看访问顾问信息

通过检查任意 IAM 用户、组、角色或托管策略的详细视图,可在 IAM 控制台的 Access Advisor 选项卡上找到数据。

查看访问顾问信息所需的最小权限

用户必须拥有查看用户、组、角色和策略详细信息的权限才能在 IAM 控制台中查看这些实体。但是,要查看服务上次访问的数据,您还必须有权使用以下操作:

  • iam:GenerateServiceLastAccessedDetails

  • iam:GetServiceLastAccessedDetails

  • iam:GetServiceLastAccessedDetailsWithEntities

  • iam:ListPoliciesGrantingServiceAccess

因为这些操作不特定于单一资源,管理员应提供在所有资源 ("Resource": "*") 上使用这些操作的访问权限。

请注意,授予这些权限允许用户查看哪些用户、组或角色附加到了托管策略。还允许用户查看用户或角色有权访问哪些服务,以及哪些用户在哪些时间访问了哪些服务。这类似于 iam:ListEntitiesForPolicyiam:ListAttached[User/Group/Role]Policies 权限。

查看访问顾问信息

  1. 登录 AWS 管理控制台 并通过以下网址打开 IAM 控制台 https://console.amazonaws.cn/iam/

  2. 在导航窗格中,选择 GroupsUsersRolesPolicies

  3. 选择任意用户、组、角色或策略名称以打开其详细视图,然后选择 Access Advisor 选项卡。该选项卡将显示带有以下列的表格:

    服务名称

    具有 IAM 策略授予的权限的服务的列表(如果您检查的是策略),或具有所有 IAM 策略向 IAM 实体授予的权限的服务的列表(如果您检查的是用户、组或角色)。

    如果某个 IAM 策略向您授予了对该实体的任意 权限,则将显示该服务的行,无论该权限仅适用于服务中的一个操作还是所有操作。

    授予权限的策略

    一个策略的名称以及向此实体授予访问指定服务的权限的其他策略的计数。选择包含策略名称和计数的链接以查看向此实体授予访问指定服务的权限所有 IAM 策略的列表。该列表还包含名称、策略的类型(AWS 托管、客户托管或内联)以及用户用来获取策略的组(如果适用)。

    如果您在 Policies Granting Permissions 对话框中选择了托管策略的名称,IAM 将打开显示策略文本的新浏览器标签。如果您在该对话框中单击了一个组名称,IAM 将打开显示组的详细信息的新浏览器标签。

    上次访问时间

    自此用户、角色或组成员上次访问指定服务以来的时间长度。如果服务已更新,但是是在 365 天前或更长时间之前,则该值为 365

    按成员访问

    (仅限组)一个用户的名称以及作为组成员和已访问此服务的其他用户的计数。选择该链接可查看作为组成员的所有 IAM 用户的列表以及每个成员上次访问指定服务的时间。

    如果您在对话框中选择了某个用户的名称,IAM 将打开显示该用户的详细信息的新浏览器标签。

    按实体访问

    (仅限策略)用户或角色的名称以及已使用此策略来访问指定服务的其他用户和角色的计数。选择该链接可查看此策略附加到的所有用户和角色的列表以及这些用户和角色上次访问指定服务的时间。

    其他选项

    • 使用 Access Advisor 上的 Filter 菜单将列表限制为 Services accessedServices not accessed。例如,您可以为策略选择 Services not accessed 来发现该策略中列出的哪些服务从未使用过。在这种情况下,您可能想要从策略中删除这些服务。您还可以在搜索框中键入名称 (或名称的一部分) 以将列表限制为其名称与您键入的名称匹配的实体。

    • 选择列标题之一以根据列信息对信息进行排序。再次选择标题可按相反的顺序进行排序。

备注

  • 表中的服务列表反映了您的 IAM 策略的当前 状态,而不是任何历史状态。例如,如果您的策略的当前版本仅允许 Amazon S3 访问权限,而它先前允许了对其他 AWS 服务的访问权限,则服务上次访问数据将仅显示 Amazon S3 的表条目。如果您尝试确定您的账户中访问控制更改的历史记录,或希望审核历史访问权限,建议您使用 AWS CloudTrail

  • 通常,最近的 Last Accessed 活动将在 4 小时内显示在表中。不过,在某些情况下,可能需要最多 12 小时。如果服务运行得异常缓慢,IAM 控制台中将显示一条通知。

  • 过去 365 天的访问顾问报告活动。如果没有活动,则访问顾问报告在跟踪期间未被访问。如果有活动,但是是在 365 天前或更长时间前,则访问顾问报告上次访问周期为 365

故障排查技巧

如果上次访问的服务表为空,可能是由于下列原因之一导致的:

  • 您直接选择或通过组成员资格选择的用户没有附加策略。

  • 您选择了已附加到没有成员的组的托管策略。

  • 您选择的用户、组或角色既没有附加内联策略,也没有附加托管策略。

  • 您选择的用户仅具有由基于资源的策略授予的权限。

示例使用场景

几个示例说明使用 IAM 访问顾问对于策略 (第一个示例) 和委托人 (第二个示例) 的意义。

缩小 IAM 策略的权限范围

假设某个管理员负责管理一个团队的 AWS 基础设施。该团队创建了一个应用程序,该应用程序在 Amazon EC2 上运行并调用其他 AWS 服务。这意味着管理员需要为该应用程序配置 EC2 实例并管理其配置。在这个过程中,需要将一个 IAM 角色附加到此 EC2 实例。

注意

您可以将 IAM 角色附加到 EC2 实例,以支持在这些实例上运行的应用程序发出 API 请求。这样,您就不需要手动管理这些应用程序使用的安全凭证了。您可以委派权限以向分配给实例的 IAM 角色发出请求,而不必创建和分配 AWS 凭证。有关更多信息,请参阅 Amazon EC2 的 IAM 角色

但是,该管理员是初次使用 IAM,在将 IAM 角色附加到 EC2 实例时,该管理员不确定在该角色的权限策略中添加哪些内容。该管理员希望 实施一个全面的访问控制机制,但当务之急是确保应用程序能够正常运行。为此,该管理员将直接复制下面显示的 PowerUserAccess AWS 托管的策略以对其进行修改,因为随着时间的推移,他会更加清楚实际需要的权限。此策略将授予对除 IAM 之外的账户中所有 AWS 服务和资源的完全读写权限 (建议绝对 要将它用作长期解决方案)。

{ "Statement": [ { "Effect": "Allow", "NotAction": "iam:*", "Resource": "*" } ] }

在应用程序运行一段时间后,管理员可以使用服务上次访问数据来查看实际所使用的权限。然后,管理员就可以减少应用程序的权限。管理员登录 IAM 控制台,然后选择 Policies,查找附加到运行该应用程序的 EC2 实例的关联 IAM 角色的策略。然后,管理员选择该策略名称查看其详细信息,并选择 Access Advisor 选项卡。

该管理员检查了 Last Accessed 列中列出的时间戳,发现该团队的应用程序仅使用 Amazon DynamoDB、Amazon S3、Amazon CloudWatch、Amazon Simple Notification Service (Amazon SNS) 和 Amazon Simple Queue Service (Amazon SQS)。然后,管理员可以选择 Permissions 选项卡,并展开需要限制权限的策略对应的行。管理员为直接附加到该用户的内联策略选择 Edit policy。要编辑托管策略,管理员需选择该策略的名称,以转到 Policies 页面。管理员可以在该页面中修改策略的访问权限,使之仅包含应用程序成功运行所需要的那些权限。

缩小 IAM 用户的权限范围

假设 IT 管理员负责确保组织中的人员不具有多余 AWS 权限。在定期安检中,管理员检查所有 IAM 用户的权限。这些用户中,有一个是应用程序开发人员,以前担任安全工程师。由于工作需要,角色发生变化,新的工作 (可授予包括 Amazon EC2、Amazon EBS、Auto Scaling 等在内的多项服务的权限) 使该开发人员成为“应用程序开发”组的成员,同时因原工作 (可授予 IAM 和 CloudTrail 权限) 也是“安全团队”组的成员。

管理员登录到 IAM 控制台,依次选择 Users、该开发人员的 IAM 用户的名称和 Access Advisor 选项卡。

管理员检查 Last Accessed 列中的时间戳,发现该开发人员最近未访问 IAM、CloudTrail、Route 53、Amazon Elastic Transcoder 以及很多其他 AWS 服务。管理员现在准备操作服务上次访问信息。不过,与前一个示例不同,委托人 (如开发人员的 IAM 用户,可能需要遵循多个策略,属于多个 IAM 组) 的后续步骤要求管理员谨慎处理,以免无意中打断其他用户的访问。因此他的第一步是确定该开发人员如何 获得这些权限。

因为该开发人员不再是内部安全团队的成员,管理员确认其不再有访问 IAM 和 CloudTrail 的业务需要。对于这些权限,在分析组成员资格和策略后,管理员意识到最简单的解决方案是在安全团队 IAM 组中移除该开发人员的成员资格,而不是进行任何策略更改。

由于该开发人员很少使用 Route 53、Elastic Transcoder 等,管理员还可以推断应从应用程序开发组取消其相应权限。但是,在将这些权限移出应用程序开发策略范围(可能会对其他组成员造成负面影响)之前,管理员应该查阅服务最后访问数据,了解应用程序开发组策略。该数据可以揭示这些权限是所有应用程序开发组成员普遍未使用还是只有此特定开发人员没有使用。如果所有组成员都确实未使用这些权限,则管理员可以安全地从应用程序开发组的策略中移除这些权限。如果只有一个开发人员没有使用这些权限,则管理员可考虑为该开发人员专门设置一组不同的权限。另一个选项是对该用户应用权限边界以限制允许该用户使用的权限。或者,管理员可以什么也不做,接受“不是所有用户都要使用授予他们的所有权限”。

如本例所示,您可以从使用委托人的服务上次访问数据入手,从多种后续步骤中选择,包括以下建议做法。不过,对于能正确平衡可访问性和组织适合的最小权限的步骤,选择权在于您,也就是 IAM 管理员。

跟踪数据的区域

AWS 在大多数区域中收集服务上次访问的数据。数据最多存储 365 天。在 AWS 添加其他区域时,这些区域将添加到下表,包括 AWS 开始跟踪每个区域中的数据的日期:

区域名称 区域 跟踪开始日期
美国东部(弗吉尼亚北部) us-east-1 2015 年 10 月 1 日
美国东部(俄亥俄州) us-east-2 2017 年 10 月 27 日
美国西部(加利福尼亚北部) us-west-1 2015 年 10 月 1 日
美国西部(俄勒冈) us-west-2 2015 年 10 月 1 日
亚太区域(东京) ap-northeast-1 2015 年 10 月 1 日
亚太区域(首尔) ap-northeast-2 2016 年 1 月 6 日
亚太区域(新加坡) ap-southeast-1 2015 年 10 月 1 日
亚太区域(悉尼) ap-southeast-2 2015 年 10 月 1 日
亚太地区(孟买) ap-south-1 2016 年 6 月 27 日
加拿大 (中部) ca-central-1 2017 年 10 月 28 日
欧洲(法兰克福) eu-central-1 2015 年 10 月 1 日
欧洲(爱尔兰) eu-west-1 2015 年 10 月 1 日
欧洲 (伦敦) eu-west-2 2017 年 10 月 28 日
欧洲 (巴黎) eu-west-3 2017 年 12 月 18 日
南美洲(圣保罗) sa-east-1 2015 年 12 月 11 日

如果某个区域未在上表中列出,则表明此区域尚不提供上次访问的服务相关数据。