Avant de connecter un outil de BI auto-hébergé à une base de données : liste de contrôle du moindre privilège

Cartographiez la connexion et les responsabilités

Cette liste de contrôle sert à préparer votre examen ; elle ne décrit pas des contrôles disponibles dans chaque application de BI ou chaque base de données. Pour les éléments ci-dessous, consultez la documentation correspondant aux produits, aux versions et à la méthode de connexion que vous prévoyez d’utiliser.

Commencez par consigner quelle application se connectera à quelles bases de données, quel compte sera utilisé et qui administrera chaque partie du parcours. Examinez séparément les rôles de l’application et les autorisations du compte dans la base de données.

• Quelle instance de l’application de BI et quelles bases de données sont concernées ?
• Qui peut créer ou modifier des rapports, et qui peut consulter les rapports partagés ?
• Où les identifiants sont-ils gérés, et qui peut les modifier ?
• Quelles équipes administrent l’application, le réseau et la base de données ?

Choisissez un compte dédié en lecture seule

Pour la connexion BI, utilisez un compte dédié en lecture seule plutôt qu’une connexion en tant que root ou avec un compte disposant d’un accès en écriture. Un [guide Basedash sur la création de tableaux de bord à partir de données MySQL](https://www.basedash.com/blog/how-to-build-dashboards-on-mysql-data) recommande cette approche.

La portée exacte de cet accès dépend de votre base de données et de votre configuration. Vérifiez dans sa documentation, avec l’administrateur concerné, quelles données le compte peut lire et quels privilèges lui sont effectivement accordés.

• Le compte utilisé est-il réservé à la connexion de BI ?
• Est-il en lecture seule, sans privilèges d’écriture ou de connexion root ?
• Quelles données et quels privilèges lui sont accordés dans la configuration réelle ?

Posez les questions relatives aux données sensibles

En vous référant aux politiques de votre organisation, repérez les champs ou enregistrements dont l’accès par les outils d’analyse doit être examiné. Cette liste ne définit aucune exigence juridique ou réglementaire.

Vérifiez dans la documentation et auprès des responsables techniques quels moyens, s’il en existe dans votre configuration, permettraient de limiter l’exposition. Si une restriction est nécessaire, déterminez où elle est censée s’appliquer et comment vous pouvez en vérifier le comportement dans les rapports concernés.

• Quels champs ou groupes d’enregistrements doivent faire l’objet d’un examen particulier ?
• La conception envisagée prévoit-elle de les exclure, de les réduire ou d’en limiter la visibilité ?
• Où la restriction est-elle censée s’appliquer, et comment tester les cas autorisés et interdits ?
• Les rapports partagés ou exportés ont-ils été pris en compte dans cet examen ?

Vérifiez l’impact des rapports et les changements d’identifiants

Avant l’utilisation courante, demandez aux responsables de la base de données quels rapports et modes d’actualisation méritent d’être examinés dans votre environnement. Consultez la documentation de l’application et de la base de données pour repérer les contrôles éventuellement disponibles, puis vérifiez leur comportement dans votre configuration plutôt que de supposer qu’ils existent.

Consignez également qui est responsable de la connexion et ce qui dépend des identifiants. Pour une rotation ou une révocation, documentez la procédure applicable à vos produits et vérifiez comment tester la connexion et les rapports importants après la modification.

• Quels rapports, fréquences d’actualisation et usages simultanés doivent être évalués ?
• Quels contrôles liés aux requêtes sont documentés et vérifiables dans votre configuration ?
• Qui gère la connexion et quels rapports ou tâches planifiées en dépendent ?
• Quelle procédure documentée s’applique aux changements ou à la révocation des identifiants ?

Consignez les vérifications avant le lancement

Une connexion établie ne répond pas à toutes les questions de votre examen. Notez les vérifications effectuées, leur résultat et les points qui restent à confirmer. Les essais doivent correspondre à la configuration et au public auxquels la connexion est destinée.

Si vous ne parvenez pas à vérifier un point important pour votre conception, consignez-le comme une question en suspens à résoudre avec les responsables concernés.

• La connexion accède-t-elle aux données prévues, et les accès non prévus ont-ils été examinés ?
• Les rôles d’utilisateurs et les rapports concernés ont-ils été vérifiés selon la documentation de l’application ?
• Les données sensibles et les rapports partagés ont-ils été examinés ?
• Les responsables concernés ont-ils évalué les requêtes et la procédure de changement des identifiants ?
• Consignez la date, la personne responsable, le résultat et les questions sans réponse.

Distinguez l’hébergement de la gouvernance des données

Un déploiement géré concerne l’exploitation de l’infrastructure applicative ; il ne détermine pas quelles données la connexion BI doit lire ni qui doit voir les résultats. Ces décisions et leur vérification restent à traiter séparément.

Airbip propose le déploiement géré des applications figurant dans son catalogue public. Les instances applicatives s’exécutent sous forme de charges de travail Docker sur les serveurs cloud Airbip. Le service automatise le routage et les certificats TLS et comprend des vérifications DNS, la gestion du cycle de vie des services et des sauvegardes configurables quotidiennes, hebdomadaires et mensuelles. Ces capacités d’infrastructure ne remplacent pas l’examen des accès à la base de données et des contrôles de l’application de BI choisie.