Mettre en œuvre un PEP - AWS Conseils prescriptifs

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.

Mettre en œuvre un PEP

Un point d'application des politiques (PEP) est chargé de recevoir les demandes d'autorisation qui sont envoyées au point de décision politique (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. PEPs, au contraire PDPs, ne peut pas être centralisé dans une application SaaS. Cela est dû au fait que l'autorisation et le contrôle d'accès doivent être mis en œuvre dans l'ensemble d'une application et de ses points d'accès. PEPs peut être appliqué à des microservices APIs, à des couches Backend for Frontend (BFF) ou à tout point de l'application où le contrôle d'accès est souhaité ou requis. L' PEPs omniprésence dans une application garantit que l'autorisation est vérifiée souvent et indépendamment à plusieurs reprises.    

Pour mettre en œuvre un PEP, la première étape consiste à déterminer où le contrôle d'accès doit être appliqué dans une application. Tenez compte de ce principe lorsque vous PEPs décidez où intégrer dans votre application : 

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

En effet, dans une architecture orientée vers les microservices ou orientée services, ils APIs servent de séparateurs entre les différentes fonctions de l'application. Il est logique d'inclure le contrôle d'accès comme point de contrôle logique entre les fonctions de l'application. Nous vous recommandons vivement de l'inclure PEPs comme condition préalable à l'accès à chaque API dans une application SaaS. Il est également possible d'intégrer l'autorisation à d'autres points d'une application. Dans les applications monolithiques, il peut être nécessaire de les PEPs intégrer dans la logique de l'application elle-même. Il n'y a pas d'emplacement unique qui PEPs devrait être inclus, mais pensez à utiliser le principe de l'API comme point de départ.

Demande de décision d'autorisation

Un PEP doit demander une décision d'autorisation au PDP. La demande peut prendre plusieurs formes. La méthode la plus simple et la plus accessible pour demander une décision d'autorisation consiste à envoyer une demande d'autorisation ou une requête à une RESTful API exposée par le PDP (OPA ou Verified Permissions). Si vous utilisez des autorisations vérifiées, vous pouvez également appeler la IsAuthorizedméthode en utilisant le AWS SDK pour récupérer une décision d'autorisation. La seule fonction d'un PEP dans ce modèle est de transmettre les informations nécessaires à la demande d'autorisation ou à la requête. Cela peut être aussi simple que de transférer une demande reçue par une API en entrée au PDP. Il existe d'autres méthodes de création PEPs. Par exemple, vous pouvez intégrer un PDP OPA localement à une application écrite dans le langage de programmation Go sous forme de bibliothèque au lieu d'utiliser une API.

Évaluation d'une décision d'autorisation

PEPs nécessité d'inclure une logique pour évaluer les résultats d'une décision d'autorisation. Lorsqu'elles PDPs sont exposées en tant que APIs, la décision d'autorisation est probablement au format JSON et renvoyée par un appel d'API. Le PEP doit évaluer ce code JSON pour déterminer si l'action entreprise est autorisée. Par exemple, si un PDP est conçu pour fournir une décision booléenne d'autorisation ou de refus, le PEP peut simplement vérifier cette valeur, puis renvoyer le code d'état HTTP 200 pour autoriser et le code d'état HTTP 403 pour refuser. Ce modèle d'incorporation d'un PEP comme condition préalable à l'accès à une API est un modèle facile à mettre en œuvre et très efficace pour mettre en œuvre le contrôle d'accès dans une application SaaS. Dans des scénarios plus complexes, le PEP peut être chargé d'évaluer le code JSON arbitraire renvoyé par le PDP. Le PEP doit être écrit de manière à inclure toute la logique nécessaire pour interpréter la décision d'autorisation renvoyée par le PDP. Étant donné qu'un PEP est susceptible d'être implémenté à de nombreux endroits différents de votre application, nous vous recommandons de packager votre code PEP sous forme de bibliothèque ou d'artefact réutilisable dans le langage de programmation de votre choix. Ainsi, votre PEP peut être facilement intégré à n'importe quel point de votre application avec un minimum de retouches.