Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
FAQ
Cette section fournit des réponses aux questions fréquemment posées sur la mise en œuvre du contrôle d'accès et de l'autorisation des API dans les applications SaaS multi-locataires.
Q. Quelle est la différence entre l'autorisation et l'authentification ?
R. L'authentification est le processus qui permet de vérifier qui est un utilisateur. L'autorisation accorde aux utilisateurs l'autorisation d'accéder à une ressource spécifique.
Q. Quelle est la différence entre l'autorisation et l'isolation des locataires dans une application SaaS ?
R. L'isolation des locataires fait référence aux mécanismes explicites utilisés 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 fait référence à l'autorisation des actions entrantes et à la prévention de leur mise en œuvre sur le mauvais locataire. Un utilisateur hypothétique pourrait être authentifié et autorisé, mais pourrait toujours accéder aux ressources d'un autre locataire. Rien dans l'authentification et l'autorisation ne bloque nécessairement cet accès, mais l'isolation des locataires est nécessaire pour atteindre cet objectif. Pour plus d'informations sur ces deux concepts, consultez la discussion sur l'isolation des locataires dans le livre blanc sur les principes fondamentaux de l'architecture AWS SaaS.
Q : Pourquoi dois-je envisager l'isolation des locataires pour mon application SaaS ?
R. Les applications SaaS ont plusieurs locataires. Un locataire peut être une organisation cliente ou toute entité externe utilisant cette application SaaS. Selon la façon dont l'application est conçue, cela signifie que les locataires peuvent accéder à des ressources partagées APIs, à des bases de données ou à d'autres ressources. Il est important de maintenir l'isolement des locataires, c'est-à-dire des structures qui contrôlent étroitement l'accès aux ressources et bloquent toute tentative d'accès aux ressources d'un autre locataire, afin d'empêcher les utilisateurs d'un locataire d'accéder aux informations privées d'un autre locataire. Les applications SaaS sont souvent conçues pour garantir que l'isolement des locataires est maintenu dans l'ensemble d'une application et que les locataires ne peuvent accéder qu'à leurs propres ressources.
Q. Pourquoi ai-je besoin d'un modèle de contrôle d'accès ?
R. Les modèles de contrôle d'accès sont utilisés pour créer une méthode cohérente permettant de déterminer comment accorder l'accès aux ressources d'une application. Cela peut être fait en attribuant des rôles aux utilisateurs qui sont étroitement liés à la logique métier, ou cela peut être basé sur d'autres attributs contextuels tels que l'heure ou le fait qu'un utilisateur répond à une condition prédéfinie. Les modèles de contrôle d'accès constituent la logique de base que votre application utilise pour prendre des décisions d'autorisation afin de déterminer les autorisations des utilisateurs.
Q. Le contrôle d'accès aux API est-il nécessaire pour mon application ?
R. Oui. APIs doit toujours vérifier que l'appelant dispose de l'accès approprié. Le contrôle d'accès généralisé aux API garantit également que l'accès n'est accordé qu'en fonction des locataires afin de maintenir une isolation appropriée.
Q : Pourquoi les moteurs de politiques sont-ils PDPs recommandés pour l'autorisation ?
R. Un point de décision politique (PDP) permet de transférer la logique d'autorisation du code d'application vers un système distinct. Cela peut simplifier le code de l'application. Il fournit également une interface easy-to-use idempotente pour prendre des décisions d'autorisation pour les microservices APIs, les couches Backend for Frontend (BFF) ou tout autre composant d'application.
Q. Qu'est-ce qu'un PEP ?
R. Un point d'application des politiques (PEP) est chargé de recevoir les demandes d'autorisation qui sont envoyées au PDP pour évaluation. Un PEP peut se trouver n'importe où dans une application où les données et les ressources doivent être protégées ou où une logique d'autorisation est appliquée. PEPs sont relativement simples par rapport à PDPs. Un PEP est uniquement chargé de demander et d'évaluer une décision d'autorisation et ne nécessite aucune logique d'autorisation pour y être incorporée.
Q : Comment choisir entre Amazon Verified Permissions et OPA ?
R. Pour choisir entre les autorisations vérifiées et l'Open Policy Agent (OPA), gardez toujours à l'esprit votre cas d'utilisation et vos exigences uniques. Les autorisations vérifiées constituent un moyen entièrement géré de définir des autorisations précises, d'auditer les autorisations entre les applications et de centraliser le système d'administration des politiques pour vos applications tout en répondant aux exigences de latence de vos applications grâce à un traitement en millisecondes. OPA est un moteur de politiques open source à usage général qui peut également vous aider à unifier les politiques au sein de votre pile d'applications. Pour exécuter OPA, vous devez l'héberger dans votre AWS environnement, généralement avec un conteneur ou AWS Lambda des fonctions.
Verified Permissions utilise le langage de politique open source Cedar, tandis qu'OPA utilise Rego. Par conséquent, la connaissance de l'une de ces langues peut vous inciter à choisir cette solution. Cependant, nous vous recommandons de vous renseigner sur les deux langues, puis de revenir sur le problème que vous essayez de résoudre afin de trouver la meilleure solution pour votre cas d'utilisation.
Q. Existe-t-il des alternatives open source aux autorisations vérifiées et à l'OPA ?
R. Il existe quelques systèmes open source similaires à Verified Permissions et à Open Policy Agent (OPA), tels que le Common Expression Language (CEL)
Q. Dois-je écrire un service d'autorisation pour utiliser l'OPA, ou puis-je interagir directement avec l'OPA ?
R. Vous pouvez interagir directement avec l'OPA. Dans le contexte de ce guide, un service d'autorisation fait référence à un service qui traduit les demandes de décision d'autorisation en requêtes OPA, et vice versa. Si votre application peut interroger et accepter directement les réponses de l'OPA, il n'est pas nécessaire d'introduire cette complexité supplémentaire.
Q. Comment puis-je surveiller mes agents OPA à des fins de disponibilité et d'audit ?
R. OPA assure la journalisation et la surveillance de base du temps de disponibilité, bien que sa configuration par défaut soit probablement insuffisante pour les déploiements en entreprise. Pour plus d'informations, consultez la DevOps section Surveillance et journalisation plus haut dans ce guide.
Q : Comment puis-je surveiller les autorisations vérifiées à des fins de disponibilité et d'audit ?
A. Verified Permissions est un service AWS géré dont la disponibilité peut être contrôlée via le AWS Health Dashboard. En outre, Verified Permissions est capable de se connecter à AWS CloudTrail Amazon CloudWatch Logs, Amazon S3 et Amazon Data Firehose.
Q. Quels systèmes d'exploitation et AWS services puis-je utiliser pour exécuter OPA ?
R. Vous pouvez exécuter OPA sur macOS, Windows et Linux
Q. Quels systèmes d'exploitation et AWS services puis-je utiliser pour exécuter les autorisations vérifiées ?
A. Verified Permissions est un service AWS géré par AWS. Aucune configuration, installation ou hébergement supplémentaire n'est nécessaire pour utiliser les autorisations vérifiées, à l'exception de la possibilité de faire des demandes d'autorisation au service.
Q. Puis-je lancer OPA AWS Lambda ?
R. Vous pouvez exécuter OPA sur Lambda en tant que bibliothèque Go. Pour savoir comment procéder pour un autorisateur Lambda API Gateway, consultez le billet de AWS blog Création d'un autorisateur Lambda personnalisé
Q : Comment choisir entre une approche PDP distribuée et une approche PDP centralisée ?
R. Cela dépend de votre candidature. Il sera probablement déterminé en fonction de la différence de latence entre un modèle PDP distribué et centralisé. Nous vous recommandons de créer une preuve de concept et de tester les performances de votre application pour vérifier votre solution.
Q. Puis-je également utiliser OPA pour des cas d'utilisation APIs ?
R. Oui. La documentation OPA fournit des exemples pour Kubernetes
Q. Puis-je utiliser les autorisations vérifiées pour d'autres cas d'utilisation APIs ?
R. Oui. Verified Permissions peut fournir une DENY réponse ALLOW ou une réponse à toute demande d'autorisation reçue. Les autorisations vérifiées peuvent fournir des réponses d'autorisation pour toute application ou service nécessitant des décisions d'autorisation.
Q : Puis-je créer des politiques dans Verified Permissions en utilisant le langage de politique IAM ?
R. Non Vous devez utiliser le langage politique de Cedar pour créer des politiques. Cedar est conçu pour prendre en charge la gestion des autorisations pour les ressources des applications clients, tandis que le langage de politique AWS Identity and Access Management (IAM) a évolué pour prendre en charge le contrôle d'accès aux AWS ressources.
