A fuerza de construir LowFlow, empezaba a tener algo que realmente se parecía a un producto.
Una aplicación local.
Datos que se quedan con el trader.
Un sistema de actualizaciones automáticas.
Un Control Panel.
Licencias.
Una infraestructura capaz de hacer que la aplicación se comunicara con mi sistema.
Todo empezaba a funcionar en conjunto.
Pero una nueva realidad se volvió evidente.
Mientras más importante se volvía el sistema, más había que protegerlo.
Al principio, no pensaba tanto en la seguridad
Cuando construía LowFlow solo para mí, la pregunta era mucho más simple.
Quería que el software funcionara.
Quería que fuera rápido.
Quería que no se cayera.
Quería añadir mis funciones.
Quería mejorar mi diario.
La seguridad no estaba en el centro de mis días.
Pero en cuanto una aplicación se convierte en un producto comercial, la situación cambia.
Ya no se trata solamente de proteger mis propios archivos, sino a los clientes, las licencias, las actualizaciones, el sistema de distribución, y la infraestructura que está detrás de todo eso.
Una aplicación distribuida ya no es lo mismo
Cuando LowFlow se queda en mi computadora, controlo todo.
Pero cuando la aplicación está instalada en la computadora de otra persona, ya no controlo directamente ese entorno.
La aplicación misma debe poder verificar ciertas cosas por sí sola.
Y mi infraestructura debe poder verificar otros elementos a distancia.
Ahí fue cuando empecé a construir varias capas de protección.
No quería poner toda la seguridad en un solo lugar.
Porque una sola protección siempre puede terminar siendo evadida.
La idea era entonces multiplicar los controles.
Proteger las licencias
Lo primero que había que proteger era evidentemente el acceso al producto.
Quería evitar que una licencia pudiera simplemente copiarse de una computadora a otra sin control.
LowFlow debía poder reconocer la instalación que usa la licencia.
Y si algo no correspondía, el sistema debía poder detectarlo.
Eso me llevó a trabajar en la identificación de la máquina y en la gestión de las transferencias.
El objetivo no era impedir que el cliente cambiara de computadora.
El objetivo era poder gestionar ese cambio correctamente.
Proteger las actualizaciones
Luego estaban las actualizaciones.
Esa se había convertido en una de las piezas más importantes del sistema.
Si LowFlow podía recuperar automáticamente una nueva versión, tenía que estar seguro de que esa versión realmente venía de mí.
Una actualización no es un simple archivo.
Es algo que va a ejecutarse directamente en la computadora del cliente.
Quería entonces que las versiones distribuidas pudieran verificarse antes de su instalación.
La distribución debía estar controlada.
El servidor también debía protegerse
Ahora tenía otro problema.
Estaba construyendo una infraestructura que debía ser accesible para la aplicación.
Pero evidentemente no quería abrir toda mi infraestructura a Internet.
Había que limitar lo que era accesible.
Limitar las funciones expuestas.
Vigilar las solicitudes.
Y sobre todo, poder saber cuándo un comportamiento no se parecía a lo esperado.
Empecé entonces a añadir controles en varios lugares.
No una sola barrera.
Varias.
La seguridad se convierte en una arquitectura
Es probablemente ahí donde mi forma de ver el proyecto cambió.
Ya no pensaba: «¿Cómo puedo asegurar LowFlow?»
Pensaba más bien: «¿Cómo puedo hacer que una sola debilidad no comprometa todo el sistema?»
Esa diferencia es importante.
La aplicación tiene sus propios controles.
El servidor tiene los suyos.
Las licencias tienen sus propias validaciones.
Las actualizaciones tienen sus propias verificaciones.
Y cierta información puede vigilarse del lado del servidor.
Todo esto funciona en conjunto.
Pero no quería convertir a LowFlow en una prisión
También había que conservar cierta simplicidad.
No quería que el trader tuviera la impresión de usar un software complicado, lleno de controles.
Simplemente debía abrir LowFlow y trabajar.
El sistema debía hacer su trabajo en segundo plano.
Esa es probablemente una de las cosas más difíciles de lograr en un software: construir algo complejo para que el usuario no tenga que ver esa complejidad.
El trader no necesita conocer los mecanismos que protegen su instalación.
Simplemente quiere que LowFlow funcione.
Y mis datos se quedan locales
A pesar de toda esta nueva infraestructura, siempre volvía al mismo principio.
Los datos del trader no se convertían de repente en míos — se quedan exactamente donde siempre han estado, en su máquina, ya sean sus operaciones, sus fotos, sus históricos o sus datos de replay.
La seguridad añadida alrededor de LowFlow no cambia esa filosofía.
Protege sobre todo al producto y su funcionamiento, no la vida de trading del cliente.
Otra lección del desarrollo
Mientras más construyo LowFlow, más descubro que cada nueva función trae consigo varias consecuencias en las que no había pensado al principio.
Quería actualizaciones automáticas.
Hubo que crear una infraestructura.
Creé una infraestructura.
Hubo que protegerla.
Añadí protecciones.
Luego había que pensar en otra cosa: cómo hacer que todo este sistema funcionara de manera suficientemente automática para que yo pudiera realmente gestionar clientes.
Porque al final de cuentas, mi objetivo no era pasar mis días detrás del Control Panel.
Quería seguir desarrollando LowFlow.
Y para eso, el sistema tenía que trabajar por mí.
El siguiente paso sería entonces el de la automatización.
Construir un sistema capaz de hacer casi todo el trabajo por sí solo.