# SEC10-BP05 预置访问权限
<a name="sec_incident_response_pre_provision_access"></a>

确保事件响应者将正确的访问权限预置到 AWS 中，以缩短调查到恢复所需的时间。

 **常见反模式：**
+  使用根账户进行事件响应。
+  变更现有账户。
+  在提供实时权限提升时直接操作 IAM 权限。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

AWS 建议尽可能减少或消除对长期有效凭证的依赖，转而使用临时凭证和*实时*权限提升机制。长期有效的凭证容易带来安全风险，并且会增加运营开销。对于大多数管理任务以及事件响应任务，建议您对管理访问实施[身份联合验证](https://aws.amazon.com/identity/federation/)以及[临时上报](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)。在此模型中，用户请求提升到更高级别的权限（例如事件响应角色），如果用户符合提升条件，则会向审批者发送请求。如果请求获得批准，用户将收到一组临时的 [AWS 凭证](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)，可用于完成用户任务。在这些凭证过期后，用户必须提交新的提升请求。

 在大多数事件响应场景中，建议使用临时权限提升。执行此操作的正确方法是使用 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) 和[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)来限定访问范围。

 在一些场景中，联合身份不可用，例如：
+  与被盗用的身份提供者（IdP）相关的中断。
+  导致联合访问管理系统损坏的错误配置或人为错误。
+  恶意活动，例如分布式拒绝服务（DDoS，Distributed Denial of Service）事件或导致系统不可用的活动。

 在上述情况下，应配置紧急 *Break Glass* 访问，以允许调查事件并及时给予补救。我们建议您使用[具有适当权限的用户、组或角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)，来执行任务和访问 AWS 资源。请仅将根用户用于[需要根用户凭证的任务](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。要确认事件响应者对 AWS 和其他相关系统是否具有正确的访问权限级别，建议预置专用的账户。账户需要特许的访问权限，并且必须受到严格的控制和监视。在构建账户时，必须使用执行必要任务所需的最少权限，并且访问级别应基于作为事件管理计划的一部分创建的行动手册。

 最好使用专门构建的专用用户和角色。通过添加 IAM 策略来临时提升用户或角色的访问权限，既会导致无法清楚地了解用户在事件期间拥有哪些访问权限，又会带来无法撤销提升的权限的风险。

 请务必删除尽可能多的依赖项，以确保能在尽可能多的故障场景中获得访问权限。为了支持此操作，可创建一个行动手册，验证是否在专用的安全账户中创建事件响应用户作为用户，而不是通过任何现有的联合身份验证或单点登录（SSO）解决方案管理他们。每个响应者都必须拥有自己的指定账户。账户配置必须实施[强密码策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)和多重身份验证（MFA）。如果事件响应行动手册仅需要对 AWS 管理控制台 的访问权限，则用户不应配置访问密钥，并且应明确禁止用户创建访问密钥。可以使用 IAM 策略或服务控制策略（SCP，Service Control Policy）进行此配置，如 AWS 安全最佳实践（适用于 [AWS Organizations SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)）中所述。用户仅能够在其他账户中代入事件响应角色，而不应具有其他任何权限。

 在事件处理期间，可能需要向其他内部或外部人员授予访问权限，以支持调查、补救或恢复活动。在这种情况下，可以使用前面提到的行动手册机制，并且必须创建一个流程，确保在事件结束后立即撤消其他任何访问权限。

 要确保能正确地监控和审计对事件响应角色的使用，至关重要的一点是，为此目的创建的 IAM 账户不会在人员之间共享，并且不会使用 AWS 账户根用户，除非[特定任务要求这样做](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。如果需要根用户（例如，对特定账户的 IAM 访问权限不可用），请使用单独的流程和可用的行动手册来验证根用户登录凭证和 MFA 令牌的可用性。

 要为事件响应角色配置 IAM 策略，请考虑使用 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) 来生成基于 AWS CloudTrail 日志的策略。为此，请在非生产账户中向事件响应角色授予管理员访问权限，并运行行动手册。完成后，会创建一个策略，仅允许已执行的操作。之后，可以跨所有账户将此策略应用于所有事件响应角色。您可能希望为每个行动手册创建一个单独的 IAM 策略，以便更轻松地进行管理和审计。示例行动手册可能包括针对勒索软件、数据泄露、丢失生产访问权限和其他场景的响应计划。

 使用事件响应用户账户可在[其他 AWS 账户 中代入专用的事件响应 IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)。必须将这些角色配置为仅可由安全账户中的用户代入，并且信任关系必须要求调用主体已使用 MFA 进行身份验证。角色必须使用严格界定的 IAM 策略来控制访问。确保这些角色的所有 `AssumeRole` 请求都记录在 CloudTrail 中并发出提醒，并确保记录使用这些角色执行的任何操作。

 强烈建议清楚地命名 IAM 账户和 IAM 角色，以便在 CloudTrail 日志中轻松找到他们。例如，将 IAM 账户命名为 `<USER_ID>-BREAK-GLASS`， 并将 IAM 角色命名为 `BREAK-GLASS-ROLE`。

 [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 用于记录 AWS 账户中的 API 活动，并且应该用于[配置关于使用事件响应角色的提醒](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)。请参阅博文，了解有关配置使用根密钥时的提醒。可以修改说明以配置 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 指标筛选条件，从而筛选 `AssumeRole` 事件（与事件响应 IAM 角色相关）：

```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```

 由于事件响应角色可能具有高级别的访问权限，因此，请务必将这些提醒转至广泛的群体，并及时采取适当的行动。

 在事件处理期间，响应者可能需要访问不受 IAM 直接保护的系统。它们可能包括 Amazon Elastic Compute Cloud 实例、Amazon Relational Database Service 数据库或软件即服务（SaaS）平台。强烈建议不要使用 SSH 或 RDP 等本机协议，而是使用 [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 对 Amazon EC2 实例进行所有管理访问。可以使用安全且经过审计的 IAM 控制此访问。此外，还可以使用 [AWS Systems Manager Run Command 文档](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)自动实施行动手册的部分内容，这样可以减少用户出错的机会并缩短恢复时间。对于访问数据库和第三方工具，我们建议将访问凭证存储在 AWS Secrets Manager 中，并向事件响应者角色授予访问权限。

 最后，事件响应 IAM 账户的管理应该添加到您的[合并人员、移动人员和离开人员流程](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html)中，并定期进行检查和测试，以确认只允许预期访问。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [管理对 AWS 环境的临时提升的访问权限](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 
+  《[AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)》
+  [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 
+  [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [为 IAM 用户设置账户密码策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [在 AWS 中使用多重身份验证（MFA）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) 
+ [ 使用 MFA 配置跨账户访问 ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ 使用 IAM Access Analyzer 生成 IAM 策略 ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ 如何在使用 AWS 账户的根访问密钥时接收通知 ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ 使用 IAM 托管策略创建精细会话权限 ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)
+  [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) 

 **相关视频：**
+ [ 在 AWS 中自动化事件响应和取证](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+  [运行手册、事件报告和事件响应 DIY 指南](https://youtu.be/E1NaYN_fJUo) 
+ [ 准备和响应 AWS 环境中的安全事件 ](https://www.youtube.com/watch?v=8uiO0Z5meCs)