aws root账户_所以您继承了一个AWS账户

aws root账户

Many engineers have found themselves in the unenviable position of being handed the keys to an AWS environment with absolutely no explanation of its contents, documentation, or training. Whether an employee leaves the company, teams are restructured, or your company acquires another, you will need to quickly audit the account and get up to speed on its operation. Even worse, many of these inherited accounts are running production infrastructure that must be kept running during the transition period. Now that you’re responsible for this account, you will also be responsible for keeping it secure.

许多工程师发现自己处于无法获得AWS环境密钥的位置，而绝对没有对其内容，文档或培训的解释。 无论员工离开公司，重组团队还是公司收购其他公司，您都需要快速审核帐户并加快其运作速度。 更糟糕的是，这些继承的帐户中有许多正在运行生产基础结构，在过渡期间必须保持该基础结构运行。 既然您对此帐户负责，那么您也将负责确保其安全。

There is a wealth of documentation, training, guides, and other resources available online to learn about security in AWS cloud environments. But many of those resources assume that you are either building an account from scratch, were intimately involved in building the account from its inception, or can take great liberty in applying destructive changes. In our case, the reality is that you’re likely staring at eight years of accumulated infrastructure with absolutely no idea of what’s running or how to make changes without causing a production outage.

在线提供了大量文档，培训，指南和其他资源，以了解AWS云环境中的安全性。 但是，其中许多资源都假定您要么从头开始构建帐户，要么从一开始就密切参与帐户的构建，要么可以在采用破坏性更改方面大放异彩。 在我们的案例中，现实情况是您可能盯着八年累积的基础架构，而完全不知道正在运行什么或如何进行更改而不会导致生产中断。

I’ve written this guide to help you filter through the mess, isolate the changes you need to make, and start to tame your environment. While I’ll assume that you have AWS experience, we’ll start with the security basics, along with changes that won’t impact running services, before moving to making tweaks that will require a bit more investigation and preparation. Our goal is to quickly triage the situation, implement the lowest risk but most impactful changes first, and then work our way toward a concrete security policy that can be used longer-term.

我编写了本指南，以帮助您过滤烂摊子，隔离需要进行的更改并开始驯服环境。 虽然我假设您具有AWS经验，但在开始进行需要更多调查和准备的调整之前，我们将从安全性基础以及不会影响正在运行的服务的更改开始。 我们的目标是快速对情况进行分类，首先实施风险最低但影响最大的更改，然后逐步采用可以长期使用的具体安全策略。

Note: The absolute best-case scenario when inheriting an account is to spin up a separate new account and migrate applications over time. However, I recognize that that is a pipe dream for many accounts, hence this guide was born.

注意：继承帐户的绝对最佳方案是启动一个单独的新帐户并随时间迁移应用程序。 但是，我认识到这对很多客户来说都是梦pipe以求的事情，因此本指南诞生了。

This guide is not a substitute for a properly-designed security program. Instead, it is designed to be a quick-start guide for the first 30–90 days after assuming ownership over an account that may not have previously been properly managed.

本指南不能替代正确设计的安全程序。 取而代之的是，它被认为是假设先前没有适当管理帐户的所有权之后的前30-90天的快速入门指南。

步骤1：获得稳定的访问权限 (Step 1: Get Stable Access)

If you’re lucky, the target account is already configured to work with your organization’s Single Sign On (SSO) provider. In actuality, you’re more likely to have sticky note with an email address and a password on it. Our first step is to confirm access to the account and embed our own user to avoid losing access. This step is especially crucial if you’re taking over an account because a previous employee left the company.

如果幸运的话，目标帐户已配置为可以与组织的单一登录(SSO)提供程序一起使用。 实际上，您更有可能在便笺上带有电子邮件地址和密码。 我们的第一步是确认对帐户的访问权限并嵌入我们自己的用户，以避免丢失访问权限。 如果您因为以前的员工离开公司而要接管帐户，则这一步骤尤其重要。

If you were given a user account and password to sign in with, it’s possible this is the root user account. This is not a good practice, but first we need to stabilize our access by running through the following steps:

如果为您提供了用于登录的用户帐户和密码，则可能是root用户帐户。 这不是一个好习惯，但是首先我们需要通过执行以下步骤来稳定访问权限：

1. Log in with the email and password to determine if you’re using the root account.
   使用电子邮件和密码登录，以确定您是否正在使用root帐户。
2. If the credentials you have are not the root credentials, and you can’t access them elsewhere, you will need to contact AWS support to regain that access. This is extremely important to do quickly; AWS will need to verify your identity, which will likely require you to submit documentation on behalf of your company. You do not want anyone else outside of your company to have root access to the account; everything you do in the next steps will be pointless if someone else has this access.
   如果您拥有的凭证不是根凭证，并且您无法在其他地方访问它们，则需要联系AWS支持以重新获得该访问权。 快速执行非常重要； AWS将需要验证您的身份，这可能需要您代表您的公司提交文档。 您不希望公司以外的任何人具有对该帐户的root访问权； 如果其他人具有此访问权限，则您在下一步中所做的所有操作都是毫无意义的。
3. If the credentials you have are the root credentials, change them immediately. You can do this by clicking “My Security Credentials” from the account menu at the top right of the dashboard. If possible, change the email to a distribution list (that can receive external email) and that you are a member of. Choose a very strong password.
   如果您拥有的凭据是根凭据，请立即更改它们。 您可以通过在信息中心右上方的帐户菜单中单击“我的安全证书”来执行此操作。 如果可能，请将您的电子邮件地址更改为一个通讯组列表(可以接收外部电子邮件)，并且您是该成员的成员。 选择一个非常强的密码。
4. If SSO is not currently setup, create a new IAM user using your own email and password and add the “Administrator” managed IAM policy to it. We’ll talk more about SSO later, but for now an email-based user is sufficient.
   如果当前未设置SSO，请使用您自己的电子邮件和密码创建一个新的IAM用户，然后向其中添加“管理员”托管的IAM策略。 稍后我们将详细讨论SSO，但是现在基于电子邮件的用户就足够了。
5. Enable MFA for your new user.
   为新用户启用MFA。

步骤2：停止使用root用户 (Step 2: Stop Using the Root User)

Your goal from this point forward is to stop using the root user entirely. To do this safely, we will need to make sure that nothing else is using the root user programmatically and then create an MFA token for the account which you will lock in a safe somewhere.

从现在开始，您的目标是完全停止使用root用户。 为了安全地执行此操作，我们需要确保没有其他人以编程方式使用root用户，然后为该帐户创建MFA令牌，并将其锁定在安全的位置。

If you’re lucky, you won’t find any access keys here. 如果幸运的话，您将在这里找不到任何访问密钥。

1. Log in as the root user (hopefully for the last time).
   以root用户身份登录(希望最后一次登录)。
2. Determine if anyone (or anything) is using the root user’s account via the API by checking the root user’s security credentials.
   通过检查根用户的安全凭证，确定是否有人(或任何东西)通过API使用了根用户的帐户。
3. Again, with luck, you won’t see any in-use credentials here. But experience tells me that you’re more likely to find two in-use access keys that have been used within the last 24 hours and will spend the rest of your existence attempting to track these keys down.
   同样，很幸运，您在这里看不到任何使用中的凭证。 但是经验告诉我，您更有可能找到在过去24小时内使用过的两个使用中的访问密钥，并将花费剩余的时间尝试跟踪这些密钥。
4. If you find keys that have not been used in a reasonable timeframe, delete them. If you’re unsure (maybe the key was used 112 days ago and you have a hunch it’s hardcoded on a production server in a closet at headquarters 1500 miles away), then take a note to come back to this because we need to fix it ASAP.
   如果找到在合理时间内未使用的键，请将其删除。 如果不确定(也许密钥是在112天前使用的，并且您有预感，它已经硬编码在位于1500英里之外的总部的壁橱中的生产服务器上)，那么请记下该注释，因为我们需要对其进行修复尽快。
5. Next, enable MFA on the root user account from the same page. Take a screenshot of the QR code key material and save it to Vault (or your company’s secret store) and then share the key with your boss or other trusted team members. Do not save the QR code on your phone (or if you need to to get the initialization codes, delete it immediately after).
   接下来，在同一页面上以root用户帐户启用MFA。 拍摄QR码密钥材料的屏幕截图，并将其保存到Vault(或您公司的秘密商店)中，然后与您的老板或其他受信任的团队成员共享密钥。 请勿将QR码保存在手机上(或如果需要获取初始化码，请在之后立即将其删除)。

步骤3：更新帐单资料 (Step 3: Update Billing Information)

While finance may be happy with someone else paying for your AWS usage for as long as it takes them to discover the charge, you want to get this information changed quickly. This info will be used by AWS to help identify you if you need to recover the account, and you don’t want to get into a digital stalemate if the previous owner tries to claim ownership because their credit card is still footing the bill.

只要其他人愿意为您的AWS使用付费，财务就可能很高兴，只要他们发现费用即可，但是您希望快速更改此信息。 AWS将使用此信息来帮助您识别您是否需要恢复帐户，并且如果先前的所有者试图声明所有权，因为他们的信用卡仍在支付账单，则您不想陷入数字僵持状态。

You’re probably going to need to involve finance for this one, so get a fruit basket queued up so they prioritize your ticket and don’t faint when you explain the incoming $142k/month charge they’re about to see.

您可能需要为此筹集资金，因此请排队等候一个水果篮，以便他们优先考虑您的机票，并且当您解释他们即将看到的每月14.2万美元的费用时也不会晕倒。

Once you get the correct billing info, make sure to add it and then remove all other payment methods including bank accounts and credit cards.

获得正确的帐单信息后，请确保添加它，然后删除所有其他付款方式，包括银行帐户和信用卡。

If the account is a member of an existing AWS Organization (and you can confirm it’s not one owned by your company), leave the Organization. If your company uses Organizations, be very careful about joining it at this stage; it’s possible that existing Service Control Policies may affect running services or workflows. If billing must be handled through the Organization, you’ll need to discuss adding the account with the Organization admin for this use case to take advantage of “billing only” features.

如果该帐户是现有AWS组织的成员(并且您可以确认它不是您的公司所有)，请离开该组织。 如果您的公司使用组织，则在此阶段要非常小心； 现有的服务控制策略可能会影响正在运行的服务或工作流程。 如果必须通过组织来处理帐单，则您需要与组织管理员讨论如何为此用例添加帐户，以利用“仅开票”功能。

Once your billing information is changed, it’s time to log out of the root account and switch to using the IAM user created earlier.

更改帐单信息后，就可以注销根帐户并切换为使用之前创建的IAM用户。

步骤4：启用CloudTrail日志记录和监视 (Step 4: Enable CloudTrail Logging and Monitoring)

Keep in mind that at this point, you still have no idea who or what has access to the account, what is running, and what kinds of activity is occurring in it. Let’s fix this by turning on AWS CloudTrail.

请记住，在这一点上，您仍然不知道谁有权访问该帐户，什么人可以访问该帐户，正在运行什么，以及其中正在进行什么活动。 让我们通过打开AWS CloudTrail来解决此问题。

No trails is no good. 没有足迹是不好的。

1. Open the CloudTrail console and determine if an existing trail is configured. If it is, you’ll want to verify that the logs are being sent to a location you have access to. If you don’t recognize the location, modify the trail to send its logs to your organization’s centralized S3 bucket used for log collection. If your organization doesn’t have such a bucket, configure CloudTrail to log to a bucket in your own account for now.
   打开CloudTrail控制台，确定是否配置了现有路径。 如果是这样，您将需要验证日志是否已发送到您有权访问的位置。 如果无法识别位置，请修改跟踪以将其日志发送到组织的集中S3存储桶中，以用于日志收集。 如果您的组织没有这样的存储桶，请立即配置CloudTrail以登录到您自己帐户中的存储桶。
2. Make sure to turn on CloudTrail’s optional security features, including encryption at-rest and file validation.
   确保打开CloudTrail的可选安全功能，包括静态加密和文件验证。

3. This is also a good time to setup some basic metric alerts for critical security activity within the account. Ideally, these monitors would run in your organizations’ centralized logging environment (e.g. Splunk), but if that’s not possible, you can configure this trail to send its logs to CloudWatch, where you can configure metric alerts. I recommend setting up alerts for CloudTrail and IAM changes at a minimum.

   这也是为帐户内的关键安全活动设置一些基本指标警报的好时机。 理想情况下，这些监视器将在您组织的集中式日志记录环境(例如Splunk)中运行，但是，如果不可能，您可以配置此跟踪以将其日志发送到CloudWatch，在此您可以配置指标警报 。 我建议至少为CloudTrail和IAM更改设置警报。

There are many other AWS security solutions that may be helpful at this point, including:

目前，还有许多其他的AWS安全解决方案可能会有所帮助，包括：

• AWS Security Hub

  AWS安全中心

• Amazon GuardDuty

  亚马逊GuardDuty

• AWS Config

  AWS配置

• Amazon Macie

  亚马逊梅西

• Amazon Inspector

  亚马逊检查员

• Amazon Detective

  亚马逊侦探

One challenge you may have at this stage is identifying true security incidents from the noise. These services tend to begin producing thousands of results in a busy environment, which could lead you on an endless goose chase. I recommend enabling them in “audit mode” where possible, and returning later once the account is more carefully pruned.

在此阶段，您可能面临的一个挑战是从噪声中识别出真正的安全事件。 这些服务往往会在繁忙的环境中开始产生数千个结果，这可能会导致您无休止的追赶鹅。 我建议尽可能在“审核模式”下启用它们，并在更仔细地修剪帐户后再返回。

步骤5：清理IAM实体 (Step 5: Cleanup IAM Entities)

I once did some consulting work for a company that had close to 1,200 IAM users in their account, each with access keys. I nearly bit off my tongue during that walkthrough. If you’re in this situation, it’s easy to put these steps off until later. But it’s truly important to get a handle on IAM. A single user or access key with excessive permissions could compromise the entire environment. Our goal in this step is to cleanup users that have not been used in awhile, delete access keys where possible, and begin to at least scope the policies attached to each user.

我曾经为一家公司提供一些咨询服务，该公司的帐户中有近1200个IAM用户，每个用户都有访问密钥。 在该演练中，我几乎咬住了舌头。 如果您处于这种情况，可以很轻松地将这些步骤推迟到以后。 但是，掌握IAM确实很重要。 具有过多权限的单个用户或访问密钥可能会损害整个环境。 我们在此步骤中的目标是清除一段时间内未使用的用户，在可能的情况下删除访问密钥，并至少开始确定附加给每个用户的策略的范围。

Initial Cleanup

初始清理

The IAM Credential Report will help you avoid carpal tunnel from clicking into every user. IAM凭据报告将帮助您避免腕管点击进入每个用户。

1. Download the IAM Credential Report for your account, which will contain a number of very important details for each IAM user.
   为您的帐户下载IAM凭据报告，其中将包含每个IAM用户的许多非常重要的详细信息。

2. Start by isolating the easiest users to delete: those who have neither a password (i.e. non-console users) nor access keys or attached certificates. These users have no value (to us anyway; their parents likely still love them). Look for all of the following fields and values:

   首先隔离最容易删除的用户：既没有密码(即非控制台用户)又没有访问密钥或附加证书的用户。 这些用户毫无价值(无论如何对我们来说；他们的父母可能仍然爱他们)。 查找以下所有字段和值：

   Start by isolating the easiest users to delete: those who have neither a password (i.e. non-console users) nor access keys or attached certificates. These users have no value (to us anyway; their parents likely still love them). Look for all of the following fields and values:- password_enabled: false- access_key_1_active: false- access_key_2_active: false- cert_1_active: false- cert_2_active: false

   首先隔离最容易删除的用户：既没有密码(即非控制台用户)又没有访问密钥或附加证书的用户。 这些用户毫无价值(无论如何对我们来说；他们的父母可能仍然爱他们)。 查找以下所有字段和值： -password_enabled：false- access_key_1_active：false- access_key_2_active：false- cert_1_active：false- cert_2_active：false

3. Once you’ve deleted these users, it’s time to move on to ones that do not have passwords but may have access keys used sufficiently long ago. “Sufficient” in this case is defined as “the length of time you’re willing to bet your job on a service not being used.” I’ve seen some franken-services arise after years of inactivity, so be careful.
   删除这些用户后，就该转到没有密码但访问密钥可能已使用很久的用户。 在这种情况下，“足够”的定义是“您愿意将工作押在未使用的服务上的时间。” 我已经看到多年不活动后出现了一些弗兰肯服务，所以要小心。

4. Next up are users who don’t have access keys, but do have passwords used sufficiently long ago. If Bob hasn’t logged in since Steve Jobs was at the helm at Apple, chances are he doesn’t need this account. Check the password_last_used field for this exercise.

   接下来是没有访问密钥，但密码使用时间已久的用户。 如果史蒂夫·乔布斯(Steve Jobs)掌管苹果以来，鲍勃(Bob)尚未登录，则很可能他不需要此帐户。 检查此练习的password_last_used字段。

Sleuthing for Users

为用户侦探

At this point, hopefully you’ve cleaned out a significant portion of users who had access to the account. To handle the remaining ones, it’s time to do some sleuthing.

到目前为止，希望您已经清除了访问该帐户的很大一部分用户。 要处理剩余的内容，是时候进行一些侦查。

Disabling user console access might force them to find you. 禁用用户控制台访问权限可能会迫使他们找到您。

1. Start with users who have both passwords and access keys. If you recognize them, send an email asking them what the keys are being used for and whether they can be disabled. Chances are they left a script running somewhere.
   从同时拥有密码和访问密钥的用户开始。 如果识别出它们，请发送电子邮件询问它们正在使用什么键以及是否可以禁用它们。 他们有可能在某个地方运行脚本。
2. If the username resembles an AIM screen name from your college days and you don’t recognize the user, we’ll need to get creative. I don’t necessarily recommend locking the account immediately, but if they have excessive permissions, it might be necessary. Just be careful not to disable the in-use access keys at this stage. Hopefully the users know where to find you if their access is revoked, so make sure to climb out of the server room and introduce yourself to the team. If you don’t hear anything in 90 days, chances are the user didn’t need that access and it can be permanently revoked.
   如果用户名类似于您上大学时的AIM屏幕名称，并且您不认识该用户，则我们需要发挥创意。 我不一定建议立即锁定该帐户，但是如果他们拥有过多的权限，则可能有必要。 请注意不要在此阶段禁用正在使用的访问键。 希望用户可以知道如果他们的访问权被撤消后可以在哪里找到您，因此请确保爬出服务器机房并向团队介绍自己。 如果您在90天内听不到任何声音，则很可能是用户不需要该访问权限，并且该访问权限可能会被永久撤销。
3. Repeat this process for users who have only passwords. These will be easier since they can be more safely deleted after a period of time after being locked.
   对仅拥有密码的用户重复此过程。 这些将更容易，因为可以在锁定后一段时间后更安全地删除它们。

We’ll now be left with a more manageable set of users who have either password or access key access to AWS (but ideally not both at the same time). From this list, I recommend placing them into three categories:

现在，我们将拥有一组更具可管理性的用户，这些用户具有对AWS的密码或访问密钥访问权限(但理想情况下，不能同时使用这两个用户)。 从此列表中，我建议将它们分为三类：

1. Humans who need console access for legitimate businesses purposes.
   需要出于合法业务目的而需要控制台访问权限的人员。
2. Machines using access keys outside of AWS (e.g. Jenkins running in a closet).
   使用AWS外部访问密钥的机器(例如，在壁橱中运行的Jenkins)。
3. Machines using access keys inside of AWS (e.g. EC2 servers, Lambda, etc.).
   使用AWS内部访问密钥的机器(例如EC2服务器，Lambda等)。

Preparing Account Policies

准备帐户政策

It won’t do much good to have users in Group 1 reset their passwords if they’re allowed to change the password to something simple. Be sure to first check the IAM Password Policy for the account and check all the applicable boxes per your organization’s password policy.

如果允许第1组中的用户将密码更改为简单的密码，那将无济于事。 确保首先检查帐户的IAM密码策略，然后根据组织的密码策略选中所有适用的框。

You can tell how many days an employee has worked at a company by dividing the reset period by the last digit of their password. 您可以通过将重置期除以密码的最后一位数字来判断员工在公司工作了多少天。

Contacting Users

联系用户

For our Group 1 users, work with them to ensure:

对于第1组用户，请与他们合作以确保：

• Passwords that have not been reset within the expiration period are reset.
  在有效期内未重置的密码将被重置。
• MFA is enabled for their account.
  他们的帐户已启用MFA。
• Their attached IAM policies are necessary for their job function. Use groups to manage this access where possible.
  他们附加的IAM策略对于他们的工作职能必不可少。 尽可能使用组来管理此访问。

Tracking Down Access Keys

跟踪访问键

For Group 2 users, the hard part will be tracking down where the scripts are running. Fortunately, CloudTrail contains a wealth of information, including origin IP address, user agent headers, and other details that can be used to locate the user. When all else fails, you can always try doing a search of your organization’s GitHub installation in ̶h̶o̶p̶e̶s̶ fear the key has been committed there.

对于第2组用户，最困难的部分是跟踪脚本的运行位置。 幸运的是，CloudTrail包含大量信息，包括原始IP地址，用户代理标头以及可用于定位用户的其他详细信息。 如果所有其他方法都失败了，您可以随时尝试在组织中搜索组织的GitHub安装，因为担心密钥已提交到那里。

For Group 3 users, the goal is to transition them to using IAM roles, deprecate the access keys, and delete the users. This may be easier said than done, especially if these are legacy applications with no automated deployment process.

对于第3组用户，目标是将其转换为使用IAM角色，弃用访问密钥并删除用户。 说起来容易做起来难，尤其是如果这些是没有自动部署过程的旧应用程序时。

When all else fails, if the keys cannot be deleted, the next best option is scope their policies to just the services they need access to. Again, this isn’t an easy task, but there are tools that can help:

当所有其他方法均失败时，如果无法删除密钥，则下一个最佳选择是将其策略范围限制在仅需要访问的服务范围内。 同样，这不是一件容易的事，但是有些工具可以帮助您：

1. Use the “Access Advisor” tool in IAM to see if the policies being granted to the user are actually being used.

   使用IAM中的“ Access Advisor ”工具查看授予用户的策略是否正在实际使用中。

2. Use CloudTrail to see specific API calls, source data, and other details to determine if all permissions are necessary.
   使用CloudTrail查看特定的API调用，源数据和其他详细信息，以确定是否需要所有权限。

By now, you should be left with a more organized IAM environment, much more tightly-scoped IAM policies, and a properly configured account password policy so that humans can login (with passwords and MFA) and machines can access the necessary APIs (with access keys).

到现在为止，您应该拥有一个井井有条的IAM环境，更严格的IAM策略以及正确配置的帐户密码策略，以便用户可以登录(使用密码和MFA)，并且计算机可以访问必要的API(通过访问键)。

Note: Many organizations use Single Sign On internally, which is a more ideal method of configuring AWS access than password-based login for a variety of reasons, including user provisioning and deprecation. If SSO can be used, I recommend setting that up and transitioning your IAM users if possible.

注意：许多组织在内部使用Single Sign On，由于多种原因(包括用户供应和弃用)，这是一种比基于密码的登录更理想的配置AWS访问的方法。 如果可以使用SSO，建议您进行设置并转换IAM用户(如果可能)。

步骤6：找到公开的服务 (Step 6: Locate Exposed Services)

Aside from improperly-configured IAM users, your biggest security risk at this stage is likely to be services that are improperly configured to allow traffic from public endpoints. This includes:

除了配置不正确的IAM用户之外，在此阶段，您最大的安全风险很可能是服务配置不当，不允许来自公共端点的流量。 这包括：

• S3 Buckets set to allow public access
  S3存储桶设置为允许公众访问
• EC2 and RDS instances and ELB/ALB/NLBs in public subnets with security groups allowing traffic from 0.0.0.0/0.
  具有安全组的公共子网中的EC2和RDS实例以及ELB / ALB / NLB，允许流量从0.0.0.0/0开始。
• ElastiCache instances configured with public access enabled, especially if a password is not set.
  配置了启用了公共访问的ElastiCache实例，尤其是在未设置密码的情况下。
• EBS volumes, RDS backups, AMIs, and other storage backups that are shared with large numbers of accounts.
  与大量帐户共享的EBS卷，RDS备份，AMI和其他存储备份。
• KMS keys, SNS topics, SQS queues, and other services configured with global or cross-account access.
  KMS密钥，SNS主题，SQS队列和其他配置了全局或跨帐户访问权限的服务。

There isn’t enough storage space on Medium to walk through the detailed steps of fixing all of these issues, but the goal at this point is to plug the most egregious gaps. There are a number of open source auditing tools that can be used to quickly discover at-risk resources, but your biggest objectives should be:

Medium上没有足够的存储空间来逐步解决所有这些问题的详细步骤，但是目前的目标是弥补最严重的差距。 有许多开源审计工具可用于快速发现有风险的资源，但是您的最大目标应该是：

• Closing ports and security group rules that are exposed publicly. You can use VPC Flow Logs (be careful, they can get expensive) to determine usage prior to closing ports.
  关闭公开公开的端口和安全组规则。 您可以在关闭端口之前使用VPC流日志(请注意，它们可能会变得昂贵)来确定使用情况。
• Locating S3 buckets that have insecure ACLs and/or bucket policies that allow public or global access. This will keep you out of the news; it’s important to do this quickly. Determining whether the bucket should have this access set will require you to consult with project owners and utilize S3 bucket access logs or CloudTrail S3 Object Logging to evaluate current usage requirements. You can also look into Amazon Macie, but be prepared to take out a reverse mortgage on your company’s fancy new office in SoMa.
  查找具有不安全的ACL和/或允许公共或全局访问的存储桶策略的S3存储桶。 这将使您远离新闻。 快速执行此操作很重要。 确定存储桶是否应具有此访问权限设置将要求您咨询项目所有者，并利用S3存储桶访问日志或CloudTrail S3对象日志记录来评估当前的使用要求。 您也可以研究Amazon Macie，但准备对公司位于SoMa的高档新办公室进行抵押贷款。
• Removing wildcards in access policies for AMIs, EBS backups, and other objects. This is a medium-risk activity; public access is almost certainly not required for a production application, but cross-account access can be a valid use case, so turning a “*” into an account ID may prove difficult.
  在AMI，EBS备份和其他对象的访问策略中删除通配符。 这是中等风险的活动； 生产应用程序几乎不需要公共访问，但是跨帐户访问可能是有效的用例，因此将“ *”转换为帐户ID可能会很困难。
• In places where making changes could introduce downtime or you have a gut feeling that wildcard in an SNS policy is all that’s keeping your company’s multi-million dollar ERP system from biting the dust, the second-best option is to configure CloudWatch metrics based on CloudTrail logs to monitor for unintended access. Over time, you should get a better sense of what’s required and what can be removed.
  在进行更改可能会导致停机的地方，或者您直觉认为SNS策略中的通配符可以阻止您公司数百万美元的ERP系统尘埃落定，第二好的选择是基于CloudTrail配置CloudWatch指标日志以监视意外访问。 随着时间的流逝，您应该对所需的内容和可以删除的内容有了更好的了解。

第7步：锁定域 (Step 7: Lock Down Your Domains)

Domains are the lifeblood of your organization’s applications and brand. If someone transfers that domain out of your Route53, a bad time is going to be had by everyone. In this step, your goals are to:

域是组织应用程序和品牌的生命线。 如果有人将那个域从您的Route53中转移出去，那么每个人都会度过一段糟糕的时光。 在此步骤中，您的目标是：

1. Configure transfer locks on all of your supported domains.
   在所有受支持的域上配置传输锁定。
2. Remove domains that may be pointing to non-existent resources.
   删除可能指向不存在的资源的域。
3. Update technical details and contacts.
   更新技术细节和联系方式。
4. Configure domains to auto-renew.
   配置域以自动更新。

Domain Settings

域设置

Enabling transfer locks will be an easy and non-destructive process. You can do this quickly via the Route53 console. The same is true for enabling auto-renewal.

启用传输锁将是一个简单且无损的过程。 您可以通过Route53控制台快速完成此操作。 启用自动更新也是如此。

Changing the technical and administrative contacts will be more time-consuming but is also a non-breaking change. Just be sure to use an email you have access to and that can receive email from outside sources so you can confirm the ownership.

更改技术和管理联系将更加耗时，但这也是一项不间断的更改。 只需确保使用您有权访问的电子邮件，并且该电子邮件可以接收来自外部来源的电子邮件，以便您可以确认所有权。

If the domain is registered outside of Route53, you’ll need to track down the registrar and apply the changes there. If you’re up for a challenge, you can transfer the domains into Route53, but that is much more likely to lead to downtime if a mistake is made.

如果该域名是在Route53之外注册的，则需要跟踪该注册商并在此处应用更改。 如果您面临挑战，则可以将域转移到Route53中，但是如果出错，则很有可能导致停机。

Domain Takeover via Unclaimed Resources

通过无人认领的资源进行域接管

For domains that have records in Route53 pointing to S3 buckets, it is very important that you audit these records to ensure the bucket actually still exists. There is a very clever attack known as subdomain takeover, in which an attacker can take advantage of the global namespace in which S3 buckets operate to point your subdomain to a bucket they own.

对于在Route53中具有指向S3存储桶的记录的域，审核这些记录以确保存储桶实际上仍然存在非常重要。 有一种非常聪明的攻击称为子域接管， 攻击者可以利用全局命名空间来利用全局命名空间，在该命名空间中，S3存储桶将您的子域指向他们拥有的存储桶 。

You should take this opportunity to audit all domain records to ensure they are still in use and pointing to valid resources or endpoints.

您应该借此机会审核所有域记录，以确保它们仍在使用中并指向有效的资源或端点。

步骤8：查找过期证书 (Step 8: Find Expiring Certificates)

AWS hides TLS certificates in two places:

AWS在两个位置隐藏TLS证书：

1. AWS ACM — a managed certificate service with its own dashboard in which certificates can be provisioned, renewed, and monitored.
   AWS ACM —具有自己的仪表板的托管证书服务，可以在其中配置，更新和监视证书。
2. AWS IAM — an identity service with no UI option for locating available certificates.
   AWS IAM —一种身份服务，不带用于选择可用证书的UI选项。

Your challenge is to locate, rotate, and associate:

您面临的挑战是定位，旋转和关联：

1. Locate all certificates that are currently in use. I recommend using the APIs, including the list-server-certificates API call.

   找到当前正在使用的所有证书。 我建议使用API​​，包括list-server-certificates API调用 。

2. Rotate expiring certificates.
   轮换到期证书。
3. Associate that the new certificate with the correct EC2 instance, CloudFront distribution, AWS API Gateway, ELB, or other resource fronting the endpoint.
   将该新证书与正确的EC2实例，CloudFront分布，AWS API网关，ELB或其他位于端点的资源相关联。

步骤9：解开服务网络 (Step 9: Untangle The Web of Services)

At this stage, we’ve avoided breaking things for as long as possible and done almost all we can without getting our hands too dirty. It’s time to start mapping existing running applications, shutting down unused services, and untangling the web of servers with names like “donotdeleteever.” Mistakes may be made.

在这个阶段，我们避免了尽可能长的时间弄坏东西，并且在不弄脏双手的情况下竭尽所能。 现在该开始映射现有的正在运行的应用程序，关闭未使用的服务，并使用诸如“ donotdeleteever”之类的名称来纠缠服务器网络。 可能会犯错误。

There is really no ideal way to go about this process, but I generally like to do the following:

确实没有进行此过程的理想方法，但我通常喜欢执行以下操作：

1. Check every region for usage. Sometimes developers like to play cruel games of hide-and-seek by launching a c5d.24xlarge EC2 instance that costs $4.608 per hour in unused regions. If you discover resources like this, use CloudTrail, VPC Flow Logs, and CloudWatch metrics to determine whether they are in use. Once you’re confident, temporarily disable the resource by, for example, blocking network traffic to it. This gives you a good way to quickly restore access if you see a developer across the office immediately stand up and flip a desk.
   检查每个地区的使用情况。 有时，开发人员喜欢通过启动c5d.24xlarge EC2实例来玩残酷的捉迷藏游戏，该实例在未使用区域的费用为每小时$ 4.608。 如果发现这样的资源，请使用CloudTrail，VPC流日志和CloudWatch指标来确定它们是否正在使用。 确信后，可以通过例如阻止网络流量暂时禁用该资源。 如果您看到办公室内的开发人员立即站起来并翻转桌子，这将为您提供一种快速恢复访问的好方法。
2. Use open source tools to map relationships between VPCs, security groups, NACLs, and other networking resources. If you are able to clean out a VPC, delete it and its sub-resources (e.g. default security group) to avoid future use.
   使用开源工具来映射VPC，安全组，NACL和其他网络资源之间的关系。 如果您可以清理VPC，请删除该VPC及其子资源(例如，默认安全组)，以避免将来使用。
3. Start adding tags to resources to help you identify relationships in the future.
   开始向资源添加标签，以帮助您将来确定关系。
4. Develop (or adopt) a naming convention for resources and rename ones you can.
   开发(或采用)资源的命名约定并重命名资源。

5. Check for potentially-compromised secrets. These include:

   检查潜在的泄露机密。 这些包括：

   - CloudFormation parameter defaults

   -CloudFormation参数默认值

   - Unencrypted Lambda environment variables

   -未加密的Lambda环境变量

   - EC2 instance data scripts with hardcoded secrets

   -具有硬编码机密的EC2实例数据脚本

   - ECS task definitions with exposed environment variables

   -具有公开环境变量的ECS任务定义

   - Sensitive files on S3

   -S3上的敏感文件

   - GitHub/code repositories at your organization that may contain committed access keys belonging to the AWS account.

   -您组织中的GitHub /代码存储库，其中可能包含属于AWS账户的已提交访问密钥。

6. Locate potentially-compromised resources, such as EC2 instances, by looking at usage patterns. If that Windows Server 2008 box is sitting at 98% CPU utilization for 24 hours a day, chances are it could be mining cryptocurrency.
   通过查看使用模式，找到可能受损的资源，例如EC2实例。 如果该Windows Server 2008机器每天24小时处于98％的CPU利用率，则很可能是在挖掘加密货币。

7. Take inventory of everything. This is time consuming, but if you don’t know what’s running on a normal day, how will you know what shouldn’t be running the next? I’m a fan of NCC Group’s AWS Inventory tool.

   盘点一切 。 这很耗时，但是如果您不知道平日的运行情况，您怎么知道下一天不应该运行什么？ 我是NCC Group的AWS Inventory工具的粉丝。

8. Stop all new development, if possible. If developers are continuing to deploy new services, before a proper security policy is in place, it’s a recipe for disaster. Set them up with a properly configured new account and shift development there. Use VPC peering and other cross-account functionality if they need access to services in the existing account.
   如果可能，请停止所有新开发。 如果开发人员继续部署新服务，那么在适当的安全策略到位之前，这就是灾难的根源。 使用正确配置的新帐户设置它们，然后将开发转移到那里。 如果他们需要访问现有帐户中的服务，请使用VPC对等和其他跨帐户功能。

步骤10：监视和迁移 (Step 10: Monitor and Migrate)

It’s important to recognize that you may never get this account into a “perfect” state. As I mentioned at the beginning of this article, there is no substitute for a brand new AWS account, provisioned from scratch to adhere to your organization’s security policies. Your goal should now be to migrate or deprecate services in this account as quickly as possible, with the eventual goal of full termination. This could be a multi-year effort.

重要的是要认识到，您可能永远无法使此帐户进入“完美”状态。 正如我在本文开头提到的，没有什么可以替代一个全新的AWS账户，它是从头开始配置的，以遵守组织的安全策略。 现在，您的目标应该是尽快迁移或弃用该帐户中的服务，最终目标是完全终止。 这可能是多年的努力。

For services that need to remain, monitoring will be key. If you can shift a majority of users and services to new accounts, this will reduce the attack surface and help protect your data. CloudTrail, with proper alerts, will help ensure that any unintended activity is quickly detected.

对于需要保留的服务，监视将是关键。 如果您可以将大多数用户和服务转移到新帐户，这将减少攻击面并帮助保护您的数据。 CloudTrail带有适当的警报，将有助于确保快速检测到任何意外活动。

Being told you are now responsible for an account full of hundreds of legacy applications can be incredibly daunting. But hopefully, using the steps outlined here, you can begin to isolate and correct the worst security risks while containing and monitoring the rest. It’s not a substitute for an account that has been properly configured from the ground up, but what’s the alternative? Nuking the account and walking into the sunset?

有人告诉您，现在对一个拥有数百个旧应用程序的帐户负责可能令人生畏。 但希望使用此处概述的步骤，您可以开始隔离并纠正最严重的安全风险，同时控制和监视其余风险。 它不能替代从头开始正确配置的帐户，但是有什么替代方法呢？ 裸体账户，走进日落？

If you liked this article, please subscribe to my mailing list for updates or follow me on Twitter.

如果您喜欢本文，请 订阅我的邮件列表 以获取更新，或 在Twitter上关注我 。

翻译自: https://medium.com/swlh/so-you-inherited-an-aws-account-e5fe6550607d

aws root账户