Seems like that could kill more birds with the same stone?
I really like the approach you are taking since it could be a quick drop-in deployment that solves a huge problem for us.
From my experience you better have dedicated views for different stakeholders and your problem is solved without those downsides.
So for me everything has to be infrastructures as code. I don't want to log into a UI and start configuring connections etc.
Also not keen on giving you production accesses to my databases, but maybe I misunderstood your implementation.
So I like the idea of a docker container that does this as a proxy.
It's a tough market you're going into, $395 per database is a big ask.
``` How are keys handled? We generate unqique encryption keys for every account and store them in a secure secrets manager. Subkeys are routinely created and rotated from the master key. For additional security, we support user provided keys on our Team and Enterprise plan. ```
`unqique` --> `unique`
Like if I had the encryption key and any salt etc, can I decrypt it without your product?
Also how much has the encrypted format been vetted?
I saw your example and the last name seemed to be massive even compared to using something like KMS.
How are updates handled, if I’m hosting the container in my cloud? How should I plan for troubleshooting if there are incidents involving JumpWire?
Did you have to get into the weeds of the wire protocols that Postgres/Mysql use? What was that like?
> Based on policies you define, individual fields can be encrypted/decrypted... Are the policies something like "retool" gets tokenized or faked data back, and the main app gets everything? Or is it more granular even within the main app? Like can I teach JumpWire about my app's users and our AuthZ ruleset?
> or they partition the data by putting some fields in a data vault and others in the main database I was considering using VGS to tokenize sensitive data, but I prefer self-hosted and reasonably auditable code for such sensitive systems. Is that the case here?
> We’ve seen entire teams dedicated to just maintaining ETL pipelines for scrubbing PII into secondary databases!
I do this to make staging environments more realistic, which makes them double as debugging tools on production when you can't give engineers any sort of direct production access. We whitelist non-sensitive fields (most importantly foreign keys), and fill in the rest with faked data. The app looks like production, but if all the users were bots who were saying nonsense at each other. At my scale (50 person company), it works reasonably well enough with just me maintaining it.
I suppose its more about ensuring the data sitting around in the DB isn't exposed to random employees or hackers yeah?
Essentially, I would pick "cooking" and get a list of vocabulary, sorted by usage/importance that contains all the words that I need for "cooking" such as tools, ingredients, techniques and so on.
Or the same for traveling, hiking, cycling, ordering in a restaurant, buying a house, ...
That would be super useful.