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

, dans le réseau de Bertrand Degoy

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, le serveur OIDC devenant une part d’OAuthSD.
Il existe des informations complémentaires,connectez vous pour les voir.


JPEG - 76.7 ko
Jeremie Bresson @j2r2b · 2 avril 2020
Je viens de regarder cette conf de @valeriane_IT
https://youtube.com/watch?v=yU_Uvm3m3VY
Un bon retour sur "Authentication vs Authorization" et l’histoire des standards (OpenID, OAuth 2, OpenID Connect, …). De quoi remettre en contexte l’idée de "Biscuit authentication token"
Cookie
JPEG - 93.4 ko
Axiomatics @axiomatics 24 avril 2020
#ZTNA is a software-defined perimeter that governs strict identity verification for every person and device attempting to access information on a private network :
#ZTNA est un périmètre défini par logiciel qui régit la vérification d’identité stricte pour chaque personne et appareil tentant d’accéder aux informations sur un réseau privé :
https://www.axiomatics.com/blog/zero-trust-network-access-eliminates-wide-network-access-perimeters/

Pour en savoir plus :

- OVH Healthcare : comment OVH accélére le développement de la e-santé depuis 2016
- OVH ouvre cinq nouveaux datacenters, dont un au Canada et un aux Etats-Unis en 2017.
- La donnée : source d’information ou vecteur de confusion
- Matinale technologique n°18 : Cybersécurité le Mardi 12 décembre 2017 à Nogent
- Une matinale protectrice le 12 décembre 2017 à Nogent
- Matinée « Santé, Intelligence Artificielle et Cybersécurité : quels enjeux ? » le 22 novembre 2018 à Rennes
- 5ème colloque sur la cybersécurité des systèmes d’information pour les établissements sanitaires et médico-sociaux le 03 octobre 2019 à Paris
- La cyberattaque du CHU de Rouen serait bien d’origine criminelle le 15 novembre 2019 à Rouen
- « La cybersécurité, enjeu majeur des acteurs de la santé » le 12 décembre 2019 à Paris
- Un rapport déplore le niveau de la sécurité et des mots de passe en entreprise
- En quoi OIDC contribue-t-il à l’approche ZTNA ?