Sicurezza per gli sviluppatori di applicazioni che eseguono PL / SQL in Oracle

Come gestite la mancanza di privilegi a livello di schema in Oracle? L'architettura di sicurezza di Oracle funziona bene per le applicazioni che richiedono solo privilegi a livello di oggetto e funziona bene per i DBA che richiedono poche restrizioni. Tuttavia, sembra esserci un grande buco nell'architettura per i programmatori che fanno sviluppo con un'applicazione front-end e PL / SQL in più schemi. Ecco alcune delle mie opzioni con i loro lati negativi:

1. Fai in modo che ogni programmatore esegua lo sviluppo nel proprio schema. Il DBA concederà privilegi a livello di oggetto ai programmatori che ne hanno bisogno. Qualsiasi sviluppo di pacchetti deve essere eseguito da un DBA. Il principale svantaggio è che i programmatori useranno il database come un secchio a scapito delle prestazioni del database. Voglio che i programmatori si sviluppino nel database, ma questo metodo lo scoraggerebbe notevolmente.

2. Assegnare a ciascun programmatore il nome utente / la password per la dozzina di schemi in cui è necessario eseguire lo sviluppo. Concedere queste autorizzazioni per lo schema dell'applicazione per creare procedure, tabelle, ecc. Alcuni degli svantaggi di questo approccio sono che i programmatori devono mantenere più accessi e raramente effettuato l'accesso come se stessi. Anche lo sviluppo di schemi incrociati è difficile.

3. Concedere ai programmatori i privilegi di autenticazione proxy su ogni schema per il quale devono eseguire lo sviluppo. Ciò li mantiene registrati come se stessi senza dover concedere loro privilegi diversi dal privilegio proxy. Gli svantaggi includono i programmatori che devono mantenere connessioni separate per ogni schema per cui sono proxy, lo sviluppo dello schema incrociato è più complicato poiché le connessioni devono essere costantemente modificate e i pacchetti che utilizzano collegamenti a database pubblici con autenticazione passata non verranno compilati all'interno di connessioni proxy.

4. Assegna a ciascun programmatore i privilegi DBA. - L'aspetto negativo qui è la sicurezza. Nessun programmatore di schemi può essere tenuto fuori da qualsiasi schema e qualsiasi programmatore può impersonare qualsiasi altro programmatore (DBA).

Sembra che manchi un'opzione per concedere a ciascun programmatore SELECT / INSERT / CREATE / etc. privilegi sullo schema di cui hanno bisogno per fare lo sviluppo. Accedono come se stessi per fare il loro lavoro usando una connessione. I nuovi oggetti nello schema a cui hanno accesso sono immediatamente disponibili.

Mi sto perdendo qualcosa? Come gestite i programmatori di applicazioni che eseguono lo sviluppo PL / SQL?

Ai tempi in cui lavoravo in un negozio Oracle, avevamo un server "dev" (sviluppo) specifico, che aveva restrizioni di sicurezza diverse rispetto al server "prod" (produzione). Gli sviluppatori potevano fare tutto ciò di cui avevano bisogno e quindi passavamo gli script necessari al DBA per applicarli al server di produzione.

Nel caso dei nostri sistemi critici (SCT Banner, per il monitoraggio di classi e studenti e Oracle Financials), c'erano anche server "test" e "seed". Il test era per il test di accettazione da parte dell'utente prima che le cose migrassero da dev a prod; 'seed' era l'installazione stock del software, quindi dovremmo trovare un bug, potremmo verificare se fosse qualcosa che avevamo introdotto o proveniva da SCT o dal software Oracle.

Utilizzare i ruoli per associare raccolte di oggetti, quindi concedere l'accesso ai ruoli

L' istruzione GRANT consente al DBA di:

Privilegi di un oggetto specifico per utenti, ruoli e PUBBLICO. La Tabella 18-2 elenca i privilegi degli oggetti e le operazioni che autorizzano.

Poiché i privilegi di oggetto possono essere concessi a un ruolo, è relativamente facile concedere a un ruolo l'accesso a tutte le tabelle in uno schema:

sql> spool privs.sql
sql> select 'grant select on scott.' || nome_tabella || ' to role_select; ' da dba_tables dove owner = 'SCOTT';
SQL> @ privs.sql
sql> grant role_select a john, sam, peter;

Ciò, combinato con il GRANT CREATE TABLErilascio da parte dell'utente appropriato dello schema al ruolo, consente agli sviluppatori di selezionare e creare tabelle. Non è perfetto poiché una tabella creata richiede di eseguire nuovamente lo script, ma WITH GRANT OPTIONsuggerisce che ogni sviluppatore possa quindi concedere l'accesso alla tabella creata per il ruolo appropriato.

Ciò suggerisce che è possibile creare trigger di livello DDL in grado di eseguire il processo di concessione appropriato, anche se ovviamente saranno necessarie quantità significative di test, dovrebbe essere possibile fare in modo che l'istruzione create table conceda automaticamente le autorizzazioni appropriate ai ruoli appropriati.

Modificare --

Secondo GRANT , il CREATE TABLEprivilegio:

Creare una tabella nello schema del beneficiario.

Pertanto, dando loro la creazione di una tabella, una modifica della tabella, ecc. Da parte dell'utente corretto, dovrebbero essere in grado di accedere allo schema di quell'utente come se fossero l'utente appropriato.