Aun recuerdo la primera vez que borré de manera accidental el trabajo que debía entregar ese mismo día. Sucedió aproximadamente 15 años atrás. Yo trabajaba en Flash, hacía contenido interactivo para el sector de la educación y para ese entonces me habían solicitado hacer un menú que iría como parte de un SCORM. El menú era sencillo: los datos del índice se cargaban desde un archivo XML local y enlazaban al contenido que iría dentro del paquete. Había terminado el prototipo y lo había exportado. Alcancé a mostrárselo a mis jefes y cuando todo estuvo bien procedí a limpiar el espacio de trabajo. Yo me acostumbré a borrar de manera permanente los archivos. Estaba borrando los archivos intermedios y temporales, además de los archivos con versiones alternativas del menú. Luego, en un segundo, me di cuenta que había seleccionado el que era el archivo final y sin embargo presioné Ctrl + Shift + Supr, luego Enter, y ahí acabó todo. Media jornada de trabajo había desaparecido y debía recuperarla ahora en tiempo récord. Nada funcionó, solo volverlo a hacer desde cero. Para mi fortuna era un trabajo que ya había aprendido a hacer, y pude entregarlo luego sin tanta demora.
En ese entonces no sabía ni en teoría qué era un control de versiones. Lo vine a saber un par de años más tarde cuando me topé por accidente con Subversion. En ese entonces eran muy pocas las plataformas que ofrecían un servicio de control de versiones y Github ni siquiera había nacido. Así que opté por instalar en un equipo en desuso una del paquete de CollabNet llamado Subversion Edge. Jugué un poco con la configuración, las características e inmediatamente lo apliqué a mi trabajo. En poco tiempo había pasado de llenarme de archivos ZIP con versiones de trabajos redundantes y sin una trazabilidad clara a tener un espacio de trabajo ordenado y a prueba de eliminaciones accidentales.
10 años después y después de reflexionar mucho en el asunto, decidí migrar los proyectos en los que seguía trabajando a git. Ahora sí existían servicios de versionamiento en la nube por montones y con diferentes motores; y con esta gran oferta de servicios también había muchas dudas sobre la seguridad de la información.
Lo que debes tener en cuenta si usas un servicio cloud de manera profesional
Un servicio en la nube del estilo regístrate en 5 minutos y empieza a usarlo esconde una variedad de dudas respecto a cómo son tratados los datos que subes a esta misma. ¿Cumplen con un estándar de seguridad? ¿existe la privacidad? ¿qué tal es la integridad? ¿hay vulnerabilidades en los servicios? ¿son confiables los trabajadores dentro de la plataforma que ni siquiera conoces? ¿cómo aplican las leyes sobre tus datos? ¿en dónde están almacenados fisicamente?
Podemos inferir que un servicio cloud es más propenso a ser atacado que uno autogestionado. La principal causa es la popularidad del servicio. Hace unos días los usuarios de Github notificaron de un ataque tipo phising que incluso burlaba la autenticación de dos factores a nivel de software. Una cuenta comprometida puede configurarse de tal modo que aunque se cambie la contraseña, el atacante aun siga teniendo control de la misma, por ejemplo, con tokens de acceso. Por supuesto hay diferentes mecanismos de monitoreo como el envío de correos electrónicos cuando una característica de seguridad es actualizada, sin embargo esto no mitiga el daño causado.
Cuando trabajas en un código cerrado quieres que el mismo sea confidencial, que no haya filtración de información ni de secretos empresariales. Como desarrollador también debes garantizar esto al cliente. La cuestión es que no todos los clientes se preocupan por este punto ya que no alcanzan a comprender ni imaginar el impacto negativo que una fuga de este tipo puede ocasionar al negocio. ¿Qué ocurriría si se libera el código fuente de Airbnb, o de los productos de Adobe? Estas empresas con un esfuerzo grande pueden mitigar las consecuencias, pero como siempre, el daño ya está hecho. Ahora bien, ¿qué pasaría si el código de tu cliente es expuesto publicamente en internet? ¿Tienes la manera de mitigar el daño causado?
El código fuente es un activo muy preciado no solo en empresas TIC. Hoy en día el software es el pegamento empresarial. Está presente en todos los niveles y en todas las cadenas de todos los procesos de negocio. Una empresa con visión no puede concebirse sin una plataforma tecnológica que ordene y procese los datos. Este software en su mayoría puede ser hecho a la medida, y muchas veces contiene los secretos empresariales que pueden llevar al éxito un negocio. Estamos hablando de dinero en juego, algo apetecible por muchas personas malintencionadas.
En seguridad informática se dice que es eslabón más débil de la cadena en el ser humano. Incluso una persona con ojo entrenado contra mensajes fraudulentos puede caer facilmente y entregar sus credenciales de manera inocente. Un servicio vulnerable puede exponer datos personales, pero este no es el caso y seguro hablaré de las vulnerabilidades más fáciles de explotar en software hecho a la medida. Esta vez nos quedaremos con que hoy en día no basta un usuario, una contraseña y una autenticación de dos pasos.
En seguridad informática se habla del protocolo AAA, refiriéndose a las garantías en la autenticación (una persona dice quien dice ser), autorización (una persona cuenta con los permisos para acceder a determinado recurso), y accounting (contabilidad, el consumo de recursos de una persona). Este tipo de protocolo es básico e inflexible en un servicio cloud, por lo que no puedes protegerlo adecuadamente.
¿Consumir o no consumir servicios cloud?
Tal vez la seguridad de un servicio de repositorio cloud baste para tu trabajo. No hay que ser paranoico. Una cuenta Github bien configurada, un perfil de equipos –que ahora son gratuitos– y un control de acceso privado y básico es suficiente para satisfacer las necesidades del negocio. No está de más tomar algunas precauciones en caso que se pueda y se quiera hacer.
Aplicar algunas técnicas de protección requiere de instalar un servicio autogestionado como Gitlab, Gogs, Gerrit, entre otros. Dependiendo de la técnica a usar y las necesidades del equipo se escoge la arquitectura a aplicar.
Por ejemplo: una empresa puede limitar el acceso a sus repositorios con credenciales básicas usuario-contraseña, y adicional puede forzar el acceso por medio de VPN. Puede añadir a la capa una implementación AAA como RADIUS, y restringir acceso a ciertos tipos de recursos dependiendo de la ubicación física de la persona.
Innecesario… hasta que ocurre
A manera de conclusión quiero compartir unas anécdotas que les ocurrieron a dos conocidos. El objetivo es despertar en el lector la necesidad de preocuparse en la seguridad de la información. Ambas ocurrieron entre los años 2018 y 2019. Uno pecó por buena fe y otro por la falsa seguridad.
Un amigo me llama y me comenta que algo extraño le pasaba a los computadores de la oficina. Aparecían mensajes en inglés que le decían que estaba infectado y que debía pagar para desinfectarse, pero no podía pagar porque no sabía cómo hacerlo y no aparecía ningún teléfono a qué llamar. Yo ya estaba casi seguro por dónde iba el asunto. Le pregunté de inmediato si tenía copias de seguridad de los archivos. Él me respondió que sí, que tenía unos CD de los que le enviaba a sus clientes con los trabajos finales y una copia de una base de datos del programa de contabilidad que usaba. Lo que más le preocupaba era perder los datos de la contabilidad –y con razón–. Luego me dijo lo que confirmaría mis sospechas: sus archivos de Office no abrían, el nombre era raro ahora y no tenían más los íconos de Word ni de Excel. Yo le respondí que había sido víctima de un ransomware, y que dependiendo de qué lo hubiera infectado habría más o menos probabilidad de recuperar los datos. También le expliqué por qué pagar era una mala idea y que lo mejor que podía hacer era intentar restaurar todo lo posible con las copias de seguridad que tenía.
Al final hablamos un poco sobre qué acciones podía tomar en la empresa para que esto no volviera a suceder. Además de instalar un buen antivirus y hacer copias de seguridad periodicamente era necesario educar a los trabajadores. Según parece habían sido víctimas de un correo con un archivo adjunto malintencionado que a manera de gusano había infectado una gran parte de los computadores dela oficina, incluido el computador que usaban como servidor. Una red de computadores en LAN con características de red insuficientes había permitido la propagación del gusano. La causa principal fue un cliente que prefirió la comodidad de hacer doble clic y que abriera la carpeta sin más, a minimamente aprenderse una contraseña para acceder al otro computador. Pero esto no lo entendió hasta que le pasó.
La otra anécdota empieza con un software no optimizado que se congelaba cuando se ejecutaban consultas grandes. Me llamaron para auditar el software y proponer un plan de optimización. En esa primera llamada le comenté acerca de los problemas comunes que podían desencadenar en un software mal optimizado, y Entre ellos el de no tener un estilo ni estándar claro en el equipo de trabajo. Se volvía muy complejo hacer mantenimiento a un código heterogéneo, sin una identidad clara y sin documentación. Cuando empecé a revisar el código me topé con que en el repositorio tenían ramas incompletas y que no seguían ningún estándar. Yo extrañado le pregunté al cliente para que eran esas ramas. Él me respondió con un tono un tanto molesto, que las ramas las habían tenido que hacer porque hacía unos meses habían contratado a un programador el cual tuvo acceso a todo el código, le había sacado copia y había empezado a vender el software por aparte. No es ético, sin embargo no puedes percibir la ética de alguien a través de entrevistas ni perfiles sicológicos.
Aunque este problema no se podría haber evitado de una manera fácil, podría haberse detectado de manera temprana si se hubiera usado un repositorio autogestionado con una implementación de protocolo AAA y otras técnicas como CI/CD y staging.
Adelantarse al evento como filosofía para la prevención de riesgos
Este es el pilar de la norma ISO 27001. Se deben identificar los incidentes que podrían ocurrir. De esta manera se puede garantizar la seguridad de la información.
Este es el pegamento con el que se unen todas las piezas: cuando estás estudiando el impacto que tiene implementar o no técnicas y protocolos como AAA, ya sea por razones técnicas o comodidad-compatibilidad, te das cuenta que los servicios cloud presentan incompatibilidades y todo aquello que hagas para pasar la certificación es probablemente una solución artificial e inestable que a final de cuentas no cumplirá su verdadero objetivo.
Entonces la conclusión es que, si crees que tu código es sensible y crítico para tu empresa o tus clientes, deberás protegerlo de manera adicional implementado tu propio servicio autgestionado, y configurando el nivel de acceso dependiendo de los requisitos del equipo de trabajo.
En caso de ser freelance sin colaboradores puede ser un contenedor local.
Y obviamente: es mejor prevenir que lamentar.