Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases

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

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

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.

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.

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.

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...

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.

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.

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.

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.

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...

> 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.

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.

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

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.

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.

The proxy layer is self-hosted, the UI can be self-hosted and the keys are your own AWS KMS keys.