L’idée « extravagante » à la base de la création d’Okta, en 200 par Todd McKinnon, était que l'identité des utilisateurs professionnels pouvait être gérée dans le cloud. Dans une interview accordée à notre confrère InfoWorld en 2013, il avait affirmé que la migration massive vers le cloud public était inévitable. Comme il l’avait prévu, le nombre et la diversité des applications dans le cloud ont explosé, et Okta a joué un rôle de plus en plus important dans la gestion des identités et des accès dans le cloud (IAM). Par la suite, l’introduction en bourse de l’entreprise en 2017 a rencontré un fort succès. Aujourd'hui, Okta se positionne autant comme un service cloud d’IAM capable de contrôler des milliers d'applications. L'entreprise s'aventure également dans l'IAM de machine à machine, une composante clé du modèle de réseaux zero trust.

Dans cette interview menée par nos confrères de CSO, M. McKinnon a parlé très directement de la feuille de route d'Okta et donné son avis sur plusieurs questions de sécurité actuelles. La conversation a débuté par une brève discussion sur le passage au travail à domicile et l'adoption accélérée des applications cloud qui s’en est suivie, en particulier les services de collaboration et de vidéoconférence, offrant encore plus d'opportunités à Okta. Comme le dit le dirigeant, « c'est formidable pour nous, même si ça fait mal de dire ça à cause de la pandémie ». Ensuite, la conversation s’est déplacée vers la menace persistance avancée la plus dommageable jamais découverte.

Quel est votre point de vue sur l'attaque SolarWinds et ses implications ?

L’attaque SolarWinds a mis en lumière un certain nombre de choses. La première, c’est que l’IT on prem n'est pas nécessairement plus sûre que l’IT dans le cloud. La seconde, c’est un renforcement massif et concret du concept de zero trust. Prenons l'exemple de Google qui a adopté le zero trust parce que des pirates chinois ont essayé de compromettre ses réseaux. Google a été intelligent et a modifié toute son infrastructure pour ne plus faire confiance à rien sur le réseau, à l'intérieur comme à l'extérieur.

Une entreprise moyenne n’a pas les moyens financiers et ne peut pas consacrer autant de temps que Google pour cela. Alors elle commence par les accès distants à la périphérie. Elle se dit notamment qu’elle ne peut pas appliquer le zero trust à tous les périphériques partout dans le monde, mais qu’elle peut au minimum le mettre en place sur les ordinateurs portables que ses employés utilisent à domicile. Mais ce que nous apprend aussi l’attaque SolarWinds, c'est que l’on ne peut pas faire les choses à moitié, et qu’il faut étendre la confiance zéro au backend. Un serveur ne peut pas faire confiance à un autre serveur sur le réseau. La raison pour laquelle les gens s’excitent, c’est que c'est difficile à mettre en place. C'est une chose d'avoir des PC portables connectés en mode zero trust, mais c'en est une autre de l’appliquer à l’ensemble des applications et des infrastructures internes. Cela signifie donc qu'il faut une plus grande exigence en matière d'identité des machines.

C’est donc une grande opportunité pour l'IAM ?

Oui. Notre produit appelé Advanced Server Access a vraiment fait ses preuves pour authentifier les administrateurs aux machines, et l’on peut appliquer les mêmes principes pour faire de l’authentification de machine à machine.

La sécurité multicloud représente un autre gros problème. Les trois grands fournisseurs de cloud ont des modèles de sécurité différents, des contrôles et des caractéristiques de sécurité différents. Il est donc facile de faire une erreur de configuration et de laisser une porte ouverte. Que proposez-vous pour résoudre ce problème ?

Advanced Server Access apporte une couche de sécurité pour les cloud. C’est sa raison d’être.

Une méta-couche de sécurité pour les clouds ?

Oui, exactement, c’est une sorte de couche de sécurité commune. En gros, vous authentifiez vos administrateurs, vous vous connectez au cloud via Okta, si bien que vous n'avez pas à coupler étroitement votre sécurité, vos processus, votre gouvernance, etc. à la chaîne d'outils d'une plate-forme.

Votre feuille de route prévoit-elle d'aller au-delà de l'identité avec ce produit ?

Oui, il le faut. C'est une réponse un peu nuancée, car vous verrez que nous allons dépasser l'identité, mais dans des usages qui bénéficient de l'identité, si cela a un sens. Nous ne ferons rien qui ne soit pas intégré à l'identité.

Les trois grands clouds sont dynamiques sur le plan des fonctionnalités. Ce n’est pas simple de suivre le flux de toutes ces évolutions et de savoir ce qui doit être verrouillé.

Oui, c'est un défi, mais nous ne résoudrons pas l'ensemble des problèmes. Notre stratégie consiste à nous connecter à tout et à laisser le client disposer d'une couche de politique cohérente autour de tout. Nous réussissons plutôt bien dans ce domaine, mais nous pouvons faire plus. Au même titre que nous pouvons nous connecter au-delà des serveurs, nous devrions aussi pouvoir nous connecter à différents services spécifiques à l'intérieur des cloud. Ils utilisent beaucoup d’API spécifiques que nous sommes encore en train d'intégrer.

Y a-t-il des standards émergents que vous soutenez ou que vous considérez comme prometteuses et qui pourraient faire partie de cette méta-couche de sécurité multicloud ?

L'un des concepts clé du zero trust, c’est l'authentification continue. Schématiquement, il y a deux façons de l’appliquer. Soit en se plaçant dans le chemin du réseau, comme un proxy. Dans ce cas, si vous détectez un logiciel malveillant, vous pouvez bloquer le chemin du réseau pour que le dispositif compromis ne puisse se connecter à rien. Une autre solution consiste à développer un standard qui permet aux applications et aux appareils de partager cet état d'authentification continu et de fermer la session quand la compromission se produit. Ainsi, au lieu de se placer dans le chemin du réseau et de fermer vos connexions réseau et votre messagerie électronique quand votre appareil est compromis, une solutions standardisée permettrait de vérifier à tout moment et sans perturber le réseau que l'authentification est encore bonne. Cela pourrait être fait à l’échelle et sans trop de travail de configuration.

Que pensez-vous de la notion d'identité auto-souveraine ?

Je pense que l’identité auto-souveraine est l'avenir. Nous devons aller vers ça. Auparavant, il faudra répondre à la question : comment s'y prendre pour l'amorcer ? Comment faire pour qu’elle soit utile dans suffisamment de situations pour qu'un nombre suffisant de personnes l'utilisent pour la rendre utile ? D'où va-t-elle venir ? Sera-t-elle fournie par un grand média social ou un grand fournisseur de technologies de l'information ? Ou doit-elle provenir d'un fournisseur d'identificateurs indépendant comme Okta ?

La solution pourrait venir des spécialistes en chiffrement, non ?

Oui, c’est une possibilité. L’authentification de l'identité est essentielle pour les systèmes de paiement. Il faut pouvoir connaître avec certitude l’identité du payeur. On peut donc dire que c'est possible. Le problème, c’est que, dans le chiffrement, il y a des standards, mais il y a aussi beaucoup d'infrastructures qui ne sont pas intégrées dans les standards. Le défi est donc de savoir... pourquoi un portefeuille de devises numériques comme Coinbase existe ? Aucune portion du standard de cryptographie ne définit comment entrer et sortir d’une monnaie souveraine. Aucun élément ne spécifie non plus comment on y fait entrer et sortir l'identité.

L'identité souveraine est-elle une chose que vous cherchez à défendre ?

Oui. Nous nous y intéressons. Honnêtement, nous explorons de nouvelles pistes et nous réfléchissons à certaines solutions, mais nous ne savons pas encore comment nous allons résoudre le problème du déclenchement. Nous avons aussi beaucoup d'atouts, de clients et d'utilisateurs. Mais nous cherchons toujours comment y arriver.