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

排查一般问题

使用此处的信息可帮助您诊断和修复在使用 AWS Identity and Access Management (IAM) 时可能遇到的拒绝访问或其他常见问题。

我丢失了访问密钥

访问密钥由两个部分组成:

  • 访问密钥标识符。标识符是公开的,您可以在列出访问密钥的任意 IAM 控制台中进行查看,例如用户摘要页面。

  • 秘密访问密钥。该密钥会在您最初创建访问密钥对时提供。它与密码一样,之后无法检索。如果您丢失了私有访问密钥,则必须创建新的访问密钥对。如果您已达到访问密钥的数量上限,必须删除一个现有的密钥对,然后才可以创建另一个。

有关更多信息,请参阅重置您丢失或遗忘的密码或访问密钥

我需要访问旧账户

当您首次创建 AWS 账户时,您提供了电子邮件地址和密码。这些是您的 AWS 账户根用户凭证。如果您有旧的 AWS 账户,但由于丢失或遗忘了密码而无法继续访问,您可以恢复密码。有关更多信息,请参阅 重置您丢失或遗忘的密码或访问密钥

如果您不再拥有该电子邮件的访问权限,您应首先尝试恢复对电子邮件的访问。如果不起作用,您可以联系 AWS 客户服务。

您可以使用以下任一选项尝试恢复对您电子邮件的访问:

  • 如果您拥有托管电子邮件地址的域,您可以将电子邮件地址添加回电子邮件服务器。或者,您可以为您的电子邮件账户设置捕获全部。域中的捕获全部设置将捕获全部发送到邮件服务器中不存在的电子邮件地址的消息。它将这些消息重定向到特定的电子邮件地址。例如,如果您的 AWS 账户根用户电子邮件地址为 paulo@sample-domain.com,但您将唯一域电子邮件地址更改为 paulo.santos@sample-domain.com,则可以将新电子邮件设置为捕获全部。这样一来,当 AWS 等其他人发送消息到 paulo@sample-domain.com 或任何其他 text@sample-domain.com 时,您将在 paulo.santos@sample-domain.com 中收到消息。

  • 如果账户上的电子邮件地址属于您的公司电子邮件系统,我们建议您联系 IT 系统管理员。他们也许能够帮助您重新获得电子邮件地址的访问权限。

如果您仍然无法访问 AWS 账户,可以在联系我们中展开 I'm an AWS customer and I'm looking for billing or account support (我是 AWS 客户,想要联系账单或账户支持) 菜单,找到其他支持选项。当您联系客户服务时,必须提供以下信息:

  • 账户上列出的所有详细信息,包括您的全名、电话号码、地址、电子邮件地址和信用卡最后四位数字。您可能需要创建一个新的 AWS 账户,以便联系客户服务,但这是帮助调查您的请求所必需的。

  • 您无法访问电子邮件账户以接收重置密码说明的原因.

  • 此外,请求支持团队删除您不使用的任何账户。最好不要在您的名下开立可能会导致向您收费的账户。

我无法登录我的账户

当您首次创建 AWS 账户时,您提供了电子邮件地址和密码。这些是您的 AWS 账户根用户凭证。如果您因丢失或忘记密码而无法访问自己的账户,可以恢复该密码。有关更多信息,请参阅 重置您丢失或遗忘的密码或访问密钥

您提供了账户电子邮件地址和密码,但 AWS 有时会要求您提供一次性验证码。要获取验证码,请检查与您的 AWS 账户关联的电子邮件地址中是否有来自 Amazon Web Services 的邮件。此类电子邮件地址以 @amazon.com 或 @aws.amazon.com 结尾。按照邮件中的说明操作。如果您在账户中未看到此类邮件,请检查垃圾邮件文件夹。如果您不再拥有该电子邮件的访问权限,请参阅我需要访问旧账户

当我向某个 AWS 服务发送请求时,收到了“访问被拒绝”

  • 验证您是否具有调用您请求的操作和资源的基于身份的策略权限。如果设置了任何条件,您还必须在发送请求时满足这些条件。有关查看或修改用于 IAM 用户、组或角色的策略的信息,请参阅管理 IAM 策略

  • 如果您尝试访问支持基于资源的策略的服务,例如 Amazon S3、Amazon SNS 或 Amazon SQS,请验证策略是否指定您作为委托人并授予您访问权限。如果您在您的账户中向服务发出请求,基于身份的策略或基于资源的策略将向您授予相应的权限。如果您在不同的账户中向服务发出请求,则基于身份的策略和基于资源的策略这两者都必须向您授予权限。要查看哪些服务支持基于资源的策略,请参阅使用 IAM 的 AWS 服务

  • 如果您的策略包含的条件具有键值对,请仔细检查。示例包括 aws:RequestTag/tag-key 全局条件键、AWS KMS kms:EncryptionContext:encryption_context_key 和多个服务支持的 ResourceTag/tag-key 条件键。确保键名称不与多个结果匹配。由于条件键名称不区分大小写,因为检查名为 foo 的键的条件将与 fooFooFOO 匹配。如果您的请求包含多个键值对,其中的键名称只是大小写形式不同,则您的访问可能会被意外拒绝。有关更多信息,请参阅 IAM JSON 策略元素:Condition

  • 如果您具有权限边界,请验证用于权限边界的策略是否允许您的请求。如果基于身份的策略允许请求,但权限边界不允许,则会拒绝请求。权限边界控制委托人实体(用户或角色)可以拥有的最大权限。基于资源的策略不受权限边界限制。权限边界不常用。有关 AWS 如何评估策略的更多信息,请参阅策略评估逻辑

  • 如果您手动签署请求(不使用 AWS 开发工具包),请确保您已正确签署请求

当我使用临时安全凭证发送请求时,收到了“访问被拒绝”

  • 首先,请确保您未因与您的临时凭证无关的原因而被拒绝访问。有关更多信息,请参阅当我向某个 AWS 服务发送请求时,收到了“访问被拒绝”

  • 要验证服务是否接受临时安全凭证,请参阅使用 IAM 的 AWS 服务

  • 验证您的请求是否采用了正确的签名和适当的格式。有关详细信息,请参阅工具包文档或 使用临时安全凭证以请求对 AWS 资源的访问权限

  • 验证您的临时安全凭证没有过期。有关更多信息,请参阅临时安全凭证

  • 验证 IAM 用户或角色拥有正确的许可。临时安全证书的权限派生自 IAM 用户或角色。因此,权限限于向您已代入其临时凭证的角色授予的权限。有关如何确定临时安全凭证的权限的更多信息,请参阅 控制临时安全凭证的权限

  • 如果您使用角色访问具有基于资源的策略的资源,则验证策略已授予该角色许可。例如,以下策略允许 MyRole 从账户 111122223333 访问 MyBucket

    { "Version": "2012-10-17", "Statement": [{ "Sid": "S3BucketPolicy", "Effect": "Allow", "Principal": {"AWS": ["arn:aws-cn:iam::111122223333:role/MyRole"]}, "Action": ["s3:PutObject"], "Resource": ["arn:aws-cn:s3:::MyBucket/*"] }] }

策略变量不起作用

  • 验证包含变量的所有策略(包括以下策略版本编号):"Version": "2012-10-17"。如果没有正确的版本编号,则在评估过程中不会更换变量。只会从字面上评估这些变量。如果您包含最新的版本号,则不包含变量的任何策略仍将起作用。

    Version 策略元素与策略版本不同。Version 策略元素用在策略之中,用于定义策略语言的版本。另一方面,当您对 IAM 中的客户托管策略进行更改时,将创建一个策略版本。已更改的策略不会覆盖现有策略。而是由 IAM 创建新的托管策略版本。要了解 Version 策略元素的更多信息,请参阅IAM JSON 策略元素:Version。要了解策略版本的更多信息,请参阅IAM 策略版本控制

  • 验证您的策略变量为正确的大小写。有关详细信息,请参阅 IAM 策略元素:变量和标签

我所做的更改可能不会立即可见

作为全球数据中心的计算机要访问的服务,IAM 使用称为最终一致性的分布式计算模型。您在 IAM(或其他 AWS 服务)中所做的任何更改需要一些时间才会对相关终端节点可见。它在服务器与服务器之间、复制区域与复制区域之间,以及全球的区域与区域之间发送数据需要时间,这会造成一定的延迟。IAM 也使用缓存来提高性能,但在某些情况下,这可能会增加耗时;在之前缓存的数据超时之前,更改可能不可见。

您在设计全球应用程序时,必须考虑到这些可能的延迟。确保应用程序可以按预期工作,即使在一个位置进行的更改不能立即在其他位置可见。此类更改包括创建或更新用户、组、角色或策略。在应用程序的关键、高可用性代码路径中,我们不建议进行此类 IAM 更改。而应在不常运行的、单独的初始化或设置例程中进行 IAM 更改。另外,在生产工作流程依赖这些更改之前,请务必验证更改已传播。

有关其他某些 AWS 服务如何受此影响的更多信息,请参阅以下资源: