Feature request: Add ability on first start up for TDE

[astb01]

Hi

I would like to be able to use TDE but haven’t got an idea where to start as the documentation talks about setting up a keystore/wallet etc and trying ALTER SYSTEM SET ENCRYPTION… doesn’t work due to not being in the root container?

Please could you add this feature in or show an example of how it can be enabled on an 18x XE image?

Suggestion perhaps in the docker image:

ENABLE_TDE=yes
WALLET_PASSWORD=foo

then on first start up these environment variables are read and the sqlora.net file is edited and the wallet set up with the instance created with encryption?

Obviously it would require the init.sql to contain encrypted table spaces etc and the start up be slower as I read that TDE may require a database reboot for it to initiate?!

[gvenzl]

Hi @astb01,

Thanks a lot for your feature request!

Oracle Database provides a lot of features and functionalities that make it the number 1 database on the market.
However, abstracting all of the bells and whistles of Oracle Database into container parameters is unfortunately not feasible nor desirable. These images aim to provide easy-to-use, general-purpose Oracle Database containers. Additional setup of any and many of the features and functionalities of Oracle DB is left to startup scripts or, of course, to users to extend these images, where they can tailor the database setup to their needs and decide on the many parameters and choices they have.

That being said, I can see the usefulness of an example of how to set up encrypted tablespaces and thanks to @dhaanpaa-lab0 we now have an examples directory where this will fit in nicely.

So instead of adding this as a feature, I will work on adding this as an example.

[astb01]

Hi @gvenzl - I was thinking it could be an enhancement that allows you to enable TDE on the image (on the initial run - subsequent re-use would imply TDE is enabled/ignored) such that when you want to apply TDE at a tablespace/table/column level you can do easily?

This is very useful if you want to have a non-production image for local testing that has TDE enabled.

I.e so you can the initialise an instance using SQL:

create tablespace BLAH ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT) ...

[gvenzl]

Hi @astb01,

All that is necessary to create an encrypted tablespace is to first create a keystore (wallet) to store the TDE master encryption key.

However, as it is so often with security, there are many choices depending on how secure one wants to be.

For example, whether that keystore should be software-based, Key Vault, OCI Vault, or hardware-based.
If it is a software-based one, the next question would be whether it should be password-protected, an auto-login keystore, or a local auto-login keystore.

Next, whether that keystore should be for the entire CDB (United Mode), or separate keystores for each PDB (Isolation Mode), each of which could now again be of different types above.
Additionally, the United Mode will make it more difficult to unplug a PDB and plug it in somewhere else.

Then there is the question of where the keystore(s) should be stored on the filesystem.
If it's ever lost or the password is forgotten, nobody will be able to ever unencrypt the data.
On the other hand, if it's using a default password or is an auto-login one, if it's put in an insecure location, anybody who gets hold of it is now able to unencrypt the data. It would be just like handing out a private SSH key.

I understand that probably nothing of that matters to someone who wants to just quickly test something against an encrypted tablespace and throw away the data again.
But it will matter a lot to anybody who does care about the security of the data and who will find a standard mechanism quickly insecure and insufficient.
Users who do care about security will know what they want and how to configure it.

For the user who just wants to quickly test something against an encrypted tablespace, I rather prefer to provide an example on how to create a default keystore with I think three or four commands that he or she can copy/paste into an initialization script first before creating the encrypted tablespaces – and with a big disclaimer that this is not a reliable secure way to encrypt the data.

[astb01]

@gvenzl - a set of commands and configuration for the encryption would be ideal - hopefully someone can upload one.

[gvenzl]

Hi @astb01,

You can now find a little example setup script and the necessary steps to configure the database for tablespace encryption in examples/setup-tde.sh.

You can, for example, just copy it under /tmp/tde (making sure that the container user has read privileges) and run it as initialization script:

podman run --name test -p 1521:1521 -e ORACLE_PASSWORD=LetsTest1 -v /tmp/tde:/container-entrypoint-initdb.d gvenzl/oracle-xe:21-slim
CONTAINER: starting up...
...
...
...
CONTAINER: Executing user defined scripts...
CONTAINER: running /container-entrypoint-initdb.d/setup-tde.sh ...

System altered.

Database closed.
Database dismounted.
ORACLE instance shut down.
ORACLE instance started.

Total System Global Area 1241512272 bytes
Fixed Size		    9685328 bytes
Variable Size		  603979776 bytes
Database Buffers	  620756992 bytes
Redo Buffers		    7090176 bytes
Database mounted.
Database opened.

System altered.


keystore altered.


keystore altered.


keystore altered.

Database is now configured for Transparent Data Encryption in United Mode.
CONTAINER: DONE: running /container-entrypoint-initdb.d/setup-tde.sh

CONTAINER: DONE: Executing user defined scripts.


#########################
DATABASE IS READY TO USE!
#########################

From then on, you can create encrypted tablespaces:

SQL> CREATE BIGFILE TABLESPACE DATA
     DATAFILE '/opt/oracle/oradata/XE/XEPDB1/data01.dbf'
     SIZE 10m ENCRYPTION USING 'AES256' ENCRYPT;

TABLESPACE DATA created.

Thanks a lot for your suggestion and of course feel free to use that example script as a template to amend for your encryption configuration needs.