Security World data and back-up and restore

It should be part of your corporate disaster recovery policy to perform regular back-ups of both your database and associated Security World such that the back-ups remain up to date and synchronized with each other. For further information about backing up the Security World, see Backing up.

The back-up strategies you employ and how you implement them will depend on your particular corporate policies and requirements, and the specifics of the type of configuration you are using. This guide cannot cover all the potential options and complexities, and will only provide broad advice on backup and restoration using the supported forms of database encryption. Whichever back-up or restoration option you use, make sure you have safely tested it before putting it into practice.

When a Security World is created, an ACS cardset is created at the same time. You should choose a quorum of ACS cards in accordance with your corporate security policy. The total number of cards in the ACS cardset should include surplus cards in case of failure or loss of an ACS card. The ACS cards authorize loading of the Security World, and some management operations on its OCS cardsets and softcards (please see the User Guide for your HSM). You should always store your ACS cards in a secure location. Normally, you should not need to use the ACS cardset for everyday use with your SQLEKM provider. However, you may need to use it if you are restoring a Security World that was previously archived and must be reloaded onto an nShield HSM.

An OCS cardset is used to authorize use of encryption keys that are assigned to and protected by that OCS cardset. Softcards perform a similar function. There can be more than one OCS cardset and/or softcard. However, a softcard exists as a single entity and has only passphrase protection. Generally, an OCS cardset is considered more secure than a softcard because it can be created with a quorum of multiple cards, physical presence of the cards is required, and each card can be supplied with its own passphrase. However, these advantages may be somewhat constrained when used with a SQL Server credential, which entails a 1/N quorum and identical passphrase for every card in the OCS cardset for the cards to be used interchangeably with the same credential.

The total number of cards in the OCS cardset should include surplus cards in case of failure or loss of an OCS card. Some of the cards should always be kept in a secure location, and access to OCS cards in everyday use should be restricted to authorized persons.

The presence of a protecting OCS card, or softcard, will be required when performing back-up or restoration operations for a TDE encrypted database. For cell encryption keys, the presence of a protecting OCS card or softcard should only be required for any preliminary encryption or decryption operations before back-up, but should not be required for back-up or restoration itself.

Encryption keys, OCS card data and softcard data, that are protected by the SQLEKM provider are stored in its Security World. Note, if using TDE encryption, this does not apply to the database encryption key (TDEDEK) which is stored as an integral part of the related database. However, it does apply to the TDE wrapping key (TDEKEK) which is used to protect the TDEDEK.

Note that the Security World will hold the encryption keys for ALL current databases it is being employed with. That may include encryption keys for databases you are not specifically backing up. Note also that it may hold encryption keys for the master database that are common to more than one user database. You may find it convenient that you need only one Security World back-up to cover several databases. Otherwise you will need to pursue a policy of one Security World for one database.

Before backing up a database and corresponding Security World, make sure you are using versions of both that are synchronized to each other. That is, the Security World holds all the up to date and correct encryption keys that are being used by the matching database.

When performing back-ups, it is advised to back-up the database first, before backing up the Security World.

Take care you do not delete any encryption keys from the SQLEKM provider that you will later need for restoration. Check if you have keys with duplicate names in the SQLEKM provider. Although technically possible, permitting duplicate names in the SQLEKM provider is not advised as it leads to confusion and possible operational errors. To avoid any future problems with your back-up, if you have keys with duplicate names, consider methods to eliminate the duplicate names, such as re-encrypting data with differently named key(s), before back-up.

If you are backing up a database that uses cell encryption keys, you should ensure that all sensitive data is encrypted first before back-up commences. Before back-up, remove the cell encryption key references from the database itself. If key references are not removed from the database, they will be stored within the database back-up. This should be avoided from a security point of view. If you are backing up a database that is both cell and TDE encrypted, perform the above instructions for the cell encryption keys before continuing with the following instructions for backing up a TDE encrypted database.

When backing up a TDE encrypted database, you must have the TDE credential (including OCS card or softcard) and database wrapping key (TDEKEK) present.

With TDE encryption, the database encryption key (TDEDEK) is an integral part of the related database. It is stored within the back-up, and not in the Security World. Note however, that the TDEDEK is protected by the TDEKEK which is held in the Security World.

If using a shared disk cluster, the exact same database and TDEDEK is being used irrespective of the currently active node. Hence it should not matter which node is currently active when a back-up is made. Similarly, if an availability group is being used with primary and secondary replicas (and no shared disk), the secondary replicas should use the same TDEDEK as the primary, and it should not matter which replica (or node) is being used during a back-up.

Once you have prepared the database as described above, you may back-up the database in a similar manner to an unencrypted database. If you are backing up a TDE encrypted database, it will be backed up while remaining in its encrypted form, which is advantageous from a security point of view. After you have backed up the database, you can then proceed to back-up the associated Security World folder.

The Security World data is encrypted and does not require any further encryption operation to protect it. It can only be used by someone who has access to a quorum of the correct ACS cards, OCS cards, softcards, their passphrases, an nShield HSM and nShield Security World Software. Therefore, back-up should simply consist of making a copy of the Security World file and placing the copy in a safe location.

You should not store back-up copies of the Security World in the same physical location as its corresponding database. You must keep a record of which database and which Security World back-ups correspond to each other, and where they are located.

You should also securely store and keep a record of ACS and OCS cards associated with each Security World, as necessary to restore the keys used by the database. If you are using many ACS or OCS cards, or many symmetric keys with an IDENTITY_VALUE attribute, you may consider securely documenting the associated passwords. Also, the more encryption keys in your Security World, the more necessary it becomes to record which keys are used to encrypt which data.

If you are backing up as part of a long term archive, and you are storing ACS and OCS cards for more than one Security World, make sure you have some way of clearly identifying which cards belong to which Security World.

If you wish to restore from back-ups, make sure you are using corresponding database and Security World copies. Restore the Security World before restoring the corresponding database.

Essentially, restoring a Security World simply means restoring a back-up copy of the Security World folder. If the configuration has not changed, you need only restore the contents of the local folder. If the Security World you are restoring is not already loaded onto your HSM, you will then have to use its ACS cards and associated passphrases to load it.

Before restoring a Security World from a back-up, decide what you wish to do with any existing Security World that you may have in your %NFAST_KMDATA% or %NFAST_KMLOCAL% directory. If you wish to keep it, you may need to perform a back-up on it before proceeding.

If you are restoring a previous version of a Security World that still exists on your nShield HSM, then as a precaution in case of failure, make a local copy of the current Security World contents before proceeding. You may then either merge or replace the existing Security World with your back-up copy.

If you are restoring an archived Security World that no longer exists on your nShield HSM, you will need to use its ACS cards with passphrases in order to reload it. Refer to your nShield HSM User Guide for more information on loading an existing Security World.

Make sure that the Security World is restored on all nShield HSMs within your configuration. Once you have restored the Security World to the SQLEKM provider, restart the SQL Server on the active or primary node you are using in order to pick up the changes. After restoring the Security World, you can then go on to restore the corresponding database.

Restore the database, including a TDE encrypted database, in a similar manner to an unencrypted database.

Once the database is restored, you will require suitable SQL Server logins and associated credentials to use the database and retrieve keys from the Security World. If these are not already present, or you have not restored them by some independent means, you will need to regenerate them. In this case, to access the encryption keys you will need to create new credential(s) that incorporate the OCS cardset(s), or softcard(s), that protect the key(s) you wish to use. Once you have created a credential you must associate it with an authorized login.

For cell encryption keys, once the database is restored with valid credentials and associated login, you can restore the cell encryption keys from the SQLEKM provider by reimporting them. But there is no need to do this until you need the keys. You must be using the correct credentials for the particular keys you wish to reimport, see Re-importing symmetric key or Re-importing an asymmetric key.

If you are restoring a database that uses both cell encryption and TDE encryption, then the database must first be restored for TDE encryption as shown below, before reimporting the cell encryption keys.

The following description focusses on restoring a TDE encrypted database. It assumes the database wrapping key (TDEKEK) has not been reimported into the master database.

Before proceeding to restore a TDE encrypted database:

If using a shared disk cluster, you should only need to perform the following steps on the active node. If using an availability group (with no shared disk) you will need to perform the following steps on the primary and all secondary replicas.