Accueil > OpenID Connect OAuth Serveur dédié > 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 à rien ni 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, ainsi que son matériel.
Chez DnC, nous notons que cette formulation suppose que l’application se trouve du côté du réseau local (application avec back-end). C’est donc une application bien identifiée, digne de confiance. Ce n’est pas le cas des applications fonctionnant sur des stations de travail ou des agents utilisateur distants. Il faudrait donc inclure l’authentification des logiciels dans ce premier principe.

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.

Avertissement : Il est important de noter que OpenID Connect, comme toute autre système d’authentification, n’assure pas la sécurité des applications ou des services de données, mais leur fournit des informations plus complètes et plus fiables sur l’utilisateur final que des méthodes d’identification plus simples. D’une part la sécurité dépendra de ce que les applications et services font de ces informations, d’autre part de leur sécurité intrinsèque ainsi que de celle du réseau.

En conclusion :

Les applications du principe ZTNA visent à compléter les protections de la couche transport (VPN, firewall, proxy) et s’intéressent donc à la qualification des applications et des personnes.

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

L’identification et le contrôle d’intégrité du matériel ainsi que des logiciels applicatifs et système est encore le parent pauvre des solutions de sécurité.

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.