Vues SQL Sécurisées : Générer des statistiques sans briser le RLS

Dans la conception d'applications SaaS multi-tenant modernes (comme un orchestrateur SOC gérant de multiples clients), l'architecture de la base de données est le nerf de la guerre. Pour garantir qu'aucun client ne puisse accéder aux incidents d'un autre client, l'industrie a adopté une norme absolue : le Row-Level Security (RLS) de PostgreSQL.

Le RLS verrouille chaque ligne de la base de données selon l'identité de l'analyste. Mais que se passe-t-il lorsque vous devez générer des statistiques globales (comme calculer le MTTR ou le nombre total de tickets) via des vues SQL (VIEWS) ou des fonctions d'agrégation ?

Si la vue SQL est mal conçue, elle peut contourner les règles RLS et fuiter des données statistiques entre les clients. Découvrez comment l'architecture d'Akuity SOC résout ce casse-tête grâce au modificateur SECURITY INVOKER.

Le problème : L'agrégation de données contourne souvent le RLS

Imaginez que vous deviez construire le tableau de bord des KPIs de votre SOC. Vous devez interroger la table Tickets (qui contient des milliers de logs de Microsoft Defender) pour faire un COUNT() ou calculer une moyenne (AVG()) du temps de résolution.

La solution classique d'un DBA (Database Administrator) est de créer une vue SQL (CREATE VIEW viewworkspacekpis AS SELECT ...).

Par défaut, dans de nombreuses bases de données ou frameworks historiques, les vues ou fonctions sont exécutées avec les droits de la personne qui a créé la vue (le propriétaire de la base de données). C'est ce qu'on appelle le mode SECURITY DEFINER.

Le danger est critique : Si une vue s'exécute en tant que super-administrateur de la base, elle contourne totalement les règles RLS. L'analyste SOC du Client A interroge la vue pour obtenir son MTTR, mais la vue, s'exécutant sans filtre RLS, va agréger et retourner le MTTR global du système, incluant les données du Client B. Même si l'interface web essaie de masquer l'erreur, la fuite de métadonnées est avérée et vous perdez votre conformité SOC 2.

La solution PostgreSQL : Le SECURITY INVOKER

Pour qu'un dashboard de KPIs SaaS soit à la fois performant et parfaitement cloisonné, il faut forcer le moteur SQL à évaluer la vue ou la fonction avec les permissions exactes de l'utilisateur final (l'analyste connecté), et non celles du créateur de la base.

C'est là qu'intervient le modificateur SECURITY INVOKER.

Dans l'architecture de la plateforme Akuity SOC (propulsée par Supabase/PostgreSQL), nos tableaux de bord statistiques (comme l'Area Chart des 30 derniers jours ou le calcul du Taux de Résolution) ne s'appuient jamais sur des requêtes applicatives lourdes. Ils interrogent des vues SQL pré-compilées qui respectent scrupuleusement cette règle.

L'implémentation dans Akuity SOC

Dans notre script de migration de base de données, la vue responsable des statistiques est déclarée ainsi :

CREATE VIEW view_workspace_kpis 
WITH (security_invoker = on) AS 
SELECT 
    t.workspace_id,
    COUNT(tk.id) as total_incidents,
    AVG(tk.resolution_time) as mttr_minutes
FROM tenants t 
LEFT JOIN tickets tk ON tk.tenant_id = t.id 
GROUP BY t.workspace_id;

De même, les requêtes permettant d'afficher le graphique temporel de la charge de travail utilisent une fonction stockée getdailyincident_count qui est définie avec SECURITY INVOKER.

L'impact opérationnel et la conformité SOC 2

Grâce à cette ligne de code WITH (security_invoker = on), la magie du cloud natif opère :

1. L'analyste (authentifié via un jeton JWT contenant son auth.uid()) demande l'affichage de son Dashboard sur l'interface Akuity.
2. La requête API appelle la vue viewworkspacekpis.
3. Le moteur PostgreSQL évalue la vue en tant que cet analyste.
4. Les règles RLS natives des tables sous-jacentes (tenants et tickets) s'appliquent brutalement avant l'agrégation. Les lignes des clients auxquels l'analyste n'a pas accès sont invisibles. L'agrégation COUNT() ou AVG() ne se fait que sur les données permises.

Pourquoi les auditeurs exigent cette architecture

Lors d'un audit de conformité de type SOC 2 Type II ou NIS 2, l'auditeur cherche à prouver que le système ne repose pas uniquement sur des promesses logicielles (le code frontend React/Next.js) mais sur des contrôles de sécurité systémiques ("Security by Design"). L'utilisation conjointe du RLS et des vues SECURITY INVOKER offre une preuve cryptographique et mathématique de l'isolation absolue des données de vos locataires.

Conclusion : L'analytique SaaS sans compromis

Construire des tableaux de bord pour un centre d'opérations de sécurité multi-tenant ne doit jamais être une porte dérobée pour les métadonnées. En exigeant une architecture de base de données irréprochable basée sur PostgreSQL, vous garantissez à vos clients MSSP ou à votre Comex que les statistiques affichées sont non seulement précises, mais étanches par conception.

Pilotez vos KPIs avec une sécurité de niveau entreprise. > Découvrez l'architecture souveraine de nos Tableaux de Bord SOC RLS et KPIs développés en Bavière.