Comment iDBQuery gère-t-il la sécurité au niveau des lignes et les permissions ?

iDBQuery contrôle l'accès à plusieurs niveaux plutôt que d'exposer tout à tout le monde : - L'authentification décide qui peut se connecter. - Les permissions basées sur les rôles décident quels projets et sources de données chaque utilisateur ou équipe peut voir, de sorte que chacun n'atteint que les données qui lui sont accordées. - Les identifiants de connexion régissent ce qu'iDBQuery lui-même peut lire ; il interroge sous les comptes de base de données que vous configurez, héritant ainsi des permissions de lecture que ces comptes appliquent déjà et les respectant.

Cela signifie que si un compte de connexion ne peut pas voir un schéma ou une table, les questions posées à travers lui ne le peuvent pas non plus. Pour une isolation plus forte, vous pouvez donner à différentes équipes leurs propres projets et connexions restreints aux données qu'elles sont autorisées à toucher.

Le contrôle le plus important reste toutefois le déploiement. Comme iDBQuery peut fonctionner dans votre propre VPC ou entièrement isolé (air-gapped), et interroge vos données sur place plutôt que de les copier au-dehors, les données sensibles n'ont jamais à quitter votre environnement en premier lieu ; la forme la plus forte de contrôle d'accès, ce sont des données qui ne bougent jamais. Les données sont chiffrées en transit et au repos, et vos données ne sont jamais utilisées pour entraîner un modèle d'IA. Pour les équipes qui ont besoin de restrictions par ligne appliquées en amont, iDBQuery honore les propres politiques de sécurité au niveau des lignes de la base de données car il exécute un véritable SQL via vos identifiants contrôlés. Le principe directeur est l'architecture d'abord : la frontière la plus sûre est celle que votre propre infrastructure applique déjà.