Security Day IAM Recommended Practices

1. ©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved
IAM Recommended Practices
Dave Walker – Specialised Solutions Architect, Security and Compliance
Amazon Web Services UK Ltd
28/01/16

2. 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”

3. AWS Identity and Access Management (IAM)
Enables you to control who can do what in your AWS account

4. AWS Identity and Access Management (IAM)
Enables you to control who can do what in your AWS account
• Users, groups, roles, and permissions

5. AWS Identity and Access Management (IAM)
Enables you to control who can do what in your AWS account
• Users, groups, roles, and permissions
• Control
– Centralised
– Fine-grained - APIs, resources, and AWS Management Console

6. 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
• Security
– Secure (deny) by default
– Multiple users, individual security credentials and permissions

7. IAM Best Practices
• Basic user and permission management
• Credential management
• Delegation

8. Basic user and permission management
• 0. Create individual users. Benefits
• Unique credentials
• Individual credential rotation
• Individual permissions

9. Basic user and permission management
• 0. Create individual users.
1. Grant least privilege.
(and monitor permission usage with the IAM
console – revoke permissions if they haven’t
been used for some time period)
Benefits
• Less chance of people making
mistakes
• Easier to relax than tighten up
• More granular control

10. Basic user and permission management
• 0. Create individual users.
1. Grant least privilege.
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

11. Basic user and permission management
• 0. Create individual users.
1. Grant least privilege.
2. Manage permissions with groups.
3. Restrict privileged access further with conditions.
Benefits
• Additional granularity when
defining permissions
• Can be enabled for any AWS
service API
• Minimises chances of
accidentally performing privileged
actions

12. Basic user and permission management
• 0. Create individual users.
1. Grant least privilege.
2. Manage permissions with groups.
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

13. Credential management
5. Configure a strong password policy. Benefits
• Ensures your users and your
data are protected

14. Credential management
5. Configure a strong password policy.
6. Rotate security credentials regularly.
Benefits
• Normal best practice
• (often for compliance reasons)

15. Credential management
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

16. 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

17. 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

18. 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

19. 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.

20. Versus – When should I use…?
AWS access keys vs. passwords

22. 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

23. 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
– Draining PII from AWS / IAM → Federated users

24. 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
– Draining PII from AWS / IAM → Federated users
IMPORTANT: Never share security credentials.

25. prod@example.com
Acct ID: 111122223333dev@example.com
Acct ID: 123456789012
How does federated access work?
IAM user: Anders
STS

26. prod@example.com
Acct ID: 111122223333
ddb-role
dev@example.com
Acct ID: 123456789012
How does federated access work?
IAM user: Anders
STS

27. prod@example.com
Acct ID: 111122223333
ddb-role
dev@example.com
Acct ID: 123456789012
{ "Statement": [
{
"Effect":"Allow",
"Principal":{"AWS":"123456789012"},
"Action":"sts:AssumeRole"
}]}
How does federated access work?
ddb-role trusts IAM users from the AWS account
dev@example.com (123456789012)
IAM user: Anders
STS

28. prod@example.com
Acct ID: 111122223333
ddb-role
{ "Statement": [
{ "Action":
[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:DescribeTable",
"dynamodb:ListTables"
],
"Effect": "Allow",
"Resource": "*“
}]}
dev@example.com
Acct ID: 123456789012
{ "Statement": [
{
"Effect":"Allow",
"Principal":{"AWS":"123456789012"},
"Action":"sts:AssumeRole"
}]}
How does federated access work?
IAM user: Anders
Permissions assigned to ddb-role
STS
ddb-role trusts IAM users from the AWS account
dev@example.com (123456789012)

29. prod@example.com
Acct ID: 111122223333
ddb-role
{ "Statement": [
{ "Action":
[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:DescribeTable",
"dynamodb:ListTables"
],
"Effect": "Allow",
"Resource": "*“
}]}
dev@example.com
Acct ID: 123456789012
{ "Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource":
"arn:aws:iam::111122223333:role/ddb-role"
}]}
{ "Statement": [
{
"Effect":"Allow",
"Principal":{"AWS":"123456789012"},
"Action":"sts:AssumeRole"
}]}
How does federated access work?
ddb-role trusts IAM users from the AWS account
dev@example.com (123456789012)
Permissions assigned to
Anders granting him
permission to assume
ddb-role in account B
IAM user: Anders
Permissions assigned to ddb-role
STS

30. prod@example.com
Acct ID: 111122223333
ddb-role
{ "Statement": [
{ "Action":
[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:DescribeTable",
"dynamodb:ListTables"
],
"Effect": "Allow",
"Resource": "*“
}]}
dev@example.com
Acct ID: 123456789012
Authenticate with
Anders’ access keys
{ "Statement": [
{
"Effect":"Allow",
"Principal":{"AWS":"123456789012"},
"Action":"sts:AssumeRole"
}]}
How does federated access work?
IAM user: Anders
STS
{ "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
ddb-role trusts IAM users from the AWS account
dev@example.com (123456789012)
Permissions assigned to ddb-role

31. prod@example.com
Acct ID: 111122223333
ddb-role
{ "Statement": [
{ "Action":
[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:DescribeTable",
"dynamodb:ListTables"
],
"Effect": "Allow",
"Resource": "*“
}]}
dev@example.com
Acct ID: 123456789012
Get temporary
security credentials
for ddb-role
{ "Statement": [
{
"Effect":"Allow",
"Principal":{"AWS":"123456789012"},
"Action":"sts:AssumeRole"
}]}
How does federated access work?
IAM user: Anders
STS
ddb-role trusts IAM users from the AWS account
dev@example.com (123456789012)
Permissions assigned to ddb-role
Authenticate with
Anders’ access keys
{ "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

32. prod@example.com
Acct ID: 111122223333
ddb-role
{ "Statement": [
{ "Action":
[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:DescribeTable",
"dynamodb:ListTables"
],
"Effect": "Allow",
"Resource": "*“
}]}
dev@example.com
Acct ID: 123456789012
Call AWS APIs using
temporary security
credentials
of ddb-role
{ "Statement": [
{
"Effect":"Allow",
"Principal":{"AWS":"123456789012"},
"Action":"sts:AssumeRole"
}]}
How does federated access work?
IAM user: Anders
STS
Get temporary
security credentials
for ddb-role
ddb-role trusts IAM users from the AWS account
dev@example.com (123456789012)
Permissions assigned to ddb-role
Authenticate with
Anders’ access keys
{ "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

34. AWS access keys vs. passwords
• Depends on how your users will access AWS
– Console → Password
– API, CLI, SDK → Access keys

35. AWS access keys vs. passwords
• 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.

36. 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}"
}]}

37. Enabling credential rotation for IAM users
(Enable access key rotation sample policy)
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 keysAccess 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}"
}]}

38. Show and Tell

40. 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.

41. 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.

43. 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.

44. 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 .

45. 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 managed policies when you need to
– Assign the same policy to users, groups, and roles.

46. 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.

47. Show and Tell

49. 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.

50. 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.

51. 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.
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

52. 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

53. How does tag-based access control work?
IAM user: Anders
i-a1234b12
Project=Blue
{
"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

54. How does tag-based access control work?
IAM user: Anders
i-a1234b12
Project=Blue
{
"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

55. How does tag-based access control work?
IAM user: Anders
i-a1234b12
Project=Blue
i-a4321b12
Project=Blue
{
"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

56. How does tag-based access control work?
IAM user: Anders
i-a1234b12
i-a4321b12
Project=Blue
{
"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

57. How does tag-based access control work?
IAM user: Anders
Project=Blue
{
"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
i-a1234b12
i-a4321b12

58. How does tag-based access control work?
IAM user: Anders
Project=Blue
i-a4321b12
Project=Green
i-a1234b12
i-a4321b12
{
"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

59. Show and Tell

61. 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.

62. 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).
– Want something close to Mandatory Access Control
– Need a single bill, but want to break out the cost and usage.

63. Cross-account access with IAM roles
dev@example.com
Acct ID: 123456123456
proj2@example.com
Acct ID: 111222333444
proj1@example.com
Acct ID: 112233445566
IAM user: Anders

64. Cross-account access with IAM roles
IAM user: Anders
dev@example.com
Acct ID: 123456123456
proj2@example.com
Acct ID: 111222333444
proj1@example.com
Acct ID: 112233445566

65. Cross-account access with IAM roles
IAM user: Anders
dev@example.com
Acct ID: 123456123456
proj2@example.com
Acct ID: 111222333444
proj1@example.com
Acct ID: 112233445566

66. Cross-account access with IAM roles
IAM user: Anders
dev@example.com
Acct ID: 123456123456
proj2@example.com
Acct ID: 111222333444
proj1@example.com
Acct ID: 112233445566

67. Cross-account access with IAM roles
IAM user: Anders
dev@example.com
Acct ID: 123456123456
proj2@example.com
Acct ID: 111222333444
proj1@example.com
Acct ID: 112233445566

68. Cross-account access with IAM roles
IAM user: Anders
dev@example.com
Acct ID: 123456123456
proj2@example.com
Acct ID: 111222333444
proj1@example.com
Acct ID: 112233445566

69. Cross-account access with IAM roles
IAM user: Anders
dev@example.com
Acct ID: 123456123456
proj2@example.com
Acct ID: 111222333444
proj1@example.com
Acct ID: 112233445566

70. Cross-account access with IAM roles
External identity
provider
acme@example.com
Acct ID: 123456789012
IAM user: Anders
IAM user: Bob
dev@example.com
Acct ID: 123456123456
proj2@example.com
Acct ID: 111222333444
proj1@example.com
Acct ID: 112233445566

71. Cross-account access with IAM roles
External identity
provider
IAM user: Anders
IAM user: Bob
acme@example.com
Acct ID: 123456789012
dev@example.com
Acct ID: 123456123456
proj2@example.com
Acct ID: 111222333444
proj1@example.com
Acct ID: 112233445566

72. Show and Tell

73. 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

74. ©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved
Dave Walker – Specialised Solutions Architect Security/Compliance
Amazon Web Services UK Ltd
22/10/15
Thank You