Authentification et autorisation disponibles en plusieurs couleurs
Le composant Zero Trust Network Access (ZTNA) de SASE est conçu pour fournir un accès sécurisé aux applications privées de l’entreprise.
Conformément au principe fondamental du contrôle d’accès basé sur l’identité dans l’architecture de confiance zéro (ZTA), ZTNA joue un rôle essentiel dans l’authentification des utilisateurs et l’application de contrôles d’accès basés sur les types d’utilisateurs, les groupes et les rôles pour chaque session entrante vers les applications de l’entreprise.
La sécurité ZTNA offre des avantages significatifs dans les scénarios suivants :
- Applications patrimoniales : Les applications patrimoniales qui ne disposent pas de mesures de sécurité intégrées ne sont souvent pas exposées aux utilisateurs de Work-From-Anywhere (WFA) pour des raisons de sécurité.
En utilisant ZTNA pour l’interface de ces applications, il est possible de fournir une terminaison HTTPS avec gestion des certificats, authentification à l’aide de protocoles tels que OIDC et autorisation basée sur des contrôles d’accès contextuels.
Cela permet aux utilisateurs de WFA d’accéder en toute sécurité aux applications existantes sur l’internet. - Applications défectueuses : Bien qu’elles aient été développées dans un souci de sécurité, certaines applications peuvent ne pas avoir été mises à jour pendant une longue période.
Ces applications peuvent ne pas disposer d’une gestion correcte des certificats, avec un support obsolète ou inexistant pour le téléchargement de nouveaux certificats ou le renouvellement automatique.
ZTNA peut agir comme un substitut de sécurité pour ces applications défectueuses, garantissant un accès sécurisé tout en surmontant leurs limites de sécurité. - Nouvelle architecture des applications : Les applications d’entreprise modernes sont souvent conçues de manière à ce que les considérations de sécurité soient confiées à des entités externes telles que ZTNA et les technologies de maillage de services.
Cette approche libère les développeurs d’applications du fardeau de la gestion du HTTPS, de l’authentification et de l’autorisation, car la sécurité est transférée à l’entité frontale.
La centralisation de la gestion de la sécurité permet d’obtenir des avantages tels que l’application uniforme de la politique de sécurité, l’augmentation de la productivité dans le développement d’applications et la simplification de la maintenance.
En outre, comme les mises à jour de sécurité sont gérées en externe, la fréquence de publication des correctifs visant à résoudre les problèmes de sécurité peut être considérablement réduite.
De nombreuses solutions ZTNA actuelles sont efficaces pour les applications d’entreprise simples, mais elles ne sont pas en mesure de fournir l’authentification et l’autorisation pour les applications multi-tenant telles que les applications SaaS.
Le rôle de ZTNA dans les applications SaaS : Dans le contexte des applications SaaS (Software-as-a-Service), ZTNA jouera à mon avis un rôle essentiel dans le renforcement et l’amélioration des mécanismes d’authentification et d’autorisation.
Les applications SaaS ont des exigences spécifiques, notamment la multi-location, la résilience contre les attaques DoS/DDoS et une protection solide contre le contournement de l’authentification et les attaques par élévation de privilèges.
Cet article se penche sur les caractéristiques des ZTNA de nouvelle génération qui peuvent contribuer à décharger ou à améliorer les processus d’authentification et d’autorisation pour les applications SaaS.
Veuillez noter que cet article ne couvrira pas les autres fonctionnalités de ZTNA, telles que WAAP (Web Application and API Protection), la terminaison HTTPS, la gestion du trafic des sessions entrantes vers diverses instances d’application, la webification des services SSH/RDP/VNC et le fait de rendre les applications invisibles pour les scanners de ports.
Il se concentre principalement sur les aspects d’authentification et d’autorisation de ZTNA.
Il est important de noter qu’il peut y avoir une confusion entre les rôles de CASB (Cloud Access Security Broker) et de ZTNA dans le contexte du SaaS.
Le composant CASB de SASE se concentre sur la sécurisation des connexions aux services SaaS utilisés par les entreprises, où les entreprises sont des consommateurs de SaaS et de services CASB.
En revanche, ZTNA, dans le contexte du SaaS, est conçu pour protéger l’application SaaS elle-même, ce qui fait des entreprises SaaS des consommateurs des services ZTNA.
Cette différenciation est essentielle pour comprendre les rôles et responsabilités distincts des CASB et ZTNA dans les solutions SASE.
Dans un article précédent sur les courtiers en identité, nous avons exploré les nombreux avantages de l’intégration des courtiers dans les solutions SASE.
Les avantages discutés tournaient principalement autour de la modularité et de la simplicité de conception, améliorant en fin de compte la résilience des solutions SASE.
Dans cet article, nous allons nous pencher sur le rôle central des courtiers d’identité dans le soutien des applications complexes, en nous concentrant particulièrement sur les applications SaaS.
Quels sont les défis posés par les applications multi-locataires ?
ZTNA de SASE excelle dans la fourniture d’un support robuste pour les autorisations basées sur des politiques.
Les moteurs d’autorisation de SASE permettent de gérer plusieurs tables de politiques, chaque table contenant plusieurs politiques.
Chaque politique est composée de plusieurs règles et spécifie l’action à entreprendre en cas de correspondance réussie.
Les règles elles-mêmes englobent divers attributs de correspondance, qui peuvent être classés en attributs de source et de destination.
Les attributs de destination concernent principalement les ressources des applications auxquelles on accède, telles que les URI et les méthodes (par exemple, GET, PUT, POST, DELETE) utilisées pour interagir avec ces ressources.
D’autre part, les attributs de source sont généralement associés aux sujets qui accèdent aux ressources.
Ces attributs englobent les attributs liés à l’utilisateur tels que le nom, le groupe, le rôle, le service d’authentification qui a validé les informations d’identification de l’utilisateur et d’autres revendications de l’utilisateur.
Ils comprennent également des attributs liés au contexte de l’appareil, qui rendent compte de la sécurité des appareils utilisés par le sujet et de l’emplacement de l’appareil à partir duquel l’utilisateur accède aux ressources.
Cependant, de nombreuses solutions ZTNA sont insuffisantes lorsqu’il s’agit d’aborder des scénarios d’authentification complets, limitant souvent leurs capacités à des applications non-SaaS.
L’intégration d’un courtier en identité dans les solutions SASE/SSE est une étape progressive vers une authentification complète pour tous les types d’applications.
Bien que l’on puisse affirmer que les fournisseurs de SaaS possèdent la capacité de gérer l’authentification et l’autorisation au sein de leurs applications, le paysage a considérablement évolué.
Dans l’environnement agile d’aujourd’hui, les fournisseurs de SaaS reconnaissent de plus en plus les avantages de se décharger des responsabilités de sécurité sur des entités externes telles que SASE.
Ce faisant, ils peuvent bénéficier d’une productivité accrue et d’une plus grande confiance dans leur posture de sécurité globale.
En outre, cette approche permet aux nouveaux fournisseurs de SaaS d’entrer plus rapidement sur le marché, car ils peuvent se décharger de l’authentification et de l’autorisation sur une entité externe et se concentrer principalement sur leur logique commerciale de base.
Les solutions SASE peuvent jouer un rôle central dans le soutien de ces nouveaux fournisseurs SaaS.
Nous pensons que les solutions SASE devraient être et seront prêtes à relever le défi de fournir une sécurité d’authentification et d’autorisation au nom d’applications complexes telles que les applications SaaS.
Le scénario suivant donne un exemple représentatif d’une application SaaS et explore comment SASE, en intégrant des courtiers en identité, peut aider à la délégation de l’authentification et de l’autorisation à partir des applications.
Considérez cet exemple de scénario d’application SaaS (hébergée sur app.example.com) qui consiste en de multiples ressources API :
| /app.example.com/service-admin-api/ | Cet espace API est exclusivement réservé aux administrateurs de fournisseurs de services d’application. |
| /app.example.com/tenants//tenant-admin-api/ | Seuls les administrateurs des locataires peuvent accéder à cet espace API sous leur locataire respectif. |
| /app.example.com/tenants//tenant-user-api/ | Cet espace API est réservé aux utilisateurs locataires. |
| /app.example.com/tenants//public-api/ | Tout le monde peut accéder à cette API à condition de fournir des informations d’identification valides par l’intermédiaire de sites de réseaux sociaux ou d’autres services d’authentification pris en charge. |
| /app.example.com/tenants//collaboration-api/ | Seuls les partenaires locataires peuvent utiliser cette API. |
Dans ce scénario, supposons également que l’IDP du fournisseur SaaS est example-idp.
Il y a deux locataires : XYZ et ABC, dont les services IDP respectifs sont XYZ-idp et ABC-idp.
Chaque locataire a également deux partenaires, chacun ayant son propre service IDP.
XYZ-P1-idp et XYZ-P2-idp sont les services IDP des partenaires de XYZ.
ABC-P1-idp et ABC-P2-idp sont les services IDP des partenaires ABC.
En outre, le locataire XYZ exige une authentification via Google et Facebook pour l’accès à l’espace API public, tandis que le locataire ABC préfère une authentification via LinkedIn et GitHub.
Les politiques d’autorisation suivantes sont nécessaires dans ZTNA pour répondre au scénario ci-dessus :
- Domaine = app.example.com ; user-role=app-admin ; authservice=example-idp ; uri = /service-admin-api/* ALLOW : Autoriser l’accès à tout utilisateur qui s’est connecté avec succès au service example-idp et qui possède le rôle app-admin pour toutes les ressources sous l’admin-api de l’application avec le domaine app.example.com.
- Domaine = app.example.com ; user-group=admin-group ; authservice=XYZ-idp ; uri = /tenants/XYZ/tenant-admin-api/* ALLOW : Autoriser l’accès à toutes les ressources sous XYZ/tenant-admin-api à tout utilisateur qui s’est connecté avec succès au service XYZ-idp et qui possède le rôle admin-group.
- Domaine = app.example.com ; user-role=admin-role ; authservice=ABC-idp ; uri = /tenants/ABC/tenant-admin-api/* ALLOW : Autorise l’accès aux ressources ABC/tenant-admin-api à tout utilisateur ayant le rôle d’administrateur, authentifié par le service ABC-idp.
- Domaine = app.example.com ; authservice=XYZ-idp ; uri = /tenants/XYZ/tenant-user-api/*, /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW : Autorise l’accès aux ressources spécifiées dans la règle pour tout utilisateur authentifié avec succès auprès du service XYZ-idp.
- Domaine = app.example.com ; authservice=ABC-idp ; uri = /tenants/ABC/tenant-user-api/*, /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW : Autorise l’accès aux ressources spécifiées dans la règle pour tout utilisateur authentifié avec succès auprès du service ABC-idp.
- Domaine = app.example.com ; authservice=XYZ-P1-idp ; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW : Autoriser l’accès à l’espace de collaboration XYZ pour les utilisateurs authentifiés avec le service XYZ-P1-idp.
- Domaine = app.example.com ; authservice=XYZ-P2-idp ; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW : Autoriser l’accès à l’espace de collaboration XYZ pour les utilisateurs authentifiés avec le service XYZ-P2-idp.
- Domaine = app.example.com ; authservice=ABC-P1-idp ; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW : Autoriser l’accès à l’espace de collaboration ABC pour les utilisateurs authentifiés avec le service ABC-P1-idp.
- Domaine = app.example.com ; authservice=ABC-P2-idp ; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW : Autoriser l’accès à l’espace de collaboration ABC pour les utilisateurs authentifiés avec le service ABC-P2-idp.
- Domaine = app.example.com ; authservice=google.com ; uri = /tenants/XYZ/public-api/* ALLOW : Autoriser l’accès à l’espace public-api de XYZ pour tous les utilisateurs authentifiés avec google.com.
- Domaine = app.example.com ; authservice=facebook.com ; uri = /tenants/XYZ/public-api/* ALLOW : Autoriser l’accès à l’espace public-api de XYZ pour tous les utilisateurs authentifiés avec facebook.com
- Domaine = app.example.com ; authservice=linkedin.com ; uri = /tenants/ABC/public-api/* ALLOW : Autoriser l’accès à l’espace ABC public-api pour tous les utilisateurs authentifiés avec linkedin.com
- Domaine = app.example.com ; authservice=github.com ; uri = /tenants/ABC/public-api/* ALLOW : Autoriser l’accès à l’espace public-api XYZ pour tous les utilisateurs authentifiés avec github.com
- Domaine = app.example.com ; DENY : refuse l’accès à l’application si aucune des règles ci-dessus ne correspond.
Les solutions SASE excellent dans le contrôle d’accès basé sur les attributs.
Cela signifie qu’elles gèrent bien la fonctionnalité d’autorisation.
Cependant, elles ne sont pas très complètes en ce qui concerne l’authentification.
Dans les politiques ci-dessus, différents niveaux d’accès sont accordés en fonction du service de fournisseur d’identité (IDP) avec lequel les utilisateurs choisissent de s’authentifier.
Par ailleurs, certains utilisateurs peuvent délibérément vouloir s’authentifier auprès d’un service IDP spécifique pour accéder à des ressources avec des autorisations minimales afin d’éviter d’éventuelles erreurs d’exfiltration de données.
Rôle des courtiers en identité
Pour répondre à ces scénarios, la fonctionnalité intégrée d’un courtier d’identité est nécessaire.
Les courtiers d’identité servent de fournisseurs OIDC (OpenID Connect) au composant proxy SASE/SSE tout en agissant en tant que clients OIDC/SAML/LDAP pour les services d’identité en amont (services d’authentification).
Keycloak, un système IAM à code source ouvert, est un choix populaire pour beaucoup.
Il peut être configuré pour jouer le rôle de courtier en identité et est couramment utilisé par les fournisseurs de services SASE et les vendeurs de produits de maillage de services.
C’est pourquoi la terminologie Keycloak est utilisée ici.
Keycloak offre la flexibilité nécessaire pour gérer l’authentification pour différents types d’applications, y compris les applications SaaS multi-locataires.
L’authentification pour les applications SaaS multi-locataires peut être réalisée à l’aide de « courtiers d’identité » de la manière suivante : Un domaine avec un client pour chaque application SaaS avec des flux d’authentification modifiés : Dans les cas où l’application-locataire ne peut pas être identifiée à partir du chemin URL ou des en-têtes de requête HTTP, le composant proxy SASE peut n’avoir qu’un seul client OIDC pour communiquer avec le courtier d’identité.
Lors de l’authentification de l’utilisateur, le courtier en identité doit savoir quel service IDP doit authentifier l’utilisateur.
Keycloak fournit des flux d’authentification standard tels que le flux du navigateur et permet la création de flux personnalisés et d’associations avec des clients Keycloak.
SASE tire parti de cette fonctionnalité en créant des flux d’authentification dans lesquels les utilisateurs sont invités à fournir des informations sur le locataire.
Sur la base de ces informations, les flux d’authentification peuvent présenter les fournisseurs d’identité disponibles pour que l’utilisateur puisse faire son choix.
Grâce à ces informations, le courtier peut rediriger les utilisateurs vers le service d’identité approprié. Un domaine avec plusieurs clients pour chaque application SaaS : Si l’application-locataire peut être identifiée à partir de l’URL ou des en-têtes de la requête HTTP, le composant proxy SASE peut être configuré pour utiliser un client pour chaque application-locataire.
Dans ce cas, des flux de navigation standard avec différents ensembles de fournisseurs d’identité peuvent être utilisés et associés aux entités client correspondantes dans Keycloak.
L’avantage est que l’utilisateur n’est pas invité à donner le nom du locataire, ce qui améliore l’expérience de l’utilisateur.
En résumé, ces stratégies permettent aux solutions SASE de gérer efficacement l’authentification pour les applications SaaS multi-locataires, en tirant parti des capacités de Keycloak en tant que courtier d’identité.
Sélection des clients de l’OIDC basée sur une politique
Le courtier Keycloak prend en charge plusieurs domaines et plusieurs clients dans chaque domaine.
Il permet des flux d’authentification standard, la création de flux d’authentification personnalisés et l’association de ces flux avec des clients.
La fonctionnalité du courtier Keycloak permet également le courtage de sessions d’authentification entre les mécanismes d’authentification côté utilisateur et les services d’authentification dorsaux (en amont).
Nous avons vu précédemment comment Keycloak peut inviter les utilisateurs à identifier leur application-locataire et à sélectionner le service d’identité pour l’authentification.
Ces capacités devraient également être exploitées par le proxy SASE, qui agit en tant que client OIDC (également connu sous le nom de relais OIDC) pour diverses applications clients, y compris les applications multi-locataires.
Le proxy SASE doit prendre en charge plusieurs clients OIDC.
Une approche consiste à disposer d’un ensemble de clients OIDC pour chaque client, ce qui permet d’isoler les configurations liées à l’authentification propres à chaque client.
En général, l’ensemble OIDC de chaque client SASE est associé à un domaine dans Keycloak.
Dans les scénarios où un client du proxy SASE possède plusieurs applications, chacune avec son propre nom de domaine, il devient nécessaire de fournir une isolation entre les administrateurs d’applications multiples.
Dans ce cas, un sous-ensemble de clients OIDC doit être configuré, avec un client assigné à chaque application.
Pour de nombreuses applications, un seul client OIDC suffit s’il s’agit d’une application à locataire unique ou si le locataire ne peut pas être identifié à partir du trafic, comme nous l’avons vu précédemment.
Toutefois, si le locataire peut être identifié, un client OIDC peut être configuré pour chaque application-locataire.
En raison de la nécessité de disposer de plusieurs clients OIDC, le proxy SASE doit offrir un mécanisme de sélection du client OIDC approprié.
C’est ici que la sélection de l’OIDC basée sur une politique devient cruciale.
Une table de politiques avec plusieurs politiques est utilisée, chaque politique pointant vers l’enregistrement du client OIDC correspondant.
Pendant le flux de trafic, le proxy SASE vérifie si l’authentification OIDC est requise et compare le client, le nom de domaine de l’application et l’application-locataire aux politiques de la table.
Si une correspondance est trouvée, l’enregistrement client OIDC correspondant est utilisé pour communiquer avec le courtier.
Certaines implémentations peuvent avoir plusieurs tables de politiques, avec une table dédiée à chaque client, afin d’accélérer le processus de correspondance des politiques.
NextGen ZTNA s’adaptera aux applications multi-locataires
ZTNA (Zero Trust Network Access) au sein des solutions SASE (Secure Access Service Edge) joue un rôle crucial dans la sécurisation des applications.
Il permet de décharger les applications des tâches d’authentification et d’autorisation, ce qui permet aux développeurs de se concentrer sur leur logique commerciale de base.
Cette approche améliore la productivité et renforce la sécurité globale.
Les vulnérabilités liées au contournement de l’authentification et à l’escalade des privilèges sont courantes dans les applications, car tous les développeurs n’ont pas d’expertise en matière de sécurité.
La délocalisation de la sécurité permet d’éliminer ces vulnérabilités et de renforcer la résilience des applications.
La centralisation de la sécurité dans un lieu commun, tel que SASE, simplifie le travail des administrateurs de sécurité, qui n’ont à gérer qu’une seule interface pour toutes les applications.
Pour assurer à la fois la sécurité et la flexibilité, la prochaine génération de solutions ZTNA au sein de SASE devrait prendre en charge divers types d’applications.
De nombreuses solutions ZTNA existantes ont souvent du mal à prendre en charge efficacement les applications multi-locataires.
Les améliorations futures devraient intégrer la fonctionnalité de courtier en identité et la sélection de clients OIDC (OpenID Connect) basée sur des règles afin de répondre à un large éventail de scénarios d’application.
-
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.