RE: restrict schema A from schema B

  • From: "Goulet, Richard" <Richard.Goulet@xxxxxxxxxxx>
  • To: <joe_dba@xxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Mon, 11 Oct 2010 22:42:48 -0400

Joe,
 
    1st you seriously need to explain Oracle security to your
management, because they obviously don't understand it.  Second, use
your own role for both schema's that gives them the right to create
their own objects, but not access anyone else's.  Something that I call
the developer role:
 
create role DEVELOPER;
grant create table to developer;
grant create sequence to developer;
grant create view to developer;
grant create procedure to developer;
grant create trigger to developer;
grant create job to developer;
grant create cluster to developer;
grant create type to developer;
grant CREATE INDEXTYPE to developer;
 
    Next when you create the schema's make sure they have their own
tablespaces, one for data and another for indexes if they are large.
    Lastly set up the database for auditing and audit all selects on
each schema.  That way you have a record that they did not look at each
other's data.
    You can also audit the granting of access to each schema's objects
as further proof that they didn't do it, or if they did who really did
the deed.
 

Dick Goulet 
Senior Oracle DBA 

 

________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Joe Smith
Sent: Monday, October 11, 2010 7:37 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: restrict schema A from schema B


How to restrict schema A from schema B.  
 
I have a db with schema B.  Our applications are written in C++ and they
use schema B.  We have to support a 3rd party product that will require
us to install schema A ( that supports the 3rd party app )  in our db.
How do I absolutely stop schema A from accessing schema B's objects?
Management want options on how to restrict access.  
 
Besides from granting privileges and assigning roles how can I stop
schema A from schema B's objects?  We already use security policies and
have discussed building a separate db for schema A.  
 
Has anybody else had this problem and how did they overcome it?
 
 
thanks.
 

Other related posts: