Pasé algún tiempo pensando en lo que significa permitir que el código fuera de la cadena influya en una autorización en la cadena.
Los oráculos PolicyData de Newton se compilan en componentes WASM. Durante la evaluación, los operadores ejecutan el componente, le pasan entradas estructuradas y ponen el JSON devuelto a disposición de la política Rego como datos de tiempo de ejecución bajo "data.wasm".
Al principio, me enfoqué en lo que el oráculo podía obtener.
La parte más interesante es lo que no se le permite alcanzar.
Los operadores de Newton ejecutan los componentes del oráculo a través de Wasmtime en un entorno aislado (sandbox). Las solicitudes a rangos de red privada, direcciones de loopback y direcciones link-local se bloquean. Por lo tanto, cualquier punto final HTTP que llame el oráculo debe estar disponible mediante una URL pública. El oráculo también puede incluir un esquema JSON que describa sus argumentos esperados, lo que permite detectar entradas malformadas antes de enviarlas.
Ese límite tiene sentido.
Un oráculo de políticas sigue siendo código ejecutable. Permitir que sondee servicios internos o dependa de entradas con formas poco definidas convertiría la autorización en una superficie de ataque mucho más amplia. El sandbox reduce lo que el código puede tocar, mientras que el esquema reduce lo que se espera que los llamadores le pidan procesar.
Pero algo seguía molestando.
El mismo aislamiento que hace la ejecución más segura puede hacer algunas integraciones más difíciles. Algunos sistemas de riesgo, bases de datos de cumplimiento o servicios internos de aprobación deliberadamente no se exponen mediante puntos finales públicos. Conectarles a Newton puede requerir una puerta de enlace orientada al público, una capa de acceso rediseñada o algún otro método para hacer disponible la información relevante.
Así que el límite de seguridad no elimina la confianza.
Eso lo desplaza.
El código del oráculo puede restringirse, y sus entradas pueden verificarse frente a un esquema declarado. Una solicitud HTTP no exitosa puede ser devuelta por el oráculo como datos estructurados de error, pero la política de Rego debe escribirse para negar la autorización cuando falten datos válidos o cuando exista un error.
Un fallo completo de ejecución en WASM es diferente. Newton documenta esa condición como un "DataProviderError", lo que significa que la evaluación puede fallar en lugar de simplemente producir un resultado ordinario de denegación de política.
La aplicación todavía tiene que decidir qué servicio público se encuentra más allá del sandbox y cómo se protege ese servicio.
Esa es la distinción a la que sigo volviendo.
El aislamiento protege el entorno del operador del oráculo. No protege automáticamente la política de datos externos poco fiables ni de un puente mal diseñado entre sistemas privados y acceso público.
La solidez del diseño es real porque no se le da a un código arbitrario un alcance arbitrario.
La parte que no he terminado de resolver es si este límite fomentará integraciones más limpias, o si empujará la infraestructura sensible detrás de puertas de enlace públicas que se vuelvan dependencias importantes por sí mismas.
El sandbox del oráculo de Newton reduce el riesgo en torno a los datos de política offchain, o traslada parte de ese riesgo a las interfaces públicas alrededor de las cuales las aplicaciones deben construir??
#Newt @NewtonProtocol $NEWT #NEWT $H $AIGENSYN
