Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

(SEC302) IAM Best Practices To Live By

10,562 views

Published on

This session will cover AWS Identity and Access Management (IAM) best practices that help improve your security posture. We will cover how to manage users and their security credentials. We’ll also explain why you should delete your root access keys—or at the very least, rotate them regularly. Using common use cases, we will demonstrate when to choose between using IAM users and IAM roles. Finally, we will explore how to set permissions to grant least privilege access control in one or more of your AWS accounts.

Published in: Technology
  • I made $2,600 with this. I already have 7 days with this... ➤➤ https://tinyurl.com/make2793amonth
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I went from getting $3 surveys to $500 surveys every day!! learn more... ➤➤ http://ishbv.com/surveys6/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

(SEC302) IAM Best Practices To Live By

  1. 1. © 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
  2. 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. 3. AWS Identity and Access Management (IAM) Enables you to control who can do what in your AWS account
  4. 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. 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 – Centralized – Fine-grained - APIs, resources, and AWS Management Console
  6. 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. 7. IAM Best Practices • Basic user and permission management • Credential management • Delegation
  8. 8. Basic user and permission management 0. Create individual users. Benefits • Unique credentials • Individual credential rotation • Individual permissions
  9. 9. Basic user and permission management 0. Create individual users. 1. Grant least privilege. Benefits • Less chance of people making mistakes • Easier to relax than tighten up • More granular control
  10. 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. 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 • Minimizes chances of accidentally performing privileged actions
  12. 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. 13. Credential management 5. Configure a strong password policy. Benefits • Ensures your users and your data are protected
  14. 14. Credential management 5. Configure a strong password policy. 6. Rotate security credentials regularly. Benefits • Normal best practice
  15. 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. 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. 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. 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. 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. 20. Versus – When should I use…? AWS access keys vs. passwords
  21. 21. 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
  22. 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 • Other important use cases – Delegating access to your account → Federated users (IAM roles) – Mobile application access → Should always be federated access
  23. 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 IMPORTANT: Never share security credentials.
  24. 24. prod@example.com Acct ID: 111122223333dev@example.com Acct ID: 123456789012 How does federated access work? IAM user: Anders STS
  25. 25. prod@example.com Acct ID: 111122223333 ddb-role dev@example.com Acct ID: 123456789012 How does federated access work? IAM user: Anders STS
  26. 26. 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
  27. 27. 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? ddb-role trusts IAM users from the AWS account dev@example.com (123456789012) IAM user: Anders Permissions assigned to ddb-role STS
  28. 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", "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
  29. 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 Authenticate with Anders’ access keys { "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. 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 Get temporary security credentials for ddb-role { "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
  31. 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 Authenticate with Anders’ access keys Get temporary security credentials for ddb-role Call AWS APIs using temporary security credentials of ddb-role { "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
  32. 32. AWS access keys vs. passwords • Depends on how your users will access AWS – Console → Password – API, CLI, SDK → Access keys
  33. 33. 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.
  34. 34. 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}" }]}
  35. 35. 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
  36. 36. Show and Tell
  37. 37. 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.
  38. 38. 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.
  39. 39. 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.
  40. 40. 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 .
  41. 41. 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.
  42. 42. 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.
  43. 43. Show and Tell
  44. 44. 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.
  45. 45. 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.
  46. 46. 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
  47. 47. 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
  48. 48. 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 i-a1234b12 Project=Blue
  49. 49. 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 i-a1234b12 Project=Blue
  50. 50. 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 i-a1234b12 Project=Blue i-a4321b12 Project=Blue
  51. 51. 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 i-a1234b12 i-a4321b12 Project=Blue
  52. 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 i-a1234b12 i-a4321b12 Project=Blue
  53. 53. 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 i-a1234b12 i-a4321b12 Project=Blue i-a4321b12 Project=Green
  54. 54. Show and Tell
  55. 55. 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.
  56. 56. 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.
  57. 57. 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
  58. 58. 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
  59. 59. 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
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 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. 64. Cross-account access with IAM roles External identity provider acme@example.com Acct ID: 123456789012 dev@example.com Acct ID: 123456123456 proj2@example.com Acct ID: 111222333444 proj1@example.com Acct ID: 112233445566 IAM user: Anders IAM user: Bob
  65. 65. Cross-account access with IAM roles External identity provider acme@example.com Acct ID: 123456789012 dev@example.com Acct ID: 123456123456 proj2@example.com Acct ID: 111222333444 proj1@example.com Acct ID: 112233445566 IAM user: Anders IAM user: Bob
  66. 66. Show and Tell
  67. 67. 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
  68. 68. 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
  69. 69. Remember to complete your evaluations!
  70. 70. Thank you!

×