One of the most important and rapidly changing areas of database management is security and protection. The major DBMS vendors have been adding security features and improving the way you can protect your precious corporate data. But it can be difficult to keep up with these features, so let’s take a brief look at some of the more interesting and useful database security options.
Encryption
Although encryption has been around for quite a while, it has only recently become an important aspect of database security for protecting sensitive data. When data is encrypted, it is transformed using an algorithm to make it unreadable to anyone without the decryption key. The general idea is to make the effort of decrypting so difficult as to outweigh the advantage to a hacker of accessing the unauthorized data. There are two situations where data encryption can be deployed: data in transit and data at rest. In a database context, data “at rest” encryption protects data stored in the database, whereas data “in transit” encryption is used for data being transferred over a network.
Encrypting data at rest is undertaken to prohibit “behind the scenes” snooping for information. When the data at rest is encrypted, even if a hacker surreptitiously gains access to the data behind the scenes, without the decryption key the data is meaningless. Data at rest encryption most commonly is supported by using built-in functions, a DBMS feature such as Oracle Transparent Data Encryption, or through an add-on encryption product.
Encrypting data in transit protects against network packet sniffing. If the data is encrypted before it is sent over the network and decrypted upon receipt at its destination, it is protected along its journey. Anyone nefariously attempting to access the data en route will receive only encrypted data. And again, without the decryption key, the data cannot be deciphered. Data in transit encryption most commonly is supported using DBMS system parameters and commands or through an add-on encryption product.
Label-Based Access Control
A growing number of DBMSs offer label-based access control (LBAC), which delivers more fine-grained control over authorization to specific data in the database. With LBAC, it is possible to support applications that need a more granular security scheme. LBAC can be set up to specify who can read and modify data in individual rows and/or columns.
LBAC is not for every application; it is geared more for top-secret, governmental, and similar types of data. For example, you might want to set up an authorization scenario such that each column and row have specific rules pertaining to which employees can see and manipulate the data. Setting up such a security scheme is virtually impossible without LBAC. An administrator configures the LBAC system by creating security label components, which are database objects used to represent the conditions determining whether a user can access a piece of data. A security policy, composed of one or more security label components, is used to describe the criteria for determining who has access to what data. The security administrator defines the policy by creating security labels that are composed of security label components. Once created, a security label can be associated with individual columns and rows in a table to protect the data held there. When a user tries to access protected data, that user’s security label is compared to the security label protecting the data.
Any attempted access to a protected column when the LBAC credentials do not permit that access will fail. If users try to read protected rows not allowed by their LBAC credentials, the DBMS simply acts as if those rows do not exist. This is important because sometimes even the knowledge that the data exists (without being able to access it) must be protected.
Consult your DBMS documentation for where and how to establish this hierarchy and how to use LBAC.
Data Masking
An additional technique for protecting database data is to deploy data masking and obfuscation. Data masking is the process of protecting sensitive information in databases from inappropriate visibility by replacing it with gibberish or realistic but not real data (in the case of production data used in test systems). The goal is making sure that sensitive, personally identifiable information is not available outside of the authorized environment. Protecting sensitive data using data masking can prevent fraud, identity theft, and other types of criminal activities. A common usage of data masking is to comply with PCI-DSS regulations to show only the last four digits of a payment card number on a receipt.
Data masking can be done while provisioning test environments so that copies created to support application development and testing do not expose sensitive information. Valid production data is replaced with usable, referentially intact, but incorrect or obfuscated data. After masking, the test data is usable just as with production data but the information content is secure.
It is possible to mask data using a variety of techniques. A good data masking solution should offer the ability to mask using multiple techniques. Common techniques include substitution, shuffling, number and data variance, nulling out, encryption, and table-to-table synchronization. Data masking is supported by many DBMS offerings as well as by third-party products.
Staying Up-to-Date
Be sure to keep up-to-date on the latest security requirements and capabilities of your DBMS. Understand what is available to you and what you may need to augment with additional tools. And keep in mind that the items covered here are not the only security features available to you for protecting your database data.