Refael Angel, Co-Fondateur et CTO d’Akeyless – Série d’entretiens

Refael Angel, Co-Fondateur et CTO d’Akeyless, est un leader en cybersécurité et en ingénierie logicielle avec une expérience approfondie en sécurité cloud, cryptage, authentification de machine et infrastructure d’entreprise. Depuis la co-fondation d’Akeyless en 2018, il a aidé à construire l’entreprise autour d’une gestion moderne des secrets et de la sécurité d’identité pour les environnements cloud natifs. Avant Akeyless, il a travaillé en tant qu’ingénieur logiciel senior en sécurité chez Intuit (INTU ), où il a conçu des systèmes pour la gestion des clés de cryptage de cloud public et l’authentification de machine, acquérant une expérience pratique sur AWS, Go, Python, Java, PHP, Bash, Linux, Git et Jenkins. Plus tôt dans sa carrière, Angel a occupé des postes d’ingénieur logiciel chez 3D Systems (DDD ) et Cimatron, développant des applications CAD/CAM et basées sur Windows en utilisant C/C++, C#, WPF, MFC et des modèles de conception orientés objet.

Akeyless est une entreprise de sécurité d’identité axée sur la sécurisation des machines, des agents IA et des humains grâce à une plate-forme cloud native construite autour de la cryptographie à connaissance zéro. Sa plate-forme réunit la gestion des secrets, la gestion des clés de cryptage, la gestion du cycle de vie des certificats, l’accès privilégié et la sécurité d’identité de machine, offrant aux organisations une manière unifiée de gérer les informations d’identification, les clés, les certificats et les accès à travers des environnements hybrides, multi-cloud, DevOps et IA. La position de l’entreprise reflète un changement plus large dans la cybersécurité : à mesure que les charges de travail, les services et les agents IA effectuent de plus en plus l’accès au système sans implication humaine directe, les entreprises ont besoin de contrôles plus solides autour des identités non humaines, des informations d’identification à durée de vie courte, de la rotation automatisée et de la gouvernance à l’exécution.

Vous avez co-fondé Akeyless en 2018 après avoir conçu des systèmes de gestion de clés de cryptage et d’authentification de machine chez Intuit. Quelle faille dans la sécurité cloud et la gestion des identités vous a convaincu qu’il était temps de lancer Akeyless, et comment cette vision originale a-t-elle évolué à mesure que les agents IA sont apparus comme une nouvelle classe d’identités numériques ?

Chez Intuit, j’ai fait partie de l’équipe qui a conçu des systèmes de gestion de clés de cryptage et d’authentification de machine à une époque où Intuit était l’une des premières grandes entreprises à migrer vers le cloud. Ce qui m’est devenu clair, c’est que chaque organisation adoptant le cloud finirait par faire face au même problème que nous résolvions en interne : gérer les secrets et les clés à travers une infrastructure distribuée et dynamique. Construire cela en interne consomme d’énormes ressources d’ingénierie, et cela n’a pas de sens que chaque entreprise réinvente la roue. La réponse logique était un modèle SaaS.

Le hic, c’était la confiance. Il s’agit du matériel le plus sensible que possède une entreprise, et aucune organisation sérieuse ne confiera à un tiers la capacité d’y accéder. Le besoin était presque contradictoire : offrir cela en tant que SaaS pour l’échelle et la simplicité, tout en rendant architecturalement impossible pour le fournisseur de jamais voir les données du client. Cette tension est exactement ce qui a donné naissance à la cryptographie à fragments distribués (DFC). La DFC nous permet de faire fonctionner un plan de contrôle SaaS entièrement géré tandis que le client détient un fragment que nous ne possédons jamais, nous sommes donc mathématiquement incapables d’accéder à ses clés. C’est devenu la base du modèle SaaS plus Zero-Knowledge sur lequel Akeyless est construit.

La vision originale concernait la sécurisation de l’accès humain et de la machine dans le cloud. Les agents IA sont l’extension la plus extrême et la plus naturelle du même problème. Ils sont des identités non humaines opérant à une échelle et à une vitesse que aucun répertoire n’a été conçu pour gérer, et la même fondation Zero-Knowledge et centrée sur l’identité s’étend maintenant directement à eux.

On vous crédite d’être l’architecte derrière la technologie de cryptage Zero-Trust brevetée d’Akeyless. Quels ont été les plus grands défis techniques dans la construction d’un modèle de sécurité qui pouvait éliminer les hypothèses de confiance tout en restant pratique pour les grandes entreprises ?

La partie la plus difficile a été de rendre “ne faire confiance à personne” pratique plutôt qu’académique. La plupart des schémas de clés partagées ou de partage de secrets assemblent toujours la clé complète à un moment donné, généralement à l’intérieur d’un processus unique, d’un HSM ou d’un enclave au moment d’une opération cryptographique. Cette brève fenêtre est précisément ce que les attaquants, les insiders malveillants et les scénarios de contrainte légale ciblent.

Avec la DFC, la clé n’est jamais assemblée, pas lors de la création, pas au repos et pas lors de l’utilisation. Les fragments sont générés de manière indépendante dans des domaines de confiance distincts, et les opérations cryptographiques s’exécutent comme un calcul distribué où chaque détenteur de fragment calcule sa part localement et n’échange que des résultats partiels. Le défi d’ingénierie a été d’atteindre cela avec la latence, le débit et la fiabilité que les grandes entreprises exigent en production.

Un second défi, et l’un des plus importants, a été de permettre le rafraîchissement continu des fragments. Nous devions être en mesure de remplacer chaque fragment par une nouvelle valeur mathématique, à chaque emplacement, tout en gardant la clé maître que les fragments représentent inchangée et le processus cryptographique jamais perturbé. Cela a ajouté une couche de sécurité très substantielle à la solution. En raison du rafraîchissement, un attaquant ne peut plus collecter des fragments patiemment au fil du temps. Un fragment capturé la semaine dernière est mathématiquement sans rapport avec les fragments qui existent aujourd’hui, il s’agit donc de bruit plutôt que d’un avantage. Pour apprendre quelque chose sur une clé, un adversaire devrait compromettre chaque emplacement de fragment simultanément, dans une seule fenêtre de rafraîchissement, et cette exigence devient de plus en plus difficile à mesure que les emplacements, les domaines de confiance et la fréquence de rafraîchissement augmentent. Combiné avec le seuil tout ou rien, où 100 pour cent des fragments sont nécessaires pour révéler quelque chose et tout sous-ensemble strict fait fuir zéro d’informations, le rafraîchissement transforme le modèle de sécurité d’une garantie statique en une garantie liée au temps.

De nombreuses organisations sont en train de déployer des agents IA, mais la sécurité des identités reste souvent une après-pensée. Quelles sont les erreurs les plus courantes que les entreprises commettent lorsqu’elles accordent aux agents IA l’accès aux systèmes et aux données sensibles d’entreprise ?

L’erreur la plus importante est de traiter un agent comme un compte de service et de lui donner une clé API statique et à long terme. Cette information d’identification devient un actif permanent et récupérable qui se trouve à l’intérieur d’un acteur non déterministe et injectable de prompte.

Les autres erreurs courantes que je vois : accorder des privilèges permanents au lieu d’un accès juste-à-temps, s’appuyer sur des autorisations basées sur des rôles grossiers qui décrivent ce qu’un agent peut atteindre mais jamais ce qu’il intentionne de faire, donner aux agents des chemins de réseau directs vers les bases de données et les API afin qu’une faille de sécurité devienne un mouvement latéral, et n’avoir aucune chaîne d’audit qui relie une action d’agent à l’humain et à la prompte qui l’a déclenchée. Chacune de ces erreurs est une tentative de réutiliser les contrôles de l’ère humaine sur quelque chose qui ne se comporte pas comme un humain.

Akeyless a soutenu que les agents IA nécessitent un modèle d’identité fondamentalement différent de celui des humains ou des charges de travail de machine traditionnelles. Qu’est-ce qui rend les agents IA particulièrement difficiles à sécuriser par rapport aux cadres IAM et PAM existants ?

L’erreur fondamentale est de traiter les agents IA comme un nouveau type d’utilisateur, ou même comme un nouveau type de compte de service, et de supposer qu’ils peuvent être intégrés et gérés comme des identités humaines. C’est une erreur de catégorie, pour plusieurs raisons liées.

Les identités des agents ne sont pas énumérables. L’instance spécifique que vous souhaitez gérer n’existe généralement pas encore, et le moment où elle existe, elle a déjà disparu. Un agent peut se lancer sur un Lambda, s’exécuter pendant 800 millisecondes et disparaître avant que tout scanner ne le remarque, ou faire éclore des chaînes d’agents sous-jacents à travers des VM, des conteneurs et des serveurs sans serveur qui se terminent en quelques secondes. Enregistrer ceux-ci dans un répertoire revient à traiter des fantômes comme des résidents : au moment où l’entrée est validée, l’entité qu’elle décrit a disparu.

L’ancre appropriée n’est donc pas l’agent, mais l’identité de charge de travail que son exécution émet déjà, le rôle d’exécution AWS, le jeton de compte de service Kubernetes, le SVID SPIFFE. Cette identité existe déjà, est cautionnée par la plate-forme sur laquelle s’exécute l’agent et disparaît lorsque l’agent disparaît. Puisque les identités sont éphémères, les seules entités stables pour écrire des politiques entre elles sont les méthodes d’authentification et les systèmes cibles, et non les identités nommées et les étendues.

Et c’est là que les cadres IAM et PAM existants se brisent le plus décisivement : les rôles et les autorisations basés sur les attributs statiques ne peuvent pas contenir un acteur non déterministe. Un agent avec un jeton parfaitement étendu et une TTL parfaitement appliquée peut toujours être injecté de prompte, halluciner une requête destructive ou basculer d’une tâche de lecture à une tâche d’écriture dans la même session, sans aucune violation de politique visible au niveau de l’autorisation. Les rôles et les autorisations basés sur les attributs évaluent lors de l’authentification, et non après, car ce qui se passe après est décidé par un LLM qui examine une fenêtre de contexte que l’auteur de la politique ne peut pas voir.

Les agents sont donc particulièrement difficiles à sécuriser car ils sont éphémères, non déterministes, multi-sous-strate et injectables de prompte, tout à la fois. La couche manquante n’est pas un répertoire meilleur. Il s’agit d’une application d’exécution consciente de l’intention sur chaque action, médiatisée par une passerelle qui vérifie ce que l’agent fait réellement par rapport à ce qu’il a dit qu’il allait faire, avant que toute information d’identification ne soit créée.

Il y a un débat croissant autour des architectures “sans secret” pour les systèmes IA. Comment définissez-vous l’authentification sans secret, et pourquoi pensez-vous que les informations d’identification statiques et les clés API sont devenues insoutenables à l’ère des agents autonomes ?

L’authentification sans secret signifie que l’agent ne détient jamais d’information d’identification. Au lieu de donner à l’agent une clé qu’il doit stocker et présenter, l’agent s’authentifie via son identité de charge de travail native, et une information d’identification à court terme et juste-à-temps est injectée dans une session intermédiaire au moment de l’exécution, puis détruite lorsque la session se termine. L’agent ne la voit jamais.

Les informations d’identification statiques et les clés API sont devenues insoutenables pour une raison simple : un secret que détient un agent est un secret que peut voler un attaquant. Dans un monde où l’acteur qui détient l’information d’identification peut être injecté de prompte ou halluciner, une clé à long terme se transforme en fuite de clé à chaque agent compromis. Retirez l’information d’identification de l’agent et un agent compromis n’a rien à fuir. C’est tout le point de ce que nous appelons SecretlessAI.

À mesure que les agents IA gagnent la capacité de planifier, d’exécuter des actions et d’interagir avec plusieurs systèmes de manière indépendante, quels nouveaux vecteurs d’attaque vous inquiètent le plus au cours des trois à cinq prochaines années ?

Les vecteurs qui m’inquiètent le plus découlent tous de la capacité des agents à planifier et à agir de manière indépendante à travers plusieurs systèmes. L’injection de prompte qui détourne l’intention d’un agent en cours de tâche est le plus clair, car l’identité reste valide même si le comportement devient malveillant. Au-delà de cela, je m’inquiète des passes d’agent à agent où l’autorité est transmise le long d’une chaîne sans responsabilité claire, du mouvement latéral à travers des agents qui ont un accès réseau direct et de l’exfiltration de données où un agent sur-autorisé extrait beaucoup plus que ce dont sa tâche a besoin.

Le fil conducteur commun est que l’information d’identification et le rôle peuvent être parfaitement légitimes tandis que l’action ne l’est pas. Les défenses qui ne vérifient que les autorisations, et non l’intention, ne détecteront aucune de ces menaces. C’est pourquoi l’application consciente de l’intention à une passerelle, sur chaque action, est le contrôle que je pense comptera le plus.

En regardant vers l’avenir, pensez-vous que les entreprises finiront par nécessiter une couche d’identité dédiée pour les agents IA, similaire à la façon dont les fournisseurs d’identité sont devenus essentiels pour les utilisateurs humains, et à quoi ressemblera cette architecture future ?

Oui, mais cela ne ressemblera pas au modèle de fournisseur d’identité humaine simplement rebaptisé pour les agents. Essayer de construire un répertoire d’agents est comme construire un répertoire pour des fantômes, des identités qui disparaissent avant que vous n’ayez fini de les inscrire.

La couche d’identité d’agent que j’attends ancrera l’identité à la charge de travail que l’exécution émet, l’IAM cloud, les jetons de compte de service Kubernetes, la fédération OIDC et les normes telles que SPIFFE/SPIRE qui sont déjà prouvées en production et transversales. L’autorisation sera exprimée en termes de relations entre les méthodes d’authentification et les systèmes cibles, plutôt qu’entre les identités nommées et les étendues. Et le centre de gravité sera un plan d’exécution, une passerelle qui intermédie chaque action, classe l’intention, injecte des informations d’identification éphémères, masque les réponses sensibles et produit une chaîne d’audit complète. L’identité a toujours de l’importance, mais elle prend place derrière l’application, et non devant. Cette couche d’autorité à l’exécution, située sur la même plate-forme qui régit déjà l’accès humain et de la machine, est ce que je pense que chaque entreprise exécutant des agents en production finira par avoir besoin.

Merci pour cette grande interview. Les lecteurs qui souhaitent en savoir plus peuvent visiter Akeyless.