it-swarm.it

Gli sviluppatori dovrebbero essere in grado di interrogare i database di produzione?

Gli sviluppatori dovrebbero avere il permesso di interrogare (SELECT/sola lettura) database di produzione? Nel posto precedente in cui ho lavorato, il team di sviluppo aveva il db_datareader ruolo; dove lavoro ora il team di sviluppo non può nemmeno connettersi all'istanza di produzione.

Una delle istanze di test è una copia della produzione ripristinata da un backup di produzione una volta alla settimana, quindi non ci sono problemi con gli sviluppatori che vedono effettivamente i dati.

Quali buoni motivi ci sono per non consentire agli sviluppatori di interrogare la produzione (tranne per il semplice fatto che non vogliono che abbiano accesso ai dati sensibili di lettura)?

164
Tom Hunter

Dipende davvero se lo sviluppatore ha delle responsabilità di supporto. Se sono agganciati per il supporto di terza linea, probabilmente dovranno guardare il database di produzione per farlo.

Generalmente è una cattiva idea fare qualsiasi cosa su un server di produzione a meno che non sia davvero necessario farlo lì.

Per la maggior parte degli scopi di sviluppo, i mirror o gli snapshot del database di produzione saranno adeguati e probabilmente migliori del database di produzione live. Se stai facendo qualcosa che coinvolge l'integrazione, allora vorrai ambienti di database stabili dove puoi controllare cosa c'è dentro. Qualunque cosa comporti la riconciliazione avrà anche bisogno della capacità di guardare un punto controllato nel tempo.

Se il problema è che non disponi di ambienti mirror di produzione o di mezzi per mettere una copia dei dati di produzione da qualche parte per i tuoi sviluppatori, allora questa è una domanda leggermente diversa. In tal caso i tuoi sviluppatori hanno davvero bisogno di almeno un ambiente mirror. Se non riesci a vedere qual è il problema nei dati, è difficile risolverlo.

No.

Gli sviluppatori non dovrebbero hanno accesso ai sistemi di database di produzione per i seguenti motivi:

  1. Disponibilità e prestazioni : avere diritti di sola lettura su un database è no innocuo. Una query scritta male può:

    1. Blocca le tabelle, bloccando altri processi critici.
    2. Cestino della cache dei dati, costringendo altri processi a rileggere i dati dal disco.
    3. Tassa il tuo livello di archiviazione, incidendo su altri servizi che condividono tale archiviazione.
  2. Sicurezza : il database di produzione può contenere informazioni riservate come:

    • hash delle password
    • informazioni di fatturazione
    • altre informazioni di identificazione personale

    Solo coloro che hanno assolutamente bisogno di accedere a queste informazioni dovrebbero averle. In un'azienda ben organizzata, gli sviluppatori non sono tra quelle persone. Inoltre, la tua azienda fallirà la conformità PCI e SOX se i suoi sviluppatori possono accedere ai sistemi di produzione con questi dati.

    Le ragioni sono ovvie. Il lavoro di sviluppo di uno sviluppatore passa attraverso molte mani prima di diventare attivo. Cosa impedisce a uno sviluppatore malintenzionato con accesso diretto alla produzione di rubare i dati di produzione o mettere in ginocchio il tuo database live?

    "Ma questo vale anche per i DBA! Potrebbero farlo!" Esattamente. Vuoi il minor numero di superutente possibile in modo responsabile.

Sì.

Gli sviluppatori dovrebbero hanno accesso ai sistemi di produzione.

Nella mia azienda abbiamo quattro team che si occupano di database di produzione. Loro sono:

  1. Sviluppatori , che progettano e scrivono lo schema e il codice per i database. Non hanno accesso ai database in produzione. Tuttavia, a volte siedono con gli amministratori o le persone di supporto e li aiutano a guardare qualcosa dal vivo.
  2. Amministratori , che distribuiscono, monitorano e gestiscono i database in produzione.
  3. Supportano le persone , che studiano i problemi di produzione sensibili al tempo e forniscono feedback agli sviluppatori in modo che possano sviluppare correzioni.
  4. Persone di Business Intelligence , che estraggono i dati dai database delle produzioni utilizzando copie periodicamente aggiornate di tali database o estratti scritti con cura e QA (di solito progettati dagli amministratori) ).

È opportuno concedere l'accesso alla produzione degli sviluppatori in presenza di determinate carenze in questi altri gruppi.

Per esempio:

  • Non hai un team di supporto. Chi saprà dove cercare per eseguire il debug di questo problema di produzione sensibile al tempo? I tuoi sviluppatori. Concedi loro l'accesso " rompi il vetro ".
  • Non hai un team di BI. I tuoi amministratori non hanno né vogliono avere a che fare con report o estratti. Chi risolverà il rapporto che i tuoi dirigenti vedono ogni mattina? I tuoi sviluppatori. Concedi loro un accesso limitato al debug di questi rapporti ed estratti.
  • Non hai un team di amministrazione. Sei in una società molto piccola o di avvio, quindi saluta il "DBA accidentale". I tuoi sviluppatori raddoppiano come i tuoi amministratori e quindi hanno bisogno di un accesso completo alla produzione.
136
Nick Chammas

Le prestazioni sarebbero un GRANDE motivo.

Solo perché non possono modificare i dati non significa che non possono influenzare il server. Una query scritta male potrebbe mettere in ginocchio l'ambiente di produzione e potenzialmente causare altri problemi (come overflow di tempdb):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

Questa è una ricetta per il disastro. Si noti che questo è un prodotto cartesiano con un ordine di, il che significa che verrà ordinato in tempDB.

79
JNK

Il principio è "privilegio minimo" e "necessità di sapere": gli sviluppatori superano questo test?
Soprattutto quando i Revisori o Sarbannes-Oxley bussano.

Quindi, il mio prossimo presupposto: gli sviluppatori sono stupidi. Quindi, se hanno bisogno di dire per il supporto di terza linea, chi allora ne ha bisogno? Le scimmie Web in genere non lo fanno, ma i tipi di database sì se sono tenuti a supportarlo.

Quindi, l'accesso è necessario in modo permanente? Possono avere un accesso "break glass" usando un login SQL o un account Windows alternativo che richiede una disconnessione. Nel nostro caso, è stato il proprietario dei dati (qualche uomo d'affari esperto di tecnologia, si spera) e il responsabile IT ad approvarlo.

Ho ho visto gli sviluppatori testare o eseguire query sulla produzione e eliminarlo a causa dell'ignoranza. Detto questo, gli sviluppatori dovrebbero assumersi la responsabilità delle loro azioni: se fanno smontare un server, dovrebbero soffrire di conseguenza. Ho qualcuno retrocesso dopo un incidente ...

Questi presuppongono ovviamente un negozio di dimensioni ragionevoli. Più i cappelli indossano, minore è la separazione dei compiti che puoi avere

Inoltre, esiste un ambiente in cui gli sviluppatori possono eseguire query su dati recenti? Nel mio ultimo negozio, prod è stato ripristinato ogni notte su un server di prova per fornire questo.

33
gbn

Penso che la risposta sia, come in molte cose dell'IT, "dipende".

Un enorme ERP con molte informazioni sensibili sulla società e sui clienti? Probabilmente no (sia per motivi di sicurezza che di prestazioni).

Un database dipartimentale da 5 MB con un front-end di Access che tiene traccia dei contributi ai fondi di ciambelle e pizza? Non farà molta differenza, almeno per l'accesso in sola lettura.

Certo, il primo esempio è molto più comune del secondo, ma queste sono differenze di cui dovresti essere consapevole se sei incaricato di prendere questo tipo di decisioni politiche. D'altro canto, è sorprendente la rapidità con cui un database di donut-and-pizza da 5 MB può raggiungere rapidamente un numero di parte 50 GB/numeri di carte di credito/clienti/chissà che cosa- altro database se lo lasci.

20
db2

In un normale 24/7 OLTP uno sviluppatore normale non dovrebbe essere autorizzato nella produzione. Periodo! Se, di volta in volta, appare un motivo particolare, le autorizzazioni potrebbero essere concesse su richiesta. Ma di solito no.

Ho visto molte ragioni per questo:

  • SELEZIONA * da un grande tavolo che porta a:

    • problemi di prestazione (prodotti cartesiani);
    • bloccare i problemi che alla fine hanno portato il sito in ginocchio;
    • catena di blocco che blocca la replica;
    • ordinando un grande insieme di dati che hanno riempito l'unità TempDB che .. indovina un po '? Causa follia completa :-)!
    • alta pressione sanguigna per il DBA responsabile della produzione per quella notte;
  • lettura di dati sensibili (uno sviluppatore non dovrebbe avere accesso alle informazioni della carta di credito ... o nessun dato personale dell'utente);

Sono sicuro che ci sono ancora più ragioni.

20
Marian
  • Sicurezza: potrebbero esserci informazioni sensibili che vengono disinfettate quando vengono rese disponibili agli sviluppatori.
  • Paranoia: alcuni potrebbero pensare che potresti ancora incasinare i dati semplicemente selezionando l'accesso.
  • Prestazioni: una query richiede alcune risorse per essere eseguita e non puoi dirmi che i tuoi sviluppatori sono perfetti quando scrivono codice.
19
Paul

Coppia di elementi da considerare

  • I dati sono sensibili?
  • I programmatori fanno parte di un team fidato di base o di un team offshore?
  • Qual è la portata dei dati su cui viene eseguita la query in termini di impatto sulle prestazioni?
  • Qual è la portata del progetto o dei dollari coinvolti?
  • Quanto è importante il tempo di attività?

Dollari più piccoli ha bisogno di meno processi ha bisogno di un flusso più rapido di sviluppo.

Dollari più grandi ha bisogno di più processi ha bisogno di standard più rigorosi delle pratiche di sviluppo.

Adatta le tue pratiche a ciò che stai facendo.

16
Jason Sebring

Lavoro come sviluppatore per un'azienda molto grande. Tutti i nostri sviluppatori che forniranno qualsiasi tipo di supporto (sostanzialmente tutti) hanno accesso ai relativi database di produzione. Posso parlare solo per il mio team specifico, ma ti dirò perché we abbiamo accesso.

  1. Dobbiamo accedere in tempo reale per tenere d'occhio la nostra elaborazione quotidiana. (Mentre abbiamo una dashboard, dobbiamo essere in grado di tenere d'occhio le cose in profondità. Anche se sarebbe bello avere questa funzionalità sulla nostra dashboard, abbiamo scoperto che non è pratico.)
  2. Abbiamo bisogno dell'accesso in tempo reale per indagare su eventuali guasti della produzione perché i ritardi possono avere un impatto enorme. (Non ho intenzione di discutere i nostri fallimenti qui. Vengono in tutti i tipi)
  3. Spesso abbiamo bisogno di creare report personalizzati per gli utenti aziendali e queste informazioni devono essere aggiornate. (i dba non hanno il tempo di farlo e non abbiamo il tempo di aspettarli. Non ideale, sicuramente.)
  4. Dobbiamo fare una verifica delle distribuzioni/patch DDL/DML di produzione. (I DBA li distribuiscono, ma solo noi sappiamo come dovrebbe essere strutturato. Sappiamo di più sulla nostra struttura di database rispetto ai DBA. Potremmo essere strani qui, ma il nostro database è molto complicato perché la nostra attività è molto complicata.)

Le prestazioni sono una preoccupazione. Abbiamo casi di sviluppatori che causano rallentamenti. Tuttavia, si tratta di istanze isolate e il nostro SQL è talmente guidato dalle prestazioni che è raro che i nostri sviluppatori non capiscano l'impatto delle loro query.

14
user606723

Per porre questa domanda si deve presumere che al momento non abbiano accesso. Se la propria organizzazione sta sviluppando software e questo serve a risolvere un problema del cliente e il cliente fornisce una copia del proprio database, allora "sì". Altrimenti, raccomanderei di mantenere gli sviluppatori fuori produzione e di creare ambienti alternativi creati per le loro esigenze di ricerca. Una volta che il dentifricio è uscito dal tubo, è difficile rimetterlo dentro.

11
jl01

Concordo sul fatto che l'onere della giustificazione dovrebbe essere su quelli che richiedono l'accesso. In genere in ambienti in cui ho consultato, ho avuto accesso a sistemi di produzione in cui era un piccolo ambiente ed ero la persona di supporto. Ho avuto accesso a backup, ecc. Dove ero supporto per il supporto e accesso indiretto (tramite uno sviluppatore di supporto dedicato) ai dati di produzione.

La cosa importante è: hai bisogno di questo accesso quando sei pronto per mantenere tutto senza intoppi e devi rispondere alla domanda del ragazzo finanziario su qualcosa che non funziona. In quel caso non puoi sempre lavorare anche con dati di un giorno. D'altra parte, maggiore è l'accesso, peggio è. In genere come consulente tendo ad evitare questo tipo di accesso a meno che non sia necessario. Dal momento che sto lavorando su database finanziari, l'ultima cosa che voglio è essere accusato di inserire le mie fatture MrGreen.

D'altra parte, se non hai bisogno di accesso non dovresti averlo. Non compro davvero l'argomento dei dati sensibili poiché lo sviluppatore è probabilmente all'amo per assicurarsi che sia gestito correttamente (ed è molto difficile verificare senza guardare a ciò che è stato effettivamente memorizzato quando arriva una segnalazione di bug). Se non puoi fidarti dello sviluppatore per guardare i dati che l'app dello sviluppatore sta memorizzando, non dovresti assumere lo sviluppatore per scrivere l'app. Ci sono troppi modi in cui lo sviluppatore potrebbe offuscare i dati e inviarli via email e non puoi mai esserne sicuro. I controlli MAC aiutano qui, ma sono ancora piuttosto complessi da implementare.

Il grosso problema da parte mia ha a che fare con l'accesso in scrittura. Se uno sviluppatore non ha accesso, a fortiori, lo sviluppatore non ha accesso in scrittura. Se si desidera verificare l'integrità dei libri, si desidera mantenere l'accesso in scrittura a quante meno persone possibile. Gli audit trail sono molto più facili da convalidare se gli sviluppatori non hanno accesso. Se lo sviluppatore ha accesso in lettura, allora hai sempre qualche domanda sul fatto che ci sia stato qualche allegato escallation di privilegi che può dare accesso in scrittura (forse iniezione SQL in-stored procedure?). Ho avuto accesso completo alle informazioni di fatturazione del cliente quando ho avuto accesso agli ambienti di gestione temporanea. Se esiste un ambiente di gestione temporanea che funziona, di solito chiedo attivamente di non di avere accesso alla produzione a meno che non sia necessario.

Quindi questo non è perfetto, ovviamente. Uno sviluppatore potrebbe ancora creare backdoor nell'applicazione che potrebbero non essere facilmente rilevabili, ma questo approccio è un approccio ragionevole, dato che i dati di backup sono disponibili da un giorno prima, mi sembra che questa sia la preoccupazione che hanno.

Spero che sia di aiuto.

Modifica: aggiungendo semplicemente che negli ambienti più grandi in cui ho lavorato, ho avuto accesso a dati di backup completi che vanno spesso da pochi giorni a pochi mesi per il sistema finanziario. Questo sempre è stato abbastanza buono per il mio lavoro e le uniche volte in cui si sono guastate sono state quando i finanziatori avevano bisogno di una capacità di testare con dati più recenti in modo da poterli confrontare con la produzione.

10
Chris Travers

Non avere accesso è una buona cosa e un modo per proteggere gli sviluppatori e altri da non corrompere accidentalmente i dati o visualizzarli. Ciò protegge anche le aziende dalla violazione della legge (ad es. Violazioni di Hipaa e problemi di privacy)

Uno sviluppatore non ha mai davvero bisogno di accedere a un ambiente di produzione, è più facile dal punto di vista degli sviluppatori se non è possibile riprodurre un bug difficile.

Tuttavia, uno sviluppatore può inserire mini-dump o file di registro e utilizzare i file dei simboli PDB per ricreare il bug.

Se i dati devono essere trasferiti in un ambiente di test, è tipico che un tipo di processo scrub i dati che possono creare lavoro extra.

A seconda del software del database utilizzato in quello che si chiama produzione, potrebbe essere necessaria una nuova licenza per consentire allo sviluppatore di accedere al database, il che è una grande spesa per avere semplicemente accesso in lettura.

Se la tua azienda non ti fornisce gli strumenti per eseguire il debug o la ricerca di problemi di produzione non è perché non hai accesso ai dati di produzione.

I dati sono la parte più preziosa della maggior parte delle applicazioni!

9

Le prestazioni potrebbero essere uno dei motivi.

Le query degli sviluppatori possono spesso essere inefficienti, causando un blocco eccessivo o un utilizzo delle risorse fino a quando non vengono regolate correttamente.

Un sistema di produzione non è un luogo adatto per sperimentare gli sviluppatori.

8
JSR

Dipende dal DBA e da come lui o lei è fiducioso con lo sviluppatore. Di solito agli sviluppatori vengono dati i privilegi di query (lettura) per i database di produzione. Come regola generale, gli sviluppatori dovrebbero funzionano solo con database test/dev.

8
MarlonRibunal

La sfida è che la maggior parte delle applicazioni software sono guidate dai dati. Quindi, quando stai cercando di risolvere un problema nell'applicazione, devi davvero vedere i dati che lo guidano. Quindi gli sviluppatori hanno davvero bisogno di una qualche forma di accesso.

L'uso degli accessi SQL per dare loro l'accesso in sola lettura alle tabelle è fantastico. MA, cosa impedisce loro di creare una query con 20 join o di fare SELECT * da una tabella con milioni di record? Queste query potrebbero uccidere accidentalmente le prestazioni del database e dello spazio di archiviazione.

La mia azienda Stackify ha escogitato un modo intelligente per risolvere questo problema. Gli sviluppatori possono eseguire la query tramite il nostro software e utilizziamo il piano di query per assicurarci che sia solo un'istruzione SELECT e che il costo stimato della query sia basso e restituirà solo pochi record. In questo modo non possono fare molto male. Controlliamo anche tutte le query che eseguono.

Questa è solo una delle cose che forniamo. Dai un'occhiata a http://www.Stackify.com per saperne di più sulle nostre soluzioni supporto DevOps .

8

Sì. In alcuni casi, ha senso consentire ad alcuni sottogruppi di utenti, inclusi gli sviluppatori un certo livello di accesso per interrogare i dati di produzione. Tuttavia, le limitazioni appropriate devono essere in atto per due motivi. Innanzitutto, come DBA, devi fare del tuo meglio per assicurare il livello di servizio necessario a tutti gli utenti. Inoltre, si desidera evitare query errate involontarie come eliminazioni di massa o violazioni delle regole aziendali. Va da sé che devono essere previsti adeguati controlli di sicurezza.

Qualunque siano i motivi che potresti avere per non consentire query ad hoc direttamente alle tabelle del database, può esserci un caso per consentire alle query di visualizzare e stored procedure. Usando le autorizzazioni per il database, è possibile impedire direttamente alle tabelle di selezione delle query SELECT e anche limitare a quali visualizzazioni e procedure memorizzate ha accesso un determinato utente. Questo metodo non solo offre flessibilità alla tua base di utenti, ma protegge anche l'integrità e la fattibilità dei tuoi dati se implementati correttamente.

7
Tom Resing

Nella nostra azienda manteniamo schiavi di sola lettura dei database di produzione a cui non fanno affidamento i servizi di produzione. Concediamo agli sviluppatori l'accesso a quelli per l'accesso ai dati di produzione. Se sono presenti dati riservati (Informazioni cliente, informazioni di pagamento, ecc.) Limitiamo la replica di tali tabelle e conserviamo una tabella di dati di esempio sul server slave.

5
Ryan Waldron

No..Never !!

Questo è il motivo per cui abbiamo server di sviluppo/test/UAT. I dati di Production possono essere copiati nell'ambiente di test e gli sviluppatori possono procedere con i loro test. Le query selezionate possono essere molto dannose anche nel caso di un ambiente di produzione. Aumenta il carico e nelle ore di punta può ridurre l'intera prestazione.

Tutte le informazioni di cui hanno bisogno dovrebbero passare attraverso il DBA che può eseguire ciò che vogliono (selezionare) e inviare loro i risultati. È così che facciamo nel nostro ambiente.

1