Google Workspace renforce automatiquement la sécurité des sessions en ligne de vos utilisateurs à l'aide d'identifiants de session liés à l'appareil. Les ISLA sont conçus pour empêcher le détournement de session, également appelé vol de cookies.
Ce type de cyberattaque se produit lorsqu'un tiers non autorisé prend le contrôle de la session Web active d'un utilisateur en dérobant le cookie de session, souvent à l'aide d'un logiciel malveillant sur l'appareil de l'utilisateur. Un cookie de session est un petit fichier de données contenant l'identifiant de session unique émis par le site Web lors de la connexion. En présentant ce cookie volé, le pirate informatique peut usurper l'identité de l'utilisateur légitime et poursuivre sa session authentifiée.
Les identifiants de session liés à l'appareil fonctionnent en associant la session d'un utilisateur à son appareil spécifique, ce qui rend difficile l'utilisation de cookies volés sur d'autres appareils par des pirates informatiques. Cela crée une limite de sécurité matérielle qui réduit le risque d'accès non autorisé aux comptes utilisateur et protège les données sensibles. La DBSC est activée par défaut pour tous les comptes Workspace. Aucune action de la part de l'administrateur n'est requise pour activer cette protection.
Conditions requises pour utiliser les identifiants de session liés à l'appareil
- Navigateur Chrome : version 146 ou ultérieure pour Windows. Pour en savoir plus, consultez Mettre à jour Google Chrome.
- Sécurité matérielle : nécessite des fonctionnalités de sécurité matérielles pour stocker de manière sécurisée les clés cryptographiques utilisées pour associer la session à l'appareil. Pour Windows, il s'agit d'un Trusted Platform Module (TPM), qui est standard sur la plupart des appareils exécutant Windows 11. Consultez la documentation du fabricant de votre appareil pour confirmer les capacités matérielles.
Comment la protection ISLA est-elle appliquée ?
La protection DBSC est appliquée automatiquement lorsque l'appareil et le navigateur d'un utilisateur répondent aux exigences techniques nécessaires. Dans certains cas, les sessions peuvent rester non liées. Les principales raisons liées à cette erreur sont les suivantes :
- Environnement non compatible : problèmes liés au système d'exploitation, à la version du navigateur ou à la sécurité matérielle de l'utilisateur (comme un TPM sur Windows).
- Sessions existantes : la protection DBSC ne s'applique qu'aux nouvelles sessions. Les utilisateurs qui étaient déjà connectés lorsque les identifiants de session liés à l'appareil ont été activés doivent se déconnecter, puis se reconnecter pour lier leur session.
- Modifications du navigateur : certaines extensions de navigateur ou modifications manuelles des cookies peuvent empêcher DBSC de fonctionner correctement.
Appliquer les identifiants de session liés à l'appareil avec l'accès contextuel
Limité aux applications Web pour ordinateur, non applicable aux applications mobiles ni aux API
Vous pouvez renforcer la sécurité en exigeant que les utilisateurs disposent d'un identifiant de session lié à l'appareil pour accéder à des applications Google Workspace spécifiques. Lorsque vous appliquez les identifiants de session liés à l'appareil, les utilisateurs sont invités à se reconnecter si le système détecte une différence avec une session liée précédemment établie. Cette réauthentification permet au système de tenter une nouvelle association sécurisée. Les utilisateurs sur des plates-formes non compatibles ne peuvent pas accéder à l'application protégée. Cette mesure de sécurité est configurée via l'accès contextuel.
Pour configurer l'application des identifiants de session liés à l'appareil :
- Suivez les instructions pour créer un niveau d'accès personnalisé dans Autoriser l'accès aux applications uniquement à partir de sessions liées aux identifiants de session de l'appareil.
- Attribuez le niveau d'accès aux applications auxquelles vous souhaitez que seules les sessions liées aux identifiants de session de l'appareil aient accès en mode Moniteur pour simuler l'application sans bloquer l'accès des utilisateurs.
- Après avoir évalué l'impact, attribuez des niveaux d'accès en mode actif pour n'autoriser l'accès qu'aux sessions liées aux identifiants de session de l'appareil. Pour en savoir plus, consultez Déployer l'accès contextuel.
L'application des identifiants de session liés à l'appareil n'est pas immédiate. Autrement dit, après qu'un utilisateur se connecte, un délai de grâce est accordé avant que les identifiants ne soient appliqués. Cette conception permet de gérer les problèmes d'association temporaire potentiels. Une fois l'association effectuée, le système vérifie régulièrement si les utilisateurs qui accèdent aux applications spécifiées disposent de sessions liées aux identifiants de session de l'appareil. Toute réauthentification réinitialisera ce délai de grâce, et les identifiants de session liés à l'appareil ne seront pas appliqués lors de cette réauthentification.
Examiner les problèmes de protection et de session DBSC
Vous pouvez utiliser l'outil d'investigation de sécurité pour surveiller la protection DBSC et résoudre les problèmes d'interruption de session. Il existe deux sources de journaux pour l'activité DBSC :
- Événements de journaux des utilisateurs : surveillez l'association des jetons d'accès aux appareils des utilisateurs.
- Événements de journaux sur l'évaluation des accès : consultez l'état de cookies spécifiques.
Remarque : Les événements de journaux ISLA ne sont visibles que pour le compte principal lorsque plusieurs comptes utilisateur sont connectés au même profil de navigateur Chrome.
Étape 1 : Recherchez l'activité DBSC dans les événements du journal utilisateur
Utilisez cette source de données pour déterminer si ISLA lie correctement les clés aux appareils des utilisateurs et valide les sessions.
Pour vérifier si DBSC lie des clés :
-
Dans la console d'administration Google, accédez à Menu
Sécurité
Centre de sécurité
Outil d'investigation.Le droit d'administrateur Centre de sécurité est requis.
- Dans le champ Source de données, sélectionnez Événements de journaux des utilisateurs.
- Cliquez sur Ajouter une condition.
- Pour Attribut, sélectionnez Événement Est comme opérateur Liaison de clé DBSC comme événement.
- Cliquez sur Rechercher.
- Dans le tableau des résultats, consultez la colonne État de l'événement :
- Réussie : la protection par identifiants de session liés à l'appareil est activée pour l'utilisateur et la session est protégée.
- Échec : la liaison ISLA a échoué et la protection n'est pas activée pour l'utilisateur.
- Aucun résultat : la protection par identifiants de session liés à l'appareil n'a pas été tentée pour cette session utilisateur.
Pour vérifier si les identifiants de session liés à l'appareil valident les sessions :
-
Dans la console d'administration Google, accédez à Menu
Sécurité
Centre de sécurité
Outil d'investigation.Le droit d'administrateur Centre de sécurité est requis.
- Cliquez sur Ajouter une condition.
- Pour Attribut, sélectionnez Événement Est comme opérateur Validation de la clé associée aux identifiants de session liés à l'appareil comme événement.
- Cliquez sur Rechercher.
- Dans le tableau des résultats, consultez la colonne État de l'événement :
- Réussie : le cookie a bien été validé.
- Échec : la validation DBSC a échoué. Cliquez sur l'état pour obtenir des informations supplémentaires, comme un code d'erreur.
Une validation infructueuse ne signifie pas nécessairement que l'utilisateur rencontre des interruptions de session. Les utilisateurs peuvent être interrompus si plusieurs validations infructueuses se produisent de suite.
Étape 2 : Recherchez les refus d'accès dans les événements du journal "Évaluation des accès"
Utilisez cette source de données pour déterminer si l'accès au cookie d'un utilisateur a été refusé.
-
Dans la console d'administration Google, accédez à Menu
Sécurité
Centre de sécurité
Outil d'investigation.Le droit d'administrateur Centre de sécurité est requis.
- Pour Source de données, sélectionnez Événements de journaux sur l'évaluation des accès.
- Cliquez sur Ajouter une condition.
- Pour Attribut, sélectionnez Événement Est comme opérateur Refuser la demande de validation des cookies comme événement.
- Cliquez sur Rechercher.
- Dans le tableau des résultats, cliquez sur Refusé dans la colonne État de l'événement ou sur le lien dans la colonne Description pour ouvrir un panneau latéral dans lequel vous pouvez consulter les raisons des tentatives infructueuses :
- DBSC_BOUND_COOKIE_MISSING
- DBSC_BOUND_COOKIE_CORRUPTED
- DBSC_BOUND_COOKIE_EXPIRED
Les événements de journaux sont regroupés par session. Pour gérer le volume de journaux, un seul événement est enregistré par heure pour chaque session unique et chaque type de tentative infructueuse. Toute autre tentative avec les mêmes informations n'est pas enregistrée pendant cette heure.
Étape 3 : Déterminez si les interruptions de session sont dues à DBSC
Les utilisateurs peuvent être déconnectés pour diverses raisons, comme des limites de durée de session, des règles définies par l'administrateur ou des problèmes de réseau. Bien qu'une déconnexion n'indique pas toujours un problème lié à DBSC, des séquences de journaux spécifiques peuvent aider à identifier une activité potentielle liée à DBSC ou les cas où le système a bloqué une session compromise.
Utilisez ces points pour identifier les activités liées à DBSC :
- Examiner les séquences de journaux : si vous constatez des validations de clé ISLA infructueuses suivies d'une demande de validation de cookie refusée, il est possible que les identifiants de session liés à l'appareil soient à l'origine de la déconnexion de l'utilisateur.
- Comprendre l'impact sur l'utilisateur : pour protéger le compte, un utilisateur doit se reconnecter si le processus d'association rencontre une erreur.
Google, Google Workspace et les marques et logos associés sont des marques de Google LLC. Tous les autres noms de sociétés et de produits sont des marques des sociétés auxquelles ils sont associés.