J’ai passé du temps à réfléchir à ce que signifie laisser du code hors chaîne influencer une autorisation on-chain.
Les oracles PolicyData de Newton sont compilés en composants WASM. Pendant l’évaluation, les opérateurs exécutent le composant, lui transmettent des entrées structurées, puis rendent le JSON retourné disponible pour la politique Rego comme des données d’exécution sous "data.wasm".
Au début, je me suis concentré sur ce que l’oracle pouvait récupérer.
La partie la plus intéressante, c’est ce qu’il n’est pas autorisé à atteindre.
Les opérateurs Newton exécutent des composants d’oracle via Wasmtime, dans un environnement sandbox. Les requêtes vers des plages de réseaux privés, les adresses de loopback et les adresses link-local sont bloquées. Tout endpoint HTTP appelé par l’oracle doit donc être accessible via une URL publique. L’oracle peut aussi être livré avec un schéma JSON décrivant ses arguments attendus, afin de détecter les entrées mal formées avant leur soumission.
Cette frontière a du sens.
Un oracle de politique reste du code exécutable. Le laisser sonder des services internes ou dépendre d’entrées faiblement structurées transformerait l’autorisation en une surface d’attaque beaucoup plus large. Le bac à sable réduit ce que le code peut toucher, tandis que le schéma réduit ce que les appelants sont censés lui demander de traiter.
Mais quelque chose continuait de me tracasser.
La même isolation qui rend l’exécution plus sûre peut rendre certaines intégrations plus difficiles. Certains systèmes de gestion des risques, des bases de données de conformité ou des services internes d’approbation ne sont pas exposés délibérément via des points d’accès publics. Raccorder Newton à ces éléments peut nécessiter une passerelle orientée vers le public, une couche d’accès repensée ou une autre méthode pour rendre les données pertinentes disponibles.
Donc, la frontière de sécurité n’élimine pas la confiance.
Il la déplace.
Le code de l’oracle peut être contraint, et ses entrées peuvent être vérifiées par rapport à un schéma déclaré. Une requête HTTP infructueuse peut être renvoyée par l’oracle sous forme de données d’erreur structurées, mais la politique Rego doit être écrite pour refuser l’autorisation lorsqu’une donnée valide manque ou lorsqu’une erreur est présente.
Un échec complet de l’exécution WASM est différent. Newton documente cette condition comme une « DataProviderError », ce qui signifie que l’évaluation peut échouer au lieu de simplement produire un résultat de refus de politique ordinaire.
L’application doit encore déterminer quel service public se trouve au-delà du bac à sable et comment ce service est protégé.
C’est la distinction à laquelle je reviens sans cesse.
L’isolation protège l’environnement de l’opérateur contre l’oracle. Elle ne protège pas automatiquement la politique contre des données externes peu fiables ou contre un pont mal conçu entre des systèmes privés et un accès public.
La robustesse de la conception est réelle, car du code arbitraire n’obtient pas une portée arbitraire.
La partie que je n’ai pas encore entièrement tranchée, c’est de savoir si cette frontière encouragera des intégrations plus propres, ou si elle poussera une infrastructure sensible derrière des passerelles publiques qui deviendront des dépendances importantes en elles-mêmes.
Le bac à sable de l’oracle de Newton réduit-il le risque lié aux données de politique hors ligne, ou déplace-t-il une partie de ce risque vers les interfaces publiques autour desquelles les applications doivent bâtir??
#Newt @NewtonProtocol $NEWT #NEWT $H $AIGENSYN
