¿Cómo puedo evitar la conexión accidental con una base de datos de producción?

31

Hace poco, un desarrollador intentó accidentalmente restaurar una base de datos a producción, cuando debería haber estado restaurando una copia provisional. Es fácil de hacer, dado que los nombres de db son similares, es decir, CustomerName_Staging versus CustomerName_Production.

Idealmente, los tendría en cajas completamente separadas, pero eso es un costo prohibitivo y, estrictamente hablando, no evita que ocurra lo mismo si el usuario se conecta a la caja incorrecta.

Este no es un problema de seguridad, per se: era el usuario correcto que trabajaba con la base de datos provisional, y si hay trabajo por hacer en la base de datos de producción, también sería él. Me encantaría tener un oficial de despliegue para separar esas preocupaciones, pero el equipo no es lo suficientemente grande para eso.

Me encantaría escuchar algunos consejos en términos de práctica, configuración y controles sobre cómo prevenir esto.

sql-server best-practices Chris B. Behrens
fuente
25
Los desarrolladores no deberían tener acceso de escritura a las bases de datos de producción, o preferiblemente, ningún acceso.
Michael Hampton
12
@MichaelHampton - Somos él y yo. También soy desarrollador. ¿Que sugieres?
Chris B. Behrens
10
Cuentas de usuario separadas para cada rol (dev vs ops / DBA). Y una abundancia de precaución.
Michael Hampton
2
Le recomiendo encarecidamente que tenga su entorno de producción en una caja separada. De lo contrario, la puesta en escena y la producción tienen que compartir recursos (disco, CPU, etc.) y si la puesta en escena monopoliza un recurso, su entorno de producción puede verse afectado.
Thorbjørn Ravn Andersen
1
Solo tiene usuarios / contraseñas separadas para esas bases de datos.
neutrinus

Respuestas:

32

Si esto es algo que te ves haciendo a menudo, automatízalo. Y dado que ambos son desarrolladores, escribir algo de código debería estar en su timonera. :) En serio ... al automatizarlo, puedes hacer cosas como:

  • Verifique que está restaurando en el servidor correcto (es decir, sin dev -> restauraciones de productos)
  • Verifique que sea el "tipo" correcto de base de datos (en su caso, "puesta en escena" y "producción")
  • Averigua qué copias de seguridad restaurar automáticamente mirando las tablas de copias de seguridad en msdb

Etcétera. Solo estás limitado por tu imaginación.

Ben Thul
fuente
1
Esa es una idea interesante ... ya tenemos un código que administra las restauraciones de db (para pruebas automatizadas). Podríamos poner una capa de abstracción en el medio que solo apuntara a la puesta en escena para que la restauración a la producción fuera un proceso completamente diferente ...
Chris B. Behrens
11
Ahora estás pensando con portales. :)
Ben Thul
44
Para los trabajos automatizados que afectan la producción, me gusta agregar un paso manual que requiere que el usuario escriba la palabra "producción" para reducir la posibilidad de que piensen que están viendo, por ejemplo, el equivalente de la puesta en escena.
Joe Lee-Moyet
2
Voté como nadie debería tener acceso a la producción por defecto. Debe tener un proceso especial para recuperar una contraseña prod. Es inconveniente pero realmente el mínimo.
OliverS
1
@BenThul Agregar una cuenta diferente para el acceso a productos y hacer que sea un paso más inconveniente sigue siendo la solución correcta para mí. La necesidad comercial no es que el DEV ahorre 2 minutos, sino restaurar la base de datos que se puede mover perfectamente a una cuenta prod.
OliverS
32

No estoy de acuerdo con el supuesto de la pregunta —esto es seguridad— pero tampoco estoy de acuerdo con que la automatización va a salvar el día por sí sola. Comenzaré con el problema:

¡No deberías poder hacer nada accidentalmente en producción!

Eso incluye hacer cosas automatizadas accidentalmente.

Estás confundiendo la seguridad del sistema con conceptos como "quién tiene permitido hacer qué". Sus cuentas de desarrollo solo deberían poder escribir en sus copias, el servidor de control de versiones y la base de datos de desarrollo. Si pueden leer / escribir la producción, pueden ser pirateados y explotados para robar datos de clientes o (como ha demostrado) pueden ser mal manejados para perder datos de clientes.

Debe comenzar ordenando su flujo de trabajo.

  • Sus cuentas de desarrollador deberían poder escribir en sus propias copias, control de versiones y quizás pasar del control de versiones a un entorno de prueba.

  • Los usuarios de respaldo solo deben poder leer de producción y escribir en su almacén de respaldo (que debe estar adecuadamente protegido).

  • Hacer cualquier otra lectura / escritura en producción debe requerir una autenticación especial e inconveniente . No debería poder entrar u olvidar que ha iniciado sesión. El control de acceso físico es útil aquí. Tarjetas inteligentes, interruptores para "armar" la cuenta, acceso simultáneo con doble llave.

    Acceder a la producción no debería ser algo que deba hacer todos los días. La mayor parte del trabajo debe realizarse en su plataforma de prueba y en implementaciones fuera de horario realizadas en producción después de un cuidadoso escrutinio. Un pequeño inconveniente no te matará.

La automatización es parte de la solución.

No estoy ciego al hecho de que el cambio completo (carga en VCS, verificación de cobertura, extracción para probar el servidor, ejecución de pruebas automatizadas, autenticación, creación de una copia de seguridad, extracción desde VCS) es un proceso largo.

Ahí es donde la automatización puede ayudar, según la respuesta de Ben. Hay muchos lenguajes de script diferentes que hacen que ejecutar ciertas tareas sea mucho, mucho más fácil. Solo asegúrate de no hacer que sea demasiado fácil hacer cosas estúpidas. Sus pasos de reautenticación aún deben ser pronunciados (y si son peligrosos) deben ser inconvenientes y difíciles de hacer sin pensar.

Pero solo , la automatización es peor que inútil. Simplemente te ayudará a cometer errores más grandes con menos pensamiento.

Apto para equipos de todos los tamaños.

Me di cuenta de que señalabas el tamaño de tu equipo. Soy un chico y me puse a prueba porque solo se necesita una persona para tener un accidente. Hay una sobrecarga pero vale la pena. Usted termina con un entorno de desarrollo y producción mucho más seguro y mucho más seguro.

Oli
fuente
2
Además, una cosa que me gusta hacer es usar dos cuentas con nombre por usuario. Uno es para el inicio de sesión normal del usuario, operación, trabajo diario, etc., mientras que la segunda cuenta (generalmente con algún tipo de sufijo como un + o un guión bajo) tiene todos los derechos de producción y desarrollo que el usuario requiere. De esa manera, el usuario debe tomar una decisión activa de presionar para presionar en lugar de dev. Esto es similar al punto 3 descrito anteriormente, pero no requiere una infraestructura o gasto adicional significativo para demostrar el valor.
user24313
3
También es importante evitar tener el hábito de hacer otra cosa que no sea el mantenimiento de productos en su cuenta de productos. A tal fin, asegúrese de prod no puede ver el código fuente, no se puede iniciar un IDE, etc
Eric Lloyd
¿Dónde obtengo uno de esos artilugios de doble llave de giro simultáneo y viene con USB?
Lilienthal
Otra cosa que podría ayudar es automatizar completamente los procedimientos (uno o dos clics) en la preparación y el desarrollo, pero no automatizar completamente las implementaciones de producción. Tener que acceder manualmente a la caja para hacer cualquier cosa a la producción pero no a otros entornos es una diferencia significativa en conveniencia, como sugiere. (Todavía puede escribir cualquier paso involucrado y usar ese script en todos los entornos; lo que quiero decir es que tendría que desactivar manualmente la ejecución de dichos scripts para la producción). Eso, por supuesto, se puede hacer además del tipo de autenticación procedimientos que recomiendas.
jpmc26
1
@Lilienthal Era una metáfora del teatro de alta seguridad, pero se podía emular esas memorias USB que atacaban de forma económica a cada desarrollador y luego hacer que su automatización verificara al menos dos de sus números de serie al ejecutar cosas peligrosas. En equipos más grandes, puede iniciar sesión para ver quién está interfiriendo con la producción y responsabilizar a las personas adecuadas cuando todo sale mal.
Oli
12

Uno de mis compañeros de trabajo tiene un enfoque interesante para esto. Su esquema de color terminal para la producción es fugoso . Gris y rosa y difícil de leer, lo que teóricamente se supone que garantiza que, sea lo que sea que escriba, realmente tenía la intención de escribir.

Su kilometraje puede variar ... y probablemente no tenga que decir que no es a prueba de balas por sí solo. :)

robhol
fuente
2
También utilizo un gran color de fondo rojo en las conexiones de terminales / db a los servidores de producción, así como fondos de pantalla rojos brillantes para las tareas administrativas en PC ...
Falco
Sí, estaba pensando eso. Haga que la producción de bomberos rojo ...
Chris B. Behrens
La codificación de colores ayuda. Igual que en un IDE.
Thorbjørn Ravn Andersen
1

Los desarrolladores no deben conocer la contraseña de la base de datos de producción. La contraseña del producto debe ser aleatoria y no memorable, algo así como el resultado de la combinación de teclado ( Z^kC83N*(#$Hx). Su contraseña dev puede ser $YourDog'sNameo correct horse battery staplelo que sea.

Claro, puede averiguar cuál es la contraseña, especialmente si es un equipo pequeño, mirando el archivo de configuración de la aplicación cliente. Ese es el único lugar donde debería existir la contraseña prod. Eso asegura que tendría que hacer un esfuerzo deliberado para obtener la contraseña prod.

(Como siempre, debe tener copias de seguridad puntuales para su base de datos de producción. Por ejemplo, con MySQL, archive los registros binarios como copias de seguridad incrementales. Para PostgreSQL, archive los registros de escritura anticipada. Esa es su protección de último recurso para cualquier tipo de desastre, autoinfligido o no).

200_success
fuente
No puedo estar totalmente de acuerdo con esto, porque en cualquier entorno grande realista hay instancias bastante regulares en las que los desarrolladores / administradores necesitan acceder a la base de datos de producción. Claro, en un mundo perfecto con un sistema impecable, esto nunca debería suceder, pero en la mayoría de los sistemas sé que tienes que arreglar algunos datos críticos de producción a mano ... Así que estoy con Oli, el inicio de sesión de producción debería ser inconveniente, pero factible
Falco
1
@Falco Eso es exactamente lo que estoy sugiriendo. Inconveniente pero factible.
200_success
El problema con su enfoque es único, si hay una emergencia y la producción está baja, el tiempo cuenta. Por lo tanto, sus desarrolladores deben saber dónde encontrar la contraseña y obtenerla rápidamente. Si tienen que preguntar, busque en el repositorio y los archivos de configuración y pruebe que está perdiendo tiempo valioso = dinero. Así que prefiero tener la contraseña en un lugar donde todos sepan dónde buscar, pero sigue siendo un inconveniente, pero rápido si es necesario
Falco
2
@Falco Dado que los entornos de producción deberían reflejar de cerca los entornos de desarrollo, el archivo de configuración estaría en el lugar análogo en el servidor de producción como en las máquinas de desarrollo. Cualquier desarrollador competente debe saber dónde buscar, y si no sabe dónde buscar, entonces desea ese retraso, precisamente para evitar daños del tipo indicado en la pregunta.
200_success
No conocer las contraseñas no obstaculiza los accidentes. Por el contrario, crea la motivación para hacer la búsqueda de contraseña solo una vez, y luego el desarrollador puede comenzar a usar bash history o incluso puede crear un alias para conectarse a la base de datos. Y luego, es más probable que ocurran accidentes.
k0pernikus
0

La respuesta corta es RBAC: control de acceso basado en roles.

Sus permisos para todos los entornos deben ser diferentes, y tan molestos como lo son cosas como UAC, los necesita: especialmente para entornos PROD.

No es nunca una razón para que los desarrolladores tengan acceso directo a Prod - por pequeña que sea la organización / equipo. Su "Dev" también puede usar los sombreros "Stage" y "Prod", pero necesita tener diferentes credenciales y procesos para atacar diferentes entornos.

¿Es molesto? Absolutamente. ¿Pero [ayuda] a prevenir el borking en sus entornos? Absolutamente.

madriguera
fuente
0

Una solución rápida y simple: use dos cuentas de usuario diferentes, una para su trabajo de desarrollo normal que solo tiene acceso a la base de datos de desarrollo y otra diferente para operar realmente en la base de datos de producción, con acceso completo a ella. De esta manera, tendrá que cambiar activamente la cuenta que está utilizando antes de poder realizar cambios en la producción, lo que debería ser suficiente para evitar errores accidentales.

Se puede utilizar el mismo enfoque si tiene dos sitios web, o dos servidores, o dos entornos completos: una cuenta de usuario para el desarrollo sin acceso (o al menos sin acceso de escritura ) a producción, otra cuenta de usuario para trabajar en el sistema de producción ( s)

Este es el mismo enfoque que un administrador de sistemas que tiene una cuenta estándar que no es de administrador para el trabajo de rutina (lectura de correo electrónico, navegación web, seguimiento de tickets, presentación de hojas de tiempo, documentación de escritura, etc.) y una cuenta distinta de administrador completo que se utilizará cuando realmente opere en servidores y / o Active Directory.

Massimo
fuente