Protecting sensitive data from criminals, hackers, and other prying eyes is an important aspect of providing security for modern systems and applications. Data is central to business and whenever it is breached for any reason there will be repercussions, whether they be financial, regulatory, or otherwise. And the most important data is stored in a database management system. As such, database administrators are tasked with protecting the core data assets of their organizations.
Data security and privacy are top corporate initiatives these days. Instead of being ignored and relegated to IT staff as in the past, today executives are being held accountable for data protection. This change has been driven, in many cases, by regulatory requirements, but also as a reaction to the publicity and negative impact of the ever-increasing number of data breaches. This shift has elevated data security and protection planning to the executive level.
Of course, executives are not the implementers. For data security, DBAs are one of the technology experts who translate the specific requirements as outlined by the business into an actual implementation. But having executives involved with—and held accountable for— data security makes it easier for the DBA team to get visibility and funding for data security projects.
Furthermore, implementing security measures within IT systems has a more elevated status in organizations because customers are becoming increasingly suspicious of big companies in terms of what data is being collected and how businesses secure and protect their data. Most organizations could use improved techniques and tools for protecting data, and the big data trend only exacerbates the situation. Organizations must be able to quantify the business value of their data and categorize exposure and loss of data in terms of the reduction in value, impact to the company’s reputation, loss of potential trade secrets, etc.
Fortunately, DBMSs have gained more security features over the past few years and will continue to do so. Database security is much more than simple logon/password authentication and authorization, but now comprises multiple additional techniques and capabilities. Examples include at-rest and in-transit data encryption, more discrete authorization levels, label-based access control (for fine grained control over authorization to specific data in a database), data masking and obfuscation, database auditing, and trusted context (to authorize only specific locations for interactions between the DBMS and an application).
Turning our attention from implementation to protection, organizations need to understand that most DBAs have significant IT experience and have worked their way into a trusted position within the company. Nevertheless, DBAs are a significant insider threat in most organizations because they have elevated authority to access data and make changes to database structures. DBAs are, for the most part, trustworthy and want to do a good job in terms of managing and protecting their company’s data. But there are always exceptions, and that is why one of the most common forms of data protection being implemented today is privileged user access auditing.
DBAs, typically with high-level authority such as DBADM or SYSADM privileges, may have carte blanche access to the database instance and all its data. Although DBAs are trusted agents and should not abuse the overarching privileges they are granted, the general maxim of “trust, but verify” applies. DBAs need a high degree of authorization to do their job, but that also brings the opportunity for nefarious activity. Implementing privileged user auditing to track every action taken by such users is a wise course of action. This means you can enable DBAs to do their jobs with appropriate levels of authority, but also ensure that they are acting appropriately via access monitoring.
Database Security Hinges on 4 Questions
The DBA should be an advisor to the business in terms of the types of database security that can be enabled. At a high level, this boils down to being able to answer four questions:
Who is it? (authentication)
Who can do it? (authorization)
Who can see it? (encryption)
Who did it? (auditing)
Answering these questions in terms of how to implement them technologically in the DBMS is the DBA’s duty. DBAs are not required to understand business-specific regulatory requirements but must be able to understand the regulations that are communicated to them and translate that into actual DBMS functionality, if it exists, to satisfy the requirement.
Indeed, data protection and security is more a part of the DBA’s job today than ever before.