Quanto accesso al database dovrebbero avere gli sviluppatori? [chiuso]

Gli sviluppatori necessitano dell'accesso in lettura a tutti i database inclusi i prodotti A volte il problema è che i dati su Prod non sono quelli che si aspettavano di avere e hanno bisogno di vedere i dati che causano il problema perché non possono riprodurli su dev.

Gli sviluppatori non dovrebbero avere diritti o diritti di scrittura dei dati di produzione per creare oggetti. Niente dovrebbe andare a pungolare che non fa parte di una versione ufficiale. Troppe volte, le persone fanno una rapida soluzione sui prodotti che non funzionano, causando un aumento del pungolo o lavori, ma dimenticano di inserire il codice nei server dev / QA / Staging e ancora peggio nella fonte controlla il repository e il codice viene sovrascritto circa un mese dopo nella prossima versione ufficiale.

Preferisco che gli sviluppatori avessero i diritti completi per il QA del database perché la distribuzione su un altro server li aiuta a vedere se ci sono delle lacune nel loro processo di distribuzione (oops ha dimenticato che ho cambiato quella tabella per fare così e così e oops ho dimenticato di ha fatto cambiare usando la GUI e non in uno script nel controllo del codice sorgente, che è come devono avvenire le modifiche strutturali del database).

Quando hai un nuovo client di tipo Enterprise che avrà il proprio set di server, le autorizzazioni potrebbero essere alleviate prima di andare in diretta. Questo perché così tanto deve accadere e le poche persone che riescono a farlo accadere sui nostri prodotti vengono rallentate e talvolta hanno anche bisogno di prendersi del tempo libero. In particolare, le persone che stanno importando dati da un altro sistema potrebbero ottenere il compito di metterli in produzione prima del lancio, se il data-list richiederà molto tempo. Queste persone tendono a essere specialisti dei dati e c'è un livello di comfort più elevato che consente loro un accesso temporaneo ai pungoli rispetto allo sviluppo medio dell'applicazione. Questo non è un lusso che hai quando vai a un server di produzione già attivo.

Uno degli aspetti più critici della limitazione dei diritti di produzione al database è che gli sviluppatori devono quindi assicurarsi che il loro lavoro sia in una forma che possa essere distribuita da qualcun altro. Questo tende a migliorare la qualità del lavoro perché non stanno cercando di fare delle correzioni al volo perché hanno dimenticato qualcosa o qualcosa non ha funzionato perché lo hanno fatto in modo diverso da prod, quando si affidano solo alla memoria. Si perdono anche quei "oops ho cancellato per errore l'intera tabella utenti perché ho dimenticato di evidenziare una clausola where" tipo di incidenti quando le distribuzioni prod utilizzano esclusivamente script che vengono eseguiti nel loro complesso non un comando alla volta come è tipico quando gli sviluppatori gestisci le cose su prod. Un team con diritti limitati per i database di produzione è più probabile che memorizzi anche le modifiche al database nel controllo del codice sorgente.

È davvero una questione di "Vampiri (programmatori) contro licantropi (amministratori di sistema)" come Jeff Atwood ha messo qui .

Di solito (questo significa che c'è il lusso di configurare un ambiente completo), l'accesso dello sviluppatore a:

• Server di produzione
  • Nessuno (SA / PM si applicherà per l'impostazione dello schema, l'utente finale fornirà i dati di init)
• Server UAT
  • Nessuno (SA / PM si applicherà per l'impostazione dello schema e il seeding dei dati di esempio)
• Test / server QA
  • Generalmente lo sviluppatore invierà uno script di configurazione dello schema al team QA e il QA crea le tabelle
  • Gli sviluppatori hanno pieno accesso ai database ma raramente lo modificano
  • Gli sviluppatori possono aiutare i colleghi del QA a seminare / correggere / eliminare alcuni dati
• Server di sviluppo / localhost
  • Accesso completo

Il motivo principale per cui gli sviluppatori non devono toccare i server di produzione è: quando qualcosa va storto, il team operativo è responsabile, ma non gli sviluppatori.

Il minimo indispensabile per completare il lavoro.

Se a tutti gli sviluppatori viene fornito l'accesso completo al DB, la possibilità che qualcuno si arrabbi (o ubriaca, o estremamente stanco o ...) e che faccia danni gravi è molto più alta di quella che può leggere solo da un database.

Se il tuo lavoro può essere svolto principalmente senza accesso in scrittura ai DB (e per lo più intendo al massimo qualche richiesta di modifica alla settimana), allora non hai davvero bisogno di accesso in scrittura.

Ci sono 2 desideri in competizione in tutti gli ambienti di lavoro.

• Il desiderio di dare accesso alle persone in modo che possano risolvere i problemi da soli. Ciò consente loro di essere veloci e autonomi.
• Il desiderio di limitare e controllare l'accesso per prevenire danni, tempi di inattività o perdita di dati (intenzionali o meno).

Parte di ciò che plasma l'equilibrio che viene colpito (o dovrebbe comunque) è l'aspettativa impostata per gli sviluppatori. In ogni lavoro che ho avuto dove gli sviluppatori avevano accesso a tutto ciò che l'aspettativa era per loro di limitarsi. Accedi al sistema solo se sai cosa stai facendo. Ciò significava che sapevi cosa stavi facendo sia dal punto di vista dello sviluppatore che dello sysadmin. Se non eri sicuro in entrambe le aree, non avevi accesso ai sistemi senza qualcuno che ti facesse da chaperon.

Per riassumere, se non lo sai, non dovresti avere accesso a sistemi diversi dai sistemi di sviluppo facilmente ricostruibili . Se lo sai, saprai che non dovresti accedere a nessun sistema eccetto i tuoi sistemi di sviluppo facilmente ricostruibili .

Gli sviluppatori dovrebbero avere pieno accesso ai database di sviluppo (idealmente dovrebbero essere in esecuzione un server locale, ma questo non è sempre possibile). Dovrebbero avere accesso al database di build / QA, ma solo ai dati (dovrebbe avere il permesso / inviare un ticket per modificare la struttura). Gli sviluppatori non dovrebbero mai avere un accesso casuale al database di produzione (a meno che non si tratti di una piccola azienda / progetto e gli sviluppatori supportano anche la produzione).

Penso che la chiave qui sia quale livello di responsabilità hanno gli sviluppatori. In una grande organizzazione con molti sviluppatori, probabilmente avranno accesso allo sviluppo solo con accesso in sola lettura a QA / Test.

Tuttavia, ci dovrebbero essere persone nel team di sviluppo con pieno accesso a tutti gli ambienti. Di solito è la persona responsabile della risoluzione di correzioni, ecc. Anche se questo è un po 'rischioso, è un compromesso tra quanto ti fidi dello sviluppatore, quanto velocemente vuoi che le cose vengano riparate, e i rischi coinvolti nel messing del sistema o nella divulgazione di informazioni nel sistema .

Ho lavorato in un grande negozio di informatica e abbiamo letto l'accesso alla produzione per la maggior parte delle persone. I come sviluppatore principale aveva anche le autorizzazioni per il database di produzione. Dovevo ancora seguire le stesse linee guida degli amministratori di sistema e degli amministratori di database in termini di processo e pratiche burocratiche, ma potrei anche apportare una soluzione urgente, se necessario.

C'è un problema correlato che molti di noi dimenticano - potremmo non essere le uniche persone che usano il database! Tendiamo a dare per scontato, ma non dovrebbe. Anche i siti di piccole dimensioni potrebbero avere gli uomini d'affari che eseguono strumenti di terze parti contro il database per i loro report. I siti aziendali avranno quasi sempre più utenti delle tabelle del database e la tua modifica "piccola" potrebbe interrompere le loro applicazioni e viceversa.

Quindi questa deve essere la prima domanda. Il secondo deve essere lo staff disponibile - Ho lavorato in siti che avevano amministratori di sistema che erano protettivi del loro territorio, ma in realtà non erano così buoni. (Il che probabilmente è il motivo per cui erano così territoriali - sapevano che avrebbero preso molto calore se qualcuno si fosse guardato intorno.) A volte devi avere più accesso di quello che vorresti.

Ma in un mondo ideale sono d'accordo con i punti fatti da altre persone. Non voglio accedere ai dati live poiché, francamente, non voglio la responsabilità. Pensaci: se ho un accesso operativo e c'è una violazione, dovrò passare molto tempo a dimostrare che non avevo niente a che fare con questo. Potrei dover dimostrare che non ho snarfed i dati per motivi personali, ecc. Molti siti prendono molto sul serio la privacy, esp. siti governativi.

Non voglio nemmeno accedere in scrittura / amministratore al sistema del gruppo di test. Se non riesco a fare qualcosa sul sistema di produzione, non voglio essere in grado di farlo sui sistemi di test. L'accesso in lettura è l'eccezione poiché è necessario aiutare a capire cosa sta succedendo.

I sistemi di sviluppo, sia individuali che dipartimentali, sono una storia diversa. Ma anche qui, in pratica, di solito è meglio eseguire tutte le modifiche al database attraverso una persona puntuale invece di fare in modo che tutti facciano le proprie cose.

Sono totalmente d'accordo con tutte le risposte, dicendo "il minimo privilegio possibile per gli sviluppatori sui database di prod". Ma per essere onesti, chi può negare agli sviluppatori l'accesso al database se vogliono ottenerlo. Con sufficiente volontà (sia criminale che per sempre) otterranno l'accesso necessario.

Chi può impedirgli di inserire un semplice editor SQL nell'applicazione? In questo modo possono utilizzare il database con i privilegi dell'applicazione. Nella maggior parte dei casi questo è tutto ciò che è necessario. Quando il database è configurato in modo sicuro, potrebbero non avere il privilegio di creare o eliminare oggetti, ma hanno almeno accesso in lettura e scrittura ai dati.

Sono già qui le persone ops che piangono. Ma sii onesto con te stesso, non hai il controllo completo dell'applicazione distribuita in produzione, a meno che tu non la scriva tu stesso (e nemmeno allora, pensi alle librerie). E a tutti gli sviluppatori, come già detto Erin, sei anche responsabile dell'ambiente di produzione, non solo delle persone ops. Quindi usa i tuoi privilegi con saggezza.