> this is table stakes level security; realistically if your DB is compromised, your encryption key probably is too, because they probably got in through your application which holds the key in memory. this just prevents "oops I accidentally copied the DB somewhere and it leaked".
Good point. If the attacker gains access to e.g. a web service that needs to access the stored secrets, they will have encryption keys and DB access.
> if you have, or when you get to the point that you have, a competent ops org, just use HashiCorp Vault.
I watched a video about Vault, but I don't see how it would help. Attacker gains access to the web service which can access Vault -> Attacker downloads all API keys from Vault. Or is there something I'm missing?
at the end of the day if the code that handles the sensitive secret is compromised, you’re leaking secrets
one of the big ways Vault can help is by separating reads and writes. the web UI that stores a secret, exposed to internet, only receives a token that can write that secret for that customer, and only that customer. that service cannot get tokens that allow the code to read secrets. the background jobs, that aren't exposed to internet, do have the ability to generate scoped tokens to read.
it also helps you mitigate risk by shortening the lifespan of tokens that can access this data. the app container/lambda/process has a Vault token that is only valid for X seconds (whatever you want it to be). This can make it a lot more difficult for an attacker to do anything useful. First they find an exploit, then they try to do something with it. If their token/access is removed every 10 seconds, that makes it a hell of a lot harder to get anywhere once they get in
Vault also increases the discoverability of a compromise by letting you log all accesses to the secrets. this helps manage the aftermath of the compromise by having more certainty in which customers have been impacted etc
It’s all basically risk mitigation. If you have data you need to use legitimately, it’s possible for someone to get it illegitimately. Limit the scope of access they can get with one break in and the length of time they can do anything once they’re in. compartmentalize systems to create defense in depth
Disclaimer: I am not a security expert, but have managed this stuff at startups too small to hire one yet
Yeah you do, but you compartmentalize that with your orchestration (hence strong ops). With HashiCorp Nomad for example you might setup a parameterized job. When Nomad receives a job to do X for customer Y, it allocates a container with a short lived token. Nomad is the system with the longer living token that lets it generate short lived tokens for short lived workloads, that are themselves containerized to add a layer of security for a compromise. And so on.
Abstract that a little bit; the system that generates the short lived token ideally would not be the same as the system that is using it
Good point. If the attacker gains access to e.g. a web service that needs to access the stored secrets, they will have encryption keys and DB access.
> if you have, or when you get to the point that you have, a competent ops org, just use HashiCorp Vault.
I watched a video about Vault, but I don't see how it would help. Attacker gains access to the web service which can access Vault -> Attacker downloads all API keys from Vault. Or is there something I'm missing?