The most timely feature of Oracles newest release, 10g R2, has to be Transparent Data Encryption. When you consider all the recent data privacy breaches and their impact on companies (if not customers—yet, anyway) due to compliance with new data privacy legislation, this feature just seemed to leap out at me.
TDE (Transparent Data Encryption) is a new feature now included in Oracles Advanced Security option ($10k per processor) and is only available to customers with Enterprise Edition licenses for the database.
This feature is a big leap forward from Oracles previously offered Obfuscation Toolkit, which, though free, leaves much to be desired. Besides the manual coding effort, it also requires changes to application code to call the encryption API.
There have always been options as to where encryption can or should occur. It can be done at the storage level (block or file), but that approach doesnt provide any granularity when it comes to what you want to encrypt.
The application layer has been a popular place to do encryption because it does provide more flexibility as to when and what will be encrypted. It also tends to be a good method for encrypting data elements that are authorized and manipulated by the application.
The problem, of course, is that encryption at this layer wouldnt have prevented some of the most recent losses of data that happened because unencrypted backup data was lost. Also, application layer encryption cannot be retrofitted if the application is a packaged application.
Oracles new Transparent Data Encryption feature is aptly named, as all encryption is handled and managed by the database, making the encryption itself transparent to all applications that access the Oracle database.
In addition, database-level encryption enables the user to choose which columns to encrypt. Remember that not all fields contain sensitive data, so be judicious in making that choice, as there is always a performance hit because of the overhead of the encryption and decryption process.
Oracle has tried to minimize the performance reduction somewhat by also encrypting the corresponding index columns. This will enable equal predicates to continue to use an index if appropriate. That has always been an issue with some database encryption solutions in the past.
In addition, any columns encrypted in the database will also be encrypted when that database is backed up, so banks and credit card companies can rest a bit easier.
One point to take note of is that TDE key management does reside within the database itself, in a new database object known as the Wallet. Most security experts would prefer that key management reside outside of the database to create another layer of security. At least the TDE Wallet is password-protected and could still be protected from tampering, even by a database administrator
So, on the surface, TDE looks like a strong solution to the most threats to data privacy. Im just concerned that organizations will stop there, thinking that is all they need.
The reality is that encryption is only one aspect of an overall strategy for creating a truly secure database environment. After all, any “authorized” user can still access all data in the clear. This means administrators still must have a well-planned and administered authentication and authorization scheme.
However, even that is not enough. Sometimes internal users bent on foul play will connect as another authorized user, or hackers will appropriate an authorized ID. That means that in addition to encryption, authorizations and authentication, organizations also need some type of policy-based approach that can create alerts or deny access when users, even authorized users, attempt to do things that are outside their normal patterns of behavior.
An example would be if a customer service rep ran a query asking for social security numbers, date of birth, address, account number and mothers maiden name for every customer in the credit card customer database.
And since policies are not foolproof, a solid auditing process also needs to be in place to detect possible incursions. Oh, and strong network protection as well. Placing your database behind the firewall. Anyway, I think you get the picture. A secure database requires good planning, strong process control and some decent tools.
This is an emerging area and many small vendors occupy niches in the database security market. Indeed, for those of you running other editions of Oracles products beside Enterprise Edition, third-party suppliers might be the better way to approach this problem, as the upgrade cost itself could be significantly higher.
With 10g R2 and the soon-to-be-released SQL Server 2005 both featuring strong encryption, organizations can finally start to take steps toward providing a more secure database environment. Now we need to see organizations implement an overall strategy.
Charles Garry is an independent industry analyst based in Simsbury, Conn. He is a former vice president with META Groups Technology Research Services.
