Résumé

  • La violation de clé AWS de 2017 chez OneLogin est devenue un test de responsabilité pour le fournisseur d'identité, car les déclarations contemporaines de OneLogin ont fait état d'un accès non autorisé dans la région américaine des données, ont ensuite décrit un attaquant utilisant des clés AWS pour accéder à l'API AWS, et ont conseillé aux clients de prendre des mesures de correction larges concernant les clés, certificats, jetons, secrets et mots de passe.
  • Qui avait le contrôle pratique sur le stockage des clés AWS, le chiffrement des données client, l'isolement du fournisseur d'identité, l'invalidation des jetons, les conseils de correction client, le calendrier de divulgation et la preuve que la compromission SSO n'a pas laissé d'exposition durable du compte?
  • Le problème de responsabilité est qu'un fournisseur d'identité concentre le risque d'accès client, de sorte qu'une compromission de clé cloud devient un test de gouvernance de la segmentation, du chiffrement et de la preuve de réparation client.
  • Les clients entreprises, les employés, les administrateurs, les fournisseurs SaaS en aval, les équipes de sécurité, les auditeurs et les régulateurs avaient besoin de preuves que la chaîne de confiance d'identité pouvait être réinitialisée et vérifiée, plutôt que simplement déclarée rétablie.
  • Cet article traite des reportages contemporains qui ont cité l'avis de sécurité de OneLogin et les conseils aux clients comme preuves pour l'incident de 2017, des documents de OneLogin et One Identity comme preuves du contexte du produit et de la résidence régionale, des documents AWS et des normes comme vocabulaire de contrôle, et des analyses tierces uniquement comme support pour les leçons sur la réponse aux incidents et les clés cloud.

Pourquoi ce cas fait partie d'un dossier de risques et de responsabilité

OneLogin fait partie d'un dossier de risques et de responsabilité car le service n'était pas une application ordinaire détenant un seul ensemble de données. C'était un fournisseur d'identité. Les entreprises l'utilisaient pour médiatiser l'accès à de nombreuses autres applications, pour émettre des assertions SAML, pour prendre en charge les flux OAuth et OpenID Connect, pour automatiser le provisionnement et le déprovisionnement, et pour centraliser la politique d'authentification.

Lorsqu'un fournisseur d'identité subit un incident de clé d'infrastructure, la question du préjudice est plus large que de savoir si une base de données a été touchée. La question pratique devient de savoir si la chaîne de confiance que les clients utilisent pour accéder à d'autres services cloud peut être réinitialisée avant qu'un attaquant ne puisse convertir une exposition côté fournisseur en un accès en aval durable.

Le dossier public commence par la divulgation de OneLogin le 31 mai 2017 telle que rapportée par Krebs on Security àhttps://krebsonsecurity.com/2017/06/onelogin-breach-exposed-ability-to-decrypt-data/et par SecurityWeek àhttps://www.securityweek.com/onelogin-shares-more-details-breach-customer-impact/. Ces articles citaient OneLogin disant qu'il avait détecté un accès non autorisé aux données de OneLogin dans sa région américaine, bloqué l'accès, signalé l'affaire aux forces de l'ordre et travaillé avec un cabinet de sécurité indépendant. Une mise à jour ultérieure de OneLogin citée dans les mêmes rapports publics indiquait qu'un acteur malveillant avait obtenu des clés AWS, les avait utilisées pour accéder à l'API AWS depuis un fournisseur intermédiaire américain, créé des instances pour la reconnaissance, et accédé à des tables de base de données contenant des informations sur les utilisateurs, les applications et les types de clés. Le rapport indiquait également que OneLogin ne pouvait pas exclure la possibilité que l'attaquant ait obtenu la capacité de déchiffrer des données.

Cette combinaison a fait de ce cas un test de responsabilité. Les clés AWS ne sont pas de simples mots de passe. Dans un environnement d'infrastructure en tant que service, elles peuvent créer des instances, lire des métadonnées, se déplacer entre les services et atteindre des bases de données selon les autorisations. Le modèle de responsabilité partagée d'AWS àhttps://aws.amazon.com/compliance/shared-responsibility-model/clarifie la ligne: AWS sécurise l'infrastructure cloud sous-jacente, tandis que le client utilisant AWS reste responsable de l'identité, de l'accès, de la configuration des données et des contrôles applicatifs. Dans ce cas, OneLogin était le client AWS, et les clients entreprises de OneLogin étaient des parties dépendantes. La chaîne de responsabilité traversait donc trois niveaux: fournisseur cloud, fournisseur d'identité et locataire client.

La question est pratique: qui avait le contrôle pratique sur le stockage des clés AWS, le chiffrement des données client, l'isolement du fournisseur d'identité, l'invalidation des jetons, les conseils de correction client, le calendrier de divulgation et la preuve que la compromission SSO n'a pas laissé d'exposition durable du compte? La réponse ne peut pas s'arrêter à « faire pivoter les clés ». La rotation est nécessaire, mais elle n'est qu'une partie de la réparation de l'identité.

Les clients devaient savoir quels objets de confiance étaient affectés, lesquels étaient potentiellement affectés, lesquels devaient être remplacés immédiatement, lesquels pouvaient être surveillés, et quelles preuves démontreraient la clôture.

Le positionnement actuel du produit OneLogin àhttps://www.onelogin.com/met l'accent sur la gestion centralisée des identités pour les employés, les clients et les partenaires, des milliers d'intégrations d'applications, l'authentification adaptative et la gestion automatisée du cycle de vie. Ce positionnement explique les enjeux de l'incident de 2017. Un fournisseur qui centralise l'accès réduit la fragmentation quand cela fonctionne. Lorsque son propre plan de contrôle est compromis, il peut aussi concentrer l'incertitude. Le dossier de réparation responsable doit montrer que la centralisation ne devient pas un rayon d'explosion illimité.

Les incidents chez les fournisseurs d'identité ne sont pas des violations de données ordinaires

De nombreuses analyses de violations comptent les enregistrements. Les incidents chez les fournisseurs d'identité nécessitent une mesure différente. Un fournisseur d'identité stocke ou médiatise les identités utilisateur, les affectations d'applications, les paramètres de fédération, les certificats de signature, les informations d'identification API, les intégrations MFA, les connecteurs d'applications, les contrôles de session et la politique administrative. Certains de ces objets sont des données. D'autres sont de l'autorité. D'autres sont des cartes de l'endroit où l'autorité est acceptée.

Si un attaquant voit la carte et peut voir les objets qui prouvent l'autorité, les clients en aval doivent supposer que l'incident peut se propager au-delà des limites du compte du fournisseur.

La documentation développeur de OneLogin montre pourquoi. L'aperçu de l'API àhttps://developers.onelogin.com/api-docs/1/getting-started/dev-overviewindique que l'API est sécurisée par OAuth 2.0 et utilise le sous-domaine OneLogin du client comme domaine API. La page des informations d'identification API àhttps://developers.onelogin.com/api-docs/1/getting-started/working-with-api-credentialsexplique que les appels API nécessitent un jeton d'accès porteur OAuth obtenu avec une paire d'identifiants. La page de génération de jetons àhttps://developers.onelogin.com/api-docs/2/oauth20-tokens/generate-tokens-2décrit la génération de jetons d'accès et de rafraîchissement pour les API de ressources. Ces documents sont la documentation produit actuelle, non des preuves médico-légales de l'incident de 2017. Ils illustrent la vérité générale du fournisseur d'identité: les jetons, les clients, les secrets, les domaines et les rôles sont de l'autorité opérationnelle, et non des métadonnées passives.

Il en va de même pour la fédération. L'aperçu SAML de OneLogin àhttps://developers.onelogin.com/samldécrit OneLogin comme un outil permettant l'authentification unique avec SAML. Son aperçu OpenID Connect àhttps://developers.onelogin.com/openid-connectdécrit OpenID Connect comme une couche d'identité au-dessus d'OAuth 2.0. La page de l'API de déconnexion àhttps://developers.onelogin.com/openid-connect/api/logoutdécrit la fin d'une session OneLogin et la révocation des jetons émis sous cette session SSO. Là encore, ce sont des documents produit plutôt que des faits d'incident, mais ils expliquent pourquoi la charge de correction client après un incident chez un fournisseur d'identité peut être importante. La confiance de fédération est acceptée par les fournisseurs de services car les certificats, jetons, points de terminaison et métadonnées indiquent que le fournisseur d'identité est autoritaire.

L'analyse contemporaine de la réponse client par Ryan McGeehan àhttps://magoo.medium.com/onelogin-breach-2017-retrospective-708305d83e2dreflétait cette charge pratique. L'article renvoyait explicitement les lecteurs à l'article de support de OneLogin comme source de vérité, puis discutait des actions client telles que la rotation des certificats SAML, des secrets d'intégration 2FA, des contenus Secure Notes, des mots de passe non SAML, des identifiants API et des objets de confiance associés. Cet article n'est pas un post-mortem de OneLogin, mais il est précieux car il montre ce que les praticiens comprenaient comme nécessaire en termes de rayon d'explosion: une réinitialisation coordonnée de l'identité, pas un simple changement de mot de passe.

La norme de responsabilité pour ce type d'incident est donc plus élevée que « les données client ont été consultées ».