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 :
- 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.
- 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 :
- Caches : chaque clé de cache commence par l'identifiant de l'environnement.
- Événements et tâches : chaque événement interne transporte son environnement, et les consommateurs définissent leur périmètre de base de données à partir de celui-ci ; chaque tâche mise en file d'attente transporte l'environnement auquel elle appartient.
- Clés : les clés de chiffrement et de signature sont distinctes pour chaque environnement.
- Journaux : les lignes de journal portent l'environnement comme champ, et l'API des journaux d'environnement ne renvoie que les entrées de l'environnement appelé.
- Travaux de fond : les tâches de maintenance (nettoyage selon la durée de conservation, suppressions) s'exécutent environnement par environnement, chacune dans sa propre transaction limitée.
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 :
- chaque table contenant des données d'environnement a la sécurité au niveau des lignes activée et forcée ;
- chaque surface d'API renvoie
404ou401pour les ressources, jetons et clients d'un autre environnement ; - les tâches de fond ainsi que le pipeline de journaux et d'événements ne touchent que l'environnement nommé dans leurs données d'entrée.
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.