Database Reference
In-Depth Information
Table 13-2.
General categories of privileged account management strategies
DBA Password Method
Comment on Risk
All DBAs have root access.
Very risky. No control or effective monitoring of the DBA
accounts.
No DBAs have root access. Shared password in the
team for “oracle.”
Still very risky in that DBAs can modify the software using
“oracle,” i.e., can install backdoor. But at least “root” should
be able to see them do it and verify integrity.
Lock “oracle” just for DBA manager and change PW
after usage. DBA team has individual OSDBA accounts
in the DBA Unix group.
Quite common, generally in medium-security
environments. Concerns are that the OSDBAs may be able
to change password file, so careful use of Unix permissions
required.
No BAU Unix access to DBAs, similar to Sybase
environment. Shared SYS password.
Preferable SoD between DB and Unix. Facility would be
required for DBAs to checkout “oracle” for upgrades and
OSDBA for import/export.
No BAU Unix access with SYS break-glassed in EPV,
and all DBAs have individual DBA account with
stripped-down privileges, e.g., without ALTER USER.
Even better but technically difficult to achieve due to
Oracle DB needing SYS password control for dataguard etc.
Therefore, keep SYS password as static value in EPV.
DBAs only have “READ” monitoring account given to
them as BAU, and all other access has to be checked
out of break-glass server.
Perfect world for PAC in that DBAs are in a monitoring role,
which is fine for stable production systems, but if there is
an emergency the SYS password checkout needs to be very
quick, i.e., break-glassed.
As a member of security staff outside of the DBA team it is sometimes difficult to ascertain which category
of access control is used. Attempts to enforce one of these models upon a DBA team can result in ambiguities of
authority, and also a culture of hiding which method is actually being used. The solution to this is to couch all audit
and compliance work as being a win-win process of
improvement—
not point scoring. Also, these improvements must
be proven to be practically implementable before attempting to recommend the improvement to DBA team leads.
Therefore, DB security has to be led by someone who is both a DBA and a security expert, which is a rare person,
so after you have read this topic your skills should be in demand.
For the purposes of this next advanced chapter we will assume that your organization is at stage 5 in that
"oracle"
Unix is locked, OSDBA and SYS access is through a checkout mechanism such as EPV, and all DBAs have
a personal lower-privileged DBA account that has monitoring privileges and BAU administration requirements
assigned to that personal DBA DB account. That is good, but what structures can help to control the highest
“oracle”/SYS privileges when they are needed?
Privileged Access Control Structures
Current privilege access control systems usually consist of some kind of centralized hub. The hub can be a repository
for passwords that are effective throughout the estate and/or can be an actual logon terminal to proxy that
administrative terminal to the destination server. I will categorize these as a “Password Hub” and a “Terminal Hub,”
respectively. (Either can be hardware, software, or VM).
Password Hub
CyberArk EPV is an example of a password hub. Figure
13-1
shows what a generic password hub system looks like
conceptually.
