Encryption (TDE) Query

ron

Member
Hi -- We use OE 11.7.4 on Linux (all chui).

My company is considering employing encryption - so I'm boning-up on it and about to do a few performance tests.

I'm told that if a self-serve client connects to an encrypted DB it is necessary to supply a passphrase. I can understand why -- but it also presents a problem for scheduled jobs (eg started by cron). How would one supply the passphrase?

Is this correct -- and if so -- is there a good way to "accommodate" it?

Ron.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I find it's best to rely on definitive source information rather than second-hand information, where possible. The docs are online, so in this case it is possible.

TDE offers several options in how it can be configured. It is really important to read the docs and understand what those options are and the implications of the decisions you make.

When a TDE-enabled database is opened (not just accessed), the user must authenticate against the TDE keystore with the user passphrase. There are two ways this can be done and it is not the user's choice; it is a configuration decision made up front. The keystore can be configured for manual start, in which the passphrase must be provided when the database is opened (e.g. proserve). Or it can be configured for autostart, in which the user doesn't have to provide the passphrase; if they can authenticate against the database/application, they can access the data.

I'd suggest you also read through this thread for more on manual versus autostart:
Question - TDE and autostarting DBs

The most important thing you can do is arm yourself with first-hand, hands-on knowledge. Read the docs. Get a TDE eval license from PSC or your ISV, as appropriate. Play with it on a sports database. Walk through concepts, setup, backup, restore, D&L, maintenance activities, etc. There is a lot that TDE changes about the product and you need to understand all of it before you dive in. Good luck.
 

TomBascom

Curmudgeon
Also -- make lots of copies of the keys and put them in safe places where people will be able to get them. If you lose the keys *nobody* can help you.
 

ron

Member
Hi ....

I did get a temporary licence for TDE and set-up a test environment with it. I found that there is an abundance of information "out there" about TDE. It is all interesting and useful but it is very oriented towards the complexities of the product -- and a bit light-on with the simple basics.

Setting up a test DB for encryption is not at all difficult -- but it took me quite a while and quite a bit of trial-and-error to get there. However -- I did get there.

Now I am thinking about the future -- if we decide to adopt TDE. We have one production database and about 30 non-production copies. (That is an unusually large number, but that's how it is.) Two copies get refreshed from backups from Production every day -- a few others once a week -- and the rest at different times as required. As is done in (I think) most places -- when copies are made the data goes through an obfuscation process to make the data "anonymous".

I am curious to know how others who use TDE handle copies to non-production environments. Should the copied databases remain encrypted -- or should they be decrypted? It seems to me that remaining all-encrypted is necessary -- since the time needed to decrypt them would be a problem.

Any thoughts?

Ron.
 

TomBascom

Curmudgeon
From a practical POV I think most people either run with TDE still enabled or stop using backups for that purpose.

Also, I've noticed over the last few years that a lot of people who formerly did the "restore a backup and obfuscate the data" thing have moved away from it. I think there is a growing understanding that those techniques tend to be full of holes and that de-anonymizing such data is actually kind of trivial.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Should the copied databases remain encrypted
I don't think we can answer that for you. People don't use TDE for the fun of it. They do it to be compliant with a policy that says they have to encrypt data at rest. That policy should be explicit about how to handle databases in non-production environments, with or without anonymized data, and other data (backup files, OS copies of database files, VM snapshots, BI files, AI files, binary dumps, audit binary dumps, etc.).

If the policy doesn't cover that, it should.
 

ron

Member
Thank you Tom and Rob -- I'll take your remarks on-board as we develop our plans and policies for adopting TDE.
Ron.
 

ron

Member
Enterprise 11.7.3 on Linux.

Say I deploy TDE into production. At various times after that I need to copy a backup from PROD into various DEV environments that have not had TDE implemented on them. Will the backups restore properly if an appropriate key-store file is present?

Or would I have to actually enable TDE on those DBs first?

Ron.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
If you want to take a copy of a TDE-encrypted DB, just probkup and prorest as you normally would for an unencrypted database. The new DB will be TDE-enabled. Then copy the keystore file (dbname.ks) to the destination location. If the target DB has a different name from the source, rename the .ks as appropriate. However that does require that you have the appropriate license to work with encrypted DBs (either Enterprise RDBMS/TDE or Advanced RDBMS) on the target machine. If your dev machines don't have TDE licenses, they will need to work with database copies that have first been decrypted.

That's the technical side; now for the business side.

If your plan is to encrypt the data in prod via TDE (presumably because some portion of the data is sensitive so you want to encrypt it at rest to protect from theft) but copy the same data to dev and not encrypt it, that plan doesn't make sense to me. The business risk isn't mitigated at all. All that has changed is that the "various dev environments" are now the targets of choice, rather than prod.

Can those dev environments be so locked down, via compensating controls, that it obviates the need for TDE? If so, they must be more physically and logically secure than prod, which seems both unlikely and senseless. And if it were possible to lock down an environment to such an extent that it provably eliminates the need for TDE (which I doubt), why not simply implement the same compensating controls in prod and not buy TDE at all?

Think like the attackers. They want your data. If the data they can steal from dev is the same as it is in prod then they don't care which environment it came from. They'll follow the path of least resistance.

That data has the same value to attackers wherever it exists, so implement TDE everywhere sensitive data (as your organization defines it) exists. Doing less seems like security theatre to me.
 

ron

Member
Thanks very much for the reply, Rob.

I was reasonably sure that it would work as you described.

The issue you mention about the security of the data in the DEV environment is a very real concern to us and we are working on that. We don't yet have a solution -- but we are considering obfuscating a copy of the database while it is still within the confines of the PROD environment. It's a hard nut to crack.

Ron.
 
Top