Sécuriser et monitorer votre entrepôt de données

4 minutes

La sécurité et le monitoring sont des aspects essentiels de la gestion d’un entrepôt de données.

Sécurité

Il est important de sécuriser un entrepôt de données pour protéger vos données contre tout accès non autorisé. Fabric fournit un certain nombre de fonctionnalités de sécurité pour vous aider à sécuriser votre entrepôt de données. Il s’agit notamment des paramètres suivants :

Contrôle d’accès en fonction du rôle (RBAC) : pour contrôler l’accès à l’entrepôt et à ses données.
Chiffrement SSL : pour sécuriser la communication entre l’entrepôt et les applications clientes.
Azure Storage Service Encryption : pour protéger les données en transit et au repos.
Azure Monitor et Azure Log Analytics : pour monitorer l’activité de l’entrepôt et auditer l’accès aux données.
Authentification multifacteur (MFA) : pour ajouter une couche de sécurité supplémentaire aux comptes d’utilisateur.
Intégration de Microsoft Entra ID pour gérer les identités utilisateur et l’accès à l’entrepôt.

Autorisations d’espace de travail

Les données dans Fabric sont organisées en espaces de travail qui permettent de contrôler l’accès et de gérer le cycle de vie des données et des services. L’attribution de rôles d’espace de travail appropriés constitue la première ligne de défense pour sécuriser votre entrepôt de données.

En plus des rôles d’espace de travail, vous pouvez accorder des autorisations d’élément et l’accès via SQL.

Conseil

Pour plus d’informations sur les rôles d’espace de travail, consultez Espaces de travail dans Power BI.

Autorisations d’élément

Contrairement aux rôles d’espace de travail qui s’appliquent à tous les éléments d’un espace de travail, vous pouvez utiliser des autorisations d’élément pour accorder l’accès à des entrepôts individuels. Cela vous permet de partager un entrepôt de données unique pour la consommation en aval.

Vous pouvez accorder des autorisations aux utilisateurs en T-SQL ou dans le portail Fabric. Accordez les autorisations suivantes aux utilisateurs qui doivent accéder à votre entrepôt de données :

Read : permet à l’utilisateur de se connecter en utilisant la chaîne de connexion SQL.
ReadData : permet à l’utilisateur de lire les données de n’importe quelle table/vue de l’entrepôt.
ReadAll : permet à l’utilisateur de lire les données des fichiers parquet bruts dans OneLake qui peuvent être consommés par Spark.

Une connexion utilisateur au point de terminaison d’analytique SQL échoue si elle ne dispose pas au minimum de l’autorisation de lecture.

Surveillance

Le monitoring des activités dans votre entrepôt de données est essentiel pour garantir des performances optimales, une utilisation efficace des ressources et la sécurité. Le monitoring vous aide à identifier les problèmes, à détecter les anomalies et à prendre les mesures nécessaires pour assurer le bon fonctionnement et la sécurité de l’entrepôt de données.

Vous pouvez utiliser des vues de gestion dynamique (DMV) pour monitorer l’état des connexions, des sessions et des demandes afin d’obtenir des insights sur le cycle de vie des requêtes SQL en direct. Les DMV vous permettent d’obtenir des détails tels que le nombre de requêtes actives et d’identifier les requêtes qui s’exécutent pendant une longue période et qui doivent être arrêtées.

Trois DMV sont actuellement disponibles dans Fabric :

sys.dm_exec_connections : retourne des informations sur chaque connexion établie entre l’entrepôt et le moteur.
sys.dm_exec_sessions : retourne des informations sur chaque session authentifiée entre l’élément et le moteur.
sys.dm_exec_requests : retourne des informations sur chaque demande active dans une session.

Monitoring des requêtes

Utilisez « sys.dm_exec_requests » pour identifier les requêtes longues susceptibles d’avoir un impact sur les performances globales de la base de données, et prenez les mesures appropriées pour optimiser ou arrêter ces requêtes.

Commencez par identifier les requêtes qui s’exécutent depuis longtemps. Utilisez la requête suivante pour identifier les requêtes exécutées le plus longtemps, par ordre décroissant :

    SELECT request_id, session_id, start_time, total_elapsed_time
    FROM sys.dm_exec_requests
    WHERE status = 'running'
    ORDER BY total_elapsed_time DESC;

Vous pouvez poursuivre l’investigation pour identifier l’utilisateur qui a exécuté la session avec la requête longue. Pour cela, exécutez :

    SELECT login_name
    FROM sys.dm_exec_sessions
    WHERE 'session_id' = 'SESSION_ID WITH LONG-RUNNING QUERY';

Enfin, vous pouvez utiliser la commande KILL pour arrêter la session avec la requête longue :

    KILL 'SESSION_ID WITH LONG-RUNNING QUERY';

Important