Two Sides of a Coin – A DBA’s Experience
This is a story of not just an Oracle Database Administrator, but any administrator out there in this IT world.
For the sake of this story, let’s say there is an employee, Mark Smith, who has been working as a Senior Database administrator in a retail company for many years. Mark comes to the office on a Monday morning and once he has finished looking through his emails, he opens the tickets assigned to him by the various application groups for that particular week. He picks the tasks based on their priority. The first one requests the DBA to assign unlimited usage on certain tablespaces to a certain number of users, which will help those respective application users to run greater workloads on that particular database. The second ticket requests the DBA to provide access for an application administrator to some of the Oracle log files. They would like to gather some information for his reference purpose and improve application performance in the long run. After reviewing the tasks, and making sure necessary approvals are received, Mark goes ahead and performs both the tasks to completion and closes the tickets.
A week passes by and Mark gets an email from his Information Security department stating that there are a few vulnerabilities they have found on some databases he supports. After careful review, Mark finds they are related to the tasks he had performed the previous week to help the application teams. Just as a coin has two sides, which represents different aspects of it, similarly, there are two different perspectives of how Mark can look into the two tasks he performed during the last week. From one side of the coin, looking from the requestor perspective, Mark has done a wonderful job in completing the tasks on time and reaching SLAs, which helped the application team to reach their deadlines for that quarter. However, if you look at it from the other side of the coin, Mark had not realized the first task he performed has the capability for the enabled users to create any unwanted data in wrong locations. In a similar way, for the second task, the log files access he has provided to the application administrator has a password embedded from a few years ago, which was created by an ex-employee. This was totally unknown to Mark.
This type of situation is not unheard of in the database and infrastructure world these days. At BIAS, we consult with customers who would like to maintain security standards for their IT systems and at the same time not become a roadblock to application teams, which in turn might affect the business operations of the respective company. For cases like that, we provide not only the resolution of the existing security problems, but also build a governance policy around how the systems need to be protected when multiple stakeholders from various companies are involved.
I understand business needs come first, but at the same time, it’s even more important that the data involved for those business needs is highly secured. Some of the important things to consider for database and other administrators to help with these aspects are:
- Awareness of Everyone – Implications of every change from a security perspective should be broadcasted to all teams so the application teams can make a well-informed request.
- Wear a Security Hat – There is a reason for why administrators are given more privileges than regular users. It’s not just to run maintenance activities, but also make sure to think twice about every aspect of security while performing any change on the systems.
- Support – Support from application teams and leadership is also required to make sure there is a strong governance policy.
- The Principle of Least Privilege – Lastly, the principle of least privilege is a very powerful concept where every user (including administrators) has only the required amount of privileges that are needed to perform his/her job and related responsibilities and nothing more than that.
The following thoughts, intentions, strategies and/or solutions are those of the blog authors and do not represent the position of anyone other than the authors.