Protecting your corporate data takes more than simply securing your network or locking down your database. With a range of security issues facing organizations today, ensuring adequate data security requires a holistic and broad security strategy that goes beyond traditional, technically-focused AAA procedures (authentication, authorization and access control). Especially in light of new regulatory and compliance drivers like Sarbanes-Oxley or Gramm-Leach-Bliley.

Of course, an organization’s data is a critical component of an appropriate security strategy. But it’s not just the protection of data that’s important these days, but the integrity of data—everything from the data in the databases to the data in the system logs to even the data that resides in non-relational systems. This aspect of integrity becomes even more important when faced with compliance requirements. When an auditor is examining the integrity of the financials, the trail pretty quickly leads back to the systems of record and the underlying databases—not only what’s in them, but who had access to them when and who might have changed what.

For the past few years, a lot of focus in the security area has been on confidentiality and the security of data, especially with regulations like HIPAA that require organizations to provide greater control over the confidentiality of specific personal data. But as we’re exploring here, it’s not just confidentiality that’s important—data integrity is also critical for ensuring an appropriate (and auditable!) data security strategy.

For example, a primary concern of auditors (and of vigilant IT managers) is the possibility that authorized users (say, database DBAs) typically have access not just to the database architecture and database settings, but to the data itself. What’s to stop a database administrator from copying off a bunch of phone numbers or credit card numbers or other corporate data?

One approach to solving this type of data access by privileged users problem is to encrypt the data to prevent the DBA from ever being able to do that, since the encryption keys for that data could be held by another person. Such a solution would require that the DBA plus the other person would have to work together to obtain access to that data, providing some additional assurance on top of traditional approaches.

Alternatively, some database vendors, such as Oracle, are offering additional data protection in the form of database realms. Database realms are essentially like areas of the database that can be surrounded and locked down without the typical overhead of the encryption requirements found in the first solution. Oracle’s Database Vault gives organizations a way to restrict access to super users (DBAs and privelaged users) via the definition of realm (or database territory) and a set of appropriate rules and conditions. For example, a database realm could be defined that would only allow DBAs to access or change database settings or content from specific IP addresses (preventing any changes from external sources, for instance), or only between certain hours (say between 9am and 5pm Monday through Friday). In effect, these database realms provide organizations with more granular access over the control of who can see what in a database, who can change what in the database, and when and where those changes can be made.