Sabemos que la aplicación de parches en vivo tiene beneficios reales, ya que reduce en gran medida el tiempo de inactividad asociado con la aplicación de parches frecuentes. Pero el parche en vivo es relativamente difícil de ganar sin causar otros problemas, y correcto a esto, el parche en vivo no se implementa con tanta frecuencia como debería. Luego de todo, lo postrer que quieren los administradores de sistemas es un parche activo que bloquee un sistema.
Las compilaciones reproducibles son una de las herramientas que los desarrolladores pueden usar para implementar parches en vivo de guisa consistente y segura. En este artículo, explicaré por qué las compilaciones reproducibles son importantes para el parcheo en vivo, qué son exactamente compilaciones reproducibles y cómo los contenedores vienen al rescate.
Tabla de Contenidos
Parches en vivo: una útil de encargo de amenazas esencial
La aplicación de parches es una parte fundamental del mantenimiento del sistema porque la aplicación de parches corrige errores y códigos defectuosos. Más importante aún, los equipos de seguridad confían en los parches para corregir los agujeros de seguridad, y existe una aprieto vivo. Esperar a que se aplique un parche de mantenimiento adecuado es arriesgado, ya que permite a los piratas informáticos rendir un exploit.
Crea un enigma difícil: mantenga una suscripción disponibilidad pero asuma un aventura de seguridad, o aplique parches con frecuencia pero termine con partes frustradas involucradas. La aplicación de parches en vivo cierra esta brecha. La aplicación de parches en vivo elimina el código incorrecto mientras un proceso se está ejecutando activamente sin reiniciar la aplicación o el servicio que depende de ese proceso.
Implementar parches en vivo no es viable
La aplicación de parches en vivo no es tan viable de hacer: el código directo tiene que «coincidir» de la misma guisa, de lo contrario, pueden suceder todo tipo de cosas no deseadas. Si se equivoca, la aplicación, o todo el servidor, se bloqueará.
El código detrás de un proceso en ejecución generalmente proviene de un archivo ejecutable binario, un agrupación de código fácil por máquina compilado a partir del código fuente. Por ejemplo, un kernel tiene miles de archivos fuente, todos los cuales se compilan en unos pocos binarios.
Con el parche en vivo, el código del parche en vivo debe coincidir en un nivel exacto. Sí, el binario con el código de parche es diferente del binario con el código defectuoso. Aun así, el nuevo código debe encajar exactamente y obedecer de la misma interpretación de las bibliotecas importadas. El código de parche en vivo todavía debe compilarse con las mismas opciones y banderas del compilador. El bit endianness todavía juega un papel: el archivo binario debe ordenarse de la misma guisa.
En principio, todo esto es factible, pero en la experiencia es un desafío. Por ejemplo, las actualizaciones diarias del sistema suelen afectar a las bibliotecas. Estas bibliotecas pueden posponer sutilmente y, a su vez, producir archivos binarios que difieren sutilmente cuando compila su código.
Si se crea un parche en un sistema donde solo hay una pequeña diferencia en una sola biblioteca, ese parche puede rodear fácilmente el proceso al que se aplica. O todo el sistema si es un parche del kernel.
Por qué las compilaciones reproducibles son importantes para la aplicación de parches en vivo
En otras palabras, el entorno en el que se desarrolla un parche es en realidad importante. Cuando se desarrolla un parche, es importante entretener el entorno rodeando del código que se está parcheando. Sin instrucciones, esto puede ser todo un desafío.
Puede ser más viable para los equipos de código campechano que admiten código, ya que esos equipos deben tener un registro del estado ambiental flamante, y lo mismo ocurre con los proveedores de software. Pero a veces los desarrolladores detrás del software pueden no divulgar un parche de inmediato.
Cuando las empresas u otros terceros intentan parchear internamente, intentar replicar el entorno de compilación flamante puede ser increíblemente desafiante, cachazudo, impredecible y requiere cierto nivel de prueba y error.
Por esta razón, los desarrolladores de software han intentado entretener el entorno de compilación flamante más fácilmente y, por lo tanto, ha surgido la citación compilación reproducible como el camino a seguir.
Entonces, ¿qué es una construcción reproducible?
En jerga simple, una compilación es reproducible cuando dos desarrolladores de software independientes tienen la capacidad de agrupar código fuente fácil por humanos en código fácil por máquina para que los dos intentos independientes produzcan un archivo binario idéntico en términos de bits.
Para construcciones reproducibles, los autores sugieren tres criterios esencia para una construcción reproducible. Primero, el proceso de construcción debe ser determinista: no se registran variables como la término o la hora y la salida debe generarse en el mismo orden, una indicación de la endianidad del bit.
A continuación, se deben proporcionar o detallar las herramientas necesarias para reproducir el entorno de construcción. En última instancia, los desarrolladores deben poder validar la compilación que han realizado.
Podría decirse que uno de los fundamentos más importantes es la capacidad de reproducir el entorno del edificio, pero dados los muchos factores cambiantes que trae el entorno del edificio, este todavía es uno de los más difíciles de ganar.
Las compilaciones reproducibles no son un concepto completamente nuevo, el Esquema GNU ha estado usando compilaciones reproducibles desde la división de 1990, pero los beneficios de las compilaciones reproducibles pueden ser mayores que nunca.
Hágalo aceptablemente y su compilación reproducible garantiza que pueda crear un parche que se ajuste a un proceso en vivo sin romper nulo. Incluso puede echarse en brazos en el proceso de compilación reproducible para cerciorarse de que el código binario que está utilizando no haya sido manipulado. En finalidad, esto asegura que se pueda corroborar una ruta directa desde la fuente al binario de salida.
Envase: el huevo de Colón de parche vivo …
Expliqué por qué las compilaciones reproducibles son un gran concepto, pero todavía por qué las compilaciones reproducibles pueden ser difíciles de ganar. Una forma que facilita la reproducción del entorno de compilación de forma coherente es utilizar máquinas virtuales. Los desarrolladores esencialmente empaquetan y distribuyen todo el entorno de compilación en una máquina potencial.
Sin incautación, mandar máquinas virtuales es engorroso: el archivo de VM es vasto y se debe iniciar todo el sistema activo para cumplir con una solicitud de cambio o para ver «adentro» de la VM para analizar el entorno de compilación. Cuando hay varios equipos en la mezcla, las máquinas virtuales pueden ser un problema vivo.
Los contenedores son una forma mucho más viable y ágil de pugnar el entorno de construcción flamante. En comparación con las máquinas virtuales, los contenedores proporcionan virtualización a nivel del sistema activo, lo que significa que las imágenes de contenedor son mucho más compactas.
Tomemos a Docker, por ejemplo, un producto popular que permite la contenedorización. Cuando los desarrolladores quieren pugnar el entorno de compilación flamante, el desarrollador simplemente descarga un archivo de configuración para un contenedor, el llamado Dockerfile. Este archivo de configuración contiene una serie de instrucciones que reflejan el entorno de construcción exacto.
En circunscripción de mandar archivos de VM grandes, cualquier cambio en el entorno de compilación simplemente se escribe en el Dockerfile, que se almacena yuxtapuesto con el otro código necesario para reproducir una compilación. Los contenedores permiten a los desarrolladores eludir muchas de las dificultades que plantean las compilaciones reproducibles al tiempo que proporcionan un proceso de compilación que se puede auditar.
El parcheo en vivo como experiencia diaria
La capacidad de reproducir paquetes binarios idénticos (compilaciones reproducibles) es fundamental para que los parches en vivo funcionen. Sin incautación, las compilaciones reproducibles han sido difíciles de ganar, lo que a su vez limita la disponibilidad de parches en vivo.
Los contenedores facilitan la creación de parches adecuados para parches en vivo. Abre la puerta al explicación de parches para los usuarios corporativos sabiendo que esos parches se están implementando en vivo, sin causar ninguna interrupción.
Esto significa que la aplicación de parches en vivo se puede implementar de guisa más amplia, lo que ahorra a muchas organizaciones los enseres disruptivos del tiempo de inactividad de la aplicación de parches y, en consecuencia, perfeccionamiento su postura de seguridad genérico, ya que los parches ahora se pueden aplicar con la ligereza y frecuencia necesarias.
