Comprehensive Database Security

Dean Compher

29 October 2012



If you aren’t scared about the security of your database you should be.  Hackers are getting more sophisticated all of the time so you need multiple layers of security.  Regulations including PCI, HIPAA and the Sarbanes-Oxley Act have strong rules about how data should be protected and require that you be able to prove that your privileged users are not improperly accessing data.  Most organizations keep their most valuable data is in their relational databases so those databases should be well protected with security auditing that is centrally managed.  There are two ways data in a database can be accessed – 1) by connecting as a client to the database management system (DBMS) or 2) by directly accessing data at rest in database data files, log files, extracted files, etc.  In this article I will explore tools for controlling access to both routes allowing you to be a good steward of your database data and to easily comply with regulations for all of your database systems regardless of vendor. 


Client Access to your DBMS


While it is important to control authorization to database objects using the traditional GRANT and REVOKE commands, they leave some things to be desired.  One of the biggest things is that the DBA is usually on his own to decide who gets access with little input from the application developers or security, so he just usually has to guess at the authorizations needed for each object.  Further, each database vendor does things a little differently so each database must be controlled at the object (e.g. table) level.  With InfoSphere Guardium Database Activity Monitoring (Guardium DAM), you can centrally set policies for who should access what data, report on data access, alert you of irregularities, and even disconnect naughty users from the database.  Guardium DAM works with all of the major databases and allows you centrally manage database access policies.  This allows the function of protecting your data to be separated from the function of database administration, so that the fox is not guarding the henhouse.  In general, the security administrator will set and monitor Guardium DAM policies. 


While the DBMS authorizations are necessary and useful, even in the best of circumstances, there are some things that they can not do.  They either give access or deny access to particular users, but they can’t enforce patterns of use.  Lets say that user “AppServUsr5” typically access 150-350 customer rows from your database per day.  Do you think that it would be worth knowing that if one day he extracted 95,000 customer rows?  Could it be that a hacker got the password for AppServUsr5 or that the correct user is doing something improper?  Another important security item is making sure users connecting to your database are coming from the correct IP ranges.  If AppServUsr5 is supposed to only be used by your central application servers, would it be a problem if the connection is coming from a machine in a part of the world known as a hacker haven?   Guardium DAM allows you to set policies for patterns of use like these and others and alert you when those patterns are out of bounds and possibly disconnect the user depending on your policies. 


When you first install Guardium DAM you will just create reports about who is accessing what and from where to get a sense of what a normal environment looks like.  There are many useful built-in reports and you can create your own as well.  Even after you are a long term user of the solution, you will continue to generate reports to periodically review policy violations and for auditing purposes.  Once you have watched the system for a while to see if your policies are working, you can take the next step of altering your policies to take action when violations occur.  You can send alerts like e-mails or text messages to your security enforcers or have the system automatically disconnect users when certain policy violations occur. 


Also nearly as important as actually securing data is being able to show that you are protecting the data and that you know what your privileged users like System Administrator (SA) and Database Administrator (DBA) are doing.   In the current regulatory environment it doesn’t really matter if you are doing a great job if you can’t show that you are doing a great job.  Therefore, you need a way to report on what people are doing, especially the privileged users.  Some organizations use database audit logging to do this, but that route has many holes in it.  Problems include significant database server performance degradation and management of the many heterogeneous logs that must be parsed by the custom reporting applications that you must write yourself.   If you have more than one database vendor, then the logs from each will be in different formats.  The worst part of using database audit logs for regulatory audits is that that method can be rejected by the auditors, because the privileged users can just turn them off for a while if they were to do something bad.  However, with Guardium DAM you can save yourself a lot of effort and have a tool that is shown to pass audits with pre-defined reports that the auditors will want.  Guardium DAM does very little I/O on your database servers and all auditing information is passed back to a central collector where all that data can be reported centrally for all servers across the enterprise.


At a high level the Guardium DAM has two main components.  The first is the central policy server that is used to define policies, collect audit information from the database servers that are being monitored, and to monitor, report and alert you about the information collected.  The other is the agent that is installed on each database server.  The agent plugs into the operating system of the database server and monitors all traffic to the databases on that server whether the source is from the network or a local session originating from the database server itself.  The agents receive security policies from the central server and send information to it about who is doing what.  They will also disconnect users from the database if a policy dictates that action.  The agent only writes audit data to the local server if it looses its connection to the central server.  You can also set a policy on the central server to alert you if the connection is lost to a database server because this could mean that someone turned it off to hide something there that they are doing.  To allow for scalability, multiple Guardium DAM servers can be used with each serving a set of database servers and each reporting to a central policy server. 


Further Reading for Guardium DAM

-          Guardium DAM produce home page

-          Description and Architecture

-          Monitored Databases, OS, and HW Requirements

-          More Details

-          Case Studies, Reports and more

-          Information Center



Access to Data on Disk


While monitoring access to the data through the database management system (DBMS) process is necessary it is not sufficient for comprehensive database protection.  To have a complete solution you also need to guard against those who would go around the DBMS and access files directly.  And not only do you need to guard the data in the data files and transaction log files used by the DBMS, you also need to worry about other files like archived log files, database backup files, extracted files, load files and other files not under control of the DBMS that might be lying around on your servers.  The best protection for the database files and the various ancillary files is to encrypt them and only decrypt them when accessed by valid users using allowed commands.  Further, your system will be more secure if the encryption policy is centrally managed and controlled rather that having a hodgepodge of various encryption methods scattered throughout the database servers where the security team has no visibility. 


InfoSphere Guardium Data Encryption (Guardium DE) is a solution that takes care of all of these concerns and provides a robust encryption solution across your enterprise.  It works by plugging into the file system on the protected server.  Files being written to that file system get encrypted, and depending on who or what is accessing the file, the data may or may not be decrypted for the reader.  It also works for raw devices.  Any application like your DBMS, more, vi, notepad, custom Java program, etc., continue to do their file system reads and writes to files as normal and are oblivious to the fact that the data is getting encrypted and decrypted by Guardium DE as it passes through the file system.  This is why it works with any DBMS like DB2, Oracle, Infomix, SQL Server and others and also can encrypt files not under the control of the DBMS.  While your policy can specify what gets encrypted on your server such as directory names, specific files, file names with wild cards and other levels, most organizations encrypt at the file system level.  File systems that should be in policy includes the one that has your DBMS files and logs plus anywhere someone may land data that they extract from the database, write backups or land files to be loaded into the database. 


Your policy determines which users and what processes are able to decrypt the data.  For example, a good policy for the data files that hold your database data would be to only decrypt the files for the DBMS engine process.  Even the DBA does not typically need to look at the data in the files.  Therefore, if your policy only allows the DBMS processes to decrypt the data, then  when the DBA logged in as the database instance owner tries the use the “more” command to browse the data she would only see encrypted data.  However, she can continue do functions like moving the files as needed.  The same goes for root (SA) in that no matter what application is used to access data from that user id, the database files will not be decrypted, but root can continue to do system administration functions on those files and file systems.  While you may not permit the DBA or instance owner to decrypt the database files using OS commands, you may allow them or some other users or groups to decrypt exports or load files using only those commands.  For example, you may allow them to decrypt using vi, more and sftp, but not for any other commands like “ftp”.  Polices like these are common and are already defined for you in Guardium DE such that you just need to invoke and specify the file systems and users. 


While some database vendors have built-in encryption, using them can be problematic.  For one, each DBMS has its own solution so you necessarily get a variety of ways of doing the encryption across your different platforms.  This leads to inconsistent encryption policies and the DBA’s controlling encryption – remember that fox/henhouse analogy?  Also some of those solutions only encrypt the files directly under the control of the DBMS, which means that export, load and other files are not protected by encryption are accessible, so any hacker who gets into the server can read the data in them.  Guardium DE solves these problems because your policies are managed by the security team and distributed to the protect servers where the file systems are encrypted and decrypted in a consistent manner, protecting all sensitive files.


Another problem of distributing the management of encryption to the various database servers is the management of the encryption keys for disaster recovery.  If you are unable to decrypt any data because you don’t have the encryption key then you might as well not have the data.  When there is a separately managed key on every server can you be sure that every key is being backed up and sent to your DR site properly?  Guardium DE centrally manages the encryption keys on one server where the data can be backed up and sent to your DR site along with all other data.  Further you don’t need to have a separate encryption key for each database server.  You could have one for all database servers or a few different keys that correspond to large groups of servers being protected. 


The Guardium DE architecture is similar to that of the Guardium DAM where you have a central policy server and an agent that runs on each of the protected database servers.  On the central server you create the encryption keys and modify existing policies or create new ones to use those encryption keys.  In those policies you also define which servers and which file systems you want to protect.  The policies are pushed out to the agents on the database servers where they are implemented to encrypt and, where in policy, decrypt files for the authorized users and processes.  


Like database monitoring, there are regulatory requirements about data protection that can be satisfied with encryption.  With Guardium DE you can not only show that you are encrypting your data, but it can also report on access and violations with reports that are built-in that can satisfy auditors. 


Further Reading about Guardium DE

Please note that Guadrim DE used to be called Guardium Encryption Expert. 

-          Architecture and Examples

-          Features and Benefits




As you can see, to do a good job of securing your database requires that you protect yourself from threats that try to connect to your database as well as protecting the data on disk.  By using both of the primary Guardium products you can do just that.  Both of these products have additional features that are quite useful for database security such as the ability to do a vulnerability assessment, but that those are beyond the scope of this article.  If you are interested in the full set of features please see the links above. 



HOME | Search