Bonnes pratiques

Cette section répertorie certains des principaux points à retenir de ce guide. Pour des discussions détaillées sur chaque point, suivez les liens vers les sections correspondantes.

Sélectionnez un modèle de contrôle d'accès adapté à votre application

Ce guide décrit plusieurs modèles de contrôle d'accès. En fonction de votre application et des exigences commerciales, vous devez sélectionner le modèle qui vous convient. Réfléchissez à la manière dont vous pouvez utiliser ces modèles pour répondre à vos besoins en matière de contrôle d'accès et à la manière dont vos besoins de contrôle d'accès pourraient évoluer, ce qui nécessiterait de modifier l'approche que vous avez choisie.

Implémenter un PDP

Le point de décision politique (PDP) peut être caractérisé comme un moteur de politiques ou de règles. Ce composant est chargé d'appliquer des politiques ou des règles et de décider si un accès particulier est autorisé. Un PDP permet de transférer la logique d'autorisation du code de l'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. Un PDP peut être utilisé pour appliquer les exigences de location de manière cohérente dans l'ensemble d'une application.

PEPs Implémentation pour chaque API de votre application

La mise en œuvre d'un point d'application des politiques (PEP) nécessite de déterminer où le contrôle d'accès doit être appliqué dans une application. Dans un premier temps, localisez les points de votre application où vous pouvez intégrer PEPs. Tenez compte de ce principe lorsque vous décidez où ajouter PEPs :

Si une application expose une API, cette API doit être dotée d'une autorisation et d'un contrôle d'accès.

Envisagez d'utiliser Amazon Verified Permissions ou OPA comme moteur de politique pour votre PDP

Amazon Verified Permissions présente des avantages par rapport aux moteurs de politiques personnalisés. Il s'agit d'un service de gestion des autorisations et d'autorisation évolutif et précis pour les applications que vous créez. Il prend en charge la rédaction de politiques dans le langage open source déclaratif de haut niveau Cedar. Par conséquent, la mise en œuvre d'un moteur de politiques à l'aide d'autorisations vérifiées nécessite moins d'efforts de développement que la mise en œuvre de votre propre solution. En outre, les autorisations vérifiées sont entièrement gérées, vous n'avez donc pas à gérer l'infrastructure sous-jacente.

L'Open Policy Agent (OPA) présente des avantages par rapport aux moteurs de politiques personnalisés. OPA et son évaluation des politiques avec Rego fournissent un moteur de politiques flexible et prédéfini qui prend en charge la rédaction de politiques dans un langage déclaratif de haut niveau. Cela réduit considérablement le niveau d'effort requis pour mettre en œuvre un moteur de politiques par rapport à la création de votre propre solution. En outre, l'OPA est en train de devenir rapidement une norme d'autorisation bien prise en charge.

Implémenter un plan de contrôle pour l'OPA pour DevOps, la surveillance et la journalisation

Étant donné que l'OPA ne fournit aucun moyen de mettre à jour et de suivre les modifications apportées à la logique d'autorisation par le biais du contrôle de source, nous vous recommandons d'implémenter un plan de contrôle pour exécuter ces fonctions. Cela permettra de distribuer plus facilement les mises à jour aux agents de l'OPA, en particulier si l'OPA fonctionne dans un système distribué, ce qui réduira le fardeau administratif lié à l'utilisation de l'OPA. En outre, un plan de contrôle peut être utilisé pour collecter des journaux à des fins d'agrégation et pour surveiller le statut des agents OPA.

Configurer les fonctionnalités de journalisation et d'observabilité dans les autorisations vérifiées

Les autorisations vérifiées permettent d'accéder facilement aux fonctionnalités d'observabilité. Vous pouvez configurer le service pour enregistrer toutes les tentatives d'accès aux groupes de CloudWatch log Amazon AWS CloudTrail, aux compartiments S3 ou aux flux de livraison Amazon Data Firehose afin de permettre une réponse rapide aux incidents de sécurité et aux demandes d'audit. En outre, vous pouvez surveiller l'état du service par le biais du AWS Health Dashboard. Dans la mesure où Verified Permissions est un service géré, son intégrité est maintenue par AWS d'autres services gérés et vous pouvez configurer ses fonctionnalités d'observabilité à l'aide d'autres services AWS gérés.

Utiliser un pipeline CI/CD pour approvisionner et mettre à jour les magasins de politiques et les politiques dans Verified Permissions

Les autorisations vérifiées étant un service géré, vous n'avez pas besoin de gérer, de configurer ou de maintenir des plans de contrôle ou des agents pour effectuer des mises à jour. Cependant, nous vous recommandons tout de même d'utiliser un pipeline d'intégration et de déploiement continus (CI/CD) pour administrer le déploiement des magasins de politiques d'autorisations vérifiées et des mises à jour des politiques à l'aide du AWS SDK. Cet effort peut supprimer les efforts manuels et réduire le risque d'erreurs de l'opérateur lorsque vous apportez des modifications aux ressources d'autorisations vérifiées.

Déterminez si des données externes sont requises pour les décisions d'autorisation et sélectionnez un modèle adapté

Si un PDP peut prendre des décisions d'autorisation basées uniquement sur les données contenues dans un jeton Web JSON (JWT), il n'est généralement pas nécessaire d'importer des données externes pour faciliter la prise de ces décisions. Si vous utilisez Verified Permissions ou OPA en tant que PDP, il peut également accepter des entrées supplémentaires transmises dans le cadre de la demande, même si ces données ne sont pas incluses dans un JWT. Pour les autorisations vérifiées, vous pouvez utiliser un paramètre de contexte pour les données supplémentaires. Pour OPA, vous pouvez utiliser les données JSON comme entrée de surcharge. Si vous utilisez un JWT, les méthodes de saisie de contexte ou de surcharge sont généralement beaucoup plus simples que la gestion de données externes dans une autre source. Si des données externes plus complexes sont nécessaires pour prendre des décisions d'autorisation, OPA propose plusieurs modèles pour récupérer des données externes, et Verified Permissions peut compléter les données de ses demandes d'autorisation en référençant des sources externes avec un service d'autorisation.