Audit pour la base de données SQL dans Fabric

S’applique à :✅Base de données SQL dans Microsoft Fabric

L’audit des bases de données SQL dans Fabric est une fonctionnalité de sécurité et de conformité critique qui permet aux organisations de suivre et de journaliser les activités de base de données. L’audit prend en charge la conformité, la détection des menaces et les enquêtes judiciaires en aidant à répondre à des questions telles que les personnes ayant accédé aux données, quand et comment.

Qu’est-ce que l’audit SQL ?

L’audit SQL fait référence au processus de capture et de stockage d’événements liés à l’activité de base de données. Ces événements incluent l’accès aux données, les modifications de schéma, les modifications d’autorisation et les tentatives d’authentification.

Dans Fabric, l’audit fonctionne au niveau de la base de données et prend en charge :

Surveillance de la conformité (par exemple : HIPAA, SOX)
Enquêtes de sécurité
Insights opérationnels

Cible d’audit

Les journaux d’audit sont écrits dans un dossier en lecture seule dans OneLake et peuvent être interrogés à l’aide de la sys.fn_get_audit_file_v2 fonction T-SQL ou de l’Explorateur OneLake.

Pour la base de données SQL dans Fabric, les journaux d’audit sont stockés dans OneLake : https://onelake.blob.fabric.microsoft.com/{workspace_id}/{artifact_id}/Audit/sqldbauditlogs/

Ces journaux sont immuables et accessibles aux utilisateurs disposant des autorisations appropriées. Les journaux peuvent également être téléchargés à l’aide de l’Explorateur OneLake ou de l’Explorateur Stockage Azure.

Facturation

Actuellement, l’écriture des journaux d’audit dans Fabric OneLake n’entraîne pas de frais supplémentaires et le stockage est inclus dans les limites de stockage OneLake de la capacité.

Options de configuration

Par défaut, l’option Auditer tout capture tous les événements, y compris les achèvements de lots et l’authentification réussie et ayant échoué.

Pour être plus sélectif, choisissez parmi les scénarios d’audit préconfigurés, par exemple : Modifications d’autorisation et tentatives de connexion, lectures de données et écritures et/ou modifications de schéma.

Chaque scénario préconfiguré correspond à des groupes d’actions d’audit spécifiques (par exemple, SCHEMA_OBJECT_ACCESS_GROUP, DATABASE_PRINCIPAL_CHANGE_GROUP). Vous pouvez également choisir les événements à auditer sous Événements personnalisés. Vous pouvez sélectionner des groupes d’actions individuels pour adapter l’audit à vos besoins. Cette option est idéale pour les organisations avec des stratégies de sécurité internes strictes.

Pour filtrer les requêtes d’accès courantes ou connues, vous pouvez fournir des expressions de prédicat dans Transact-SQL (T-SQL) pour filtrer les événements d’audit en fonction de conditions (par exemple, pour exclure des instructions SELECT) : WHERE statement NOT LIKE '%select%'.

Permissions

Pour gérer l’audit à l’aide de rôles d’espace de travail Fabric (recommandé), vous devez disposer d’une appartenance au rôle Contributeur d’espace de travail Fabric ou à des autorisations supérieures.

Pour gérer l’audit avec les autorisations SQL :

Pour configurer l’audit de base de données, vous devez disposer de l’autorisation ALTER ANY DATABASE AUDIT.
Pour afficher les journaux d’audit à l’aide de T-SQL, vous devez disposer de l’autorisation VIEW DATABASE SECURITY AUDIT.

Retention

Par défaut, les données d’audit sont conservées indéfiniment, sauf si vous configurez une période de rétention personnalisée pour supprimer automatiquement les journaux après cette durée.

Fabric stocke actuellement les journaux d’audit dans le dossier de l’élément dans OneLake et les étend au cycle de vie de l’élément. Si vous supprimez l’élément, Fabric supprime également ses journaux d’audit. Si vous avez besoin d’une rétention indépendante du cycle de vie de l’élément, déplacez les journaux d’audit vers un emplacement de stockage distinct (par exemple, un autre compte Lakehouse ou un compte de stockage Azure) à l’aide d’outils tels que AzCopy ou SSDT.

Rétention des paramètres après la restauration

Après une opération de restauration, les paramètres d’audit sont conservés, mais l’audit doit être réactivé dans Fabric BASE de données SQL. Dans le portail Fabric, ouvrez Gérer l’audit SQL, sélectionnez Enregistrer.

Configurer l’audit pour la base de données SQL à partir du portail Fabric

Pour commencer l’audit pour une base de données SQL Fabric :

Accédez à votre base de données SQL dans le portail Fabric et ouvrez-la.
Dans le menu principal, sélectionnez l’onglet Sécurité , puis sélectionnez Gérer l’audit SQL.
Le volet Gérer l’audit SQL s’ouvre.
Sélectionnez le bouton Enregistrer des événements dans les journaux d’audit SQL pour activer l’audit.
Configurez les événements à enregistrer dans la section Événements de base de données . Choisissez Auditer tout (par défaut) pour capturer tous les événements.
Si vous le souhaitez, configurez une stratégie de rétention sous Rétention.
Si vous le souhaitez, configurez une expression de prédicat des commandes T-SQL à ignorer dans le champ Expression de prédicat .
Cliquez sur Enregistrer.

Interroger les journaux d’audit

Les journaux d’audit peuvent être interrogés à l’aide des fonctions T-SQL sys.fn_get_audit_file et sys.fn_get_audit_file_v2.

Dans le script suivant, vous devez fournir l’ID d’espace de travail et l’ID de base de données. Les deux peuvent être trouvés dans l’URL du portail Fabric. Par exemple : https://fabric.microsoft.com/groups/<fabric workspace id>/sqldatabases/<fabric sql database id>. La première chaîne d’identifiants unique dans l’URL est l’ID de l’espace de travail Fabric, et la deuxième chaîne d’identifiants unique est l’ID de la base de données SQL.

Remplacez <fabric_workspace_id> par votre ID d’espace de travail Fabric. Vous trouverez l’ID d’un espace de travail dans l’URL, il s’agit de la chaîne unique à l’intérieur de deux / caractères après /groups/ la fenêtre de votre navigateur.
Remplacez <fabric sql database id> par votre base de données SQL dans l’ID de base de données Fabric. Vous trouverez l’ID de l’élément de base de données dans l’URL, il s’agit de la chaîne unique à l’intérieur de deux / caractères après /sqldatabases/ la fenêtre de votre navigateur.

Par exemple:

SELECT * FROM sys.fn_get_audit_file_v2(
  'https://onelake.blob.fabric.microsoft.com/<fabric workspace id>/<fabric sql database id>/Audit/sqldbauditlogs/',
  DEFAULT, DEFAULT, DEFAULT, DEFAULT );

Cet exemple récupère les journaux d’audit entre 2025-11-17T08:40:40Z et 2025-11-17T09:10:40Z.

SELECT *
FROM sys.fn_get_audit_file_v2(
    'https://onelake.blob.fabric.microsoft.com/<fabric workspace id>/<fabric sql database id>/Audit/sqldbauditlogs/',
    DEFAULT,
    DEFAULT,
    '2025-11-17T08:40:40Z',
    '2025-11-17T09:10:40Z')

Pour plus d’informations, consultez sys.fn_get_audit_file et sys.fn_get_audit_file_v2.

Gérer l’audit avec l’API REST

Vous pouvez également afficher et configurer des paramètres d’audit de base de données SQL par programmation à l’aide de l’API REST Fabric. L’API REST vous permet de gérer l’audit de manière cohérente sur toutes les bases de données d’un espace de travail à l’aide de scripts PowerShell.

Pour plus d’informations, consultez Gérer l’audit de base de données SQL avec l’API REST.

Protéger les informations sensibles dans les journaux d’audit

Lorsque vous construisez du SQL dynamique en concaténant directement les valeurs d’entrée dans l’instruction SQL, ces valeurs deviennent partie intégrante du texte de l’affirmation. Si vous auditez le relevé, le journal d’audit peut capturer des informations sensibles incluses dans le texte du relevé.

Pour réduire le risque d’exposition d’informations sensibles, suivez ces pratiques :

Évitez le SQL dynamique pour les opérations contenant des valeurs sensibles

Pour les opérations administratives sensibles à la sécurité, évitez de construire des instructions en concaténant des valeurs sensibles dans un SQL dynamique. Lorsque possible, utilisez des instructions SQL natives ou d’autres approches qui empêchent les valeurs sensibles d’être intégrées directement dans le texte de l’énoncé.

Les instructions SQL dynamiques construites à partir de chaînes accessibles par l’utilisateur rendent également vos applications vulnérables aux attaques d’injection SQL. L’injection SQL est une attaque dans laquelle un code malveillant est inséré dans des chaînes de caractères qui sont ensuite transmises à la base de données pour analyse et exécution. Vous devez tester toute procédure qui construit T-SQL pour les vulnérabilités d’injection SQL, car le moteur de base de données exécute toutes les requêtes syntaxiquement valides qu’il reçoit. Utilisez des paramètres pour les valeurs des données, et ne concaténez jamais les valeurs des paramètres dans le texte de requête. Les valeurs correctement paramétrées sont traitées comme des données plutôt que comme une syntaxe SQL exécutable.
Restreindre l’accès aux journaux d’audit

Limitez l’accès aux journaux d’audit aux utilisateurs autorisés et aux administrateurs. Au sein du SQL Moteur de base de données, les permissions SQL régissent l’accès à l’audit au sein du SQL Moteur de base de données et peuvent varier selon la plateforme et le périmètre d’audit. Suivez le principe du moindre privilège et n’accordez que les autorisations nécessaires à la gestion ou à la consultation des informations d’audit. Il existe des modèles d’autorisations d’audit distincts au niveau serveur et au niveau de la base de données, et Azure SQL Database diffère de SQL Server par la disponibilité des autorisations au niveau serveur. Restreindre l’accès aux données d’audit aide à réduire le risque de divulgation non autorisée lorsque des informations sensibles sont présentes lors d’événements d’audit enregistrés.

L’accès aux journaux d’audit en dehors du SQL Moteur de base de données dépend des autorisations dans la destination configurée (comme OneLake). Suivez le principe du moindre privilège et n’accordez que les autorisations nécessaires à la gestion ou à la consultation des informations d’audit.

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2026-09-17