Fundamental Security Part Seven– Data Encryption At Rest
09/11/2023 3 Comments
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
Neil Chandler's DB Blog 