Internet Explorer n'est pas pris en charge par notre site web. Pour une expérience plus sécurisée, veuillez utiliser Chrome, Safari, Firefox ou Edge.
Logiciel deep tech
Dharmesh Thakker, René Bonvanie, Danel Dayan | 18 mai 2021
Authentification et autorisation, Post-Auth0 : Styra* et extension de l'identité à toutes les couches de la pile d'applications basées sur le cloud computing

L'acquisition récente, pour 6,5 milliards de dollars , de la startup d'identité et d'authentification Auth0 par Okta a mis en lumière ce secteur de plus en plus important dans le logiciel d'entreprise, en particulier à mesure que les charges de travail se déplacent vers le cloud. Mais nous pensons que l'authentification de l'utilisateur - c'est-à-dire la validation qu'un utilisateur est vraiment celui qu'il prétend être - n'est que le début de la bataille de la sécurité en ligne pour les organisations d'aujourd'hui.

Tout aussi importante, mais peut-être pas aussi bien comprise, est la nécessité d'une autorisation de haute qualité , ou la garantie qu'un utilisateur ou un service authentifié a les bonnes permissions pour effectuer certaines actions.

L'autorisation est présente dans presque toutes les interactions avec les utilisateurs ou les services. Par exemple, dans certaines situations, il ne suffit pas de savoir qu'un employé est un développeur ; il est également essentiel de savoir qu'il est également un administrateur système disposant de droits élevés dans la console Kubernetes. Au niveau de l'application, les politiques d'autorisation peuvent consister à déterminer si un utilisateur a des droits de lecture seule sur des champs au sein d'une application, ou s'il peut effectuer une certaine action au sein d'une application. Cela peut dépendre de divers facteurs, tels que l'emplacement, les privilèges ou les droits d'administrateur. Traditionnellement, cette logique d'autorisation ou de permission est codée en dur ou intégrée au code de l'application.

Chez Battery, les thèmes de l'identité des utilisateurs et des services, ainsi que des autorisations et des accès programmatiques, ont souvent été abordés lors de l'évaluation des outils de développement et des sociétés de sécurité basées sur l'identité, l'authentification et l'autorisation. Ce travail a donné lieu à nos investissements antérieurs dans JFrog* pour le dépôt de binaires ; Cypress* pour l'automatisation des tests ; et Bridgecrew* pour l'automatisation de la sécurité des développeurs.

Si l'authentification est la première étape d'un programme de sécurité des applications, nous avons constaté dans notre travail que l'autorisation est un problème beaucoup plus complexe dont les implications vont au-delà de la simple validation de l'identité. En passant du temps dans la catégorie, nous en sommes venus à admirer le populaire projet open-source Open Policy Agent (OPA), un agent unifié d'application des politiques et un langage permettant de mettre en œuvre des contrôles d'autorisation et des politiques en code. Cela nous a également conduits à Styra*, la société qui assure la maintenance commerciale d'OPA et qui est rapidement devenue la norme des développeurs pour l'autorisation des applications. À cette fin, nous sommes ravis d'annoncer notre investissement dans Styra et ravis de l'occasion qui nous est donnée de nous associer à l'équipe de direction de l'entreprise.

Comment en sommes-nous arrivés là ?

La gestion des identités et des accès (IAM) a été largement acceptée en raison de son importance stratégique dans un monde de plus en plus numérique. La gestion de l'identité d'un utilisateur ou d'un service est un élément essentiel du programme de sécurité de toute organisation. Cette importance n'a fait que s'amplifier pendant la pandémie de Covid-19, car toutes les entreprises, du commerce de détail au divertissement en passant par les voyages et le commerce, ont accéléré leurs initiatives de transformation numérique pour permettre le travail à domicile, améliorer les capacités en ligne et mieux servir leurs clients.

Si l'authentification a été largement résolue par des services comme Auth0, il est devenu évident que l'autorisation restait un processus lourd et manuel pour les entreprises. Traditionnellement, elle a été définie par des langages hérités tels que XACML ou réduite à de simples contrôles d'accès combinés à des listes de contrôle basées sur les rôles qui sont maintenues manuellement ou codées en dur dans la logique métier de l'application.

Nous avons appris qu'à mesure que de plus en plus d'applications étaient développées et déployées dans le nuage, les politiques de sécurité périmétrique traditionnelles ne fonctionnaient pas avec les charges de travail modernes natives ou hybrides. Les décisions d'autorisation devaient être prises plus près des applications, et des entreprises comme Atlassian, Pinterest et Goldman Sachs, entre autres, avaient besoin de cadres de politique standardisés pour pouvoir définir, surveiller et appliquer des politiques de manière centralisée et à grande échelle sur leur nombre croissant de services et d'applications en nuage. Cela nous a fait comprendre que la logique de la politique d'autorisation doit être séparée de la logique de l'application, et que l'OPA menait la charge derrière ce mouvement.

L'autorisation touche chaque couche de la pile d'applications.

Une partie de la complexité entourant l'autorisation aujourd'hui est la surface qu'elle couvre. L'autorisation consiste à donner aux utilisateurs et aux services la permission d'accéder à une ressource ou à une fonction spécifique à chaque niveau de la pile, du client de l'application à l'API, au service ou à la base de données. Les différents types d'applications développées et déployées par les organisations, telles que les applications natives, les applications Web et les microservices, ont toutes leurs propres exigences en matière d'identité et d'accès qui nécessitent chacune des politiques d'autorisation. Nous y avons vu l'opportunité pour une entreprise de définir le bon niveau d'abstraction pour mettre en œuvre la politique en tant que code et servir de couche horizontale qui unifie les contrôles d'autorisation.

Nos investissements à Styra

Styra et OPA deviennent rapidement la norme de facto pour la mise en œuvre de contrôles de politiques sur l'ensemble de la pile technologique, de l'autorisation de service à service à l'autorisation d'application de l'utilisateur final. Les retours de notre diligence indiquent que Styra/OPA est rapidement devenu une priorité du top 5 en matière d'initiatives de cloud et un service de niveau 0 (une nomenclature typique pour décrire le plus haut niveau de criticité pour 3rd party Logiciel, similaire à AWS ou Datadog*).

Aujourd'hui, l'entreprise possède l'une des plus grandes communautés open-source au monde, avec plus de 65 millions de téléchargements et plus de 4 000 membres de la communauté au sein de certaines des entreprises cloud-native les plus sophistiquées. Styra permet aux développeurs d'écrire, de mettre en œuvre et de tester des politiques de contrôle d'accès sur l'ensemble de la pile d'applications, des ressources de l'infrastructure au client de l'application. Après avoir passé beaucoup de temps à évaluer et à investir dans les outils pour développeurs et la sécurité, nous sommes ravis de nous associer à l'équipe de Styra et nous pensons qu'elle a le potentiel pour devenir une entreprise définissant une catégorie pour l'autorisation, tout comme Auth0 l'a fait pour l'authentification axée sur le développeur.

Ce contenu est fourni à titre d'information et ne constitue pas, et ne peut en aucun cas être considéré comme, un conseil juridique, fiscal ou d'investissement ou comme une offre de vente ou une sollicitation d'une offre d'achat d'un intérêt dans un fonds ou un instrument d'investissement géré par Battery Ventures ou toute autre entité de Battery. 

Les informations et les données sont en date de la publication, sauf indication contraire.

Le contenu obtenu de sources tierces, bien que considéré comme fiable, n'a pas été vérifié de manière indépendante quant à son exactitude ou son exhaustivité et ne peut être garanti. Battery Ventures n'a aucune obligation de mettre à jour, de modifier ou d'amender le contenu de ce post ni d'avertir ses lecteurs dans le cas où toute information, opinion, projection, prévision ou estimation incluse, changerait ou deviendrait ultérieurement inexacte.

Les informations ci-dessus peuvent contenir des projections ou d'autres déclarations prévisionnelles concernant des événements ou des attentes futurs. Les prédictions, opinions et autres informations discutées dans cette vidéo sont susceptibles d'être modifiées en permanence et sans préavis d'aucune sorte et peuvent ne plus être pertinentes après la date indiquée. Battery Ventures n'assume aucune obligation et ne s'engage pas à mettre à jour les déclarations prospectives.

*Dénote une entreprise de Battery Portefeuille. Pour une liste complète de tous les investissements de Battery, veuillez cliquer ici.

Retour au blog
Articles connexes