Oracle Database Review

TDE advanced security is valuable as there are several options of different encryption algorithms.

What is most valuable?

The most valuable feature is the TDE advanced security as there are several options of different encryption algorithms. It's also easy to implement Tablespace Encryption.

How has it helped my organization?

We're able to go through and encrypt our database much faster using Tablespace Encryption versus using column encryption which requires you to identify each atomic piece of information to be encrypted. This ease-of-implementation gives us cost savings as we're able to get things done quickly.

What needs improvement?

I've heard rumors of an upcoming ability to get rid of ghost data. Here's an example: if I have a column in a database, say social security number, and a policy comes up and says encrypt social security number, and if there's an index on that column before you encrypt it, if you look at it, you can see the information in plain text. When you encrypt it, it does not encrypt the index. What it does is it marks the blocks available and creates a new index. Now you have ghost data -- plain text data.

We need an ability to shred that ghost data. Right now what I do is I advise people that when they encrypt something, manually move everything out of the old table space and then shred those data files. To be able to get rid of ghost data automatically would be great.

What was my experience with deployment of the solution?

We've had no issues with deployment.

What do I think about the stability of the solution?

It's incredibly stable. There's a couple things you do need to be aware of, but it's not so much the stability issues, it's actually the data leakage issues. Because we're talking about encryption here, you have to be careful that data can leak out in third text, and I'll give you an example. If you take a data pump export of encrypted data and you do not specify encrypted in the command line, it will be saved in clear text. That's one issue.

Another issue is if you gather histogram information on encrypted data, that data will be stored in the statistics tables unencrypted so you have to use a product such as Database Vault to wall that off so you can protect it.

What do I think about the scalability of the solution?

I don't think there's an issue with scalability. Most people are more concerned about performance because you have to encrypt and decrypt on the fly, but with hardware encryption modules that is really a null issue. There is very little performance impact. We've encrypted data out to 25 terabytes in one system and we had no performance issues.

How are customer service and technical support?

I haven't had to contact technical support.

Which solution did I use previously and why did I switch?

I was involved in the initial architecting setup of this. It's not difficult, but it's very precise. Simply, the easiest thing to think about is you have to store your encryption keys. If you lose your encryption key, you've lost your data. One of the first things you do once you've encrypted your data is back up your encryption keys. Actually, you want to back up your encryption keys before you start encrypting the data. We generally burn those off onto a DVD and store them in the safe and then we store them on another system offsite. That is the one thing that will really burn you if you're not careful.

It's not time-consuming at all. The encryption keys are minuscule. I have Word documents that are bigger than the encryption keys. It's just if you lose that encryption key, you're hosed.

Which other solutions did I evaluate?

We looked at SAN encryption, but we wanted a system that was native to Oracle so that we're not worried about whether everything is integrated properly.

What other advice do I have?

If it's not implemented correctly, you can still have leakages of clear text data. Understand the product and it's limitations before you implement it. Understand where things can leak and plug those holes ahead of time.

You also want to be able to basically understand the product end to end because here's another little issue: if I encrypt the table space at AES 126 or AES 128 and a policy comes out, we're now going to encrypt everything AES 256, you cannot re-encrypt the table space. You would have to create another table space, encrypt it at AES 256 and then move that data over. Then you have the issue again where you can go back and shred the data.

**Disclosure: I am a real user, and this review is based on my own experience and opinions.
More Oracle Database reviews from users
...who work at a Financial Services Firm
...who compared it with SQL Server
Learn what your peers think about Oracle Database. Get advice and tips from experienced pros sharing their opinions. Updated: May 2021.
511,307 professionals have used our research since 2012.
Add a Comment
ITCS user