Audit pour Azure SQL Database et Azure Synapse Analytics

S’applique à :Azure SQL Database Azure Synapse Analytics

L’audit pour Azure SQL Database et Azure Synapse Analytics suit les événements de base de données et les écrit dans un journal d’audit dans votre compte de stockage Azure, votre espace de travail Log Analytics ou Event Hubs.

Par ailleurs, l’audit :

peut vous aider à respecter une conformité réglementaire, à comprendre l’activité de la base de données ainsi qu’à découvrir des discordances et anomalies susceptibles d’indiquer des problèmes pour l’entreprise ou des violations de la sécurité ;
permet et facilite le respect de normes de conformité, même s’il ne garantit pas cette conformité. Pour en savoir plus, accédez au Centre de confidentialité Microsoft Azure, qui inclut la liste la plus à jour des certifications de conformité de SQL Database.

Remarque

Pour plus d’informations sur l’audit Azure SQL Managed Instance, consultez l’article suivant Bien démarrer avec l’audit Azure SQL Managed Instance.

Vue d’ensemble

Vous pouvez utiliser l’audit SQL Database pour :

Conservez une piste d’audit d’événements sélectionnés. Vous pouvez définir les catégories des actions de base de données à auditer.
La génération de rapports sur les activités de la base de données. Vous pouvez utiliser des rapports préconfigurés et un tableau de bord pour une prise en main rapide de la génération de rapports d’activités et d’événements.
L'analyse des rapports. Vous pouvez repérer les événements suspects, les activités inhabituelles et les tendances.

Importante

L’audit pour Azure SQL Database, les pools SQL Azure Synapse Analytics et Azure SQL Managed Instance est optimisé pour la disponibilité et les performances de la base de données ou de l’instance faisant l’objet de l’audit. Pendant les périodes d’activité très élevée ou de charge réseau élevée, la fonctionnalité d’audit peut permettre la poursuite des transactions sans enregistrer tous les événements marqués pour l’audit.

Améliorations apportées aux performances, à la disponibilité et à la fiabilité de l’audit des serveurs pour Azure SQL Database (disponibilité générale prévue en juillet 2025)

Les principales parties de l’audit SQL réécrites, ce qui a entraîné une disponibilité et une fiabilité accrues des audits de serveur. En guise d’avantage supplémentaire, il existe un alignement plus étroit des fonctionnalités avec SQL Server et Azure SQL Managed Instance. L’audit de base de données reste inchangé.
La conception précédente de l’audit déclenche un audit au niveau de la base de données et exécute une session d’audit pour chaque base de données du serveur. La nouvelle architecture d’audit crée une session d’événements étendue au niveau du serveur qui capture les événements d’audit pour toutes les bases de données.
La nouvelle conception d’audit optimise la mémoire et le processeur et est cohérente avec le fonctionnement de l’audit dans SQL Server et Azure SQL Managed Instance.

Modifications de la ré-architecture de l’audit du serveur

Modification de la structure des dossiers pour le compte de stockage :
- L’une des principales modifications implique une modification de structure de dossiers pour les journaux d’audit stockés dans des conteneurs de compte de stockage. Auparavant, les journaux d’audit du serveur étaient écrits dans des dossiers distincts ; un pour chaque base de données, avec le nom de la base de données servant de nom de dossier. Avec la nouvelle mise à jour, tous les journaux d’audit du serveur seront consolidés masterdans un dossier unique étiqueté . Ce comportement est le même qu’Azure SQL Managed Instance et SQL Server.
Modification de l'arborescence des dossiers pour les copies en lecture seule :
- Les répliques de base de données en lecture seule avaient jusqu'à présent leurs journaux stockés dans un dossier en lecture seule. Ces journaux seront désormais écrits dans le dossier master. Vous pouvez récupérer ces journaux en filtrant sur la nouvelle colonne is_secondary_replica_true.
Autorisations requises pour afficher les journaux d’audit :
- VIEW DATABASE SECURITY AUDIT permission dans la base de données des utilisateurs

Limitations de l’audit

L’activation de l’audit sur un pool SQL Azure Synapse interrompu n’est pas possible. Pour activer l’audit, relancez le pool SQL Synapse.
L’activation de l’audit à l’aide de l’identité managée affectée par l’utilisateur (UAMI) n’est pas prise en charge sur Azure Synapse.
Actuellement, les identités managées ne sont pas prises en charge pour Azure Synapse, sauf si le compte de stockage se trouve derrière un réseau virtuel ou un pare-feu.
En raison de contraintes de performances, nous n’auditons pas les tempdb et les tables temporaires . Bien que le groupe d’actions terminées par lots capture des instructions sur des tables temporaires, il se peut qu’il ne remplisse pas correctement les noms d’objets. Toutefois, la table source est toujours auditée, ce qui garantit que toutes les insertions de la table source vers des tables temporaires sont enregistrées.
L’audit pour les pools Azure Synapse SQL prend en charge les groupes d’actions d’audit par défaut uniquement.
Lorsque vous configurez l’audit pour un serveur logique dans Azure ou Azure SQL Database avec la destination du journal en tant que compte de stockage, le mode d’authentification doit correspondre à la configuration de ce compte de stockage. Si vous utilisez des clés d’accès de stockage comme type d’authentification, le compte de stockage cible doit être activé avec l’accès aux clés du compte de stockage. Si le compte de stockage est configuré pour utiliser uniquement l’authentification avec Microsoft Entra ID (anciennement Azure Active Directory), l’audit peut être configuré pour utiliser des identités managées pour l’authentification.
L’audit n’est pas pris en charge sur les bases de données avec des noms qui contiennent le ? caractère. Cela s’applique à l’audit au niveau du serveur et au niveau de la base de données , car les bases de données avec ? leurs noms ne sont plus prises en charge sur Azure.
Les journaux d’audit Azure SQL Database et Azure Synapse enregistrent jusqu’à 4 000 caractères dans les statement et data_sensitivity_information. Si la sortie d’une action auditable dépasse cette limite, tout contenu au-delà des 4 000 premiers caractères est tronqué et exclu de l’enregistrement d’audit.

Remarques

Le Stockage Premium avec BlockBlobStorage est supporté. Le stockage standard est pris en charge. Toutefois, pour que l’audit écrive dans un compte de stockage derrière un réseau virtuel ou un pare-feu, vous devez disposer d’un compte de stockage universel v2. Si vous disposez d’un compte v1 universel ou Stockage Blob, procédez à une mise à niveau vers un compte de stockage v2 universel. Pour obtenir des instructions spécifiques, consultez Écrire un audit dans un compte de stockage situé derrière un réseau virtuel ou un pare-feu. Pour plus d’informations, consultez Types de comptes de stockage.
L’espace de noms hiérarchique est pris en charge pour tous les types de comptes de stockage Standard et comptes de stockage Premium avec BlockBlobStorage.
Les journaux d’audit sont écrits dans des objets blob d’ajout d’un Stockage Blob Azure de votre abonnement Azure.
Les journaux d’audit sont au format .xel et peuvent être ouverts avec SQL Server Management Studio (SSMS).
Pour configurer un magasin de journaux immuable pour les événements d’audit au niveau du serveur ou de la base de données, suivez les instructions fournies par Azure Storage. Lorsque vous configurez le stockage blob immuable pour l’audit, assurez-vous que l’option Autoriser les ajouts protégés est définie sur Ajouter des blobs ou Bloquer et ajouter des blobs. L’option Aucun n’est pas prise en charge. Pour les stratégies de rétention basées sur le temps, l’intervalle de rétention du compte de stockage doit être plus court que le paramètre de rétention de l’audit SQL. Les configurations dans lesquelles la stratégie de stockage est définie, mais la conservation de l’audit SQL est 0, ne sont pas prises en charge.
Vous pouvez écrire des journaux d’audit dans un compte de Stockage Azure derrière un réseau virtuel ou un pare-feu.
Pour plus de détails sur le format du journal, la hiérarchie du dossier de stockage et les conventions d’affectation de noms, voir l'article, Format du journal d'audit SQL Database.
L'audit de Utiliser des répliques en lecture seule pour décharger les charges de travail des requêtes en lecture seule est automatiquement activé. Pour plus d’informations sur la hiérarchie des dossiers de stockage, les convention d’affectation de noms et le format des journaux, voir l'article, Format du journal d'audit de SQL Database.
Lors de l’utilisation de l’authentification Microsoft Entra, les enregistrements d’échecs de connexion n’apparaissent pas dans le journal d’audit SQL. Pour consulter les enregistrements d’audit des tentatives de connexion échouées, il vous faut vous rendre au centre d'administration Microsoft Entra, qui consigne les détails de ces événements.
Les connexions sont acheminées par la passerelle vers l’instance spécifique où se trouve la base de données. Avec les connexions Microsoft Entra, les informations d’identification sont vérifiées avant une tentative d’utilisation de cet utilisateur pour se connecter à la base de données demandée. En cas d’échec, la base de données demandée n’est jamais accessible, de sorte qu’aucun audit n’est effectué. Avec les connexions SQL, les informations d’identification étant vérifiées sur les données demandées, elles peuvent dans ce cas être auditées. Les connexions réussies, qui ont manifestement atteint la base de données, sont auditées dans les deux cas.
Une fois que vous avez configuré vos paramètres d’audit, vous pouvez activer la nouvelle fonctionnalité de détection des menaces et configurer les adresses e-mail de réception des alertes de sécurité. La détection des menaces vous permet de recevoir des alertes proactives sur des activités anormales de la base de données qui peuvent indiquer des menaces de sécurité potentielles. Pour plus d’informations, consultez SQL Advanced Threat Protection.
Lorsqu’une base de données avec l’audit activé est copiée sur un autre serveur logique, vous pourriez recevoir un e-mail vous informant que l’audit a échoué. Il s’agit d’un problème connu et l’audit doit fonctionner comme prévu sur la base de données qui vient d’être copiée.

Rétroaction

Cette page vous a-t-elle été utile ?

Last updated on 2025-11-24