Le principe fondamental de la sécurité Zero Trust est la définition de contrôles granulaires et de politiques d'autorisation pour chaque application, chaque utilisateur et chaque appareil. La conformité aux exigences réglementaires et de sécurité exige de disposer d'un système doté d'une granularité suffisante. Cependant, un tel nombre de contrôles comporte un inconvénient potentiel : pour résoudre les incidents affectant les utilisateurs, un administrateur doit tenir compte d'un ensemble complexe de variables englobant les applications, l'identité des utilisateurs et les informations sur les appareils. Cette approche peut, par conséquent, nécessiter un examen particulièrement minutieux des journaux.
Nous pensons qu'il existe une meilleure approche : c'est pourquoi, à partir d'aujourd'hui, les administrateurs peuvent auditer facilement toutes les sessions d'utilisateurs actifs, ainsi que les données associées utilisées par leurs politiques Cloudflare One. Cette approche réunit tous les avantages : des contrôles extrêmement granulaires, ainsi qu'une capacité améliorée de résolution d'incidents et de diagnostic des déploiements Zero Trust depuis un panneau de contrôle unique et simple. Les informations qui, auparavant, résidaient dans le navigateur de l'utilisateur ou changeaient dynamiquement sont désormais accessibles aux administrateurs, sans contraindre ces derniers à déranger les utilisateurs finaux ou à examiner longuement des journaux.
Quelques notions fondamentales sur l'authentification et l'autorisation des applications
L'authentification et l'autorisation sont les deux composantes évaluées par une politique Zero Trust avant d'autoriser un utilisateur à accéder à une ressource.
L'authentification est le processus de vérification de l'identité d'un utilisateur, d'un appareil ou d'un système. Les méthodes d'authentification courantes incluent notamment la saisie de noms d'utilisateur et de mots de passe, la présentation d'un certificat numérique ou même l'utilisation de données biométriques, telles que l'analyse des empreintes digitales ou l'analyse faciale. L'authentification multifactorielle (MFA, « Multi-Factor Authentication ») fait appel à deux méthodes d'authentification distinctes ou plus pour offrir une sécurité renforcée (par exemple, l'association d'une clé physique et d'un mot de passe).
L'autorisation est le processus consistant à accorder ou à refuser l'accès à des ressources ou des autorisations spécifiques lorsqu'une entité a été authentifiée avec succès. Elle définit les opérations que l'entité authentifiée est ou non autorisée à effectuer dans le système.
Mécanismes d'authentification/d'autorisation d'applications
Les applications web, sur lesquelles nous allons nous concentrer, utilisent généralement des cookies HTTP pour gérer l'authentification et l'autorisation.
Authentification:
Connexion : lorsqu'un utilisateur se connecte à une application web en saisissant son nom d'utilisateur et son mot de passe, l'application vérifie ces informations d'identification dans sa base de données ou auprès d'un fournisseur d'identité. D'autres formes d'authentification peuvent également être mises en œuvre, afin d'obtenir plusieurs facteurs d'authentification. Si ces facteurs correspondent, le serveur ou le service de sécurité externe (par exemple, Cloudflare Access) considère que l'utilisateur est authentifié.
Création d'un cookie ou d'un jeton : le serveur crée ensuite une session pour l'utilisateur sous la forme d'un cookie ou d'un jeton Web JSON Token (JWT). Le cookie reste valable un certain temps, jusqu'à ce que l'utilisateur doive s'authentifier à nouveau.
Envoi et stockage de cookies : le serveur renvoie au navigateur de l'utilisateur une réponse contenant l'identifiant de session et d'autres informations d'identification de l'utilisateur dans le cookie. Le navigateur stocke ce cookie, qui est ensuite utilisé pour reconnaître l'utilisateur lorsque celui-ci transmet des requêtes ultérieures.
Autorisation :
Requêtes ultérieures : pour toutes les requêtes ultérieures transmises à l'application web, le navigateur de l'utilisateur inclut automatiquement le cookie (avec l'identifiant de session et d'autres informations d'identification) dans la requête.
Vérification côté serveur : le serveur extrait les données de l'utilisateur du cookie et vérifie si la session est valide. Si elle est valide, le serveur récupère également les coordonnées de l'utilisateur, ainsi que les autorisations d'accès associées à cet identifiant de session.
Décision d'autorisation : en fonction des autorisations d'accès de l'utilisateur, le serveur décide si l'utilisateur est autorisé à effectuer l'opération demandée ou à accéder à la ressource demandée.
Ainsi, l'utilisateur reste authentifié (et son autorisation peut être vérifiée) pour toutes les requêtes ultérieures après sa connexion, jusqu'à ce que la session expire ou que l'utilisateur se déconnecte.
Dans les applications web modernes, cet état de session est, le plus souvent stocké, sous la forme d'un jeton JSON Web Token (JWT).
Débogage de l'authentification basée sur les jetons JWT
Les jetons JWT sont utilisés dans de nombreuses applications web modernes et dans des solutions Zero Trust Network Access (ZTNA), telles que Cloudflare Access, aux fins de l'authentification et de l'autorisation. Un jeton JWT inclut une charge utile assurant l'encodage des informations sur l'utilisateur, ainsi que d'autres données ; il est signé par le serveur, afin d'empêcher toute falsification. Les jetons JWT sont souvent utilisés sans état, ce qui signifie que le serveur ne conserve pas une copie de chaque jeton JWT ; il vérifie et décode simplement les jetons au fur et à mesure qu'il les reçoit avec les requêtes. En raison de la nature sans état des jetons JWT, la gestion des sessions d'utilisateurs ne dépend pas d'un système central, ce qui évite les problèmes d'évolutivité en cas d'augmentation du nombre d'utilisateurs accédant à un système.
Cependant, la nature sans état des jetons JWT rend difficile le débogage de l'authentification basée sur les jetons JWT en l'absence d'accès au jeton JWT spécifique d'un utilisateur. Voici pourquoi :
1. Spécificité des jetons : chaque jeton JWT est spécifique à un utilisateur et une session. Il contient des informations (affirmations) sur l'utilisateur, l'autorité émettrice, la date et l'heure d'émission du jeton et sa date d'expiration, ainsi que d'autres données, éventuellement. Par conséquent, le débogage d'un incident nécessite souvent d'avoir accès au jeton JWT exact à l'origine du problème.
2. Absence d'enregistrements côté serveur : les jetons JWT étant sans état, le serveur ne stocke pas les sessions par défaut. Il ne peut pas rechercher de jetons antérieurs, ni leur état associé, à moins d'avoir été spécifiquement conçu pour assurer leur journalisation ; toutefois, ce n'est généralement pas le cas, en raison de considérations liées à la confidentialité et à la minimisation des données.
3. Problèmes transitoires : les problèmes liés aux jetons JWT peuvent être transitoires ; ils peuvent être liés à l'instant précis auquel le jeton a été utilisé. Par exemple, si un jeton a expiré alors qu'un utilisateur essayait de l'utiliser, vous devrez avoir accès à ce jeton spécifique pour effectuer le débogage de l'incident.
4. Confidentialité et sécurité : les jetons JWT peuvent contenir des informations sensibles et doivent donc être manipulés avec précaution. L'obtention d'un jeton JWT auprès d'un utilisateur peut exposer ses informations personnelles ou ses identifiants de sécurité à la personne effectuant le débogage de l'incident. En outre, si un utilisateur transmet son jeton JWT à un développeur ou un service d'assistance informatique via un canal non sécurisé, le jeton JWT peut être intercepté (Cloudflare a récemment publié une application gratuite d'assainissement de fichiers HAR afin d'aider à atténuer cette préoccupation).
En raison de ces facteurs, il est difficile de résoudre les problèmes liés à l'authentification par jeton JWT sans avoir accès au jeton en question.
Une meilleure façon de déboguer les incidents liés à l'identité
Nous avons entrepris de développer une meilleure manière de déboguer les incidents liés à l'identité d'un utilisateur dans Cloudflare Zero Trust, qui ne nécessite pas la transmission de jetons JWT ou de fichiers HAR, dans un sens ou dans l'autre. Les administrateurs peuvent désormais visualiser l'identité de registre (« Registry Identity ») d'un utilisateur (utilisée pour les politiques de passerelle), ainsi que toutes les sessions Access actives.
Ces informations sur les sessions incluent l'identité complète évaluée par la solution Zero Trust, notamment les affirmations de fournisseurs d'identité, les informations sur la stratégie de sécurité de l'appareil, le contexte réseau et bien davantage. Nous avons pu développer cette fonctionnalité sans ajouter une charge supplémentaire à la logique d'authentification d'Access, en utilisant Cloudflare Workers KV. Lorsqu'un utilisateur s'authentifie auprès d'Access, l'identité qui lui est associée est immédiatement enregistrée dans une paire clé/valeur dans Workers KV. Tout cela se déroule dans le contexte de l'événement d'authentification de l'utilisateur, permettant ainsi de minimiser l'impact en termes de latence ou la dépendance vis-à-vis d'un service externe.
Cette fonctionnalité est disponible pour tous les clients de toutes les offres Zero Trust. Si vous souhaitez faire vos premiers pas avec Cloudflare Zero Trust, inscrivez-vous dès aujourd'hui pour créer un compte gratuit pour jusqu'à 50 utilisateurs. Vous pouvez également contacter les experts de Cloudflare pour parler de l'approche SSE ou SASE pour votre entreprise et examiner vos scénarios d'utilisation de la sécurité Zero Trust, étape par étape.