Analytique IA en lecture seule : architecture, contrôles et menaces
Avant de connecter une base, vérifiez quelles lectures sont autorisées, quelles actions sont bloquées et qui peut consulter les réponses.
Par l'équipe Datarelix · Publié le · Mis à jour le · Vérifié le
Pour produire un rapport de ventes, un outil d’analyse doit lire les commandes et calculer des totaux. Il n’a pas besoin de supprimer des commandes, de modifier des prix ou de créer des utilisateurs. La lecture seule limite ces actions, mais permet toujours de lire des informations sensibles et de consommer des ressources de la base.
Ce guide aide les utilisateurs métier et les analystes à comprendre les accès dont leur reporting a besoin, et donne aux responsables de bases et aux relecteurs sécurité le détail nécessaire pour les évaluer. Les exemples décrivent Datarelix ; cette liste de contrôle ne constitue pas une certification indépendante.
Commencer par les droits du compte
Utilisez un compte dédié aux tables ou aux vues nécessaires au rapport. Demandez au responsable de la base de vérifier les rôles hérités, les droits publics, les fonctions exécutables et les règles d’accès aux lignes, en plus des autorisations directement accordées. Une liste de droits SELECT ne décrit pas à elle seule tous les droits effectifs du compte.
PostgreSQL accorde par défaut certains droits à PUBLIC, notamment TEMPORARY sur les bases et EXECUTE sur les fonctions. Leur modification peut affecter d’autres applications : elle demande un examen de la configuration existante. Documentation PostgreSQL sur les privilèges
La documentation des connexions décrit la configuration. Si vous avez besoin d’une authentification individuelle auprès de la base avec Enterprise, confirmez d’abord le connecteur et les modalités disponibles avec Datarelix.
Les contrôles avant l’exécution
Le modèle propose un plan structuré sans rien exécuter lui-même ; comment le text-to-SQL génère les requêtes suit une question à travers ce parcours. Datarelix valide le plan et contrôle les requêtes avant leur exécution par son service de requêtes. Le SQL est analysé syntaxiquement ; KQL et ES|QL suivent leurs propres règles. Les limites de résultats bornent le nombre de lignes renvoyées, pas nécessairement le volume de données parcouru par la base.
Voici un exemple volontairement dangereux, à ne pas exécuter :
WITH removed AS (
DELETE FROM orders WHERE status = 'test' RETURNING order_id
)
SELECT COUNT(*) FROM removed;
Le SELECT final ne transforme pas le DELETE en lecture. La validation SQL de Datarelix rejette ce type de modification imbriquée. Les autorisations de la base constituent un autre contrôle, dont la portée dépend du rôle configuré.
Associer chaque risque aux contrôles pertinents
| Risque | Contrôle Datarelix concerné | Point à examiner également |
|---|---|---|
| Le SQL tente une modification | Validation des requêtes en lecture seule | Droits effectifs, fonctions et rôles hérités |
| Une lecture autorisée révèle des champs sensibles | Périmètre du compte connecté | Tables, colonnes et lignes accessibles |
| Le Python généré tente d’envoyer des données ailleurs | Environnement d’analyse avec sorties réseau bloquées et ressources limitées | Circulation des données en dehors de cet environnement |
| Une instruction demande un mot de passe | Identifiants exclus du contexte du modèle | Gestion de la connexion et renouvellement du secret |
| Un utilisateur demande les résultats d’un autre compte | Contrôles d’accès par compte | Configuration des identités et besoins de partage |
| Une lecture consomme beaucoup de calcul | Délais et limites des connecteurs | Plan de requête, réglages de calcul et facturation |
Ces contrôles répondent à des problèmes différents. Une limite de processeur ne remplace pas une restriction réseau. Le chiffrement au repos ne définit pas quel service peut déchiffrer un identifiant.
Examiner les données qui quittent la base
Datarelix conserve des résultats et des éléments d’exécution pour permettre de rouvrir le travail. Le modèle reçoit les questions, les informations de schéma, les descriptions et le contexte de conversation. Le contexte d’une question suivante peut inclure certaines valeurs d’un résultat à une ligne, y compris du texte. Un message d’erreur de la base peut aussi servir à corriger une requête. Ce mécanisme de suivi n’inclut pas les tableaux de résultats à plusieurs lignes.
Les identifiants sont chiffrés au repos. Les services de connexion les utilisent pour tester l’accès, découvrir le schéma et exécuter les requêtes ; ils ne sont pas transmis au modèle. Consultez le guide des identifiants et des données, la présentation sécurité et la politique de confidentialité.
Le modèle de menace
Ces cinq scénarios constituent un point de départ. Ajoutez les risques propres à vos données et à votre déploiement ; ce modèle de menace n’est pas exhaustif.
| # | Menace | Vecteur | À quoi ressemble la défaillance |
|---|---|---|---|
| T1 | Tentative d’écriture par injection de prompt | Du texte malveillant dans une question, ou dans des descriptions de tables renseignées à la main, oriente le modèle vers une instruction de modification | Le système exécute une écriture que l’utilisateur n’a jamais voulue |
| T2 | SQL destructif | Le modèle émet DROP, DELETE, TRUNCATE ou du DDL — halluciné ou induit | Perte de données ou dégradation du schéma dans la base connectée |
| T3 | Exfiltration par le code d’analyse généré | Le code Python généré tente d’envoyer les résultats de requête vers un hôte externe | Les données de résultat quittent l’environnement par le réseau |
| T4 | Exposition des identifiants au modèle | Un prompt façonné amène des détails de connexion dans une réponse du modèle | Des chaînes de connexion ou des secrets apparaissent dans la conversation |
| T5 | Accès entre comptes | Une requête émise par un compte atteint les connexions, exécutions ou tableaux de bord d’un autre compte | Les données d’un client sont visibles par un autre |
T1 et T2 diffèrent par l’intention — l’une malveillante, l’autre une erreur du modèle — mais convergent vers le même point de passage obligé.
Examiner chaque contrôle séparément
La validation des requêtes et les droits de la base portent sur des éléments différents. Le validateur examine la syntaxe générée et les opérations permises. La base applique les droits effectifs de l’identité connectée, avec ses rôles hérités et ses politiques. Une erreur de configuration mérite une investigation ; parler de deux couches ne prouve pas que leurs défaillances sont indépendantes.
Un SELECT peut lire davantage d’informations que le rapport n’en demande, effectuer une jointure coûteuse ou appeler une fonction. Examinez les fonctions accessibles avec le responsable de la base. Pour les sources volumineuses, consultez l’historique et les plans d’exécution côté source, en complément de la limite de lignes renvoyées.
La validation du plan sépare une proposition de son exécution. Elle restreint les actions demandées, mais une injection de prompt peut encore influencer la lecture autorisée proposée ou l’interprétation de la question. Conserver un plan aide à enquêter ; enregistrer une action ne l’empêche pas.
Code généré et ensemble des flux de données
Lorsqu’une question utilise du Python généré, l’environnement d’analyse hébergé bloque les sorties réseau et impose des limites de ressources. Examinez ces contrôles pour cet environnement précis. Les limites de processeur ou de mémoire encadrent la consommation ; elles ne bloquent pas indépendamment une divulgation.
Cet environnement n’est qu’une partie du système. Les résultats passent aussi par le service pour parvenir à l’utilisateur et sont conservés avec les fichiers d’exécution. Questions, descriptions de schéma, erreurs de base et certaines valeurs de résultats d’une seule ligne peuvent être traitées par le modèle. Bloquer le réseau du code d’analyse ne signifie pas qu’aucune information ne quitte la base ou n’atteint un fournisseur de modèle.
Les graphiques ordinaires ne nécessitent pas de Python généré. Vérifiez le parcours réellement utilisé, sans supposer que chaque graphique exécute du code isolé. La documentation Python décrit cet environnement.
Examiner un parcours de reporting représentatif
Choisissez un jeu de test approuvé et une identité aux droits adaptés à l’usage prévu. L’utilisateur métier identifie le rapport et les champs sensibles nécessaires ; l’analyste examine le SQL ; le responsable de la base confirme les droits effectifs et les limites côté source.
- Posez une question dont la réponse est connue et vérifiez tables, filtres et résultat.
- Dans l’environnement de test autorisé, vérifiez une table interdite à cette identité. Conservez le résultat du contrôle et la configuration.
- Examinez le traitement d’une requête en échec et la validation du SQL corrigé.
- Rouvrez la réponse et établissez quel compte peut consulter le résultat conservé.
- Documentez la révocation et la rotation des identifiants avec le responsable de la connexion.
Ces tests étayent des conclusions sur cette configuration. Ils ne démontrent pas une résistance à toutes les entrées et ne remplacent pas une évaluation plus large. Gardez les preuves des contrôles nécessaires à votre usage et suivez les exigences non résolues avec la liste de contrôle sécurité.
Adapter l’accès au travail prévu
Une vue contenant les champs de vente autorisés peut suffire à un bilan mensuel. Une enquête qui nécessite les coordonnées des clients demande un autre examen. La lecture seule ne tranche pas ces décisions et ne prouve pas qu’une réponse est correcte.
Posez une question représentative, examinez la source et le résultat, puis faites vérifier le calcul par une personne qui maîtrise SQL. La liste de contrôle de sécurité permet de consigner vos exigences.