J’ai récemment donné une conférence à la CNCF Security Conference North America sur le sujet de l’informatique de confiance zéro. Dans cet article, je donnerai un aperçu du contenu de cette conférence, en expliquant comment l’informatique de confiance zéro est prise en charge au niveau du module, de l’exécution, de la capacité et du cluster.
Informatique distribuée Zero Trust
J’ai pensé que ce pourrait être une bonne idée de fournir un récapitulatif et une distillation du matériel de la conférence ici. Alors que nous continuons à prêcher, WebAssembly est bien plus qu’un simple outil pour créer des applications qui s’exécutent dans le navigateur. Nous croyons tous fermement qu’il s’agit d’une technologie habilitante de nouvelle génération pour le cloud, la périphérie et partout entre les deux.
L’exploration des façons dont WebAssembly est parfait pour les environnements de sécurité zéro confiance est un voyage. Ce voyage commence au niveau le plus bas, le module (par exemple, le .wasm fichier lui-même), et continue vers des abstractions plus élevées tout au long de l’exécution et jusqu’aux réseaux wasmCloud pour la sécurité du cluster. Dans cet article de blog, nous allons parcourir ce voyage.
Sécurité des modules
Nous commençons notre voyage au bas de la pile d’abstraction : les modules. Au niveau le plus bas de la machine virtuelle wasm, il existe un certain nombre de mesures de sécurité innovantes et puissantes. Le code WebAssembly ne peut pas être exploité via RCE (Remote Code Execution), qui est souvent activé par des attaques de dépassement de mémoire tampon. Cela vient de l’incapacité innée à former des pointeurs arbitraires vers des emplacements en mémoire pour l’exécution. Le code et les données restent distincts, vous ne pouvez donc pas tromper une machine virtuelle Wasm pour qu’elle exécute des données. De plus, la sécurité du module vous empêche de sauter ou de vous brancher à un emplacement qui n’existait pas lorsque le module a démarré. Et, bien sûr, WebAssembly est entièrement en bac à sable, de sorte que l’accès à la mémoire hôte depuis l’intérieur du module est interdit, la communication étant limitée à un accès partagé à un bloc de mémoire linéaire isolée.
La chose importante à retenir à propos de la sécurité des modules WebAssembly est qu’ils arrêtent intrinsèquement une bande entière de vecteurs d’attaque potentiels. Plutôt que d’avoir à détecter les intrusions après qu’elles se produisent, WebAssembly peut rendre de nombreux types d’intrusions physiquement impossibles car le bytecode n’a même pas d’instructions pour parler aux ressources système ou se brancher sur du code prétendant être des données.
Sécurité d’exécution
Au fur et à mesure que nous montons dans le niveau d’abstraction, nous laissons de côté le fichier WebAssembly brut et examinons maintenant les applications et les bibliothèques responsables de l’exécution de bas niveau de ces modules : temps d’exécution. Dans cette catégorie de runtime, vous trouverez des outils comme wasmtime, wasm3, wasm edge, ainsi que les moteurs propriétaires utilisés par les fournisseurs FaaS/edge comme Fastly.
Un module WebAssembly peut faire rien que l’environnement d’exécution de l’hôte ne permet pas. Cette capacité pour le runtime hôte de prendre toutes les décisions de refus/autorisation pour tout ce que le module tente de faire est encore une autre couche de sécurité puissante que nous voulons généralement dans les systèmes distribués mais que nous trouvons rarement. Même dans notre monde conteneurisé actuel, notre position en matière de sécurité se limite souvent à surveiller ce que fait un conteneur et à réagir après coup. Avec WebAssembly, nous arrivons à empêcher les comportements malveillants de se produire en premier lieu.
L’extension WASI de la spécification permet aux modules de faire quelques autres choses qui leur permettent de prétendre être de vraies applications, comme communiquer avec stdout/stderr, fichier E/S, etc. Même avec cela en place, le runtime lui-même est responsable de faire le système de fichiers virtuel disponible pour le module et peut refuser toute tentative d’utilisation de tout descripteur de fichier (y compris stdout).
Sécurité des capacités
Une fois que nous avons dépassé le niveau d’exécution de base (nous l’appelons aussi souvent le niveau « moteur »), nous avons wasmCloud (qui utilise un moteur/d’exécution en interne) et notre capacité à lier de manière sécurisée et dynamique des capacités aux acteurs. WasmCloud permet de construire réel applications utilisant WebAssembly qui sont beaucoup plus prêtes pour la production et sécurisées que les modules autonomes compatibles WASI.
Avec wasmCloud, nous utilisons des jetons Web JSON signés (JWT) intégrés directement dans le module. Cela nous permet de vérifier les autorisations d’un module sans consulter une autorité centrale qui peut être usurpée ou compromise. Cela signifie que nous pouvons toujours prendre des décisions éclairées sur ce qu’un acteur peut ou ne peut pas faire dans des environnements hors ligne ou contraints ou lors d’événements de partition de réseau.
Les acteurs sont signés avec des identifiants pour les contrats de capacité auxquels ils ont obtenu l’accès, comme HTTP Server, Message Subscriberou Key Value Store. Ces capacités sont des contrats abstraits dont les implémentations sont liées au moment de l’exécution. Vous pouvez utiliser des implémentations fictives, de test ou légères lorsque vous parcourez votre boucle de développement interne sur votre poste de travail, puis passer à différentes implémentations dans des environnements supérieurs, le tout sans avoir à reconstruire ou à redéployer vos acteurs.
Étant donné que les acteurs sont signés cryptographiquement avec des clés ed25519, nous pouvons également soumettre les acteurs à des politiques qui utilisent des métadonnées telles que l’émetteur du module, sa date d’expiration, sa date « non valide avant », et bien plus encore. Nous pouvons utiliser des politiques comme celle-ci pour autoriser uniquement les acteurs d’un certain ensemble d’émetteurs de confiance, diviser les émetteurs autorisés pour la production et le développement/test, et un certain nombre d’autres mesures de sécurité supplémentaires.
Sécurité des grappes
Alors que nous continuons à monter le niveau d’abstraction à partir d’un seul hôte wasmCloud, nous pouvons ensuite examiner un cluster d’hôtes wasmCloud connu sous le nom de treillis. Dans un treillis, seuls les hôtes qui ont été autorisés à communiquer avec le cluster peuvent le faire, et les invocations provenant d’émetteurs non valides ou d’expéditeurs usurpés ou d’attaquants MITM (man-in-the-middle) peuvent toutes être rejetées.
Pour ce faire, chaque hôte d’un cluster wasmCloud génère sa propre paire de clés d’identité unique, mais reçoit également un clé de signature de cluster. Cette clé est utilisée pour signer les invocations aux acteurs et fournisseurs ailleurs dans le cluster. Ces hôtes distants recevant ces appels peuvent alors vérifier l’émetteur de cette invocation, ainsi que si les octets de l’invocation ont été falsifiés.
Étant donné que chaque hôte reçoit une clé de signature et une liste de clés publiques à approuver, le système est résilient à la plupart des formes d’intrusion. Au fur et à mesure que chaque hôte signe que chaque invocation est émise, d’autres hôtes peuvent vérifier si l’invocation provient de l’entité qui prétend l’avoir envoyée.
Résumé
En résumé, la sécurité Zero Trust utilisant WebAssembly, les runtimes WebAssembly et wasmCloud fournit un spectre dans lequel vous pouvez utiliser des stratégies de défense en profondeur. Les développeurs peuvent être sûrs que les petites charges de travail qu’ils déploient sur des applications distribuées seront sécurisées, inviolables et incapables de faire quoi que ce soit d’inattendu ou d’exiger une élévation des privilèges.
Avec WebAssembly et wasmCloud, nous pouvons empêcher les intrusions et les compromis de se produire plutôt que de devoir nous fier aux alertes après coup.