Support formation Microsoft Azure

Pages

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.

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

Exemple de sécurité au niveau des colonnes

Créez la table Membership avec la colonne SSN utilisée pour stocker les numéros de sécurité sociale :

CREATE TABLE Membership

(MemberID int IDENTITY,

FirstName varchar(100) NULL,

SSN char(9) NOT NULL,

LastName varchar(100) NOT NULL,

Phone varchar(12) NULL,

Email varchar(100) NULL);

Autorisez TestUser à accéder à toutes les colonnes à l'exception de la colonne SSN qui contient les données sensibles :

GRANT SELECT ON Membership(MemberID, FirstName, LastName, Phone, Email) TO TestUser;

Les requêtes exécutées sous le nom TestUser échouent si elles comprennent la colonne SSN :

SELECT * FROM Membership;

-- Msg 230, Level 14, State 1, Line 12

-- The SELECT permission was denied on the column 'SSN' of the object 'Membership', database 'CLS_TestDW', schema 'dbo'.

Exemple de sécurité au niveau des lignes

Une fois les prérequis en place, créez trois comptes d’utilisateur qui illustrent différentes fonctionnalités d’accès.

--run in master

CREATE LOGIN Manager WITH PASSWORD = '<user_password>'

CREATE LOGIN Sales1 WITH PASSWORD = '<user_password>'

CREATE LOGIN Sales2 WITH PASSWORD = '<user_password>'

--run in master and your SQL pool database

CREATE USER Manager FOR LOGIN Manager;

CREATE USER Sales1 FOR LOGIN Sales1;

CREATE USER Sales2 FOR LOGIN Sales2 ;

Créez une table pour stocker des données

CREATE TABLE Sales

(

OrderID int,

SalesRep sysname,

Product varchar(10),

Qty int

);

Remplissez la table avec six lignes de données, en affichant trois commandes pour chaque représentant commercial

INSERT INTO Sales VALUES (1, 'Sales1', 'Valve', 5);

INSERT INTO Sales VALUES (2, 'Sales1', 'Wheel', 2);

INSERT INTO Sales VALUES (3, 'Sales1', 'Valve', 4);

INSERT INTO Sales VALUES (4, 'Sales2', 'Bracket', 2);

INSERT INTO Sales VALUES (5, 'Sales2', 'Wheel', 5);

INSERT INTO Sales VALUES (6, 'Sales2', 'Seat', 5);

-- View the 6 rows in the table

SELECT * FROM Sales;

Créez une table externe Azure Synapse à partir de la table Sales que vous venez de créer.

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<user_password>';

CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';

CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://<file_system_name@storage_account>.dfs.core.windows.net', CREDENTIAL = msi_cred);

CREATE EXTERNAL FILE FORMAT MSIFormat WITH (FORMAT_TYPE=DELIMITEDTEXT);

CREATE EXTERNAL TABLE Sales_ext WITH (LOCATION='<your_table_name>', DATA_SOURCE=ext_datasource_with_abfss, FILE_FORMAT=MSIFormat, REJECT_TYPE=Percentage, REJECT_SAMPLE_VALUE=100, REJECT_VALUE=100)

AS SELECT * FROM sales;

Accordez SELECT pour les trois utilisateurs sur la table externe Sales_ext que vous avez créée.

GRANT SELECT ON Sales_ext TO Sales1;

GRANT SELECT ON Sales_ext TO Sales2;

GRANT SELECT ON Sales_ext TO Manager;

Créez un schéma et une fonction table inlined. La fonction retourne 1 quand une ligne de la colonne SalesRep est identique à l’utilisateur qui exécute la requête (@SalesRep = USER_NAME()) ou si l’utilisateur qui exécute la requête correspond à l’utilisateur Manager (USER_NAME() = 'Manager').

CREATE SCHEMA Security;

CREATE FUNCTION Security.fn_securitypredicate(@SalesRep AS sysname)

RETURNS TABLE

WITH SCHEMABINDING

RETURN SELECT 1 AS fn_securitypredicate_result

WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'Manager';

Créez une stratégie de sécurité sur votre table externe en utilisant la fonction table inlined comme prédicat de filtre. L'état doit être défini sur ON pour activer la stratégie

CREATE SECURITY POLICY SalesFilter_ext

ADD FILTER PREDICATE Security.fn_securitypredicate(SalesRep)

ON dbo.Sales_ext

WITH (STATE = ON);

Testez maintenant le prédicat de filtrage en effectuant une sélection dans la table externe Sales_ex. Connectez-vous chacun en tant qu’utilisateur Sales1, Sales2 et Manager. Exécutez la commande suivante en tant qu’utilisateur. L'utilisateur Manager doit visualiser l'ensemble des six lignes. Les utilisateurs Sales1 et Sales2 ne doivent voir que leurs propres ventes

SELECT * FROM Sales_ext;

Modifiez la stratégie de sécurité pour désactiver la stratégie : Les utilisateurs Sales1 et Sales2 peuvent maintenant visualiser l'ensemble des six lignes.

ALTER SECURITY POLICY SalesFilter_ext

WITH (STATE = OFF);

Gérer les données sensibles avec Dynamic Data Masking

Dynamic Data Masking pris en charge dans :

Azure SQL Database

Azure SQL Managed Instance

Azure Synapse Analytics

Dynamic Data Masking :

garantit une exposition limitée des données aux utilisateurs sans privilèges, de sorte qu’ils ne peuvent pas voir les données masquées.

basée sur des stratégies

masque les données sensibles dans un jeu de résultats d’une requête qui s’exécute sur des champs de base de données désignés

Pour Azure Synapse Analytics, la façon de configurer une stratégie de Dynamic Data Masking consiste à utiliser PowerShell ou l’API REST.

⁠

Stratégies de Dynamic Data Masking :

Utilisateurs SQL exclus des stratégies de Dynamic Data Masking Les identités Microsoft Entra ID et les utilisateurs SQL suivants peuvent obtenir des données non masquées dans les résultats de la requête SQL. Les utilisateurs possédant des privilèges administrateur sont toujours exclus du masquage et voient les données d’origine sans masque.

Règles de masquage Ensemble de règles qui définissent les champs désignés à masquer, y compris la fonction de masquage à utiliser. Les champs désignés peuvent être définis avec un nom de schéma de base de données, un nom de table et un nom de colonne.

Fonctions de masquage Ensemble de méthodes qui contrôlent l'exposition des données dans différents scénarios.

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

Règles de pare-feu

Réseaux virtuels

Instances Private Endpoint

Configurer un accès conditionnel

Configurer l’authentification

Besoins d’authentifications