Title: Protecting schema changes
In a n-tier system that connects to the database with JDBC, how does a DBA keep developers from modifying the application schema without the DBA's consent or knowledge in a centralized development environment?
The developers can have their own personal
Following is one approach that I had implemented... (oracle 8i and up).
The credit goes to Joe Testa for posting it 3 years ago :)
- Kirti
On Thu, 6 Jan 2000, Joseph Testa wrote:
Why would you want to do that, well, i'm at a place where the developers
have the schema owner password
Title: Message
Revoke
the create table privileges.
-Original Message-From: Webber Valerie H
[mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003
11:50 AMTo: Multiple recipients of list ORACLE-LSubject:
Protecting schema changes
In a n-tier system that connects
Val,
One option is to provide access via an account that is not the owner of
these objects but has all required DML privs but not DDL privs. If you
cannot do this, you could always code in a Database level trigger for DDL
and rap the Developer's knuckles when they do something out of turn. We
Valerie - Here is what I've been doing. Say the application uses SCHEMA_A.
Create schema SCHEMA_B and create all objects in that schema. Grant select,
insert, delete, update access for all objects to SCHEMA_A. In SCHEMA_A,
create synonyms to point to the objects in SCHEMA_B. Only give the
Title: Protecting schema changes
Val,
1).
Create a role. Grant select, insert, update and delete of all the tables,
views, sequences, procedures, packages and functions used by the application to
this role.
2).
create public synonyms for the objects in the application
synonym.
3).
create
Title: Protecting schema changes
Super!
Is it okay to grant 'select any table' or should it be
object specific? I'd think object specific would be more
secure.
Thanks for your help and have a nice weekend
too!
Val
-Original Message-From: Mercadante, Thomas F
[mailto:[EMAIL
Title: Protecting schema changes
Seperate the object owner from the account which they
use to connect. So they would connect through
an
account that doesn't actually own any objects but just have enough privilege to
access them.
-Original Message-From: Webber Valerie H
[mailto
We faced a similar problem. We use change control to help manage this.
The developers have the schema password in development , but not in UAT
(Certification) or Production. We create a run-time userid for their
application to use rather than logging in as the schema owner. The
run-time userid
or allow modification to the data only through stored procedures . compile
stored procedures in to another schema ( having dmp rites ) . Give execute
privilage to the gateway schema .
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Friday, January
10 matches
Mail list logo
