AWS Security Essentials
2 likes1,181 views
This document provides an overview of key areas to focus on for security when using AWS cloud infrastructure: automation, IAM, network design, encryption, auditing, and continuous integration. It emphasizes that automation is critical for security and infrastructure should be defined as code. For IAM, it recommends using a directory service and restricting use of the root account. For network design, it suggests using VPCs and monitoring traffic. It also provides checklists for each area to help ensure security best practices are followed.
AWS Security Essentials
- 1. AWS Security Essentials Aaron Bedra Chief Scientist, Jemurai @abedra keybase.io/abedra
- 2. Cloud infrastructure providers offer some incredible benefits
- 3. There are loads of reasons to take the leap
- 4. But there are a lot of misconceptions about how to approach it
- 5. This talk will focus on AWS, but the concepts apply to all providers
- 6. It’s easy to get caught up in mirroring your legacy datacenter
- 7. Just say no to lift and shift!!!
- 8. But you have to realize that this is not a traditional DC
- 9. And you shouldn’t treat it that way
- 10. There are aspects you want to keep
- 11. And some you want to throw away
- 12. To get security right in the cloud requires change
- 14. Automation
- 16. This is a critical step
- 17. There’s no excuse for ignoring automation
- 18. The platforms are built for it
- 19. Humans clicking buttons is what causes security issues
- 20. And what causes blockers, slow down, and frustration
- 21. If you desire to move to the cloud and wish to continue clicking buttons, stay where you are
- 22. You shouldn’t be logging into the AWS console
- 23. In fact, page the security team when it happens
- 24. Or just disable console access entirely*
- 25. Getting your infrastructure configuration into code is step 1
- 26. It allows for review, analysis, and audit
- 27. It creates a culture around describing systems as data
- 28. The cloud is an abstraction, talk about it as one
- 29. It creates a place where simple code review is the only blocker between you and the end result
- 30. Automation Checklist All infrastructure is recorded as code All infrastructure changes are made by an automated tool Console logins are restricted to a handful of administrators Teams are educated and empowered to make necessary changes via automation
- 31. IAM
- 32. Get a grip on users and permissions
- 34. A mistake here could provide control over everything
- 35. How do we get to a good place?
- 36. Use a directory!
- 37. If you already have a directory, replicate it into AWS
- 38. Avoid keeping multiple systems of record for user accounts
- 39. This solves on-boarding and off-boarding issues
- 40. And ensures that changes propagate without additional work
- 41. If you don’t have a directory, make sure you setup strong account requirements
- 42. The root account
- 43. Don’t use it
- 44. Page security when it is used
- 45. There are only a handful of things you should use the root account for
- 47. Use of the root account isn’t acceptable if it’s not on that list
- 48. The only permission IAM accounts should have is assume role
- 49. Security Token Service should be the gateway to everything
- 50. This reduces the direct exposure of credentials
- 51. And forces people to think about the roles they need to perform a task
- 52. IAM Checklist Root account has MFA enabled Root account has no access keys* Users have no permissions outside of the ability to use STS to assume roles* Directories are replicated into AWS and used as the system of record MFA is enabled for all human users MFA is required to access privileged roles Users are trained and provided tools to make role assumption seamless Users have no inline policies
- 53. Network Design
- 54. Network design is situation dependent
- 55. But there are a few things that matter
- 57. VPC should be that boundary
- 58. Isolate environments and scope with VPCs
- 59. Monitor what comes in and out of the VPC
- 60. Be conscious about entry points!
- 61. There should only be one way in
- 62. VPN or Bastion hosts
- 63. Make sure not to expose management of all machines directly
- 64. Use tools to report on external footprint
- 65. Network Design Checklist Everything is deployed inside a VPC Flow logs are enabled and monitored Everything that can has a security group attached Any security group that allows access from 0.0.0.0/0 has a detailed description and justification Remote access is only allowed via a bastion host or internal interface
- 66. Encryption
- 68. We can all acknowledge that this is difficult
- 69. But we can make choices that reduce effort and the chance for mistakes
- 70. KMS
- 71. This is your new default
- 72. All your keys should originate from KMS
- 73. Any AWS service you use that stores data should have a kms key attached
- 74. resource "aws_db_instance" "default" { allocated_storage = 10 storage_type = "gp2" engine = "mysql" engine_version = "5.6.17" instance_class = "db.t1.micro" name = "mydb" username = "foo" password = "bar" db_subnet_group_name = "my_database_subnet_group" parameter_group_name = “default.mysql5.6" }
- 75. resource "aws_db_instance" "default" { allocated_storage = 10 storage_type = "gp2" engine = "mysql" engine_version = "5.6.17" instance_class = "db.t1.micro" name = "mydb" username = "foo" password = "bar" db_subnet_group_name = "my_database_subnet_group" parameter_group_name = “default.mysql5.6" kms_key_id = “${aws_kms_key.foo.key_id}” }
- 76. Start with AWS services encrypted using KMS
- 77. Encryption Checklist All Master or Key Encryption Keys are stored using KMS All KMS keys have the rotation option enabled All AWS services utilized that store data should use KMS Data encryption keys are generated using kms master keys and stored encrypted
- 78. Auditing
- 79. How do you know things are configured correctly?
- 80. Scout2
- 81. Scout2 audits all configurations across all regions
- 82. It produces a report of dangerous issues
- 84. Run this tool on your infrastructure and see what you find
- 85. You will likely be surprised
- 86. Take some time to discuss and correct these issues
- 87. This helps with audit of configuration
- 88. But what about user activity?
- 91. They are an absolute must for anyone taking security seriously
- 92. Enable CloudTrail for all active regions
- 93. Use CloudWatch to establish alerts on big ticket concerns
- 94. Or better yet, use a third party that can do this for you
- 95. You don’t have to manage everything on your own
- 97. Alert Event Examples Root account login Root account key usage New user created User added to administrative roles Too many KMS decrypt events
- 98. Auditing Checklist Configuration analysis is performed at least daily, if not for every change CloudTrail is enabled for all active regions CloudWatch metrics and alarms are implemented for major violation cases Guard Duty?
- 100. How do I automate it?
- 101. Because your infrastructure is in code, you can hook audit into the CI pipeline
- 102. Now you can block or rollback changes based on audit findings
- 103. You can also institute a seamless sign-off policy that lives in code hosting
- 106. CI Checklist All infrastructure changes trigger configuration audits Critical issues found in CI trigger immediate response Use the CI pipeline to create a sign-off process that allows teams to move faster
- 107. The benefits of being on provider like AWS are massive
- 108. If there is still fear of shifting, please look again!
- 109. Healthcare, Finance, Government, etc. are there already
- 110. Questions?