Re: [Non-DoD Source] Re: Security Wonks ate my hamster.
Date: Wed, 23 Mar 2016 13:09:43 -0500
Message-ID: <CAJvnOJac3raPAkhW4RWGb44LZyqVoEbiKnTPgSUgJAXsdzW0SQ_at_mail.gmail.com>
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....
On Wed, Mar 23, 2016 at 1:05 PM, Freeman, Donald G. CTR < donald.freeman.ctr_at_ablcda.navy.mil> wrote:
> >>>>>>>>>>>" 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. ..."
>
> That is a sensible observation.
>
> Donald Freeman
>
>
>
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Andrew Kerber
> Sent: Wednesday, March 23, 2016 1:23 PM
> To: dba_at_michael-brown.org
> Cc: fmh; John Piwowar; rajendra.pande_at_ubs.com; howard.latham_at_gmail.com;
> oracle-l_at_freelists.org
> Subject: [Non-DoD Source] Re: Security Wonks ate my hamster.
>
> 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_at_michael-brown.org>
> 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_at_gmail.com 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 <mailto:jpiwowar_at_gmail.com>
> Sent: Wednesday, March 23, 2016 9:59 AM
> To: rajendra.pande_at_ubs.com
> Cc: howard.latham_at_gmail.com; 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>
> 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)
>
>
>
>
>
> --
>
> Andrew W. Kerber
>
> 'If at first you dont succeed, dont take up skydiving.'
>
-- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' -- http://www.freelists.org/webpage/oracle-lReceived on Wed Mar 23 2016 - 19:09:43 CET