Autorisation SaaS multi-locataires et contrôle d'accès aux API : options de mise en œuvre et meilleures pratiques

Tabby Ward, Thomas Davis, Gideon Landeman et Tomas Riha, Amazon Web Services ()AWS

Mai 2024 (historique du document)

Les autorisations et le contrôle d'accès aux API constituent un défi pour de nombreuses applications logicielles, en particulier pour les applications SaaS (Software as a Service) mutualisées. Cette complexité est évidente si l'on considère la prolifération des API de microservices qui doivent être sécurisées et le grand nombre de conditions d'accès qui découlent des différents locataires, des caractéristiques des utilisateurs et des états des applications. Pour résoudre efficacement ces problèmes, une solution doit renforcer le contrôle d'accès aux nombreuses API présentées par les microservices, les couches Backend for Frontend (BFF) et les autres composants d'une application SaaS mutualisée. Cette approche doit être accompagnée d'un mécanisme capable de prendre des décisions d'accès complexes en fonction de nombreux facteurs et attributs.

Traditionnellement, le contrôle d'accès et l'autorisation des API étaient gérés par une logique personnalisée dans le code de l'application. Cette approche était sujette aux erreurs et n'était pas sécurisée, car les développeurs ayant accès à ce code pouvaient accidentellement ou délibérément modifier la logique d'autorisation, ce qui pouvait entraîner un accès non autorisé. L'audit des décisions prises par la logique personnalisée dans le code de l'application était difficile, car les auditeurs devaient s'immerger dans la logique personnalisée pour déterminer son efficacité en termes de respect d'une norme particulière. En outre, le contrôle d'accès aux API était généralement inutile, car il n'y avait pas autant d'API à sécuriser. Le changement de paradigme dans la conception des applications pour favoriser les microservices et les architectures orientées services a augmenté le nombre d'API qui doivent utiliser une forme d'autorisation et de contrôle d'accès. En outre, la nécessité de maintenir un accès basé sur les locataires dans une application SaaS à locataires multiples pose des problèmes d'autorisation supplémentaires pour préserver la location. Les meilleures pratiques décrites dans ce guide présentent plusieurs avantages :

• La logique d'autorisation peut être centralisée et écrite dans un langage déclaratif de haut niveau qui n'est spécifique à aucun langage de programmation.

• La logique d'autorisation est extraite du code de l'application et peut être appliquée sous forme de modèle répétable à toutes les API d'une application.

• L'abstraction empêche les développeurs de modifier accidentellement la logique d'autorisation.

• L'intégration dans une application SaaS est cohérente et simple.

• L'abstraction évite d'avoir à écrire une logique d'autorisation personnalisée pour chaque point de terminaison d'API.

• Les audits sont simplifiés, car l'auditeur n'a plus besoin de revoir le code pour déterminer les autorisations.

• L'approche décrite dans ce guide soutient l'utilisation de plusieurs paradigmes de contrôle d'accès en fonction des exigences d'une organisation.

• Cette approche d'autorisation et de contrôle d'accès fournit un moyen simple et direct de maintenir l'isolation des données des locataires au niveau de la couche API d'une application SaaS.

• Les meilleures pratiques fournissent une approche cohérente en matière d'intégration et de départ des locataires en ce qui concerne l'autorisation.

• Cette approche propose différents modèles de déploiement d'autorisations (groupés ou silo), qui présentent à la fois des avantages et des inconvénients, comme indiqué dans ce guide.

Résultats commerciaux ciblés

Ce guide prescriptif décrit des modèles de conception reproductibles pour les contrôles d'autorisation et d'accès aux API qui peuvent être mis en œuvre pour les applications SaaS multi-locataires. Ce guide est destiné à toute équipe qui développe des applications soumises à des exigences d'autorisation complexes ou à des besoins stricts en matière de contrôle d'accès aux API. L'architecture détaille la création d'un point de décision politique (PDP) ou d'un moteur de politique et l'intégration des points d'application des politiques (PEP) dans les API. Deux options spécifiques pour créer un PDP sont abordées : utiliser Amazon Verified Permissions avec le SDK Cedar et utiliser l'Open Policy Agent (OPA) avec le langage de politique Rego. Le guide explique également comment prendre des décisions d'accès sur la base d'un modèle de contrôle d'accès basé sur les attributs (ABAC) ou d'un modèle de contrôle d'accès basé sur les rôles (RBAC), ou d'une combinaison des deux modèles. Nous vous recommandons d'utiliser les modèles et concepts de conception fournis dans ce guide pour informer et standardiser votre mise en œuvre de l'autorisation et du contrôle d'accès aux API dans les applications SaaS multi-locataires. Ces conseils aident à atteindre les résultats commerciaux suivants :

• Architecture d'autorisation d'API standardisée pour les applications SaaS à locataires multiples : cette architecture distingue trois composants : le point d'administration des politiques (PAP) où les politiques sont stockées et gérées, le point de décision politique (PDP) où ces politiques sont évaluées pour parvenir à une décision d'autorisation, et le point d'application des politiques (PEP) qui applique cette décision. Le service d'autorisation hébergé, Verified Permissions, sert à la fois de PAP et de PDP. Vous pouvez également créer vous-même votre PDP en utilisant un moteur open source tel que Cedar ou OPA.

• Dissociation de la logique d'autorisation des applications — Lorsqu'elle est intégrée au code de l'application ou mise en œuvre par le biais d'un mécanisme d'application ad hoc, la logique d'autorisation peut être sujette à des modifications accidentelles ou malveillantes entraînant un accès involontaire aux données entre locataires ou d'autres violations de sécurité. Pour atténuer ces risques, vous pouvez utiliser un PAP, tel que Verified Permissions, pour stocker les politiques d'autorisation indépendamment du code de l'application et pour appliquer une gouvernance solide à la gestion de ces politiques. Les politiques peuvent être gérées de manière centralisée dans un langage déclaratif de haut niveau, ce qui rend la gestion de la logique d'autorisation bien plus simple que lorsque vous intégrez des politiques dans plusieurs sections du code de l'application. Cette approche garantit également que les mises à jour sont appliquées de manière cohérente.

• Approche flexible des modèles de contrôle d'accès — Le contrôle d'accès basé sur les rôles (RBAC), le contrôle d'accès basé sur les attributs (ABAC) ou une combinaison des deux modèles sont tous des approches valides en matière de contrôle d'accès. Ces modèles tentent de satisfaire aux exigences d'autorisation d'une entreprise en utilisant différentes approches. Ce guide compare et met en contraste ces modèles afin de vous aider à sélectionner un modèle adapté à votre organisation. Le guide explique également comment ces modèles s'appliquent aux différents langages de politique d'autorisation, tels que OPA/Rego et Cedar. Les architectures décrites dans ce guide permettent d'adopter avec succès l'un ou l'autre des modèles ou les deux.

• Contrôle strict de l'accès aux API — Ce guide fournit une méthode pour sécuriser les API de manière cohérente et omniprésente dans une application avec un minimum d'effort. Cela est particulièrement utile pour les architectures d'applications orientées services ou microservices qui utilisent généralement un grand nombre d'API pour faciliter les communications intra-applications. Le contrôle strict de l'accès aux API contribue à renforcer la sécurité d'une application et à la rendre moins vulnérable aux attaques ou à l'exploitation.

Isolement des locataires et autorisation multi-locataires

Ce guide fait référence aux concepts d'isolement des locataires et d'autorisation multi-locataires. L'isolation des locataires fait référence aux mécanismes explicites que vous utilisez dans un système SaaS pour garantir que les ressources de chaque locataire, même lorsqu'elles opèrent sur une infrastructure partagée, sont isolées. L'autorisation multi-locataires consiste à autoriser les actions entrantes et à empêcher qu'elles ne soient mises en œuvre sur le mauvais locataire. Un utilisateur hypothétique pourrait être authentifié et autorisé, tout en continuant d'accéder aux ressources d'un autre locataire. L'authentification et l'autorisation ne bloqueront pas cet accès. Pour atteindre cet objectif, vous devez mettre en œuvre l'isolation des locataires. Pour une discussion plus approfondie des différences entre ces deux concepts, consultez la section sur l'isolation des locataires du livre blanc sur les principes fondamentaux de l'architecture SaaS.