In this day and age, most servers are dedicated to the Oracle database. As
a consequence, it really makes no sense to refuse root access from a
reasonably knowledgeable Oracle DBA. The data in the database is the only
item that is important to security and the financial health of the company,
so there is nothing the root user can do that is more important than the
oracle user.
On Wed, Mar 23, 2016 at 11:52 AM, Michael Brown <dba@xxxxxxxxxxxxxxxxx>
wrote:
For years, I have helped setup environments where almost no one had root
or oracle.
The few that had it were also the ones who could connect to our syslog
server.
Everyone else would use sudo based upon group membership. We set up an
alias in /etc/bashrc: become=‘sudo /bin/su -‘, and in sudoers, the groups
were authorized to run /bin/su - USERNAME (production required passwords
for root and oracle, test systems required passwords for root, oracle was
group dependent, and dev did not require passwords). vnc passwords were
set randomly by a cron job. This meant we could see who logged in and
su’ed to a privileged account in the log files. Since they also logged to
an external server, a user could not erase the record of doing stuff.
The only time I have ever needed the root password was for certain
activities during boot. The oracle password is required by certain
installers, but in that case, we set it to a temporary value for the
duration of the install (or have one of the senior people who knows the
password run the installer).
If a person only has access to oracle, they have to have someone who has
root access to run root.sh.
On Mar 23, 2016, at 11:28 AM, fmhabash@xxxxxxxxx wrote:
I have also monkey’d around with HashiCorp Vault secret store.
https://www.hashicorp.com/blog/vault.html . The issue that confronts me
the most is how ready the enterprise is to formally adopt and
institutionalize such solutions. There is going to be significant overhead
in learning, maintenance, and architecture.
What I normally see are three distinct scenarios ….
1) Hierarchy- based mandates: were a directive comes from the top
e.g. CIO/director, ‘we must get this done’. This is effective and sends
everyone chasing their tail to get it done.
2) Self-organizing / energizing teams: A group of people that
internalize such needs and embrace the idea that ‘good is never good
enough’. They learn fast, execute, and communicate effectively. It is hard
to see such teams & individuals.
3) Who cares. If not broken, do not fix it. These are places who
have inserted plain-text passwords everywhere is scripts and config files
for the entire life of the organization. Everyone knows about it, everyone
knows it needs fixing, but no one is saying/doing anything i.e. no drive
(internal or external).
----------------------------------------
Thanks
*From: *John Piwowar <jpiwowar@xxxxxxxxx>
*Sent: *Wednesday, March 23, 2016 9:59 AM
*To: *rajendra.pande@xxxxxxx
*Cc: *howard.latham@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
*Subject: *Re: Security Wonks ate my hamster.
Yup, that's a fair point, both about the analogy and the situation,
thanks!
It really comes down to whether the process is more thoroughly defined
than, "passwords locked in that box over there." :-) I'm hoping the answer
is yes.
On Wednesday, 23 March 2016, <rajendra.pande@xxxxxxx> wrote:
Well it depends is right J
“but I really wonder about about the motivation of taking the keys away
from the guy entrusted to drive the bus.”
With a lot of ongoing issues – staying with your analogy - the effort is
*NOT *to take the keys of the bus – but make it such that the driver gets
to have the keys when he needs to drive the bus and not have the keys all
the time.
Standing access vs break glass when you need it
The question comes down to is how easy or cumbersome that process is
--
Regards,
John P.
(Typed with thumbs on a mobile device. Lowered expectations appreciated)
