Aller au contenu
datarelix.ai docs

Connecter Azure SQL et Synapse

Datarelix se connecte à Azure SQL Database et à Azure Synapse Analytics via un service de requêtes en lecture seule qui utilise le ODBC Driver 18 for SQL Server. Les deux variantes de T-SQL partagent le même connecteur.

Types de pools Synapse

Synapse expose deux surfaces SQL, dont les modèles d’authentification diffèrent :

Type de poolComment l’accès est accordé
Dedicated SQL pool (pool dédié)Comme Azure SQL Database — nécessite un utilisateur de base de données contenu (CREATE USER ... FROM EXTERNAL PROVIDER)
Serverless SQL pool (pool serverless)Rôles RBAC Synapse attribués dans Synapse Studio — aucune commande SQL nécessaire

Lorsque les étapes de configuration ci-dessous diffèrent selon le type de pool, un encadré signale la différence.

Prérequis

  • Une base Azure SQL Database, un pool SQL dédié Synapse ou un pool SQL serverless Synapse.
  • Un utilisateur SQL (pour l’authentification par mot de passe) ou un principal Entra (pour l’authentification Entra) disposant au minimum de SELECT sur les schémas et les tables que vous voulez analyser.
  • Pare-feu : autorisez les adresses IP de sortie de Datarelix dans le panneau Networking → Public access du serveur SQL (ou utilisez un Private Endpoint). Voir les règles de pare-feu Azure SQL.

Modes d’authentification

Nom d’utilisateur et mot de passe

Authentification SQL classique. Le nom d’utilisateur et le mot de passe sont transmis au pilote ODBC ; le mot de passe est stocké chiffré. Pratique pour les comptes de service de secours.

Configuration — créer un utilisateur SQL en lecture seule

Connectez-vous en tant qu’administrateur du serveur et exécutez :

CREATE LOGIN datarelix_reader WITH PASSWORD = 'choose-a-strong-password';
USE your_db;
CREATE USER datarelix_reader FOR LOGIN datarelix_reader;
ALTER ROLE db_datareader ADD MEMBER datarelix_reader;

Cela accorde un accès en lecture seule via le rôle de base de données fixe db_datareader.

Où trouver vos identifiants

ChampOù le trouver
Host (hôte)Portail Azure → votre serveur SQL → Overview → Server name (par ex. yourserver.database.windows.net)
Port1433 (par défaut)
Database (base de données)Le nom de la base de données
Username (nom d’utilisateur)Le login créé ci-dessus
Password (mot de passe)Le mot de passe défini dans CREATE LOGIN

À saisir

Host:            yourserver.database.windows.net
Port:            1433
Database:        your_db
Allowed schema:  dbo
Username:        datarelix_reader
Password:        ••••••••

Chaîne de connexion

Collez une chaîne de connexion ODBC. Pratique si vous en avez déjà une, issue du portail Azure ou de votre outil de gestion des connexions.

Où trouver votre chaîne de connexion

Portail Azure → votre base Azure SQL Database → Connection strings → onglet ODBC. Copiez-la et remplacez {your_password} par le mot de passe réel.

À saisir

Driver={ODBC Driver 18 for SQL Server};Server=tcp:yourserver.database.windows.net,1433;Database=your_db;Uid=datarelix_reader;Pwd=your-password;Encrypt=yes;TrustServerCertificate=no

Entra OBO

La connexion hérite de l’identité Entra de l’utilisateur actuellement connecté. Son jeton bearer est échangé, via le flux OAuth On-Behalf-Of, contre un jeton limité à https://database.windows.net, que le pilote ODBC utilise directement. Aucun mot de passe n’est stocké. C’est le meilleur choix pour des analystes interactifs, quand vous voulez une attribution d’audit par utilisateur côté base de données.

Pour le contexte, voir l’authentification Microsoft Entra pour Azure SQL et le flux OAuth 2.0 On-Behalf-Of.

Configuration

  1. Dans votre base Azure SQL Database, associez vos utilisateurs Entra à des rôles de base de données. Connectez-vous en tant qu’administrateur Entra et exécutez :

    CREATE USER [user@yourtenant.onmicrosoft.com] FROM EXTERNAL PROVIDER;
    ALTER ROLE db_datareader ADD MEMBER [user@yourtenant.onmicrosoft.com];

    Ou, pour un groupe ou un principal de service :

    CREATE USER [YourEntraGroupName] FROM EXTERNAL PROVIDER;
    ALTER ROLE db_datareader ADD MEMBER [YourEntraGroupName];

  2. L’inscription d’application Entra de Datarelix doit avoir https://database.windows.net/user_impersonation configuré comme autorisation déléguée. Contactez votre administrateur si votre locataire (tenant) exige un consentement administrateur pour cela.

Où trouver vos identifiants

Aucun identifiant supplémentaire à saisir — la connexion utilise automatiquement l’identité de l’utilisateur connecté.

À saisir

Host:            yourserver.database.windows.net
Port:            1433
Database:        your_db
Allowed schema:  dbo
Auth mode:       Entra OBO

Principal de service — secret client

Une inscription d’application Azure AD s’authentifie avec un ID client et un secret client. Adapté aux charges de travail sans intervention humaine. Le secret client est stocké chiffré.

Configuration

  1. Dans le portail Azure, inscrivez une application dans Microsoft Entra ID. Donnez-lui un nom (par ex. datarelix-sql-reader).

  2. Sous Certificates & secrets → Client secrets, ajoutez un secret client. Copiez la valeur (Value) immédiatement — elle n’est affichée qu’une seule fois.

  3. Copiez l’Application (client) ID depuis la page Overview de l’application.

  4. Copiez votre Directory (tenant) ID depuis la même page Overview.

  5. Accordez à l’application un accès en lecture — la méthode dépend du type de pool :

    Azure SQL Database ou pool SQL dédié Synapse — connectez-vous en tant qu’administrateur Entra et exécutez :

    CREATE USER [datarelix-sql-reader] FROM EXTERNAL PROVIDER;
    ALTER ROLE db_datareader ADD MEMBER [datarelix-sql-reader];

    Pool SQL serverless Synapse — ignorez l’étape SQL. Dans Synapse Studio, allez dans Manage → Access control → Add role assignment et attribuez au principal de service le rôle Synapse SQL Administrator (ou un rôle RBAC Synapse personnalisé limité au pool serverless). Aucune commande CREATE USER n’est nécessaire.

Où trouver vos identifiants

ChampOù le trouver
Tenant IDAzure AD → votre inscription d’application → Overview → Directory (tenant) ID
Client IDAzure AD → votre inscription d’application → Overview → Application (client) ID
Client secretAzure AD → votre inscription d’application → Certificates & secrets → la valeur du secret copiée à la création

À saisir

Host:            yourserver.database.windows.net
Port:            1433
Database:        your_db
Allowed schema:  dbo
Auth mode:       Service Principal (secret)
Tenant ID:       xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Client ID:       xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Client secret:   ••••••••

Principal de service — certificat

L’inscription d’application s’authentifie avec un certificat (certificat public téléversé dans Entra, clé privée stockée sur la connexion). Même cas d’usage que la variante par secret, mais avec un identifiant à durée de vie plus longue et plus difficile à exfiltrer.

Configuration

  1. Générez une paire de clés avec certificat :
    Fenêtre de terminal
    openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -nodes -days 365 \
      -subj "/CN=datarelix-sql-reader"
  2. Dans votre inscription d’application → Certificates & secrets → Certificates, téléversez cert.pem (le certificat public). Azure affiche l’empreinte (thumbprint) après le téléversement.
  3. Accordez à l’application un accès en lecture par la même méthode que la variante par secret ci-dessus — CREATE USER / ALTER ROLE pour Azure SQL et les pools dédiés ; attribution d’un rôle RBAC Synapse dans Synapse Studio pour les pools serverless.

Où trouver vos identifiants

ChampOù le trouver
Tenant IDAzure AD → inscription d’application → Overview → Directory (tenant) ID
Client IDAzure AD → inscription d’application → Overview → Application (client) ID
Certificate thumbprint (empreinte)Azure AD → inscription d’application → Certificates & secrets → Certificates → chaîne hexadécimale de 40 caractères affichée après le téléversement
Certificate PEMLe fichier key.pem que vous avez généré — collez le bloc complet -----BEGIN PRIVATE KEY----- … -----END PRIVATE KEY-----

À saisir

Host:                   yourserver.database.windows.net
Port:                   1433
Database:               your_db
Allowed schema:         dbo
Auth mode:              Service Principal (certificate)
Tenant ID:              xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Client ID:              xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Certificate thumbprint: AABBCCDDEEFF...
Certificate PEM:        -----BEGIN PRIVATE KEY-----
                        ...
                        -----END PRIVATE KEY-----

Sémantique de la portée

Le champ Allowed schema (schéma autorisé) limite l’introspection et les requêtes à un seul schéma. Valeur par défaut : dbo. T-SQL utilise la qualification [schema].[table].

Pour analyser plusieurs schémas, créez une connexion par schéma.

Découverte

Entièrement prise en charge. L’introspection parcourt sys.tables, sys.columns, sys.foreign_keys et sys.key_constraints pour faire remonter les tables, les colonnes, les clés primaires et les clés étrangères.

Limites

  • Aucune requête d’écriture ni DDL — le validateur rejette INSERT/UPDATE/DELETE/MERGE/CREATE/ALTER/DROP/GRANT/REVOKE/TRUNCATE.
  • Application de TOP côté serveur : le validateur réécrit le SELECT dans l’arbre syntaxique pour ajouter TOP <row_limit> lorsqu’il est absent.
  • Les fonctionnalités propres à Synapse (tables externes PolyBase, COPY INTO) ne sont pas bloquées par le validateur, mais l’introspection traite les tables externes comme des tables ordinaires.

Dépannage

SymptômeCause probableSolution
Login failed for userIdentifiants SQL incorrects ou pare-feuVérifiez Networking sur le serveur Azure SQL → autorisez les adresses IP de sortie de Datarelix.
Could not open a connection to SQL ServerIncompatibilité TLS ou de piloteVérifiez que le ODBC Driver 18 est bien utilisé ; sur des serveurs plus anciens, vous devrez peut-être ajuster les paramètres d’application de TLS.
Entra OBO renvoie 401Audience ou consentement incohérentVérifiez que l’application Entra a https://database.windows.net/user_impersonation comme autorisation déléguée, et que le consentement administrateur a été accordé si la politique de votre locataire l’exige.
AADSTS65001: The user or administrator has not consentedLe locataire exige un consentement administrateurDemandez à votre administrateur Azure AD d’accorder le consentement pour l’application à l’adresse https://login.microsoftonline.com/<tenant>/adminconsent?client_id=<client-id>
Forbidden: Principal is not authorizedUtilisateur non associé dans la base de donnéesPool dédié / Azure SQL : exécutez CREATE USER ... FROM EXTERNAL PROVIDER et ajoutez-le à db_datareader. Pool serverless : attribuez le rôle RBAC Synapse dans Synapse Studio.
Confidentialité