Accueil > OpenID Connect OAuth Server par DnC > En quoi OIDC contribue-t-il à l’approche ZTNA ?

En quoi OIDC contribue-t-il à l’approche ZTNA ? Perspectives d’évolution d’OAuthSD vers le contrôle du niveau matériel

Zero Trust Network Access, ZTNA : Accès "zéro-confiance" au réseau . Ce concept formalisé en 2010 par le cabinet d’études Forrester vise à donner aux utilisateurs des privilèges justes nécessaires (contrairement à un accès au réseau par Virtual Private Network, VPN).
OpenID Connect apporte dans ce domaine certaines réponses, notamment pour une protection en profondeur, au-delà du contrôle de l’accès au réseau.

Dans le contexte du COVID-19, le télétravail conduit de nombreux employés à accéder au réseau de leur entreprise au moyen d’un tunnel VPN à partir de l’ordinateur personnel ou - horreur absolue - l’ordinateur familial. Il convient d’effectuer des contrôles à ce niveau.

Principes du ZTNA

Il s’agit de protéger le système d’information (SI) et les données sensibles en partant du principe que l’on ne doit faire confiance à personne. Du matériel de l’utilisateur jusqu’à l’application, trois principes généraux s’appliquent :

1. Contrôle des matériels utilisés pour accéder au SI : Le seul contrôle de l’utilisateur final n’est pas suffisant, il convient de contrôler également l’agent utilisateur au moyen duquel il accède au réseau et aux applications.

2. Authentification multi-facteurs : l’authentification (à deux facteurs au moins, ou Two Factors Authentication, TFA) exige plusieurs preuves d’identité de l’utilisateur final.

3. Privilège minimum : Ne donner aux utilisateurs que l’accès aux ressources ou données dont ils ont besoin pour effectuer leurs tâches.

Comment se situe OpenID Connect ?

1. OpenID Connect intervient au niveau des applications. OIDC ne peut donc se substituer aux moyens d’identifier et de contrôler les couches matérielles. Cependant, le flux d’autorisation avec code (Authorization Code Grant), lorsqu’il est appliqué à des applications et services "avec back-end", offre un moyen d’identifier ces composants au niveau matériel. Sur ce sujet, voyez : Vérification de l’origine de la requête reçue par un serveur de ressource.

2. L’identification multi-facteurs ne fait pas partie de la norme OpenID Connect. La couche identification du contrôleur Authorize se doit d’implémenter plusieurs moyens d’identification, OAuthSD assure l’identification multi-facteurs.

3. En permettant de véhiculer par le jeton d’identité (ID Token) des informations d’identité et de privilèges et d’en garantir l’intégrité au moyen de la signature du jeton, OpenID Connect ouvre un moyen de contrôler les accès aux applications et aux données. OAuthSD permet la transmission des privilèges.
Cependant, tout dépend de ce que les applications et les ressources protégées feront de ces informations.

En conclusion :

Les applications du principe ZTNA visent le plus souvent à remplacer l’accès par VPN, et s’intéressent donc à la couche transport. L’identification et le contrôle d’intégrité du matériel est encore le parent pauvre des solutions de sécurité, OIDC n’y ajoute rien.

OpenID Connect étend la sécurité au niveau applicatif (dans la couche haute du modèle de l’OSI) et trouve donc sa place dans une approche ZTNA complète.

La difficulté d’OIDC réside dans la nécessité d’adapter les applications et les ressources de données protégées en leur incorporant un module OIDC. Voyez : Adaptation des applications.

Perspectives pour l’évolution d’OAuthSD

Notons que le serveur OAuthSD intègre déjà quelques fonctionnalités de sécurité au niveau des couches matérielles et transport, et en apportera de plus en plus au fur et à mesure de son développement.

Il existe des informations complémentaires, connectez vous pour les voir.