| Sorry for stream of consciousness here; 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 |
I have the feeling that damage control is the only option:
1) Secrets store is on different credentials
2) Decryption key is only known outside of secrets storage
3) There is a maximum number of different credentials that can be queried per day (adjustable over time)