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. Esistono troppi modi in cui lo sviluppatore potrebbe offuscare i dati e inviarli via e-mail e non si può mai essere sicuri. 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 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 che si sono guastate sono state quando i ragazzi della finanza avevano bisogno di una capacità di testare con dati più recenti in modo da poterli confrontare con la produzione.