Enforcing Least Privilege To Enhance Database Security
The principle of least privilege refers to the practice of ensuring that each individual has only the privilege and access that is necessary to perform their job function.
In most IT shops that run an Oracle database, there are a group of individuals that need administrative access to the operating system and the database. These individuals include both operating system administrators and database administrators.
In order to ensure Database Security, particularly Oracle Security, it is critical that privileges for these individuals be limited and managed properly.
In many cases, these individuals are all given the username and password to a shared, privileged operating system account, such as root on the unix platform. Also in many cases, these individuals are also given the password to the oracle account which owns the oracle binaries.
The Risks
There are two critical problems with this approach that significantly reduce your ability to ensure your Database Security.
- By granting multiple users access to these shared operating system accounts, you compromise the effectiveness of any database auditing or operating system auditing that you may have in place. If data is accessed or modified, future forensics would only yield the shared account name, not the name of the individual that took the rogue actions.
- Oracle’s operating system authentication mechanism enables a user, once connected to an operating system account, to connect to oracle without a password. Furthermore, if the operating system account is highly privileged, such as an account that is in the osdba group, then the user can connect to Oracle as sysdba (using the Oracle SYS account), which is the most privileged account in Oracle. The oracle account is in the osdba group. This leads to numerous risks including an oradebug vulnerability, described in an excellent post by Pete Finnigan, that results in the ability to turn off auditing completely (without the turn-off action being recorded).
How to mitigate these risks:
There are a number of steps we can take to significantly reduce (though not eliminate) the risks outlined above.
- Grant all system and database administrators their own operating system account and do not grant access to any shared administration account (including root and oracle) except when absolutely necessary.
- Ensure that the passwords of administrative accounts such as root and oracle are changed regularly. This protects you in the event that passwords had to be given out to resolve an emergency.
- Restrict Oracle DBAs that perform operational functions such as backups, or space management, to connect as sysoper or asmadmin instead of sysdba. This can be controlled by placing their operating system accounts into the osoper or osasm group or instead of dba group.
These steps will not completely eliminate the risk of a data breach. However, it will significantly reduce the potential for a breach, and will further reduce the potential of a breach that can avoid detection.
Contact Buda Consulting for more information about how to enhance your Database Security and Database Compliance.
Please reply with other risks that you have found that are caused by similar database management issues.
