Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
We've built startups (Ryan was Dir. of Engineering at N26) and worked in big tech (William was SRE at Spotify), and in every company, saw the same pattern of data spreading out of control. It felt like a dirty secret: hundreds of employees are granted access to customer PII through internal systems. Engineers responsible for securing data end up in a race against a growing list of SaaS or internal tools in use across the organization, and fall back to using bad access management workflows. Trying to secure data by controlling access is a risky proposition on its own — data leaks due to compromised access have become an all-too-regular occurrence, e.g. Uber contractor breach in September as a recent example.
Companies that outgrow the access control approach typically do one of two things. Either developers have to write custom logic into all of their applications to encrypt/decrypt data, or they partition the data by putting some fields in a data vault and others in the main database. Both options are costly in terms of implementation work and ongoing maintenance. We’ve seen entire teams dedicated to just maintaining ETL pipelines for scrubbing PII into secondary databases!
JumpWire automates the encryption of data by identifying fields that contain sensitive information in databases and APIs. We do this without developers needing to modify their applications or manage access control rules. You define policies that determine how data should be handled—for a ‘user’ record, this might mean that the email address, name, and birthday are labeled as ‘PII’ and encrypted while signup date and favorite type of cheese are not.
JumpWire is a transparent proxy between applications and a database. The application connects using the same library it would if it was going directly to the database, and JumpWire intercepts and inspects queries before forwarding them on. Based on policies you define, individual fields can be encrypted/decrypted, nulled out, or audited as the requests and responses flow through the proxy. These policies are designed to be granular and map to table-specific schemas—for example, a policy might say to encrypt all PII, and the users table has a schema marking email address as PII. Different access controls can be applied to allow a subset of applications to bypass the policies where needed.
Because our proxies implement the underlying database protocols, application code or clients do not have to be changed to work with JumpWire.
The product is built to be self-hosted. The main component, our proxy engine, is run on your network as a cluster of Docker containers. The web interface is run by us by default but is also available to self-host. Our engine uses your own AWS KMS or HashiCorp Vault installation to store sensitive configuration data, such as database credentials and encryption keys. This ensures that confidential data is never transmitted across the Internet, and you remain in full control of the data infrastructure and keys. We do have a hosted Vault option as well to make it easy to get started or try things out in a staging environment.
Our database proxy supports PostgreSQL and MySQL/MariaDB, and DynamoDB is in beta. We also have an API proxy in early alpha that uses OpenAPI specs instead of connecting directly to a DB.
We actually built similar (but half-baked) versions of this at startups we were part of (a neobank and payment API), but it was always part of backend application code. We realized it could be abstracted out of the application entirely, and integrated via configuration instead. This would be easier to maintain, since application code wouldn’t need updating each time data policies changed. However, building it was never feasible at these other...
79 comments
[ 3.9 ms ] story [ 139 ms ] threadSeems like that could kill more birds with the same stone?
As an aside: Not exactly sure why the parent is getting down voted.
I'm not saying that your post was such a hijack, but it's difficult to interpret these things accurately, so any post of this kind will always land on a spectrum of responses.
We've peeked at Snaplet in the past, and :heart: your design aesthetic
With JumpWire, all of the works happens in an engine proxy that works directly with the database protocols. That makes the integration simpler - any language and connector can be used by just changing the hostname and auth. The downside is it's harder for us to add new databases - Voltage's approach definitely wins out there.
With JIT response encryption none of that is an issue, but it can be slow for large amounts of data. Any kind of big-data analytics will be a poor fit for JumpWire right now.
[1] https://en.wikipedia.org/wiki/Homomorphic_encryption
I really like the approach you are taking since it could be a quick drop-in deployment that solves a huge problem for us.
With JIT response encryption none of that is an issue, the database still has the raw data but applications are protected. The downside is it can be slow for large amounts of data.
[1] https://en.wikipedia.org/wiki/Homomorphic_encryption
Did you have to get into the weeds of the wire protocols that Postgres/Mysql use? What was that like?
Also critical is ensuring encryption occurs within the database transaction, so that data doesn't leak into write-ahead logs or change data capture streams. Since we manage keys/rotation this takes some careful logic in our engine.
``` 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`
Looks like a great product!
Of course BigID could build their own technical controls for customers to install, but I'm seeing more partnerships happening in the space - Cyera and Wiz recently announced a tighter product integration [1].
There's also problems of offering a solution over SaaS. We believe a proxy must run in our customers' network for low latency, as well as the added security of data isolated to a VPC.
[1] https://www.prnewswire.com/news-releases/cyera-and-wiz-partn...
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?
Policies are cluster aware, so that individual policies can be pinned to a particular cluster.
For troubleshooting, our engine publishes events that you can ship into your observability or monitoring stack (datadog/statsd, prometheus, cloudwatch) so any degradation can be handled by an IR process. And we support our customers with quick responses on shared slack channels directly with their engineering teams.
[1] https://github.com/47ng/prisma-field-encryption
I suppose its more about ensuring the data sitting around in the DB isn't exposed to random employees or hackers yeah?
The proxy layer is self-hosted, the UI can be self-hosted and the keys are your own AWS KMS keys.
Whether engineers can access the keys and decrypt data depends on your setup. The engine can use either AWS KMS or Vault for top-level key management, so if an engineer has full permissions over those then they could get the keys out. We can also host the keys in our infrastructure and sync them over to the engine if you're comfortable with that tradeoff.
pgcrypto mentioned below is a good example. It's a great extension that works really well, and if you're only using PostgrSQL you could build a lot of the functionality of JumpWire using it. But it requires a lot of engineering work to fit into your application. Having the basic encryption functions only gets you part of the way to a full solution - the rest is aligning those with high level policies and keeping up to date as data schemas change.
Last Password was hacked twice this year. How many data breaches are there on a regular basis. The reality is the cost of trouble worth the possibility. As much as everyone wants to say they care about users data, the reality in most companies is very different.
But we try _really_ hard to ensure your data is never exposed to the Internet. And we do everything we can to limit our ability to read your data, either through self-hosting or ensuring you own the keys.
> 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.
> Are the policies something like "retool" gets tokenized or faked data back, and the main app gets everything?
Yep, that's exactly right. Application credentials are grouped under classifications, and policies can be included/excluded across classifications. We aren't passing authz through JumpWire but for something like Retool you can configure it to connect through different proxies for different users.
> I prefer self-hosted and reasonably auditable code for such sensitive systems. Is that the case here?
Exactly. The engine which interacts with your data is almost always self-hosted, and the web app also can be if needed.
> At my scale (50 person company), it works reasonably well enough with just me maintaining it.
Makes sense! No reason to add more tools to your stack yet if the custom process isn't too burdensome.
We are hoping to leverage their recently released Queryable Encryption feature [1], but the key management is tricky.
[1] https://www.mongodb.com/products/queryable-encryption
https://www.mongodb.com/docs/manual/core/queryable-encryptio...
From my experience you better have dedicated views for different stakeholders and your problem is solved without those downsides.
Custom views can help, but it does mean you're dealing with access controls directly in the database which can be hard to manage. And the database is fully exposed through backups or engineers with server access.
That may not be a correct assumption for ALL systems, but it's a safe assumption for A LOT of systems.
OP this is seriously cool, nicely done.
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.
prefix + base64(len_encode(metadata) + len_encode(key_tag) + aes_encrypt(data))
So definitely possible to decrypt it without JumpWire, if you have the keys. There are some pieces of metadata we add in that we could make optional if you want to reduce the resulting ciphertext size. That metadata adds a few extra bytes, but it doesn't grow with the data size.
Although I might be biased cuz I'm a founder from a tech background so I want those details, but even with those details, I'm one of your target market but my worry with these kinds of products tends to be more about things like:
- am I adding an unreliable piece of infra to my stack? this is going to be a critical gatekeeper, so if this fails, not only is it like my DB being down, as the only method of decrypting my data, does it have the ability to fail in a way that results in permanent data loss (whereby I can't decrypt some subset of the data)
- if I had to yank this out, what's the process? will I be stuck?
- what are the chances of us doing something stupid and lock OURSELVES out of our own data? what guardrails are available there?
- what is the key management story? (which answers a lot of the above questions)
- is this roll-your-own crypto (not just which algorithm, but how the messages are constructed, etc) or something standard and vetted? Because there's no secret sauce to be had there, it's more in making all those OTHER elements easier for me.
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.
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.
We don't have production access to your databases, it's a pretty fundamental part of our value prop. Database credentials can be stored in your own secret store (i.e. HashiCorp Vault) and is loaded directly from there by the proxy. And if you are concerned about the UI harvesting credentials as they are being entered, you can self-host the web app as well for full isolation.
We are also expanding our IaC support, many of the configurations in our product can be defined as YAML in a git repository with webhooks. For deployment, we provide helm charts [1] and terraform modules [2] to include in your existing ci/cd pipeline.
[1] https://charts.jumpwire.ai [2] https://github.com/jumpwire-ai/infrastructure-tools/tree/mai...
We haven't set up a public test suite or bug bounty program yet, but will look into this, it makes a lot of sense.