Database Reference
In-Depth Information
Four-Eye “Extreme” Database Administration
Dealing with malicious insiders is topical after Snowden, and one way to address this is to divide administrative
tasks into two human roles. “Four-eye” administration requires two people to supervise each other's work. For
example, one may take the mouse and another uses the keyboard. The problem with this is that if an organization
has a potential morale issue, or is very high security, then encouraging administrators to work together may increase
risk of internal fraud. Alienation of administrators from each other is used as a way to control staff in high-security
environments, hence the high desk separators in banking.
An oft-forgotten aid to decreasing human malfeasance and mistakes is the message of the day (MOTD), which
can normally be configured on terminal hubs to a custom value. Unix root terminal logons used to say something
to the effect of “with great power comes great responsibility,” which costs nothing to turn on. In my view it is worth
telling the admin that they are monitored as well, as it will encourage tidier work. MOTD should not be required for
application accounts that do not have human access.
Non-Human Application Account Management
Some application account passwords should have all human knowledge removed completely, which reduces risks
such as an admin or a developer searching through CVS for hardcoded passwords in scripts. PAC systems can be
applied to these non-human accounts as well.
In CyberArk terminology, application account management is done by a product called AIM. Other vendors, such
as Xceedium, have the same principle of replacing hard-coded passwords in applications and scripts with a variable
that is populated by making a call to the PAC server, where the secrecy of the password value is managed. The threat
that this mitigates is that of a human reading the application password and logging on directly. Xceedium's solution
even does a checksum of the application script being run to make sure it hasn't been tampered with before releasing
the password to be used by that script. This is a great feature.
The application account may have access to encryption keys and data that the DBA accounts do not have
direct access to, and the account that owns the application objects in the DB has super powers on those objects. It is
therefore arguably equally as important to secure the application/schema accounts as it is the DBA account. This is
achieved by making sure that no human knows the value of that password by passing responsibility for managing it
to the PAC server. This can be a difficult concept to grasp. The notion of placing effective authority with a robot raises
concerns of dependability. Therefore, backup and load balancing of PAC servers is crucial to that availability.
Resistance to Passing Privilege Power to PAC Servers
The major problem with PAC servers is that for Oracle they have historically used a plaintext
"ALTER USER"
statement
to manage accounts enterprise wide, which can actually reduce the security of the system. SSL for client/server
database (ASO) has been expensive until very recently.
Additionally, there are technical barriers to passing the SYS password over to the PAC server. For example,
Dataguard needs to save the SYS password to connect to the standby, but if the PAC server changes the value on the
primary then there may be an issue with failover. 12c does address this with the new SYSDG privilege so that the
primary can log on to the standby without having to use the SYS password.
That is one good point for 12c. In my view, one bad point for 12c is the current ignorance of the fact that all the SYS
passwords on the PDBs and CDB are the same as each other. A number of 12c commentators have said that the PDBs
are properly separated from each other and that this increases security. This is misleading as all the password-managed
users have the same password file, so SYS has the same password on all PDBs and the CDB. The PDBs are not separated,
so they are not secure. One way to deal with this in your PAC servers is to group the various PDB SYS password values
as being managed together in the PAC server. This is possible on most PAC systems. If you are carrying out a PoC on a
vendor solution it is well worth making sure that you can choose to manage multiple servers as a single logical unit in
terms of password value (Xceedium and CyberArk do this).
