On the other side of the coin… I can think of reasons to lock down root. First,
there are lots of things with *nix that you can do to destabilize it from a
security point of view. Configuration drift is a real risk as well if many
DBA’s have access to root. Etc…etc… The approach needs to consider the needs as
well as the risks. Further, I’d suggest most DBA’s are not as experienced as
Linux admins … nor do most keep up on current best practices for locking down
*nix boxes. Giving root risks unraveling security…
In large shops I’ve worked in and managed we had specific people who were
authorized to access root on systems aligned with the group they were in. The
same was true with the Linux admins. So, not all DBA’s had root – they didn’t
really need it because they were not doing things like cluster upgrades, etc.
If they had a need, then they would call the person who was the root holder for
that group. We also had a check in/check out password system. It seemed to work
quite well and offered the best balance between security, accountability and
practical use.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Andrew Kerber
Sent: Wednesday, March 23, 2016 1:10 PM
To: Freeman, Donald G. CTR <donald.freeman.ctr@xxxxxxxxxxxxxxx>
Cc: dba@xxxxxxxxxxxxxxxxx; fmh <fmhabash@xxxxxxxxx>; John Piwowar
<jpiwowar@xxxxxxxxx>; rajendra.pande@xxxxxxx; howard.latham@xxxxxxxxx;
oracle-l@xxxxxxxxxxxxx
Subject: Re: [Non-DoD Source] Re: Security Wonks ate my hamster.
Of course in my experience, sensible is rarely taken into account by security
types. They have a checklist, and that is all that counts. No doubt they
would get very unhappy about me having root access to the vm I created in
vmware workstation....
