Partage via

Méthodologie de réussite de l’implémentation Synapse : Évaluer la conception de l’espace de travail

  • Article

Notes

Cet article fait partie de la série Réussite de l’implémentation d’Azure Synapse par conception. Pour obtenir une vue d’ensemble de la série, consultez Réussite de l’implémentation d’Azure Synapse par conception.

L’espace de travail Synapse est une expérience utilisateur graphique unifiée qui combine vos moteurs de traitement des données et analytiques, lacs de données, bases de données, tables, jeux de données et artefacts de création de rapports, ainsi que du code et de l’orchestration des processus. Compte tenu du nombre de technologies et de services intégrés dans l’espace de travail Synapse, assurez-vous que les composants clés sont inclus dans votre conception.

Évaluation de la conception de l’espace de travail Synapse

Vérifiez si votre conception de solution implique un espace de travail ou plusieurs espaces de travail Synapse. Identifiez les pilotes de cette conception. Bien qu’il puisse exister des raisons diverses à l’existence d’espaces de travail multiples, ceux-ci servent généralement à séparer la sécurité ou la facturation du reste de l’environnement informatique. Lorsque vous définissez le nombre d’espaces de travail et de limites de base de données, gardez à l’esprit que la limite est 20 espaces de travail par abonnement.

Identifiez les éléments ou services au sein de chaque espace de travail qui doivent être partagés et avec quelles ressources ils doivent l’être. Les ressources peuvent inclure des lacs de données, des runtimes d’intégration, des métadonnées ou des configurations et du code. Déterminez pourquoi cette conception particulière a été choisie en termes de synergies potentielles. Demandez-vous si ces synergies justifient le coût supplémentaire et la charge de gestion.

Révision de conception du lac de données

Nous recommandons que le lac de données (s’il fait partie de votre solution) soit correctement hiérarchisé. Vous devez diviser votre lac de données en trois zones principales liées aux jeux de données Bronze, Silver et Gold. Bronze - la couche brute - peut résider sur son propre compte de stockage distinct, car il a des contrôles d’accès plus stricts en raison de données sensibles non masquées qu’il peut stocker.

Évaluation de conception de la sécurité

Passez en revue la conception de sécurité de l’espace de travail et comparez-la aux informations que vous avez collectées pendant l’évaluation. Vérifiez que toutes les exigences sont remplies et que toutes les contraintes ont été prises en compte. Pour faciliter la gestion, nous recommandons aux utilisateurs d’être organisés en groupes avec le profilage des autorisations approprié : vous pouvez simplifier le contrôle d’accès à l’aide de groupes de sécurité qui s’alignent sur les rôles. De cette façon, les administrateurs réseau peuvent ajouter ou supprimer des utilisateurs des groupes de sécurité appropriés pour gérer l’accès.

Les pools SQL serverless et les tables Apache Spark stockent leurs données dans un conteneur Azure Data Lake Gen2 (ADLS Gen2) associé à l’espace de travail. Les bibliothèques Apache Spark installées par l’utilisateur sont également gérées dans le même compte de stockage. Pour activer ces cas d’usage, les utilisateurs et l’identité du service administré de l’espace de travail doivent être ajoutés au rôle Contributeur aux données Blob de stockage du conteneur de stockage ADLS Gen2. Vérifiez cette exigence par rapport à vos exigences de sécurité.

Les pools SQL dédiés fournissent un ensemble complet de fonctionnalités de sécurité pour chiffrer et masquer les données sensibles. Les pools SQL dédiés et serverless activent la surface d’exposition complète des autorisations SQL Server, notamment les rôles intégrés, les rôles définis par l’utilisateur, l’authentification SQL et l’authentification Microsoft Entra. Passez en revue la conception de sécurité pour le pool SQL dédié de votre solution et l’accès et les données au pool SQL serverless.

Passez en revue le plan de sécurité de votre lac de données et tous les comptes de stockage ADLS Gen2 (et d’autres) qui feront partie de votre solution Azure Synapse Analytics. Le stockage ADLS Gen2 n’est pas lui-même un moteur de calcul et ne dispose donc pas d’une capacité intégrée pour masquer de manière sélective les attributs de données. Vous pouvez appliquer des autorisations ADLS Gen2 au niveau du compte de stockage ou du conteneur à l’aide du contrôle d’accès en fonction du rôle (RBAC) et/ou au niveau du dossier ou du fichier à l’aide de listes de contrôle d’accès (ACL). Passez en revue attentivement la conception et essayez d’éviter toute complexité inutile.

Voici quelques points à prendre en compte pour la conception de la sécurité.

  • Vérifiez que les exigences de configuration de Microsoft Entra ID sont incluses dans la conception.
  • Recherchez les scénarios interlocataires. De tels problèmes peuvent survenir, car certaines données se situent dans un autre locataire Azure ou doivent être déplacées vers un autre locataire, ou elles doivent être accessibles par les utilisateurs d’un autre locataire. Vérifiez que ces scénarios sont pris en compte dans votre conception.
  • Quels sont les rôles pour chaque espace de travail ? Comment utiliseront-t-ils l’espace de travail ?
  • Comment la sécurité est-elle conçue dans l’espace de travail ?
    • Qui peut afficher tous les scripts, notebooks et pipelines ?
    • Qui peut exécuter des scripts et des pipelines ?
    • Qui peut créer/suspendre/reprendre des pools SQL et Spark ?
    • Qui peut publier des modifications dans l’espace de travail ?
    • Qui peut valider les modifications apportées au contrôle de code source ?
  • Les pipelines accèdent-ils aux données à l’aide d’informations d’identification stockées ou de l’identité managée de l’espace de travail ?
  • Les utilisateurs ont-ils l’accès approprié au lac de données pour parcourir les données dans Synapse Studio ?
  • Le lac de données est-il correctement sécurisé à l’aide de la combinaison appropriée de RBAC et de listes de contrôle d’accès ?
  • Les autorisations utilisateur du pool SQL ont-elles été définies correctement pour chaque rôle (scientifique des données, développeur, administrateur, utilisateur professionnel et autres) ?

Révision de conception de mise en réseau

Voici quelques points à prendre en compte pour la conception du réseau.

  • La connectivité est-elle conçue entre toutes les ressources ?
  • Quel est le mécanisme de mise en réseau à utiliser (Azure ExpressRoute, Internet public ou points de terminaison privés) ?
  • Avez-vous besoin de pouvoir vous connecter en toute sécurité à Synapse Studio ?
  • L’exfiltration des données a-t-elle été prise en compte ?
  • Avez-vous besoin de vous connecter à des sources de données locales ?
  • Avez-vous besoin de vous connecter à d’autres sources de données cloud ou moteurs de calcul, tels qu’Azure Machine Learning ?
  • Les composants réseau Azure, comme les groupes de sécurité réseau (NSG), ont-ils été examinés pour une connectivité et un déplacement approprié des données ?
  • L’intégration aux zones DNS privées a-t-elle été prise en compte ?
  • Avez-vous besoin de pouvoir parcourir le lac de données à partir de Synapse Studio ou simplement interroger des données dans le lac de données avec SQL serverless ou PolyBase ?

Enfin, identifiez tous vos consommateurs de données et vérifiez que leur connectivité est prise en compte dans la conception. Vérifiez que les avant-postes de sécurité et de réseau permettent à votre service d’accéder aux sources locales requises et que ses protocoles et mécanismes d’authentification sont pris en charge. Dans certains scénarios, vous devrez peut-être posséder plusieurs IR auto-hébergés ou passerelle de données pour les solutions SaaS, comme Microsoft Power BI.

Analyse de la conception

Passez en revue la conception de la supervision des composants Azure Synapse pour vous assurer qu’ils répondent aux exigences et aux attentes identifiées lors de l’évaluation. Vérifiez que la surveillance des ressources et de l’accès aux données a été conçue et qu’elle identifie chaque exigence de surveillance. Une solution de supervision robuste doit être mise en place dans le cadre du premier déploiement en production. De cette façon, les défaillances peuvent être identifiées, diagnostiquées et traitées en temps opportun. Outre l’infrastructure de base et les exécutions de pipeline, les données doivent également être surveillées. Selon les composants Azure Synapse en cours d’utilisation, identifiez les exigences de surveillance pour chaque composant. Par exemple, si les pools Spark font partie de la solution, surveillez le magasin d’enregistrements mal formé. 

Voici quelques points à prendre en compte pour la conception de la supervision.

  • Qui peut surveiller chaque type de ressource (pipelines, pools et autres) ?
  • Combien de temps les journaux d’activité de base de données doivent-ils être conservés ?
  • L’espace de travail et la rétention des journaux de base de données utiliseront-ils Log Analytics ou Stockage Azure ?
  • Les alertes seront-elles déclenchées en cas d’erreur de pipeline ? Si c’est le cas, qui doit être averti ?
  • Quel niveau de seuil d’un pool SQL doit déclencher une alerte ? Qui doit être averti ?

Révision de conception du contrôle de code source

Par défaut, un espace de travail Synapse applique les modifications directement au service Synapse à l’aide de la fonctionnalité de publication intégrée. Vous pouvez activer l’intégration du contrôle de code source, ce qui offre de nombreux avantages. Les avantages incluent une meilleure collaboration, le contrôle de version, les approbations et les pipelines de mise en production pour promouvoir les modifications apportées aux environnements de développement, de test et de production. Azure Synapse autorise un référentiel de contrôle de code source unique par espace de travail, qui peut être Git Azure DevOps ou GitHub.

Voici quelques points à prendre en compte pour la conception du contrôle de code source.

  • Si vous utilisez Azure DevOps Git, l’espace de travail Synapse et son référentiel se trouve-t-il dans le même locataire ?
  • Qui pourra accéder au contrôle de code source ?
  • Quelles sont les autorisations accordées à chaque utilisateur dans le contrôle de code source ?
  • Une stratégie de branchement et de fusion a-t-elle été développée ?
  • Les pipelines de mise en production seront-ils développés pour le déploiement vers différents environnements ?
  • Un processus d’approbation sera-t-il utilisé pour la fusion et pour les pipelines de mise en production ?

Notes

La conception de l’environnement de développement est d’une importance capitale pour le succès de votre projet. Si un environnement de développement a été conçu, il sera évalué dans une phase distincte de cette méthodologie.

Étapes suivantes

Dans l’article suivant de la série Réussite d’Azure Synapse par conception, découvrez comment évaluer la conception de l’intégration de données et vérifier qu’elle répond aux instructions et exigences.