|
|
|
|
|
|
by kop316
1774 days ago
|
|
|
Hello! If I may, some (hopefully constructive) criticism: - I skimmed the article, and I honestly am not sure who the customer is. AWS customers I suppose? It would be nice to have a quick "TL;DR" section so I can quickly tell if I am the right customer. (I'm also not an AWS customer, so maybe I just don't understand the jargon). - A big pet peeve of mine when reading security related things is not seeing security assumptions. It would be nice to understand what your infrastructure does and does not protect against. |
|
|
Our customers are mostly developers working at startups which process high volumes of sensitive data (things like payment details, healthcare data, credentials etc.). We abstract away all of the infrastructure that E3 runs on, so we don't have any requirements for where our customers our hosted. Our customers run on a very diverse range of stacks/clouds, so being cloud-agnostic was a key design requirement.
The core security assumption with Evervault is that your API key is reasonably well managed. API keys can be easily rotated in our dashboard, but having encrypted data and an Evervault API key could potentially lead to data leakage. Over time, we plan on adding some cool features around data leakage whereby we can proactively block data exfiltration/leakage. More on this soon!
A simple model for how security with Evervault works is: you store encrypted data, but not keys; Evervault stores keys, but no data. This creates a nice dual-responsibility model which far exceeds what most companies can do today.
Feel free to email directly if you have any other questions! I'm on shane@evervault.com