Once you have established your encryption policies and all your data is encrypted, you will need to perform some policy maintenance. Periodically, your encryption policies should be updated with a new key. A new key keeps the encryption cipher the same, but provides new input to the cipher algorithm. The following figure depicts the periodic updating of encryption policies in the life cycle of encrypted data.

Figure 1. Encrypted data life cycle


Encryption policies are rekeyed in several ways. See one of the following sections for more information:

In prior releases, there is one database master key that is not changeable unless encryption is disabled. Encryption keys for objects are derived from database master key. Changing the database master key means that encryption keys for all encrypted objects need to be remade.

The following guidelines apply to object encryption policies:

  • There can be no more than two active encryption policies associated with a database object. The active policies supported are current and either previous or pending.
  • If one policy exists for a database object (the current policy), you can create a new version of the policy. The new version becomes the current policy and the other becomes the previous.
  • If two policies (current and previous) exist for an object, you cannot create another version of the policy until all data encrypted with the previous policy is migrated to the current policy.
  • When a new pending encryption DB policy is created, all encrypted objects will have a new pending policy. The new version becomes the pending policy and the other is still the current.
  • No data blocks will be encrypted with pending object policies.
  • Epolicy …cipher will be allowed when there is a pending object policy. The cipher of pending object policy can be changed.

The following guidelines apply to encryption DB policies:

  • There can be no more than two active encryption policies associated with a database object. The active policies supported are current and either previous or pending.
  • If one policy exists (the current policy), you can create a new version of the policy. The new version becomes the current policy and the other becomes the previous policy.
  • If one policy exists (the current policy), you can create a new pending policy. The new version becomes the pending policy and the other is still the current policy.
  • If there is a current policy and a pending policy, you can activate the pending policy. The new version becomes the current and the other becomes previous.
  • If two policies (current and previous or pending) exist for an object, you cannot create another version of the policy until all data encrypted with the previous policy, is migrated to the current policy, or the pending policy is deleted or goes through activation and migration.

You can also view the history of an encryption policy. See View encryption policy history in the Data Administration tool for instructions.