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 handling options audit 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 block 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 drop fields 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 tokenize 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 encrypt 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 in streaming mode, data is encrypted and decrypted as it enters jumpwire the classification of the current connection determines whether to return encrypted or decrypted results existing data is never automatically updated only queries going through jumpwire are transformed