Dans mon blog précédent sur les SASE sensibles à l’identité, j’ai parlé de la confiance zéro, du rôle des SASE et de l’importance de l’identité dans les contrôles d’accès.
Un autre blog sur le proxy SASE explique comment les solutions SASE obtiennent les identités des utilisateurs après les avoir authentifiés par l’intermédiaire de fournisseurs d’identité (IdP).
En résumé, la partie forward proxy des solutions SASE authentifie les utilisateurs via les méthodes d’authentification Kerberos, NTLM, Digest et Basic.
De leur côté, les portails captifs authentifient les utilisateurs par Kerberos ou OIDC.
Le reverse proxy des solutions SASE utilise généralement Kerberos ou OIDC pour authentifier les utilisateurs.
La passerelle VPN de SASE authentifie également les utilisateurs à l’aide des bases de données d’authentification de l’entreprise.
Les solutions SASE attendent des informations sur l’utilisateur telles que le fournisseur d’identité qui a validé les informations d’identification de l’utilisateur, l’adresse électronique de l’utilisateur, les groupes et les rôles auxquels l’utilisateur appartient, etc. au format JWT (JSON Web Token).
Les solutions SASE utilisent ces informations (appelées « claims » dans la terminologie JWT) pour appliquer des contrôles d’accès spécifiques à l’identité.
Courtier en identité
Un courtier d’identité est un service qui agit en tant qu’intermédiaire, facilitant l’authentification des utilisateurs finaux par les solutions SASE avec divers fournisseurs d’identité (IdP).
Tous les fournisseurs d’identité ne mettent pas en œuvre tous les protocoles d’authentification ; certains peuvent ne mettre en œuvre que OIDC, OAuth2 ou SAMLv2.
Les solutions SASE étant conçues pour fonctionner avec plusieurs fournisseurs d’identité, leur complexité augmente lorsqu’elles doivent prendre en charge différents protocoles d’authentification.
Les courtiers en identité, en tant que services intermédiaires de confiance, peuvent permettre à la solution SASE d’utiliser un seul protocole d’authentification dans le backend et laisser le courtier en identité transférer le processus d’authentification aux IdP via les protocoles d’authentification pris en charge par les IdP.
L’image suivante illustre la solution SASE avec et sans courtier d’identité. 
La partie gauche de l’image montre SASE sans courtier d’identité : Les navigateurs/applications des utilisateurs s’authentifient auprès du forward proxy de SASE en utilisant Kerberos, NTLM, nom d’utilisateur/mot de passe, nom d’utilisateur/mot de passe numérique.
SASE doit valider les informations d’identification de l’utilisateur.
Il utilise plusieurs modules fonctionnels dorsaux pour communiquer avec différents systèmes d’authentification.
Dans le cas de Kerberos, le ticket de service est validé localement dans le plan de données de SASE, puis il obtient les décorations de l’utilisateur à partir de systèmes d’authentification tels que AD via LDAP ou SCIM.
Dans le cas d’un nom d’utilisateur/mot de passe, le backend LDAP est utilisé pour valider les informations d’identification de l’utilisateur.
Le proxy inverse SASE et les portails captifs authentifient les utilisateurs soit via OIDC (Open ID Connect), soit via SAMLv2.
Si le backend IdP est également basé sur OIDC ou SAMLv2, il redirige les utilisateurs vers les IdP.
Dans le cas de systèmes basés sur LDAP, SASE est censé fonctionner comme IdP et utiliser LDAP pour AD afin de valider les informations d’identification de l’utilisateur et d’obtenir les décorations de l’utilisateur pour créer le jeton d’identité sous forme de JWT.
La passerelle VPN est un autre module utilisé pour l’accès à distance.
Dans le cadre de l’établissement du tunnel IKEv2, la passerelle VPN authentifie l’utilisateur.
Les informations d’identification de l’utilisateur sont validées par la base de données locale, le serveur RADIUS ou le serveur LDAP.
Comme vous pouvez le constater, plusieurs composants du plan de données sont nécessaires pour prendre en charge différents protocoles afin de fonctionner avec divers navigateurs et applications natives.
En outre, ils doivent fonctionner avec de multiples IdP non seulement de différents locataires, mais aussi de multiples exigences IdP au sein d’un environnement de locataire.
La partie droite de l’image montre SASE avec un courtier d’identité intégré : Avec le courtier d’identité, le plan de données de SASE est considérablement simplifié.
Le plan de données de SASE ne doit fonctionner qu’avec un seul protocole d’authentification vers le courtier.
Dans l’image ci-dessus, OIDC est le seul protocole que le plan de données SASE doit prendre en charge.
Le courtier peut orchestrer/fédérer des sessions d’authentification avec plusieurs IdP.
Le courtier d’identité est également censé créer des JWT à partir des informations utilisateur du jeton de sécurité SAMLv2, des JWT provenant des serveurs IdP en amont ou des informations utilisateur contenues dans la base de données locale ou accessibles via LDAP.
En d’autres termes, le courtier d’identité conçu pour SASE est censé fournir des JWT dans tous les cas – que l’utilisateur s’authentifie à l’aide de Kerberos via des en-têtes de proxy, Kerberos via des en-têtes WWW, OIDC, IKEv2 et que les serveurs IdP soient basés sur OIDC, SAMLv2 ou LDAP.
Il y a de nombreux avantages à séparer le plan de données SASE du courtier d’identité SASE.
Certains de ces avantages sont énumérés ci-dessous.
- La modularité rend l’ensemble de la solution moins complexe, moins sujette aux erreurs et donc plus robuste.
- Secure:Identity broker peut être instancié séparément du plan de données SASE dans des environnements informatiques confidentiels afin de garantir que les clés/mots de passe/accréditations utilisés pour communiquer avec les IdP sont protégés même lorsqu’ils sont en cours d’utilisation.
- Extensibilité : de nouveaux IdP avec des protocoles d’authentification plus récents peuvent être pris en charge sans incidence sur le plan de données SASE.
- Consolidation : les solutions de courtier d’identité sont de plus en plus envisagées pour d’autres applications également.
Les entreprises peuvent utiliser le courtier d’identité associé à la solution SASE pour leurs applications au lieu d’opter pour un service/solution de courtier d’identité séparé.
Caractéristiques spécifiques du SASE
La fonctionnalité des courtiers en identité peut en effet jouer un rôle important dans l’arrêt de l’accès direct aux services SaaS/Cloud en appliquant des contrôles de politique et en garantissant que seuls les utilisateurs authentifiés disposant d’un contrôle d’accès approprié peuvent accéder à ces ressources.
En outre, les courtiers d’identité traditionnels peuvent ne pas avoir un bon support pour le proxy Kerberos, qui est essentiel pour l’authentification SASE.
Il est donc important que les courtiers en identité prennent en charge le proxy Kerberos et d’autres exigences SASE pour s’intégrer efficacement aux solutions SASE.
En apportant ces améliorations, les courtiers en identité peuvent renforcer la sécurité et la facilité d’utilisation des solutions SASE pour les entreprises.
- Assurer un contrôle d’accès basé sur l’identité pour les services SaaS et en nuage en permanence et de manière déterministe : Les entreprises utilisent de plus en plus les services SaaS et d’infrastructure en nuage, auxquels elles peuvent accéder de n’importe où.
Il s’agit là d’un avantage considérable, mais aussi d’un problème de sécurité pour de nombreuses entreprises.
Les entreprises veulent restreindre l’accès à leurs données dans les services SaaS/Cloud à des employés spécifiques, et SASE est censé le garantir.
Toutefois, cela n’est possible que si le trafic des utilisateurs vers les services SaaS/Cloud passe par le plan de données SASE.
Si le trafic se dirige directement vers les services SaaS/Cloud, en contournant le plan de données SASE, l’accès devrait être refusé.
Un courtier en identité peut aider à bloquer ces accès.
En configurant les services SaaS/Cloud pour qu’ils utilisent le courtier d’identité SASE, toute nouvelle session d’authentification d’utilisateur atterrit d’abord sur le courtier d’identité SASE.
Le courtier d’identité SASE, via ses contrôles de politique, peut empêcher les utilisateurs d’accéder directement aux services. - Prise en charge de l’octroi Kerberos : Pour de nombreux cas d’utilisation, les types d’autorisation implicite et de mot de passe sont suffisants.
Toutefois, ces deux types de subventions ne sont pas suffisants pour prendre en charge l’authentification Kerberos.
Le plan de données SASE, une fois qu’il a reçu le ticket de service Kerberos, soit via des en-têtes proxy, soit via des en-têtes WWW de l’utilisateur (navigateurs, par exemple), est censé valider le ticket de service et obtenir les décorations d’utilisateur correspondantes à partir des bases de données d’authentification.
Étant donné que le courtier est utilisé pour valider les informations d’identification, la mise en œuvre du protocole OIDC doit être améliorée pour permettre l’envoi du ticket de service du plan de données SASE au courtier d’identité et l’obtention du JWT si les informations d’identification sont validées.
Dernières réflexions
Les courtiers en identité peuvent en effet jouer un rôle crucial dans une solution SASE (Secure Access Service Edge) complète.
En intégrant un courtier d’identité dans l’architecture SASE, les organisations peuvent simplifier l’intégration des solutions de gestion des identités et des accès (IAM) dans leur infrastructure SASE.
Cela peut conduire à un processus d’authentification et de contrôle d’accès plus rationalisé et plus sûr pour les utilisateurs.
En outre, en appliquant les principes de sécurité zéro confiance, un courtier en identité peut aider à garantir que seuls les utilisateurs autorisés accèdent aux ressources au sein de l’environnement SASE.
Cela peut contribuer à réduire le risque de violation de données et d’autres incidents de sécurité.
Bien que les analystes de l’industrie ne discutent pas actuellement des courtiers en identité dans le contexte de la SASE, il est possible que cela change car les organisations continuent à chercher des moyens d’améliorer la sécurité et l’efficacité de leurs environnements informatiques.
-
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.