RE: User equiv and "oracle" lockdown
- From: "Herring, David" <HerringD@xxxxxxx>
- To: Seth Miller <sethmiller.sm@xxxxxxxxx>, "dimensional.dba@xxxxxxxxxxx" <dimensional.dba@xxxxxxxxxxx>
- Date: Mon, 22 Sep 2014 16:26:05 -0500
Np. Here's the link I was sent:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-ssh-configuration-keypairs.html.
This link just shows changing over from password authentication to using pass
phrases that are good only for your current session.
Unfortunately I'm in an environment where any DBA access is guilty until proven
innocent. I tried to convince them that locking down a system that isn't even
fully functional, much less not having any front-end access is rather silly but
they wouldn't budge.
Dave Herring
From: Seth Miller [mailto:sethmiller.sm@xxxxxxxxx]
Sent: Monday, September 22, 2014 3:32 PM
To: dimensional.dba@xxxxxxxxxxx
Cc: Herring, David; Oracle-L Freelists
Subject: Re: User equiv and "oracle" lockdown
I would agree on posting the documentation they are citing. There are very few
methods of authentication that are more secure than shared-key and I doubt they
are proposing any of them.
If security is the issue, there are all kinds of fruit within reach to start
picking rather than trying to reach to the top of the tree for this issue.
Seth Miller
On Mon, Sep 22, 2014 at 3:02 PM, Dimensional DBA <dimensional.dba@xxxxxxxxxxx>
wrote:
I would ask them for the specific Red Hat documentation. I have been in many
discussions with Linux teams and found their documentation to be old or not
specific to Oracle and normally there are specific ones to Oracle that
states how you must do things.
If you have the specific documentation they are using can you share the Red
Hat note numbers. I would be more than happy to pull you the Red Hat
documentation.
One Example is
https://access.redhat.com/sites/default/files/attachments/oracle_11gr2_on_rh
el6_0.pdf
4.2.9 Security Settings and Recommendations
Best practices for initial set-up for database security are straightforward,
but ongoing
security-or security as a process-is more difficult to summarize. Briefly,
use root powers
sparingly. Oracle has separated and grouped root actions; e.g., a small set
of pre-installation
tasks and a small set of post-install fix-up scripts. Do not use application
accounts as your
normal account; that is, log onto the database host as a non-generic, named
user (jqbach, for
example), and when database tasks are needed, use sudo or su to switch to
the application
(oracle) account.
These extra steps require discipline to follow (because the alternatives
require fewer
keystrokes), but the benefit lies in preventing accidents that might cause
significant amount of
time to correct, and in providing a simple log of who has done what and
when.
Matthew Parker
Chief Technologist
425-891-7934 (cell)
Dimensional.dba@xxxxxxxxxxx
View Matthew Parker's profile on LinkedIn
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Herring, David
Sent: Monday, September 22, 2014 12:27 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: User equiv and "oracle" lockdown
Does anyone know all areas where user equivalency for the account "oracle"
is necessary in a RAC system, let's say 11g and above on Linux RH?
The reason I ask is that our security team is now refusing to have this set
up and even though I passed snipets from Oracle doc which states "it must be
set", they're balking and sending snipets from RedHat doc saying that's
unwise.
Without user equiv for "oracle" I believe the following will break/have
issues:
* Proper management agent monitoring. The agent needs to know it's a RAC to
properly monitor the configuration. I don't have specific examples, just
oddity with agent behavior when user equiv isn't set properly.
* All "cluvfy" uses will fail. Most are interactive uses but the management
agent uses it too for cluster verification. So in a way almost all our
ability to validate the cluster will be unavailable.
* All installs, patches, upgrades will fail or least be a complete hack.
Rolling patch application would never be possible, I assume.
I know the cluster will still work without user equiv as I've run into
enough existing systems where the DBA didn't do it properly or didn't
properly add new nodes. Is there anything else that would break/be a major
pain? Since documentation proof isn't enough I need to explain in (my)
painful detail of why we need it.
Dave Herring
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
