Centralized Management of TDE Oracle Wallets on a Separate Machine

Note: Below is a re-posting of the February 19th, 2014 article about centrally managing TDE wallets on a separate machine. This post originally appeared on the Oracle Advanced Security blog, and we are moving it here to the key management blog for the convenience of our readers.

* * * * * * * * * * * * * * * *

We have been getting questions about whether it is possible to store the Oracle Wallet used by TDE on a location that is physically separate from the database host machine. Because Oracle Wallets are just files and because the database’s touch of the wallet file is fairly "light-weight", you certainly can store the wallet elsewhere – and there are various approaches for doing this. Note that the Oracle Database accesses to the TDE wallet file infrequently. For normal day-to-day database operations, the wallet typically will be in an open state with the TDE master keys (current and historical) loaded by the database and no direct reads/writes to the underlying file.

I want to point out before getting too deep into the weeds that I view physical separation of the wallet file from the database host machine as optional. Your particular auditor or assessor may disagree with this. My rationale is that you can lock-down access to the wallet file quite tightly when it is on the same machine as the database by leveraging proven and effective file security mechanisms that have been used widely for a number of years. To be specific, you can utilize native operating system and file system permissions to lock down the wallet storage location, and on certain operating systems and file systems, you also can set the "immutable bit", which prevents even the OS root user from accidentally altering/deleting the wallet. Moreover, the standard password-based wallet itself is encrypted using a password derived encryption key according to the PKCS12 and PKCS5 standards, so you get another layer of security by restricting knowledge of the wallet password to a few trusted users. You can even split-up knowledge of the wallet password, dividing it among multiple users. Net net, the Oracle Wallet is always separate from the TDE encrypted data, and it is possible to keep the wallet quite secure when it is stored on the same physical machine as the database.

(The default storage location that I usually recommend for the TDE wallet is a path outside of $ORACLE_BASE on the database host. For example, something like /etc/ORACLE/WALLETS/<$ORACLE_SID> on Linux.)

One other important point here: if you are like most IT organizations, then storage volumes accessible to the database host machine often are located on physically separate hardware already – namely, dedicated SAN and Enterprise NAS storage hardware. When your database host mounts a storage volume provided by SAN/NAS and that volume has a standard file system, then you can easily store the wallet file there, thus achieving the desired physical separation.

If these points are not enough to satisfy your particular auditor or assessor, and they simply are demanding that storage of the TDE master key reside on a specialized key management device or on a secure network directory, then rest assured that you can do this too. I am not going to dwell on specialized key management devices in this blog post (more to come on that topic later), but I would like to describe a few recommendations for storing the wallet on a network directory should you elect to go down this path.

The following slide summarizes storing the wallet on a network directory:

I setup this configuration a few months back in a virtual environment, and it worked great. Here are a couple of recommendations for you based on that experience:

  • To secure the connection to the network directory, I tunneled SMB over a mutually authenticated and encrypted SSH connection using an RSA key pair. To further harden the share, you should close non-essential ports on the file server using software and/or hardware firewall and take other standard security precautions. Note that I used SMB for the share due to the tie-ins with Kerberos, Active Directory and LDAP, but there is no reason you could not employ NFS instead – just make sure to use a recent secure version of NFS and setup an authenticated and encrypted connection.
  • For TDE running on Oracle RAC nodes, I recommend that you setup the subdirectories inside of the network directory as /<$ORACLE_SID OF THE DATABASE>/<HOSTNAME OF THE RAC NODE>. Then, each <HOSTNAME...> subdirectory has an identical copy of the wallet file for the <$ORACLE_SID...> database. Note that you should never attempt to share a single TDE wallet across multiple running Oracle Databases (it is always one wallet per database), and for RAC, you need to have a copy of that wallet accessible to each node (exceptions: you can have per-database wallets that are shared by all RAC nodes if you are using Oracle ACFS or if you are on Oracle Database 12c, which supports wallet storage directly in Oracle ASM).

Remember that if you are storing the TDE wallets on a network directory, then availability of the TDE master key and availability of all your TDE encrypted data will be dependent on availability of the network. In certain environments where the network is not always up, that could be a critical dependency for you to consider, and in other environments it could be a non-issue. Something to keep in mind.

Okay, time to wrap-up…

What you read above was a quick tour of storing TDE wallets on a separate machine. It provided a few insights and recommendations. There certainly are other aspects of this topic and other approaches where I am not getting into great detail, but this material gives you one good centralized wallet management pattern to follow. I hope it helps, and please stay tuned for further posts coming soon.


Post a Comment:
Comments are closed for this entry.

Blog covering key management for Oracle.


« July 2016