L’authentification à l’ère du SaaS et du Cloud
Commençons par les différences entre l’authentification et l’autorisation. Les gens ont tendance à regrouper ces concepts sous le nom d’authentification, mais ce sont deux processus distincts.
L’authentification décrit le processus permettant de découvrir que vous êtes qui vous prétendez être. Dans le passé, nous utilisions des identifiants d’utilisateur et des mots de passe. De nos jours, il est beaucoup plus courant d’utiliser des liens magiques ou une authentification multifacteur, etc., mais c’est le même processus.
Auparavant, l’authentification relevait de la responsabilité du système d’exploitation qui vous connecte une fois que vous avez fourni un mot de passe. Mais au cours des 15 dernières années, alors que nous entrions dans l’ère du SaaS et du cloud, cela a changé. La première génération d’applications SaaS et cloud a dû réinventer ce processus car il n’y avait plus de systèmes d’exploitation à demander pour authentifier l’identité de l’utilisateur.
Au cours des 15 dernières années, nous avons commencé à travailler ensemble en tant qu’industrie pour développer des normes autour de l’authentification, comme OAuth2, OpenID connect et SAML. Nous avons commencé à utiliser les JWT, etc. Aujourd’hui, personne n’a à créer un système de connexion s’il ne le souhaite pas. De nombreux services de développement peuvent vous aider à le faire.
Dans l’ensemble, vous pouvez dire que nous avons réussi à déplacer l’identité sur site vers le domaine du SaaS dans le cloud.
L’autorisation, en revanche, n’a pas migré vers le cloud. L’autorisation, ou contrôle d’accès, est le processus de discernement de ce que vous pouvez voir et faire une fois que vous êtes connecté. Contrairement à l’authentification, l’autorisation est un problème qui est loin d’être résolu.
Le problème est qu’il n’y a pas de normes de l’industrie pour l’autorisation. Vous pouvez appliquer certains modèles tels que le contrôle d’accès basé sur les rôles (RBAC) et le contrôle d’accès basé sur les attributs (ABAC), mais il n’existe pas de normes car l’autorisation est un problème spécifique au domaine. Il n’y a pas non plus de services de développement. Pouvez-vous penser à un Twilio ou à un Stripe pour l’autorisation ? Et parce qu’il n’y a pas de normes ou de services de développement à proprement parler, les entreprises perdent en agilité parce qu’elles doivent passer du temps à construire un système d’autorisation interne et subir la douleur que cela implique.
Il faut penser au coût d’opportunité. Combien cela vous coûtera-t-il de passer du temps à développer et à maintenir un système de contrôle d’accès interne, au lieu de vous concentrer sur vos propositions de valeur ? Et, malheureusement, lorsque les entreprises le font elles-mêmes, elles le font mal. C’est la raison pour laquelle le contrôle d’accès cassé se classe au premier rang des 10 principaux problèmes de sécurité répertoriés par le projet de sécurité des applications Web ouvertes (OWASP). Il semble que nous nous soyons vraiment creusés dans un assez grand trou et qu’il est maintenant temps de nous creuser pour en sortir.
Autorisation cloud native
Regardons comment nous sommes arrivés ici. Il y a eu trois transitions qui ont affecté le monde du logiciel en général et de l’autorisation en particulier :
1. Transition vers le SaaS: L’authentification a réussi le déplacement, mais pas le contrôle d’accès. Si nous creusons pourquoi, nous voyons qu’à l’époque, lorsque les applications parlaient simplement au système d’exploitation, nous avions un annuaire, comme LDAP. Dans ce répertoire, vous aviez des groupes, avec des utilisateurs affectés à ces groupes. Ces groupes correspondaient généralement à vos rôles d’application métier et les choses étaient assez simples. Mais maintenant, nous n’avons pas de système d’exploitation ou d’annuaire global que nous pouvons interroger, donc chaque application doit réinventer le processus d’autorisation.
2. Montée en puissance des microservices : Nous avons assisté à un changement architectural passant des applications monolithiques aux microservices. À l’époque où nous avions des monolithes, l’autorisation se produisait à un moment et à un endroit du code. Aujourd’hui, nous avons plusieurs microservices, et chaque microservice doit faire sa propre autorisation. Nous devons également penser à autoriser les interactions entre les microservices, afin que seuls les bons modèles d’interaction soient autorisés.
3. Confiance zéro : Le passage de l’approche de sécurité basée sur le périmètre à la sécurité zéro confiance. Avec la confiance zéro, une grande partie de la responsabilité de la sécurité s’est déplacée de l’environnement vers l’application.
Nous avons maintenant un nouvel ordre mondial où tout est dans le cloud, tout est un microservice et la confiance zéro est un must. Malheureusement, toutes les applications n’ont pas rattrapé ce nouveau paradigme, et lorsque nous comparons des applications bien architecturées à des applications mal architecturées, nous voyons clairement émerger cinq anti-modèles et cinq bonnes pratiques correspondantes.
Cinq meilleures pratiques de contrôle d’accès cloud natif
1. Service d’autorisation spécialement conçu
Aujourd’hui, chaque service autorise par lui-même. Si chaque microservice doit se soucier de son autorisation, chaque microservice est susceptible de le faire un peu différemment. Ainsi, lorsque vous souhaitez modifier le comportement d’autorisation sur l’ensemble de votre système, vous devez réfléchir à la manière dont chaque microservice doit être mis à jour et au fonctionnement de la logique d’autorisation dans ce microservice, ce qui devient très difficile à mesure que vous ajoutez des microservices à votre système.
La meilleure pratique que nous souhaitons prendre en compte consiste à extraire la logique d’autorisation des microservices et à créer un microservice spécialement conçu qui ne traitera que de l’autorisation.
Au cours des deux dernières années, de grandes organisations ont commencé à publier des articles décrivant le fonctionnement de leur système d’autorisation spécialement conçu. Tout a commencé avec l’article de Google Zanzibar qui décrit comment ils ont construit le système d’autorisation pour Google Drive et d’autres services. D’autres entreprises ont suivi et décrit comment elles ont construit leur service d’autorisation spécialement conçu et un système distribué autour de celui-ci. Ceux-ci incluent le document AuthZ d’Intuit, Himeji d’Airbnb, AuthZ de Carta et PAS de Netflix. Nous commençons maintenant à distiller ces apprentissages et à les intégrer dans des logiciels.
2. Contrôle d’accès précis
Le deuxième anti-modèle consiste à intégrer des rôles à gros grains dans votre application. Nous le voyons souvent dans les applications où vous avez des rôles, tels que « admin », « member » et « viewer ». Ces rôles sont intégrés directement dans le code de l’application et, à mesure que les développeurs ajoutent des autorisations, ils essaient de cascader ces autorisations dans ces rôles existants, ce qui rend le modèle d’autorisation difficile à affiner.
La meilleure pratique, dans ce cas, consiste à commencer par un modèle d’autorisation affiné qui applique le principe du moindre privilège. L’objectif est de donner à un utilisateur uniquement les autorisations dont il a besoin, ni plus ni moins. Ceci est important car lorsque l’identité est compromise – et ce n’est pas une question de si, c’est une question de quand – nous pouvons limiter les dommages que cette identité compromise peut potentiellement causer en limitant les autorisations que nous attribuons aux rôles que nous spécifions .
3. Gestion des accès basée sur des politiques
Le troisième anti-modèle que nous voyons est le « code spaghetti » d’autorisation, où les développeurs ont des instructions « switch » et « if » parsemées tout autour du code qui régit la logique d’autorisation. C’est une mauvaise idée et cela coûte cher lorsque vous souhaitez modifier la manière dont l’autorisation s’effectue dans votre système.
La meilleure pratique consiste ici à maintenir une séparation claire des tâches et à conserver la logique liée à l’autorisation dans une stratégie d’autorisation. En séparant la politique du code d’application, nous nous assurons que l’équipe de développement est responsable du développement de l’application et que l’équipe de sécurité de l’application est responsable de sa sécurisation.
4. Contrôles d’accès en temps réel
Le quatrième anti-modèle utilise des autorisations obsolètes dans un jeton d’accès. Cela a tendance à se produire au début de la vie d’une application, lorsque les développeurs exploitent les étendues, puis intègrent ces étendues dans le jeton d’accès.
Voici un scénario : un utilisateur qui a une portée « admin » se connecte. Cette portée est intégrée au jeton d’accès et partout où cet utilisateur interagit avec notre système en utilisant un jeton d’accès non expiré avec la portée « admin », cet utilisateur a des privilèges d’administrateur. Pourquoi est-ce mauvais ? Parce que si nous voulons supprimer la portée « admin » de l’utilisateur et l’invalider, nous rencontrerons un obstacle. Tant que l’utilisateur détient un jeton d’accès non expiré, il aura accès à toutes les ressources que le jeton d’accès lui accorde.
Vous ne pouvez tout simplement pas avoir un modèle de contrôle d’accès de qualité utilisant des jetons d’accès. Même si l’émetteur du jeton d’accès a une visibilité sur les ressources auxquelles l’utilisateur peut accéder, il n’est pas pratique d’insérer ces droits dans un jeton d’accès. Disons que nous avons une collection de documents et que nous voulons donner à un utilisateur une autorisation de lecture sur un document. De quel document parle-t-on ? Tous les documents? Seulement quelques-uns d’entre eux ? Il est clair que cette approche n’est pas à l’échelle.
La meilleure pratique ici consiste à ne jamais supposer que le jeton d’accès dispose des autorisations dont nous avons besoin et à effectuer des vérifications d’accès en temps réel qui prennent en compte le contexte d’identité, le contexte de ressource et l’autorisation avant d’accorder l’accès à une ressource protégée.
5. Journaux de décision centralisés
Enfin, l’accès non autorisé n’est pas une question de si, c’est une question de quand. Cela dit, les entreprises ont tendance à négliger de maintenir des journaux d’autorisation cohérents, ce qui limite leur capacité à retracer les incidents non autorisés.
La meilleure pratique consiste à disposer de journaux d’autorisation centralisés et détaillés. Nous devons surveiller et enregistrer tout dans un emplacement centralisé que nous pouvons analyser en aval pour mieux comprendre ce qui se passe dans notre système.
Modèles de contrôle d’accès à grain fin
Parlons un peu plus du contrôle d’accès à grain fin et de la façon dont il a vu le jour.
Listes de contrôle d’accès (ACL)
Dans les années 80, les systèmes d’exploitation définissaient des autorisations telles que « lire », « écrire » et « exécuter » sur les fichiers et les dossiers. Ce modèle était appelé listes de contrôle d’accès (ACL)
Avec ACL, vous pouvez répondre à des questions telles que : « Alice a-t-elle un accès en lecture à ce fichier ? »
Contrôle d’accès basé sur les rôles (RBAC)
RBAC, ou contrôle d’accès basé sur les rôles, est apparu dans les années 90 et au début des années 2000 avec l’avènement des annuaires comme LDAP et Active Directory. Ces répertoires vous donnent la possibilité de créer des groupes puis d’affecter des utilisateurs à des groupes, qui correspondent généralement à un rôle particulier…