Skip to main content
Version: 2.24.0

Multi-Region

This section will demonstrate eXate’s ability to maintain the sovereignty of keys and processes when handling multi-region data. The vault is used for all cross-region configurations to store the corresponding connection information for each country.

Multi-Region Connection Storage​

As previously mentioned, the “Connection Storage” menu can be found under the “Location” section of the Vault. It defines all custom connection stores that you will be using to store “Keys” and “Shards” that are important in managing location specific data.

We securely store the connection strings for the distributed databases used to manage location specific data, the example showcasing this for Swiss data. The figure shows how we created a connection store for “Key-CH” and specified the “Connection Usage Type” as “Key”, meaning it can only be used for a Key Store. However, the same can be done to store Ciphertext Shards (Ciphertext is split into multiple parts – and can also be held within jurisdiction).

Key Connection Storage Configuration​

The “Key” configuration within the “Connection Storage” menu. As can be seen in the example, there are 3 Key Stores mapped currently. The Key Stores created previously can then be selected and mapped with a country. This will inform the application, which Key Store to access for a specific country. All Keys used for Pseudonymise + KeyAuthorisations + KeyRequest audits will be stored per KeyStore, per country.

Shard CConnection Storage Configuration​

Once again, these can be selected and mapped with a country. This informs the application which “Shard Store” to access for a specific country. Once the data is protected, it is broken into 3 parts, called “Shards”, and stored in the respective “Shard Stores”. One part of the shard is sent back to the user as the protected output. This is used to identify the information and reconstruct it when required.

The idea of breaking into shards is that it is an incomplete “Ciphertext” and all parts need to be assembled to allow for reconstruction. This is due to certain rules around Ciphertext being personal data still – this additional step means majority of Ciphertext can be held in jurisdiction and only the token of the metadata identifier and partial Cipher Text is passed to the calling application. The breakdown into Shards serves a second purpose is that it adheres to existing column length restrictions.

FPE Connection Storage Configuration​

Format-Preserving Encryption (FPE) refers to encrypting in such a way that the output (the ciphertext) is in the same format as the input (the plaintext). We use this to protect Dates, Integers, Strings and return the same type back, it will preserve the type of the data to ensure we remain compatible with downstream requirements. FPE Keys also need to be stored in their corresponding regions, so we use the FPE config screen to set that up in a similar way to the setup of Key and Shard Connection Storages. You need to choose the Data Source, Country and enter the FPE Key.

Database Audit​

Once you have connection storages set-up, as demonstrated in the previous section, you can perform database audits. These are snapshots of the key request information of the database, mapped against the country chosen during configuration (in this example it is Switzerland). For every key access request to the database, an entry is logged in the “KeyRequest” table of the Keys database located in that region.

  • KeyReleaseId: Unique Id for each Key Request

  • KeyAuthorisationId: This is used to identify whether the Key is authorised for a specific user, firm and fetch the respective encrypt / decrypt key from the database

  • Username: Login Id of the user requesting the access

  • KeyGranted: Boolean field to indicate whether the access is granted or not

  • DateRequested: UTC datetime of when the Key was requested

  • TypeOfAccessRequest: The access type for the Key -> Request, Create, Delete