Bonnes pratiques pour la conception d'un modèle d'autorisation

Lorsque vous vous préparez à utiliser le service Amazon Verified Permissions au sein d'une application logicielle, il peut être difficile de se lancer immédiatement dans la rédaction de déclarations de politique dans un premier temps. Cela reviendrait à commencer le développement d'autres parties d'une application en rédigeant des SQL instructions ou des API spécifications avant de décider pleinement de ce que l'application doit faire. Vous devriez plutôt commencer par une expérience utilisateur. Ensuite, revenez en arrière à partir de cette expérience pour arriver à une approche de mise en œuvre.

Au cours de ce travail, vous vous poserez des questions telles que :

• Quelles sont mes ressources ? Comment sont-ils organisés ? Par exemple, les fichiers se trouvent-ils dans un dossier ?

• L'organisation des ressources joue-t-elle un rôle dans le modèle d'autorisations ?

• Quelles actions les directeurs peuvent-ils effectuer sur chaque ressource ?

• Comment les directeurs obtiennent-ils ces autorisations ?

• Voulez-vous que vos utilisateurs finaux puissent choisir parmi des autorisations prédéfinies telles que « Administrateur », « Opérateur » ou « ReadOnly », ou devraient-ils créer des déclarations de politique ad hoc ? Ou les deux ?

• Les rôles sont-ils globaux ou délimités ? Par exemple, un « opérateur » est-il limité au sein d'un seul tenant, ou le terme « opérateur » signifie-t-il un opérateur pour l'ensemble de l'application ?

• Quels types de requêtes sont nécessaires pour améliorer l'expérience utilisateur ? Par exemple, devez-vous répertorier toutes les ressources auxquelles un directeur peut accéder pour afficher la page d'accueil de cet utilisateur ?

• Les utilisateurs peuvent-ils accidentellement se priver de leurs propres ressources ? Cela doit-il être évité ?

Le résultat final de cet exercice est appelé modèle d'autorisation ; il définit les principes, les ressources, les actions et la façon dont ils sont liés les uns aux autres. La production de ce modèle ne nécessite aucune connaissance unique de Cedar ou du service Verified Permissions. Il s'agit avant tout d'un exercice de conception de l'expérience utilisateur, un peu comme les autres, qui peut se traduire par des artefacts tels que des maquettes d'interface, des diagrammes logiques et une description globale de la manière dont les autorisations influencent ce que les utilisateurs peuvent faire dans le produit. Cedar est conçu pour être suffisamment flexible pour répondre aux besoins des clients selon un modèle, plutôt que de forcer le modèle à se plier de manière anormale pour se conformer à la mise en œuvre d'un modèle Cedar. Par conséquent, une compréhension précise de l'expérience utilisateur souhaitée est le meilleur moyen de parvenir à un modèle optimal.

Pour répondre aux questions et parvenir à un modèle optimal, procédez comme suit :

• Passez en revue les modèles de conception de Cedar dans le guide de référence du langage politique de Cedar.

• Tenez compte des meilleures pratiques décrites dans le Guide de référence du langage politique de Cedar.

• Tenez compte des meilleures pratiques présentées sur cette page.

Il n'existe pas de modèle canonique « correct »

Lorsque vous concevez un modèle d'autorisation, il n'existe pas de réponse unique et correcte. Différentes applications peuvent utiliser efficacement différents modèles d'autorisation pour des concepts similaires, et ce n'est pas grave. Par exemple, considérez la représentation du système de fichiers d'un ordinateur. Lorsque vous créez un fichier dans un système d'exploitation de type Unix, il n'hérite pas automatiquement des autorisations du dossier parent. En revanche, dans de nombreux autres systèmes d'exploitation et dans la plupart des services de partage de fichiers en ligne, les fichiers héritent des autorisations de leur dossier parent. Les deux choix sont valides en fonction des circonstances pour lesquelles l'application est optimisée.

L'exactitude d'une solution d'autorisation n'est pas absolue, mais elle doit être considérée en fonction de la manière dont elle fournit l'expérience souhaitée par vos clients et de la manière dont elle protège leurs ressources comme ils l'attendent. Si votre modèle d'autorisation tient ses promesses, cela signifie qu'il est efficace.

C'est pourquoi commencer votre conception avec l'expérience utilisateur souhaitée est la condition préalable la plus utile à la création d'un modèle d'autorisation efficace.

Concentrez-vous sur vos ressources au-delà API des opérations

Dans la plupart des applications, les autorisations sont modélisées en fonction des ressources prises en charge. Par exemple, une application de partage de fichiers peut représenter les autorisations comme des actions pouvant être effectuées sur un fichier ou un dossier. Il s'agit d'un bon modèle simple qui fait abstraction de l'implémentation sous-jacente et des opérations de backendAPI.

En revanche, d'autres types d'applications, en particulier les services Web, conçoivent fréquemment des autorisations en fonction des API opérations elles-mêmes. Par exemple, si un service Web fournit un API nomcreateThing(), le modèle d'autorisation peut définir une autorisation correspondante, ou un nom action dans CedarcreateThing. Cela fonctionne dans de nombreuses situations et facilite la compréhension des autorisations. Pour appeler l'createThingopération, vous devez disposer de l'autorisation createThing d'action. Cela semble simple, non ?

Vous constaterez que le processus de démarrage dans la console des autorisations vérifiées inclut la possibilité de créer vos ressources et vos actions directement à partir d'unAPI. Il s'agit d'une base de référence utile : un mappage direct entre votre magasin de politiques et API celui qu'il autorise.

Toutefois, au fur et à mesure que vous développez votre modèle, cette approche API ciblée risque de ne pas convenir aux applications dotées de modèles d'autorisation très précis, car il APIs s'agit simplement d'un proxy de ce que vos clients essaient réellement de protéger : les données et les ressources sous-jacentes. Si plusieurs personnes APIs contrôlent l'accès aux mêmes ressources, il peut être difficile pour les administrateurs de déterminer les chemins d'accès à ces ressources et de gérer l'accès en conséquence.

Prenons l'exemple d'un annuaire d'utilisateurs qui contient les membres d'une organisation. Les utilisateurs peuvent être organisés en groupes, et l'un des objectifs de sécurité est d'empêcher les parties non autorisées de découvrir leur appartenance à un groupe. Le service de gestion de cet annuaire d'utilisateurs propose deux API opérations :

• listMembersOfGroup

• listGroupMembershipsForUser

Les clients peuvent utiliser l'une ou l'autre de ces opérations pour découvrir l'appartenance à un groupe. Par conséquent, l'administrateur des autorisations doit se rappeler de coordonner l'accès aux deux opérations. Cela est encore plus compliqué si vous choisissez ultérieurement d'ajouter une nouvelle API opération pour traiter des cas d'utilisation supplémentaires, tels que les suivants.

• isUserInGroups(une nouveauté API pour tester rapidement si un utilisateur appartient à un ou plusieurs groupes)

Du point de vue de la sécurité, cela API ouvre une troisième voie pour découvrir les appartenances à des groupes, perturbant ainsi les autorisations soigneusement conçues de l'administrateur.

Nous vous recommandons de vous concentrer sur les données et les ressources sous-jacentes ainsi que sur leurs opérations d'association. L'application de cette approche à l'exemple d'appartenance à un groupe conduirait à une autorisation abstraiteviewGroupMembership, par exemple, que chacune des trois API opérations doit consulter.

APINom	Autorisations
listMembersOfGroup	nécessite une viewGroupMembership autorisation sur le groupe
listGroupMembershipsForUser	nécessite viewGroupMembership l'autorisation de l'utilisateur
isUserInGroups	nécessite viewGroupMembership l'autorisation de l'utilisateur

En définissant cette autorisation unique, l'administrateur contrôle avec succès l'accès à la découverte des appartenances à des groupes, maintenant et pour toujours. En contrepartie, chaque API opération doit désormais documenter les différentes autorisations éventuellement requises, et l'administrateur doit consulter cette documentation lors de l'élaboration des autorisations. Cela peut être un compromis valable lorsque cela est nécessaire pour répondre à vos exigences de sécurité.

Considérations relatives à la location multiple

Vous souhaiterez peut-être développer des applications destinées à plusieurs clients (entreprises qui utilisent votre application ou locataires) et les intégrer aux autorisations vérifiées d'Amazon. Avant de développer votre modèle d'autorisation, élaborez une stratégie multi-locataires. Vous pouvez gérer les politiques de vos clients dans un magasin de politiques partagé ou attribuer à chacun un magasin de politiques par locataire. Pour plus d'informations, consultez les considérations relatives à la conception multi-locataires d'Amazon Verified Permissions dans les directives AWS prescriptives.

1. Un magasin de politiques partagé

   Tous les locataires partagent un seul magasin de politiques. L'application envoie toutes les demandes d'autorisation au magasin de politiques partagé.

2. Boutique de politiques par locataire

   Chaque locataire dispose d'un magasin de polices dédié. L'application interrogera différents magasins de politiques pour obtenir une décision d'autorisation, en fonction du locataire qui fait la demande.

Aucune de ces stratégies n'aura d'impact important sur votre AWS facture. Alors, comment devriez-vous concevoir votre approche ? Les conditions suivantes sont courantes susceptibles de contribuer à votre stratégie d'autorisation multi-tenant avec Verified Permissions.

Isolement des politiques relatives aux locataires

Il est important d'isoler les politiques de chaque locataire des autres pour protéger les données des locataires. Lorsque chaque locataire possède son propre magasin de politiques, il dispose de son propre ensemble de politiques isolé.

Flux d'autorisation

Vous pouvez identifier un locataire qui fait une demande d'autorisation à l'aide d'un identifiant de magasin de politiques figurant dans la demande, avec des magasins de politiques par locataire. Dans le cas d'un magasin de règles partagé, toutes les demandes utilisent le même identifiant de magasin de politiques.

Gestion des modèles et des schémas

Lorsque votre application possède plusieurs magasins de politiques, vos modèles de politiques et un schéma de magasin de politiques ajoutent un certain niveau de charge de conception et de maintenance à chaque magasin de politiques.

Gestion des politiques globales

Vous souhaiterez peut-être appliquer certaines politiques globales à chaque locataire. Le niveau de surcharge lié à la gestion des politiques globales varie entre les modèles de magasins de politiques partagés et par locataire.

Débarquement du locataire

Certains locataires apporteront à votre schéma et à vos politiques des éléments spécifiques à leur cas. Lorsqu'un locataire n'est plus actif au sein de votre organisation et que vous souhaitez supprimer ses données, le niveau d'effort varie en fonction de son niveau d'isolation par rapport aux autres locataires.

Quotas de ressources de service

Verified Permissions dispose de quotas de ressources et de taux de demandes susceptibles d'influencer votre décision de location multiple. Pour de plus amples informations sur les quotas, veuillez consulter Quotas de ressources.

Comparaison des magasins de politiques partagés et des magasins de politiques par locataire

Chaque considération nécessite son propre niveau d'engagement en termes de temps et de ressources dans les modèles de magasins de polices partagés et par locataire.

Considération	Niveau d'effort dans un magasin de politiques partagé	Niveau d'effort dans les magasins de polices par locataire
Isolement des politiques relatives aux locataires	Moyen.Doit inclure les identifiants des locataires dans les politiques et les demandes d'autorisation.	Faible. L'isolation est le comportement par défaut. Les politiques spécifiques aux locataires ne sont pas accessibles aux autres locataires.
Flux d'autorisation	Faible. Toutes les requêtes ciblent un magasin de politiques.	Moyen. Doit maintenir les mappages entre chaque locataire et son ID de magasin de politiques.
Gestion des modèles et des schémas	Faible. Doit faire fonctionner un schéma pour tous les locataires.	Haut. Les schémas et les modèles peuvent être moins complexes individuellement, mais les modifications nécessitent plus de coordination et de complexité.
Gestion des politiques globales	Faible. Toutes les politiques sont globales et peuvent être mises à jour de manière centralisée.	Haut. Vous devez ajouter des politiques globales à chaque magasin de politiques lors de l'intégration. Répliquez les mises à jour des politiques globales entre de nombreux magasins de politiques.
Débarquement du locataire	Haut. Doit identifier et supprimer uniquement les politiques spécifiques au locataire.	Faible. Supprimez le magasin de politiques.
Quotas de ressources de service	Haut. Les locataires partagent des quotas de ressources qui affectent les magasins de politiques, tels que la taille du schéma, la taille des politiques par ressource et les sources d'identité par magasin de politiques.	Faible. Chaque locataire dispose de quotas de ressources dédiés.

Comment choisir

Chaque application mutualisée est différente. Comparez soigneusement les deux approches et leurs considérations avant de prendre une décision architecturale.

Si votre application ne nécessite pas de politiques spécifiques aux locataires et utilise une source d'identité unique, un magasin de politiques partagé pour tous les locataires est probablement la solution la plus efficace. Cela se traduit par une simplification du flux d'autorisation et de la gestion globale des politiques. Le désengagement d'un locataire à l'aide d'un magasin de politiques partagé nécessite moins d'efforts, car l'application n'a pas besoin de supprimer les politiques spécifiques au locataire.

Toutefois, si votre application nécessite de nombreuses politiques spécifiques au locataire ou utilise plusieurs sources d'identité, les magasins de politiques par locataire sont probablement les plus efficaces. Vous pouvez contrôler l'accès aux politiques des locataires à l'aide de IAM politiques qui accordent des autorisations par locataire à chaque magasin de politiques. Le désembarquement d'un locataire implique la suppression de son magasin de politiques ; dans un shared-policy-store environnement, vous devez rechercher et supprimer les politiques spécifiques au locataire.