iDBQuery respecte-t-il mon propre identifiant de base de données et ses autorisations ?

L'accès d'iDBQuery à une source n'est jamais plus large que les identifiants que vous lui remettez, ce qui vous donne un levier de contrôle familier, au niveau de la base de données.

• Vos identifiants, vos limites. Connectez-vous avec un utilisateur de base de données, et iDBQuery ne peut atteindre que ce que cet utilisateur peut atteindre. Si le compte ne peut pas voir un schéma ou une table, iDBQuery non plus.
• Moindre privilège par conception. La bonne pratique est un compte en lecture seule limité aux seules données que vous voulez analyser — une réplique de lecture, un schéma de reporting, un sous-ensemble de tables — ce qui plafonne l'empreinte d'iDBQuery à la source.
• En couches avec les contrôles applicatifs. Par-dessus les autorisations de la base de données, iDBQuery ajoute son propre accès basé sur les rôles et sa sécurité des lignes/colonnes, de sorte que vous pouvez différencier davantage ce que chaque utilisateur voit à l'intérieur de ce que la connexion autorise.

Ce modèle à deux couches — le propre système d'autorisations de votre base de données plus celui d'iDBQuery — est rassurant lorsqu'on pointe un outil d'IA vers de vrais systèmes. Il signifie que vous pouvez raisonner sur l'accès à l'aide d'outils auxquels vous faites déjà confiance, et il complète les choix de déploiement comme le VPC, le Desktop ou l'isolement du réseau. Chaque requête qu'iDBQuery exécute est visible et sourcée, de sorte que vous pouvez aussi confirmer qu'il n'a jamais lu que dans les limites permises par son identifiant.