Fundamental Security Part Seven– Data Encryption At Rest

October 2023 – Oracle 19C+

What is Data Encryption At Rest and why should we use it?

We have looked at Data Encryption in Transit, encrypting your network traffic. Everyone should be doing this. But what about Encrypting Data At Rest? Data that is stored permanently (on your hard drives).

---

The simplest way to do this, from a database/DBA perspective, is to use an encrypted storage device. Most SAN/NAS devices come with encryption built-in, and encryption of the storage presented to servers is abstracted away to the SAN. The CPU overhead is handled by the SAN and you don’t need to worry about it. However, if you are using Exadata or any Oracle Cloud Service, this is not an option. You will need to implement Oracle Transparent Data Encryption. This is mandatory with the Oracle Cloud. Some cloud providers provide a Storage-Level encryption option (which is frequently an added cost and is usually not the default!)

Why Do This?

There are 3 reasons to implement Encryption At Rest

1. In case the hardware gets stolen. This may not just be directly from your data centre, but following the decommissioning or break/replace of the hardware too.
2. Bypassing database controls to read or amend the data in your database directly from the files.
3. Because the auditors insist upon it (see points 1 and 2)

Storage-Level Encryption [SLE] v Oracle Transparent Data Encryption [TDE]

Neither Storage-Level Encryption [SLE] nor TDE means your data is safe. The processes running against your data need to see it unencrypted. If the processes can do this, so can suitably privileged Operating System administrators.

No matter what security you have put within your databases to prevent unauthorised access to your data, if your data is unencrypted (or encrypted using SLE where it is presented to the server “unencrypted”), you can run a “dd” (in Linux, other O/S have similar commands) and view the data directly. Don’t think for a moment that because it is in an Oracle internal format that it is difficult to read.

> create table read_me (c1 varchar2(1000)) tablespace users
;
Table created.

> insert into read_me values ('I CAN SEE YOU!');
1 row created.

> commit;
Commit complete.

select segment_name,block_id,blocks from dba_extents where segment_name = 'READ_ME';

SEGMENT_NAME                     BLOCK_ID     BLOCKS
------------------------------ ---------- ----------
READ_ME                               136          8

$ dd if=./users01.dbf bs=8192 skip=136 count=8 | od -xa --endian=big

*
0157740    0000    0000    0000    0000    0000    2c01    010e    4920
        nul nul nul nul nul nul nul nul nul nul   , soh soh  so   I  sp
0157760    4341    4e20    5345    4520    594f    5521    0106    7004
          C   A   N  sp   S   E   E  sp   Y   O   U   ! soh ack   p eot
0160000    06a2    0000    8f00    c003    6f04    4200    0000    0204
        ack   " nul nul  si nul   @ etx   o eot   B nul nul nul stx eot
0160020    73e2    0000    0100    0000    4426    0100    6f04    4200
          s   b nul nul soh nul nul nul   D   & soh nul   o eot   B nul
0160040    0080    0000    0200    3200    8800    c003    0000    0000
        nul nul nul nul stx nul   2 nul  bs nul   @ etx nul nul nul nul
0160060    0000    0000    0000    0000    0000    0000    0000    0000
        nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*

Encrypting your data on the storage layer DOES NOT PREVENT this sort of access or potential attack.

Oracle Transparent Data Encryption [TDE]

First of all, Oracle Transparent Data Encryption is a COST OPTION. It is not part of the standard Oracle license.

TDE encrypts the actual Oracle data files. Running a “dd” against an encrypted tablespace reveals no usable information. However, you now need to handle all of the keys to be able to open your databases. Key management is the most important aspect of using TDE, ensuring they are available and are not compromised. If you lose the keys, your data is unrecoverable. Remember to backup the keys at the same time (but not with!) as the database as you will need the relevant key should you need to recover the database.

Important note: Most companies who implement TDE do it at the tablespace level. This means the data on disk is encrypted and the CPU overhead is generally low. However, data in memory is NOT encrypted. In Linux, as memory is effectively treated as a file by the O/S, it is possible to read whatever is in your buffer cache using the “dd” method. If you are very skilled (hackers are!), this is also possible from the dom0 layer of the hypervisor, which is accessible by the staff of the cloud provider. Only data encrypted at a column level remains encrypted within the buffer cache. The overhead for accessing column-level encrypted data is high.

It is debatable whether data in the server memory is “at rest”. If you have extremely valuable data, such as credit card information, this should be encrypted by the application (for example by adhering to PCI DSS standards).

For a basic implementation of TDE, I would recommend looking at Tim’s article here (rather than me repeat his excellent website) or one from an Oracle PM here.

When I have time, I’ll do a follow-on article about using a HSM or OKV to manage your keys.

---

Now I would like to talk about Fundamental Security Part Eight – Unified Audit