Quali autorizzazioni devono avere gli sviluppatori nell'istanza del database Dev

Question

... e come dovrebbero essere concesse tali autorizzazioni. Lavoro in un grande reparto IT con oltre 70 applicazioni, alcune in SQL server e la maggior parte in Oracle. Ogni sistema ha un'istanza di prod, QA e Dev. Noi (io sono uno sviluppatore) abbiamo accesso in sola lettura a prod/qa, con cui sto bene. Negli sviluppatori di istanze di sviluppo del server SQL viene fornito db_owner, che funziona perfettamente. Il dibattito riguarda le autorizzazioni che dovrei avere nei database Oracle Oracle.

Riconosco che il caso migliore sarebbe che ogni sviluppatore esegua la propria istanza sulla propria workstation per lo sviluppo, ma a causa delle dimensioni dei database questa opzione non è stata considerata.

Sono anche interessato a COME devono essere applicate queste autorizzazioni. In oracle le autorizzazioni concesse tramite un ruolo non sono attive durante l'esecuzione di PL/SQL, quindi i ruoli (anche il ruolo "dba") non sono utili. Questo lascia utilizzando un account (sistema) integrato o creando dozzine di utenti su dozzine di database e concedendo direttamente a loro decine di autorizzazioni. Nella mia mente, lasciare che gli sviluppatori facciano il login come sistema ha molto senso, ma i nostri DBA affermano che è una cattiva idea.

Answer 1

Abbiamo usato solo per dare agli sviluppatori l'accesso all'account dell'applicazione. Questo funziona per i negozi di piccole dimensioni ma rapidamente sfugge al crescere del numero di sviluppatori.

Qui è quello che facciamo oggi:

1. l'applicazione ha il proprio conto (aka schema).
2. Gli sviluppatori hanno i loro conti
3. dati risiedono nello schema applicazione
4. Abbiamo uno script Ant per costruire il codice in qualunque schema che si desidera.
   • codice include vista, pacchetti, oggetti ecc ..
   • lo script di build include un passo per eseguire una stored procedure per concedere i diritti espliciti agli sviluppatori per i dati delle applicazioni
5. gli sviluppatori a fare cambiamenti nella loro proprio schema
6. Se felici controllano che in sovversione
7. Lo schema di dev dell'applicazione è costruito dalla nuova generazione di subversion.
8. Gli sviluppatori possono controllare e ricostruire i propri ambienti.
9. modifiche DDL alle strutture di tabella vengono effettuate tramite il DBA
   • questi possono essere script così

Questo ha il vantaggio di garantire tutte le applicazioni front-end, non è rotto da sviluppatori di database costantemente ricostruire tutto.

Answer 2

Uno dei compiti del DBA è la gestione dei privilegi degli utenti. Non penso che il sistema sia una buona idea per alcuni motivi, non ultima la possibilità di eliminare un intero schema che sono sicuro che tu non voglia. Detto questo, penso che sia perfettamente giusto concedere tutto agli utenti e lasciare che i DBA gestiscano queste autorizzazioni, indipendentemente da quante decine di account ci siano. La maggior parte degli amministratori di database dispongono di script che possono essere utilizzati per gestire comunque tali autorizzazioni.

Ascolta i tuoi DBA, generalmente sanno di cosa stanno parlando.

Answer 3

Se è solo un'istanza di sviluppo; avrei tutti gli utenti hanno aggiunto account individuali al ruolo di amministratore. In questo modo è ancora possibile registrare attività per utente; ma dai agli sviluppatori abbastanza spazio per fare le loro cose.

Answer 4

Presumo che ci sia un numero relativamente piccolo di account di applicazioni che possiedono gli oggetti reali. Quindi una o più applicazioni logiche sono composte da tabelle di proprietà di un particolare utente Oracle. Questo non sarebbe da SYSTEM o SYS, non sarebbe uno dei conti che Oracle l'azienda offre. Sarebbe un account creato dai tuoi DBA. Se si ha familiarità con gli schemi di esempio Oracle, l'utente delle risorse umane possiede tutte le tabelle nello schema delle risorse umane che comprendono il back-end per un'applicazione HR.

Partendo dal principio di "la cosa più semplice che potrebbe funzionare", il mio primo pensiero sarebbe di vedere se gli sviluppatori potevano accedere direttamente a quegli account di applicazione. Questa non è la configurazione più sicura possibile, e si sta aprendo la possibilità che uno sviluppatore accidentalmente o intenzionalmente fa un danno che può essere difficile da tracciare o risolvere facilmente. Ma può funzionare abbastanza bene a seconda dell'organizzazione. La gestione dei privilegi è banale: l'account del proprietario dell'applicazione ha già tutti i privilegi di cui ha più bisogno.

Il prossimo passo sarebbe dare a ogni sviluppatore uno schema separato per lo sviluppo, presumibilmente in congiunzione con un carico di sinonimi pubblici nel database e un'assenza di qualificatori dello schema nel codice dell'applicazione, in modo che qualsiasi oggetto creato nel lo schema dello sviluppatore sovrascrive automaticamente la versione condivisa di quell'oggetto. Questo fornisce un isolamento molto migliore. Le autorizzazioni vengono generalmente concesse creando script che contengano tutte le concessioni di cui uno sviluppatore ha bisogno o creando uno script che copi tutti i privilegi da un account "conosciuto" al nuovo account. Né è particolarmente difficile scrivere, basta assicurarsi che tutti gli sviluppatori finiscano con lo stesso set di privilegi, che è generalmente solo un altro script che viene eseguito quando viene concesso un nuovo privilegio.

Answer 5

Il mio gruppo supporta circa 100 app con circa 20 di loro con il proprio schema Oracle. Siamo andati lungo la strada di ogni sviluppatore ha la password per lo schema ed è conveniente. Tuttavia, a ben vedere, consiglierei a ciascuno sviluppatore di utilizzare il proprio account Oracle per lo sviluppo. Il motivo principale è l'auditing.

Answer 6

riconosco che migliore delle ipotesi sarebbe quella di avere ogni Dev gestiscono propria istanza sulla loro postazione di lavoro per lo sviluppo, ma a causa delle dimensioni dei database questo non è stato considerato un'opzione.

C'è un modo per affrontare questo, forse riducendo la quantità di dati nelle copie personali? Questa sembra la soluzione ideale, poiché ti consentirebbe di apportare le modifiche necessarie. Quindi puoi inviarli al DBA quando sei pronto e fargli aggiornare il server di sviluppo condiviso.

Answer 7

Se si stanno sviluppando oggetti PL/SQL memorizzati, lo schema proprietario di tali oggetti ha bisogno, come già accennato, di concessioni esplicite sugli oggetti utilizzati. Se si dispone di un singolo schema di "dati" ma si sta sviluppando codice nei propri schemi individuali, si dovrebbe ottenere la possibilità di concedere l'accesso agli oggetti dello schema di dati ai propri schemi di sviluppo. Normalmente mi aspetterei username/password per lo schema dei dati.

Per quanto riguarda i privilegi di sistema (ad esempio CREATE), mi aspetto di CREATE TABLE, TYPE, VIEW, TRIGGER PROCEDURE, SYNONYM. Altri potrebbero essere appropriati (ad esempio CONTESTO) a seconda di ciò che fai. Il DBA può escludere CREARE DIRECTORY in quanto potrebbe essere dannoso se usato in modo errato. Idem per i privilegi con ANY in loro (es. SELEZIONA QUALSIASI TABELLA, ELIMINA QUALSIASI TABELLA)

Per la regolazione delle prestazioni/monitoraggio del sistema, su un database di sviluppo SELECT_CATALOG_ROLE è buono. Se il DBA è avverso al rischio, potrebbe essere necessario negoziare sovvenzioni su singole visualizzazioni. Passare attraverso la guida REFERENCE per la tua versione e chiedere qualsiasi cosa tu possa usare.