(SEC302) IAM Best Practices To Live By

© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

IAM Best Practices to Live By

SEC302

Anders Samuelsson, Principal Technical Program Manager,

AWS Identity and Access Management

October 2015

What to expect from this session

We will look at:

• Best practices – To help you get started

• Versus – When to use one technology over another

• Demos – “Show and tell”

AWS Identity and Access Management (IAM)

Enables you to control who can do what in your AWS account



Users, groups, roles, and permissions




Control

– Centralized

– Fine-grained - APIs, resources, and AWS Management Console




Control

– Centralized

– Fine-grained - APIs, resources, and AWS Management Console

Security

– Secure (deny) by default

– Multiple users, individual security credentials and permissions

IAM Best Practices

• Basic user and permission management

• Credential management

• Delegation

Basic user and permission management

0. Create individual users. Benefits

• Unique credentials

• Individual credential rotation

• Individual permissions


0. Create individual users.

1. Grant least privilege.

Benefits

• Less chance of people making

mistakes

• Easier to relax than tighten up

• More granular control




2. Manage permissions with groups.

Benefits

• Easier to assign the same

permissions to multiple users

• Simpler to reassign permissions

based on change in

responsibilities

• Only one change to update

permissions for multiple users





3. Restrict privileged access further with conditions.

Benefits

• Additional granularity when

defining permissions

• Can be enabled for any AWS

service API

• Minimizes chances of

accidentally performing

privileged actions





3. Restrict privileged access further with conditions.

4. Enable AWS CloudTrail to get logs of API calls.

Benefits

• Visibility into your user activity by

recording AWS API calls to an

Amazon S3 bucket

Credential management

5. Configure a strong password policy. Benefits

• Ensures your users and your

data are protected


5. Configure a strong password policy.

6. Rotate security credentials regularly.

Benefits

• Normal best practice


5. Configure a strong password policy.

6. Rotate security credentials regularly.

7. Enable MFA for privileged users.

Benefits

• Supplements user name and

password to require a one-time

code during authentication

Delegation

8. Use IAM roles to share access. Benefits

• No need to share security

credentials

• No need to store long-term

credentials

• Use cases

- Cross-account access

- Intra-account delegation

- Federation

Delegation

8. Use IAM roles to share access.

9. Use IAM roles for Amazon EC2 instances.

Benefits

• Easy to manage access keys on

EC2 instances

• Automatic key rotation

• Assign least privilege to the

application

• AWS SDKs fully integrated

• AWS CLI fully integrated

Delegation

8. Use IAM roles to share access.

9. Use IAM roles for Amazon EC2 instances.

10. Reduce or remove use of root.

Benefits

• Reduce potential for misuse of

credentials

Top 11 IAM best practices

0. Users – Create individual users.

1. Permissions – Grant least privilege.

2. Groups – Manage permissions with groups.

3. Conditions – Restrict privileged access further with conditions.

4. Auditing – Enable AWS CloudTrail to get logs of API calls.

5. Password – Configure a strong password policy.

6. Rotate – Rotate security credentials regularly.

7. MFA – Enable MFA for privileged users.

8. Sharing – Use IAM roles to share access.

9. Roles – Use IAM roles for Amazon EC2 instances.

10. Root – Reduce or remove use of root.

Versus – When should I use…?

AWS access keys vs. passwords

IAM users vs. federated users

• Depends on where you want to manage your users

– On-premises → Federated users (IAM roles)

– In your AWS account → IAM users





• Other important use cases

– Delegating access to your account → Federated users (IAM roles)

– Mobile application access → Should always be federated access





• Other important use cases

– Delegating access to your account → Federated users (IAM roles)

– Mobile application access → Should always be federated access

IMPORTANT: Never share security credentials.

[email protected] ID: [email protected]

Acct ID: 123456789012

How does federated access work?

IAM user: Anders

STS

[email protected] ID: 111122223333

ddb-role



IAM user: Anders

STS


ddb-role


{ "Statement": [{"Effect":"Allow","Principal":{"AWS":"123456789012"},"Action":"sts:AssumeRole"

}]}


ddb-role trusts IAM users from the AWS account

[email protected] (123456789012)

IAM user: Anders

STS


ddb-role

{ "Statement": [{ "Action":

["dynamodb:GetItem","dynamodb:BatchGetItem","dynamodb:DescribeTable","dynamodb:ListTables"

],"Effect": "Allow","Resource": "*“

}]}



}]}




IAM user: Anders

Permissions assigned to ddb-role

STS


ddb-role




}]}


{ "Statement": [{"Effect": "Allow","Action": "sts:AssumeRole","Resource": "arn:aws:iam::111122223333:role/ddb-role"

}]}


}]}




Permissions assigned

to Anders granting him

permission to assume

ddb-role in account B

IAM user: Anders


STS


ddb-role




}]}


Authenticate with

Anders’ access keys


}]}


}]}








IAM user: Anders


STS


ddb-role




}]}


Authenticate with


Get temporary

security credentials

for ddb-role


}]}


}]}








IAM user: Anders


STS


ddb-role




}]}


Authenticate with


Get temporary


for ddb-role

Call AWS APIs

using temporary


of ddb-role


}]}


}]}








IAM user: Anders


STS


• Depends on how your users will access AWS

– Console → Password

– API, CLI, SDK → Access keys


• Depends on how your users will access AWS

– Console → Password

– API, CLI, SDK → Access keys

• In either case make sure to rotate credentials regularly

– Use Credential Report to audit credential rotation.

– Configure password policy.

– Configure policy to allow access key rotation.

Enabling credential rotation for IAM users

(Enable access key rotation sample policy)

Access keys

{"Version":"2012-10-17","Statement": [{"Effect": "Allow","Action": [

"iam:CreateAccessKey","iam:DeleteAccessKey","iam:ListAccessKeys","iam:UpdateAccessKey"],

"Resource": "arn:aws:iam::123456789012:

user/${aws:username}"}]}

Enabling credential rotation for IAM users

(Enable access key rotation sample policy)

Access keys

{"Version":"2012-10-17","Statement": [{"Effect": "Allow","Action": [

"iam:CreateAccessKey","iam:DeleteAccessKey","iam:ListAccessKeys","iam:UpdateAccessKey"],

"Resource": "arn:aws:iam::123456789012:

user/${aws:username}"}]}

1. While the first set of credentials is still active, create a second set of credentials, which will also be active by default.

2. Update all applications to use the new credentials.

3. Change the state of the first set of credentials to Inactive.

4. Using only the new credentials, confirm that your applications are working well.

5. Delete the first set of credentials.

Steps to rotate access keys

Show and Tell

Inline policies vs. managed policies

• Use inline policies when you need to:

– Enforce a strict one-to-one relationship between policy and principal.

– Avoid the wrong policy being attached to a principal.

– Ensure the policy is deleted when deleting the principal.

Inline policies vs. managed policies

• Use inline policies when you need to:

– Enforce a strict one-to-one relationship between policy and principal.

– Avoid the wrong policy being attached to a principal.

– Ensure the policy is deleted when deleting the principal.

• Use managed policies when you need:

– Reusability.

– Central change management.

– Versioning and rollback.

– Delegation of permissions management.

– Automatic updates for AWS managed policies.

– Larger policy size.

Groups vs. managed policies

• Provide similar benefits

– Can be used to assign the same permission to many users.

– Central location to manage permissions.

– Policy updates affect multiple users.






• Use groups when you need to

– Logically group and manage users .






• Use groups when you need to

– Logically group and manage users .

• Use managed policies when you need to

– Assign the same policy to users, groups, and roles.

Combine the power of groups AND managed policies

• Use groups to organize your users into logical clusters.

• Attach managed policies to those groups with the permissions those groups

need.

• Pro tip: Create managed policies based on logically separated permissions

such as AWS service or project, and attach managed policies mix-and-

match style to your groups.

Show and Tell

Resource-specific policy vs. tag-based access control

• Use resource-specific policy when you need to:

• Control access to a specific resource.

• Control access to most AWS service resources.





• Use tag-based access control when you need to:

• Treat resources as a unit, such as a project.

• Automatically enforce permissions when new resources are created.





• Use tag-based access control when you need to:

• Treat resources as a unit, such as a project.

• Automatically enforce permissions when new resources are created.

NOTE: The following services currently support tag-based access control:

Amazon EC2, Amazon VPC, Amazon EBS, Amazon RDS, Amazon Simple

Workflow Service, and AWS Data Pipeline

How does tag-based access control work?

{"Version": "2012-10-17","Statement": [{

"Effect": "Allow","Action": "ec2:*","Resource": "*","Condition": {

"StringEquals": {"ec2:ResourceTag/Project" : "Blue"

}}

}]

}

Permissions assigned to Anders granting him permission

to perform any EC2 action on resources tagged with

Project=Blue

IAM user: Anders





}}

}]

}



Project=Blue

IAM user: Anders

i-a1234b12Project=Blue





}}

}]

}



Project=Blue

IAM user: Anders






}}

}]

}



Project=Blue

IAM user: Anders







}}

}]

}



Project=Blue

IAM user: Anders

i-a1234b12

i-a4321b12

Project=Blue





}}

}]

}



Project=Blue

IAM user: Anders

i-a1234b12

i-a4321b12

Project=Blue





}}

}]

}



Project=Blue

IAM user: Anders

i-a1234b12

i-a4321b12

Project=Blue

i-a4321b12Project=Green

Show and Tell

One AWS account vs. multiple AWS accounts?

Use a single AWS account when you:

• Want simpler control of who does what in your AWS environment.

• Have no need to isolate projects/products/teams.

• Have no need for breaking up the cost.

One AWS account vs. multiple AWS accounts?

Use a single AWS account when you:

• Want simpler control of who does what in your AWS environment.

• Have no need to isolate projects/products/teams.

• Have no need for breaking up the cost.

Use multiple AWS accounts when you:

• Need full isolation between projects/teams/environments.

• Want to isolate recovery data and/or auditing data (e.g., writing your

CloudTrail logs to a different account).

• Need a single bill, but want to break out the cost and usage.

Cross-account access with IAM roles




IAM user: Anders





IAM user: Anders





IAM user: Anders





IAM user: Anders





IAM user: Anders





IAM user: Anders





IAM user: Anders


External identity

provider





IAM user: Anders

IAM user: Bob


External identity

provider





IAM user: Anders

IAM user: Bob

Show and Tell

What did we cover?

1. Top 1011 best practices.

2. IAM users vs. federated users.

3. Access keys vs. passwords.

4. Inline policies vs. managed policies.

5. Groups vs. managed policies.

6. Resource-specific policy vs. tag-based access control.

7. One AWS account vs. multiple AWS accounts.

X

Related sessions

Session Title When Where

SEC305 How to Become an IAM Policy Ninja in 60

Minutes or Less

Thursday, 10/8,

11:00 A.M.–Noon

Palazzo K

SEC307 A Progressive Journey Through AWS IAM

Federation Options: From Roles to SAML to

Custom Identity Brokers

Thursday, 10/8,

1:30–2:30 P.M.

Marcello 4501B

Remember to complete

your evaluations!

Thank you!

Technology

(SEC302) IAM Best Practices To Live By