Isolation des données entre environnements

Chaque environnement KeenAuth (development, staging, production dans chacun de vos projets) constitue un locataire distinct. Les utilisateurs, organisations, applications, sessions, clés, journaux et événements d'un environnement ne sont jamais visibles depuis un autre environnement, y compris un autre environnement de votre propre compte. Cette page explique comment cette frontière est appliquée.

Deux lignes de défense indépendantes

Les environnements partagent un schéma de base de données, et chaque ligne appartenant à un environnement porte l'identifiant de cet environnement. L'isolation est appliquée deux fois, et les deux contrôles doivent échouer simultanément pour que des données franchissent la frontière :

  1. Périmètre d'environnement typé dans l'application. Chaque requête est rattachée à un seul environnement, à partir de son nom d'hôte ou de son identifiant, avant toute lecture de données. Le code qui lit ou écrit des données d'environnement ne peut pas ouvrir une transaction de base de données sans ce périmètre ; un appel qui en est dépourvu est rejeté avant l'exécution de la requête.
  2. Sécurité au niveau des lignes dans PostgreSQL. Chaque table contenant des données d'environnement a la sécurité au niveau des lignes activée et forcée, de sorte que la politique s'applique également au propriétaire de la table. Chaque transaction définit l'environnement courant, et une ligne n'est visible que si son environnement correspond. Une transaction qui n'a pas défini d'environnement ne voit aucune ligne. Aucun rôle applicatif ou de maintenance n'est autorisé à contourner la sécurité au niveau des lignes.

La clé primaire et les index de chaque table limitée à un environnement commencent par l'identifiant de cet environnement, de sorte que la condition d'isolation n'ajoute pas de recherche distincte aux requêtes.

Recherches par jeton ou par clé

Certaines requêtes arrivent avec une seule valeur secrète, par exemple un code d'autorisation, un jeton de rafraîchissement ou une clé d'API. KeenAuth retrouve une telle valeur au moyen d'une recherche basée uniquement sur un condensat, puis compare l'environnement de l'enregistrement stocké à celui de la requête. S'ils diffèrent, la valeur est considérée comme invalide.

Ce que vous observez lorsque vous franchissez la frontière

Tentative Réponse
Lire une ressource appartenant à un autre environnement 404 Not Found ; la réponse ne révèle pas que la ressource existe
Utiliser un jeton d'accès émis par un autre environnement 401 Unauthorized ; chaque environnement dispose de son propre émetteur et de ses propres clés de signature (JWKS)
S'authentifier avec un client enregistré dans un autre environnement invalid_client

Au-delà de la base de données

La même frontière s'applique à tous les autres emplacements où des données d'environnement sont stockées :

Le transfert de configuration d'un environnement à un autre (promotion de configuration) ne copie que les paramètres. Les secrets ainsi que les données des utilisateurs finaux ou des organisations ne font jamais partie d'un lot de promotion.

Comment l'isolation est testée

Une suite de tests d'isolation entre locataires s'exécute dans l'intégration continue de KeenAuth et bloque une modification en cas d'échec. Elle vérifie que :

Une vérification du schéma rejette également toute nouvelle table de données d'environnement dépourvue de la colonne d'identifiant d'environnement.

Voir aussi