Neon Enterprise Software Blog

Welcome to Neon Enterprise Software Blog Sign in | Join | Help
in Search

Data Management Today by Craig Mullins

News, views, and issues involved in managing data as a valuable corporate asset.

Tracking Privileged Database Users

Do you know what the privileged users of your database systems are up to? Privileged users are the "super" users and administrators with global, or near global, access to all of the data in your corporate databases. They may be known as SYSADM, SYSADMIN, DBADM, SYSCTRL or something similar. Users with this type of privilege typically have carte blanche access to read, modify, alter and administer everything in the system or perhaps a specific database.

Privileged users make auditors cringe, but they are a fact of life when dealing with today's database management system. The way the major DBMSs are architected, privileged users are a requirement. You simply cannot use DB2, for example, without having at least one Install SYSADM. And that means there will be at least one "super" user out there who will be able to do anything to the system. And that means read (SELECT) any data in any table (including the production HR tables that contain salary information, add (INSERT) data to any table, modify (UPDATE) data in any table, and remove (DELETE) data from any table.

So we must be sure to assign only trusted personnel privileged user authority. But the wise person will trust, but verify. That means we need a mechanism that watches over privileged user access. It is important to note, though, that this mechanism should not rely on privileged users. I mean, do you really want to stake the accuracy of your verification methodology on having privileged users installing and setting it up? That kinda deflates the purpose of verification, don't you think?

What is needed is an auditing procedure that traps all requests made to the database. It should have the capability of enabling the audit by userid so that only the privileged users you want to monitor are being watched. It should not store the audit trail data in the database because, remember, the privileged users we are monitoring could change (or delete) the audited information after it was captured. Additionally, a database auditing solution should be easy-to-use by non-database personnel -- and by that I mean security professionals (whose job it is to monitor corporate security) should be able to view the information and make sense of it. This means pre-configured reporting needs to be a part of the solution.

Of course, any solution for auditing privileged user access should be as non-intrusive as possible to the database infrastructure. You don't want your auditing solution to negatively impact database and application performance.

And your DBAs will be glad you have such a solution. Most of them are honorable and trustworthy and will happily accept a solution that proves their innocence, gets the auditors out of their hair, and enables them to continue to be able to do their job.

If you are interested in the market-leading (according to Forrester) enterprise datbase auditing solution, check out Guardium.

 

Published Wednesday, October 31, 2007 12:01 PM by cmullins

Comments

No Comments
Anonymous comments are disabled

About cmullins

Craig S. Mullins is a data management strategist for NEON Enterprise Software, Inc.. Craig has extensive experience in the field of database management having worked as an application developer, a DBA, and an instructor with multiple database management systems, including working with with DB2 for z/OS since Version 1. Craig is also an IBM gold consultant and is the author of two books: "DB2 Developer’s Guide" and "Database Administration: Practices and Procedures."
Powered by Community Server, by Telligent Systems