Security - Data At Rest Encryption

OVERVIEW

Data at rest data refers to the data which is stored in the database, hard disk, etc. in the servers as well as the cloud or any other device or network. It is important to protect data at rest as much as data in transit; as sensitive data in large sizes are stored, and if not secured effectively - can be easy for attackers to gain access to them. Similar to using TLS for encrypting data in transit we must encrypt the data at rest.

Types of sensitive data (including but not limited to)

  • Login credentials
  • Phone Number
  • Email Address
  • Masked Account Numbers
  • Consent ID
  • Consent Artefact

Data at rest must be encrypted to protect against physical theft as well as logical theft; so that the data cannot be decrypted in case of a breach. The following are the main security standards followed:

  • For Symmetric encryption and hashes, 256 bits is used for higher security.
  • One-way hash functions based on strong cryptography also called hashed index are used, which display only index data pointing to records in the database where sensitive data actually resides.
  • Truncation is done to remove a data segment, such as showing only the last four digits.
  • Strong cryptography with associated key management processes and procedures are followed.
  • Decryption keys are checked to not be tied to user accounts.
  • Encryption keys used for encryption of sensitive data are protected against both disclosure and misuse by strong key management policy.

FIU and FIP (DATA AT REST ENCRYPTION)

MYSQL Encryption

  • All sensitive data stored in the database is done so only in encrypted format.
  • Strong AES 256 encryption is used for the InnoDB (storage engine for MySQL) tables tables.
  • InnoDB uses a two-tier encryption key architecture, consisting of a master encryption key and tablespace keys.
  • The tablespace is encrypted and stored in the tablespace header.
  • When an application or authenticated user wants to access encrypted data, InnoDB uses a master encryption key to decrypt the tablespace key.
  • The decrypted version of a tablespace key never changes, but the master encryption key can be changed as required.This action is referred to as master key rotation.
  • All MySQL editions provide a keyring_file plugin, which stores keyring data in a file local to the server host.
  • The master key is protected inside the keyfile.
  • The data-at-rest encryption feature relies on a keyring plugin for master encryption key management.
  • The master encryption key is rotated periodically and whenever it is suspected that the key has been compromised.
  • The private key is stored in a different instance so that in case the database is compromised, the attacker cannot obtain the key to decrypt the data.
  • If a server failure occurs during an encryption operation, the operation is rolled forward when the server is restarted.
  • If a server failure occurs during master key rotation, InnoDB continues the operation on server restart. Key Storage (Using HSM)
  • A Hardware security module (HSM) is a dedicated hardware machine with an embedded processor to perform cryptographic operations and protect cryptographic keys. An HSM will guard encryption keys through every stage of their lifecycle, including creation, import, export, usage, rotation, destruction and auditing.
  • FinShare and FinPro applications integrate with HSM software provided by customers and use HSM APIs for encryption key lifecycle management.
  • The keys are rotated every 1 year and also in case of suspicion of a breach or tampering of the storage.