Puis-je donner à iDBQuery un utilisateur de base de données en lecture seule ?

iDBQuery est un outil en lecture seule par conception : il rédige du SQL pour répondre aux questions et l'exécute sur vos données, mais il ne modifie jamais votre base. La façon la plus sûre et recommandée de se connecter passe par un utilisateur dédié en lecture seule.

Comment le mettre en place :

• Créez un rôle / utilisateur doté des seuls privilèges SELECT (sans INSERT, UPDATE, DELETE ni DDL).
• Restreignez-le aux seuls schémas ou tables que vous voulez rendre visibles à iDBQuery, si vous souhaitez limiter davantage l'exposition.
• Confiez ces identifiants à iDBQuery, qui les stocke chiffrés.

Avec un utilisateur en lecture seule, même dans le cas improbable d'une mauvaise requête, iDBQuery ne peut rien modifier — la base elle-même impose la limite. C'est un accès au moindre privilège à la source, et pas seulement une promesse logicielle.

Cela se marie aussi naturellement avec les autres garde-fous d'iDBQuery : interrogation sur place afin que vos données ne soient pas copiées de force, chiffrement en transit et au repos, accès basé sur les rôles au sein d'iDBQuery, et déploiement dans votre propre VPC, sur site ou isolé (air-gapped) afin que les données restent dans vos murs.

Exemple : une entreprise souhaite que ses utilisateurs métier fassent de l'analytique en libre-service sur la base de production sans aucun risque pour celle-ci. Elle crée un utilisateur en lecture seule sur une réplica, le confie à iDBQuery, et toute l'équipe obtient des réponses sourcées — la base étant démontrablement protégée contre toute écriture. Vous contrôlez exactement ce que cet utilisateur peut voir.