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

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

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

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

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

AWS 建议尽可能减少或消除对长期有效凭证的依赖，转而使用临时凭证和 *实时* 权限提升机制。长期有效的凭证容易带来安全风险，并且会增加运营开销。对于大多数管理任务以及事件响应任务，建议您对管理访问实施 [身份联合验证](https://docs.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* 访问，以允许调查事件并及时给予补救。我们建议您使用 [具有适当权限的 IAM 用户，](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 策略来临时提升用户或角色的访问权限，既会导致无法清楚地了解用户在事件期间拥有哪些访问权限，又会带来无法撤销提升的权限的风险。 

 请务必删除尽可能多的依赖项，以确保能在尽可能多的故障场景中获得访问权限。为了支持此操作，可创建一个行动手册，验证是否在专用的安全账户中创建事件响应用户作为 AWS Identity and Access Management 用户，而不是通过任何现有的联合身份验证或单点登录（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 安全事件响应指南 ](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/)
+ [ 多账户环境中的 AWS Organizations 服务控制策略的最佳实践 ](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/)

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

 **相关示例：** 
+ [ 实验室：AWS 账户设置和根用户 ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ 实验：使用 AWS 控制台和 CLI 的事件响应 ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)