Third-Party Apps

Présentation

Third-Party Apps est l'inventaire des applications de toute votre organisation dans elba. Il rassemble, dans une même fiche d'application, les indices issus des intégrations d'identité et des applications connectées directement, des autorisations OAuth, de l'activité e-mail, des usages Browser Security, des statuts de compte IA observés dans le respect de la vie privée et des extensions de navigateur installées.

Chaque signal conserve sa source et une explication de la façon dont il a été établi. L'activité du navigateur est une observation, et non la preuve qu'un compte existe ; l'activité e-mail étaye l'usage ; seuls les comptes, autorisations ou attributions provenant d'une source connectée sont confirmés. Cette distinction permet d'évaluer l'adoption sans transformer une observation du navigateur en accès ou en décision de remédiation.

Ouvrez le module correspondant à votre région Elba :

• Espace d'administration UE
• Espace d'administration États-Unis

Parcourir l'espace de travail

Le module comporte cinq onglets :

• Radar met en évidence les risques et les changements d'inventaire qui nécessitent votre attention.
• Inventaire répertorie les applications détectées, leurs utilisateurs, leurs indices, leur fraîcheur et la politique de l'organisation.
• Alertes suit les alertes de sécurité et l'état de leur traitement.
• Playbooks contient les modèles d'automatisation disponibles et les processus que vous avez configurés.
• Sources présente les connexions qui fournissent les données sur les applications.

Les sources et les actions disponibles pour votre organisation dépendent des intégrations connectées et du déploiement de Browser Security. Fiez-vous aux fonctionnalités, à la fraîcheur des indices et à l'état des connexions affichés dans elba.

Utiliser le Radar

Le Radar contient actuellement sept widgets :

• Usages risqués pour les applications disposant d'autorisations risquées
• Vulnérabilités à haut risque (CVE) pour les vulnérabilités de gravité élevée ou critique
• Fuites de données pour les fuites signalées chez un fournisseur
• Playbooks pour les processus configurés et les modèles disponibles
• Applications découvertes regroupées selon leur score de réputation
• Apps Shadow AI pour les applications d'IA qui n'ont pas été explicitement approuvées
• Apps à faible adoption pour les applications ayant peu d'utilisateurs

Sélectionnez Voir tout dans un widget pour ouvrir l'inventaire filtré correspondant. Utilisez Exporter pour télécharger le rapport du Radar lorsque vous souhaitez l'examiner hors ligne.

Les widgets de réputation utilisent les applications évaluées par elba. Une application privée à votre organisation peut tout de même apparaître dans l'Inventaire pendant qu'elba la rapproche du catalogue d'applications. Elle porte la mention Identification en cours, et son Score de réputation affiche Score de réputation pas encore disponible jusqu'à ce qu'un profil du catalogue soit disponible.

Examiner les CVE et les fuites de données

Depuis le Radar, sélectionnez Voir l’historique sur la carte des CVE ou des fuites de données, puis ouvrez l’onglet À propos d’une application pour examiner ses données.

Le Radar UE en production, capturé le 9 octobre 2026.

Ouvrez le lien de la source d’une donnée pour lire le rapport d’origine. Source et dates présente ses dates publiques et, pour les CVE, les versions concernées. Comparez-les à la version que vous utilisez avant d’évaluer votre exposition.

Un tiret indique que la valeur actuelle est indisponible. Vous pouvez toujours consulter l’historique ; une valeur indisponible ne signifie pas qu’il n’existe aucune donnée.

Examiner l'inventaire

Le tableau Inventaire affiche :

• Application, avec ses sources de détection et son état d'identification
• Score de réputation, fondé sur le profil du catalogue évalué automatiquement par elba lorsqu'il existe
• Exposition des accès, fondée uniquement sur les indices vérifiés des connecteurs
• Adoption du SSO, lorsque des comptes vérifiés permettent de la calculer
• Utilisateurs, dédupliqués parmi les indices actuels, avec les utilisateurs navigateur non détectés récemment affichés séparément
• Politique d’utilisation, qui enregistre la décision d'approbation de votre organisation

Recherchez une application par son nom ou utilisez les filtres Politique d’utilisation et Score de réputation, ainsi que les filtres de propriétaire, source, lieu d'hébergement, catégorie, informations de conformité, CVE, fuite de données, classification IA ou autorisations risquées. Le filtre des sources inclut les sources Browser Security.

Origine des indices

La vue Utilisateurs explique comment chaque signal a été établi :

• Confirmé par une source connectée : compte, autorisation OAuth ou attribution Okta remonté par une source connectée
• Étayé par l'activité e-mail : activité e-mail qui confirme un indice d'utilisation sans vérifier l'existence d'un compte
• Observé dans le navigateur : usage d'une application, statut d'un compte IA ou installation d'une extension observé dans le navigateur

Une même personne et une même application peuvent présenter des indices provenant de plusieurs sources. elba regroupe ces signaux sous un seul utilisateur lorsqu'ils peuvent être reliés de manière sûre, tout en conservant chaque source, type d'indice, date de première et de dernière détection et état de fraîcheur.

Un indice navigateur reste actuel pendant 30 jours après sa dernière observation. Au-delà, il reste visible avec l'état Non détecté récemment afin de préserver l'historique de l'application. Cette fenêtre ne s'applique pas aux indices des connecteurs ; leur propre date de dernière synchronisation reste visible.

Identité de l'application et évaluation automatique du catalogue

elba résout les applications à partir d'identifiants de catalogue acceptés par son moteur de révision automatique, tels que les correspondances exactes de source et les domaines, et jamais à partir du seul nom affiché. Une application détectée avec une confiance élevée qui ne correspond pas encore au catalogue global est conservée comme identité provisoire privée à votre organisation et marquée Identification en cours. Son nom et son domaine d'application sûr facilitent l'examen sans exposer cette fiche privée à une autre organisation.

L'évaluation du catalogue est réalisée par le pipeline automatisé d'enrichissement et de révision d'elba ; cet état ne représente pas une approbation humaine manuelle. La politique Approuvée, Non approuvée ou À examiner de votre organisation reste une décision distincte de l'administrateur.

Les applications, suites et extensions de navigateur autonomes apparaissent dans l'inventaire par défaut. Les signaux classés comme appareils, systèmes d'exploitation, composants de plateforme, sites web génériques ou éléments ambigus sont conservés hors de l'inventaire par défaut pour être classifiés, au lieu d'être présentés comme des applications SaaS ordinaires.

Score de réputation

Elba associe le score de l'application à quatre états :

• Fiable : de 7 à 10
• Incertain : de 5 à moins de 7
• Peu fiable : de 0 à moins de 5
• Score de réputation pas encore disponible : aucun score n'est encore disponible

Le score est une aide à l'examen, et non une décision d'approbation. Une application provisoire privée affiche Score de réputation pas encore disponible jusqu'à ce qu'un profil de catalogue évalué automatiquement soit disponible. Examinez l'application, son éditeur, ses autorisations confirmées, ses indices, ses utilisateurs et le besoin métier avant de modifier sa politique.

Politique d'utilisation

Votre organisation peut appliquer l'une des quatre politiques suivantes :

• Non examinée pour une application nouvellement détectée
• À examiner pour une application en attente de décision
• Approuvée pour une application autorisée par votre organisation
• Non approuvée pour une application que votre organisation n'autorise pas

La politique d'utilisation est distincte du score de réputation et de l'exposition des accès ; elba ne les fusionne pas en un score de risque unique. Le passage d'une application au statut Approuvée empêche la création de nouvelles alertes pour cette application. Examinez les alertes existantes et la politique de votre organisation avant de l'approuver.

Une application privée explicitement Non approuvée ne peut être bloquée par Browser Security que si elba dispose d'un domaine applicatif enregistrable et sûr. La fiche de l'application indique lorsqu'aucun domaine applicable n'est disponible. Pour définir la politique d'une application qu'elba n'a pas encore observée, consultez Ajouter un domaine d'application.

Détails de l'application

Sélectionnez une application pour ouvrir ses détails. Le volet comporte deux onglets :

• À propos distingue Informations sur l’application, Score de réputation, Exposition des accès, Utilisateurs observés et Politique d’utilisation. Il présente également, lorsqu'ils sont disponibles, l'évaluation du catalogue, les autorisations risquées, les fuites de données, les CVE, la conformité, l'hébergement, les informations DNS et les installations d'extensions.
• Utilisateurs présente les utilisateurs liés ou les comptes de connecteur non rattachés dans Utilisateurs et comptes détectés, avec les sources de détection, les types et explications des indices, les dates de première et de dernière détection, la fraîcheur, la méthode de connexion, le statut du compte IA et les actions réellement prises en charge pour chaque indice.

Pour les outils d'IA pris en charge, Browser Security transmet le Statut du compte IA observé : Compte professionnel, Compte personnel, Aucun compte connecté ou Indéterminé. L'inventaire canonique peut aussi afficher Comptes professionnel et personnel, mais uniquement lorsque des indices actuels professionnels et personnels coexistent pour le même utilisateur et la même application. Ce statut combiné est calculé par l'inventaire et non transmis par le navigateur ; les journaux du navigateur ne peuvent donc pas le filtrer. Toutes ces valeurs restent des observations du navigateur : Compte professionnel ne signifie pas qu'elba a vérifié un compte dans l'application. Les adresses e-mail et domaines des comptes IA détectés, le contenu des pages, les noms d'hôtes propres aux tenants et les URL complètes ne sont exposés ni dans l'inventaire, ni dans les journaux du navigateur, ni dans l'API publique.

Les applications détectées uniquement dans le navigateur affichent Score de réputation pas encore disponible et Aucun accès à un compte confirmé par une source connectée. L'adoption du SSO reste indisponible tant qu'une source connectée n'a pas confirmé l'accès à un compte. Les lignes d'usage navigateur et d'extension observées ne proposent aucune remédiation sur les comptes. Seuls les indices confirmés par un connecteur éligible peuvent proposer une action de distribution ou de révocation prise en charge.

Ce volet vous permet également d'attribuer un propriétaire, de définir le caractère critique de l'application pour l'activité et de mettre à jour sa politique d'utilisation.

Ajouter un domaine d'application

Utilisez Ajouter un domaine d’application pour définir la politique d'utilisation d'une application qu'elba n'a pas encore observée, par exemple pour bloquer un outil avant que les employés ne commencent à l'utiliser. Les propriétaires et administrateurs de l'organisation peuvent ajouter un domaine depuis l'inventaire.

1. Ouvrez Third-Party Apps → Inventaire et sélectionnez Ajouter un domaine d’application.
2. Dans Domaine de l’application, saisissez uniquement le domaine, par exemple app.exemple.fr, et non une URL complète.
3. Si vous le souhaitez, saisissez un Nom de l’application. Il n'est affiché que jusqu'à ce qu'elba identifie l'application.
4. Choisissez la Politique d’utilisation. Non approuvée est sélectionnée par défaut ; À examiner et Approuvée sont également disponibles.
5. Sélectionnez Vérifier l’accès via le navigateur et lisez l'aperçu. Il indique si un playbook Browser Security actif bloquera le domaine, le message que verront alors les employés et si le domaine appartient à une application déjà connue d'elba.
6. Si vous avez saisi un sous-domaine, confirmez que la politique s'applique au domaine enregistrable, sous-domaines inclus. Un nom de domaine internationalisé est enregistré sous sa forme ASCII, que vous confirmez également.
7. Sélectionnez Ajouter le domaine avec la politique « … », par exemple Ajouter le domaine avec la politique « Non approuvée ».

elba refuse les domaines qu'il ne peut pas cibler en toute sécurité :

• les URL, chemins, ports, adresses e-mail et adresses IP ;
• les suffixes publics, comme com ou co.uk ;
• les domaines d'hébergement partagé, comme customer.github.io ;
• les domaines globaux d'éditeurs utilisés par de nombreux produits, comme google.com ou microsoft.com ;
• un domaine qui possède déjà une cible active dans votre organisation ou qui correspond à plusieurs applications.

Le nom de l'application ne peut contenir ni URL, ni domaine, ni adresse e-mail, ni adresse IP.

Fonctionnement d'un domaine ajouté

• Browser Security ne bloque le domaine que si sa politique est Non approuvée et qu'un playbook Browser Security actif utilise le déclencheur Application non autorisée visitée avec l'action Bloquer l'accès à la page. Le blocage couvre le domaine enregistrable et ses sous-domaines, et commence après l'actualisation de la configuration des extensions de navigateur inscrites.
• Un domaine qu'elba n'a pas observé apparaît dans l'inventaire sans utilisateur, avec le badge Non observée. Sa fiche affiche Définie par un administrateur et Non observée. elba ne crée pour lui aucun utilisateur, compte ni usage.
• Si le domaine appartient déjà à une application de votre inventaire ou du catalogue d'elba, la politique s'applique à cette application au lieu de créer une nouvelle entrée.
• Lorsque Browser Security observe ensuite l'application sur ce domaine, les utilisateurs et usages observés rejoignent la même entrée, le badge Non observée disparaît et votre politique est conservée. Si elba identifie ensuite le domaine comme une application du catalogue, l'entrée et sa politique sont rattachées à cette application.
• Modifiez ensuite la politique depuis la colonne Politique d’utilisation ou la fiche de l'application. Les applications associées à un domaine ajouté ne peuvent pas être sélectionnées pour les actions groupées.

Supprimer un domaine ajouté

Ouvrez la fiche de l'application, sélectionnez Supprimer la cible, puis confirmez avec Supprimer la cible. elba rétablit la politique d'utilisation que l'application avait avant l'ajout du domaine et conserve les indices, utilisateurs et historiques d'usage observés. Une application qu'elba n'a jamais observée disparaît de l'inventaire.

Applications gérées dans Okta

Lorsque Okta est le fournisseur d'identité elba de votre organisation, ou lorsque vous connectez une application API Services Okta pour Third-Party Apps, elba lit les applications Okta attribuées à chaque personne synchronisée dans elba, directement ou via un groupe Okta, ainsi que le mode de connexion de chaque application : SSO fédéré (SAML, OpenID Connect ou WS-Federation), coffre-fort de mots de passe (SWA) ou favori (bookmark). elba se contente de lire Okta ; modifiez les attributions dans la console d'administration Okta.

• Chaque attribution apparaît avec la mention Attribuée dans Okta pour cette personne et cette application. Confirmée par une source connectée, elle compte comme un accès dans les totaux d'utilisateurs et d'accès, mais n'ouvre jamais d'alerte, ne reçoit aucun tag et ne modifie jamais la politique d'utilisation de l'application.
• Lorsqu'une application est fédérée dans Okta et attribuée à une personne, sa méthode de connexion indique le SSO via Okta au lieu d'un mot de passe déduit de l'activité e-mail. Les applications de coffre-fort de mots de passe et les favoris sont gérés dans Okta, mais ne comptent pas comme du SSO.
• Dès que votre organisation a des attributions Okta, l'inventaire propose deux filtres : Géré dans Okta affiche les applications ayant des attributions Okta, et Non géré dans Okta met en évidence les applications sans attribution Okta utilisées par au moins 5 personnes, d'après une source connectée ou l'extension navigateur. Activez Inclure les applications vues seulement par e-mail pour compter aussi les applications repérées uniquement dans les e-mails. Une application non gérée dans Okta n'est pas, pour autant, non autorisée ou risquée.
• Une fois qu'elba lit les connexions Okta, chaque attribution Okta indique la dernière connexion de la personne via Okta, et le filtre Attribué, sans connexion Okta depuis 90 jours affiche les applications attribuées à quelqu'un il y a plus de 90 jours qui ne s'y est pas connecté via Okta depuis. Parmi les utilisateurs de l'application, cette attribution porte la mention Aucune connexion depuis 90 jours. Ce sont des attributions candidates au retrait dans Okta ; les favoris n'y apparaissent jamais.

Seules les applications Okta qu'elba peut associer avec certitude à son catalogue d'applications apparaissent. Les autres sont ignorées : une application absente du filtre Géré dans Okta peut donc exister dans Okta. Les attributions sont actualisées après chaque synchronisation de l'annuaire Okta, ou chaque jour pour une application API Services. L'intégration de service Okta doit disposer d'un rôle administrateur capable de lire toutes les applications, et les connexions nécessitent okta.logs.read ; consultez Connecter Okta.

Examiner les alertes

L'onglet Alertes est la file de traitement des risques détectés liés aux comptes et aux autorisations. Vous pouvez filtrer les alertes par membre, groupe, source, statut, dates, politique d'utilisation, application, éditeur, catégorie, hébergement, informations de conformité, classification IA, réputation, autorisations risquées, CVE ou fuite de données.

Les actions groupées disponibles dépendent de la source et de l'état de l'alerte. Elles peuvent inclure :

• Distribuer les alertes aux employés inscrits
• Ignorer les alertes sélectionnées
• Révoquer les autorisations lorsque la source le permet

Une alerte n'est pas envoyée automatiquement à un employé lorsqu'elle est détectée. Sa distribution est déclenchée par une action d'administrateur ou un playbook actif.

Rouvrir une alerte ignorée par un administrateur

Un administrateur ou propriétaire de l'organisation peut corriger une décision d'ignorer une alerte Third-Party Apps prise par erreur.

1. Ouvrez Third-Party Apps → Alertes. Utilisez le filtre de statut pour inclure les alertes terminées par un administrateur avec la décision Ignorée ; la liste active par défaut masque les décisions terminées.
2. Ouvrez l'alerte ignorée et sélectionnez Rouvrir l’alerte.
3. Vérifiez la confirmation. Sélectionnez Annuler pour laisser l'alerte inchangée, ou Rouvrir l’alerte pour confirmer.
4. Après le message de confirmation, l'alerte revient à l'état Détectée dans la liste active par défaut. Vous pouvez l'examiner et utiliser à nouveau les actions habituelles de distribution ou de résolution prises en charge.

La réouverture conserve l'application, la source, le membre associé, les éléments de preuve et la décision précédente d'ignorer l'alerte. L'historique indique qui l'a rouverte et à quel moment. L'accès à l'application et l'état du membre restent inchangés ; la réouverture ne révoque ni ne rétablit d'accès externe. Vérifiez vos playbooks actifs avant de remettre une alerte dans la file de traitement.

La réouverture concerne les alertes individuelles ignorées par un administrateur. Elle n'est pas disponible pour les alertes terminées par un employé, les décisions Changements réalisés ou les alertes dont la remédiation a commencé. La réouverture groupée n'est pas prise en charge. Si un message d'erreur s'affiche, actualisez l'alerte et vérifiez son statut actuel avant de réessayer.

Configurer des playbooks

Ouvrez Playbooks pour sélectionner un modèle ou créer un processus. L'éditeur propose uniquement les déclencheurs, conditions et actions pris en charge par la source sélectionnée. Un processus peut distribuer les alertes de vérification des autorisations prises en charge. Consultez Examiner les CVE et les fuites de données pour les vulnérabilités et incidents.

Si la surveillance des CVE ou des fuites est temporairement indisponible, l’action d’activation ou de reprise vous l’indique. Vous pouvez toujours consulter ou mettre en pause un playbook existant et modifier ses autres paramètres.

Avant l'activation :

1. Vérifiez que la source concernée est connectée et synchronisée.
2. Vérifiez le déclencheur et chaque condition.
3. Configurez des exclusions ou une liste d'autorisation lorsque la source le permet.
4. Vérifiez les destinataires de l'action et si une notification est envoyée immédiatement.
5. Activez le processus et surveillez son historique d'exécution.

Le moment de la notification dépend du processus et des paramètres de communication ; il n'existe pas de calendrier hebdomadaire fixe et universel.

Traitement par les employés

Les alertes distribuées apparaissent dans la Checklist de l'employé. Pour une alerte Third-Party Apps, l'employé peut :

• Ignorer l'alerte et continuer à utiliser l'application.
• Révoquer les permissions lorsque la source connectée prend en charge la révocation directe.

Si une connexion à une source présente une erreur, les actions qui modifient la source peuvent être temporairement indisponibles. Les administrateurs conservent l'historique de l'alerte et peuvent agir depuis l'onglet Alertes.

Processus de vérification recommandé

1. Connectez les sources concernées et attendez la fin de leur synchronisation initiale.
2. Commencez par Radar pour identifier les usages risqués, les applications vulnérables, les fuites, les Apps Shadow AI et les applications nouvellement découvertes.
3. Ouvrez Inventaire pour vérifier l'identité de l'application, la source et la fraîcheur des indices, son score de réputation, l'exposition des accès et son propriétaire métier.
4. Attribuez à l'application le statut À examiner, Approuvée ou Non approuvée conformément à votre politique.
5. Utilisez Alertes pour examiner les risques vérifiés au niveau des comptes ou des autorisations et appliquer les traitements pris en charge.
6. N'ajoutez un playbook qu'après avoir validé le public, les exclusions et les actions prévus.