Pourquoi la sensibilisation à l’identité dans les SASE ?
Mon blog précédent sur le décryptage du SASE traitait de la prise en compte de l’identité dans les différents composants de sécurité du SASE.
Ce billet décrit les différentes méthodes permettant de réaliser un SASE tenant compte de l’identité.
Les contrôles d’accès dans la sécurité traditionnelle centrée sur le périmètre sont définis à l’aide d’adresses IP et de services.
Les clients sont représentés par des adresses IP dans les politiques d’accès, et les services sont définis soit par des noms de domaine et des adresses IP, soit par des ports TCP/UDP tels que le port 80 pour HTTP et 443 pour HTTPS, etc.
Étant donné qu’il existe différents types de clients – utilisateurs humains accédant aux services via des PC/ordinateurs portables/mobiles, applications clientes, appareils IoT, et diverses catégories d’utilisateurs humains, une approche de segmentation avec chaque segment représentant divers types de clients est inventée.
Chaque segment se voit attribuer son propre sous-réseau ou sa propre plage d’adresses IP.
Cela permet de définir des contrôles d’accès pour différents types de clients.
Bien que cette approche ait permis de résoudre certains problèmes liés à la définition des contrôles d’accès pour les différents clients, elle a introduit une autre série de complexités : la gestion des segments.
Rapidement, de nombreuses organisations ont commencé à constater l’explosion du nombre de segments.
Les organisations ont commencé à voir la nécessité de créer différents segments pour définir une qualité de service différenciée, une sélection de liens WAN et différents types de contrôles d’accès de sécurité.
Un autre grand défi de la segmentation est lié au « travail de n’importe où« .
En d’autres termes, l’adresse IP de l’utilisateur change constamment en fonction de l’endroit d’où il travaille.
Dans ce cas, l’association de l’utilisateur à un segment devient rapidement un grand défi.
Les utilisateurs travaillant dans des bureaux désignés, à domicile, dans des cafés, dans un autre bureau ou dans des bureaux partenaires doivent être traités de la même manière, quel que soit l’endroit d’où ils travaillent.
Le SASE sensible à l’identité simplifie la gestion des segments en supprimant la nécessité de créer des segments pour différencier les clients, du moins pour les utilisateurs humains.
Vous ne pouvez cependant pas vous débarrasser complètement des segments pour les clients tels que les appareils IoT.
Le SASE sensible à l’identité est également nécessaire pour la « criminalistique numérique ». En cas de violation de données, il est important de savoir ce qui s’est passé pendant l’attaque afin de comprendre l’approche utilisée par les attaquants, les points faibles exploités et d’identifier l’impact global.
Selon le « 2022 Verizon Data Breach Report« , 82 % des violations de données impliquent l’élément humain.
Par conséquent, l’identité de chaque connexion/session devient extrêmement importante pour comprendre les schémas d’accès, les sites visités, les appareils et les applications utilisés par l’utilisateur qui ont entraîné la première infection.
Cela peut ensuite aider à découvrir les attaques latérales qui ont finalement abouti à la brèche.
En résumé, la sensibilisation à l’identité dans les SASE aide à :
- Définition de politiques d’accès différenciées à travers le pare-feu, le SWG, le CASB et le ZTNA pour différents utilisateurs
- Définition de politiques de réseau différenciées en matière de qualité de service et de routage pour divers utilisateurs
- L’informatique légale
- Analyse du comportement des utilisateurs
Identité dans les politiques SASE
Les composants du SASE contrôlent l’accès à divers services/sites à différents niveaux de granularité.
Le pare-feu de SASE contrôle l’accès aux couches L3/L4.
SWG contrôle l’accès au niveau des URL.
ZTNA et CASB contrôlent l’accès au niveau des API.
SWG, ZTNA et CASB avec DLP peuvent contrôler l’accès au niveau des données.
Tous ces contrôles sont nécessaires avec l’utilisateur comme l’un des sélecteurs pour les raisons expliquées ci-dessus et pour répondre aux directives de confiance zéro spécifiées par le NIST.
Toute politique de contrôle d’accès contient un ensemble de règles, principalement des règles ordonnées.
Ces règles sont vérifiées pour chaque session de trafic.
Si la règle correspond, les actions spécifiées dans la règle correspondante sont exécutées.
Les actions typiques comprennent l’autorisation du trafic, le refus du trafic ou simplement la surveillance et l’enregistrement du trafic.
La correspondance d’une règle se fait à l’aide d’un ensemble d’attributs.
Chaque règle est spécifiée avec les valeurs de ces attributs.
Ces attributs comprennent traditionnellement 5 tuples (IP source, IP destination, protocole, port source et port destination), des zones et des emplacements.
Lors d’une nouvelle session de trafic, les valeurs sont extraites du paquet et du contexte (zone, emplacement) et mises en correspondance avec les valeurs des attributs de la règle.
Si elles correspondent, la règle est considérée comme correspondante.
Dans le cadre du SASE avec prise en compte de l’identité, les attributs de correspondance des règles incluent les attributs de l’utilisateur.
Ces derniers peuvent être un ensemble de noms d’utilisateurs individuels, de groupes d’utilisateurs, de rôles d’utilisateurs, de noms de sujets de certificats de clients ou de noms alternatifs de sujets de certificats.
La mise en correspondance des règles doit inclure la mise en correspondance avec le contexte de l’utilisateur pour le SASE basé sur l’identité.
La correspondance typique des politiques sur une nouvelle session de trafic est la suivante :
- Extrayez 5 tuples (adresse IP source, adresse IP destination, protocole IP, port source et port destination) du paquet.
- Obtenez la zone source et l’emplacement d’où provient la session de trafic.
- Obtenez les informations sur l’utilisateur (nom, groupe d’utilisateurs et rôle de l’utilisateur) qui a initié la session de trafic.
- Obtenir la position de l’appareil d’où provient la session de trafic.
- Parcourez les règles de haut en bas de la politique en faisant correspondre les informations extraites ci-dessus avec les valeurs des attributs de correspondance des règles.
S’il y a correspondance, prenez l’action spécifiée dans cette règle.
Sinon, passez à la règle suivante. - S’il n’y a pas de règle correspondante, l’action configurée pour ce niveau de table de politique est prise en compte.
Identification et authentification de l’utilisateur
Étant donné qu’un utilisateur doit être identifié avant tout contrôle de politique sur les sessions de trafic, quelques questions se posent :
- Comment SASE authentifie-t-il les utilisateurs ?
- Comment SASE identifie-t-il l’utilisateur lorsqu’il reçoit le trafic ?
Avant d’en arriver là, voyons quelques-unes des considérations que les solutions SASE doivent prendre en compte.
SASE doit prendre en compte les types de clients suivants :
- Utilisateurs humains utilisant des navigateurs pour accéder aux services
- Utilisateurs humains utilisant des applications autres que les navigateurs pour accéder aux services
- Applications non-browser qui fonctionnent sans intervention humaine pour accéder aux services
- Applications non-browser avec épinglage de certificats CA
- Dispositifs IoT accédant aux services
Il en résulte que les solutions SASE ne peuvent pas partir du principe que ce sont toujours des utilisateurs humains qui initient les sessions de trafic.
Il peut y avoir des entités et des dispositifs programmatiques qui initient les sessions de trafic. SASE est censé servir les deux types de clients, et les solutions SASE supportent donc plusieurs méthodes d’authentification.
SASE doit prendre en compte les défis suivants en matière d’expérience utilisateur :
- Expérience utilisateur où les utilisateurs humains ne voient pas ou moins d’écrans contextuels pour la saisie des données d’identification de l’utilisateur.
- Expérience de l’utilisateur : les utilisateurs humains sont informés des raisons pour lesquelles un accès particulier leur est refusé.
- Les utilisateurs se servent de leurs propres appareils pour accéder aux services
- Utilisateurs utilisant des dispositifs gérés par l’employeur pour accéder aux services
- Une expérience uniforme pour les utilisateurs, qu’ils travaillent à domicile ou au bureau
Compte tenu de ces exigences et implications, les solutions SASE mettent en œuvre différents modes d’authentification.
La plupart des modes d’authentification supportés par les solutions SASE sont listés ici.
- Authentification par proxy inverse
- Authentification du proxy de transfert
- Authentification par portail
- Authentification du tunnel
- Authentification du certificat du client
- Authentification basée sur une clé API
Une fois que les clients se sont authentifiés auprès du SASE par l’intermédiaire de ce qui précède, le SASE doit disposer d’un moyen d’associer les sessions de trafic initiées par l’utilisateur à l’utilisateur approprié.
Deux approches de mappage d’identification sont utilisées.
Elles sont les suivantes :
- Cartographie des jetons : Les solutions SASE identifient l’utilisateur à partir du jeton d’authentification/d’identité/de porteur dans les en-têtes de requête des sessions de trafic HTTP/HTTPS.
Les clients reçoivent des jetons dans le cadre de l’authentification et le même jeton est présenté par les clients dans les sessions de trafic. - Mappage IP représentatif : Dans cette approche, l’adresse IP représente l’utilisateur.
Les solutions SASE utilisent l’adresse IP source de la session de trafic pour identifier l’utilisateur.
Lorsqu’un utilisateur s’authentifie pour la première fois avec succès auprès du SASE, ce dernier enregistre l’adresse IP de l’utilisateur.
Toutes les sessions de trafic ultérieures provenant de cette adresse IP sont alors associées à l’utilisateur.
Les jetons ne sont valables que pour les sessions de trafic HTTP/HTTPS.
Étant donné que les jetons sont présents dans chaque session HTTP, soit directement, soit indirectement par l’intermédiaire de cookies, ils sont considérés comme plus sûrs que l' »adresse IP représentative » Pour les sessions de trafic non HTTP/HTTPS, les solutions SASE utilisent le mappage de l' »adresse IP représentative ».
Notez que la méthode de mappage « IP représentative » présente quelques difficultés car l’adresse IP est utilisée par toutes les applications de la machine. En d’autres termes, même si l’utilisateur d’un navigateur est authentifié auprès de la solution SASE, non seulement le navigateur mais aussi toutes les autres applications clientes fonctionnant sur la machine auront le même accès. Dans le cas de systèmes multi-utilisateurs, tous les utilisateurs de ce système auront accès même si un seul utilisateur s’authentifie avec succès auprès de la solution SASE. Le danger est encore plus grand si le système utilisé pour s’authentifier auprès du système SASE se trouve derrière un dispositif NAT. Tous les utilisateurs situés derrière cette adresse IP NAT auront accès au système. Il est donc particulièrement important de n’utiliser la fonction « Representative IP » qu’en cas de nécessité et d’essayer de limiter ce mappage aux sessions non HTTP/HTTPS.
Étant donné que le jeton (via l’en-tête proxy-authorization ou l’en-tête authorization ou via le cookie) fait partie de chaque requête HTTP, seule l’application cliente authentifiée par la solution SASE peut envoyer le jeton.
Les autres applications clientes basées sur le web qui ont besoin d’un accès sont censées s’authentifier auprès de la solution SASE pour obtenir l’accès.
En raison des avantages en termes de sécurité, il est fortement recommandé d’utiliser l’approche du mappage de jetons pour toutes les sessions HTTP/HTTPS.
Authentification et identification de l’utilisateur par les différents composants du SASE
De nombreux composants SASE qui assurent la sécurité des applications/services web tendent à identifier et à associer les utilisateurs aux sessions de trafic via des jetons dans les en-têtes de requête HTTP, des certificats clients ou des clés API.
Les sections suivantes fournissent une correspondance entre les modes d’authentification pertinents et les meilleurs modes d’authentification et les divers composants SASE.
ZTNA
ZTNA, comme indiqué dans ce blog précédent, est destiné à protéger les applications d’entreprise contre les clients malveillants et infectés.
ZTNA, par le biais de services d’application frontaux, offre les fonctionnalités suivantes.
- Sécurité TLS/SSL pour les applications non TLS/SSL et pour les applications qui ne prennent pas en charge des algorithmes de cryptographie puissants
- Support d’accès RBAC / Least Privilege pour les applications qui ne supportent aucun RBAC et pour les applications qui requièrent un RBAC de second niveau
- Gestion de l’accès aux privilèges avec un niveau supplémentaire de MFA
- Répartition de la charge du trafic entre plusieurs instances d’application
- WAF et protection des applications contre les menaces au niveau de l’API
Le ZTNA devient de plus en plus une nécessité car il retire la responsabilité de la sécurité aux services d’application.
Les avantages qui en découlent sont une augmentation de la productivité du développement des applications d’entreprise, une configuration uniforme de la sécurité dans plusieurs services d’application et une réduction de la surface d’attaque.
ZTNA est principalement destiné à sécuriser les applications basées sur le web.
Les développeurs d’applications ne créent pas seulement de nouvelles applications avec des protocoles web, mais les applications existantes sont également webifiées pour tirer parti des innovations qui se produisent sur les protocoles web.
Même les protocoles d’administration traditionnels tels que SSH sont en train d’être webifiés grâce à des projets tels qu’Apache Guacamole.
Cela dit, il y aura toujours des applications non web.
Un pare-feu intégré à SASE fournit un contrôle d’accès et une protection contre les menaces pour les services non web instanciés par l’entreprise.
Veuillez consulter la section sur les pare-feux pour plus de détails. Comment ZTNA obtient-il l’accès au trafic ? Le ZTNA accède au trafic de deux manières : par la méthode DNS et par la méthode du proxy transparent.
Les administrateurs des applications d’entreprise configurent les serveurs de domaine faisant autorité pour qu’ils pointent vers le ZTNA pour les applications.
En d’autres termes, les administrateurs configurent les serveurs DNS pour qu’ils répondent par des adresses IP ZTNA aux requêtes DNS sur les FQDN des applications.
Dans la méthode du proxy transparent, ZTNA est censé être dans la ligne de trafic, ou une entité dans la ligne de trafic est censée intercepter le trafic et l’envoyer à ZTNA.
Les administrateurs d’applications configurent également ZTNA avec des paires certificat TLS/SSL/clé privée au nom des services d’application. Comment ZTNA authentifie-t-il les utilisateurs et associe-t-il les sessions de trafic aux utilisateurs ? ZTNA prend en charge les modes d’authentification par proxy inverse, par certificat client et par clé API pour authentifier différents types de clients – utilisateurs humains et entités programmatiques.
Le fonctionnement est le suivant :
- ZTNA met fin à la connexion TLS/SSL
- Si le certificat du client est négocié, il le valide.
S’il est valide, il extrait le nom du sujet du certificat et le SAN (Subject Alt Name).
Il s’agit des identités de l’utilisateur du client.
Si un groupe d’utilisateurs ou un rôle est provisionné, il extrait les informations relatives au groupe et au rôle de la base de données provisionnée. - Si le client présente la clé API, il se réfère à la base de données interne (provisionnée) pour extraire l’identité de l’utilisateur.
Si un groupe ou un rôle d’utilisateur est provisionné, il extrait les informations relatives au groupe et au rôle de la base de données provisionnée. - Si la requête HTTP est associée à un jeton d’authentification/d’identité, cela signifie que l’utilisateur a été authentifié auparavant.
Cela signifie également que le contexte de l’utilisateur (nom d’utilisateur, groupe d’utilisateurs et rôle de l’utilisateur, le cas échéant) est connu du ZTNA. - Si le jeton n’est pas valide ou s’il n’y a pas de jeton, il demande à l’utilisateur de s’identifier et de s’authentifier via l’OIDC.
Le courtier OIDC de ZTNA peut, à son tour, utiliser divers protocoles d’authentification pour permettre à l’utilisateur de s’authentifier auprès des services d’authentification de l’entreprise.
Pour les comptes privilégiés, ZTNA effectue sa propre MFA pour s’assurer que l’utilisateur est bien un utilisateur authentique. - Si l’utilisateur est authentifié avec succès, le composant OIDC de ZTNA établit le jeton d’identité.
Il note également les informations relatives à l’utilisateur (nom d’utilisateur, groupe d’utilisateurs, le cas échéant, et rôle de l’utilisateur, le cas échéant). - ZTNA établit alors une connexion avec l’une des instances du service d’application.
- Il prend des décisions de contrôle d’accès basées sur l’utilisateur pour chaque transaction HTTP.
- Si ZTNA est configuré pour une protection avancée contre les menaces, il analyse également le trafic à la recherche d’exploits, de logiciels malveillants et de fuites de données sensibles.
L’utilisateur n’est invité à fournir des informations d’identification qu’une seule fois, jusqu’à ce que le jeton d’identité expire.
En raison de la politique de même origine des clients, ceux-ci présentent toujours le bon jeton d’identité dans les transactions HTTP vers les services d’application.
Si le jeton d’identité est valide, ZTNA utilise cette information pour associer la session au bon utilisateur.
GTS et CASB
Le composant SWG empêche les utilisateurs de visiter des sites malveillants, des sites d’hameçonnage et des sites non sécurisés.
Il empêche également les applications clientes de contacter les sites de botnet C&C en cas d’infection.
En outre, SWG permet de fournir un accès différencié à divers sites en fonction du rôle de l’utilisateur dans l’organisation et du groupe auquel il appartient.
SWG enregistre également les métadonnées de la session de trafic ainsi que les informations relatives à l’utilisateur, ce qui peut contribuer à diverses analyses et à la criminalistique numérique.
Le composant CASB protège les données d’entreprise conservées par les fournisseurs SaaS en veillant à ce que seuls les bons utilisateurs accèdent aux données et les modifient à l’aide d’un contrôle d’accès au niveau de l’API pour diverses applications SaaS.
CASB, tout comme SWG, enregistre également les métadonnées de l’API avec les informations sur l’utilisateur à des fins d’analyse et de criminalistique numérique.
Les composants SWG et CASB nécessitent l’inspection du trafic HTTP/HTTPS des utilisateurs vers les sites Internet.
SWG et CASB mettent fin aux connexions des clients, interceptent le protocole SSL si cela est autorisé et procèdent à une inspection plus approfondie du contenu afin de détecter et de prévenir les logiciels malveillants et d’empêcher toute fuite de données sensibles. Comment les SWG et la CASB ont-ils accès au trafic ? Le proxy SWG & CASB s’empare du trafic par le biais de deux méthodes – la méthode proxy/PAC et la méthode transparente.
Dans la méthode Proxy/PAC, les machines/applications clientes sont soit configurées manuellement avec les paramètres du proxy, soit auto-configurées par les applications clientes via la découverte automatique des proxys.
Une fois que les applications clientes connaissent les serveurs mandataires, elles utilisent la méthode HTTP CONNECT pour tunneliser les sessions de données, qui sont normalement des transactions HTTP et HTTPS.
L’URI de connexion HTTP indique la destination prévue des transactions internes HTTP et HTTPS.
Le proxy utilise cette URL pour établir la connexion avec le site de destination.
Les proxys exécutent tous les services de contrôle d’accès et de protection contre les menaces avant de permettre aux données de passer des clients aux serveurs et vice-versa.
Dans la méthode du proxy transparent, les clients n’ont pas connaissance des proxys.
On s’attend à ce que les proxys soient dans la ligne du trafic pour s’en emparer. Comment le proxy SWG/CASB authentifie-t-il les utilisateurs et associe-t-il les sessions de trafic aux utilisateurs ? Si la méthode proxy/PAC est utilisée pour atteindre le proxy SWG/CASB, les proxys ont la possibilité d’authentifier les utilisateurs dans le cadre de la transaction HTTP CONNECT.
C’est ce que l’on appelle « l’authentification par procuration ».
L’authentification forward proxy basée sur HTTP CONNECT est très bien décrite ici.
Bien que ce lien décrive l’authentification NTLM, un flux similaire est également applicable à l’authentification Kerberos.
Comme HTTP CONNECT précède chaque session de trafic HTTP/HTTPS, l’utilisateur est connu du proxy à chaque session.
L’avantage de cette méthode est que la majorité des applications clientes natives, en plus des applications de navigation, respectent également les paramètres du proxy et peuvent s’authentifier auprès des proxys, couvrant ainsi la plupart des cas d’utilisation de l’accès à l’internet.
Dans la méthode du proxy transparent, il n’y a pas de transaction HTTP CONNECT.
Par conséquent, l’authentification par proxy n’est pas possible.
Toute authentification de l’utilisateur doit se faire avec des schémas d’authentification HTTP normaux, comme la redirection de la demande HTTP vers le portail SASE, qui utilise à son tour les méthodes OIDC et SAML pour authentifier les utilisateurs.
Ce type d’authentification est appelé « Portal-based Authentication ».
Une fois que l’utilisateur s’est connecté avec succès, le portail peut définir le cookie, mais celui-ci n’est pas visible par le proxy lorsque l’utilisateur navigue sur des sites Internet en raison de la politique de la même origine dans les navigateurs.
En raison de ce problème, une fois que l’utilisateur s’est connecté avec succès, le portail crée une correspondance entre le nom d’utilisateur et l’adresse IP source de la session d’authentification de l’utilisateur et informe le proxy de cette correspondance.
Le proxy utilise ensuite cette correspondance pour associer les sessions de trafic à l’utilisateur.
Si aucune correspondance n’est disponible, le proxy redirige la session de trafic vers le portail pour la connexion.
Ce « mappage » est appelé « mappage IP représentatif ».
Comme décrit précédemment, cette méthode de mappage doit être utilisée avec précaution car elle peut ouvrir l’accès à des parties non désirées.
Les méthodes de proxy transparent dépendent de la redirection des transactions HTTP entrantes.
Cela signifie qu’elles doivent s’emparer du trafic clair via l’interception SSL.
Dans certains cas, l’interception SSL/TLS n’est pas autorisée ou n’est pas possible.
Comme la redirection n’est pas possible dans ces cas, on s’attend à ce que l’utilisateur soit authentifié auprès de SASE via d’autres mécanismes, tels que l’authentification proactive avec le portail ou via l' »authentification par tunnel ».
Pare-feu et fonctions basées sur L3/L4
Le pare-feu et les fonctions NAT, routage et QoS associées travaillent sur les paquets au niveau des couches L3/L4.
Ces fonctions doivent se trouver dans des systèmes qui sont dans la ligne du trafic.
Le plus souvent, les systèmes SASE dotés de ces fonctions sont des passerelles vers le trafic provenant des sites et des utilisateurs distants.
Étant donné que le pare-feu traite toutes sortes de protocoles au-delà de HTTP et HTTPS en ce qui concerne le contrôle d’accès, le proxy inverse et le proxy direct, les mécanismes d’authentification de portail à la demande ne sont pas possibles.
Deux modes sont principalement utilisés pour authentifier les utilisateurs : l’authentification explicite du portail et l’authentification par tunnel.
Dans le mode d’authentification par portail explicite, les utilisateurs sont censés s’authentifier auprès du portail SASE en faisant pointer leur navigateur vers le portail SASE.
Le portail SASE, ainsi que l’OIDC, authentifient les utilisateurs.
Dans ce cas également, SASE utilise la méthode de mappage « IP représentatif ».
Le portail SASE envoie la correspondance entre l’adresse IP et l’utilisateur au pare-feu lorsque l’authentification de l’utilisateur est réussie.
Le pare-feu et les fonctions L3/L4 utilisent ces enregistrements de mappage pour associer les sessions de trafic aux utilisateurs.
Le mode d’authentification par tunnel nécessite l’installation d’un logiciel spécial sur les appareils clients.
Les clients établissent des sessions de tunnel avec SASE de manière proactive.
Une partie de ce tunnel est authentifiée par le SASE.
Si des tunnels basés sur IPSec sont utilisés, l’authentification du tunnel est prise en charge par le composant SASE/IKEv2.
Le composant SASE/IKEv2 annonce l’utilisateur (ID de l’initiateur) et le mappage de l’adresse IP virtuelle aux services de sécurité et de réseau du SASE.
Le pare-feu et les fonctions L3/L4 utilisent la méthode de mappage « Representative IP » pour relier les sessions de trafic à l’utilisateur.
Même si ces deux modes d’authentification sont explicitement mentionnés ici, la correspondance entre l’adresse IP et l’utilisateur peut également provenir de proxys, lorsqu’un utilisateur s’authentifie auprès de proxys dans les modes « Reverse Proxy » et « Forward Proxy ».
Il convient de noter ici que l’authentification de l’utilisateur est nécessaire pour que les règles spécifiques à l’utilisateur soient efficaces.
Si l’utilisateur n’est pas authentifié, la logique de correspondance des règles suppose que l’utilisateur est inconnu.
Pour cette raison, les politiques basées sur l’utilisateur au niveau du pare-feu et de L3/L4 sont considérées comme opportunistes.
Pour inciter/rappeler aux utilisateurs de se connecter de manière proactive, les solutions SASE ont tendance à générer des notifications de navigateur pour informer les utilisateurs de se connecter au portail SASE.
SASE et identité unifiés
Le SASE unifié a été discuté ici, et cet article présentait les différents avantages que les entreprises tirent des offres de « SASE unifié ».
Si le SASE est construit à partir de différents composants distincts, l’authentification de l’utilisateur peut se faire plusieurs fois, ce qui n’est pas très agréable pour l’utilisateur.
Avec le « SASE unifié », les utilisateurs ne sont censés être authentifiés qu’une seule fois pour l’ensemble du SASE.
Il s’agit là d’un avantage supplémentaire du « SASE unifié ». Les offres de SASE unifié ajoutent des informations sur l’utilisateur aux messages logs pertinents de manière uniforme et complète sur une plateforme d’observabilité commune.
Cela permet de réaliser diverses analyses et de détecter les anomalies en surveillant le comportement de l’utilisateur dans les services SDWAN et de sécurité.
Résumé
L’approche de la micro-segmentation est nécessaire, mais l’extension de la micro-segmentation pour catégoriser les différents utilisateurs n’est pas une solution évolutive.
Les solutions SASE permettent de plus en plus la définition et l’application de politiques basées sur l’identité.
Pour ce faire, les solutions SASE authentifient les utilisateurs et établissent ensuite une correspondance entre les sessions de trafic et les utilisateurs.
Les solutions SASE offrent aux utilisateurs différents moyens de s’authentifier auprès de SASE.
Ce billet décrit quelques-unes de ces méthodes.
Aryaka s’est lancé dans la voie du « SASE conscient de l’identité ».
La solution Aryaka SWG prend en charge l’application de politiques spécifiques à l’utilisateur.
Pour en savoir plus sur la solution SWG d’Aryaka, cliquez ici : https://www.aryaka.com/secure-web-gateway/
-
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.
