Skip to main content

Encryption & Tokenization

Encryption​

InCountry Data Residency-as-a-Service uses the industry-standard symmetric encryption algorithm - AES in the GCM mode with 256-bit long keys. All encryption keys are stored in InCountry’s secured keys vault. This keys vault meets all high industry standards and provides secure storage of encryption keys.

All InCountry services encrypt data at rest provided to them by customer’s applications. All data communications between components of the InCountry platform (including data in transit) use the HTTPS protocol and TLS 1.3 by default.

Key Management​

Management of encryption keys is performed on the InCountry Portal. It generates a separate encryption key for each activated country within an environment. For the details on management of encryption keys, please check our documentation.

The InCountry Portal supports the automatic rotation of encryption keys according to the configured rotation period.

Bring Your Own Key (BYOK) support​

InCountry platform supports AWS KMS. For the details on BYOK support, please check our documentation.

Tokenization and Hashing​

InCountry provides the Web Services Proxy which supports a variety of redaction algorithms that you can use to anonymize data so they will not break your application backend validations, and also supports the patterns for outputted values.

Redaction Strategies​

Web Services Proxy supports the following algorithms of the data anonymization:

  • alphaNumeric - applies an alphanumeric hash to a string containing letters and numbers. The produced alphanumeric string varies during every redaction.
  • alphaNumericLowerCase - applies a lower-case alphanumeric hash to a string containing letters and numbers.
  • alphaPrepended - applies a prefix comprising a single letter.
  • email - applies an email-pattern string, e.g. dsf34fsdf@redactedemail.com. The produced email-pattern string varies during every redaction.
  • plain - forwards the original value.
  • one - applies '1' ( a single digit).
  • zero - applies '0' (a single digit).
  • numeric - applies a random numeric value of the length equal to the original value.
  • dateISO - applies a random date in the ISO format.
  • defaultDateISO - applies a random date in the default ISO format (1970-01-01T00:00:00Z).
  • fixed - applies any hardcoded value. If you select this option, in the Value box, enter the value that should be applied by default.
  • emailPersistent - applies an email-pattern string that remains the same for the same email address during every redaction.
  • alphaNumericPersistent - applies an alphanumeric hash that remains the same for the same alphanumeric string during every redaction.

For the details, please see the documentation about how to configure CRUD operations through Web Services Proxy.

Data Masking​

Web Services Proxy supports the following data masking algorithms for the outputted values:

  1. default - Web Services will use the initial redaction algorithm used for this field in the configured redaction algorithm.
  2. fixed - Web Services will apply the fixed value you enter in the Value field, for example, John Doe can be replaced with REDACTED.
  3. masking - Web Services will apply the masking value to the original clear text value, for example, John Doe can be replaced with J**** D****. For this algorithm, you can specify additional settings:
    1. Type - select the value type (alphanumeric or email).
    2. Masking after N characters - specify the number of characters that will be preserved as is at the string beginning. All the characters then will be masked with the masking character.
    3. Masking character - enter the character that will mask values from the original clear-text value, for example, * (asterisk), @ (ampersand) or X.
    4. Masking length - specify the number of masking characters applied to the string.
    5. Value delimiter - delimiter to separate values with.

For the details, please see the documentation for data masking.

Currently, supported data masking strategies in RestAPI are: alphanumeric, email, and numeric. Strategies supported for string type:

  • alphanumeric turns a string of delimiter separated values into masked values. For this algorithm, you can specify additional settings:

    1. After N characters - specify the number of characters that will be preserved as is at the value beginning. All the characters then will be masked with the masking character.

    2. Character - enter the character that will mask values from the original clear-text value, for example, * (asterisk), @ (ampersand) or X.

    3. Length - specify the number of masking characters applied to the value.

    4. Value delimiter - delimiter to separate values with.

      For example, "John Doe" turning into "Jo* Do*" using the following params: After N characters=2, Character=*, Length=1, Value delimiter=" ".

  • email works similar to alphanumeric, but doesn’t use the delimiter option and keeps the original domain name, e.g. turning "johndoe@gmail.com" into "jo**@gmail.com" using the following params: After N characters=2, Character=*, Length=2.

Strategies supported for numeric type:

  • numeric - replaces the input number with a completely random number of the same order of magnitude, e.g. 12345 will be replaced with ABCDE, where A, B, C, D, E - any number between 0 and 9 (except A is between 1 and 9), e.g. 52612. (or e.g. 1.23 replaced with 7.25 for decimals).

For the details, please see the documentation about how to create access policy and add masking here.

How to adjust the user interface if a field is redacted/masked?​

Let's assume that in your application frontend, you would like to disable edit action for redacted/masked field. The implication is that your application should know which fields are redacted or masked.

info

In the future, we are going to add some meta information for fields in the response that will allow you to determine if the fields are masked/redacted or contain original values.