The Security Focused DBA ?

Many employers seem to believe that about five years of solid DB2 DBA experience puts a potential employee into an “advanced” or “senior” DB2 DBA role.  Those with less experience are typically slotted for positions that will have some oversight from a more senior DBA.  If the employers are right, then the act of just learning how to do the typical DBA tasks is equivalent to the years most of us apply toward acquiring a college degree.  In other words, becoming a DBA requires a serious commitment just to learn the aspects of product information that drive the database engine itself.   Then with the constant updates to the product and applications being supported, the DB2 DBA quickly becomes focused on keeping current.  DBAs are, by definition of their job responsibilities, constantly learning new things.

How does this relate to security?

Learning security principles and keeping up with all the new security information in an attempt to keep up with evolving threats to the data is also a significant learning “opportunity”.   One reason I like to talk to DBAs about security is because I know they “know how to learn” and grow their skills.  I suspect most DBAs are curious about more than just how the databases “work” and that they enjoy their profession immensely and want to continue to advance their knowledge and their careers.

For DB2 DBAs, IBM has built in some robust security options that we can use to harden our databases and provide a layer of protection at the database layer.  DB2 9.7, for instance, gives us the ability, for the first time, to truly apply the security principles of Separation of Duties to our databases.  DB2 9.1 introduced us to a new Security Administrator (SECADM) authority and with DB2 9.7, that SECADM job function has evolved to allow a true separation/delegation of database security responsibilities which can be performed without the need for additional high level privileges. DB2 9.5 introduced a greatly enhanced auditing capability, with highly granular options, to help us design an auditing approach that matched our specific requirements without overwhelming us with unnecessary data.  There is no additional charge for any of these security features and they are available for our use as soon as we complete the installation steps.

Fortunately, I am starting to see more and more DBAs signing up to learn about database security.  The awareness of this particular need is just now starting to come into focus.  I think we may be approaching a tipping point.

As more breaches occur, as more regulations are written, as more “bottom line”, financial damage is done to companies who “lose” data, I see a new opportunity for DBAs to grow their careers by focusing on security protections specific to the database layer.

This is good news for DB2 DBAs and good news for the organizations who need to harden their database security posture.

Do you agree?  Disagree? Want to comment?

My email is open 24×7.  db2locksmith@securedb2.com



Comments are closed.