Biggest problem I could see with applications is that if you were using this inside a larger application, someone with control of the application could just change the less-secure application to bypass Evervault entirely. Wouldn't compromise historical/data-at-rest data already inside evervault, but would bypass it for new submissions. That doesn't mean this isn't useful, but it would be a concern in some use cases.
back
This looks pretty cool (particularly that it's easy to use). If you're already using AWS you could just use nitro enclaves to do this directly, but this makes it easier to use, and easier to use if you're not using AWS but trust AWS (+ evervault, particularly for availability). It's cool to see this for something other than just payment card info vaulting.
1 comments
If someone has control of the application, aren't all bets off at that point?
At some point, your application has to decrypt the data to work with it. The person with control of the application would exfiltrate data that way.
This is mostly true, but even if somebody manages to get access to an application runtime there won't be a major data leakage issue using Evervault because all data has been encrypted using a key that our customers don't host.
All plaintext data processing happens on Evervault's infrastructure, so our customers don't have any runtimes that handle sensitive data in plaintext.
> If someone has control of the application, aren't all bets off at that point?
Great point, but not necessarily. This is what we are trying to solve with Redact. Would be interested to hear your thoughts on our solution: https://redact.ws