Policies
Policies declare how fields matching a given label should be handled. Each policy is composed of four components:
- A unique name
- The handling to apply to matching fields
- A field label indicating when this policy is applied
- Optionally, a connection classification that can bypass the policy
The audit policy will generate an event stream that records the source data for whenever a field matches. The audit log destination is configurable and completely separate from operational application logs.
Blocking the event causes the entire blob of data to be dropped if any field in it matches the corresponding label.
For database queries, the row itself is removed from the query response.
With API data, an empty object is returned with no fields in it.
The drop fields handling policy will cause matching fields to be removed from data passing through JumpWire. The actual field key will remain, but the value is set to null.
Tokenization is currently in beta and not enabled by default. If you are interested in trying it out with your account, let us know!
Tokenization policies transform matching fields into a deterministic token. The token is formed from a SHA256 hash of the source value combined with some metadata. The source value is encrypted and stored alongside the token. The note below concerning PGP keys applies to both encryption and tokenization when JumpWire is acting as a database proxy.
JumpWire will automatically convert a token back to its original value for connections with permitted classifications. An API endpoint is also available for clients that need to detokenize a value but don't directly connect to the JumpWire proxy.
Encryption handling causes all fields matching the policy label to be encrypted. Both asymmetric PGP RSA keys and symmetric AES keys are supported.
JumpWire will automatically decrypt values for connections with permitted classifications. If the labeled field is already decrypted, it will be passed along as is.
Raw and encrypted fields can be safely mixed, such as when a database has existing data that not been migrated. The raw data will be encrypted on the fly before JumpWire returns the query result, and the data source will not be updated.
PGP Keys and Databases
When using PGP for encryption or tokenization in any encryption mode, databases will additionally be configured to encrypt matching fields on updates or inserts. This ensures that even if an application bypasses JumpWire to insert directly in the database, the raw value will be safely handled.
Only the public key and encrypted values exists on the database - a full database backup will not be sufficient to decrypt the original values as the private key is never sent to the database.
There are several different encryption modes JumpWire can be configured to use:
Backfill mode is only relevant for database proxies. When used with an API gateway, backfill behaves the same as streaming.
When operating in backfill mode, JumpWire will automatically migrate existing unencrypted fields as soon as a matching database and policy are enabled. While this is the simplest way to ensure the database does not have any raw sensitive data, it can temporarily cause performance issues if not configured correctly.
A safe approach is to use streaming encryption when setting up JumpWire, and separately run a backfill task to migrate existing data once the policies and schemas are all configured as desired.
