Conceder privilegios de SA para desarrolladores en el cuadro de desarrollo

8

A pesar de nuestras vehementes protestas, nuestra gerencia ha decidido que el equipo de desarrollo debe tener derechos 'sa' en el servidor de desarrollo. El problema es que nosotros, el grupo de soporte de DB todavía somos responsables de mantener este cuadro.

Ahora se nos ha encomendado la tarea de elaborar una lista de qué hacer y qué no hacer para los equipos de desarrollo con estos privilegios mejorados.

Por favor agregue a esta lista:

DO: limitar las actividades a la base de datos en desarrollo

NO HAGA --

  • cambiar cualquier configuración de instancia de SQL
  • sp_configure (incluido cmdshell)
  • agregar / cambiar / eliminar cualquier configuración de seguridad
  • agregar / cambiar / eliminar objetos de la base de datos
  • agregar / cambiar / eliminar objetos del servidor como dispositivos de respaldo y servidores vinculados
  • agregar / cambiar / eliminar replicación
  • agregar / cambiar / eliminar planes de mantenimiento
  • toca cualquier base de datos que no pertenezca a tu equipo

Se agradecerá mucho cualquier indicador de las herramientas disponibles para rastrear las actividades de estos usuarios.

sql-server sql-server-2005 permissions Raj
fuente
1
¿Qué tareas necesitan hacer que requieran privilegios de mayor nivel de SA?
Creo que db_owner sería todo lo que necesitan ...
55
OK, si se les aconseja NO "agregar / cambiar / eliminar objetos de la base de datos", ¿qué se supone que deben hacer? ¿No es el punto de tener una caja de desarrollo que puedan romperla?
Stuart Ainsworth
Estos son desarrolladores de aplicaciones. Necesitan privilegios 'sa' para poder depurar procedimientos almacenados en Dev Studio. La decisión ya está tomada por la gerencia y no están dispuestos a ceder. Estamos tratando de minimizar el posible dolor de cabeza
2
+1 para la pregunta, ya que he tocado ese tema un par de veces. Otra solución: dar a los desarrolladores una máquina virtual de espacio aislado con SQL en el que son 100% jefes. También son 100% responsables de mantenerlo vivo :) -> es sorprendente lo rápido que los DEV aprenden a no romper su propio sistema :)
Martin S. Stoller

Respuestas:

8

Si no es demasiado tarde, una opción de compromiso que he visto funcionar bien es en lugar de actualizar los permisos o reemplazar las cuentas existentes de los desarrolladores, crear una cuenta separada que solo se usa cuando necesitan los permisos elevados.

Por lo tanto, normalmente funcionan bajo cuentas "restringidas" individuales (que uso libremente porque estas cuentas restringidas todavía necesitan algunos permisos fuertes, es decir, crear, eliminar, modificar para tablas). Pero para esa rara ocasión en que creen que lo necesitan sa, pueden iniciar sesión con esta cuenta. Luego, puede marcar la cuenta en sus registros y realizar un monitoreo adicional. Le has dado a los desarrolladores el acceso que pidieron, pero de una manera que es un poco más controlable.

Finalmente, si hay abuso, los registros de esta cuenta se pueden usar como evidencia para eliminarlo.

Joel Coehoorn
fuente
6

Aquí dice (MSDN) que necesita sysadmin (sa) para depurar en SQL Server 2005.

Sin embargo, esta pregunta SO muestra otra forma sin sa, que es lo que pensé inicialmente. Simplemente permítales corrersp_sidedebug

También sugiero darles SQL Express local que también resuelve otros problemas ...

(editado con más información)

Editar, después de la respuesta de W. Craig Trader

Otros problemas con los derechos "sa", en el peor de los casos:

  • los desarrolladores crearán conjuntos CLR no confiables
  • usarán xp_cmdshell
  • todas las acciones están en el contexto de la cuenta de servicio del servidor sql
  • asumirán los derechos de la conexión del cliente
  • etcétera etcétera

p.ej xp_cmdshell 'scm -Action 6 -Server PRODSERVER'

gbn
fuente
1
La respuesta para los desarrolladores que codifican fuera de las líneas es hacer una integración continua con bloqueado 'como lo ejecutarán los permisos de los usuarios, y fallar la compilación en consecuencia. Haga que el servidor de compilación vuelva a crear la base de datos desde cero y la complete con datos de prueba (todo desde SCM, por supuesto). (En mi caso, utilicé exactamente el mismo código que usaría el instalador de la aplicación para crear una nueva base de datos, probando así el instalador y la aplicación).
1
@Craig trader: no funcionará. Para reformular mi antigua respuesta, no se puede confiar en los desarrolladores y las integraciones de integración no detectarán todos los casos. Soy desarrollador dba: un mono de código de cliente es mi enemigo. En mi empresa, gano ... es mi conjunto de trenes y trato con el mínimo común denominador ...
gbn
Aparentemente, su kilometraje puede variar. En mi experiencia, generalmente he tenido que hacer un poco de capacitación / orientación para explicar cómo y por qué se hacen las cosas, pero después de eso las cosas suelen funcionar bastante bien. Por supuesto, siempre insisto en que las únicas compilaciones que van más allá del desarrollo son las que provienen del servidor de compilación estrictamente controlado: si el código no se construye allí, es un problema con su código (o sus pruebas) no configuración. Lo he hecho con pequeños equipos y grandes proyectos, en muchas empresas, y siempre con éxito.
4

Una sugerencia que tengo es configurar la gestión basada en políticas y hacer cumplir todos sus 'hacer' y 'no hacer' como reglas de política. Esto ayudaría mucho a proteger la instancia.

También desplegaría la auditoría de cambios DDL, vea Auditoría en SQL Server 2008 , no tanto como un elemento disuasorio, sino principalmente como un sistema de seguimiento de cambios para que cuando algo se atornille, al menos sepa lo que cambió.

Remus Rusanu
fuente
3

Si es el servidor de DESARROLLO, ¿cuál es el problema con los DESARROLLADORES que pueden tener acceso completo? Decirle a los desarrolladores que no puede agregar / eliminar / cambiar objetos de la base de datos (por ejemplo: tablas, columnas, índices) es como decirles "Puede tener un compilador, pero no puede ejecutarlo". Me parece que los desarrolladores quieren / necesitan acceso a su propia instancia de base de datos específicamente para permitirles probar diferentes métodos de resolución de problemas SIN tener que interferir con las bases de datos PRODUCTION o TEST. Deberías alentar ese tipo de comportamiento, no desalentarlo.

Algunos pueden sugerir que los desarrolladores trabajen con instancias locales de SQL Express, pero si bien SQL Express para cada desarrollador puede resolver ciertos problemas, tiene diferentes limitaciones y características de rendimiento que SQL Server completo en un servidor separado.

Lo que DEBE hacer es instituir un programa regular de copias de seguridad (al menos todas las noches) y trabajar con los desarrolladores para asegurarse de que sepan cómo iniciar copias de seguridad no programadas y restaurar desde copias de seguridad, de modo que el tiempo de inactividad se minimice en caso de problemas.

Craig Trader
fuente
Tu analogía está completamente equivocada. Lo que sucede es que se mudan y luego se quejan cuando no pueden migrar su muck a servidores bloqueados. Soy desarrollador DBA, por supuesto :-)
gbn
Entonces un poco de educación está en orden. Soy un desarrollador que ha sido un DBA con demasiada frecuencia. Con un pie en ambos mundos, generalmente ha sido mi trabajo enseñar a ambas partes a coexistir. Después de todo, son los usuarios que son el enemigo, no el DBA o desarrolladores ...
También hay cosas como planes de mantenimiento a los que no deberían tener acceso.
Joel Coehoorn el
1
El problema es que tenemos múltiples grupos de desarrollo y este servidor aloja todas sus bases de datos. Este grupo que requiere derechos 'sa' posee solo el 33% de los Dbs. La preocupación es que pueden atornillar y derribar el servidor, afectando también a otros grupos. La compañía no quiere obtener hardware separado para ellos, a menos que podamos demostrar que se equivocaron.
2
Eso es ridículo. Cada grupo de desarrollo debe tener su propio servidor, para que nadie pise los pies de nadie. El hardware en estos días es prácticamente gratuito, y el software es casi tan barato como el hardware. Y si su organización es lo suficientemente grande como para tener múltiples grupos de desarrollo, debería usar la virtualización del servidor, lo que facilitaría todo esto.
3

Es el dev servidor, no el servidor de grupos de apoyo DB o el servidor de producción. Mantenga una buena copia de seguridad / imagen y deje que los desarrolladores corten. Dejar que DBA controle el devbox es como dejar que la cola mueva al perro. Está ahí para que los desarrolladores realicen el trabajo del desarrollador Esto implica romper cosas a veces y soltar tablas, y luego volver a colocarlas con diferentes configuraciones. Las cajas de desarrollo siempre estarán en mal estado después de un tiempo, eso es lo que hacemos. Si no sabemos dónde está ocurriendo un problema, intentamos cosas diferentes. Algunos de ellos son fáciles de deshacer, otros no tanto.


fuente
El problema aquí es que es fácil para los desarrolladores olvidar que las aplicaciones que crean no tendrán los mismos derechos todo el tiempo. Sí, dáselos sa, pero haz que no sean sa por defecto, para que estén conscientes cuando están haciendo algo que necesitará un poco de trabajo extra para desplegarse correctamente.
Joel Coehoorn
1

No creo que necesiten privilegios de SA en el cuadro Desarrollo. En casi todos los casos, pueden prescindir.

Creo que una buena opción es tener instalada la edición de desarrollo local.

pregunta:

¡¿No quieres que los desarrolladores agreguen / cambien / eliminen objetos de la base de datos? !! ¿Cómo se van a desarrollar?

Raj Más
fuente
Perdón por la confusión. Lo que quise decir con ese punto es que los desarrolladores no deben cambiar la configuración de la base de datos ni descartarlas.
1

Requerimos que todos los cambios en la estructura de la base de datos se realicen con scripts (incluso en dev) y se guarden en subversion. Luego, en un horario establecido, actualizamos el desarrollo desde prod y tienen que volver a ejecutar sus scripts para volver a donde estaban en el ciclo de desarrollo. Esto ayuda a garantizar que todo se haga a través de scripts y que tengan scripts listos cuando llegue el momento de la implementación.

Sé que en 2008 puede configurar DDL Triggers para rastrear los cambios estructurales de la base de datos, ¿puede hacer esto en 2005? De esta manera, al menos puede averiguar cuándo alguien cambia una configuración que lo hizo y descubrir por qué.

HLGEM
fuente