Sarbanes-Oxley and the DBA
It’s unlikely the average database administrator (DBA) would ever say his or her job is easy, but the increased presence of regulations, such as the Sarbanes-Oxley Act of 2002 (SOX), have made the DBA’s job that much tougher.
Also known as the Public Company Accounting Reform and Investor Protection Act of 2002, SOX is a U.S. federal law created in response to several high-profile corporate and accounting scandals in companies such as Enron, Tyco and WorldCom. The scandals led to a decline of public trust in accounting and reporting practices, and SOX established more stringent standards for all U.S. public company boards, management and public accounting firms. This means the DBA is now required by law to be fully vigilant about data. This increased vigilance affects many facets of the database, including archiving, access auditing and encryption, as well as procedures and backup and recovery processes.
Database retention — retaining data in an authentic manner, should it be needed in a court of law for discovery, etc. — requires database archiving, essentially moving data out of the operational database and putting it into a long-term data store or database archive of some sort.
“There are things in Sarbanes-Oxley that require you to do this,” said Craig Mullins, a corporate technologist for NEON Enterprise Software Inc., IBM consultant and author of two books: DB2 Developer’s Guide and Database Administration: Practices and Procedures. “You have to keep for seven years records that apply to reporting periods for that particular quarter of financial numbers in the organization. There are other regulations that require you to keep that data for decades.
“In that case, you really can’t keep the data in the operational database because you get performance degradation as the size of the database increases. If these records are almost never touched, and the only reason you’re keeping them is because the law says you have to, you don’t want them intermingled with the rest of the data that’s being touched on a daily basis,” he said.
Mullins said today’s DBAs also have to think differently about database access auditing, or having a record of who did what to which piece of data when. There are facilities within database management systems (DBMS) that allow fine-grain auditing, but each DBMS does this differently. DBAs may have to look at additional tools to ensure they capture every data access point.
“For example, a regulation like HIPAA dictates that the person who owns or has custody of your medical records has to be able to tell, on request, who even looked at that data,” he said. “That’s something that DBAs today are just not prepared to do. Most DBMSs are not even architected to tell them that information at all. They need additional software.”
Database encryption is another area under compliance scrutiny. Data breaches are common news fodder these days, and Mullins said part of the reason they are so frequent is because people leave their data unprotected in their laptop or system for every potentially nefarious character to read. However, you can encrypt data, which requires a key to unlock and access information.
There are two types of encryption: encryption of data at rest, which means encryption on a disk, and encryption of data in transit, which means encryption as data moves across the network from the disk to the program to the user. Mullins said both are important.
“DBAs need to be involved in the trade off of data protection versus data performance,” he said. “Encrypting the entire database causes problems. Certain types of clauses in your SQL statements will operate but won’t be indexable, meaning they won’t perform. DBAs need to know all of these tradeoffs and make sure that only the right things are encrypted in the right context.”