Database Reference
In-Depth Information
One potential barrier to the high availability of PAC servers is that most of them lean towards Active Directory,
and the fact that Windows will need a restart at patch time could be a concern to the Unix/Oracle folks who are asked
to give their admin passwords to the PAC server, which will then be reset. Availability in the *nix world has tools like
oradebug to change static parameters without reboot, and ksplice to patch without reboot at the OS, while rolling
patches achieve the same in RAC. Losing Oracle administrative availability because the Windows PAC server is being
patched is not impressive for the *nix community. Oracle/Unix DBAs may not trust a Windows-based PAC server
group to maintain their credentials. Letting go of the power over the SYS passwords is a big ask. Vendor representation
is one reason that Oracle has moved into the privileged access control market with the Oracle Privileged Account
Manager (OPAM) product.
OPAM
OPAM is an application that runs on Weblogic and has connectors that allow it to manage accounts on Unix, Oracle,
MSSQL, and other platforms. OPAM is a password hub, not a terminal hub, though it does have pre-built facility for
break-glass workflows as well as session encryption. The ease of setting up encryption between OPAM and the target
databases is a great advantage for OPAM in the DB world, as is the “one throat to choke” vendor support relationship.
A reasonably succinct paper from Oracle on OPAM is at this URL:
http://www.oracle.com/technetwork/
middleware/id-mgmt/overview/opam-wp-11gr2-1697093.pdf
.
One caveat I have regarding the above document is
its interpretation of “break-glass” access, which does not concur with my long experience of using and researching
break-glass systems.
Break-Glass Access Control Systems
The origin of break-glass access control is in the desire to discourage users from accidental and deliberate abuse
of outdoor telegraphic fire alarm systems (Charles Bright, London). The most well-known contemporary paper
applying break-glass-like access to computer systems is by Dean Povey— “Optimistic Security: A New Access Control
Paradigm,” found here:
Povey quotes Bob Blakey as saying:
“Make the users ask forgiveness, not permission,”
which we will amend to
“Make the
DBAs
ask forgiveness, not permission.”
In practice, break-glass access control is where a shared high-privileged account like root or SYS is boarded onto
a PAC server, like EPV, and the approval process is placed
after
the checkout of the password, as long as the requester
is
already
in the admin's group. Note that authentication of the requestor as being a member of the admin group is
a prerequisite. Break-glass enables the admin identity to be associated with time slots for admin access on servers
controlled by the central break-glass robot (EPV), which automatically changes the password for that account after the
predefined time slot, e.g., one day per checkout of the password. The notion of post-approval goes against instincts
initially, but the key point is to compare that with the current position of having a shared account with a password of a
constant value. Additionally, there is the notion of recategorizing BAU (business as usual) server access, as break-glass
access infers that the need for humans to administrate these servers on a daily basis is reduced. Therefore, the move
to using break-glass can be seen as a step in the consolidation process.
Break-glass is in place within many banks, but it has significant weaknesses at this time, which the next chapter
will attempt to address.
The main alternative to the break-glass method of controlling root/SYS is using capability-style privileges where
the single shared super-powerful account is broken down in to sub-privileges. We will also discuss the practicalities of
capabilities in the next chapter.
