Re: Protecting production from "us"

  Using a customized SQLPROMPT> and different admin passwords (oracle account, sys,system and others) might help too!

All the Best,

Mufalani

> Em 03/12/2015, à(s) 16:53, Matt Adams <MAdams_at_TroverSolutions.com> escreveu:
>
> I’d almost forgotten the rather elegant but expensive solution in place at Mutual of Omaha when I was there back in the 90s
>
> Two distinct and completely non-connected networks…one for production, one for everything else. And when I say non-connected, I mean really non-connected. I had two pc’s on my desk. One that could connect to the production network, but not the dev network, and vice versa. There were no connections between the two networks anywhere. As I remember, on code release day, it had to be written to physical media, then that media loaded onto a different server on the other network and then installed.
>
> Matt
>
>
>
> From: oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org> [mailto:oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org>] On Behalf Of Tim Gorman
> Sent: Thursday, December 03, 2015 1:49 PM
> To: oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>
> Subject: Re: Protecting production from "us"
>
> Change the font color in PUTTY for each server. Red for prod, yellow for qa/test, white for dev. Or whatever works for your group.
>
>
>
>
> On 12/3/15 11:35, Matt Adams wrote:
> It may seem simplistic, but my solution is….three screens on my destop. Left, laptop (middle) and right.
>
> Production putty session are allowed only on the right, and are the ONLY things ever on the right screen.
>
>
>
> From: oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org> [mailto:oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org>] On Behalf Of Herring, David
> Sent: Thursday, December 03, 2015 11:45 AM
> To: oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>
> Subject: Protecting production from "us"
>
> Folks,
>
> The whole subject of locking down production, limiting access, etc. comes up periodically in our list so I apologize if this seems to be a repeat but in short I'm looking for anyone who's willing to share, on this list or privately, how they "protect" production from those who support it.
>
> Here's the situation: as with many others, we're (DBA team) asked to support hundreds of environments. In one situation a DBA (let's call him Scapebob) had multiple putty sessions open for hosts supporting stage and production for the same application. In the heat of the moment he typed a "srvctl stop instance..." command in wrong window - production instead of stage. Both stage and production are 4-node RACs and initially no one noticed, not even the client. Scapebob immediately restarted the production instance and all was fine for about an hr but then some locking issues came up that caused an outage at which point upper-management heard of the accidental instance shutdown and our whole team came under fire.
>
> The question/issue/subject I'm researching is how to best avoid this kind of thing happening again.
>
> · We already have LDAP/RH directory involved on a number of environments but that doesn't differentiate production vs. lower env. All require individual accounts and use "sudo -u oracle" to execute more dangerous commands.
> · Should we look into some kind of additional controls where commands like "srvctl stop…" cannot be run under our own accounts using "sudo -u oracle" but instead need a different account on production? For example, normally our unfortunate DBA would use his "scapebob" Linux account but perhaps to perform a production shutdown he'd need to connect as "scapebob-rw", a new, special account just for dangerous production activities.
> · The problem in our situation was over confusion with multiple windows. Do people set a Linux TMOUT to something short like 10 or 15 minutes, to hopefully avoid accidentally leaving production putty sessions open?
> · Beyond changing the linux prompt and text colors (we set $PS1 with escape sequences and various key, env-specific values) do you do anything else for protection of production?
>
> Thanks in advance for anything shared.
>
> Regards,
>
> Dave
> **** This communication may contain privileged and/or confidential information. If you are not the intended recipient, you are hereby notified that disclosing, copying, or distributing of the contents is strictly prohibited. If you have received this message in error, please contact the sender immediately and destroy any copies of this document. ****
>
>
> **** This communication may contain privileged and/or confidential information. If you are not the intended recipient, you are hereby notified that disclosing, copying, or distributing of the contents is strictly prohibited. If you have received this message in error, please contact the sender immediately and destroy any copies of this document. ****
>

--
http://www.freelists.org/webpage/oracle-l