Database Reference
In-Depth Information
Chapter 10
Security Issues in 12c
Oracle Database 12c was made available publicly in July 2013. Organizations will commonly wait for the second
release before committing to production installs, so it is interesting to see how production ready 12.1.0.1.0 is and
whether the new features described in Chapter 8 will entice organizations to commit early.
A good measure of a new release is how long it takes for researchers to find security issues. The issues described
in this chapter were discovered by the author in the first few days of the GA (General Availability of 12c).
First, let's set the scene for the greatest security issue in 12c, which is privilege escalation. Arranging privilege in
terms of increasing security sensitivity starts from the lowest “read” access for monitoring and business reports, and
finishes with highest sensitivity being “physical” access at the datacenter. Physical access allows the user to boot to
another OS, which bypasses almost all security, whereas read access should not allow any control of the system.
Segregated Groups of User Privilege
In practice there are seven main groups of employees who have increasing levels of security sensitivity and also need
to have separate access-control privileges in order to maintain a low-risk environment. This is a bit like having two
keys to the safe given to two separate members of staff at the bank. Both are needed to open the safe. It is important to
make sure that neither's privilege can overflow into the other. Even more important, other staff and customers should
have no access to either of the keys. Therefore we can identify a need for horizontal segregation of duty (SoD) to
prevent collusion and a vertical seperation for security sensitivity. This two-dimensional aspect is behind the classic
privilege heirarchies in security control structures such as the Bell Lapadula (
http://en.wikipedia.org/wiki/
Bell%E2%80%93LaPadula_model
)
model that is largely based on military command and control structures.
The seven general levels of ascending privilege are as follows:
1.
Low-privileged select for reports
- business users and developers monitoring
performance.
2.
Applicant account and schema owners
- locked and statechecked outside of release to
alert to unauthorized changes.
3.
Junior DBA and Dev Ops
- with ability to grant non-SYS object privileges, and with
wide-read privileges.
4.
Senior DBA with sysdba/osdba
- ability to access time-limited breakglass to “oracle” Unix
(software owner).
Unix or Linux sysadmin (SA)
- with root and
oracle
control as part of their Business
as Usual (BAU) responsibility. System administrators are able to control and monitor
DBAs without their sanction, and therefore provide SoD counterbalance to DBA's power.
Segregation between the SA and DBA team is critical to environments with high security
requirements.
5.
