Skip to content

Multi-Region

This page covers eXate's ability to maintain the sovereignty of keys and processes when handling multi-region data. The Vault handles all cross-region configurations, storing the corresponding connection information for each country. This is the operational mechanism behind the Data Sovereignty Concepts described in the Platform overview.

Multi-Region Connection Storage

The Connection Storage menu, under Location, defines all custom connection stores used to store Keys and Shards for location-specific data.

Connection strings for the distributed databases used to manage location-specific data are stored securely. For example, a connection store named "Key-CH" with Connection Usage Type set to "Key" means it can only be used for a Key Store. The same pattern applies to storing Ciphertext Shards, since ciphertext can be split into multiple parts and each part held within its own jurisdiction.

Key Connection Storage Configuration

Key Stores created in Connection Storage can be selected and mapped to a country, informing the application which Key Store to access for a given country. All keys used for Pseudonymise, KeyAuthorisations, and KeyRequest audits are stored per Key Store, per country.

Shard Connection Storage Configuration

Shard Stores are mapped to a country the same way, informing the application which Shard Store to access for that country.

Once data is protected, it's broken into multiple parts called Shards, stored in the respective Shard Stores. One part of the shard is returned to the user as the protected output, used to identify the information and reconstruct it when required.

Breaking data into shards means an incomplete ciphertext, requiring all parts to be assembled for reconstruction. This matters because ciphertext is still considered personal data under certain rules, so most ciphertext can be held in-jurisdiction while only the token/metadata identifier and a partial ciphertext are passed to the calling application. This also helps the data conform to existing column length restrictions.

FPE Connection Storage Configuration

Format-Preserving Encryption (FPE) encrypts data such that the ciphertext output is in the same format as the plaintext input, for example protecting Dates, Integers, and Strings while preserving their type, keeping downstream systems compatible.

FPE keys need to be stored in their corresponding regions, configured through the FPE screen the same way as Key and Shard Connection Storages: choose the Data Source, Country, and enter the FPE Key.

Database Audit

Once connection storages are set up, you can perform database audits, snapshots of key request information mapped against the configured country. For every key access request, an entry is logged in the KeyRequest table of the Keys database in that region:

  • KeyReleaseId: unique ID for each key request
  • KeyAuthorisationId: identifies whether the key is authorised for a specific user and firm, and fetches the respective encrypt/decrypt key from the database
  • Username: login ID of the user requesting access
  • KeyGranted: boolean field indicating whether access was granted
  • DateRequested: UTC datetime of when the key was requested
  • TypeOfAccessRequest: the access type, Request, Create, or Delete