Audit dans Azure Synapse Analytics

Tip

Microsoft Fabric Data Warehouse est un entrepôt relationnel à l’échelle de l’entreprise sur une base de lac de données, avec une architecture future, une IA intégrée et de nouvelles fonctionnalités. Si vous débutez avec l'entreposage de données, commencez par Fabric Data Warehouse. Les charges de travail de pool SQL existantes dédicées peuvent être mises à niveau vers Fabric pour accéder à de nouvelles fonctionnalités dans la science des données, l’analytique en temps réel et la création de rapports.

L’audit d’Azure Synapse Analytics suit les événements de la base de données et les écrit sur stockage Azure, un espace de travail Azure Monitor Log Analytics ou Azure Event Hubs.

L’audit vous aide à :

  • Conserver une piste d’audit des événements sélectionnés.
  • Comprendre l’activité des bases de données et enquêter sur les écarts ou anomalies.
  • Faites un rapport sur l’activité en utilisant des requêtes, des classeurs et des outils de surveillance en aval.
  • Soutenir les exigences réglementaires et organisationnelles en matière de conformité. L’audit ne garantit pas la conformité en soi.

Overview

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.

Important

L’auditisation est optimisée pour la disponibilité et la performance du pool SQL. Lors de périodes d’activité très élevée ou de charge réseau, les transactions peuvent se dérouler sans que chaque événement sélectionné ne soit enregistré.

Pour les environnements avec de nombreuses bases de données exécutant des charges de travail OLTP lourdes, l’utilisation de l’audit au niveau du serveur avec les paramètres par défaut peut entraîner des volumes d’audit très volumineux sur le serveur logique. Étant donné que tous les événements de toutes les bases de données sont écrits dans le même dossier d’audit, l’interrogation des journaux d’audit d’une base de données unique devient lente et opérationnellement coûteuse. Pour améliorer les performances et réduire le bruit :

  • Basculez vers l’audit au niveau de la base de données. Chaque base de données écrit dans son propre dossier de journal d’audit, ce qui réduit le volume total analysé et accélère la récupération.
  • Passez en revue la configuration d’audit. Déterminez si la capture de tous les événements terminés par lots est nécessaire ou si une configuration filtrée personnalisée peut répondre à vos exigences de sécurité et de conformité.

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

Le texte de l’instruction journalisée peut contenir des valeurs sensibles lorsque les applications concaténent ces valeurs en SQL dynamique. Utilisez des paramètres pour les valeurs des données, évitez d’intégrer des secrets ou des données personnelles dans le texte de requête, et restreignez l’accès aux journaux d’audit aux utilisateurs autorisés.

Les permissions sur la destination d’audit contrôlent l’accès en dehors du moteur SQL. Appliquez le minimum de privilège à stockage Azure, Log Analytics et Event Hubs, et surveillez l’accès à ces ressources.

Limitations

  • Vous ne pouvez pas activer l’audit sur un pool SQL dédié en pause. Reprenez le pool avant d’activer la stratégie.
  • Les identités managées attribuées par les utilisateurs ne sont pas prises en charge pour l'audit dans Azure Synapse Analytics.
  • Une identité managée attribuée par le système est prise en charge pour une destination stockage Azure lorsque le compte de stockage est derrière un réseau virtuel ou un pare-feu. Les identités gérées ne sont pas prises en charge pour Azure Synapse sauf si le compte de stockage est derrière un réseau virtuel ou un pare-feu.
  • Les pools SQL Synapse ne prennent en charge que les groupes d’actions d’audit par défaut.
  • L'audit n'est pas supporté sur les bases de données dont le nom contient le caractère ?. Cette limitation s’applique aussi bien à l’audit au niveau serveurqu’au niveau de la base de données, car les bases de données avec ? dans leur nom ne sont plus prises en charge sur Azure.
  • Les enregistrements d’audit stockent jusqu’à 4 000 caractères dans les champs statement et data_sensitivity_information. Les caractères supplémentaires sont tronqués.

Remarks

  • Les événements initiés par SQLDBControlPlaneFirstPartyApp dans le journal d’activité sont une fonction de Azure interne du plan de contrôle Azure SQL Database. Les événements initiés par SQLDBControlPlaneFirstPartyApp font partie d’une opération de synchronisation interne entre le moteur SQL et Azure Resource Manager. Ces événements font normalement partie de la gestion Azure SQL Database et sont requis pour une représentation et une opération de ressources correctes dans Azure.
  • Le Stockage Premium avec BlockBlobStorage est supporté. Le stockage standard est pris en charge. Cependant, pour écrire des journaux d’audit sur un compte de stockage derrière un réseau virtuel ou un pare-feu, vous devez utiliser un compte de stockage v2 à usage général. Si vous utilisez un compte à usage général v1 ou un compte Stockage Blob, passez à un compte de stockage à usage général v2. Pour des instructions spécifiques, voir Écrire des journaux d’audit sur un compte de stockage derrière un réseau virtuel et un pare-feu. Pour plus d’informations, consultez Types de comptes de stockage.
  • Lorsque vous activez l’audit SQL et configurez les restrictions réseau sortant, vous devez ajouter à la liste d’autorisation les noms de domaine complets de votre compte de stockage d’audit afin de garantir que les événements d’audit atteignent la destination. Si vous n’ajoutez pas le point de terminaison de stockage à la liste d’autorisation, le trafic d’audit est bloqué, ce qui entraîne une perte d’événements d’audit. Après avoir ajouté les FQDN de comptes de stockage requis à la liste d’autorisations, vous devez sauvegarder à nouveau votre configuration d’audit pour reprendre le flux normal d’événements d’audit.
  • 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 dans un stockage Blob Azure sur 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 stockage Azure. 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 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 de nommage, voir le format du journal d’audit.
  • 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.
  • Après avoir configuré vos paramètres d’audit, vous pouvez activer la nouvelle fonction de détection de menaces et configurer les e-mails pour recevoir 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 Protection avancée contre les menaces.
  • 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é. Cette condition est un problème connu et l’audit devrait fonctionner comme prévu sur la base de données nouvellement copiée.

Contenu connexe

  • Dernière mise à jour :