Partager via

Que puis-je accomplir avec les stratégies DevOps Microsoft Purview ?

  • Article

Cet article explique comment gérer l’accès aux sources de données dans votre patrimoine de données à l’aide du portail de gouvernance Microsoft Purview. Il se concentre sur les concepts de base des stratégies DevOps. Autrement dit, il fournit des informations générales sur les stratégies DevOps que vous devez connaître avant de suivre d’autres articles pour obtenir les étapes de configuration.

Remarque

Cette fonctionnalité est différente du contrôle d’accès interne dans le portail de gouvernance Microsoft Purview.

L’accès aux métadonnées système est essentiel pour le personnel informatique et DevOps afin de s’assurer que les systèmes de base de données critiques sont sains, qu’ils correspondent aux attentes et qu’ils sont sécurisés. Vous pouvez accorder et révoquer cet accès efficacement et à grande échelle via des stratégies Microsoft Purview DevOps.

Tout utilisateur qui détient le rôle Auteur de stratégie au niveau de la collection racine dans Microsoft Purview peut créer, mettre à jour et supprimer des stratégies DevOps. Une fois les stratégies DevOps enregistrées, elles sont publiées automatiquement.

Stratégies d’accès et stratégies DevOps

Les stratégies d’accès Microsoft Purview permettent aux clients de gérer l’accès aux systèmes de données sur l’ensemble de leur patrimoine de données, le tout à partir d’un emplacement central dans le cloud. Vous pouvez considérer ces stratégies comme des octrois d’accès qui peuvent être créés via Microsoft Purview Studio, ce qui évite d’avoir besoin de code. Ils déterminent si une liste de principaux de Microsoft Entra, tels que des utilisateurs et des groupes, doit être autorisée ou refusée à un type spécifique d’accès à une source de données ou à une ressource qu’elle contient. Microsoft Purview communique ces stratégies aux sources de données, où elles sont appliquées en mode natif.

Les stratégies DevOps sont un type spécial de stratégies d’accès Microsoft Purview. Ils accordent l’accès aux métadonnées du système de base de données plutôt qu’aux données utilisateur. Ils simplifient l’approvisionnement des accès pour le personnel chargé des opérations informatiques et de l’audit de sécurité. Les stratégies DevOps accordent uniquement l’accès. Ils ne refusent pas l’accès.

Éléments d’une stratégie DevOps

Trois éléments définissent une stratégie DevOps :

  • Subject

    Il s’agit d’une liste d’utilisateurs, de groupes ou de principaux de service Microsoft Entra auxquels l’accès est accordé.

  • Ressource de données

    Il s’agit de l’étendue dans laquelle la stratégie est appliquée. Le chemin de la ressource de données est la composition de la source de données du groupe > de ressources d’abonnement>.

    Les stratégies DevOps Microsoft Purview prennent actuellement en charge les sources de données de type SQL. Vous pouvez les configurer sur des sources de données individuelles et sur des groupes de ressources et des abonnements entiers. Vous pouvez créer des stratégies DevOps uniquement après avoir inscrit la ressource de données dans Microsoft Purview avec l’option Application de la stratégie de données activée.

  • Rôle

    Un rôle est mappé à un ensemble d’actions autorisées par la stratégie sur la ressource de données. Les stratégies DevOps prennent en charge les rôles SQL Analyseur de performances et Vérificateur de sécurité SQL. Ces deux rôles permettent d’accéder aux métadonnées du système SQL, et plus particulièrement aux vues de gestion dynamique (DMV) et aux fonctions de gestion dynamique (DFS). Toutefois, l’ensemble des vues de gestion dynamique et des DFS que ces rôles accordent est différent. Nous fournissons quelques exemples populaires plus loin dans cet article.

    L’article Créer, lister, mettre à jour et supprimer des stratégies Microsoft Purview DevOps détaille la définition de rôle pour chaque type de source de données. Autrement dit, il fournit un mappage des rôles dans Microsoft Purview aux actions autorisées dans ce type de source de données. Par exemple, la définition de rôle pour SQL Analyseur de performances et SQL Security Auditor inclut des actions de connexion au niveau du serveur et de la base de données côté source de données.

En substance, la stratégie DevOps attribue les autorisations associées au rôle au sujet et est appliquée dans l’étendue du chemin d’accès de la ressource de données.

Application hiérarchique des stratégies

Une stratégie DevOps sur une ressource de données est appliquée à la ressource de données elle-même et à toutes les ressources enfants qu’elle contient. Par exemple, une stratégie DevOps sur un abonnement Azure s’applique à tous les groupes de ressources, à toutes les sources de données prenant en charge la stratégie au sein de chaque groupe de ressources et à toutes les bases de données au sein de chaque source de données.

Exemple de scénario pour illustrer le concept et les avantages

Bob et Alice sont impliqués dans le processus DevOps au sein de leur entreprise. Ils doivent se connecter à des dizaines d’instances SQL Server locales et Azure SQL serveurs logiques pour surveiller leurs performances afin que les processus DevOps critiques ne s’arrêtent pas. Son responsable, Mateo, place toutes ces sources de données SQL dans le groupe de ressources 1. Il crée ensuite un groupe Microsoft Entra et inclut Alice et Bob. Ensuite, il utilise les stratégies DevOps Microsoft Purview (stratégie 1 dans le diagramme suivant) pour accorder à ce groupe Microsoft Entra l’accès au groupe de ressources 1, qui héberge les serveurs logiques.

Diagramme montrant un exemple de stratégies DevOps sur un groupe de ressources .

Voici les avantages :

  • Mateo n’a pas besoin de créer des connexions locales sur chaque serveur.
  • Les stratégies de Microsoft Purview améliorent la sécurité en limitant l’accès privilégié local. Ils appuient le principe du moindre privilège. Dans le scénario, Mateo accorde uniquement l’accès minimal dont Bob et Alice ont besoin pour effectuer la tâche de surveillance de l’intégrité et des performances du système.
  • Lorsque de nouveaux serveurs sont ajoutés au groupe de ressources, Mateo n’a pas besoin de mettre à jour la stratégie dans Microsoft Purview pour qu’elle soit appliquée sur les nouveaux serveurs.
  • Si Alice ou Bob quitte le organization et que le travail est renvoyé, Mateo met simplement à jour le groupe Microsoft Entra. Il n’a pas besoin d’apporter de modifications aux serveurs ou aux stratégies qu’il a créées dans Microsoft Purview.
  • À tout moment, Mateo ou l’auditeur de l’entreprise peut voir toutes les autorisations qui ont été accordées directement dans Microsoft Purview Studio.
Principe Avantage
Simplifier Les définitions de rôle SQL Analyseur de performances et SQL Security Auditor capturent les autorisations dont les personnes informatiques et DevOps standard ont besoin pour exécuter leur travail.
Il est moins nécessaire d’avoir une expertise en matière d’autorisation sur chaque type de source de données.
Réduire l’effort Une interface graphique vous permet de parcourir rapidement la hiérarchie des objets de données.
Microsoft Purview prend en charge les stratégies sur l’ensemble des groupes de ressources et des abonnements Azure.
Renforcer la sécurité L’accès est accordé de manière centralisée et peut être facilement examiné et révoqué.
Les comptes privilégiés ont moins besoin de configurer l’accès directement au niveau de la source de données.
Les stratégies DevOps prennent en charge le principe du moindre privilège via des étendues de ressources de données et des définitions de rôle.

API de stratégies DevOps

De nombreux clients sophistiqués préfèrent interagir avec Microsoft Purview via des scripts plutôt que via l’interface utilisateur. Les stratégies DevOps Microsoft Purview prennent désormais en charge une API REST qui offre une fonctionnalité cruD (création, lecture, mise à jour et suppression) complète. Cette fonctionnalité inclut la liste, les stratégies pour sql Analyseur de performances et les stratégies pour SQL Security Auditor. Pour plus d’informations, consultez la spécification de l’API.

Capture d’écran montrant où trouver l’API DevOps dans le menu API REST Azure.

Les métadonnées dynamiques SQL incluent une liste de plus de 700 DMV et DFS. Le tableau suivant illustre certains des plus populaires. Le tableau mappe les vues de gestion dynamique et les DFS à leurs définitions de rôle dans les stratégies Microsoft Purview DevOps. Il fournit également des liens vers du contenu de référence.

Rôle DevOps Catégorie Exemple de DMV ou DMF
sql Analyseur de performances Interroger les paramètres système pour comprendre votre système sys.configurations
sys.dm_os_sys_info
Identifier les goulots d’étranglement des performances sys.dm_os_wait_stats
Analyser les requêtes en cours d’exécution sys.dm_exec_query_stats
Analyser les problèmes bloquants sys.dm_tran_locks
sys.dm_exec_requests
sys.dm_os_waiting_tasks
Analyser l’utilisation de la mémoire sys.dm_os_memory_clerks
Analyser l’utilisation et les performances des fichiers sys.master_files
sys.dm_io_virtual_file_stats
Analyser l’utilisation et la fragmentation des index sys.indexes
sys.dm_db_index_usage_stats
sys.dm_db_index_physical_stats
Gérer les connexions utilisateur actives et les tâches internes sys.dm_exec_sessions
Obtenir les statistiques d’exécution de procédure sys.dm_exec_procedure_stats
Utiliser le Magasin des requêtes sys.query_store_plan
sys.query_store_query
sys.query_store_query_text
Obtenir le journal des erreurs (pas encore pris en charge) sys.sp_readerrorlog
Vérificateur de sécurité SQL Obtenir les détails de l’audit sys.dm_server_audit_status
SQL Analyseur de performances et SQL Security Auditor sys.dm_audit_actions
sys.dm_audit_class_type_map

Pour plus d’informations sur ce que le personnel du support informatique peut faire lorsque vous lui accordez l’accès via les rôles Microsoft Purview, consultez les ressources suivantes :

Étapes suivantes

Pour commencer à utiliser les stratégies DevOps, consultez les ressources suivantes :