Exercice – Classification de données, masquage dynamique des données et audit SQL

Effectué

Dans cet exercice, vous allez combiner vos apprentissages du module pour parcourir un scénario. Vous allez apprendre à ajouter des classifications de données et des masques de données dynamiques, puis vous allez découvrir différentes méthodes d’audit des utilisateurs tentant de visualiser les colonnes marquées pour la classification des données. Cet exercice associe plusieurs des concepts que vous avez déjà découverts dans le module sur la gestion de la sécurité.

Configurer la classification et le masquage des données

1. Dans le portail Azure, accédez à votre instance Azure SQL Database (pas au serveur logique).

   Portail Azure

2. Dans le menu gauche, sous Sécurité, sélectionnez Découverte et classification des données.

3. Sélectionnez l’onglet Classification, puis Ajouter une classification.

   

   Lors d’un exercice précédent, vous avez ajouté toutes les classifications de colonnes recommandées. Dans cette étape, vous ajoutez manuellement une colonne potentiellement sensible à la liste des colonnes classifiées.

4. Dans la table Clients SalesLT, le service Découverte et classification des données a identifié que FirstName et LastName devaient être classifiés, mais pas MiddleName. Utilisez les listes déroulantes pour l’ajouter maintenant, puis sélectionnez Ajouter une classification.

   

5. Cliquez sur Enregistrer.

6. Vérifiez que la classification est correctement ajoutée en affichant l’onglet Vue d’ensemble pour vous assurer que MiddleName figure maintenant dans la liste des colonnes classifiées du schéma SalesLT.

7. Dans le volet gauche, sélectionnez Vue d’ensemble pour revenir à la vue d’ensemble de votre base de données.

   Dynamic Data Masking (DDM) est disponible à la fois dans Azure SQL et SQL Server. DDM limite l’exposition des données en masquant les données sensibles aux utilisateurs non privilégiés au niveau de SQL Server plutôt qu’au niveau de l’application, où vous devez coder ces types de règles. Azure SQL vous recommande des éléments à masquer. Vous pouvez également ajouter des masques manuellement.

   Dans les étapes suivantes, vous allez masquer les colonnes FirstName, MiddleName et LastName que vous avez révisées à l’étape précédente.

8. Dans le portail Azure, accédez à votre instance Azure SQL Database. Dans le volet gauche, sous Sécurité, sélectionnez Dynamic Data Masking, puis Ajouter un masque.

9. Dans les listes déroulantes, sélectionnez le schéma SalesLT, la table Customer et la colonne FirstName. Vous pouvez ensuite passer en revue les options de masquage, mais l’option par défaut convient pour ce scénario. Sélectionnez Ajouter pour ajouter la règle de masquage.

   

10. Répétez l’étape précédente pour les colonnes MiddleName et LastName dans cette table.

    Vous avez maintenant trois règles de masquage similaires à celles illustrées ici :

    

11. Cliquez sur Enregistrer.

12. Dans le volet gauche, sélectionnez Vue d’ensemble pour revenir à la vue d’ensemble de votre base de données.

Récupérer des données classifiées et masquées

Vous simulez ensuite une personne interrogeant les colonnes classifiées et découvrant Dynamic Data Masking en action.

1. Accédez à SQL Server Management Studio (SSMS).

2. Si vous souhaitez créer une requête dans votre base de données AdventureWorks, cliquez avec le bouton droit sur la base de données, puis sélectionnez Nouvelle requête.

3. Lancez la requête suivante pour obtenir les données classifiées (et, dans certains cas, des colonnes marquées pour des données masquées). Sélectionnez Exécuter pour exécuter la requête.

   SELECT TOP 10 FirstName, MiddleName, LastName
   FROM SalesLT.Customer;
   

   Votre résultat doit présenter les 10 premiers noms, sans aucun masquage appliqué. Pourquoi ? Parce que vous êtes l’administrateur de ce serveur logique Azure SQL Database.

   

4. Dans la requête suivante, vous créez un utilisateur et exécutez la requête précédente en tant que cet utilisateur. Vous allez également utiliser EXECUTE AS pour emprunter l’identité de Bob. Lors de l’exécution d’une instruction EXECUTE AS, le contexte d’exécution de la session bascule vers la connexion ou l’utilisateur. Cela signifie que les autorisations sont vérifiées par rapport à la connexion ou l’utilisateur plutôt que par rapport à la personne exécutant la commande EXECUTE AS (en l’occurrence, vous). REVERT est ensuite utilisé pour arrêter l’emprunt d’identité de la connexion ou de l’utilisateur.

   Vous reconnaîtrez peut-être les premières parties des commandes qui suivent, car elles sont une répétition d’un exercice précédent. Créez une requête avec les commandes suivantes, puis sélectionnez Exécuter pour exécuter la requête, enfin observez les résultats.

   -- Create a new SQL user and give them a password
   CREATE USER Bob WITH PASSWORD = 'c0mpl3xPassword!';
   
   -- Until you run the following two lines, Bob has no access to read or write data
   ALTER ROLE db_datareader ADD MEMBER Bob;
   ALTER ROLE db_datawriter ADD MEMBER Bob;
   
   -- Execute as our new, low-privilege user, Bob
   EXECUTE AS USER = 'Bob';
   SELECT TOP 10 FirstName, MiddleName, LastName
   FROM SalesLT.Customer;
   REVERT;
   

   Le résultat doit maintenant présenter les 10 premiers noms, mais avec le masquage appliqué. Bob n’a pas été autorisé à accéder à la forme non masquée de ces données.

   

   Que se passe-t-il si, pour une raison quelconque, Bob a besoin d’accéder aux noms et y est autorisé ?

   Vous pouvez mettre à jour les utilisateurs exclus du masquage dans le portail Azure en accédant au volet Masquage dynamique des données, sous Sécurité, ainsi qu’en utilisant T-SQL.

5. Cliquez avec le bouton droit sur la base de données AdventureWorks et sélectionnez Nouvelle requête, puis entrez la requête suivante pour permettre à Bob d’interroger les résultats de noms sans masquage. Sélectionnez Exécuter pour exécuter la requête.

   GRANT UNMASK TO Bob;  
   EXECUTE AS USER = 'Bob';
   SELECT TOP 10 FirstName, MiddleName, LastName
   FROM SalesLT.Customer;
   REVERT;  
   

   Vos résultats devraient inclure les noms en entier.

   

6. Vous pouvez également retirer à un utilisateur ses privilèges de démasquage et confirmer cette action en exécutant les commandes T-SQL suivantes dans une nouvelle requête :

   -- Remove unmasking privilege
   REVOKE UNMASK TO Bob;  
   
   -- Execute as Bob
   EXECUTE AS USER = 'Bob';
   SELECT TOP 10 FirstName, MiddleName, LastName
   FROM SalesLT.Customer;
   REVERT;  
   

   Vos résultats devraient inclure les noms masqués.

   

Examiner les journaux d’audit dans SSMS

En tant qu’administrateur, vous pouvez avez avoir besoin d’examiner et de vérifier qui accède aux bases de données, plus particulièrement, aux données classifiées. Ensuite, vous pouvez examiner les fichiers d’audit envoyés au Stockage Blob Azure. La première chose à faire est de fusionner les fichiers d’audit, si les journaux s’étendent sur plusieurs fichiers. Vous pouvez effectuer cette opération à partir de SSMS en procédant comme suit :

1. Sélectionnez Fichier>Ouvrir>Fusionner les fichiers d’audit.

   

2. Sélectionnez Ajouter.

   

3. Sélectionnez Ajouter à partir du stockage blob Azure, puis Se connecter.

   

4. Connectez-vous à Azure avec le compte que vous utilisez pour ce module.

   

5. Sélectionnez l’abonnement, le compte de stockage et le conteneur d’objets blob que vous avez configurés pour l’envoi des journaux d’audit. Le nom du compte de stockage doit commencer par sql. Le conteneur sera appelé sqldbauditlogs. Si aucun conteneur ne porte ce nom, vous avez créé un compte de stockage différent pour l’audit ; utilisez ce compte à la place.

6. Sélectionnez votre serveur logique Azure SQL Database et votre base de données AdventureWorks. Assurez-vous que l’heure de début est antérieure à l’heure à laquelle vous avez commencé les exercices. Sélectionnez OK.

7. La fenêtre de confirmation vous permet de savoir combien de fichiers sont téléchargés et fusionnés. Sélectionnez OK.

8. Passez les fichiers en revue, puis sélectionnez OK une dernière fois.

   Tous les journaux d’audit s’affichent désormais. Recherchez l’emplacement auquel vous testiez le masquage avec Bob. La liste doit se trouver dans la partie inférieure.

9. Sélectionnez l’instruction, puis passez en revue les informations dans le volet d’informations. Par exemple, pour l’une des requêtes où Bob tente d’afficher des données classifiées, sous le champ data_sensitivity_information, vous pouvez voir les données classifiées.

10. Double-cliquez sur la valeur de data_sensitivity_information sous l’onglet Détails. Une fenêtre contextuelle s’ouvre pour vous permettre de lire plus facilement les données.

    Voici un exemple de ce que vous pouvez voir sous data_sensitivity_information :

    <sensitivity_attributes max_rank="20" max_rank_desc="Medium"><sensitivity_attribute label="Confidential - GDPR" label_id="bf91e08c-f4f0-478a-b016-23422b2a65ff" information_type="Name" information_type_id="57845286-7598-22f5-3422-15b24aeb125e" rank="20" rank_desc="Medium"/></sensitivity_attributes>
    

    Vous pouvez ensuite exporter ce fichier fusionné vers un fichier XEL, un fichier CSV ou une table à des fins d’analyse supplémentaire. Vous pouvez également interroger les fichiers Événements étendus à l’aide d’Azure PowerShell.

Examiner les journaux d’audit dans le portail Azure

L’analyse de vos journaux d’audit dépend de votre préférence. Dans cette section, vous pouvez interroger les journaux de sécurité du portail Azure avec Log Analytics.

1. Dans le portail Azure, accédez à votre base de données AdventureWorks. Dans le volet gauche, sous Sécurité, sélectionnez Audit, puis le bouton Afficher les journaux d’audit dans la barre des tâches.

   Vous devez maintenant être en mesure de voir une requête de vos enregistrements d’événements, des options à exécuter dans l’Éditeur de requête (exécuter des requêtes T-SQL via le portail), des options pour Log Analytics, la vue Tableau de bord, et bien plus encore.

   

   N’hésitez pas à chercher à comprendre certaines des options proposées.

2. Sélectionnez Log Analytics. Il est possible que vous deviez sélectionner Actualiser pour accéder au bouton Log Analytics. Si vous voyez s’afficher un écran Prise en main, sélectionnez OK. Vous accédez à un éditeur de requête, mais ce n’est pas un éditeur T-SQL. Dans cette vue, vous pouvez interroger les journaux à l’aide du langage de requête Kusto (KQL), conçu pour être facilement utilisé et compris par les professionnels SQL.

   La requête par défaut interroge la catégorie SQLSecurityAuditEvents. Même si vous pouvez utiliser cette catégorie maintenant pour visualiser des incidents liés à la sécurité, cet outil vous permet aussi d’interroger d’autres journaux et catégories Azure dans Log Analytics. Pour cette étape, vous pouvez rechercher les instructions dans lesquelles Bob a essayé d’accéder à des informations sensibles. Pour obtenir les mêmes informations que celles que vous avez vues dans SSMS, développez les détails de ligne en sélectionnant le bouton >.

   L’affichage des résultats peut prendre quelques minutes. Vous pouvez actualiser la requête en sélectionnant de nouveau Exécuter.

   Dans cette activité, vous n’allez pas approfondir l’exécution de requêtes KQL sur les journaux, mais de nombreuses ressources sont disponibles dans les références antérieures si vous souhaitez vous exercer ultérieurement.

   Dans l’étape suivante, vous allez voir comment la sécurité SQL a construit un tableau de bord basé sur Log Analytics pour vous permettre de superviser et d’auditer les journaux et d’autres activités SQL. Pour revenir au volet Enregistrements d’audit, fermez la fenêtre de requête Log Analytics en sélectionnant X en haut à droite.

3. Sélectionnez Afficher le tableau de bord.

   

   Un tableau de bord de vue d’ensemble s’affiche.

4. Sélectionnez Azure SQL – Accès aux données sensibles pour afficher d’autres détails.

   Vous devrez peut-être attendre entre trois et cinq minutes, puis sélectionner Actualiser pour que les éléments apparaissent ici.

   Vous pouvez utiliser ces informations détaillées pour découvrir ceci :

   • Le nombre de requêtes qui accèdent à des données sensibles.
   • Les types et sensibilités de données auxquelles elles accèdent.
   • Les principaux qui accèdent aux données sensibles.
   • Les adresses IP qui accèdent aux données sensibles.

   Examinez ce qui est disponible ici, et comment vérifier l’utilisation avec cet outil. Vous pouvez même sélectionner chacun de ces éléments pour consulter les journaux associés dans Log Analytics.

5. Quand vous avez terminé, fermez le volet Azure SQL – Accès aux données sensibles en sélectionnant X en haut à droite.

6. De retour dans le volet de vue d’ensemble du tableau de bord d’audit, sélectionnez Azure SQL - Insights sur la sécurité.

   Ce tableau de bord présente des informations d’audit supplémentaires pour vous aider à comprendre l’activité de la base de données et à mieux cerner les anomalies. Prenez quelques minutes pour examiner et explorer les options proposées ici.

En plus de ces informations sur les services Azure SQL, le fait d’être dans Azure vous permet d’utiliser Microsoft Defender pour le cloud pour surveiller, gérer et résoudre les problèmes qui surviennent dans l’ensemble de votre patrimoine Azure. Si vous souhaitez voir ce qui est disponible en dehors de Defender pour le cloud Azure SQL, vous pouvez rechercher et sélectionner Microsoft Defender pour le cloud dans le portail Azure. Votre accès peut être limité, selon votre niveau d’abonnement.