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.
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.
Est-ce vraiment nouveau ? Est-ce vraiment suffisant ?
De façon générale, on assure une sécurité périmétrique à l’aide d’un pare-feu et de mesures de protection afin d’empêcher les intrusions. Constatant l’absence de mesures de protection lorsque les intrus parviennent à franchir le périmètre, ZTNA semble proposer d’accepter le réseau tel qu’il est et de reporter la défense au niveau applicatif. Ce serait une erreur de négliger le réseau : par exemple, si l’accès aux fonctionnalités d’administration de la base de données (avec une console SSH) est mal protégé, il ne sera pas suffisant de protéger l’accès à l’application.
En 2004, le Jericho Forum introduisait le concept de dépérimétrisation, une stratégie de sécurité qui consiste à compléter la « limite » de sécurité standard séparant un réseau de l’Internet et à créer à la place un système de sécurité segmenté et multicouche basé sur le chiffrement et l’authentification.
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 :
Le principe ZTNA nous invite à compléter les protections du niveau réseau (VPN, firewall, proxy) en authentifiant les applications et les personnes. Le principe de dépérimétrisation nous invite à appliquer les barrières dans la profondeur du réseau et à chiffrer au niveau applicatif.
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.
RSS 2.0