El caso de la copia de seguridad del código fuente



Nunca antes las organizaciones han manejado más información, o han estado más preocupadas por cómo puede caer en las manos equivocadas. Esta preocupación se aplica a todos los datos, pero especialmente al código fuente en el que se basan para mantener sus procesos en ejecución.

Tanto las empresas como las personas confían en plataformas como GitHub, GitLab y BitBucket para almacenar y administrar su código fuente y mantener sus proyectos de desarrollo en ejecución. Estas plataformas son muy populares: GitHub tiene más que 73 millones de desarrolladores y 200 millones de repositorios, GitLab estimados 30 millones de usuarios registrados y BitBucket reportado 10 millones de usuarios en 2019.

Si los equipos de seguridad no están preocupados por el código fuente almacenado en estas plataformas, deberían estarlo porque es probable que sus desarrolladores tengan al menos algunos proyectos que están guardando allí. Algunos ataques en los últimos años han resaltado la amenaza: un ataque de ransomware de 2019 borrado Repositorios de código fuente de Git en todas las plataformas y los reemplazó con una demanda de rescate. También existe el riesgo de tiempo de inactividad, como fue el caso cuando GitHub Estaba abajo durante al menos dos horas en junio de 2020.

El costo de perder el código fuente es alto, dice John Bambenek, principal cazador de amenazas de Netenrich.

«Todo lo que es crítico para una organización debe ser respaldado», dice. «Una buena regla typical es: ‘¿Puede la empresa continuar operando sin esto?’ y si la respuesta es no, debe haber un system de respaldo».

Hay muchas razones por las que una empresa podría no estar pensando en hacer una copia de seguridad de su código fuente. En parte podría ser querer ahorrar dinero y en parte sentirse invulnerable a los ataques que comprometerán su código fuente. También existe la realidad de que las copias de seguridad cuestan dinero sin ningún beneficio tangible, hasta que se necesitan, señala Mark Loveless, ingeniero de seguridad sénior de GitLab.

«En su mayor parte, solo estás haciendo algo en lo que no ves una ganancia inmediata», dice. «Así son las copias de seguridad. No ves una ganancia inmediata, y nunca quieres ver una ganancia inmediata en las copias de seguridad porque esperas que todo funcione y nunca tengas que recurrir a ellas. Pero necesitas un prepare para eso.»

La conciencia es otro tema. Es posible que algunas personas no hagan una copia de seguridad de su código fuente porque creen que no tienen que hacerlo, agrega. GitLab, GitHub y BitBucket, al igual que los principales proveedores de nube, tienen un «modelo de responsabilidad compartida» en el que los usuarios y proveedores del servicio comparten la responsabilidad de proteger su información.

GitLab hace copias de seguridad en sus propios servidores «casi constantemente», dice Loveless, pero muchas personas tienen su propia instancia de GitLab ejecutándose en su propio espacio de nube privada o en un servidor físico en su centro de datos. En estos casos, los usuarios deben considerar el proveedor de la nube que están utilizando, qué tipo de copias de seguridad mantienen y cuánto tiempo antes quieren respaldar sus datos.

«Git… dado que almacena un historial de registros de código y puede retroceder a una versión anterior del código, [users] tienden a pensar que hay una copia de seguridad», dice Loveless. «La hay, en lo que respecta a las revisiones y los cambios en su código… pero están almacenados en [and] archivos de datos, y esos necesitan ser respaldados».

Una copia de trabajo del repositorio en cada computadora no debe considerarse una copia de seguridad, ya que generalmente solo contiene el código fuente y no los problemas, comentarios, solicitudes de extracción y otros metadatos asociados con él. Es común pensar que un repositorio Git u otro management de versiones es suficiente, agrega Taylor Gulley, consultor sénior de seguridad de aplicaciones en nVisium. El command de versiones, aunque es muy útil, solo tiene su código almacenado en una única ubicación centralizada.

«A menos que su program de recuperación ante desastres sea extraer el código de la máquina local de un desarrollador, suponiendo que haya alguno que sobreviva al incidente que derribó el servidor, las copias de seguridad adecuadas son críticas», dice Gulley.

Lo que las empresas deben saber sobre el proceso
Las copias de seguridad del código fuente pueden tomar múltiples formas. Las organizaciones pueden optar por administrar sus propias copias de seguridad y hacerse cargo de la infraestructura, los procesos y los costos de reparación asociados. Si bien esto les da un mayor management sobre sus datos, puede costar más a largo plazo debido a los recursos que se gastan en mantenimiento.

Las copias de seguridad manuales también implican desafíos técnicos. Es difícil mantener la coherencia de todos los activos para que puedan recuperarse en cualquier repositorio de Git porque cada proveedor tiene su propia API, proceso, comentarios y problemas. Los límites de la tasa de solicitud de API plantean otro obstáculo: por lo general, la copia de seguridad de Git está asociada con el envío de muchas solicitudes a la API del proveedor de Git, y tienen que limitar la cantidad de solicitudes enviadas en un período de tiempo limitado.

Alternativamente, pueden buscar a un tercero que se encargue de la gestión de copias de seguridad. En muchos casos, existen servicios en la nube que pueden ayudar con esto, señala Bambenek. Las organizaciones pueden recurrir a un servicio como GitProtect.io, una herramienta diseñada para realizar copias de seguridad del código en GitHub, GitLab y BitBucket.

«La necesidad se encontró dentro de nuestra propia empresa», dice el gerente de desarrollo de productos de GitProtect, Greg Bak, sobre la creación del producto. «Teníamos algunos scripts internos para proteger esos repositorios, pero nadie podía garantizar que siempre podamos restaurar esos repositorios… que estén protegidos correctamente, que nuestras copias de seguridad estén probadas. Así que decidimos [build] eso.»

GitProtect está disponible en dos modelos: respaldo como servicio y community, por lo que las organizaciones pueden instalarlo localmente o implementarlo en la nube pública. El objetivo del producto es no solo proteger el código fuente, sino también todos los metadatos relacionados necesarios para mantener un repositorio consistente, como comentarios, problemas y tareas de CI/CD, dice Bak.

Hay una serie de amenazas que podrían comprometer el código fuente, más allá de los ataques dirigidos a los repositorios y la posible interrupción de estas plataformas. El error humano y los cambios no deseados en el código en sí podrían requerir copias de seguridad para que los procesos vuelvan a funcionar, agrega.

Mejores prácticas de copia de seguridad
Independientemente de cómo decida hacer una copia de seguridad de su código fuente, Loveless de GitLab aconseja llevar a un experto en seguridad a la sala.

«Invierte en algunas personas de seguridad», dice. «Si puede tener personas allí, personas experimentadas que saben cómo hacer esto, invierta en personas y debería obtener resultados mucho mejores».

Los expertos también aconsejan mantener las copias de seguridad almacenadas en un lugar seguro y cifradas. Si está ejecutando un entorno multinube, rote las copias de seguridad fuera del sitio o fuera del sistema. Gulley recomienda mantener un par de copias en el sitio y una fuera del sitio, en caso de que la ubicación se vea comprometida. Las copias de seguridad anteriores no deberían poder ser modificadas o eliminadas por los procesos o cuentas de copia de seguridad automatizados.

Todos los expertos coinciden en que no basta con hacer copias de seguridad del código fuente. También es importante probarlos y asegurarse de que funcionan. Si no lo hacen, no querrá saber cuándo los necesita. Pruebe el proceso de acceso y uso de las copias de seguridad para asegurarse de que puede usarlas y de que todos los involucrados comprenden su función en caso de un ataque, interrupción o compromiso.



Enlace a la noticia initial