Implications of Data Encryption for Database Design and Operations
• When the passphrase is changed, database backups before this point in time must be accessed using the old passphrase. Subsequent backups must be accessed using the new passphrase. When restoring from a pre-existing database backup, log records cannot be rolled forward beyond the execution of the ALTER PASSPHRASE statement. It is therefore recommended to perform a new database backup after changing the passphrase.
• When the passphrase is changed, the main key is decrypted using the old passphrase, re-encrypted using the new passphrase, and then replaced in its storage location. The user data is not re-encrypted because only the passphrase — not the underlying table encryption keys — has changed.
• If the option NEWKEY is specified, the meta data containing the table keys is decrypted with the old database key and re-encrypted with the new database key. To perform this, a full write lock on the database is needed, and depending on the size of the meta data involved it can be a computationally expensive operation.
• If a backup or replication method works at the binary level by transferring and applying journal records, the original table and the replicate table must use the same table key. This will be the case if the replicate system originally was copied at the binary level (and the table key was not changed afterwards via ALTER KEYS).
Note: In encrypted databases, tables that use the same table key for encrypting user data can be protected by different passphrases.
• Encrypted data is usually unique at the binary level for each database. But outside of the database the data is not protected in the same manner. When data is copied to a flat file, it is unprotected. Such files should use an external protection method, such as password encrypting the entire file, or writing it to an encrypted device or file system.
• Encryption and Copydb/Unloaddb Considerations
Database encryption does not protect data outside the database, including files generated by the copydb, unloaddb, and genxml utilities.
• Optimizedb Considerations for Data at Rest Encryption
When the optimizedb utility is used to create statistics for columns, the histogram cells will contain unencrypted (plain text) data. The histogram cells are statistical extracts and cannot be linked back to a specific row in the table (except when there is only a single table row). Nevertheless, depending on the nature of the data and your business, this may be considered a security breach.
If columns should be excluded, then the optimizedb -r (relation) and -a (attribute) flags can be used to specify for which tables and columns to generate statistics.
You can use the statdump command to verify which columns have had statistics generated for them.
Last modified date: 12/19/2024