AWS Account First Steps

For teams or individuals that are creating an AWS account at the UW there are some essential first steps that you should take.  This guide assumes your account is a DLT account and that you have recieved an email from DLT saying your account is now ready for use.

1. Create a Billing Alert

Send an email to opscenter@dlt.com.  Provide your AWS account number and start with something simple like $50.  Once your monthly bill hits $50 you will get a notification.  Do this now because forgetting to do so can lead to overspending and not knowing for a few months until the actual bill arrives in your UW budget.

2. Enable AWS Cloud Trail

Immediately upon recieving root credentials and on your very first login you MUST enable Cloud Trail for every region.  Simply use the search at the top of the console and enable it using the UI it provides.  Cloud Trail logs every AWS API call, so all actions done in the AWS console will be logged.  You are dead in the water if ever having to deal with an incident response (security breach, account comprise etc) with Cloud Trail disabled.  Cloud Trail is your audit log for all activities done by those whom are granted access.

3. Enable MFA on the Root Account

You goal should be to stop using the root account ASAP and enable MFA on the root account. 

• The AWS root account can NOT be UW SSO enabled.
• AWS hardware based MFA options are limited, please choose from a supported vendor.
• It is advised to purchase two of these for the root account, one will be a backup.
• Once UW SSO integration is completed in the steps below immediately change the root password to something more difficult and never use it again until your MFA authenticator arrives, and only then to register the device.
• There are rare exceptions where using the root account is required like billing console access and some Cloud Front security settings, so do document your root account setup.

4. Enable UW SSO and 2FA

You MUST enable UW SSO integration (with opt in 2FA) for AWS Console access vs. using AWS IAM users for AWS Console access.  As of May 2018, UW-IT IAM enabled opt in 2fa.  There is now no reason to continue the use of AWS IAM users for AWS Console activities for those UW people authorized for UW's 2FA service.  You now can have a comprehensive solution for Authentication and Authorization into the AWS Console and have that access control managed with UW Groups to AWS IAM Roles. 

• Please follow this guide for configuring UW SSO and 2fa at the UW for your AWS administrators.

5. Stop Using the Root Account

Once you have completed the above SSO with 2fa setup for your AWS account administrator(s) it's time to stop using the root account and create a stronger password for the root account.  It's also time to think strategicly about how you will use your AWS account.  There is no right or wrong architecture and this depends on your team size.

All Teams

• Set a strong password for the root account
• No longer use the root account and instead use the UW SSO integration described above
• Have a strategic discussion with your team about what services you need to enable in AWS and how to map UW Groups to least privleaged access in AWS via AWS IAM Roles and AWS IAM Policies.

6. Enable Role Based Access Control

Once you have had a conversation with your team about how your account will be used you should now expand your use of UW Groups and AWS IAM Roles.  The following are suggested practicies you may want to adopt.

Small Team Suggested Practice

• This is only advised for very small teams, 1-5 individuals.
• Create a UW Group u_weblogin_aws_[account id]_admin and add one or two netids to that group, possibly the actual admin and maybe the director of the team.
• Create a UW Group u_weblogin_aws_[account id]_developer and add the remaining team members, including the admins to this group.
• Enable the 2FA setting for these UW Groups
• Create matching AWS IAM Roles using the UW SSO guide.
• Attach the AWS IAM AdministratorAccess policy to the admin role.
• Attach addtional AWS IAM policies (AmazonS3FullAccess  for example) as needed to the developer role (requires logging into the console having the admin role to perform this action)

Large Team Concerns

You will want some governance around this from day 1.  It's very difficult to unwrap a complex structure of haphazardly built AWS IAM Roles, Policies, Groups and Users.  Think about who will need access to the IAM console and what actions they will need to perform.  For even larger deployments you may want to consider a multi account architecture to segment your environments (keep in mind DLT is the AWS Organization account for the UW vs. a UW entity or yourself being the Organization account).  Regardless, map AWS IAM Roles to UW Groups using the UW SSO guide.

Do you have an audit or security team?  If so, maybe a role for both of them will suffice and that role could have limited policies to Read everything but no privlages beyond that (write, delete etc).  Is there a developer team?  Maybe multiple developer teams? 

AWS IAM is a very robust feature and can have as granular role based access control as you want.  The key thing to remember is for AWS Console access and use, AWS documentation infers that those console actions are being performed by an AWS IAM User.  That is not the case if you have enabled UW SSO.  AWS Console access is actually granted to a UW SSO authenticated user and that user is given access based on the AWS IAM Policies attached to the mapped AWS IAM Role.  Ideally you would want to limit the use of AWS IAM Users to service accounts within or connecting to AWS.