Oracle Database Review

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


Valuable Features

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.

Improvements to 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.

Room for 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.

Deployment Issues

We've had no issues with deployment.

Stability Issues

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.

Scalability Issues

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.

Customer Service and Technical Support

I haven't had to contact technical support.

Previous Solutions

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.

Other Solutions Considered

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.

Other Advice

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.
Add a Comment
Guest

Sign Up with Email