Inherited AWS Account

Sources

  • 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

  • Similar posts:

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 0.0.0.0/0
    • 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