Transparent Data Encryption
NuoDB supports Transparent Data Encryption (TDE). When enabled on a database, TDE ensures that user data stored in the archive, the journal, backups, and spill-to-disk files is encrypted before being written to disk.
This page provides overview and background information on TDE. To learn how to enable and manage TDE see Configuring Transparent Data Encryption.
Fully enabling encryption involves two steps: first, a storage password must be assigned to the database using the NuoDB Admin Process
update data-encryption command.
This will allow TDE to be enabled.
Be aware that setting a storage password does not cause any storage to be encrypted.
For more information on using this command, see NuoDB Command Reference.
Second, the database administrator must invoke the
ALTER DATABASE CHANGE ENCRYPTION TYPE SQL command.
This command will not succeed unless a storage password has already been configured on the database.
Once this command succeeds, storage on all NuoDB engines in that database will start to be encrypted.
For more information on running this command, see the ALTER DATABASE reference section.
Encrypted content is secured with a storage password, which must be provided by the domain administrator using NuoDB Admin.
This password is separate from any SQL user password.
It is used only for TDE and must be provided to the domain before starting a TDE-enabled database.
It will also need to be provided by the user when using
nuoarchive on a TDE-enabled archive or hot copy.
Each database has its own storage password and all SMs and TEs in a database use the same storage password.
|NuoDB, Inc. cannot recover Transparent Data Encryption storage passwords, and the database cannot be loaded if its storage password is lost. It is the user’s responsibility to keep track of storage passwords, including historical passwords for encrypted hot copy backups.|
Storage passwords are never saved to disk by any NuoDB process.
NuoDB Admin will preserve storage passwords in memory throughout the domain. Upon joining an existing domain, new NuoDB Admin processes will be provided with the storage passwords known by the domain. If the domain is fully restarted, the domain administrator must provide NuoDB Admin with the storage password in effect when each TDE-enabled database was shut down, before that database can be restarted.
NuoDB Admin does not write the storage password to disk but it will store a one-way hash of the storage password into the raft log. The storage password cannot be recovered from this hashed value and so the hashed value cannot be used to start a database; it is used to verify that the domain administrator knows the current storage password before it can be changed.
The domain administrator can use NuoDB Admin to change the storage password of a database at any time. All SMs and TEs that are online when the storage password is changed will be updated immediately.
If an SM is not online when the storage password is changed, the storage password used to encrypt its archive will not be updated. NuoDB Admin will keep previous storage passwords in memory and provide both the current storage password and previous storage password(s) when starting an SM. As long as the archive’s storage password is any one of those provided, the SM will be able to start.
If an SM starts and discovers that it needs to use one of the previous storage passwords to decrypt the archive, it will automatically change the archive to use the current storage password: no explicit commands need to be run.
If none of the storage passwords known by NuoDB Admin are the correct storage password for the archive, the SM will fail to start and the domain administrator will need to provide NuoDB Admin with the storage password needed by that archive, then re-start the SM.
The storage password is necessary, but not sufficient, to allow decryption of the archive: additional encryption information is stored in the archive itself, in the
If this file is lost or corrupted then the archive cannot be recovered, even if the storage password is known and the rest of the archive is still available.
The preferred solution for an unrecoverable archive is either to remove it and allow it to be synced from another SM in the database, or if that is not possible to recover the archive from backup and restart the database using the recovered copy.
To preserve the possibility of decrypting the archive when the
state.dat file is lost or corrupted, you can run
nuoarchive check --show-archive-history <archive-dir> and preserve the generated XML output.
There is no way for users to rebuild the
state.dat file from this XML output: in the event of this last resort you will have to contact NuoDB Support for assistance, and provide them with the XML file.
When the encryption type is changed using the
ALTER DATABASE CHANGE ENCRYPTION command, SMs and TEs will immediately start using the new encryption type for all data written to disk.
In addition, SMs will start converting their archives to the new encryption type in the background.
The SMs will attempt to ensure that this conversion doesn’t adversely impact the normal operation of the database, so the encryption may take some time to complete for larger archives.
If the SM is restarted while encryption is in progress, the encryption will automatically start from where it left off and run to completion. It is not necessary to wait for the conversion to complete before changing the encryption type again: the previous conversion will be canceled and the new conversion started. For example, it is possible to enable encryption then disable it again, before the encryption had completed.
The state of encryption for each node can be monitored by querying the
disk_encryption column in the
system.nodes SQL table.
While encryption is in progress the
disk_encryption column will contain both the encryption type and a percentage of the archive which has been encrypted.
When encryption is complete
disk_encryption will contain only the cipher name.
Backups created from databases with TDE enabled will also be encrypted. The storage password for the backup will be the one in effect when it was created. A backup set may have a different storage password for different backup elements if the storage password was changed while the backup set was active. The storage password(s) required to decrypt the backup should be placed into escrow at the same time as the backup, to ensure it can be recovered.
When restoring a backup set with TDE enabled,
nuoarchive restore will ask for the storage password.