Évolution de l’architecture SASE

Vous avez peut-être entendu parler de plusieurs principes d’architecture dans le contexte de la sécurité des réseaux en général et des SASE en particulier.
Voici quelques principes d’architecture logicielle utilisés par l’industrie dans le contexte des SASE :

• Architecture à passage unique
• Architecture à mandataire unique
• Architecture de l’exécution à l’achèvement
• Architecture évolutive
• Traitement parallèle à un seul passage Architecture
• Apportez votre propre fonction de sécurité Architecture
• Architecture native de l’informatique en nuage
• Architecture d’isolation
• L’API d’abord L’architecture
• Architecture de découpage (segmentation E2E)

Bon nombre des principes architecturaux susmentionnés ne sont pas nouveaux.
Les principes architecturaux « single-pass », « one-proxy », « single-pass-parallel-processing » et « run-to-completion » sont populaires depuis l’époque de l’UTM (Unified Threat Management) au début des années 2000, bien qu’ils aient été connus sous d’autres noms auparavant.
L’objectif principal de ces principes architecturaux est d’atteindre les objectifs suivants

• Un débit plus élevé avec une utilisation efficace des ressources.
• Diminution de la latence de bout en bout
• Gigue plus faible
• Plus grande élasticité (Scale-out) et résilience, même en cas d’attaques DDoS sur les services de sécurité
• Introduction plus rapide de nouvelles fonctions de sécurité (agilité)
• Intégration des fonctions de sécurité de plusieurs fournisseurs sans introduire d’inefficacité (intégration des meilleures technologies)
• Adoptabilité (courir partout)
• Vitrage unique

L’évolution

L’industrie de la sécurité des réseaux a ceci de formidable qu’elle est dynamique.
Il adopte des logiciels plus récents et des principes d’architecture de déploiement dans chaque nouvelle génération de produits.
Il maintient également la protection contre la sophistication des attaquants.
Cela dit, le marché de la sécurité des réseaux est traditionnellement fragmenté.
Il existe de nombreux fournisseurs de sécurité qui proposent différentes fonctions de sécurité.
C’est une bonne chose du point de vue de l’innovation, qui doit être encouragée et qui se poursuivra.
Il convient de noter qu’un fournisseur n’est pas forcément bon dans toutes les fonctions de sécurité.
Comme vous le verrez plus loin, si chaque fournisseur fournit une pile complète pour ses fonctions de sécurité, il y aura d’énormes inefficacités et, par conséquent, d’énormes implications en termes de coûts.
En outre, cela peut entraîner une plus grande latence, ce qui pourrait constituer un défi pour certaines applications.
D’où l’applicabilité de nouveaux principes d’architecture et de meilleures pratiques.
L’architecture logicielle doit être conçue de manière à éliminer les inefficacités, mais aussi à permettre l’intégration des technologies de plusieurs fournisseurs pour une cybersécurité optimale.

Avant la convergence

Les figures 1 et 2 sont deux exemples représentatifs de la sécurité des réseaux avant SASE.
La figure 1 illustre l’accès sécurisé à l’internet et la figure 2 un exemple d’accès privé sécurisé.
Notez que l’ordre des fonctions de sécurité dans ces images est arbitraire et que l’ordre d’exécution est normalement spécifique au déploiement. L’accès sécurisé à l’internet est traditionnellement réalisé à l’aide de plusieurs solutions de sécurité, comme indiqué dans la figure
1. C’est l’entreprise qui achète ces fonctions de sécurité et les place dans une chaîne de services.
Étant donné que de nombreuses fonctions de sécurité requièrent des connexions par proxy, ce chaînage est également appelé chaînage par proxy par l’industrie.
Étant donné que chaque solution de sécurité discrète est autonome et provient de plusieurs fournisseurs, la fonctionnalité commune est répétée dans toutes ces solutions.
Les fonctionnalités communes comprennent la police du trafic à l’entrée, la mise en forme du trafic à la sortie, le filtrage du trafic pour s’assurer que seul le trafic pertinent est acheminé vers les proxys, la terminaison TCP de la connexion du client, une nouvelle connexion TCP vers la destination, l’interception SSL/TLS (qui nécessite elle-même la génération de certificats à la demande émulant le certificat de destination) qui comprend le décryptage et le cryptage TLS, l’authentification par proxy (Kerberos, NTLM, OIDC), le décryptage HTTP 1.1/2.0.
Selon une estimation, cette fonctionnalité commune à chaque boîtier/appareil virtuel occupe 50 % des ressources de l’unité centrale de la solution de sécurité totale.
L’accès sécurisé aux applications est également obtenu d’une manière similaire en enchaînant les solutions de sécurité discrètes, comme le montre la figure
2. Ici aussi, la fonctionnalité commune est la même pour plusieurs solutions de sécurité.
Elle est presque identique à la fonctionnalité commune des solutions de sécurité utilisées dans l’accès sécurisé à l’internet.
Les quelques différences sont la terminaison SSL/TLS au lieu de l’interception et l’authentification de l’utilisateur par des méthodes traditionnelles au lieu de l’authentification par proxy.
Le surcoût moyen de la fonctionnalité commune d’une solution de sécurité peut représenter jusqu’à 50 % de la solution totale.
La latence due à cette architecture peut augmenter de quelques millisecondes en raison de l’enchaînement des fonctions. Un autre grand défi auquel les entreprises sont confrontées avec des appareils physiques et virtuels est celui de l’évolutivité.
À l’origine, la mise à l’échelle était assurée par l’utilisation d’appareils plus grands ou par l’attribution de ressources CPU et mémoire plus importantes aux solutions de sécurité basées sur les machines virtuelles.
C’est ce qu’on appelle la mise à l’échelle.
Si le trafic est constant, il est logique que les entreprises dépensent de l’argent pour des appliances physiques/virtuelles plus grandes.
Mais si le trafic est irrégulier, les entreprises n’aiment pas que l’on gaspille de l’argent.
Pensez aux cas où le trafic n’est plus important que quelques jours par an.
Pourquoi les entreprises voudraient-elles dépenser de l’argent pour ces fluctuations tout au long de l’année ?
Cela a conduit à l’évolution suivante, lorsque les fournisseurs de sécurité ont commencé à prendre en charge une architecture évolutive via des services fournis dans le nuage.
C’est un peu le même raisonnement que pour l’IaaS dans le monde des applications en nuage.
Dans l’architecture scale-out, davantage d’instances de solutions de sécurité sont mises en place automatiquement en cas de détection d’un trafic plus élevé ou d’une attaque DDoS, et elles sont réduites lorsque la demande diminue.
L’image 3 illustre cette architecture scale-out. Il ne fait aucun doute que la fonctionnalité « scale-out » est nécessaire.
Cependant, elle nécessite un équilibreur de charge pour chaque solution de sécurité.
Cet équilibreur de charge est nécessaire pour répartir les sessions sur plusieurs instances de la solution de sécurité.
Les traversées multiples de l’équilibreur de charge nécessitent plus de ressources et augmentent la latence de bout en bout des sessions de trafic.
La prochaine évolution de l’architecture de sécurité du réseau répond aux défis suivants

• Besoin d’un plus grand nombre de ressources informatiques
• Temps de latence plus élevé

Avec

• Une architecture de proxy unique
• Architecture à passage unique

Architecture à passage unique et à proxy unique (architecture convergente)

Comme le montre la figure 4 ci-dessous, toutes les fonctions de sécurité sont regroupées, le proxy et les autres fonctions communes n’intervenant qu’une seule fois.
Toutes les fonctions de sécurité sont appelées une à la fois de manière à ce qu’elles soient exécutées jusqu’à leur terme.
Par conséquent, cette architecture consomme efficacement les ressources informatiques.
Comme toutes les fonctions sont appelées dans le même contexte de l’espace utilisateur, les copies de mémoire sont évitées.
En outre, l’architecture à un seul processus de l’espace utilisateur réduit considérablement les changements de contexte du système d’exploitation.
Une seule instance de proxy peut traiter plusieurs sessions à la fois grâce au multithreading, chaque thread traitant un sous-ensemble de sessions, ce qui permet d’exploiter efficacement les processeurs multicœurs.
La capacité de multithreading permet également à certaines fonctions de sécurité d’être exécutées en parallèle plutôt qu’en série pour une session de trafic donnée, améliorant ainsi la latence.
Cette architecture est appelée « traitement parallèle à passage unique ». Pour faire face aux charges imprévues et aux scénarios DDoS, l’architecture auto scale-out est adoptée avec une instance d’équilibreur de charge qui intervient dans l’équilibrage de la charge des sessions. Dans cette architecture, le proxy expose une interface API.
Toutes les fonctions de sécurité s’accrochent à cette API.
Le proxy appelle les fonctions de sécurité accrochées pertinentes pendant le traitement de la session de trafic.
Toutes les fonctions de sécurité peuvent ne pas être mises en œuvre par les développeurs de solutions SASE.
Les développeurs de solutions SASE travaillent avec les fournisseurs de technologie en intégrant les moteurs et les flux des fournisseurs de technologie dans les proxys.
De cette manière, les clients des fournisseurs de SASE bénéficient du meilleur des deux mondes – des SASE très performants avec les meilleures implémentations de sécurité.
Cela dit, certains fournisseurs de technologie peuvent ne pas fournir de moteur sous forme de SDK pour développer des fonctions de sécurité dans le cadre du proxy.
Il se peut qu’ils l’aient sous forme de service en nuage.
La DLP est un exemple où de nombreux fournisseurs de technologie l’ont en tant que service en nuage.
De même, dans certains cas, il se peut que le fournisseur de solutions SASE ne souhaite pas intégrer certaines fonctions de sécurité dans le même contexte de processus de l’espace utilisateur du proxy pour des raisons telles que des contraintes de mémoire, pour éviter une incompatibilité de licence, pour éviter de fragiliser l’espace utilisateur, etc.

Architecture unifiée et fonctions de sécurité propres

L’évolution suivante de l’architecture SASE est présentée ci-dessous.
Trois points saillants sont illustrés dans la figure 6 ci-dessous. Prise en charge des services de sécurité via ICAP (Internet Content Adaptation Protocol) : Les entreprises peuvent être habituées à utiliser des services de sécurité d’autres fournisseurs de sécurité ou souhaiter le faire. Les spécifications ICAP de l’IETF précisent comment les serveurs mandataires peuvent communiquer avec des services externes d’adaptation du contenu, y compris des services de sécurité.
En autorisant les services de sécurité externes, les fournisseurs de solutions SASE permettent aux entreprises de choisir leurs propres services de sécurité. Apportez vos propres fonctions de sécurité : Selon le rapport de sécurité d’IBM intitulé « Cost of a Data Breach Report 2022 », les organisations mettent en moyenne 277 jours pour détecter et contenir une violation de données.
Bien que SASE fournisse une très bonne configuration de politique, il se peut que certaines violations de données nécessitent des règles programmatiques.
Les organisations qui analysent la violation de données sont bien placées pour élaborer ces programmes.
En fonction des fournisseurs de SASE ou de services de sécurité, les vendeurs peuvent prendre du temps, car les versions des produits doivent passer par un cycle de développement logiciel complet.
Pour éviter ces retards, les nouvelles architectures SASE permettent aux équipes de sécurité des entreprises de développer elles-mêmes des règles programmatiques et de les déployer.
Comme celles-ci ne doivent pas provoquer d’instabilité dans le proxy, les architectures SASE fournissent des runtimes WASM pour permettre la création de règles programmatiques en tant que modules WASM.
Comme le runtime WASM agit comme un bac à sable, tout problème avec les modules WASM n’entraîne pas le plantage ou la mort de l’espace utilisateur hébergeant et d’autres plugins de fonctions de sécurité. Proxy unifié : Un proxy unifié pour l’accès sécurisé à l’internet et l’accès sécurisé aux applications peut réduire les besoins en mémoire.
Les moteurs et les flux de certaines fonctions de sécurité, comme l’anti-malware et le DLP, consomment beaucoup de mémoire.
La mise en place de deux instances de proxy différentes pour chaque site d’entreprise peut donc s’avérer coûteuse.
De plus, le fait d’avoir un seul proxy supportant les trois modes (avant, arrière et transparent) est une bonne pratique de développement du point de vue de la productivité du développeur également.

Les autres principes d’architecture suivis dans la nouvelle génération d’architecture SASE sont les suivants

Natif du nuage : Comme nous l’avons vu dans le SASE universel de ce billet, les services SASE sont nécessaires sur site, dans les nuages et à la périphérie.
Par conséquent, les architectures SASE de nouvelle génération suivent les principes « Cloud native » pour que le SASE fonctionne partout.
Bien que Cloud native et Kubernetes ne soient pas synonymes, les solutions dites Cloud native sont souvent basées sur Kubernetes.
La raison pour laquelle on choisit de faire fonctionner les solutions sur Kubernetes est que tous les fournisseurs de services en nuage/de pointe offrent Kubernetes en tant que service et, plus important encore, que l’interface API est conservée intacte par les fournisseurs de services en nuage/de pointe.
Grâce à la cohérence de l’interface API de Kubernetes entre les fournisseurs de cloud/edge, les solutions SASE basées sur K8s fonctionnent de manière transparente entre les fournisseurs de cloud/edge. Architecture d’isolation : Les architectures SASE actuelles, pour des raisons d’efficacité, permettent à plusieurs sessions de locataires de passer par des processus d’espace utilisateur partagés.
Des méthodes astucieuses sont utilisées pour garantir le maintien d’un certain niveau d’isolation, même si les adresses IP des locataires se chevauchent.
Les processus de l’espace utilisateur partagé pour plusieurs locataires ne sont pas une bonne chose du point de vue des performances et de l’isolation de la sécurité.
Avec des ressources partagées, il est possible qu’un mauvais comportement, tel qu’une attaque DDOS sur un locataire, puisse causer des problèmes de performance dans le trafic des autres locataires.
De même, tout exploit sur le processus de l’espace utilisateur partagé peut exposer tous les secrets/mots de passe/clés de tous les locataires.
Compte tenu de ce qui précède, les architectures SASE de nouvelle génération s’orientent de plus en plus vers des instances proxy dédiées, soit via des processus user space dédiés, soit via des conteneurs dédiés. Architecture API first : Les solutions SASE actuelles fournissent un CLI et un portail pour la configuration et l’observation.
Certaines solutions SASE utilisent des API entre le CLI/Portail et les systèmes de gestion dorsaux, mais elles ne sont pas annoncées.
Dans certains cas, les API n’auraient pas été propres.
Les nouvelles solutions SASE adoptent l’architecture API first où les API sont définies non seulement pour les implémentations CLI et Portal mais aussi pour les tierces parties afin de développer des entités programmatiques externes.
Les API permettent d’utiliser SecOps-as-code via terraform et d’autres, du simple développement de scripts au développement de flux de travail complexes.
La pratique générale est d’opter pour une API RESTful, des charges utiles JSON avec une documentation basée sur OpenAPI, mais certains exposent également des ressources personnalisées Kubernetes pour configurer des objets et des politiques de sécurité et de mise en réseau.
L’architecture API First est également censée séparer la logique backend réelle de la mise en œuvre du RBAC (contrôle d’accès basé sur les rôles).
L’expérience de l’industrie montre qu’il existe un grand nombre de vulnérabilités lorsque le RBAC et la logique commerciale sont combinés.
Par conséquent, l’industrie s’oriente vers la séparation de la fonctionnalité RBAC vers des entités externes et laisse les applications se concentrer sur la logique d’entreprise.
La même logique est appliquée aux systèmes de gestion SASE, qui se concentrent sur les politiques/objets SAE et l’observabilité et laissent la fonctionnalité RBAC à des entités externes telles que les proxys d’entrée et les passerelles API.
Les mandataires d’entrée se chargent de l’authentification, de l’autorisation et de l’acheminement de l’API.
Ce qui est intéressant, c’est qu’un seul proxy d’entrée peut servir de façade à plusieurs applications.
De ce fait, les utilisateurs administrateurs ne doivent se familiariser qu’avec une seule entité RBAC pour plusieurs applications. Pour cette séparation de la logique d’entreprise et du RBAC, les solutions d’architecture API-first sont censées suivre certaines lignes directrices.
Par exemple, de nombreux proxys d’entrée et passerelles API s’attendent à ce que l’URI soit utilisé pour pointer vers une ressource pour le RBAC.
Dans le cas de l’automatisation basée sur le flux de travail, on s’attend à ce que les systèmes de gestion puissent étiqueter la configuration et restaurer les anciennes étiquettes pour permettre des modèles de saga.
Toute architecture API-first doit suivre les meilleures pratiques de l’industrie.

Résumé

Les architectures de sécurité des réseaux évoluent d’entités physiques/monolithiques vers des appliances virtuelles et des conteneurs.
De nombreux principes « cloud-native » qui sont devenus populaires dans le monde des applications sont adoptés dans les solutions SASE pour obtenir des avantages similaires à ceux du « cloud », y compris le « scale-out/in », l’agilité, le multi-cloud / edge ready, et l’utilisation efficace des ressources à travers de multiples locataires.
Surveillez cet espace pour connaître les nouveaux principes d’architecture et la façon dont Aryaka exploite les technologies de type cloud.

• 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.