Something here seems to not fit together to me on the assumptions this is based on, because you say
> We're explicitly not claiming to defend against an attacker who fully owns your running application with valid credentials.
and dandraper says:
> I was CTO [...] and the engineers all had access to patient data. They needed DB access [...] but not access to the sensitive values
> [...]
> CipherStash solves the following:
> * Hide sensitive data from direct database accessors
So putting these together is this implying that a developer who wants to test things on a large data set is given access to the database directly, but not access to debug the application? Surely for example if they could load the app in a debugger, step through it, and execute arbitrary code (eg. if they are developing on it) that includes "fully running the application"? So are you saying that scenario is not secure?
If so then I'm struggling to see how a developer would use this realistically. As a dev how am I supposed to work on an application without access to be able to change the code (assuming here then that "change the code" means I can also add a statement that dumps a decrypted value to the log)?
If the security level we want is something like "devs need to be able to test migrations work on the actual data" then why would I use this instead of just NOT giving direct db access and having an audited environment spin up a db copy and container and just output the logs of whether the migration worked, without access to query the db directly. If I do that then nobody needs direct db access right? But then why would I need CipherStash?
> We're explicitly not claiming to defend against an attacker who fully owns your running application with valid credentials.
and dandraper says:
> I was CTO [...] and the engineers all had access to patient data. They needed DB access [...] but not access to the sensitive values > [...] > CipherStash solves the following: > * Hide sensitive data from direct database accessors
So putting these together is this implying that a developer who wants to test things on a large data set is given access to the database directly, but not access to debug the application? Surely for example if they could load the app in a debugger, step through it, and execute arbitrary code (eg. if they are developing on it) that includes "fully running the application"? So are you saying that scenario is not secure?
If so then I'm struggling to see how a developer would use this realistically. As a dev how am I supposed to work on an application without access to be able to change the code (assuming here then that "change the code" means I can also add a statement that dumps a decrypted value to the log)?
If the security level we want is something like "devs need to be able to test migrations work on the actual data" then why would I use this instead of just NOT giving direct db access and having an audited environment spin up a db copy and container and just output the logs of whether the migration worked, without access to query the db directly. If I do that then nobody needs direct db access right? But then why would I need CipherStash?