RE: Using TOAD on production databases
- From: "Mercadante, Thomas F" <thomas.mercadante@xxxxxxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 18 Aug 2004 07:54:39 -0400
My point is that by suggesting such a security policy, you may be giving the
lesser-experienced DBA's an idea that it is the correct way to go. In no
database is this a correct policy.
The tool is not the problem here. Correct security policy is the tool. And
as you said, security by obscurity is no security at all.
Tom Mercadante
Oracle Certified Professional
-----Original Message-----
From: Jesse, Rich [mailto:Rich.Jesse@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, August 17, 2004 4:25 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Using TOAD on production databases
I understand and agree with your position, but it wasn't the point -- the
point was allowing the sometimes dangerous ease of TOAD into a production DB
with hopefully the least amount of destructive ability. It may be construed
as security-through-obscurity (which is not security at all), but in some
cases, it has it's place. It's orders of magnitude easier for a TOAD user
to accidentally drop all tables in a schema than it is in SQL*Plus. And the
Schema Browser is an accident that's waiting to happen. He11, I'm just happy
that 9i doesn't allow an account with DELETE ANY TABLE to muck up the DD!
:)
Rich
-----Original Message-----
Sent: Tuesday, August 17, 2004 1:59 PM
Subject: RE: Using TOAD on production databases
Rich,
Why in the world go through all of this?
Why not do it the right way?
Why not use Oracle security as it is designed - do not grant any more access
than a person needs.
I'll bet you a $100. Go ahead and set up security based on denial of access
from Toad. Give me an Oracle account with full access to the database. And
I'll be selling your database's data on e-bay in about 10 minutes.
It is simply foolish to attempt to apply security policy on an Oracle
database based on the tool that a person connects with. Foolish and a waste
of time.
Hope this helps.
Tom Mercadante
Oracle Certified Professional
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
