Support formation Microsoft Azure

Support formation Microsoft Azure

DP-203

Sécuriser un entrepôt de données dans Azure Synapse Analytics [WiP]

Gonzague Ducos

Découvrir les options de sécurité réseau pour Azure Synapse Analytics

Pour sécuriser l’accès au service lui-même : créer les objets réseau suivants, notamment :

Règles de pare-feu

Réseaux virtuels

Instances Private Endpoint

Règles de pare-feu

Vérifiez que le pare-feu sur votre réseau et ordinateur local autorise les communications sortantes sur les ports TCP 80, 443 et 1443 pour Synapse Studio.

UDP 53 pour Synapse Studio

SSMS et Power BI, vous devez autoriser la communication sortante sur le port TCP 1433

Réseaux virtuels

Le réseau virtuel permet à de nombreux types de ressources Azure, telles qu’Azure Synapse Analytics, de communiquer de manière sécurisée avec d’autres réseaux virtuels, avec Internet et avec les réseaux locaux.

Le réseau virtuel associé à votre espace de travail est managé par Azure Synapse.

Appelé réseau virtuel d’espace de travail managé

Avantages suivants :

Déplacer la charge liée à la gestion du réseau virtuel vers Azure Synapse.

Pas obligé de configurer des règles de groupe de sécurité réseau entrantes sur vos propres réseaux virtuels pour autoriser le trafic de gestion Azure Synapse à pénétrer sur votre réseau virtuel.

Pas besoin de créer de sous-réseau pour vos clusters Spark en fonction de la charge maximale

Le réseau virtuel d’espace de travail managé, ainsi que les points de terminaison privés managés, assurent une protection contre l’exfiltration des données. Vous pouvez créer des points de terminaison privés managés uniquement dans un espace de travail associé à un réseau virtuel d’espace de travail managé.

Garantit que le réseau de votre espace de travail est isolé de celui des autres espaces de travail.

⁠

Instances Private Endpoint

Azure Synapse Analytics vous permet de vous connecter à ses différents composants par le biais de points de terminaison.

⁠

Configurer un accès conditionnel

Définir les conditions dans lesquelles un utilisateur peut se connecter à votre abonnement Azure et aux services d’accès.

Couche supplémentaire de sécurité qui peut être utilisée conjointement avec l’authentification pour renforcer l’accès de sécurité à votre réseau

Dans leur forme la plus simple, sont des instructions if-then : si un utilisateur souhaite accéder à une ressource, il doit effectuer une action

Utilisent des signaux comme base pour déterminer si l’accès conditionnel doit d’abord être appliqué. Les signaux courants sont les suivants :

Noms d’appartenance des utilisateurs ou des groupes

Informations sur les adresses IP

Plateformes ou types d’appareils

Demandes d’accès aux applications

Détection des risques en temps réel et calculés

Microsoft Cloud App Security (MCAS)

Selon signaux, choisir de bloquer l’accès. Ou également accorder l’accès + demander à l’utilisateur d’effectuer une action supplémentaire, notamment :

Effectuer l’authentification multifacteur

Utiliser un appareil spécifique pour la connexion

Azure Synapse Analytics doit être configuré pour prendre en charge Microsoft Entra ID. De plus, si vous avez choisi l'authentification multifacteur, l'outil que vous utilisez le prend en charge.

Se connecter au portail Azure, sélectionnez Microsoft Entra ID, puis sélectionnez Accès conditionnel.

Dans Stratégies d’accès conditionnel > Nouvelle stratégie, fournissez un nom, puis cliquez sur Configure rules (Configurer les règles).

Sous Affectations, sélectionnez Utilisateurs et groupes, cochez Sélectionner des utilisateurs et des groupes, puis sélectionnez l’utilisateur ou le groupe pour l’accès conditionnel. Cliquez sur Sélectionner, puis sur Terminé pour valider la sélection.

Sélectionnez Applications cloud, puis cliquez sur Sélectionner des applications. Vous voyez toutes les applications disponibles pour l’accès conditionnel. Sélectionnez Azure SQL Database, cliquez en bas sur Sélectionner, puis sur Terminé.

Si vous ne trouvez pas Azure SQL Database répertorié dans la troisième capture d’écran ci-dessous, effectuez les étapes suivantes :

Connectez-vous à votre base de données dans Azure SQL Database à l'aide de SSMS avec un compte d'administrateur Microsoft Entra.

Exécutez CREATE USER [user@yourtenant.com] FROM EXTERNAL PROVIDER.

Connectez-vous à Microsoft Entra ID et vérifiez qu'Azure SQL Database, SQL Managed Instance ou Azure Synapse sont répertoriés dans les applications de votre instance Microsoft Entra.

Sélectionnez Contrôles d’accès, Accorder, puis cochez la stratégie que vous souhaitez appliquer. Pour cet exemple, nous sélectionnons l’option Exiger l’authentification multifacteur.

Configurer l’authentification

L’authentification est le processus de validation des informations d’identification lorsque vous accédez aux ressources dans une infrastructure numérique.

Besoins d’authentifications

L'authentification est essentielle pour protéger les données dans Azure Synapse Analytics. Elle concerne à la fois les utilisateurs individuels, qui utilisent des identifiants et des mots de passe, et les services, qui doivent s'authentifier entre eux pour fonctionner de manière transparente. Des scénarios combinant l'authentification des utilisateurs et des services existent également, comme l'utilisation de Power BI pour afficher des rapports, nécessitant plusieurs niveaux d'authentification.

Types de sécurité

Microsoft Entra ID

L’atout de Microsoft Entra ID est que l’employé n’a à se connecter qu’une seule fois.

Identités managées

Fonctionnalité de Microsoft Entra ID.

Identités managées pour les ressources Azure est le nouveau nom du service anciennement nommé Managed Service Identity (MSI).

⁠

Authentification SQL

Pour les comptes d’utilisateurs qui ne font pas partie de Microsoft Entra ID, l’utilisation de l’authentification SQL est une alternative.

Généralement utile pour les utilisateurs externes qui ont besoin d’accéder aux données, ou si vous utilisez des applications tierces ou héritées sur le pool SQL dédié d’Azure Synapse Analytics

Authentification multifacteur

⁠

Keys

Si vous ne parvenez pas à utiliser une identité gérée pour accéder à des ressources telles qu’Azure Data Lake, vous pouvez utiliser les clés de compte de stockage et les signatures d’accès partagé. Utiliser Azure Key Vault pour gérer et sécuriser les clés.

Principaux avantages de l’utilisation de Key Vault :

Séparation entre les informations sensibles des applications et les autres informations de configuration et le code, ce qui réduit les risques de fuites accidentelles

Accès restreint aux secrets grâce à des stratégies d’accès adaptées aux applications et aux personnes qui en ont besoin

Centralisation du stockage des secrets, ce qui permet d’effectuer tous les changements nécessaires à un seul endroit

Journalisation et supervision des accès pour vous aider à comprendre comment et quand les secrets sont sollicités

Signatures d’accès partagé

Pour les clients non approuvés, utilisez une signature d’accès partagé (SAS).

Est une chaîne contenant un jeton de sécurité qui peut être attaché à un URI.

Pour déléguer l’accès aux objets de stockage et pour spécifier des contraintes, comme les autorisations et la plage de temps de l’accès.

Vous pouvez donner à un client un jeton de signature d'accès partagé.

Types de signatures d’accès partagé

Par exemple, vous pouvez utiliser une signature d’accès partagé au niveau du compte pour donner la possibilité de créer des systèmes de fichiers.

Gérer l’autorisation par le biais de la sécurité au niveau des colonnes et des lignes

Sécurité au niveau des colonnes dans Azure Synapse Analytics

La méthode d’implémentation de la sécurité au niveau des colonnes est l’utilisation de l’instruction T-SQL GRANT. À l’aide de cette instruction, SQL et Microsoft Entra ID prennent en charge l’authentification.

GRANT <permission> [ ,...n ] ON

[ OBJECT :: ][ schema_name ]. object_name [ ( column [ ,...n ] ) ] // specifying the column access

TO <database_principal> [ ,...n ]

[ WITH GRANT OPTION ]

[ AS <database_principal> ]

<permission> ::=

SELECT

| UPDATE

<database_principal> ::=

Database_user // specifying the database user

| Database_role // specifying the database role

| Database_user_mapped_to_Windows_User

| Database_user_mapped_to_Windows_Group

Sécurité au niveau des lignes dans Azure Synapse Analytics [WiP]

Description de la sécurité au niveau des lignes par rapport aux prédicats de filtre

Seuls les prédicats de filtre sont pris en charge au sein d’Azure Synapse. Si vous devez utiliser un prédicat BLOCK, celui-ci n’est actuellement pas pris en charge dans Azure Synapse. Permettent de filtrer silencieusement les lignes disponibles pour les opérations de lecture, telles que SELECT, UPDATE, DELETE

[ FILTER | BLOCK ]

Type de prédicat de sécurité pour la fonction liée à la table cible. Les prédicats FILTER filtrent de manière silencieuse les lignes disponibles pour les opérations de lecture. Les prédicats BLOCK bloquent de façon explicite les opérations d’écriture qui violent la fonction de prédicat

La façon d’implémenter la sécurité au niveau des lignes consiste à utiliser la stratégie CREATE SECURITY POLICY.

Si vous souhaitez créer, modifier ou supprimer les stratégies de sécurité, vous devez utiliser l’autorisation ALTER ANY SECURITY POLICY. En effet, lorsque vous créez ou supprimez une stratégie de sécurité, vous devez disposer des autorisations ALTER sur le schéma

Autorisations

Il existe d’autres autorisations requises pour chaque prédicat ajouté :

Les autorisations SELECT et REFERENCES sur la fonction table sont utilisées comme prédicats.

L’autorisation REFERENCES sur la table que vous ciblez est liée à la stratégie.

L'autorisation REFERENCES sur chaque colonne de la table cible utilisée comme argument

Si vous avez créé une stratégie de sécurité dans laquelle SCHEMABINDING = OFF, l’utilisateur doit disposer de l’autorisation SCHEMABINDING = OFF ou EXECUTE sur la fonction de prédicat pour pouvoir interroger la table cible. Il est également nécessaire d’avoir les autorisations sur des tables, des vues ou des fonctions supplémentaires utilisées dans la fonction de prédicat. Si une stratégie de sécurité est créée avec SCHEMABINDING = ON (valeur par défaut), alors ces contrôles d’autorisations sont ignorés quand les utilisateurs interrogent la table cible.