Processus partagés pour les technologies de sécurité au niveau des paquets

Les technologies de mise en réseau et de sécurité au niveau des paquets, telles que les pare-feu à inspection d’état, IPSEC et l’équilibrage de charge, imposent des exigences de calcul plus faibles en termes de nombre de cycles d’unité centrale requis pour chaque paquet.
En outre, le traitement par paquet est très cohérent, ce qui simplifie la prédiction des performances.
Dans le paysage actuel, les fonctions de sécurité (par exemple, FWaaS) sont fournies en tant que services par des fournisseurs de services qui déploient ces fonctions dans le nuage/les points de présence (PoP).
Pour répondre aux besoins de plusieurs locataires, les implémentations technologiques de sécurité sous-jacentes s’appuient sur un modèle d’occupation VRF (Virtual Routing and Forwarding).
Dans le cadre de ce modèle, le trafic de plusieurs locataires traverse le même dispositif de sécurité ou le même conteneur/processus, ce qui permet de résoudre efficacement les problèmes liés au chevauchement des adresses IP entre les locataires.
Le trafic des locataires est identifié soit par des interfaces de tunnel, soit par d’autres mécanismes, et des configurations spécifiques adaptées à chaque locataire, telles que des politiques de sécurité propres à chaque locataire, sont alors appliquées en conséquence.
Pour atténuer tout problème potentiel de « voisinage bruyant », une limitation du débit des paquets est appliquée à l’entrée, par locataire.
Cette stratégie garantit que les performances de sécurité de chaque locataire ne sont pas affectées par les activités d’autres locataires potentiellement problématiques.
Compte tenu du traitement cohérent par paquet, la limitation du débit s’avère efficace pour garantir un traitement équitable à tous les locataires.
Une autre préoccupation importante des organisations est la fuite potentielle de données sensibles résultant de l’exploitation de vulnérabilités au sein de processus ou de conteneurs partagés par des paquets malveillants provenant d’autres locataires.
Un argument souvent présenté par les fournisseurs de services de sécurité est que le traitement par paquet est simple, ce qui réduit la probabilité de vulnérabilités et d’exploitation correspondante.
Il est vrai que les technologies de sécurité au niveau des paquets sont plus simples, et cet argument a une certaine validité.
Les deux défis mentionnés précédemment, à savoir le problème du « voisin bruyant » et les « vulnérabilités des ressources partagées », peuvent ne pas poser de problèmes significatifs pour les technologies de sécurité au niveau des paquets qui utilisent des processus partagés.
Cependant, nous pensons que ces défis peuvent être plus prononcés et plus importants pour les technologies de sécurité SASE (Secure Access Service Edge) ou SSE (Secure Service Edge).

Distinction entre la sécurité SASE/SSE et les technologies et défis liés à la sécurité au niveau des paquets

Les technologies de sécurité SASE/SSE (Secure Access Service Edge/Secure Service Edge) transcendent la sécurité traditionnelle au niveau des paquets et offrent un ensemble complet de fonctionnalités :

  • Fonctions de sécurité complètes : SASE/SSE englobe un large éventail de fonctions de sécurité, notamment IDPS (détection et prévention des intrusions), sécurité DNS, SWG (Secure Web Gateway), ZTNA (Zero Trust Network Access), CASB (Cloud Access Security Broker) avec pare-feu de réputation IP/URL/Domaine/Fichier, contrôle d’accès avec des attributs au niveau du trafic tels que URI, en-têtes de requête, en-têtes de réponse, Anti-Malware, et DLP (Data Leak Prevention).
    Le Zero Trust Networking (ZTN) dans SASE/SSE est fondamental, garantissant l’accès uniquement sur authentification et autorisation de l’utilisateur, avec un contrôle granulaire sur les ressources de l’application tout en tenant compte de l’identité et du contexte de l’appareil.
  • Inspection approfondie du contenu : Le cœur de la sécurité SASE/SSE réside dans l’inspection approfondie du contenu.
    L’utilisation de proxys qui gèrent les connexions des clients, initient les connexions des serveurs, décryptent les flux, extraient les données pertinentes du trafic, exécutent des fonctions de sécurité et empêchent la transmission de contenus malveillants.

Examinons maintenant les différences d’exécution entre les technologies SASE/SSE et les technologies de sécurité au niveau des paquets :

  • Passage d’un traitement par paquet à un traitement par session : Dans le contexte de SASE/SSE, l’exécution de la sécurité ne se fait plus au niveau de chaque paquet, mais plutôt au niveau des flux de sessions de trafic.
    Contrairement aux technologies par paquet, le nombre de cycles de calcul utilisés dans le traitement de la sécurité SASE/SSE varie d’un locataire à l’autre, pour les raisons suivantes :

    • Les fonctions de sécurité appliquées au flux de trafic peuvent varier d’un locataire à l’autre.
    • Même lorsque des fonctions de sécurité similaires sont appliquées, la nature des données échangées peut nécessiter un traitement plus intensif.
      Prenons l’exemple de scénarios impliquant la lutte contre les logiciels malveillants et la protection des données personnelles, qui nécessitent l’extraction de texte à partir de divers types de fichiers, la décompression des fichiers transférés, le déarrimage des collections de fichiers, etc.
      Certains locataires peuvent transférer des fichiers compressés, ce qui entraîne un traitement intensif et a un impact sur le débit et la latence des autres locataires.
      Le bruit généré par un locataire particulier, qu’il soit dû à une infection ou à un trafic commercial élevé lors d’un événement important, peut affecter les performances du trafic des autres locataires.
  • Traitement complexe de la sécurité : Le traitement de la sécurité SASE/SSE est intrinsèquement complexe et intègre souvent diverses bibliothèques, y compris des composants tiers et open-source.
    Ceux-ci englobent des fonctions telles que les clients OIDC (OpenID Connect), les clients Kerberos, les clients SAMLv2 pour l’authentification, les moteurs de politiques complexes pour l’application, les SDK des fournisseurs de renseignements sur les menaces, l’extraction de données, le décodage JSON/XML, le décodage base64, les moteurs de décompression de données et l’extraction de texte via des projets open-source tels que Tika, parmi d’autres pour la sécurité au niveau des données tels que l’anti-malware et le DLP.
    Cette complexité augmente la surface d’attaque pour une exploitation potentielle.
    Bien que les fournisseurs de SASE/SSE donnent la priorité à la résolution rapide des vulnérabilités, il peut s’écouler un certain temps entre l’exploitation et la résolution.
    Lorsque des processus partagés sont utilisés pour plusieurs locataires, les attaquants peuvent potentiellement exploiter les vulnérabilités et accéder à des informations sensibles non seulement du locataire visé, mais aussi des données de tous les locataires partageant ce contexte d’exécution.
  • Apportez votre propre fonction de sécurité : Bien que les services SASE/SSE offrent des fonctions de sécurité complètes, ils offrent également aux organisations la possibilité d’introduire leurs propres fonctions de sécurité à l’aide de modules Lua ou de modules WebAssembly (WASM).
    Cependant, dans de tels cas, les processus partagés posent des défis importants, car ils peuvent potentiellement conduire à l’exfiltration de données d’autres locataires s’ils ne sont pas gérés avec soin.
    La résolution de ce problème devient plus complexe lorsque des processus partagés sont utilisés, et il peut toujours y avoir des moyens potentiels de contourner ces contrôles.

En résumé, la sécurité SASE/SSE offre un cadre de sécurité complet qui va au-delà de la sécurité au niveau des paquets, mais elle introduit des complexités et des défis liés à l’utilisation variable du calcul, au traitement complexe et aux ressources partagées.
Il est essentiel de maintenir une sécurité solide dans de tels environnements pour se prémunir contre les problèmes de performance, les violations de données et les atteintes à la vie privée.

Recherchez des solutions SASE/SSE qui offrent une isolation de l’exécution

Les organisations apprécient sans aucun doute la raison d’être des fournisseurs de SASE/SSE qui emploient des processus partagés pour plusieurs locataires.
Cette approche utilise efficacement les ressources informatiques entre les locataires, contribuant ainsi à la durabilité et à la rentabilité.
Les fournisseurs de services peuvent, à leur tour, répercuter ces économies sur leurs clients.
Cependant, certains segments de l’industrie sont réticents à accepter les risques de sécurité associés à l’architecture multi-locataires et aux processus partagés.
Certaines organisations peuvent anticiper des besoins futurs pour une approche plus prudente.
Dans ce cas, les organisations doivent rechercher des services SASE/SSE qui offrent une certaine flexibilité, en proposant des options pour les processus partagés et les processus/conteneurs dédiés.
Les contextes d’exécution dédiés avec des processus/conteneurs dédiés pour le traitement du trafic peuvent répondre efficacement aux défis décrits dans la section précédente :

  • Isolation des performances : Il devient possible d’obtenir des performances déterministes sans se préoccuper des « locataires bruyants » perturbateurs.
    Avec un contexte d’exécution dédié, il est relativement simple d’allouer des ressources de calcul dédiées à des locataires individuels.
    Il est également possible de configurer des plafonds de ressources pour éviter que des voisins bruyants n’utilisent toutes les ressources des nœuds de calcul.
  • Isolation de la sécurité : Un contexte d’exécution dédié garantit que toute intention malveillante ou menace interne visant à exploiter les services SASE/SSE d’un locataire n’entraînera pas de fuite de données pour les locataires qui optent pour des contextes d’exécution dédiés.
  • Apportez votre propre fonction de sécurité » : Un contexte d’exécution dédié garantit incontestablement que les scripts Lua/modules WASM sont exclusivement exécutés dans le cadre de processus dédiés.
    Par conséquent, tout problème de traitement ou d’exfiltration de données est limité au locataire qui apporte ses fonctions de sécurité personnalisées, ce qui rassure les autres locataires à cet égard, si les fournisseurs de services n’activent cette fonction que pour les processus dédiés.

Anticiper les besoins futurs : L’importance de l’informatique confidentielle

A l’avenir, certaines organisations prennent de plus en plus conscience de l’importance croissante de l’informatique confidentielle.
Cette prise de conscience est particulièrement pertinente dans le contexte de l’inspection TLS et de la gestion de nombreuses données sensibles, y compris les secrets et les mots de passe, au sein des services SASE/SSE.
Une préoccupation récurrente concerne la possibilité que le personnel ayant accès à l’infrastructure du serveur, y compris le personnel du fournisseur de services, puisse obtenir un accès non autorisé à la mémoire des processus et des conteneurs.
En outre, même les attaquants qui parviennent à exploiter les systèmes d’exploitation des serveurs peuvent potentiellement violer la mémoire de ces conteneurs et processus.
Ce problème est encore plus aigu lorsque les services sont disponibles dans plusieurs points de présence (POP) dans différents pays, avec des niveaux variables de définitions et de mises en œuvre juridiques.
Les processeurs modernes, tels que ceux équipés d’Intel Trust Domain Extensions (TDx), offrent des fonctions avancées pour une exécution de confiance.
Ces technologies jouent un rôle crucial en garantissant que même les administrateurs de l’infrastructure ou les attaquants disposant de privilèges élevés ne peuvent pas déchiffrer le contenu de la mémoire, car il reste crypté en toute sécurité par le matériel TDx.
Les fournisseurs de SASE/SSE qui proposent des contextes d’exécution dédiés sont mieux placés que les autres pour offrir cette fonction de confidentialité essentielle.
Par conséquent, il est fortement conseillé aux organisations de considérer les fournisseurs qui offrent la flexibilité des processus partagés et des contextes d’exécution dédiés.
Cette flexibilité leur permettra d’adapter leurs stratégies d’atténuation des risques à l’avenir et de garantir le plus haut niveau de sécurité des données dans des environnements en constante évolution.

  • Blog CTO Insights

    La série de blogs Aryaka CTO Insights fournit un leadership éclairé sur les thèmes du réseau, de la sécurité et de la SASE.
    Pour les spécifications des produits Aryaka, consultez les fiches techniques d’Aryaka.