¿Debería un desarrollador negarse a acceder al servidor de producción? [cerrado]

7

Ya hay preguntas en SE que preguntan si un desarrollador debería tener acceso a los servidores de producción.

Pero, dado el hecho de que ya tengo un acceso raíz en el servidor de producción, ¿debería decir que, como desarrollador, usar ese acceso está más allá de mis responsabilidades? ¿Debo argumentar que no soy un administrador de sistemas y tengo miedo de romper cosas?

O, ¿el cambio de cosas en el servidor de producción debe considerarse una mala práctica pero solo una parte de nuestro pobre proceso de lanzamiento / depuración / desarrollo?

Gracias.

    
pregunta Mathieu 25.09.2014 - 07:00

4 respuestas

15

Depende. Aquí está el principio meta. Si estás en una pequeña empresa y hay un problema, y te niegas a resolverlo, entonces tu comportamiento se convirtió en un problema.

Ahora la pregunta es qué problema tienes.

  1. ¿El problema es que se deben realizar cambios en la producción y usted es el que está disponible?
  2. ¿El problema es que realmente no sabes cómo hacer la tarea?
  3. ¿O es el problema que alguien esté tratando de usarte como una puerta trasera para hacer las cosas que alguien más piensa que no debería pasar?

Decide rápido.

Si es el primero, entonces lo que debes hacer es realizar la tarea, documentar cuidadosamente a medida que avanzas lo que hiciste, y luego enviarlo a quien sea ideal debería haber hecho ese trabajo, posiblemente junto con Con su comentario de que se siente fuera de su profundidad y esto es arriesgado. Siéntete libre de enviar un CC a cualquier persona que creas que esté calificada para tener una opinión sobre lo que hiciste. Existe la posibilidad de que obtengas comentarios que te ayuden a hacerlo mejor la próxima vez.

Si es el segundo, mida dos veces, corte una vez. Esta es una oportunidad de aprendizaje, trátelo como a uno. Y envíe un correo electrónico como el descrito anteriormente en busca de comentarios y consejos sobre cómo hacerlo la próxima vez.

Si es el último, entonces debes decir: "Así es el responsable de esto, y no quiero crear un problema porque no sé qué otra cosa estaría pisando". Y luego mantente firme al pasar la pelota.

Si tiene alguna duda, comience a hacer lo que se necesita inmediatamente después de enviar las advertencias que necesita. Por lo general, no lo arruinarás (demasiado mal), y eso soluciona un problema obvio inmediato. Si su acción resultó ser incorrecta, la culpa suele ser fácil de desviar. (A menos que esté en una organización tóxica, en cuyo caso la única opción que funcionará a largo plazo es conseguir un mejor trabajo).

    
respondido por el btilly 25.09.2014 - 09:17
1

¿Es usted responsable o responsable de alguna acción que debe ejecutarse "como root" en el servidor de producción?

Si es así, entonces estás agobiado.

  • Consiga un complemento de shell que registre todo lo que escribe en un archivo; de esa manera, al menos tendrá un registro de cómo se rompieron las cosas ,
  • Haga que alguien más mire por encima del hombro antes de presionar algo circular y vagamente rojo ( especialmente si está destellando en algún grado),
  • Notifique a quien cuide de sus acuerdos de seguridad corporativa que tiene este nivel de acceso (y ellos pregunte por qué), que puede provocar un nido de avispas para su jefe,
  • Investigue formas de minimizar el riesgo de que usted cause algún daño. ¿Puede hacer lo que necesita hacer de otra manera (o por alguien u otra cosa)?
    Automatización: hacer las cosas de manera confiable, de la misma manera, cada vez, es algo maravilloso.
  • Prepárate para lo peor cuando sucede.

Si en realidad no necesita este nivel de acceso, entonces alguien debe quitárselo.

El principio de privilegio mínimo no solo se aplica al código de la aplicación; Se aplica igualmente bien a las personas. ¿Boss realmente quiere que puedas ver su salario? Dejar que ese "resbalón" en la conversación pueda muy bien hacer que las cosas rueden.

    
respondido por el Phill W. 25.09.2014 - 13:38
0

Evita la interacción solo si ...

Evitar completamente el servidor de producción solo es práctico si:

  1. Le proporciona al cliente una forma sencilla de actualizar el software y está dispuesto a proporcionar capacitación para mostrarle cómo hacerlo.
  2. Las actualizaciones son tales que el cliente puede realizarlas a su gusto. Si requiere que realicen una actualización para las lagunas de seguridad en su software, es posible que no quieran / puedan hacerlo. , y usted debe dar cuenta de eso.
  3. Usted rechaza la posibilidad de tener acceso de cualquier . Una de las implicaciones legales de poder acceder al servidor de producción es que se le puede culpar por cualquier tipo de problema al que tenga acceso. Eliminar esa posibilidad es fundamental para eliminar la responsabilidad legal.

Sin embargo, las ventajas de evitar por completo el servidor de producción solo se aplican si toda la empresa está de acuerdo. Si usted, el programador, decide que este es el mejor enfoque y Bob, el programador interno no está de acuerdo e ignora su atención, en última instancia, no ha logrado nada, excepto potencialmente algunas cenizas de cigarrillos en el café de la mañana en la oficina. En otras palabras, si esto no es una política de la empresa, esto es lo que debe cambiar, no usted personalmente. Puede mencionar estos puntos a su jefe, sin embargo, si su empresa no está a bordo, debe interactuar con el servidor de producción.

Algunos consejos útiles si debes

Si tiene que interactuar con el servidor de producción, tengo suficiente experiencia para mencionar algunos puntos:

  • HAGA una copia de seguridad antes de hacer cualquier cosa que manipule la base de datos. Cuanto más reciente, mejor. Si algo sucediera y tienes una copia de seguridad de un día, todavía estarás en la mierda, pero al menos no serás despedido por ello. Tenga una copia de hace media hora, e incluso puede salir ileso de ella.
  • DEBE notificar antes de realizar cualquier actividad en el servidor de producción. Si este es un problema legal, si bien no es una evidencia sólida de que no toque el servidor sin previo aviso, es un buen argumento a su favor. Si envía un correo electrónico, asegúrese de recuperar un indicador de que su cliente lo ha leído.
  • Póngase en contacto con su cliente cuando sea conveniente realizar actualizaciones / verificaciones. Solo necesitas hacer esto una vez, para tener una idea general de las horas (a la hora del almuerzo o lo que sea). Asegúrese de enviar una confirmación de las horas comunicadas por teléfono por escrito en un correo electrónico, y asegúrese de que su cliente reciba el correo electrónico (los correos electrónicos siguen fallando a veces).
  • NO realice cambios en la base de datos que no pueda revertir. Sí, tiene una copia de seguridad, es cierto, aunque ¿cómo reaccionaría su cliente si se viera obligado a decirle que la única forma de regresar a un estado anterior era borrar todos los datos de ese día? Más importante aún, ¿cómo reaccionaría su jefe ante usted al decirle que debe borrar los datos de producción del cliente para ese día? Si no hay otra forma, siempre puede elegir NOT para hacerlo. Siempre puede trasladar los datos a sus bases de datos locales para replicar los problemas (asumiendo, por supuesto, que tiene aprobación). No debería haber excusas aquí.
  • NO deje datos basura en la base de datos. Este es un corolario de la declaración anterior. Si creó un nuevo registro para probar algo, aunque puede que no afecte el funcionamiento del programa, el cliente todavía puede ver esto. Como programador, es completamente poco profesional y hace que su empresa parezca que usted vende chocolate y también software adicional.

Probablemente ya conoce estos puntos o no preguntaría si es una buena idea modificar el servidor de producción, aunque tal vez esta respuesta podría ayudarlo a formular algún tipo de política de la compañía para lo que concierne a la interacción con el servidor de producción. .

Espero que ayude!

    
respondido por el Neil 25.09.2014 - 10:15
0

La cuestión de 'debería' encuentra su camino en una serie de otras situaciones. En el mundo de devops donde los programadores toman lo que se ve tradicionalmente como roles de TI, la línea se pone muy muy borrosa. En otros mundos, como los bancos o cualquier cosa que maneje dinero (o atención médica e hipaa), la pregunta es un rotundo "no" que no requiere más elaboración.

Veamos cómo lo maneja una de esas áreas de manejo de dinero. El PCI DSS (industria de tarjetas de pago (es decir, Visa, Mastercard y similares) Estándar de seguridad de datos) tiene algunas puntos específicos sobre este tema.

Hay requisitos específicos en el DSS como 3.5.1:

  

Restrinja el acceso a las claves criptográficas al menor número de custodios necesarios.

o 6.4.2:

  

Separación de tareas entre los entornos de desarrollo / prueba y producción

Este último habla específicamente de lo que estás preguntando y en la sección de orientación dice:

  

La reducción de la cantidad de personal con acceso al entorno de producción y los datos del titular de la tarjeta minimiza el riesgo y ayuda a garantizar que el acceso se limite a aquellas personas que necesitan información.

     

El propósito de este requisito es separar las funciones de desarrollo y prueba de las funciones de producción. Por ejemplo, un desarrollador puede usar una cuenta de nivel de administrador con privilegios elevados en el entorno de desarrollo y tener una cuenta separada con acceso de nivel de usuario al entorno de producción.

Esto significa que si está usando un sombrero de desarrollador, no debería tener acceso administrativo en el entorno de producción. Uno puede argumentar que puede cambiar de sombreros (y todos los entornos asociados: aquí está el "está de guardia y tiene una computadora portátil de acceso de administrador en la que no hace desarrollo" y no hace nada de administrador desde su máquina de desarrollo. "), pero eso se relaciona con la forma en que la administración desea afirmar que cumple con los requisitos.

Entonces, ¿deberían los desarrolladores tener acceso a la producción? Por supuesto, los registros de lectura y similares son muy útiles y una molestia tener que pasar por TI y / u organizaciones de Operaciones para acceder. ¿Deben los desarrolladores tener acceso a la producción de admin ? Depende de lo que estén haciendo y de lo que digan las distintas regulaciones.

Si está en una tienda pequeña que no tiene el personal o la infraestructura, o el requisito de que no tenga acceso, es probable que se encuentre con acceso de administrador sin importar si te guste o no, y se te pedirá que hagas cosas de administrador de vez en cuando.

Realmente depende de dónde se encuentre y cuánta burocracia hay para proteger la producción de los desarrolladores (porque hay algunas cosas tan divertidas como empujar código o editar código en vivo en la producción).

La vida de alguien que tiene acceso a la producción siempre es 'interesante'.

    
respondido por el user40980 26.09.2014 - 04:17

Lea otras preguntas en las etiquetas