Informations d’arrière-plan
L’histoire commence en 2007 lorsque nos fondateurs, Omri Gazitt et Gert Drapers, travaillaient sur ce qui allait devenir Azure Active Directory. À cette époque, Active Directory était une charge de travail clé pour Windows Server. Il a permis aux administrateurs informatiques de mapper les utilisateurs et les groupes dans les rôles exposés par les applications d’entreprise.
Cependant, lorsque les logiciels d’entreprise sont passés au cloud, il n’y avait plus de système d’exploitation serveur capable d’authentifier l’utilisateur et de savoir à quels groupes il appartenait. En conséquence, chaque application cloud a été obligée de réinventer à la fois l’authentification et l’autorisation. Le service de contrôle d’accès Azure et Azure Active Directory ont été les premiers efforts visant à réinventer l’identité et l’accès à l’ère du SaaS et du cloud.
Contrôle d’accès précis en tant que service
Quinze ans plus tard, nous disposons désormais d’un tissu d’identité interopérable basé sur des normes telles que OAuth2, OpenID Connect, SAML et JWT, pris en charge par toutes les principales plates-formes cloud. De plus, des entreprises comme Okta, Auth0, OneLogin et PingID ont développé des solutions neutres pour le cloud, de sorte que personne n’a à réinventer la connexion.
L’autorisation, en revanche, reste largement mal desservie. À la mi-2020, alors qu’Omri et Gert cherchaient le prochain problème difficile à résoudre, ils ont immédiatement pensé à créer une solution définitive pour le contrôle d’accès aux applications et aux API.
Les directeurs techniques et les vice-présidents de l’ingénierie confirment que l’autorisation est un problème. Ils doivent continuellement construire et reconstruire leurs systèmes de contrôle d’accès en fonction d’exigences en constante évolution. Le service informatique est frustré par le fait que chaque application autorise différemment, en fonction d’ensembles distincts d’autorisations, de données et de modèles de backend. Avoir à naviguer à travers des dizaines de consoles pour gérer les politiques n’est pas non plus une promenade dans le parc. Omri et Gert savaient qu’il devait y avoir un meilleur moyen.
Autorisation moderne
Commençons par définir le problème. L’authentification est le processus de prouver qui vous êtes à un système. Cela peut être fait via une combinaison d’identifiant d’utilisateur et de mot de passe, ou via une authentification unique (SSO), une authentification multifacteur ou la biométrie.
L’autorisation, ou le contrôle d’accès, est en aval de l’authentification. C’est le processus d’évaluation de ce qu’un utilisateur connecté peut faire dans le contexte de votre application. Il s’agit d’un problème différent de celui de l’authentification et il est étonnamment complexe.
Au début, des rôles simples et rudimentaires, comme administrateur et spectateur, peuvent suffire. Mais, à mesure que vous développez et faites évoluer votre application et que vous intégrez des clients plus sophistiqués avec des exigences avancées, ces rôles simples ne suffisent plus. À ce stade, vous avez besoin d’un contrôle d’accès précis.
L’autorisation moderne est un contrôle d’accès précis, basé sur des politiques et en temps réel. Il est basé sur votre hiérarchie de ressources et votre modèle de domaine, et diffuse des données en temps réel vers des points de décision locaux pour permettre une application à la milliseconde basée sur les dernières données. Il est sécurisé par défaut et utilise les principes du moindre privilège. Il est facile à intégrer et s’intègre dans vos environnements. Plus important encore, il offre aux développeurs la flexibilité nécessaire pour faire évoluer les modèles et les politiques de contrôle d’accès en fonction de l’évolution des besoins.
Système de contrôle d’accès open source
Nous avons construit Aserto en tirant parti des meilleurs projets open source et natifs du cloud, y compris Open Policy Agent (OPA), qui est la base de notre moteur de décision. Plutôt que d’inventer notre propre moteur de politique et notre propre langage, nous avons choisi de rejoindre l’écosystème OPA, qui dispose d’un bon moteur de décision à usage général.
Nous concentrons Aserto sur la résolution du problème difficile, à savoir : comment créer une API évolutive et une autorisation d’application en plus de ces ressources open source ?
L’un des défis les plus difficiles consiste à transmettre les données des points d’information sur les politiques au moteur de décision, en les mettant en cache pour permettre l’exécution sur les données locales, mais en les maintenant synchronisées avec la source. Aserto résout ce problème en diffusant en temps réel les informations sur les attributs et les ressources de l’utilisateur vers les points de décision de politique qui se trouvent dans votre cloud, afin que vous puissiez prendre des décisions d’autorisation en quelques millisecondes et sur la base de données en temps réel.
Notre stratégie open source est ce que nous appelons « open edge » : Topaz, le logiciel d’autorisation que les applications appellent pour prendre des décisions d’autorisation, est open source, tandis que notre plan de contrôle est propriétaire. Notre plan de contrôle est l’endroit où nous estimons que nous ajoutons de la valeur aux organisations qui cherchent à coordonner ou à gérer le cycle de vie de leurs politiques, à connecter tous leurs fournisseurs d’identité, à amener toutes ces données à la périphérie et à ramener les journaux de décision de la périphérie au contrôle. avion.
CLI de politique
En cours de route, nous avons créé des projets open source à usage général pour aider à faire avancer l’écosystème.
Par défaut, les politiques OPA sont intégrées dans des archives tar. La Policy CLI apporte un flux de travail de type Docker pour la création de politiques OPA dans des images OCI, que vous pouvez signer avec cosign, afin de fournir une chaîne d’approvisionnement logicielle sécurisée pour vos images de politique.
Politique en tant que code et Politique en tant que données
Il y a un débat intéressant dans l’industrie entre deux écosystèmes – nous les appelons « policy-as-code » et « policy-as-data ».
- Politique en tant que code: soutient que vous pouvez tout définir dans votre politique. Vous pouvez créer des règles à usage général et utiliser un moteur logique pour évaluer ces règles et décider si cet utilisateur a ou non l’autorisation d’effectuer cette opération sur cette ressource.
- Politique en tant que données: Découle de la conviction que la plupart des problèmes de contrôle d’accès s’inscrivent dans un modèle basé sur les relations où la structure de règles relie un sujet, une action et un objet, construisant essentiellement un graphe de relations entre les sujets et les objets. Ce n’est pas une idée nouvelle, mais elle a été relancée par l’article de Google Zanzibar, qui décrit comment ils ont construit le système d’autorisation pour Google Docs.
Nous ne pensons pas que ce soit un choix : vous obtenez en fait un système plus intéressant et flexible lorsque vous combinez les deux.
L’annuaire Aserto est construit autour du modèle Zanzibar, où vous pouvez définir un ensemble de types d’objets tels que des organisations, des projets, des équipes, des dossiers ou des listes. Vous pouvez ensuite définir un ensemble de types de sujets tels que des utilisateurs et des groupes. Enfin, vous créez des types de relations qui relient les deux et suspendez les autorisations de ces relations.
Mais si vous souhaitez étendre le modèle basé sur les relations avec des règles de contrôle d’accès basées sur des attributs, vous pouvez créer une seule stratégie qui fait les deux. La réunion de ces concepts est la base d’un système flexible qui évoluera avec vous. Un système qui vous permet de commencer simplement, mais qui s’adapte à vos besoins au fil du temps.
Conclusion
Aujourd’hui, chaque application cloud est obligée de créer et de reconstruire son propre système de contrôle d’accès. L’autorisation d’application semble simple au premier abord, mais elle est étonnamment complexe. L’autorisation est le chemin critique de chaque demande d’application, et la transmission des données les plus récentes au moteur de décision pour permettre des décisions à la milliseconde est un problème de systèmes distribués que la plupart des équipes d’ingénierie ne peuvent tout simplement pas justifier de résoudre.