This week i had the opportunity to attend the Serverless Days in Hamburg which took place in the iconic Sankt Pauli Stadium.
The first day was all about hands-on workshops. There were many tracks available and i choose two workshops about Security on AWS.
These are some notes i took. i hope you can find some interesting tips.
First part was about setting up all the necessary to secure and monitor your account:
CloudTrail is a AWS service that provides event history of your AWS account activity. Everything that happens on the AWS API ( UI-console or cli) will be registered.
What to do:
- Activate a Cloud Trail on ALL regions
- Write everything to a S3 Bucket ( but keep logs longer than 90 days - on Glacier or backed up somewherecloud ) for forensics.
- Make sure nobody can access those logs and of course none can delete the bucket nor the logs. (eventually encrypt content)
- Monitor what is happening on the bucket itself ( you want to now if someone tried to temper with it)
- Use Cloudwatch events to produce Alarms in case of specific actions, like when:
- someone tries to delete or read data
- policies are given or removed
- configuration is changed
- resources are created or used in other regions
- for more specific stuff (like a server instance being probed or bruteforce attacks) to check patterns in the logs use GuardDuty
- Create a Topic in AWS SNS ( Simple Notification Service) and subscribe to it in order to be immediately notified when an Alarm on CloudWatch occurs and be able to act (like removing all roles from the user / service that caused the alarm)
Second part was about granting roles to users or accounts to temporarily access resources - like in case of testers or auditors.
This is possible via the Action AssumeRole and STS which is a service that grants Temporary Tokens that can be used to Assume a specific role.
- Swiss cheese security: every layer of security will have holes. If aligned, they could lead to accidents.
- Security in Depth
- prevent - detect - notify - contain
- Try to keep the monitoring part (from S3 bucket to SNS) on a different account from the one which is monitored with Cloudtrail.
- Always configure the policy on the resource AND on the role to prevent data loss: (you cannot assign a role to Cloudtrail - in case of the monitoring bucket create a policy on the bucket).
- remember that DENY overrules ALLOW ( in case of conflicting configurations between policies and roles)
- Principle of Least Privilege : dont give open policies expecting to be restricted later. that will never happen..
steal data and documents for fraud and spy, delete data to create harm, bitcoin mining.
because you definetely want to know if someone is doing stuff on other regions (like spawning EC2 instances in Singapore)
whenever you provide to pubsub services or to newsletter etc - you can append some words to your email address so that you can then add a filter in Gmail
so if your email is email@example.com you can enter firstname.lastname@example.org and then filter your emails by spamming_newsletter
Second workshop was pretty intense. After a short but interesting introduction about Lambda Permission Model and some insights about Execution vs Function policies we were given a shitload of material taken from https://github.com/aws-samples/aws-serverless-security-workshop and we basically went through all of it( well, mostly..) to rebuild the app.
I must say that this kind of workshop is not really my preferred type because i prefer to tinker with code alone - or pair programming with someone - in different contexts and when i am at a workshop i prefer a more active discussion or a frontal lessons.
But that is just my way of learning, other people were enjoying that a lot - and i managed anyway to learn a lot and discuss with Alex and his two assistants about many details of Cognito and Scopes.
- don´t be obsessed with how much you pay for Memory with Lambdas because Lambdas with less Memory allocation will take longer and you might end up paying the same ( but with slower services)
- don´t use asterisk in permission policies: you could / should even add linter to prevent its usage
- if you use Cloudfront - deployment of the stack take way longer, try to keep stack description from Cloudfront description separated so that if cloudfront stack fails at least not everything is rolled back. it does not speed it up in the end but avoids unnecessary rollbacks
Tomorrow i will tell you about Day 2 - when A LOT of Talks took place! :-)