Re: Security Wonks ate my hamster.
Date: Wed, 23 Mar 2016 12:52:44 -0400
Message-Id: <E3ECEA26-FA3B-42FE-A07B-B3E6F29BDBEC_at_michael-brown.org>
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_at_gmail.com wrote:
>
> I have also monkey’d around with HashiCorp Vault secret store. https://www.hashicorp.com/blog/vault.html <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 <mailto:jpiwowar_at_gmail.com>
> Sent: Wednesday, March 23, 2016 9:59 AM
> To: rajendra.pande_at_ubs.com <mailto:rajendra.pande_at_ubs.com>
> Cc: howard.latham_at_gmail.com <mailto:howard.latham_at_gmail.com>; oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>
> 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_at_ubs.com <mailto:rajendra.pande_at_ubs.com>> 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)
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Mar 23 2016 - 17:52:44 CET