Hi,
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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx>]
On Behalf Of Tim Gorman
Sent: Thursday, December 03, 2015 1:49 PM
To: oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx>]
On Behalf Of Herring, David
Sent: Thursday, December 03, 2015 11:45 AM
To: oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>
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. ****
