Depuis au moins février 2025, Okta Threat Intelligence a suivi une campagne d'extorsion dans laquelle des cybercriminels ont utilisé le social engineering vocal, le phishing d'identifiants et le phishing de terminaux pour accéder et exfiltrer des données des environnements Salesforce.
Des attaquants se sont fait passer pour des membres du personnel de support technique lors d'appels téléphoniques à des utilisateurs ciblés. Ces utilisateurs ont souvent été trompés lors de ces appels pour autoriser une application OAuth contrôlée par un attaquant (« Salesforce Data Loader ») à accéder à leur organisation Salesforce. En conséquence, l'application a obtenu les autorisations nécessaires pour accéder aux données dans le contexte de l'utilisateur et les exfiltrer.
Une campagne initiale d'attaques de phishing d'identifiants en février 2025 a ciblé des dizaines d'Organizations. À partir de mars 2025, les attaquants ont pivoté vers l'utilisation du phishing par code de terminal dans des attaques qui ont exfiltré des données de Google, Workday et bien d'autres.
Une question qui mérite d'être posée est la suivante : pourquoi ces attaques relativement simples sont-elles efficaces contre plusieurs Organizations disposant de programmes de sécurité bien financés ?
La réponse réside dans deux attentes irréalistes :
Il est inacceptable de s’attendre à ce que les utilisateurs puissent systématiquement faire la distinction entre une application OAuth bénigne et une application malveillante. Dans ces attaques, un utilisateur est dirigé pour interagir avec des pages de connexion et de consentement authentiques d'un domaine de confiance et reçoit peu de contexte pour examiner l'application qui demande l'accès. Les programmes de sensibilisation à la sécurité peuvent jouer un rôle d’atténuation, mais ne doivent pas être le contrôle principal.
Il est complexe et inefficace pour les administrateurs de la sécurité de gérer (c.-à-d. établir une liste d'autorisation) des milliers de connexions OAuth à des centaines d'applications principales sur une base point à point.
L’équipe sécurité interne d’Okta, par exemple, a bloqué des milliers d’intégrations OAuth qui cherchaient à obtenir un certain niveau d’accès à l’une de nos principales plateformes de productivité. L'Enterprise moyenne dispose de plus de 200 applications principales, dont des dizaines aspirent à être suffisamment extensibles pour être considérées comme une « plateforme ».
Cette complexité augmentera à mesure que les agents d'IA demanderont l'accès à des ressources protégées pour effectuer des tâches au nom des utilisateurs. L'IA agentique finira par porter cette crise d'autorisation à son paroxysme : notre secteur n'a guère d'autre choix que de repenser l'autorisation d'application à application pour un monde agentique.
Par défaut, la plupart des écosystèmes d'applications Enterprise ont historiquement permis aux utilisateurs de consentir à ce que des applications tierces accèdent aux données de leur compte. Microsoft a annoncé son intention de revenir sur sa décision pour toutes les nouvelles applications Azure d'ici la fin août 2025, et Salesforce a annoncé que les utilisateurs ne pourront plus consentir à autoriser les applications connectées non installées à partir de la fin septembre 2025.
Les contrôles dont disposent les équipes sécurité pour autoriser les connexions tierces sont très fragmentés. Les Organizations peuvent externaliser l'évaluation de la réputation des applications OAuth à des fournisseurs tiers, mais cela ne s'adapte déjà pas bien aujourd'hui et deviendra ingérable dans un contexte agentique.
Pour résoudre les problèmes actuels et sécuriser l'avenir agentique, nous devons d'abord aborder ce problème fondamental d'autorisation d'application à application.
L'endroit le plus logique pour résoudre ce problème est au niveau du fournisseur d'identité (IdP). Aujourd'hui, les politiques d'authentification configurées chez le fournisseur d'identité déterminent quels utilisateurs peuvent accéder à quelles ressources sous un ensemble de conditions spécifiées. L'authentification unique (SSO) peut être utilisée pour réduire le nombre d'identifiants qu'un utilisateur doit mémoriser, ainsi que pour diminuer le nombre total de demandes d'authentification qu'il doit satisfaire. Il est logique de régir l'autorisation des échanges de données entre ces mêmes applications via le même moteur de politiques.
Okta a proposé Cross App Access comme un moyen de rétablir la visibilité et le contrôle de l'écosystème d'applications pour les équipes informatiques et sécurité. La promesse de Cross App Access est de centraliser la visibilité et le contrôle des connexions entre applications et entre agents et applications.
Construit sur les flux OAuth standard de l'industrie, Cross App Access donnerait aux administrateurs la priorité sur les données auxquelles les applications ou agents peuvent accéder depuis Enterprise.
Figure 1 : Gestion de l'autorisation application-to-application et agent-to-application au niveau du fournisseur d'identité (Identity Provider ou fournisseur d'identité)
Les demandes d'accès provenant d'un agent ou d'une application non autorisé pourraient par la suite être auditées ou bloquées au niveau du fournisseur d'identité, plutôt qu'au sein de chaque application individuelle ou à l'aide d'outils de sécurité tiers.
Et tout comme l'authentification unique (SSO), la centralisation des décisions d'autorisation au niveau du fournisseur d'identité a le potentiel de réduire la charge cognitive des utilisateurs. Si une intégration entre deux applications est pré-approuvée dans la politique par les administrateurs de sécurité, et qu'un utilisateur est connecté aux deux applications à l'aide de l'authentification unique (SSO), les administrateurs peuvent avoir la confiance nécessaire pour réduire le nombre total de demandes d'authentification auxquelles un utilisateur est confronté.
Lorsque l'industrie adoptera Cross App Access, nous pourrons raisonnablement alléger le fardeau des utilisateurs qui doivent déterminer si une intégration d'application donnée est légitime ou malveillante. Les utilisateurs ne pourront consentir qu'à un ensemble de connexions autorisées, avec un périmètre des données requises prédéfini, et dans de nombreux cas, ils n'auront pas besoin de se voir présenter un écran de consentement.
Recommandations pour les éditeurs de logiciels indépendants (ISV)
Nous recommandons aux ISVs et aux développeurs de se renseigner sur l'intégration de Cross App Access et de préparer le support des standards émergents qui le sous-tendent.
Recommandations pour les CISO
Aidez à sensibiliser vos pairs et les fournisseurs de logiciels Enterprise à Cross application Access.
Inscrivez les utilisateurs à des authentificateurs résistants au phishing, tels que Okta FastPass ou des passkeys, et appliquez la résistance au phishing dans la politique.
Vérifiez quelles applications existantes supportent les connexions d'application à application ou d'agent à application via OAuth. Envisagez une approche progressive de l'autorisation.
Offrez à l’équipe sécurité une visibilité sur les applications attribuées aux utilisateurs grâce aux outils de gestion du niveau de sécurité des identités (ISPM).
Menez des exercices de sensibilisation à la sécurité qui simulent le phishing par demande de consentement afin d'éduquer les utilisateurs sur les risques d'approuver des intégrations d'applications non autorisées et non sollicitées.
Assurez-vous que votre contact principal de sécurité chez Okta est à jour pour accéder aux derniers avis de menace d'Okta Threat Intelligence. Veuillez noter que le contact de sécurité principal peut désormais inviter d'autres utilisateurs de son Organizations à consulter des documents, sans avoir à les ajouter à la fiche de contact. La fonction Inviter un collègue se trouve dans le profil utilisateur après vous être connecté à okta-security.helptechsolucoes.com.br
