Using the Copy or Restore Encryption Method on Block Devices
The process for using the Copy or Restore encryption method on block devices and raw disks is much the same as with file systems.
Information for Encrypting Block Devices
-
The Oracle DBA defines a disk group with
secvm
disks/devices. Thensecvm
communicates with the DBA and updates the disk group information. Oracle ASM provides the mapping ofsecvm
devices to physical disks/devices. -
All databases (table space) in a disk group must be encrypted. Do not mix encrypted and non-encrypted databases in a single disk group. Non-encrypted databases must be kept in separate disk groups that are not protected by a CTE Agent.
-
If you want to apply GuardPoints globally to a set of hosts, configure the GuardPoints in a host/client group. This ensures that the same GuardPoints with the same policies are applied to all members of the host/client group. If you plan to configure the host in a host/client group, do not configure GuardPoints at the host level.
-
Partitions are identified by their device name. Device names for partitions vary between platforms.
Prerequisites
-
Verify that there is a good backup of the data to be encrypted. This step is vital.
-
The block device receiving the protected data must be new or clean as all existing data will be unusable.
-
You will need to stop ALL access and services to the data to be encrypted during part of this procedure, and access will NOT be restored until all of the data has been copied to the new location and the encryption process is complete. Make sure that you plan for this outage and that users know the data will be inaccessible for some time.
-
Make sure that you have a CTE production policy with the proper security rules defined for the new GuardPoint. The production policy needs to use the same encryption key that you will be using to initially encrypt the data.
Procedure
-
Make sure that the block devices into which you plan to copy the data are empty and have enough storage space to contain the existing data.
Caution
Any existing data in the target devices will become unusable after this procedure is complete. Make sure that the target devices do not contain any data before you continue with this procedure.
-
Log on to your key manager and, if necessary, switch to the domain containing the host you want to protect.
-
Identify the encryption key you want to use to encrypt the data or create a new encryption key.
-
Create one or more initial encryption policies for the GuardPoints. These policies will only be used to encrypt the data as it is copied into the new block devices, after which you will replace the initial policies with production policies.
a. For Policy Type, select Standard.
b. Add a security rule with:
-
Action: all_ops
-
Effect: Apply Key, Permit
c. Add a Key Rule that specifies the encryption key you want to use. This key must match the one specified in the production policy you intend to apply to the GuardPoint after the data has been encrypted.
-
-
Create a GuardPoint for each block device you want to encrypt. For each GuardPoint:
-
For Policy, select the initial encryption policy you want to use.
-
In the Type field, select either Raw or Block Device (Auto Guard) or Raw or Block Device (Manual Guard).
If you select Auto Guard, CTE starts the guard process as soon as the policy is pushed to the host. You enable, disable, guard, and unguard the GuardPoint in your key manager.
If you select Manual Guard, You guard the GuardPoint on the protected host with the
secfsd -guard <path>
command and unguard it with thesecfsd -unguard <path>
command. At system startup, you must guard the device and then mount it. This gives you more control over when data transformations occur because CTE will not start encrypting or rekeying the device until you manually start the process. -
For Path, enter the path to the device or click Browse. For example,
/dev/sda1
orE:/
.If you click Browse, the selection dialog box shows the available block devices. Inactive partitions are displayed, but open partitions and currently guarded partitions are not displayed.
Note
Third-party applications can open raw devices in obscure ways, and may cause the Remote File Browser to ignore and not display supposedly inactive devices. For example, inactive raw devices in the Oracle DBCA disk discovery path are not displayed in the Remote File Browser, even when the devices are not assigned to a disk group. If /dev/sd is configured in the DBCA disk discovery path and DBCA is running, inactive /dev/sd devices are not displayed in the browser. This is because the devices are kept open by the Oracle process. To get around this problem, close DBCA and open the browser again. The devices are free, displayed in the browser, and available for selection.
-
-
Click OK to apply the policy to the GuardPoint.
Wait until the policy has been applied to the device. This may take up to a minute.
-
Stop ALL access and services to the devices to be encrypted. Make sure no processes, services, or users are currently accessing the data. You cannot restore access to the data until the encryption process is complete.
-
Copy or restore the data from the old operational directory to the newly created GuardPoint. CTE encrypts the data as it is added to the GuardPoint.
Make sure you wait until the encryption process has finished for all data in the GuardPoint before you continue with this procedure.
-
Disable the encryption policy from the new GuardPoint and apply your production policy. Your data is now fully encrypted and you can redirect access to the GuardPoint.
-
Start all services and restore access to the data that is now fully encrypted.
Make sure that the applications and services access the newly created CTE-protected hosts. CTE encrypted raw or block protected hosts are accessed using the directory:
/dev/secvm/dev/xxxxx
wherexxxxx
is the original device name. -
Start application testing and inform application teams that systems are ready for use. Everything should work exactly as before; however, monitor the situation with your users.