Database Reference
In-Depth Information
Chapter 14
Securing Privileged Access
Control Systems
The previous chapter looked at known methods for implementing privileged access control as well as some of the
issues with their security. This chapter is focused on how to secure those methods and how to control high privilege in
preparation for the process of consolidation and for a potential move to a shared infrastructure—commonly known as
“the Cloud.” Securing DBA accounts is a prerequisite to cloud consolidation in 12c, so let's start.
Privilege Access Control Communications
To recap, time-based privileged access control (PAC) systems, of which break-glass is an example, basically limit the
access to a privileged account to a set period of time. The classic system involves an automated password hub that
cycles all the admin passwords daily. When a DBA wants the password for SYS they check it out from the hub using
their SSO login, and then the hub automatically changes the password for SYS after a day. This time-based rationing
of SYS access means that the privileged access is tied to an individual user, and that user has to come back each time
they want access.
The first issue with time-based privileged access control (PAC) systems like break-glass is that they rely on the
human user not to share the SYS password, as that value is now unique to them for that time period (therefore similar
in nature to a personal useraccount/password). This may sound obvious, but I have been asked for my personal
account password numerous times, and really there should never be a need to give that information to another
human—even if they are your boss!
Your personal password for an account unique to you, whether that be a timed segment of SYS usage or a fully
individualized username, should only be known to you and the system itself. In particular, the use of websites to check
the strength of a user's password is a complete no-no. Even SANS Guide Version 2.0 (page 45, action 2.1.3) suggests that
users test their password strength on a small third-party Internet website based in Switzerland (cnlab.ch). In the U.K.
the BBC's technology program Click-Online recently recommended that members of the public put their passwords
into a third-party website to check their strength (
http://www.bbc.co.uk/news/technology-23712087
). Don't do this.
The website may record your password and your IP address.
If anyone asks for your individual password then politely reply that it is unique to you and that you are
accountable for actions performed using that account, and therefore cannot disclose the password. If the requester
has genuine authority then they should be able to ask an administrator to reset the password anyway.
Now, refusing to give up a password can raise interesting questions of organizational authority. If we look at the
Terry Childs case in San Francisco, he too refused to give up the administrative password for the network. But the key
point here is that the credential he refused to give up was the non-time-limited system credential for the network.
That credential was not designed to be limited to him only.
