Webcast: AWS account setup tips for audit, governance, and security

AWS Account, Spend, and Audit Best

Practices

Ed Lee Saradhi Sreegiriraju

Feb 23 2017 @ 10:05 PSTVOIP or Dial-in (see chat)

Questions? Hit the GTW chat or @applatix

May 3, 2023 2AWS Account, Spend, and Audit Best Practices

Who are we?

Ed Lee Founder &

CTO

Saradhi SreegirirajuFounder & CPO


Agenda

•AWS account & user management

• Spend monitoring & analysis

•Audit & governance

AWS Account Management


AWS account structure

AWS “Main” account

“Root User” for main account


First things first – protect ‘Root User’ account

•Root User Account is the most important accountCannot be deletedAccess cannot be limited using roles

•Best PracticesActivate MFA for the Root User accountDo not create access keys for the Root User accountDon’t use your Root User account unless specifically needed

oInstead, create separate admin user accounts


Secure your “Main” AWS account

• Restrict use of the “Main” AWS account Use it primarily for user management, consolidated billing and

access control Activate MFA for all user accounts with any significant privilege


Use ”sub” accounts for actual work

AWS “dev” account

“Root User” for dev account

AWS “qa” account

“Root User” for qa account

AWS “prod” account

“Root User” for prod account




AWS Identity & Access Management (IAM)

IAM Users Groups Policies

Roles Policies

Policies Roles“Assume”


Mapping IAM Users, Groups, and Policies






“Root User” for prod account

User Group PolicyMary Kome admin dev-adminBob Adams admin prod-adminJoe Smith quality qa-user

IAM Users, Groups, and PoliciesDefine all IAM Users in “Main” account




User Group PolicyMary Kome admin dev-adminBob Adams admin prod-adminJoe Smith quality qa-admin

Mapping IAM Users, Groups, and Policies






“Root User” for prod accountRolesdev-admin-role Roles

prod-admin-role

Define all IAM Users in “Main” account



IAM Users, Groups, and Policies


AWS console access to sub accounts• Create policies to grant access to sub accounts from main

account

Example policy to allow cross-account role switching from main account{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::xxx-account1-xxx:role/dev-role" }}


AWS console access to sub accounts

• Users log into main account and then “switch” to sub accounts where they do their actual work

• Require MFA to switch roles (a good way to force users to use MFA)

• Use policies to govern which users can switch to which accounts


API access to sub accounts

• Create access keys only for main user accounts• Control API access to sub AWS accounts using roles and policies• Use policies to govern which users can make API calls to which AWS

accounts using which roles• Specify an external_id => role cannot be used from the console

[profile dev-account]source_profile = main-accountrole_arn = arn:aws:iam::<xxx>-dev-account-id-<xxx>:role/dev-api-accessexternal_id = <yyy>


Not so good alternatives

• One account for everything Lack of project-level visibility and accountability Lack of isolation between projects

oProjects members will be stepping on each other’s toeso Some important AWS resource limits are per account and cannot be

increased

• Every user has a user account & access key on every account Impossible to keep track of who has access to what Greater likelihood a user will “leak” or lose track of their passwords

or access keys


User Group PolicyMary Kome admin dev-adminBob Adams admin prod-adminJoe Smith quality qa-admin

In summary






“Root User” for prod accountRolesdev-admin-role Roles

prod-admin-role

Define all IAM Users in “Main” account



IAM Users, Groups, and Policies

Spend Monitoring & Analysis


Monitor your spending

• Regularly monitor spending and investigate changes in spending

• Use AWS Cost Explorer (or third party applications/services) It’s free! Provides useful information related to Reserved Instances Does not provide hourly granularity Does not break out enough items Limited usefulness in categorizing spending


Example AWS cost explorer report


Enable AWS cost and usage reports• Enable consolidated billing report on main account

Choose hourly granularity Enable resource ids (useful for analyzing RI usage)


Enable AWS cost and usage reports


Use the new AWS cost and usage reports• Two types of billing report formats

Detailed billing reports – old formatAWS cost & usage reports – new formatMainly differ in how RI usage is reported

•Best practice: AWS recommends using the new format


Tag your resources

• Choose a scheme for tagging your resourcesUser, project, application etc.

• Enable the tags you want in your billing reports

• Allows you to group spending by tagsVery useful for analyzing and allocating costs

• Challenge is to systematically tag your resourcesAutomation may be required


Limitations of AWS billing reports

• Even at hourly granularity, report is generated twice a day

• 2-3 day delay for the last day of the month

• Daily S3 usage is attributed to a particular hour in the day

• The upfront payments for RIs are not amortized


Claudia – Free AWS cost management


Application granular resource usage metrics

Audit & Governance


Enable logs for Audit and Governance• Enable Cloud Trail on all accounts (including sub-accounts)

Who did what when Also very useful when you hit API call limits


Use roles instead of access keys

• Keys can be leaked, roles cannot• Keys can be unknowingly shared• Roles can be revoked more easily

• If you must use keys Grant the minimum required permissions Do not share keys Use a separate key per user/entity

oBetter audit trailo Easier to revoke


Create a network map early• Helps you access your AWS infrastructure using private IP

addresses

• Create a CIDR map and avoid overlapping network addresses for subnets that you want to route to Having this in place early will save you time and effort later

• VPC peering is a convenient way to route between accounts Management can be difficult VPCs must be in the same region


Regularly check for security exposures• Security groups open to the Internet

E.g. Ports open to 0.0.0.0/0

• Log incoming connections Useful for analyzing potential threats and for forensics in the event of a break in

• Log outgoing connections Useful for detecting a break in A compromised instance is often used to attack other systems (DDoS, port scans)

• Use software for regular vulnerability scanning & testing Often requires pre-approval from AWS

• Carefully design and configure any Internet facing services


Key Takeaways• Setting up proper account management is critical

• Enable consolidated billing and reporting for tracking use

• Create network maps from the get go and keep them updated

• Enable audit logging and regularly perform security checks


Thank you!

• For more resources see http://applatix.com/resources

• Feedback? Questions? [email protected] or @applatix

• Our next Webinar March 16th, 2017 Cloud Management and Spend Analysis

http://applatix.com/resources

mailto:[email protected]

Thank you

Webcast: AWS account setup tips for audit, governance, and security

Technology

Transcript of Webcast: AWS account setup tips for audit, governance, and security