Concessione dei privilegi SA per gli sviluppatori sulla casella di sviluppo

8

Nonostante le nostre veemente proteste, il nostro management ha deciso che al team di sviluppo devono essere concessi diritti "sa" sul server di sviluppo. Il problema è che noi, il gruppo di supporto DB, siamo ancora responsabili del mantenimento di questa scatola.

Ora ci è stato affidato il compito di presentare un elenco di cose da fare e da non fare per i team di sviluppo con questi privilegi avanzati.

Si prega di aggiungere a questo elenco:

DO: limitare le attività al DB in fase di sviluppo

NON --

  • modificare eventuali impostazioni dell'istanza SQL
  • sp_configure (incluso cmdshell)
  • aggiungere / modificare / eliminare eventuali impostazioni di sicurezza
  • aggiungi / modifica / elimina oggetti database
  • aggiungere / modificare / eliminare oggetti server come dispositivi di backup e server collegati
  • aggiungi / modifica / elimina replica
  • aggiungere / modificare / eliminare i piani di manutenzione
  • toccare un database che non appartiene alla tua squadra

Qualsiasi suggerimento sugli strumenti disponibili per tenere traccia delle attività di questi utenti sarà molto apprezzato.

sql-server  sql-server-2005  permissions 
— Raj
fonte
1
Quali compiti devono svolgere per richiedere privilegi di livello superiore di SA?
Penserei che db_owner sarebbe tutto ciò di cui hanno bisogno ...
5
OK, se viene loro consigliato di NON "aggiungere / modificare / eliminare gli oggetti del database", cosa dovrebbero fare? Il punto di avere una scatola di sviluppo non è forse che possono romperla?
— Stuart Ainsworth,
Questi sono sviluppatori di applicazioni. Hanno bisogno dei privilegi di "sa" per poter eseguire il debug delle stored procedure in Dev Studio. La decisione è già presa dalla direzione e non sono disposti a muoversi. Stiamo cercando di ridurre al minimo il potenziale mal di testa
2
+1 per la domanda, poiché ho riscontrato questo problema un paio di volte. Un'altra soluzione: dai agli sviluppatori una VM sandbox con SQL su di loro di cui sono al 100% boss. Sono anche responsabili al 100% di mantenerlo in vita :) -> è sorprendente la velocità con cui i DEV imparano a non rompere il proprio sistema :)
— Martin S. Stoller

Risposte:

8

Se non è troppo tardi, un'opzione di compromesso che ho visto funzionare bene è piuttosto che aggiornare le autorizzazioni o sostituire gli account esistenti degli sviluppatori, creare un account separato che viene utilizzato solo quando hanno bisogno di autorizzazioni elevate.

Quindi normalmente funzionano con singoli account "limitati" (che uso in modo approssimativo perché questi account con restrizioni hanno ancora bisogno di alcune pesanti autorizzazioni - ovvero creazione, eliminazione, modifica delle tabelle). Ma per quella rara occasione in cui pensano di aver bisogno sa, possono accedere usando questo account. Quindi puoi contrassegnare l'account nei tuoi registri e fare un ulteriore monitoraggio su di esso. Hai concesso agli sviluppatori l'accesso richiesto, ma in un modo un po 'più controllabile.

Alla fine, in caso di abuso, i log di questo account possono essere utilizzati come prova per portarlo via.

— Joel Coehoorn
fonte
6

Qui dice (MSDN) che è necessario sysadmin (sa) per eseguire il debug su SQL Server 2005.

Tuttavia, questa domanda SO mostra un altro modo senza sa, che è quello che ho pensato inizialmente. Consenti semplicemente loro di correresp_sidedebug

Suggerirei anche di dare loro SQL Express locale che risolva anche altri problemi ...

(modificato con maggiori informazioni)

Modifica, dopo la risposta di W. Craig Trader

Altre questioni con diritti "sa", nel peggiore dei casi:

  • gli sviluppatori creeranno assembly CLR non attendibili
  • useranno xp_cmdshell
  • tutte le azioni sono nel contesto dell'account del servizio server sql
  • assumeranno i diritti per la connessione client
  • ecc ecc

per esempio xp_cmdshell 'scm -Action 6 -Server PRODSERVER'

— GBN
fonte
1
La risposta agli sviluppatori che codificano al di fuori delle linee è di fare un'integrazione continua con il sistema di blocco "come verrà eseguito dalle autorizzazioni degli utenti e fallire la compilazione di conseguenza. Chiedi al server di build di ricreare il database da zero e di popolarlo con i dati di test (ovviamente tutti da SCM). (Nel mio caso, ho usato esattamente lo stesso codice che il programma di installazione dell'applicazione userebbe per creare un nuovo database, testando così il programma di installazione e l'applicazione.)
1
Commerciante @Craig: non funzionerà. Per riformulare la mia vecchia risposta, non ci si può fidare degli sviluppatori e l'integrazione non rileverà tutti i casi. Sono uno sviluppatore dba: una scimmia codice client è il mio nemico. Nella mia azienda, vinco ... è il mio convoglio e mi occupo del minimo comune denominatore ...
— gbn
Apparentemente, il tuo chilometraggio può variare. Nella mia esperienza, di solito ho dovuto fare un po 'di allenamento / orientamento per spiegare come e perché le cose vengono fatte, ma dopo di ciò le cose di solito funzionano abbastanza bene. Certo, insisto sempre che le uniche build che vanno oltre lo sviluppo sono quelle che provengono dal server di build strettamente controllato - se il codice non viene compilato lì, è un problema con il tuo codice (o i tuoi test) e non con configurazione. L'ho fatto con piccoli team e grandi progetti, in molte aziende e sempre con successo.
4

Il suggerimento che ho è quello di impostare la gestione basata sulle politiche e applicare tutte le regole "fare" e "non". Questo farebbe molto per proteggere l'istanza.

Distribuirei anche il controllo delle modifiche DDL, vedi Controllo in SQL Server 2008 , non tanto come deterrente, ma soprattutto come sistema di tracciamento delle modifiche, quindi quando qualcosa viene rovinato, almeno saprai cosa è cambiato.

— Remus Rusanu
fonte
3

Se si tratta del server DEVELOPMENT, qual è il problema con i DEVELOPERS che possono avere pieno accesso? Dire agli sviluppatori che non è possibile aggiungere / rimuovere / modificare oggetti di database (ad es. Tabelle, colonne, indici) è come dire loro "Puoi avere un compilatore, ma non puoi eseguirlo". Mi sembra che gli sviluppatori desiderino / abbiano bisogno dell'accesso alla propria istanza di database in modo specifico per consentire loro di testare diversi metodi di risoluzione dei problemi SENZA dover confondere con i database PRODUCTION o TEST. Dovresti incoraggiare quel tipo di comportamento, non scoraggiarlo.

Alcuni potrebbero suggerire che gli sviluppatori lavorino con istanze locali di SQL Express, ma mentre SQL Express per ogni sviluppatore può risolvere determinati problemi, presenta limiti e caratteristiche prestazionali diversi rispetto a SQL Server completo su un server separato.

Quello che DOVREBBE fare è istituire un programma di backup regolare (almeno ogni notte) e collaborare con gli sviluppatori per assicurarsi che sappiano come avviare backup non programmati e ripristinare dai backup, in modo da ridurre al minimo i tempi di inattività in caso di problemi.

— Craig Trader
fonte
La tua analogia è completamente sbagliata. Quello che succede è che vanno in giro e poi si frustano quando non riescono a migrare i loro muck su server bloccati. Sono uno sviluppatore DBA ovviamente :-)
— gbn
Quindi un po 'di educazione è in ordine. Sono uno sviluppatore il cui DBA è stato troppo spesso. Con un piede in entrambi i mondi, di solito è stato il mio lavoro insegnare a entrambe le parti a convivere. Dopotutto, sono gli UTENTI che sono i nemici, non i DBA o gli sviluppatori ...
Ci sono anche cose come i piani di manutenzione a cui non dovrebbero avere accesso.
— Joel Coehoorn,
1
Il problema è che abbiamo più gruppi Dev e questo server ospita tutti i loro DB. Questo gruppo che richiede diritti "sa" possiede solo il 33% dei Dbs. La preoccupazione è che potrebbero rovinarsi e far crollare il server, incidendo anche su altri gruppi. La società non vuole ottenere hardware separato per loro, a meno che non siamo in grado di dimostrare che hanno rovinato.
2
È ridicolo. Ogni gruppo di sviluppo dovrebbe avere il proprio server, in modo tale che nessuno passi su qualcun altro. L'hardware in questi giorni è praticamente gratuito e il software è quasi economico quanto l'hardware. E se la tua organizzazione è abbastanza grande da avere più gruppi di sviluppo, dovrebbe utilizzare la virtualizzazione del server, il che renderebbe tutto ancora più semplice.
3

Suo il dev server, non il server di gruppo di supporto di DB, o il server di produzione. Mantieni un buon backup / immagine e lascia che gli sviluppatori si allontanino. Lasciare il controllo di DBA al devbox è come lasciare scodinzolare il cane. È lì per gli sviluppatori per fare il lavoro degli sviluppatori. Ciò comporta la rottura delle cose a volte e l'abbandono dei tavoli, quindi il loro ripristino con impostazioni diverse. Le scatole di sviluppo saranno sempre in uno stato di rovina dopo un po ', ecco cosa facciamo. Se non sappiamo dove si sta verificando un problema, proviamo diverse cose. Alcuni sono facili da annullare, altri non così tanto.

Il problema qui è che è facile per gli sviluppatori dimenticare che le app che costruiscono non avranno sempre gli stessi diritti. Sì, dai loro sa, ma fai in modo che non siano sa per impostazione predefinita, in modo che siano consapevoli quando stanno facendo qualcosa che avrà bisogno di un po 'di lavoro extra per essere distribuito correttamente.
— Joel Coehoorn,
1

Non credo che abbiano bisogno dei privilegi SA nella casella Sviluppo. In quasi tutti i casi, possono farne a meno.

Penso che una buona opzione sia quella di installare l'edizione di sviluppo locale.

domanda:

Non vuoi che gli sviluppatori aggiungano / cambino / eliminino oggetti di database? !! Come si svilupperanno?

— Raj More
fonte
Mi dispiace per la confusione. Quello che intendevo con quel punto elenco era che gli sviluppatori non devono modificare le impostazioni del database o eliminare i database.
1

Richiediamo che tutte le modifiche alla struttura del database vengano eseguite con script (anche su dev) e salvate in sovversione. Quindi, con un programma prestabilito, aggiorniamo gli sviluppatori dal prod e devono rieseguire i loro script per tornare al punto in cui si trovavano nel ciclo di sviluppo. Questo aiuta a garantire che tutto venga eseguito tramite script e che siano pronti per gli script quando è il momento della distribuzione.

So che nel 2008 puoi impostare DDL Trigger per tenere traccia delle modifiche strutturali del database, puoi farlo nel 2005? In questo modo almeno puoi scoprire quando qualcuno cambia un'impostazione che lo ha fatto e scoprire perché.

— HLGEM
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.