Cómo incorporar la seguridad como una característica SaaS: una guía

En esta publicación, le mostraré cómo brindar una conectividad más granular y segura hacia y desde una plataforma SaaS. El resultado final es una solución integral que parece una extensión natural de la plataforma SaaS y se ofrece como una característica para planes centrados en la empresa o como un diferenciador competitivo para todos sus clientes. El tiempo total necesario para ejecutar la demostración es de sólo unos minutos. También profundizaré en lo que sucede detrás de escena para explicar cómo funciona la magia.

Primero, permítanme brindarles algunos antecedentes sobre por qué surge esta necesidad específica y resaltar las deficiencias en las implementaciones tradicionales. Porque esos viejos enfoques ya no funcionan.

Debe empezar a pensar en la seguridad como una característica. Si es vicepresidente de ingeniería, si es gerente de producto, propietario de producto, dedique tiempo a la seguridad y permita que sus desarrolladores creen una infraestructura mejor y más segura.

- Joel Spolsky , fundador de Stack Overflow

Los productos más exitosos durante la próxima década serán aquellos que se den cuenta de que los enfoques del status quo ya no son lo suficientemente buenos. Tampoco es necesario que confíe en la palabra de Joel; Lea los detalles del recientemente anunciado Private Cloud Compute de Apple. Una de las empresas más exitosas de las últimas dos décadas está dejando claro que la seguridad, la privacidad y la confianza serán un diferenciador fundamental.

Incluso discuten cómo el uso actual de protocolos como TLS no puede proporcionar las garantías de seguridad y privacidad de extremo a extremo que los clientes deberían esperar.

Trabajé conectando sistemas entre sí hace muchos años, una tarea que requirió mucha mano de obra en las primeras etapas de mi carrera. Nuestra empresa estaba creciendo y parchearíamos la sala de servidores del edificio actual con el sistema que acabamos de instalar en el nuevo edificio. La nueva oficina estaba a unas cuadras de la calle y estábamos trabajando con la empresa de telecomunicaciones local para instalar una línea dedicada.

En ese momento, conectar dos redes separadas tenía una realidad obvia y físicamente tangible.

Todos hemos superado esos días. Ahora, las pilas de tecnología modernas son más complicadas; una serie de aplicaciones interconectadas repartidas por todo el mundo, ejecutadas en la nube por las mejores empresas de productos. A lo largo de décadas, evolucionamos. Hoy en día, es raro que dos empresas distintas quieran conectar todas sus redes entre sí: son aplicaciones y cargas de trabajo específicas dentro de cada red las que necesitan comunicarse.

Sin embargo, hemos seguido utilizando enfoques antiguos como una forma de conectar nuestros sistemas de forma "segura".

El tendido real de cables se ha eliminado, pero prácticamente estamos haciendo lo mismo. Estos viejos enfoques lo exponen transitivamente a una cantidad incontable de redes, lo que constituye una enorme superficie de ataque lista para explotar.

La necesidad de conectarse a un sistema privado

Lo que la gente quiere decir cuando dice "nube" o "local" se ha vuelto borroso en las décadas anteriores. Para evitar cualquier confusión, crearé un escenario hipotético para nosotros:

• Plataforma Initech: esta es una plataforma SaaS que usted opera. Es elástico y escalable y está alojado en uno de los principales proveedores de nube. Los clientes compran la plataforma para mejorar sus procesos de DevOps, ya que proporciona visibilidad sobre una serie de métricas útiles y proporciona comentarios útiles directamente en sus flujos de trabajo de desarrollo.

• ACME Corp: Este es un gran cliente de Initech al que desea brindar soporte. Manejan una gran cantidad de infraestructura en varios lugares. ¿Es "local" en el sentido clásico de estar dentro de su propio centro de datos? ¿Está dentro de su propia VPC en uno de los principales proveedores de nube? ¡No importa! Los sistemas de los clientes se ejecutan en una o más redes que Initech no controla, a las que no tenemos acceso y a las que no se puede acceder directamente desde la Internet pública.

Participación proactiva en los flujos de trabajo de los desarrolladores

Al crear la versión inicial de la plataforma Initech, hay muchos clientes potenciales con quienes trabajar para demostrar la adecuación del producto al mercado. Se integrará con las API públicas de los principales proveedores de sistemas de control de versiones (por ejemplo, GitHub, GitLab, Bitbucket, etc.), utilizará confirmaciones/webhooks para reaccionar a eventos, insertar resultados en el flujo de trabajo y todo funcionará como se esperaba.

Esto es fantástico mientras el producto es pasivo y simplemente reacciona a eventos iniciados por alguien de ACME Corp. Muchos servicios quieren ofrecer valor evaluando los cambios externos en el mundo y siendo proactivos a la hora de impulsar mejoras para sus clientes.

Piense en los muchos servicios de escaneo de seguridad o dependencia: si hay una nueva divulgación de vulnerabilidad, quieren crear una solicitud de extracción/fusión en todos los repositorios afectados lo más rápido posible. Los servicios VCS totalmente administrados con API públicas brindan formas de habilitar esto; sin embargo, las versiones autohospedadas de estos productos no tienen una API de acceso público.

Los clientes que optan por autohospedar estos sistemas generalmente se inclinan hacia las grandes empresas, por lo que ahora nos enfrentamos a algunas decisiones difíciles: ¿Initech no puede vender su producto a estos clientes de alto valor? ¿Los clientes tienen que comprar una versión reducida del producto al que le falta una de las características más valiosas? ¿O les pedimos que reevalúen algún aspecto de su postura de seguridad y redes para darle acceso a Initech?

Acceso a datos privados

Initech necesita consultar una base de datos para mostrar su solución de informes personalizada. Este no es un problema exclusivo de Initech, ya que casi todas las plataformas de datos del cliente (CDP) o herramientas de visualización tienen el mismo problema: los clientes no quieren que sus datos privados sean accesibles desde la Internet pública, por lo que normalmente estarán en un base de datos en una subred privada.

Los problemas con nuestros enfoques actuales

Como dije antes, las pilas de tecnología moderna han evolucionado hasta convertirse en una serie de aplicaciones interconectadas. Sin embargo, la forma en que conectamos estas aplicaciones ha cambiado sólo un poco con respecto a la forma en que conectamos las redes hace décadas. Si bien estos enfoques son convenientes y familiares, nunca fueron diseñados para los casos de uso que tenemos hoy.

En cambio, están intentando hacer los ajustes más pequeños posibles en la forma en que solían funcionar las cosas para intentar acercarse a cómo necesitamos que funcionen las cosas hoy.

Poner sistemas en la Internet pública

La opción de implementación predeterminada para la mayoría de los sistemas privados es ubicarlos en una red privada, con una subred privada, sin direcciones IP públicas. ¡Hay muy buenas razones para ello! La opción más sencilla para que Initech se conecte a este sistema privado sería pedirle a ACME Corp que proporcione una dirección IP pública o un nombre de host al que se pueda acceder desde Internet.

Esto es malo.

Todas las buenas razones para colocar inicialmente un sistema en una red privada desconectada del mundo se desvanecen inmediatamente. Este sistema ahora es accesible a toda la Internet pública, lo que permite que miles de posibles piratas informáticos intenten constantemente ingresar por la fuerza bruta al sistema o simplemente hacerlo. Está a una sola credencial filtrada, CVE u otro problema de ser propietario.

Proxies inversos

Otro enfoque consiste en colocar un proxy inverso delante del sistema. No me refiero sólo a algo como nginx y HA Proxy; Existe toda una categoría de servicios alojados o administrados que también se ajustan a esta descripción.

Esto tiene la ventaja de que ACME Corp ya no coloca un sistema privado directamente en la Internet pública. El proxy inverso también agrega la capacidad de limitar o ajustar las restricciones de acceso para mitigar posibles ataques DoS. Esta es una mejora en profundidad de la defensa, pero ACME Corp todavía permite que toda la Internet pública alcance e intente atacar el proxy.

Si está comprometido, hará lo que hace un proxy: permitir que el tráfico llegue al destino previsto.

Listas de direcciones IP permitidas

Una mejora incremental es que Initech proporcione una lista de IP desde las que enviarán solicitudes y que ACME Corp administre su firewall y reglas de enrutamiento para permitir solicitudes solo desde esas direcciones IP. Aunque esto no supone una gran mejora.

En Initech, no querrás tener un acoplamiento estrecho entre las instancias de tu aplicación actual y las direcciones IP; querrá tener la flexibilidad para poder escalar la infraestructura según sea necesario sin la necesidad de informar constantemente a los clientes sobre nuevas direcciones IP.

Por lo tanto, lo más probable es que las direcciones IP pertenezcan a una puerta de enlace NAT o a un servidor proxy. ACME Corp podría suponer que bloquear el acceso a sólo una o dos direcciones IP de origen significa que sólo una o dos máquinas remotas tienen acceso a su red.

La realidad es que cualquier cosa en la red remota que pueda enviar una solicitud a través de la puerta de enlace NAT o el proxy ahora también tendrá acceso a la red de ACME Corp. Esto no permite la entrada de una sola aplicación o máquina; ha permitido una red remota completa.

Aún más preocupante es que las direcciones IP de origen están trivialmente falsificadas . Un atacante potencial podría crear una solicitud bien formada, falsificar la dirección de origen y enviar datos o instrucciones a la red de ACME Corp. Los proveedores de SaaS, incluido Initech, también inevitablemente tienen que documentar la lista de direcciones IP actuales para que haya una lista preparada de IP para intentar suplantar.

Cuanto más sofisticado sea su enfoque para el filtrado de IP, más sofisticado deberá ser un atacante para comprometerlo, pero ninguno de ellos es perfecto. He escuchado a personas afirmar en el pasado que la suplantación de IP solo es para ataques DDoS porque, en la mayoría de los casos, el atacante no puede recibir la respuesta y, por lo tanto, no puede hacer nada útil.

Piense en los sistemas que estamos conectando: ¿qué tan seguro está de que no habrá llamadas API de tipo "activar y olvidar" que no crearán, actualizarán o destruirán datos valiosos? Una buena seguridad es más que simplemente prevenir la exposición de los datos, también se trata de protegerlos y garantizar su integridad.

Si usted es un objetivo valioso, como una importante institución financiera, los atacantes tienen la motivación para utilizar enfoques como este para lanzar ataques MitM e interceptar flujos de comunicaciones . Si sus clientes y prospectos son objetivos valiosos, eso también lo convierte a usted en un objetivo valioso.

Redes privadas virtuales (VPN)

Las VPN son una solución común en muchas empresas para permitir que los empleados se conecten a la "red corporativa" cuando están fuera de la oficina. También se utilizan para permitir que otros sistemas se conecten a una red existente.

El caso de uso del que estamos hablando aquí es diferente. Se trata de permitir que dos empresas independientes, un producto SaaS y sus clientes, puedan comunicarse entre sí.

En muchos de esos casos, sólo hay un sistema en cada extremo de la conexión que debería poder comunicarse entre sí. En lugar de ello, buscamos una herramienta diseñada para conectar redes enteras. Es como ejecutar un cable de conexión virtual desde el enrutador de una empresa al enrutador de otra.

Si le pidiera que hiciera la versión física de eso, para conectar un cable desde su entorno de producción directamente al entorno de producción de otra empresa, probablemente le daría una pausa. Mucha pausa. Y por una buena razón. Pero las VPN son "virtuales" y "privadas" y tan fáciles (en comparación con tender un cable) y tan ubicuas que no le damos mucha importancia.

Si todo lo que necesitabas hacer era conectar una cosa en cada red, has utilizado un instrumento muy contundente para lo que debía ser una tarea muy precisa.

Aún puede realizar la tarea precisa utilizando una VPN, pero existen capas de controles a nivel de red y reglas de enrutamiento que debe asegurarse de que estén implementadas para cerrar todas las puertas solo a la que desea abrir en cada red. Es otro ejemplo de cómo tenemos herramientas y enfoques que son excelentes para lo que fueron diseñados, pero estamos dando pasos graduales en cómo los usamos para obligarlos a trabajar con nuestras necesidades evolucionadas.

Hacer eso de forma segura significa agregar más complejidad y esperar que obtengamos todos los detalles correctos en todas esas capas, todo el tiempo. Hacerlo mal conlleva riesgos de acceso transitivo más allá de las intenciones originales.

No puedes confiar en la red

¿Qué pasaría si le dijera que, independientemente de cuánto tiempo, personas y dinero invierta en su programa de seguridad, es casi seguro que su red está expuesta a un agujero de seguridad fácilmente explotable? …

Los datos de la industria muestran que menos del 1% de las empresas más grandes del mundo aún no han tomado medidas para proteger su red de esta amenaza nueva y emergente...

La historia nos ha enseñado que hacer lo correcto debe ser lo más fácil de hacer. Esto es particularmente crítico con los desarrolladores de software y la protección contra componentes intencionalmente maliciosos. Esta lenta curva de adopción de la tecnología de seguridad... permitió efectivamente a los malos actores ver el potencial, innovar e impulsar el espectacular crecimiento del cibercrimen.

- Mitchell Johnson , Sonatipo

El problema con cada uno de estos enfoques es que asumir que es seguro requiere muchas suposiciones adicionales: que nadie en Internet intentará comprometerlo, que puede confiar en la IP de origen de las solicitudes, que la red remota está compuesta únicamente por buenos actores. , que estas suposiciones seguirán siendo ciertas tanto ahora como indefinidamente en el futuro... y que todas estas suposiciones también son ciertas para cada red a la que se haya conectado, y cualquier red a la que se hayan conectado, y cualquier red...

Eche un vistazo a cómo se vería esto desde la perspectiva de ACME Corp:

Ya no son sólo dos redes y dos empresas conectadas entre sí; son muchas redes. Cada proveedor de SaaS tendrá su propio conjunto de servicios que utilizará, lo que lo multiplicará aún más. No sólo no puedes confiar en la red, sino que tampoco puedes confiar en la de nadie más. Cualquier participante en esta imagen es solo una mala configuración de la red o una dependencia comprometida que le impide transmitir ese riesgo a través de la(s) red(es).

¡Y esta imagen es el ejemplo más ampliado de un fractal de este problema! Al alejarse, cada proveedor estará conectado con su propio conjunto de clientes, con sus propios proveedores, con sus propios clientes... la superficie de riesgo crece exponencialmente.

Entonces, ¡resolvámoslo!

¡Podemos incorporar la seguridad como una característica de nuestro producto en cuestión de minutos! Elevaremos el nivel de seguridad proporcionando una solución más enfocada y granular. También dejaremos de imponer problemas a clientes como ACME Corp pidiéndoles que realicen cambios a nivel de red.

En lugar de eso, vamos a trasladar la conectividad segura a una preocupación a nivel de aplicación y brindaremos una experiencia de producto holística al extender la plataforma Initech a los lugares específicos donde debe estar.

El ejemplo aquí explica cómo la plataforma Initech puede establecer una conexión a un servidor GitHub Enterprise autohospedado administrado por ACME Corp. El resultado final se verá así:

¡Solo toma unos minutos hacer girar todas las piezas necesarias! Para saber cómo hacerlo, consulte nuestro recorrido por el código para crear la base de un agente autohospedado .