Sécurité et contrôles en lecture seule

Cette page décrit ce que Datarelix peut faire de vos données et ce qui est transmis au modèle, au niveau des mécanismes — les limites, les plafonds et les codes d’erreur dont vous avez besoin pendant la configuration. Le résumé destiné aux clients se trouve sur datarelix.ai/fr/security, et le traitement des données personnelles est décrit dans la politique de confidentialité.

Vous menez un audit de sécurité fournisseur plutôt qu’une installation ? Le modèle de menaces derrière ces mécanismes — ce que chaque contrôle bloque, et les risques qui subsistent malgré tout — est exposé dans l’analyse de données par IA en lecture seule, et les questions à poser à tout fournisseur de cette catégorie figurent dans la liste de contrôle sécurité pour l’analytique IA.

Le modèle planifie ; il n’exécute rien

Le modèle n’exécute jamais rien. Il reçoit votre question et les métadonnées de schéma, puis renvoie un plan structuré. Une couche d’exécution distincte contrôle ce plan par rapport à un schéma strict, puis exécute elle-même chaque étape.

C’est cette frontière qui fait qu’une instruction erronée ou hallucinée n’a nulle part où aller : le modèle n’a aucun outil à appeler, ne détient aucune connexion, et aucun chemin ne mène de sa sortie à votre base de données en contournant la validation.

Chaque requête est validée avant son exécution

Les requêtes générées sont vérifiées avant leur exécution, pas après :

Moteurs SQL — l’instruction est analysée en arbre syntaxique complet et rejetée si ce n’est pas une lecture. SELECT, les CTE et les opérations ensemblistes passent ; tout ce qui écrit, modifie la structure ou administre le serveur est rejeté.
KQL (Kusto) et ES|QL (Elasticsearch) — ce n’est pas du SQL : chacun a donc son propre validateur, qui exige une requête de forme lecture et bloque les commandes de modification et d’administration.
Portée — les requêtes sont limitées aux schémas, jeux de données ou motifs d’index que vous avez autorisés sur la connexion.
Plafonds — chaque requête porte un plafond de lignes (5 000 lignes) et une limite de 30 secondes.

Une requête qui échoue à la validation n’atteint jamais votre base de données. Vous la voyez sous la forme d’une erreur SQL_VALIDATION — voir les codes d’erreur.

Les identifiants restent hors de portée du modèle

Les identifiants de connexion sont chiffrés au repos et déchiffrés uniquement au moment où une connexion est ouverte pour exécuter une requête. Ils sont détenus par la couche d’exécution, ne sont jamais placés dans une invite et ne sont jamais renvoyés dans une réponse d’API.

Le modèle reçoit la question, les métadonnées de schéma et le contexte de la conversation. Il ne reçoit ni chaîne de connexion, ni hôte, ni nom d’utilisateur, ni mot de passe, ni jeton, ni clé — et aucun chemin de code ne lui permettrait d’en demander un.

Vous pouvez réduire ce que tout cela peut atteindre en connectant un utilisateur de base de données en lecture seule et à portée limitée. Chaque guide de connexion fournit exactement les droits correspondants, et c’est la configuration que nous recommandons. Deux faits à énoncer honnêtement : Datarelix peut lire tout ce que l’identifiant que vous connectez peut lire, et un utilisateur en lecture seule à portée restreinte est le contrôle qui change cela. L’application de la lecture seule décrite plus haut vaut dans les deux cas.

L’analyse générée s’exécute dans un bac à sable isolé

Lorsqu’une question nécessite du Python — une statistique, une transformation, une entrée de graphique — le code généré s’exécute dans un environnement isolé, pas dans l’application :

Aucun accès à Internet. Le trafic sortant est bloqué au niveau réseau par un pare-feu de sortie, et non par une vérification à l’intérieur du code exécuté.
Plafonds de ressources stricts. 512 Mo de mémoire et 90 secondes de temps réel ; dépasser l’un ou l’autre fait échouer l’étape, pas le service.
Aucun identifiant, aucune base de données. Le bac à sable reçoit les résultats de requête qui lui ont été transmis, et rien d’autre. Il ne peut pas ouvrir de connexion.

Plus de détails sur l’usage de cet environnement dans Analyse Python.

Vos données sont cloisonnées dans votre compte

Les connexions, exécutions, conversations, tableaux de bord et artefacts appartiennent au compte qui les a créés. Deux mécanismes l’imposent : chaque lecture est filtrée par propriétaire dans la requête elle-même, et chaque point d’accès vérifie la propriété — pour un résultat ou un graphique, en remontant jusqu’à l’exécution qui l’a produit — avant de renvoyer quoi que ce soit. Sur les tables de données utilisateur, la sécurité au niveau des lignes de la base de données vient en dernier rempart derrière les deux.

Il n’existe aujourd’hui aucun modèle de partage — aucun moyen de transmettre une connexion, une conversation ou un tableau de bord à un autre utilisateur, et aucune donnée d’espace de travail partagé. Un plan Team partage l’abonnement et le pool de questions, pas les données : chaque membre conserve ses propres connexions et son propre historique. Voir Facturation et plans.

Ce qui parvient réellement au modèle

Votre question, telle que vous l’avez saisie.
Les métadonnées de schéma — noms de tables et de colonnes, types, clés, relations et les descriptions que vous avez rédigées. L’analyse IA du schéma part de la structure ; aucun échantillon de lignes ne lui est envoyé.
Le contexte de la conversation pour les questions de suivi — les questions précédentes du fil, les requêtes exécutées et leur nombre de lignes. Lorsqu’un échange précédent a renvoyé un résultat sur une seule ligne, les valeurs de cette ligne peuvent être reprises comme contexte pour qu’un « et le mois dernier ? » se résolve correctement. Autrement dit : les résultats volumineux ne sont jamais renvoyés au modèle, mais une réponse scalaire que vous avez déjà vue à l’écran peut l’être.
Des informations dérivées sur les colonnes lors de la construction d’un graphique — la forme d’une colonne (une indication de rôle, son nombre de valeurs distinctes), pas ses valeurs.

Les résultats eux-mêmes vous sont renvoyés et conservés avec l’exécution. Ils ne sont pas réinjectés dans le modèle comme données à raisonner.

Chaque exécution conserve sa trace

Une exécution est enregistrée sous forme de relevé étape par étape : la question, le plan renvoyé, la requête réellement exécutée, les tables utilisées, le nombre de lignes et le temps d’exécution. Vous pouvez rouvrir chacun de ces éléments depuis votre historique, ce qui signifie qu’une réponse peut être vérifiée après coup plutôt que crue sur parole.

Il s’agit d’un historique d’exécutions par compte, pas d’un journal d’audit à l’échelle de l’organisation, et il n’existe ni rôles d’administration ni niveaux de permission — chaque compte détient ses propres données et voit ses propres exécutions.

Ce que nous n’affirmons pas

Pas de journal d’audit à l’échelle de l’organisation, pas de contrôle d’accès par rôles, pas de provisionnement d’utilisateurs (SCIM). Non développés.
Pas de choix de résidence des données. Vous ne choisissez pas aujourd’hui de région de traitement.
Aucune garantie que la réponse soit celle que vous vouliez dire. Une question peut être interprétée autrement que vous ne l’entendiez ; la requête s’exécute quand même, elle mesure simplement quelque chose de voisin. C’est exactement pour cela que chaque réponse est accompagnée de sa requête et de ses sources — un coup d’œil vous dit ce qui a été mesuré. Quelle que soit l’interprétation, il ne peut jamais s’agir que d’une lecture.
Un modèle d’IA traite vos questions. Nous gérons le fournisseur, les clés et la configuration ; la politique de confidentialité précise qui traite quoi.

Si vous avez un audit de sécurité à mener ou des exigences qui vont au-delà, parlons-en.

Pages liées

Authentification — connexion, sessions, clés d’API et identité de base de données par utilisateur.
Guides de connexion — les droits en lecture seule pour chaque moteur.
Codes d’erreur — à quoi ressemble le retour d’une requête rejetée.