Qualche suggerimento per ridurre i miei privilegi nella produzione ma non rendere il mio lavoro eccessivamente difficile

Esecuzione di SQL Server 2005 e 2008 su Windows 2008 R2.

Ridurremo i privilegi di produzione per gli sviluppatori - e mi piacerebbe fare lo stesso per me come DBA , limitando i diritti alla produzione e aumentando quando necessario .

Il mio obiettivo principale sarebbe quello di eliminare gli stupidi errori - fatti dai DBA , i devopers avranno al massimo l'accesso in lettura nella produzione. Ci piace comportarci come se fossimo dei supereroi che non possono sbagliare, ma non avere sempre diritti di produzione ha senso ed è una buona pratica, raccomandata da alcuni.

Qual è l'approccio migliore? Cosa sarà meno doloroso da usare giorno per giorno e durante le installazioni?

Al momento disponiamo di un gruppo windows per DBA che ha diritti su tutti i nostri server e database.

Sarei anche interessato a ridurre le autorizzazioni di accesso al sistema operativo / remoto, ma sono più interessato ai diritti DB.

Immagino che avremmo bisogno di privilegi elevati per eseguire tracce come sa, e possibilmente per una pulizia della proprietà prima di togliere i diritti SA del nostro vecchio login. Quali altri problemi possiamo aspettarci?

Grazie per i tuoi consigli e per condividere le tue esperienze!

Idealmente, per un database di produzione operativo, non si desidera che gli sviluppatori abbiano alcun accesso al server o alcun database su di esso. Questo genere di cose è una delle prime cose che dovrete fare per la conformità SOX .

Per il tipo di diritti che userids corrono sotto, gli unici diritti che realmente dovrebbero avere sono db_datareader, db_datawritered esplicita GRANT EXECUTE ON x TO y(per ogni proc memorizzato e la funzione definita dall'utente xper l'userID y).

Se devi eseguire tracce nella produzione, hai dei problemi e ci vorrà una Great Wall of Text ™ per spiegare tutto. La mia prima raccomandazione è di avere un ambiente di controllo qualità bloccato proprio come la produzione e se è necessario eseguire le tracce, ripristinare un backup del db prodotto nel QA ed eseguire le tracce lì. Ancora una volta, se si hanno requisiti SOX, HIPAA o PCI-DSS , è meglio disinfettare i dati del prod prima di ripristinarli nel QA.

Al momento disponiamo di un gruppo windows per DBA che ha diritti su tutti i nostri server e database.

Concedi loro l'accesso e visualizza i diritti sui dati; tuttavia per eseguire compiti DBAly, utilizzare un accesso separato con privilegi elevati. Conosco un cliente finanziario che lo fa: i normali accessi basati su autenticazione di Windows erano limitati nel danno che potevano inavvertitamente fare. Ripristini ed esecuzione di DML richiesti in esecuzione con il login di autenticazione SQL separato.

Un'agenzia governativa con cui ho lavorato ha usato 2 accessi separati per ciascun server / amministratore di database. Quindi, se Tangurenafosse il mio accesso al dominio (questo accesso avrebbe Userprivilegi regolari ), allora TangurenaAdminsarebbe il mio Administratoraccesso separato . Ti metterai nei guai se usi sempre il tuo account amministratore, ma poi non ha i permessi per altre cose (come nessuna e-mail. Oh, dici che è una brutta cosa ... ).

L'attuale agenzia governativa con cui sto lavorando ha ogni server / amministratore di database con privilegi elevati rispetto all'utente standard, ma non abbastanza amministratore (pensalo come il PowerUsergruppo). Le funzioni di amministratore di dominio vengono eseguite con un account amministratore di dominio condiviso.

Un errore comune è il ripristino del database errato (come il QA ripristinato sul server di produzione) e questo non verrà risolto tramite diritti limitati o accessi multipli. Fare cose potenzialmente distruttive in coppia è un modo per ridurre al minimo i rischi.

Immagino che avremmo bisogno di privilegi elevati per eseguire tracce come sa

No. Hai solo bisogno delle autorizzazioni ALTER TRACE:
http://msdn.microsoft.com/en-us/library/ms187611.aspx

Inizialmente, ti suggerisco di svolgere tutti i privilegi in un ambiente di sviluppo o di controllo qualità dove non vi sono problemi se l'accesso viene rimosso per un po 'di tempo. Dovrai vedere se le applicazioni non avranno problemi di sicurezza.

Ti dirò il nostro approccio interno:

• tutte le applicazioni utilizzano un singolo utente del dominio a cui sono concesse le autorizzazioni necessarie su un database (di solito ruolo del database db_owner).

• per i dati occasionali letti utilizziamo un login SQL. A quell'utente viene assegnato il ruolo di database - db_datareader. È qui che termina l'accesso per gli sviluppatori sul cluster di database principale. Per qualsiasi altra idea che avrebbero, useranno i database del server di report che sono copie (eseguite utilizzando Log Shipping) dei database del server principale eseguiti a mezzanotte. Per non uccidere il server di report con query killer ad hoc, utilizziamo le allocazioni dei gruppi di risorse per memoria e CPU.

• per il team DBA abbiamo un gruppo di dominio che ha tutti i privilegi sulla macchina e sul server (admin sulla macchina windows e sysadmin sul server sql)

• per le installazioni abbiamo un utente SQL che è db_owner nei database che utilizziamo durante l'esecuzione degli aggiornamenti: utilizziamo i trigger DDL per monitorare le modifiche dello schema e dovremmo vedere quali modifiche sono state apportate durante l'installazione o come modifica separata

• ci sono alcune eccezioni occasionali per gli sviluppatori esperti, ma dopo che le loro esigenze sono state soddisfatte rimuoviamo il loro accesso: ricevono le autorizzazioni in base al loro accesso al dominio, in modo da poter monitorare le connessioni nelle viste tracce / ddl e qualsiasi possibile modifica con i trigger ddl.

Per quanto riguarda il modo di fare tutto ciò che funziona con gli accessi e gli utenti: in Management Studio nella cartella di sicurezza del server crei tutti gli accessi necessari, quindi li associ ai tuoi database e assegni loro i ruoli di cui hanno bisogno. Se esegui lo script dell'azione, vedrai che inizialmente verrà creato un accesso al server, quindi un utente del database connesso a tale accesso, quindi assegnato un ruolo di database per quell'utente. Puoi tenere lo script nel tuo set di script, in modo da poter verificare ogni volta quali utenti devono essere attivi e attivi e quali no.

In SQL Server è possibile creare un utente del database e assegnarlo a database rolecon autorizzazioni di lettura / scrittura / proprietà. Una volta che l'utente è migrato alla produzione, è possibile passare all'utente del database che è stato migrato e deselezionare i ruoli che non si desidera che abbia. Ad esempio, supponiamo che l'utente stan sia un membro di db_owner (proprietà del database) nel test. Una volta che lo stan utente è stato migrato alla produzione, è possibile estrarlo da db_owner e assegnargli solo un ruolo di db_datareader (sola lettura).

In SQL 2005+ è possibile eseguire un controllo più granulare con schema. Controlla questo link sullo schema per maggiori dettagli.