¿Cuánto acceso a la base de datos deben tener los desarrolladores? [cerrado]

Así que he trabajado en muchos lugares de trabajo diferentes como desarrollador y mi nivel de acceso a la base de datos ha sido variado. Por lo general, no tengo acceso db de producción.

La mayoría de las veces tengo acceso a la base de datos de prueba, pero varía. A veces puedo hacer y cambiar la base de datos y los datos a mi gusto, pero generalmente hay otros arreglos. Como si solo pudiera tener acceso de lectura a los datos.

Trabajé en un lugar donde un equipo de DBA administraría las bases de datos, no podríamos hacer ningún cambio a menos que enviáramos un formulario con el script sql para que lo "inspeccionen". Por lo general, no tenían mucho que ver con el proyecto en sí, por lo que la mayoría de las veces era solo presionar F5.

Honestamente, puedo entender por qué los productos deben bloquearse, pero prefiero tener tanto acceso a la base de datos en los entornos de desarrollo y prueba. Creo que la mayoría de los desarrolladores son razonablemente capaces de conocer una base de datos. ¿Pero me gustaría escuchar opiniones? ¿Cuánto acceso a la base de datos deben tener los desarrolladores? ¿Se puede confiar en nosotros para no romper nada allá arriba?

Los desarrolladores necesitan acceso de lectura a todas las bases de datos, incluida la producción. A veces, el problema es que los datos en Prod no son lo que esperaban tener y necesitan ver los datos que están causando el problema porque no pueden reproducirlos en dev.

Los desarrolladores no deben tener derechos de escritura de datos de producción o derechos para crear objetos. No debería haber nada que no sea parte de un lanzamiento oficial. Demasiadas veces, las personas hacen una solución rápida en el producto que no funciona, lo que hace que el producto esté aún más sucio o funcione, pero se olvidan de poner el código en los servidores de desarrollo / control de calidad / almacenamiento provisional y aún peor en la fuente controle el repositorio y el código se sobrescribe aproximadamente un mes después en la próxima versión oficial.

Prefiero que los desarrolladores tengan derechos completos de control de calidad de la base de datos porque la implementación en otro servidor les ayuda a ver si hay vacíos en su proceso de implementación (¡Vaya! Se olvidó de que cambié esa tabla para hacerlo) y se me olvidó que hice ese cambio. usando la GUI y no en un script en el control de origen, que es cómo deben ocurrir los cambios estructurales de la base de datos).

Cuando tiene un nuevo cliente de tipo Enterprise que tendrá su propio conjunto de servidores, los permisos se pueden facilitar antes de lanzarse. Esto se debe a que es necesario que sucedan muchas cosas y las pocas personas que pueden hacerlo en productos se retrasan y, a veces, incluso necesitan tomarse un tiempo libre. En particular, las personas que están importando datos de otro sistema pueden recibir la tarea de ponerlas en producción antes del lanzamiento si la carga de datos demorará mucho tiempo. Estas personas tienden a ser especialistas en datos y hay un mayor nivel de comodidad al permitirles acceso temporal a productos que el desarrollador promedio de aplicaciones. Este no es un lujo que tiene cuando va a un servidor de producción ya en vivo.

Una de las cosas más críticas acerca de limitar los derechos de producción a la base de datos es que los desarrolladores deben asegurarse de que su trabajo esté en una forma que otra persona pueda implementar. Esto tiende a mejorar la calidad del trabajo porque no están tratando de hacer arreglos sobre la marcha porque olvidaron algo o algo no funcionó porque lo hicieron de manera diferente en el producto que en el desarrollo cuando confiaban solo en la memoria. También pierde esos "¡Uy! Eliminé toda la tabla de usuarios por accidente porque olvidé resaltar un tipo de cláusula where" cuando los despliegues de productos utilizan puramente scripts que se ejecutan en conjunto, no un comando a la vez, como es típico cuando los desarrolladores ejecutar cosas en prod. Es más probable que un equipo con derechos limitados para bases de datos de producción almacene cambios en la base de datos en el control de origen.

Bueno, es realmente una cuestión de "Vampiros (Programadores) versus Hombres Lobo (Sysadmins)" como Jeff Atwood lo ha puesto aquí .

Por lo general (eso significa que existe el lujo de configurar un entorno completo), el acceso del desarrollador a:

• Servidor de producción
  • Ninguno (SA / PM se aplicará para la configuración del esquema, el usuario final proporcionará datos de inicio)
• Servidor UAT
  • Ninguno (SA / PM se aplicará para la configuración del esquema y la siembra de datos de muestra)
• Servidor de pruebas / control de calidad
  • Por lo general, el desarrollador enviará un script de configuración de esquema al equipo de QA y QA crea las tablas
  • Los desarrolladores tienen acceso completo a las bases de datos, pero rara vez lo modifican
  • Los desarrolladores pueden ayudar a los colegas de QA a sembrar / parchar / eliminar algunos datos
• Servidor de desarrollo / localhost
  • Acceso completo

La razón principal por la que los desarrolladores no deben tocar los servidores de producción es: cuando algo sale mal, el equipo de operación es responsable, pero no los desarrolladores.

El mínimo absoluto que necesita para hacer el trabajo.

Si todos los desarrolladores tienen acceso completo a la base de datos, la posibilidad de que uno se enoje (o esté borracho, extremadamente cansado o ...) y haga un daño grave es mucho mayor que si solo pueden leer desde una base de datos.

Si su trabajo se puede hacer principalmente sin acceso de escritura DB (y en su mayoría me refiero a un máximo de algunas solicitudes de cambio por semana), entonces realmente no necesita acceso de escritura.

Hay 2 deseos competitivos en todo el entorno laboral.

• El deseo de dar acceso a las personas para que puedan resolver los problemas por su cuenta. Esto les permite ser rápidos y de autoservicio.
• El deseo de limitar y controlar el acceso para evitar daños, tiempo de inactividad o pérdida de datos (intencional o no).

Parte de lo que da forma al equilibrio que se alcanza (o debería de todos modos) es la expectativa establecida para los desarrolladores. En cada trabajo que tuve donde los desarrolladores tenían acceso a todo lo que se esperaba era que se limitaran. Solo acceda al sistema si sabe lo que está haciendo. Eso significaba que sabías lo que estabas haciendo tanto desde el punto de vista del desarrollador como del administrador del sistema. Si no estaba seguro en ninguna de las áreas, no tenía negocios para acceder a los sistemas sin alguien que lo acompañara.

En resumen, si no lo sabe, no debería tener acceso a ningún sistema que no sea un sistema de desarrollo fácilmente reconstruible . Si lo sabe, entonces sabe que no debería acceder a ningún sistema, excepto a sus sistemas de desarrollo fácilmente reconstruibles .

Los desarrolladores deberían tener acceso completo a las bases de datos de desarrollo (idealmente deberían estar ejecutando un servidor local, pero eso no siempre es posible). Deben tener acceso a la base de datos de compilación / QA, pero solo a los datos (deben tener permiso / enviar un ticket para cambiar la estructura). Los desarrolladores nunca deberían tener acceso casual a la base de datos de producción (a menos que sea una pequeña empresa / proyecto y los desarrolladores también hagan soporte de producción).

Creo que la clave aquí es qué nivel de responsabilidad tienen los desarrolladores. En una organización grande con muchos desarrolladores, es probable que solo tengan acceso al desarrollo con acceso de solo lectura a QA / Test.

Sin embargo, debería haber personas en el equipo de desarrollo con acceso total a todos los entornos. Esta suele ser la persona responsable de hacer arreglos, etc. Si bien esto es algo arriesgado, es una compensación entre cuánto confía en el desarrollador, qué tan rápido quiere que se arreglen las cosas y los riesgos involucrados en desordenar el sistema o revelar información en el sistema. .

Trabajé en una gran tienda de TI y teníamos acceso de lectura a la producción para la mayoría de las personas. Yo como desarrollador principal también tenía permisos para la base de datos de producción. Todavía tenía que seguir las mismas pautas que los administradores de sistemas y los administradores de bases de datos en términos de procesos y documentación, pero también podía hacer una solución urgente si fuera necesario.

Hay un problema relacionado que la mayoría de nosotros olvidamos: ¡no podemos ser las únicas personas que usan la base de datos! Tendemos a dar esto por sentado, pero no debería. Incluso los sitios pequeños pueden hacer que los empresarios ejecuten herramientas de terceros contra la base de datos para sus informes. Los sitios empresariales casi siempre tendrán múltiples usuarios de las tablas de la base de datos y su 'pequeño' cambio podría romper sus aplicaciones y viceversa.

Entonces esta tiene que ser la primera pregunta. El segundo tiene que ser el personal disponible: he trabajado en sitios que tenían administradores de sistemas que protegían su territorio pero que en realidad no eran tan buenos. (Probablemente por eso eran tan territoriales: sabían que se calentarían mucho si alguien miraba a su alrededor). A veces tienes que tener más acceso del que deseas.

Pero en un mundo ideal, estoy de acuerdo con los puntos hechos por otras personas. No quiero acceder a datos en vivo ya que, francamente, no quiero la responsabilidad. Piénselo: si tengo acceso operativo y hay una brecha, tendré que pasar mucho tiempo demostrando que no tuve nada que ver con eso. Puede que tenga que demostrar que no he procesado los datos por razones personales, etc. Muchos sitios se toman muy en serio la privacidad, especialmente. sitios gubernamentales.

Ni siquiera quiero acceso de escritura / administrador al sistema del grupo de prueba. Si no puedo hacer algo en el sistema de producción, entonces no quiero poder hacerlo en los sistemas de prueba. El acceso de lectura es la excepción, ya que es necesario para ayudar a descubrir qué está pasando.

Los sistemas de desarrollo, tanto individuales como departamentales, son una historia diferente. Pero incluso aquí, en la práctica, generalmente es mejor ejecutar todos los cambios en la base de datos a través de una persona de contacto en lugar de hacer que todos hagan lo suyo.

Estoy totalmente de acuerdo con toda la respuesta, diciendo "la menor cantidad de privilegios posibles para los desarrolladores en bases de datos de productos". Pero para ser honesto, ¿quién puede negar a los desarrolladores el acceso a la base de datos si quieren obtenerla? Con suficiente voluntad (ya sea criminal o para bien) obtendrán el acceso necesario.

¿Quién puede evitar que pongan un simple editor SQL en la aplicación? De esta manera pueden usar la base de datos con los privilegios de la aplicación. En la mayoría de los casos, esto es todo lo que se necesita. Cuando la base de datos se configura de forma segura, es posible que no tengan el privilegio de crear o eliminar objetos, pero al menos tienen acceso de lectura y escritura a los datos.

Ya estoy aquí, la gente de operaciones llora. Pero sea honesto con usted mismo, no tiene el control total de la aplicación implementada en producción, a menos que la escriba usted mismo (y ni siquiera entonces, piense en las bibliotecas). Y para todos los desarrolladores, como ya dijo Erin, usted también es responsable del entorno de producción, no solo del personal de operaciones. Así que usa tus privilegios sabiamente.