So I had the opportunity to attend this event in Manchester. As someone who has been digging into AWS this year and planning to do the cert, I thought going to this event would be worthwhile. It was also a great chance to meet other people jumping into the cloud and AWS in general.
It also gave me the chance to bombard the AWS techies with questions and scenarios that were running through my mind. I bombarded both @AWSTomWoodyer and @ric__harvey with questions and they were more than happy to answer them.
It was split into two tracks Technical and Management. I kept in the technical until towards the end of the day, where I then jumped into management track as they were discussing security. I was torn between both tracks as they both covered topics I was very interested in.
Key Points:
- Security was one of the main focuses of the event
- AWS have an implicit deny on everything, the customer has to actively allow traffic/users in using various rules. So it is the customers responsibility to use the tools provided to maintain a secure environment, much in the same way as you would do with a physical estate
- AWS operate a shared responsibility model, AWS is responsible for the security OF the cloud, the customer is responsible for security IN the cloud
- AWS for example give you Security Groups, but it is up to the customer to set the rules that AWS will enforce for you
CloudTrail logs all API calls, leaving a very good audit trail, these can then be sent to a different S3 bucket, in the same account or a totally separate secure account. These logs can also be sent off site to a 3rd party log collector for your own analytics.
AWS DOES NOT charge for data ingestion, but AWS DOES charge for storage and how you access it,
AD integration can be done using Federated services, so all the AD groups that are already in use can be applied across the AWS account, which makes managing and securing your account much easier.
AWS provide full access to their compliance certifications/Statement of Applicability (SoA) . They will provide you with the framework to comply with everything on their end, but it is you as the customer to ensure you use the correct features in the correct way to ensure compliance:
- Know the shared responsibility model
- Understand AWS Secure Global Infrastructure
- Define and Categorize Assets in AWS – Macie, Tag all EC2 instances
- Design IAMs (Identity and Access Management) to protect assets in AWS – CloudTrail/Macie
- Manage AWs account/IAM Users/Groups/Roles correctly – AD Federated Access
- Manage EC2 SSH keys – Hardware keys etc
- Secure your data – SSL certs, cert manager in AWS, use your own keys if you don’t trust AWS with them
- Patch O/S and applications – AWS WAF (web Firewall), AWS Shield – DDOS protection, AWS Inspector – a lite penetration tester. Penetration testing is allowed, you just need to inform AWS that you will be doing this, otherwise they will lock your account as it could be seen as a breach/attack
- Secure you infrastructure – VPC: no one but you can see that traffic (not even Amazon), Security Groups and ACLs, LBs, Remote access points (VTS). Enable MFA for access and for deletes too.
- Mandatory alerting/Audit Tools/Responses – CloudWatch/CloudTrail/GuardDuty
Remember to keep your root AWS account details up-to date, because when there are any security issues the security team will contact those details right away.
As with many things in life, the more you pay the more responsibility AWS can take on for you with regards to maintaining your infrastructure, patching and security compliance.
When you turn off an EC2 instance you stop paying for it, but you are still paying for the underlying EBS volumes that are attached to you
The presentations are available here they are really good and have some cool diagrams:
I have read my fair share of stories about security breaches when it comes to using S3, and I have been pondering over the ins and outs of it. When it comes to security you can make something super secure, but as a result it will become a total pain to manage. You can also make something insecure but it will become very easy to manage. Management and Security will always be at odds with each other but the key is to find that sweet spot, where you are secure enough so you don’t make it easy for any kind of breaches to happen, but also you do not make it a nightmare for people to use and manage, where you could run the risk of some form of Shadow IT happening.
It appears to me that AWS gives you a vast amount of options, but it can become very complex to manage and understand. This is why people just give read only open access, as they can bypass this. But the risk there is that now it is open to anyone who can find the link. It is the perfect example, where you give too many options and people get confused and just ignore them, but then again if you didn’t give these options, people would complain and say it was lacking.
Amazon/AWS do say that they provide the tools, but you have the responsibility as the customer to use them correctly.
Leave a Reply