¿Se debe dar permiso a los desarrolladores para consultar ( SELECT/ solo lectura) bases de datos de producción? El lugar anterior donde trabajé, el equipo de desarrollo tenía el db_datareaderpapel; donde trabajo ahora, el equipo de desarrollo ni siquiera puede conectarse a la instancia de producción.

Una de las instancias de prueba es una copia de producción restaurada desde una copia de seguridad de producción una vez por semana, por lo que no hay ningún problema con los desarrolladores que realmente ven los datos.

¿Qué buenas razones hay para no permitir que los desarrolladores consulten la producción (excepto simplemente por no querer que tengan acceso a leer datos confidenciales)?

Realmente depende de si el desarrollador tiene alguna responsabilidad de soporte. Si están enganchados para el soporte de la tercera línea, entonces probablemente tendrán que mirar la base de datos de producción para hacerlo.

En general, es una mala idea hacer algo en un servidor de producción a menos que sea realmente necesario hacerlo allí.

Para la mayoría de los propósitos de desarrollo, los espejos o las instantáneas de la base de datos de producción serán adecuados y probablemente mejores que la base de datos de producción en vivo. Si está haciendo algo relacionado con la integración, entonces querrá entornos de bases de datos estables donde pueda controlar lo que hay en ellos. Cualquier cosa que implique reconciliación también necesitará la capacidad de mirar un punto controlado en el tiempo.

Si el problema es que no tiene entornos espejo de producción o ningún medio para colocar una copia de los datos de producción en algún lugar para sus desarrolladores, entonces esta es una pregunta algo diferente. En ese caso, sus desarrolladores realmente necesitan al menos un entorno espejo. Si no puede ver cuál es el problema en los datos, es difícil solucionarlo.

No.

Los desarrolladores no deberían tener acceso a los sistemas de bases de datos de producción por los siguientes motivos:

1. Disponibilidad y rendimiento : tener derechos de solo lectura para una base de datos no es inofensivo. Una consulta mal escrita puede:

   1. Bloquear tablas, bloqueando otros procesos críticos.
   2. Deseche su caché de datos, obligando a otros procesos a volver a leer los datos del disco.
   3. Grave su capa de almacenamiento, impactando otros servicios que comparten ese almacenamiento.

2. Seguridad : su base de datos de producción puede contener información confidencial como:

   • hashes de contraseña
   • Datos de facturación
   • otra información de identificación personal

   Solo aquellos que necesitan acceso a esta información deben tenerla. En una empresa bien organizada, los desarrolladores no se encuentran entre esas personas. Además, su empresa fallará en el cumplimiento de PCI y SOX si sus desarrolladores pueden acceder a los sistemas de producción con estos datos.

   Las razones para esto son obvias. El trabajo de desarrollo de un desarrollador pasa por muchas manos antes de su lanzamiento. ¿Qué impide que un desarrollador malintencionado con acceso directo a la producción robe sus datos de producción o ponga de rodillas su base de datos en vivo?

   "¡Pero eso también se aplica a los DBA! ¡Podrían hacer eso!" Exactamente. Desea tan pocos superusuarios como sea responsablemente posible.

Si.

Los desarrolladores deberían tener acceso a los sistemas de producción.

En mi empresa tenemos cuatro equipos que se ocupan de las bases de datos de producción. Son:

1. Desarrolladores , que diseñan y escriben el esquema y el código de las bases de datos. No tienen acceso a las bases de datos en producción. Sin embargo, a veces se sientan con los administradores o personas de apoyo y los ayudan a mirar algo en vivo.
2. Administradores , que implementan, supervisan y administran las bases de datos en producción.
3. Apoye a las personas que investigan problemas de producción urgentes y brindan retroalimentación a los desarrolladores para que puedan desarrollar soluciones.
4. Gente de Business Intelligence , que extrae datos de bases de datos de producción utilizando copias actualizadas regularmente de esas bases de datos o extractos cuidadosamente escritos y de control de calidad (generalmente diseñados por los Administradores).

Es apropiado otorgar a sus desarrolladores acceso de producción cuando tiene ciertas deficiencias en estos otros grupos.

Por ejemplo:

• No tienes equipo de soporte. ¿Quién va a saber dónde buscar para depurar ese problema de producción urgente? Tus desarrolladores Concédeles acceso para " romper el vidrio ".
• No tienes equipo de BI. Sus administradores no tienen ni quieren tener nada que ver con informes o extractos. ¿Quién solucionará el informe que ven tus ejecutivos todas las mañanas? Tus desarrolladores Concédeles acceso limitado para depurar estos informes y extractos.
• No tienes equipo de administración. Estás en una empresa muy pequeña o de nueva creación, así que saluda al "DBA accidental". Sus desarrolladores funcionan como sus administradores y, por lo tanto, necesitan acceso total a la producción.

El rendimiento sería una GRAN razón.

El hecho de que no puedan cambiar los datos no significa que no puedan afectar al servidor. Una consulta mal escrita podría poner de rodillas al entorno de producción y potencialmente causar otros problemas (como desbordamientos tempdb):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

Esa es una receta para el desastre. Tenga en cuenta que este es un producto cartesiano con un pedido por, lo que significa que se ordenará en tempDB.

El principio es "privilegio mínimo" y "necesidad de saber": ¿los desarrolladores pasan esta prueba?
Especialmente cuando los Auditores o Sarbannes-Oxley llaman a la puerta.

Entonces, mi siguiente suposición: los desarrolladores son estúpidos. Así que si no hay necesidad de hablar de apoyo tercera línea, que luego lo necesita? Los monos web generalmente no lo hacen, pero los tipos de bases de datos sí si se espera que lo admitan.

Entonces, ¿se necesita acceso de forma permanente? Pueden tener acceso para "romper cristales" utilizando un inicio de sesión SQL o una cuenta alternativa de Windows que requiera un cierre de sesión. En nuestro caso, fue el propietario de los datos (con suerte, un experto en tecnología) y el gerente de TI para aprobarlo.

Yo he visto desarrolladores de pruebas en contra o se ejecutan consultas sobre la producción y hacerla caer debido a la ignorancia. Dicho esto, los desarrolladores deberían asumir la responsabilidad de sus acciones: si eliminan un servidor, deberían sufrir en consecuencia. Tengo a alguien degradado después de un incidente ...

Estos suponen una tienda de tamaño razonable, por supuesto. Mientras más sombreros use la gente, menos separación de deberes puede tener

Además, ¿existe un entorno en el que los desarrolladores puedan ejecutar consultas contra datos recientes? En mi última tienda, prod fue restaurado cada noche a un servidor de prueba para proporcionar esto.

Creo que la respuesta es, como con muchas cosas de TI, "depende".

¿Una base de datos ERP masiva con mucha información confidencial de la empresa y el cliente? Probablemente no (tanto por razones de seguridad como de rendimiento).

¿Una base de datos departamental de 5 MB con un front-end de Access que rastrea las contribuciones a los fondos de donas y pizzas? No va a hacer una gran diferencia, al menos para el acceso de solo lectura.

De acuerdo, el primer ejemplo es mucho más común que el segundo, pero estas son las diferencias que debe tener en cuenta si está a cargo de tomar este tipo de decisiones de política. Pero, por otro lado, es sorprendente la rapidez con que una base de datos de 5 MB de donuts y fondos para pizzas puede avanzar lentamente a números de parte de 50 GB / números de tarjetas de crédito de clientes / quién sabe qué. otra base de datos si lo dejas.

En un entorno OLTP habitual las 24 horas, los 7 días de la semana, no se debe permitir que un desarrollador normal entre en producción. ¡Período! Si, de vez en cuando, aparece una razón particular, entonces se podrían otorgar permisos a pedido. Pero sobre una base habitual no.

He visto muchas razones para esto:

• SELECCIONE * de una tabla grande que conduce a:

  • problemas de rendimiento (productos cartesianos);
  • bloqueando problemas que eventualmente pusieron el sitio de rodillas;
  • cadena de bloqueo que colgó la replicación;
  • ordenando un gran conjunto de datos que llenó la unidad TempDB que ... ¿adivina qué? Causó una locura completa :-)!
  • presión arterial alta para el DBA a cargo de la producción de esa noche;

• lectura de datos confidenciales (un desarrollador no debería tener acceso a la información de la tarjeta de crédito ... ni a los datos personales del usuario);

Estoy seguro de que hay aún más razones.

• Seguridad: puede haber información confidencial que se desinfecta cuando la ponen a disposición de los desarrolladores.
• Paranoia: Algunos podrían pensar que aún podría arruinar los datos con solo seleccionar el acceso.
• Rendimiento: una consulta requiere algunos recursos para realizarse, y no puede decirme que sus desarrolladores son perfectos cuando escriben código.

Un par de elementos a considerar

• ¿Son sensibles los datos?
• ¿Son los programadores parte de un equipo de confianza central o de algún equipo offshore?
• ¿Cuál es la escala de los datos que se consultan en términos de impacto en el rendimiento?
• ¿Cuál es la escala del proyecto o los dólares involucrados?
• ¿Qué tan crítico es el tiempo de actividad?

Los dólares más pequeños necesitan menos procesos y necesitan un flujo de desarrollo más rápido.

Los dólares más grandes necesitan más procesos necesitan estándares más estrictos de prácticas de desarrollo.

Adapta tus prácticas a lo que estás haciendo.

Trabajo como desarrollador para una empresa muy grande. Todos nuestros desarrolladores que harán cualquier tipo de soporte (básicamente todos) tienen acceso a las bases de datos de producción relevantes. Solo puedo hablar por mi equipo específico, pero te diré por qué tenemos acceso.

1. Necesitamos acceso en tiempo real para vigilar nuestro procesamiento diario. (Si bien tenemos un panel de control, debemos ser capaces de vigilar las cosas en profundidad. Si bien sería bueno tener esta función en nuestro panel de control, hemos descubierto que no es práctico).
2. Necesitamos acceso en tiempo real para investigar cualquier falla de producción porque las demoras pueden tener un gran impacto. (No voy a discutir nuestros fracasos aquí. Vienen en todo tipo)
3. A menudo necesitamos hacer informes personalizados para usuarios comerciales y esta información debe estar actualizada. (Los dba no tienen tiempo para hacer esto y no tenemos tiempo para esperarlos. Sin embargo, no es ideal, sin duda).
4. Necesitamos verificar las implementaciones / parches de producción DDL / DML. (Los DBA los implementan, pero solo nosotros sabemos cómo debería estructurarse. Sabemos más acerca de nuestra estructura de base de datos que los DBA. Puede ser extraño aquí, pero nuestra base de datos es muy complicada porque nuestro negocio es muy complicado).

El rendimiento es una preocupación. Tenemos casos de desarrolladores que causan ralentizaciones. Sin embargo, estas son instancias aisladas y nuestro SQL está tan orientado al rendimiento que es raro que nuestros desarrolladores no entiendan el impacto de sus consultas.

Para que se haga esta pregunta, se debe suponer que actualmente no tienen acceso. Si la organización está desarrollando software y esto es para solucionar un problema del cliente y el cliente proporciona una copia de su base de datos, entonces 'sí'. De lo contrario, recomendaría mantener a los desarrolladores fuera de producción y crear entornos alternativos para sus necesidades de investigación. Una vez que la pasta de dientes está fuera del tubo, es difícil volver a colocarla.

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.

No tener acceso es algo bueno y una forma de proteger a los desarrolladores y a otros para que no corrompan accidentalmente los datos o los vean. Esto también protege a las empresas de infringir la ley (es decir, violaciones de Hipaa y preocupaciones de privacidad)

Un desarrollador nunca necesita realmente acceder a un entorno de producción, es más fácil desde el punto de vista de los desarrolladores si no se puede reproducir un error difícil.

Sin embargo, un desarrollador puede colocar mini volcados o archivos de registro y usar los archivos de símbolos PDB para volver a crear el error.

Si los datos deben reducirse a un entorno de prueba, es típico que algún tipo de proceso elimine los datos, lo que puede generar trabajo adicional.

Dependiendo del software de la base de datos que se utiliza en lo que llama producción, se podría requerir una nueva licencia para que el desarrollador acceda a la base de datos, lo cual es un gasto grande para simplemente tener acceso de lectura.

Si su empresa no le proporciona las herramientas para depurar o investigar problemas de producción, no es porque no tenga acceso a los datos de producción.

¡Los datos son la parte más valiosa de la mayoría de las aplicaciones!

El rendimiento podría ser una de las razones.

Las consultas de los desarrolladores a menudo pueden ser ineficientes, lo que provoca un bloqueo excesivo o el uso de recursos hasta que se ajustan correctamente.

Un sistema de producción no es un lugar adecuado para que los desarrolladores experimenten.

Depende del DBA y de cómo él o ella confía con el desarrollador. Por lo general, los desarrolladores tienen privilegios de consulta (lectura) para las bases de datos de producción. Como regla general, los desarrolladores solo deberían trabajar con bases de datos de prueba / desarrollo.

El desafío es que la mayoría de las aplicaciones de software están basadas en datos. Entonces, cuando está tratando de solucionar un problema en la aplicación, realmente necesita ver los datos que lo están impulsando. Entonces los desarrolladores realmente necesitan alguna forma de acceso.

Usar los inicios de sesión de SQL solo para darles acceso de solo lectura a las tablas es excelente. PERO, ¿qué les impide crear una consulta con 20 combinaciones o hacer SELECT * desde una tabla con millones de registros? Estas consultas podrían matar accidentalmente el rendimiento de su base de datos y almacenamiento.

A mi empresa Stackify se le ocurrió una forma inteligente de resolver esto. Los desarrolladores pueden ejecutar la consulta a través de nuestro software y usamos el plan de consulta para asegurarnos de que sea solo una declaración SELECT y que el costo estimado de la consulta sea bajo y que solo devuelva unos pocos registros. De esta manera no pueden hacer mucho daño. También auditamos todas las consultas que ejecutan.

Esta es solo una de las cosas que ofrecemos. Visítenos en http://www.Stackify.com para obtener más información sobre nuestras soluciones de soporte de DevOps .

Si. En algunos casos, tiene sentido permitir que algunos subconjuntos de usuarios, incluidos los desarrolladores, tengan cierto nivel de acceso a los datos de producción de consultas. Sin embargo, las limitaciones apropiadas deben estar en su lugar por dos razones. Primero, como DBA, debe hacer todo lo posible para asegurar el nivel de servicio que necesitan todos los usuarios. Además, desea evitar consultas erróneas no intencionales, como eliminaciones masivas o volatilizaciones de reglas comerciales. Debe ser evidente que deben existir controles de seguridad adecuados.

Cualesquiera que sean las razones que pueda tener para no permitir consultas ad hoc directamente a las tablas de la base de datos, puede haber un caso para permitir consultas a vistas y procedimientos almacenados. Con los permisos de la base de datos, puede evitar consultas SELECT contra tablas directamente e incluso limitar a qué vistas y procedimientos almacenados tiene acceso un usuario determinado. Este método no solo brinda flexibilidad a su base de usuarios, sino que también protege la integridad y la confiabilidad de sus datos cuando se implementa correctamente.

En nuestra empresa mantenemos bases de datos de esclavos de producción de solo lectura en los que los servicios de producción no confían. Otorgamos a los desarrolladores acceso a aquellos para acceder a los datos de producción. Si hay datos confidenciales (información del cliente, información de pago, etc.) restringimos la replicación de esas tablas y mantenemos una tabla de datos de muestra en el servidor esclavo.

¡¡No nunca!!

Es por eso que tenemos servidores de desarrollo / prueba / UAT. Los datos de Producción se pueden copiar en el entorno de prueba y los desarrolladores pueden continuar con sus pruebas. Las consultas seleccionadas también pueden ser muy perjudiciales en el caso de un entorno de producción. Aumenta la carga y en la hora pico puede reducir todo el rendimiento.

Cualquier información que necesiten debe ir a través del DBA, que puede ejecutar lo que quiera (Seleccionar) y enviarles los resultados. Así es como lo hacemos en nuestro entorno.

No estoy seguro de por qué todos asumen que los desarrolladores son estúpidos y no saben nada. Recibo una muestra de un montón de roles diferentes donde se equivocaron y no deberían estar "en producción". Tengo administradores de bases de datos, administradores de sistemas, administradores de red, desarrolladores, etc., todo está en mal estado.

Nadie (dev, dba, sa) tiene acceso a ningún servidor o base de datos en ningún entorno con un inicio de sesión de red normal. Todos tienen cuentas específicas de "administrador" que deben usarse. Sí, por lo general, los dba y sa usan los suyos con más frecuencia, pero incluso deberían caminar ligeramente. Me he quemado por todos.

Entonces, en un buen día, ningún rol de TI necesita acceso. Sin embargo, la mierda golpea al ventilador, todas las manos en cubierta y necesitamos a las personas adecuadas para resolver el problema. Esto generalmente lo lleva el desarrollador que conoce la aplicación y guía el dba y sa a ciertos puntos. Es solo el retraso innecesario o la solicitud y aprobación.

Además, la aprobación nunca es seguida por ningún tipo de auditoría, de modo que la aprobación no significa nada.