本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 使用基于资源的策略和资源控制策略控制控制台访问权限 **重要** 默认情况下，控制台登录访问处于启用状态。 AWS Sign-In 最初允许不受限制地访问控制台。要添加限制，请为您的账户或组织启用控制台授权配置。在启用控制台授权之前，您创建的资源权限声明无效。请参阅[使用资源策略进行控制台访问控制台访问控制台入门](#console-access-control-getting-started)。 AWS Sign-In 支持基于资源的策略和资源控制策略 (RCP) 来控制对的访问。 AWS Sign-In使用这些策略在整个 AWS 管理控制台 访问过程中（身份验证之前、期间和之后）验证用户身份和网络位置。对于 root 用户，这些策略会在开始收集凭据之前验证网络位置和用户身份。只有当访问来自预期的网络时，才能输入凭证。 AWS Sign-In 基于资源的政策： + 适用于个人 AWS 账户。 + 让账户管理员根据网络参数和委托人身份限制控制台访问权限。 资源控制策略 (RCP)： + 通过 AWS Organizations 在整个组织范围内申请。 + 对所有成员账户进行集中管理。 两种策略类型均在身份验证之前验证访问权限。这会阻止委托人从意外网络访问登录页面。 这些策略不能取代继续适用的 IAM 基于身份的策略。 **注意** 有关资源控制策略（包括组织级配置和管理）的完整文档，请参阅 *AWS Organizations 用户*指南中的[资源控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)。本节主要侧重于 AWS Sign-In 基于资源的策略。 AWS Sign-In 基于资源的策略和 RCP 适用于以下身份验证方法： + **AWS 管理控制台**— 使用控制台登录页面直接登录。 + **AWS IAM 身份中心** — 使用 IAM 身份中心进行控制台登录。 + **联合身份提供商** — Sign-in 通过 SAML 或 OIDC 联合。 + **与 AWS Sign-In Amazon Connect、亚马 QuickSight逊、Healt AWS h Dashboard、亚马逊 AppStream、亚马逊 Lightsail、AWS IQ 集成的应用程序**。 这些控制不适用于使用访问密钥（AWS SDK 或 API 调用 Sigv4 签名）的编程访问。 ## 操作方法 AWS Sign-In 评估基于资源的策略 AWS Sign-In 在控制台访问期间的两个时刻评估适用的基于资源的策略或资源控制策略 (RCP)：身份验证之前（身份验证前阶段）和成功身份验证之后（身份验证后阶段）。每次评估都会检查您的策略中定义的条件密钥。可用的按键取决于阶段和操作。有关更多信息，请参阅 [支持的条件键](#console-access-control-condition-keys)。 **注意** 对于 root 用户登录，在出现密码提示之前，系统会阻止来自意外网络的访问尝试。这样可以防止来自意外网络的凭证提交。 身份验证后，评估还会考虑委托人的基于身份的策略。拒绝相关登录操作的 IAM 策略可能会阻止授予控制台会话，即使满足网络条件也是如此。 ## 支持的操作 AWS Sign-In 资源策略（基于资源的策略和 RCP）支持以下操作： `signin:Authenticate` 这是一项仅限评估（不可调用）的操作，在收到登录请求时进行评估。这是一种预身份验证检查，当委托人在登录页面上输入证书（根用户、IAM 用户）或使用身份提供商或 AWS STS（联合用户、角色）提供的证书启动控制台登录时，就会发生这种检查。 **支持的条件键：**`aws:SourceIp`、`aws:SourceVpc`、`aws:SourceVpce`、`aws:VpcSourceIp`、`aws:RequestedRegion`、`signin:PrincipalArn`。 Principal-based 全局条件键 (`aws:PrincipalArn`,`aws:PrincipalAccount`) 不可用于此操作，因为用户的身份尚未得到确认。 `signin:AuthorizeOAuth2Access` 用于生成 OAuth 授权码。成功进行身份验证后，系统生成 OAuth 授权码时会触发此操作。此时，用户已通过身份验证，并且可以使用基于委托人的条件密钥。 **支持的条件键：**`aws:SourceIp`、`aws:SourceVpc`、`aws:SourceVpce`、`aws:VpcSourceIp`、`aws:RequestedRegion`、`aws:PrincipalArn`、`aws:PrincipalAccount`。 `signin:CreateOAuth2Token` 此身份验证后操作用于创建和交换 OAuth 令牌。使用授权码兑换访问令牌、刷新令牌或执行令牌交换操作时，会触发此操作。 Principal-based 在此阶段可以使用条件键。 **支持的条件键：**`aws:SourceIp`、`aws:SourceVpc`、`aws:SourceVpce`、`aws:VpcSourceIp`、`aws:RequestedRegion`、`aws:PrincipalArn`、`aws:PrincipalAccount`。 **重要** 在创建 AWS Sign-In 策略（基于资源的策略或 RCP）时，请在身份验证前声明`signin:AuthorizeOAuth2Access`和身份验证后声明`signin:Authenticate`中涵盖策略`signin:CreateOAuth2Token`中的所有三项操作。控制台登录使用 OAuth 2.0，它按顺序完成所有三个操作。如果您的策略省略了某项操作，则相应阶段将不受保护。有关 VPC 终端节点策略操作`signin:CreateAccount`，包括，请参阅 [AWS 管理控制台私有访问](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-private-access.html)。 ## 支持的条件键 AWS Sign-In 支持基于资源的策略和资源控制策略 (RCP) 中的以下条件键。使用以下密钥根据网络位置和主体身份控制控制台访问权限： + **Network-based （所有操作）：**`aws:SourceIp`、`aws:SourceVpc`、`aws:SourceVpce`、`aws:VpcSourceIp`、`aws:RequestedRegion`。 + **Identity-based （身份验证后的操作）：**`aws:PrincipalArn`，`aws:PrincipalAccount`。 + **Service-specific （仅限预先认证）：**`signin:PrincipalArn`。 有关详细的使用规则、操作员兼容性、组合限制和按操作划分的可用性矩阵，请参阅[AWS Sign-In 条件键参考](reference-signin-condition-keys.md)。 ## 使用资源策略进行控制台访问控制台访问控制台入门 **先决条件** + AWS 已安装并配置 CLI。 + 适当的 IAM 权限（请参阅[AWS 托管策略： AWSSignInResourcePolicyManagement](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSSignInResourcePolicyManagement)）。 + 已识别的网络边界（IP 范围、VPC 或 VPC 终端节点）。 + 指定排除的委托人以保留访问权限（建议但可选）。 + 如果您的网络使用出口过滤，请将 AWS Sign-In 控制平面端点列入许可名单（请参阅[AWS Sign-In 将管理域列入许可名单](allowlist-domains.md#allowlist-domains-admin)）。 **重要** 在生产环境中启用控制台授权之前， AWS 建议至少配置一个排除的主体以维护紧急恢复访问权限。除非明确排除在外，否则所有委托人（包括根用户）均受该政策的约束。排除的委托人是可选的，但是如果网络条件意外发生变化，则省略它们会增加账户被封锁的风险。 `--region us-east-1`为 AWS Sign-In策略上的所有写入操作指定。 AWS 从该区域在全球范围内复制策略。读取操作可以针对任何区域。 ### 步骤 1：创建资源权限声明 创建用于定义访问控制的权限声明。所有写入操作都需要`--region us-east-1`（该 AWS Sign-In 服务仅接受该区域的政策更改）。其余参数（`--source-vpc``--source-ip`、`--requested-region`、、`--excluded-principal`）定义策略中的条件。例如，`--requested-region us-west-2`添加限制登录到 us-west-2 区域登录端点的条件。 **示例-限制对企业 VPC 的访问：** ``` aws signin put-resource-permission-statement \ --source-vpc vpc-0abc123def456789 \ --requested-region us-west-2 \ --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \ --client-token unique-request-id-12345 \ --region us-east-1 ``` **示例-限制对特定 IP 范围的访问：** ``` aws signin put-resource-permission-statement \ --source-ip "{{IP_ADDRESS}}" \ --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \ --region us-east-1 ``` **注意** 该`--excluded-principal`参数指定一个绕过网络限制的排除主体，在网络条件发生变化时保留紧急访问权限。 ### 步骤 2：启用控制台授权配置 以下步骤将在您的账户或组织中激活控制台登录过程的策略强制执行。可以随时创建资源权限语句，但在启用控制台授权后才会对其进行评估。 **警告** 如果您的网络条件配置错误，或者现有的服务控制策略 (SCP) 或资源控制策略 (RCP) 拒绝操作，则启用控制台授权可能会将主体拒之门外。 AWS Sign-In 在启用控制台授权之前，请确认您的权限声明正确无误，并删除或调整任何拒绝`signin:Authenticate``signin:AuthorizeOAuth2Access`、或的 SCP 或 RCP。`signin:CreateOAuth2Token` 对于独立账户： ``` aws signin put-console-authorization-configuration \ --target-id \ --region us-east-1 ``` 对于 AWS 组织： ``` aws signin put-console-authorization-configuration \ --target-id \ --region us-east-1 ``` 验证配置： ``` aws signin get-console-authorization-configuration \ --target-id \ --region ``` 删除控制台授权配置： ``` aws signin delete-console-authorization-configuration \ --target-id \ --region us-east-1 ``` ### 第 3 步：验证您的政策 列出所有权限声明： ``` aws signin list-resource-permission-statements \ --max-results 50 \ --region ``` 检索完整的合并策略： ``` aws signin get-resource-policy \ --region ``` 该`get-resource-policy`命令返回由您的所有权限声明组成的基于资源的完整策略。在测试控制台访问权限之前，请查看此政策以确认其反映了您的预期访问控制。 ### 区域可用性 所有 AWS 商业区域均提供控制台授权 API。您可以从您运营的任何地区调用这些 API。 **重要** 必须`us-east-1`在该区域中执行写入操作（`put-console-authorization-configuration``put-resource-permission-statement``delete-console-authorization-configuration`、、、`delete-resource-permission-statement`）。在中创建的策略`us-east-1`会自动进行全局复制。可以从任何区域执行读取操作 (`get-console-authorization-configuration``list-resource-permission-statements`、、`get-resource-policy`)。 ### 了解政策结构 AWS Sign-In 策略包含两个保护控制台登录流程不同阶段的声明： + **Pre-authentication statement (Action:`signin:Authenticate`)：**在收到登录请求时、身份验证完成之前进行评估。由于委托人的身份尚未得到确认，因此全局密钥`aws:PrincipalArn`在此阶段不可用。在此阶段`signin:PrincipalArn`，可以免除特定委托人的网络限制。 Network-based 在此阶段可以使用条件键进行评估。 + **Post-authentication 语句 (Action:`signin:AuthorizeOAuth2Access`,`signin:CreateOAuth2Token`)：**在身份验证之后，在 OAuth 令牌交换期间进行评估。`aws:PrincipalArn`用于豁免特定主体。在此阶段，所有基于网络和基于身份的条件密钥都可供评估。 这两个语句都是必需的，因为控制台登录使用 OAuth 2.0，它会按顺序执行所有三个操作。只有一条语句的策略会使另一个阶段处于不受保护状态。 `signin:PrincipalArn`支持根用户、IAM 用户和角色委托人类型。 `aws:PrincipalArn`支持所有委托人类型（根用户、IAM 用户、联合用户、角色）。 ## 策略示例 ### 示例 1：具有网络边界和排除主体的 RCP 以下资源控制政策 (RCP) 拒绝您组织中的所有账户从公司网络外部 AWS 管理控制台 登录。指定的被排除在外的校长可获得紧急访问豁免。由于 VPC ID 仅在一个区域内是唯一的，因此该策略包含第三条声明，用于锁定对预期区域的 VPC-based 访问权限。 该`EnforceNetworkPerimeterPreAuth`声明用于`signin:PrincipalArn`在预认证阶段豁免被排除的委托人。该`EnforceNetworkPerimeterPostAuth`语句`aws:PrincipalArn`用于在身份验证后豁免排除的主体。该`EnforceSourceVPCRegion`语句可确保请求区域与 VPC 区域匹配，从而限制对指定 VPC 的预期区域的访问。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceNetworkPerimeterPreAuth", "Effect": "Deny", "Principal": "*", "Action": ["signin:Authenticate"], "Resource": "*", "Condition": { "ArnNotEquals": { "signin:PrincipalArn": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root", "arn:aws:iam::777788889999:user/EmergencyUser", "arn:aws:iam::777788889999:role/OrgBreakGlassRole" ] }, "NotIpAddressIfExists": { "aws:SourceIp": "" }, "StringNotEquals": { "aws:SourceVpc": "" } } }, { "Sid": "EnforceNetworkPerimeterPostAuth", "Effect": "Deny", "Principal": "*", "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"], "Resource": "*", "Condition": { "ArnNotEquals": { "aws:PrincipalArn": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root", "arn:aws:iam::777788889999:user/EmergencyUser", "arn:aws:iam::777788889999:role/OrgBreakGlassRole" ] }, "NotIpAddressIfExists": { "aws:SourceIp": "" }, "StringNotEquals": { "aws:SourceVpc": "" } } }, { "Sid": "EnforceSourceVPCRegion", "Effect": "Deny", "Principal": "*", "Action": [ "signin:Authenticate", "signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceVpc": "" }, "StringNotEqualsIfExists": { "aws:RequestedRegion": "" } } } ] } ``` 本策略： + 除非请求来自企业 IP 范围或企业 VPC，否则拒绝访问登录页面。排除的根账户和 IAM 用户可通过`signin:PrincipalArn`（预身份验证）获得豁免。 + 除非来自企业 IP 范围或 VPC，否则拒绝 OAuth 令牌交换。排除的根账户、IAM 用户和角色通过`aws:PrincipalArn`（身份验证后的全局密钥）获得豁免。 + 如果请求来自指定的 VPC，但区域不匹配，则访问将被拒绝。 AWS VPC ID 在一个区域内是唯一的，并且相同的 VPC ID 可以存在于不同的区域中。 + 配置为 RCP 时，可在全球范围内应用于您的 AWS 组织。 ### 示例 2：排除委托人的 IP-based 访问 Resource-based 策略 以下基于资源的策略拒绝所有从指定 IP 范围之外发出请求的委托人访问控制台，排除的主体除外。该策略包含两个语句：使用服务专用`signin:PrincipalArn`密钥的预身份验证语句和使用全局密钥的身份验证后语句。`aws:PrincipalArn` ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": ["signin:Authenticate"], "Resource": "*", "Condition": { "ArnNotEquals": { "signin:PrincipalArn": "" }, "NotIpAddress": { "aws:SourceIp": "" }, "StringEquals": { "aws:ResourceAccount": "" } } }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"], "Resource": "*", "Condition": { "ArnNotEquals": { "aws:PrincipalArn": "" }, "NotIpAddress": { "aws:SourceIp": "" }, "StringEquals": { "aws:ResourceAccount": "" } } } ] } ``` 本策略： + 拒绝所有委托人的访问权限，除非他们从 IP 范围``进行连接。 + 使用`signin:PrincipalArn`（预身份验证）和（身份验证后）将排除的主体排除在网络限制之外。`aws:PrincipalArn` + 仅适用于配置基于资源的策略的特定账户（由标识``）。 ## 最佳实践 ### 为紧急恢复访问配置排除的主体 AWS 建议在生产环境中强制执行控制台授权策略之前，至少配置一个排除的用户。在预身份验证阶段，`signin:PrincipalArn`条件密钥可豁免根用户、IAM 用户和角色委托人。在身份验证后阶段，`aws:PrincipalArn`条件密钥豁免所有委托人类型（根用户、IAM 用户、联合用户、角色）。 排除的主体是可选的，但是如果网络条件意外变化或策略配置错误，则省略它们会增加账户被封锁的风险。 推荐的排除主体配置步骤： 1. 创建排除的 IAM 角色（例如，`BreakGlassRole`）。 1. 对于排除的角色，需要在角色信任策略中提供 MFA。 1. 仅向排除的身份授予紧急恢复所需的最低权限。 1. 在身份验证前 (`signin:PrincipalArn`) 和身份验证后 () 策略声明中都包含排除的主体 ARN。`aws:PrincipalArn` 1. 记录恢复过程并将其安全地存放在外面 AWS。 1. 定期测试排除的主体访问权限，以确认其在需要时起作用。 ### 维护恢复访问路径 除了上述排除的主体外，还要确保有其他访问方法可用，以防控制台授权策略意外阻止登录： + **Role-based 编程访问：**控制台授权策略仅适用于交互式控制台登录。它们不适用于使用 Sigv4 签名的 API 请求。如果您拥有编程访问权限（例如，现有访问密钥、跨账户角色），请使用它来调用`signin:DeleteConsoleAuthorizationConfiguration`和删除限制策略。凭证必须包含`signin:DeleteConsoleAuthorizationConfiguration`权限（包含在`AWSSignInResourcePolicyManagement`托管策略中）。 AWS 建议使用临时证书而不是长期 IAM 用户访问密钥。对于成员账户，管理账户管理员可以代`OrganizationAccountAccessRole`入成员账户 (`aws sts assume-role`) 来获取这些临时证书。 + **AWS 支持恢复：**保持您的 root 用户帐户电子邮件和电话号码为最新。如果排除主体和编程访问均不可用，Su AWS pport 可以在身份验证后提供恢复门户链接。[启用主机授权后，我的账户被锁定了](#console-access-control-ts-lockout)有关完整的恢复过程，请参阅。 ### 在生产部署之前进行测试 AWS 建议在未彻底测试该政策对账户的影响之前，不要将限制性的 RCP 附加到组织根部。取而代之的是，创建一个 OU，您可以将自己的账户逐个转移到一个账户中，或者至少可以少量移动，以确保您不会无意中将用户锁定在关键账户之外。 测试工作流程： 1. 创建包含您的主要网络限制的单一权限声明。 1. 在非生产账户中启用控制台授权。 1. 测试允许和拒绝的网络对控制台的访问。 1. 查看 Amazon CloudTrail 日志以确认政策评估行为。 1. 使用排除的委托人测试访问权限。 1. 逐步扩展到其他网络和账户。 1. 在生产账户中强制执行之前进行监控。 ### 采用深度防御的设计 使用 AWS Sign-In 基于资源的策略和资源控制策略作为更广泛的安全策略中的一层。 AWS Sign-In 策略根据网络位置和主体身份限制控制台访问权限。将它们与其他策略类型结合使用以创建全面的访问控制： + **AWS Sign-In 策略（基于资源的策略和 RCP）：**在身份验证之前、期间和之后，根据网络位置和委托人身份限制控制台访问权限。 + **IAM 策略：**控制用户登录后可以执行的操作。 + **服务控制策略 (SCP)：**对所有委托人应用组织范围的权限护栏。 + **VPC 终端节点策略：**控制可以通过 VPC 终端节点访问哪些服务和账户。 ### 持续监控和审计 AWS CloudTrail 自动记录所有 AWS Sign-In 策略评估和配置更改。在活动历史记录中查看这些 CloudTrail 事件，最长可保存 90 天。要延长保留期，请通过创建跟踪将事件传送到 Amazon S3（参见[创建跟踪](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)）。要获得实时警报，请创建与 AWS Sign-In 事件匹配的 Amazon EventBridge 规则，将您的跟踪配置为针对基于指标筛选器的警报发送到 CloudWatch日志日志组，或者将事件转发到现有的 SIEM 解决方案。 ## 使用案例 网络外围强制执行 限制对企业 VPC 或批准的 IP 范围的控制台访问权限。对个人账户使用基于资源的策略或在组织范围内实施的资源控制策略 (RCP)，以确保用户只能从可信的网络位置登录，从而防止来自公共或不可信网络的未经授权的访问。 **示例场景：**一家公司要求所有控制台访问权限都来自其公司网络或经批准的 AWS VPC。他们为单个账户或整个组织的 RCP 配置基于资源的策略，该策略拒绝来自所有其他网络的访问，同时保持紧急管理员的紧急恢复访问权限。 合规性要求 满足基于网络的访问控制的监管要求。许多合规框架要求组织根据网络位置限制对敏感系统的访问。 AWS Sign-In 策略提供了可审计、可强制执行的控制措施，以证明遵守了这些要求。 **示例场景：**金融服务公司必须遵守规定，要求只能从经批准的网络访问控制台。他们使用 RCP 来强制执行组织范围的网络限制，并维护 AWS CloudTrail 日志作为合规证据。 Multi-account 治理 在 AWS Organizations 中实施一致的控制台访问策略。使用 RCP 对所有成员账户实施标准网络限制，无需个人账户级别配置即可确保一致的安全状态。 **示例场景：**一家拥有 100 多个 AWS 账户的企业使用 RCP 强制执行一项策略，要求所有控制台访问权限都必须来自其组织内的 VPC 终端节点，从而确认所有账户之间的一致网络控制。 Third-party 访问控制 向来自特定网络的合作伙伴或承包商授予临时控制台访问权限。Organizations 可以在不影响整体安全状况的情况下为外部各方创建有时间限制、受网络限制的控制台访问权限。 **示例场景：**一家公司需要向咨询公司授予临时控制台访问权限。他们创建了一个基于资源的策略，该策略仅允许从咨询公司的已知 IP 范围进行访问，并且仅允许分配给顾问的 IAM 角色进行访问。 将控制台访问权限限制为特定委托人 无论网络位置如何，都只允许一组已定义的委托人登录 AWS 管理控制台，并拒绝所有其他委托人登录。这对于未使用 VPC 终端节点并希望使用基于身份的控制台限制的客户非常有用。被拒绝登录控制台的委托人保留其编程访问权限； AWS Sign-In 策略仅限制控制台登录，只有您豁免的委托人才能登录。 **示例场景：**一家公司只希望其管理员使用控制台。他们配置的 RCP 拒绝除管理员主体 ARN 之外的所有委托人登录控制台。具有有效证书的 Amazon EC2 实例角色无法登录控制台，因为它不是豁免委托人，尽管它保留了其编程权限。这解决了使用实例角色凭证进行控制台登录的常见情况。 ## 控制台访问控制故障排除 ### 由于 Sign-in 基于资源的策略中的网络状况，我无法登录 当 AWS Sign-In 策略拒绝访问时，您可能会看到以下错误消息之一： + “您的身份验证信息不正确。请再试一次。” （基于资源的策略拒绝预先进行身份验证） + “身份验证失败请求无效”（RCP 拒绝预先验证） + “身份验证失败：要访问此账户，请从其他网络登录，或者联系管理员了解更多信息”（身份验证后拒绝） 如果您看到其中任何错误并认为应该允许您进行访问，请联系您的 AWS 管理员。他们可以查看带有 `errorMessage` “由于基于资源的策略而拒绝授权” 或 “由于资源控制策略而拒绝授权” `ConsoleLogin` 的事件 CloudTrail 日志，以确定哪个策略声明拒绝了访问。 **可能的原因：** + 您的源 IP 地址不在允许的 CIDR 范围内。 + 您未连接到所需的 VPC 或 VPC 终端节点。 + 您正在访问的区域登录终端节点与政策中的预期区域不匹配。 + 您的委托人 ARN 未正确列在保单的排除委托人中。 + 该政策最近已更新，但该变更尚未在全球范围内复制。 **解决方法：** + 确认您已连接到公司网络或 VPN。 + 如果配置了基于 VPC 端点的限制，请确认您通过正确的 VPC 终端节点进行访问。 + 请联系您的 AWS 管理员以验证策略配置并确认哪些网络已获得授权。 + 如果您被配置为排除的委托人，请确认您的委托人 ARN 在排除的委托人列表中配置正确。 + 如果最近进行了策略更改，请等待几分钟以完成全局复制。 **对于诊断此问题的管理员：** + 查看策略评估事件的 AWS CloudTrail 日志，以确定哪个策略声明拒绝了访问。 + `aws signin get-resource-policy`用于查看当前的策略配置。 + 验证用户的网络位置是否符合策略中的条件。 + 如果用户应免于网络限制，请确认已正确配置排除的主体。 ### 启用主机授权后，我的账户被锁定了 如果您配置了控制台授权，但无法再访问您的账户，则在实施该策略之前，您可能没有配置排除的委托人。 重新获得访问权限的途径有多种，具体取决于您的账户类型和可用凭证。 **选项 1：使用编程访问权限（AWS CLI 或 SDK）** 控制台授权策略仅适用于交互式控制台登录。它们不适用于使用 Sigv4 签名的 API 请求。如果您拥有编程访问权限（例如，现有访问密钥、跨账户角色），请使用它来调用`signin:DeleteConsoleAuthorizationConfiguration`和删除限制策略。您使用的凭证必须具有调用权限`signin:DeleteConsoleAuthorizationConfiguration`。`AWSSignInResourcePolicyManagement`托管策略包括此权限。 AWS 建议使用临时证书而不是长期 IAM 用户访问密钥。对于成员账户，管理账户管理员可以代`OrganizationAccountAccessRole`入成员账户以获取临时证书。此角色不会在受邀加入组织的账户中自动创建。 ``` aws signin delete-console-authorization-configuration \ --target-id \ --region us-east-1 ``` 或者删除特定的权限声明： ``` # First, list statements to get the statement ID aws signin list-resource-permission-statements \ --region us-east-1 # Then delete the problematic statement aws signin delete-resource-permission-statement \ --statement-id \ --region us-east-1 ``` **选项 2：联系 Suppor AWS t** 如果您没有编程访问权限且无法使用帐户访问权限，请联系 Supp AWS ort 以启动锁定恢复流程。`OrganizationAccountAccessRole` 恢复过程如下所示： 1. 如果您无法使用上述选项解决问题，请在 Support Center 提交 AWS 支持案例。 AWS 在检查您的账户之前，Support 将验证您的身份。验证方法可能包括确认根用户账户的电子邮件地址、回复电话验证电话或回答账户安全问题。 1. AWS Support 确认控制台访问问题是由基于资源的策略封锁引起的。 1. AWS Support 共享恢复门户链接。使用此链接使用具有`signin:DeleteConsoleAuthorizationConfiguration`权限的账户中的 IAM 委托人登录。此权限允许主体删除导致锁定的控制台授权配置。 **重要** 恢复门户会删除该账户的整个控制台授权配置，包括所有资源权限声明。恢复门户不允许重新配置 AWS Sign-In 基于资源的策略。 恢复门户链接在 Support 共 AWS 享 72 小时后过期。如果您未在该窗口内完成恢复，请联系 Supp AWS ort 重新启动该过程。 **重新获得访问权限后：** + 查看并更新您的资源权限声明，以包括正确配置的排除委托人。 + 在重新启用控制台授权之前，请测试来自预期网络的控制台访问权限。 + 记录您的恢复程序，以备将来参考。 ### 我所做的更改可能不会立即可见 策略更改会全局复制，但复制可能需要几分钟。 **解决方法：** + 更改策略后，请等待几分钟以完成全局复制。 + 使用`get-resource-policy`以下命令验证您的更改： ``` aws signin get-resource-policy --region ``` + 检查 AWS CloudTrail 日志中是否存在策略评估事件，以确认正在评估新策略。 + 确认您的操作使用的是正确的区域（写入操作必须使用`us-east-1`）。 + 如果使用基于 VPC 终端节点的条件，请确认 VPC 终端节点策略也配置正确。 **常见的策略复制问题：** + **缓存的登录页面：**浏览器可能会缓存登录页面。清除浏览器缓存或使用隐身窗口来测试政策变更。 + **相互冲突的声明：**如果您有多个权限声明，请确认它们之间没有冲突。`get-resource-policy`用于查看合并后的政策。 + **VPC 终端节点 AWS Sign-In 策略：**策略与 VPC 终端节点策略配合使用。两者都必须允许所需的访问权限。