Inherited AWS Account


This page is a summary of So You Inherited an AWS Account:

  • 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
Step Description
Step 1 Get Stable Access
  • Confirm access to the account and embed our own user to avoid losing access:
    • Log in with the email and password provided to determine if you're using the root account
    • If the credentials are not the root credentials, contact AWS support to regain that access
    • Change the root credentials immediately
    • If SSO is not currently setup, create a new IAM user and add the Administrator managed IAM policy to it
    • Enable MFA for your new user
Step 2 Stop Using the Root User
  • Log in as the root user
  • Determine if anyone/anything is using the root account, by checking the root user's security credentials
  • If you find keys that have not been used in a reasonable timeframe, delete them
  • Enable MFA on the root user account. Take a screenshot of the QR code key material and save it to Vault
Step 3 Update Billing Information
  • 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 billing must be handled through the Organization, you'll need to discuss adding the account to the Organization
Step 4 Enable CloudTrail Logging and Monitoring
  • Open the CloudTrail console and determine if an existing trail is configured
    • If it is, 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
  • Enable CloudTrail's encryption at-rest and file validation
  • Setup basic alerts for critical security activity within the account (CloudTrail and IAM changes at a minimum)
  • Other security services: Security Hub, GuardDuty, Config, Macie, Inspector, Detective
Step 5 Cleanup IAM Entities
  • Cleanup users that have not been used in awhile:
    • Download the IAM Credential Report for your account
    • Start with the easiest users to delete: those who have neither a password nor access keys or attached certificates
    • Next, tackle users that do not have passwords but may have access keys used sufficiently long ago
    • Next, tackle users who don't have access keys, but do have passwords used sufficiently long ago
  • For users who need console access:
    • First check the IAM Password Policy for the account and check all the applicable boxes per your organization’s password policy
    • Ensure passwords that have not been reset within the expiration period are reset
    • MFA is enabled for their account
    • Their attached IAM policies are necessary for their job function
  • Track Down Access Keys:
    • For scripts, tracking down where the scripts are running
    • For users, the goal is to transition them to using IAM roles, deprecate the access keys, and delete the users:
      • If the keys cannot be deleted, the next best option is scope their policies to just the services they need access to
      • Use Access Advisor to see if the policies being granted to the user are actually being used
      • Use CloudTrail to see specific API calls, source data, and other details to determine if all permissions are necessary
Step 6 Locate Exposed Services
  • Check services that are improperly configured to allow traffic from public endpoints:
    • S3 Buckets set to allow public access
    • EC2 and RDS instances and ELB/ALB/NLBs in public subnets with security groups allowing traffic from
    • ElastiCache instances configured with public access enabled, especially if a password is not set
    • EBS volumes, RDS backups, AMIs, and other storage backups that are shared with large numbers of accounts
    • KMS keys, SNS topics, SQS queues, and other services configured with global or cross-account access
  • Your biggest objectives should be:
    • Closing ports and security group rules that are exposed publicly
    • Locating S3 buckets that have insecure ACLs and/or bucket policies that allow public or global access
    • Removing wildcards in access policies for AMIs, EBS backups, and other objects
    • Configure CloudWatch metrics based on CloudTrail logs to monitor for unintended access
Step 7 Lock Down Your Domains
  • Configure transfer locks on all of your supported domains
  • Remove domains that may be pointing to non-existent resources
  • Update technical details and contacts
  • Configure domains to auto-renew
Step 8 Find Expiring Certificates
  • Locate all certificates that are currently in use
  • Rotate expiring certificates
  • Associate that the new certificate with the correct EC2 instance, CloudFront distribution, AWS API Gateway, ELB, or other resource fronting the endpoint
Step 9 Untangle The Web of Services
  • Check every region for usage
  • Map relationships between VPCs, security groups, NACLs, and other networking resources
  • Start adding tags to resources to help you identify relationships in the future
  • Develop (or adopt) a naming convention for resources and rename ones you can
  • Check for potentially-compromised secrets
  • Locate potentially-compromised resources, such as EC2 instances, by looking at usage patterns
  • Take inventory of everything
Step 10 Monitor and Migrate
  • Migrate or deprecate services in this account as quickly as possible, with the eventual goal of full termination
Back to top