|
Data encryption is a central component of data security. Legal and compliance regulations, such as the Payment Card Industry Data Security Standard (PCI DSS), HIPAA, Gramm-Leach-Bliley Act (GLBA), and Sarbanes-Oxley (SOX), also refer to the need for data encryption. So, to encrypt your database files on a Unix machine, you could just use the Unix crypt command or install PGP, right? Not really.
Before proceeding, determine why you need to encrypt the entire database file. The role of information security is to ensure the availability, integrity and confidentiality of data. If you consider the implications of encrypting and decrypting an entire production database each time someone tries to access it, you'll likely end up hindering data availability. Encryption is a performance-intensive operation, and encrypting and decrypting data significantly impacts access times and overall performance. Another problem with encrypting the entire database file is that different pieces of data cannot be encrypted with different keys. Such a feature is essential if you need to separate data from different user types, such as sales and human resources.
Encryption is certainly one of the layers of security needed to protect a database, but don't confuse its role with that of access control. With regard to a database, access control means creating users and granting them privileges to access data and execute certain commands and tasks. Databases -- such as Oracle and Microsoft SQL Server -- have extensive controls, allowing you to assign access rights, down to the field and SQL command level. Only once you have implemented these access controls and user authentications should you think about implementing encryption.
If the problem is one of access control, then encryption is not the answer. Think about it: any user who has been granted the privilege to access data within the database has no more or less privilege when information is encrypted. That said, encryption does provide additional protection if access controls are circumvented.
When encrypting data in a database, encrypt only the sensitive data, like credit card numbers, and encrypt them directly in the database fields and columns where the information is stored. This greatly reduces any performance hit. You will find plenty of programs on all sorts of different operating systems that provide column, row, and field encryption functions for databases. Remember though that encryption does not protect data from being deleted or modified, so access control still remains essential.
However, you certainly should consider encrypting data stored on backup media. For this you have various options. The MCrypt library provides a wide range of encryption functions to encrypt files or data streams. Also there are source versions of PGP available for Unix and Linux systems, and if you use HP Integrity servers, take a look at their HP-UX 11i v2 Unix operating system software, which has enhanced encryption features.
Of course, your data storage facility needs to have secure physical access controls. And since performance considerations are not important since backup data isn't being constantly accessed, encrypting an entire database before it is stored can provide an extra layer of protection. Do make sure, though, that your data recovery procedures are tested and that encrypted media can be restored in a timely fashion. Finally, you need to consider using network encryption to protect sensitive data-in-motion as it travels from the database to the user's desktop application.
More information:
Before you leap into database encryption, make sure you know your options.
James C. Foster answers the tough database compliance questions.
|
