Wasm para complementos y sandbox: ejecutar código de terceros de forma segura

Toda plataforma exitosa llega a un punto en el que necesita permitir que otros escriban código que se ejecuta en ella. Complementos de usuario, funciones de cliente empresarial personalizadas, extensiones de socios, reglas comerciales enviadas a través de API. El problema es siempre el mismo: ¿cómo ejecutas código que no escribiste, en la infraestructura que controlas, sin convertir esa apertura en una vulnerabilidad? Las respuestas tradicionales son costosas, lentas o frágiles. WebAssembly ofrece una respuesta diferente, y comprender por qué requiere comprender qué dificulta el problema.

Por qué las soluciones tradicionales no escalan

El primer intento de muchos equipos es eval() o equivalente: ejecutar la cadena de código directamente en tiempo de ejecución. Es rápido de implementar y catastrófico de mantener. El código del complemento tiene acceso a todo lo que tiene el proceso host: memoria, red, sistema de archivos. Un complemento malicioso o simplemente defectuoso puede interrumpir todo el proceso o filtrar datos de otros inquilinos.

El segundo intento es un microservicio complementario: cada extensión se ejecuta en un contenedor aislado. Funciona desde el punto de vista de la seguridad, pero el costo operativo crece linealmente con la cantidad de complementos. Mantener un contenedor por cliente es inviable en plataformas con cientos de extensiones. La latencia de cada llamada entre contenedores también penaliza las operaciones que deberían ser inferiores a un milisegundo.

Los procesos secundarios con espacios de nombres de Linux son otra opción: más livianos que los contenedores, pero con la sobrecarga de inicialización y la complejidad de seccomp y cgroups para garantizar un verdadero aislamiento. Requiere un equipo que comprenda profundamente el modelo del kernel. El problema común con todos estos enfoques es que tratan el aislamiento como algo externo: se construye una valla alrededor del código que no es de confianza utilizando mecanismos del sistema operativo. Wasm invierte esta lógica.

El modelo de capacidades: cero por defecto

Un módulo WebAssembly comienza sin capacidades. Literalmente ninguno. No puede abrir un archivo. No se puede realizar una solicitud de red. No se pueden leer variables de entorno. No puede acceder a ningún byte fuera de su propia memoria lineal. Si el módulo intenta cualquiera de estas operaciones sin que el host haya hecho disponible explícitamente la interfaz correspondiente, la operación falla, no en tiempo de ejecución con una excepción, sino estructuralmente, porque la función que llama el módulo simplemente no existe en el entorno de ejecución.

Esto se denomina seguridad basada en capacidades y es conceptualmente diferente del modelo de autoridad ambiental que hereda el código nativo. Cuando carga una biblioteca nativa, se ejecuta con privilegios de proceso completos. Cuando carga un módulo Wasm, se inicia sin ningún privilegio y usted, como anfitrión, decide qué entregar.

La interfaz de seguridad está en el código de integración del host. Expone al módulo exactamente las funciones que tienen sentido: acceso a la API del lienzo de Figma, pero no al sistema de archivos; acceso a los datos de pedidos de Shopify, pero no a las credenciales de la base de datos. El módulo hace todo lo que le permitiste hacer y nada más. La superficie de ataque se establece explícitamente, no se infiere.

Cómo lo usan las plataformas reales

Figma es el ejemplo más conocido. El sistema de complementos ejecuta cada complemento dentro de un entorno limitado de Wasm. El complemento recibe acceso a la API del lienzo (puede leer y modificar elementos, crear capas, acceder a propiedades de texto), pero no tiene acceso a nada fuera de ese contrato. Un complemento no puede leer archivos del sistema operativo ni realizar llamadas de red arbitrarias. Esta no es una política de uso; Es una imposibilidad técnica. Es por eso que puedes instalar un complemento Figma de un desarrollador desconocido con una confianza razonable de que no filtrará tus archivos.

Shopify tomó una decisión similar a Shopify Functions: los comerciantes envían la lógica personalizada para descuentos, validación de carritos y reglas de envío como módulos Wasm. Cada invocación recibe los datos de la solicitud, se ejecuta dentro de límites estrictos de CPU y memoria por llamada y devuelve el resultado. Un comerciante con un código mal escrito no bloquea la plataforma ni accede a datos de otros comerciantes.

Envoy Proxy utiliza el mismo modelo para filtros de tráfico personalizados. Las empresas que operan Envoy como proxy (Istio y AWS App Mesh son ejemplos) pueden escribir filtros Wasm que procesen solicitudes y respuestas en tránsito. El filtro tiene acceso a los encabezados y al cuerpo, pero nada al estado interno del proxy. Extensibilidad sin abrir el núcleo del sistema. Los motores de juego llegaron al mismo modelo a través de caminos independientes: los sistemas de modificación que permiten a los jugadores agregar contenido necesitan ejecutar código de extraños sin comprometer el juego anfitrión, y Wasm resuelve esto con el mismo mecanismo de capacidades.

El costo para quienes escriben complementos.

Esta seguridad tiene un precio. Escribir un complemento para una plataforma basada en Wasm es más difícil que escribir JavaScript o Python.

La primera fricción es la cadena de herramientas: compilar para Wasm requiere un compilador compatible: Rust y C/C++ tienen soporte maduro, Go tiene soporte experimental, Python y Ruby llegan con limitaciones. El segundo es el acceso al sistema: dentro del sandbox, no hay acceso directo a nada más que lo que el host ha expuesto. Las bibliotecas que realizan llamadas HTTP directas no funcionan si el host no ha puesto a disposición la interfaz correspondiente. Esto obliga a una disciplina de diseño que puede resultar frustrante al principio.

Por el lado de la plataforma, la complejidad radica en definir bien la API expuesta al módulo. Una API mal diseñada es demasiado restrictiva (los complementos no hacen lo que necesitan) o demasiado permisiva, comprometiendo la seguridad. Este contrato es un trabajo de producto y seguridad tanto como de ingeniería.

¿Cuándo tiene sentido invertir en este modelo?

La decisión tiene un perfil claro. Tiene sentido cuando estás creando una plataforma con desarrolladores externos cuya calidad del código no puedes garantizar. Tiene sentido cuando necesita personalización por inquilino con límites de recursos individuales: cada cliente tiene su lógica, pero ninguno monopoliza la CPU o la memoria. Tiene sentido cuando distribuye código que se ejecutará en una infraestructura que no controla por completo.