Aclaración de la pregunta
La mayoría de las respuestas hasta ahora asumen que el pasaje citado en la pregunta se refiere a los cambios que se originan en las estaciones de trabajo de los desarrolladores individuales.
Por el contrario, el pasaje se refiere a la propagación de cambios entre un servidor de desarrollo y un servidor de producción. El autor debería haber utilizado la terminología más apropiada para el caso de uso más común: propagar cambios de un servidor "de prueba" o "de prueba" a un servidor de producción. La redacción en el pasaje citado también es incómoda, pero lo esencial es que el proceso de propagación del cambio siempre debe iniciarse desde el servidor de producción, es decir, los cambios se "extraen" del servidor de desarrollo. , no "empujado" desde el servidor de desarrollo / prueba / puesta en escena.
La justificación
El fundamento es simple: en la mayoría de los casos, tiene mucho más sentido dar a un entorno de producción acceso a un servidor de desarrollo (o prueba / organización) que al revés. Si el servidor de producción se ve comprometido, la probabilidad de que se produzcan daños adicionales como resultado del "paso a paso" del atacante hacia el servidor de desarrollo es mínima (al menos siempre que se observen las mejores prácticas y no haya nada "sensible" en el servidor de desarrollo, particularmente en la forma de credenciales a otros sistemas o datos "reales"). No hace falta decir que las credenciales a otros sistemas internos, datos de clientes reales, etc., nunca deben propagarse a un servidor de desarrollo.
Un lado relacionado
En los casos en que un problema espinoso requiera absolutamente acceso a los datos de producción, se debe tener especial cuidado de "proteger" los datos en un sistema sin conexión, aislado con un acceso extremadamente limitado. Los datos de dicho sistema deben destruirse inmediatamente después de resolver el problema. Para los problemas que requieren acceso a otros sistemas para reproducirse, como un servidor web que requiere acceso a una instancia de almacén de datos, se debe hacer todo lo posible para "simular" la funcionalidad que proporciona la dependencia y eliminar la necesidad de conectar los sistemas. .
Excepción a la regla
Una excepción a la "regla" que describe el autor es cuando el servidor de desarrollo se encuentra dentro del firewall y el servidor de producción está en la DMZ. En tales casos, puede ser que el servidor de producción no pueda iniciar la comunicación con el servidor de desarrollo (lo que hace imposible la estrategia de "extracción"), pero el servidor de desarrollo puede iniciar la comunicación con el servidor de producción. En tales topologías, en las que esta iniciación unidireccional es un diseño secundario, puede ser necesario impulsar cambios desde el desarrollo a la producción.
En tales casos, las credenciales requeridas para conectarse desde el desarrollo hasta la producción deben estar altamente protegidas y nunca deben almacenarse en el servidor de desarrollo (por ejemplo, en la forma de una clave SSH sin una contraseña). Además, cualquier persona que esté autorizada para conectarse al servidor de desarrollo e iniciar un impulso a la producción debe ser obligada a iniciar sesión en su propia cuenta en los sistemas ambos (las cuentas nunca deben compartirse entre los usuarios, al hacerlo compromete la responsabilidad).
Si se requiere acceso a nivel de raíz en cualquiera de los sistemas para completar la propagación, se debe emplear una implementación similar a sudo si es posible, ya que tal mecanismo mejora enormemente la responsabilidad.