Serverless Architectures Security Guide
puresec.io
puresec.io
There's no difference in security considerations when interacting with external resources at the application level. Either way you better have some form of auth and be sending credentials over TLS.
WAFs aren't irrelevant since from an external perspective there's no discernible difference between a request like
POST /login?user=root&password=' OR 1=1 --
In fact, Lambdas (and every other serverless platform I'm aware of) execute with the same isolation as EC2 instances in AWS. There are effectively no differences security-wise between code executing on an EC2 and code executing in Lambda. Any vulnerability in a Lambda function is also going to be a vulnerability in a traditional application hosted on EC2 and vice versa.
It enumerates the Top 10 Most Critical Security Risks, but doesn't explain what each one really means, gives examples of where and how they're exposed, or how to mitigate them. Things that OWASP does.
Now, you might say that it's just the beginning and they iterate. Fine, but without any detail on these Top 10, this document is not super useful.
It would have been better to wait until it had more "meat".
I have the idea that it could be particularly helpful in a serverless context, since I would imagine that configuration sprawl becomes an issue pretty quickly. That said, it's not an approach I have a lot of personal experience with, so I would love to hear thoughts on whether it's really a good fit!
Things would likely change if my company gets bigger, let’s say > 15 devs. Everybody can deploy the ansible playbooks right now but if the company gets bigger then I will have to worry about access control for different people. I may also have dedicated devops/ops people in which case I will want to limit normal developers’ access. I will worry about whether there is a process in place to ensure that keys always stay safe and are rotated whenever an employees leaves. etcetera.
Your product reminds me a lot of Launchdarkly, in that it solves a seemingly trivial problem (they help you manage feature flags), yet when you think of it in the context of a larger organization where people have to work together then there are suddenly lots of related problems that aren’t so trivially solved. Launchdarkly apparently managed to convince VCs to invest in them. You may want to look at them for inspiration. They have material posted on Heavybit.
Haven't tried sops, thanks for the link.
The comparison to LaunchDarkly is interesting. When first hearing about the idea of a feature flagging service, I do remember thinking "why does anyone need a service for this?" but as you say, the complexity grows very quickly.
I'm hoping to convince smaller teams that it's worthwhile for them to spend a few minutes and a few dollars up front to make secrets and configuration an area that is secure and 'just works' so they never have to worry about it again, but it's probably true that larger teams are a more natural fit.