Isolation des locataires grâce au modèle documentaire OPA

L'OPA utilise des documents pour prendre des décisions. Ces documents peuvent contenir des données spécifiques au locataire. Vous devez donc réfléchir à la manière de maintenir l'isolation des données du locataire. Les documents OPA se composent de documents de base et de documents virtuels. Les documents de base contiennent des données provenant du monde extérieur. Cela inclut les données fournies directement à l'OPA, les données relatives à la demande de l'OPA et les données susceptibles d'être transmises à l'OPA en tant qu'entrée. Les documents virtuels sont calculés par politique et incluent les politiques et règles de l'OPA. Pour plus d'informations, consultez la documentation de l'OPA.

Pour concevoir un modèle de document dans OPA pour une application multi-locataires, vous devez d'abord déterminer le type de documents de base dont vous aurez besoin pour prendre une décision dans OPA. Si ces documents de base contiennent des données spécifiques au locataire, vous devez prendre des mesures pour vous assurer que ces données ne sont pas accidentellement exposées à un accès entre locataires. Heureusement, dans de nombreux cas, les données spécifiques au locataire ne sont pas nécessaires pour prendre une décision dans OPA. L'exemple suivant montre un modèle de document OPA hypothétique qui autorise l'accès à une API en fonction du locataire propriétaire de l'API et du fait que l'utilisateur est membre du locataire, comme indiqué dans le document d'entrée.

Dans cette approche, l'OPA n'a accès à aucune donnée spécifique au locataire, à l'exception des informations sur les locataires qui possèdent une API. Dans ce cas, le fait que l'OPA facilite l'accès entre locataires ne suscite aucune inquiétude, car les seules informations que l'OPA utilise pour prendre une décision d'accès sont l'association d'un utilisateur avec un locataire et l'association du locataire avec APIs. Vous pouvez appliquer ce type de modèle de document OPA à un modèle SaaS cloisonné, car chaque locataire serait propriétaire de ressources indépendantes.

Cependant, dans de nombreuses approches d'autorisation RBAC, il existe un risque d'exposition d'informations entre locataires. Dans l'exemple suivant, un modèle de document OPA hypothétique autorise l'accès à une API selon que l'utilisateur est membre d'un locataire et qu'il possède le rôle approprié pour accéder à l'API.

Ce modèle présente un risque d'accès entre locataires, car les rôles et autorisations de plusieurs locataires data.tenant2.user_roles doivent désormais être rendus accessibles à data.tenant1.user_roles l'OPA pour prendre des décisions en matière d'autorisation. Pour préserver l'isolement des locataires et la confidentialité du mappage des rôles, ces données ne doivent pas résider dans l'OPA. Les données RBAC doivent résider dans une source de données externe telle qu'une base de données. En outre, l'OPA ne doit pas être utilisée pour associer des rôles prédéfinis à des autorisations spécifiques, car cela rend difficile pour les locataires de définir leurs propres rôles et autorisations. Cela rend également votre logique d'autorisation rigide et nécessite une mise à jour constante. Pour obtenir des conseils sur la manière d'intégrer en toute sécurité les données RBAC dans le processus décisionnel de l'OPA, consultez la section Recommandations pour l'isolation des locataires et la confidentialité des données plus loin dans ce guide.

Vous pouvez facilement maintenir l'isolement des locataires dans OPA en ne stockant aucune donnée spécifique au locataire sous forme de document de base asynchrone. Un document de base asynchrone est une donnée qui est stockée en mémoire et qui peut être mise à jour périodiquement, dans OPA. D'autres documents de base, tels que les entrées OPA, sont transmis de manière synchrone et ne sont disponibles qu'au moment de la décision. Par exemple, la fourniture de données spécifiques au locataire dans le cadre de la saisie par l'OPA d'une requête ne constituerait pas une violation de l'isolement du locataire, car ces données ne sont disponibles que de manière synchrone pendant le processus de prise de décision.