Verifying Database Encryption
Option 1
The best way to verify the state of the data, without impacting anything in the existing environment, is to use the Oracle kfed command. You can run this command against the native path of the existing GuardPoints and make sure it returns with valid header information. If it returns valid information with the GuardPoint in place, then this confirms that the data is properly encrypted. If it returns with invalid header information, then that indicates that the data is either clear, double encrypted, or not in the expected encrypted state. The syntax for running this command would look similar to the following but will vary based on your environment.
If the location is properly encrypted, following is an example of the viewable output:
System Response:
Option 2
The second option to verify the state of the data is to use the dd command. This requires you to specify some blocks and write it out to a file. After this completes, read the file using the strings command. You can do this while the device is in use. In the example below some sectors are skipped and it only dumps 10000 counts.
For example:
Option 3
The third option to verify the state of the data without impacting the existing environment is to use the strings command.
Note
The strings command cannot read a busy or large device.
You can run this command against the native path (/dev/<deviceName>
) of the existing GuardPoints (/dev/secvm/dev/<deviceName>
). The new path to SecVM would be similar to /dev/secvm/dev/<deviceName>
. By executing the strings command against the native path strings /dev/devicename | more
, this does not go through the SecVM device and therefore is not be decrypted. If it is encrypted the output should contain illegible text.