Estoy de acuerdo en que la carga de la justificación debería recaer en los que requieren acceso. Por lo general, en los entornos en los que he consultado, he tenido acceso a los sistemas de producción donde era un entorno pequeño y era la persona de soporte. He tenido acceso a copias de seguridad, etc. donde fui soporte para el soporte, y acceso indirecto (a través de un desarrollador de soporte dedicado) a los datos de producción.
Lo importante es: necesita este acceso cuando está enganchado para mantener todo funcionando sin problemas y debe responder la pregunta del tipo de finanzas sobre algo que no funciona. No siempre se puede trabajar desde datos de un día en ese caso. Por otro lado, cuanto más acceso, peor es. Por lo general, como consultor, tiendo a evitar este tipo de acceso a menos que sea necesario. Como estoy trabajando en bases de datos financieras, lo último que quiero es que me acusen de ingresar mis propias facturas :-D.
Por otro lado, si no necesita acceso, no debería tenerlo. Realmente no compro el argumento de los datos confidenciales, ya que el desarrollador probablemente está pendiente de asegurarse de que se maneja correctamente (y es muy difícil de verificar sin mirar lo que realmente se almacenó cuando entra un informe de error). Si no puede confiar en el desarrollador para ver los datos que la aplicación del desarrollador está almacenando, no debe contratar al desarrollador para que escriba la aplicación. Hay muchas maneras en que el desarrollador puede ofuscar los datos y enviarlos por correo electrónico y nunca puede estar seguro. Los controles MAC ayudan aquí, pero aún son bastante complejos de implementar.
El gran problema de mi lado tiene que ver con el acceso de escritura. Si un desarrollador no tiene acceso, a fortiori, el desarrollador no tiene acceso de escritura. Si desea verificar la integridad de los libros, desea mantener el acceso de escritura a la menor cantidad de personas posible. Las pistas de auditoría son mucho más fáciles de validar si los desarrolladores no tienen acceso. Si el desarrollador tiene acceso de lectura, entonces siempre tiene alguna pregunta sobre si ha habido algún adjunto de escalonamiento de privilegios que pueda proporcionar acceso de escritura (¿tal vez una inyección de SQL de procedimiento almacenado?). A menudo he tenido acceso completo a la información de facturación del cliente cuando he tenido acceso a entornos de preparación. Sin embargo, si hay un entorno de ensayo que funcione, generalmente pediré activamente que no tenga acceso a la producción a menos que sea necesario.
Entonces esto no es perfecto, por supuesto. Un desarrollador aún podría construir puertas traseras en la aplicación que pueden no ser fácilmente detectables, pero este enfoque es razonable, dado el hecho de que los datos de respaldo están disponibles desde un día antes, me parece que esta es la preocupación que tienen.
Espero que esto ayude.
Editar: solo agrego que en los entornos más grandes en los que he trabajado, he tenido acceso a datos de copia de seguridad completos que a menudo van desde unos pocos días hasta unos pocos meses para el sistema financiero. Esto siempre ha sido lo suficientemente bueno para mi trabajo y las únicas veces en que se ha descompuesto han sido cuando los encargados de las finanzas necesitaban la capacidad de probar con datos más nuevos para poder compararlos con la producción.