Sécuriser un pool SQL dédié (anciennement SQL DW) dans Azure Synapse Analytics

Cet article vous guide tout au long des principes de base de la sécurisation de votre pool SQL dédié (anciennement SQL DW). En particulier, cet article vous permet de commencer à utiliser des ressources pour limiter l’accès, protéger les données et surveiller les activités à l’aide d’un pool SQL dédié (anciennement SQL DW).

Sécurité de la connexion

La sécurité des connexions fait référence à la façon dont vous limitez et sécurisez les connexions à votre base de données à l’aide de règles de pare-feu et de chiffrement de connexion.

Les règles de pare-feu sont utilisées par le serveur SQL logique et ses bases de données pour rejeter les tentatives de connexion à partir d’adresses IP qui n’ont pas été approuvées explicitement. Pour autoriser les connexions à partir de l’adresse IP publique de votre application ou de la machine cliente, vous devez d’abord créer une règle de pare-feu au niveau du serveur à l’aide du portail Azure, de l’API REST ou de PowerShell.

En guise de meilleure pratique, vous devez restreindre les plages d’adresses IP autorisées par le biais de votre pare-feu au niveau du serveur autant que possible. Pour accéder à votre pool SQL dédié (anciennement SQL DW) à partir de votre ordinateur local, vérifiez que le pare-feu sur votre réseau et l’ordinateur local autorise la communication sortante sur le port TCP 1433.

Le pool SQL dédié (anciennement SQL DW) utilise des règles de pare-feu IP au niveau du serveur. Il ne prend pas en charge les règles de pare-feu IP au niveau de la base de données. Pour plus d’informations, consultez les règles de pare-feu Azure SQL Database

Les connexions à votre pool SQL dédié (anciennement SQL DW) sont chiffrées par défaut. La modification des paramètres de connexion pour désactiver le chiffrement est ignorée.

Authentification

L’authentification fait référence à la façon dont vous prouvez votre identité lors de la connexion à la base de données. Le pool SQL dédié (anciennement SQL DW) prend actuellement en charge l’authentification SQL Server avec un nom d’utilisateur et un mot de passe et avec l’ID Microsoft Entra.

Lorsque vous avez créé le serveur pour votre base de données, vous avez spécifié une connexion « administrateur de serveur » avec un nom d’utilisateur et un mot de passe. À l’aide de ces informations d’identification, vous pouvez vous authentifier auprès de n’importe quelle base de données sur ce serveur en tant que propriétaire de la base de données ou « dbo » via l’authentification SQL Server.

Toutefois, comme bonne pratique, les utilisateurs de votre organisation doivent utiliser un autre compte pour s’authentifier. De cette façon, vous pouvez limiter les autorisations accordées à l’application et réduire les risques d’activité malveillante si votre code d’application est vulnérable à une attaque par injection SQL.

Pour créer un utilisateur authentifié SQL Server, connectez-vous à la base de données master sur votre serveur avec votre connexion d’administrateur de serveur et créez une connexion de serveur. Il est judicieux de créer un utilisateur dans la base de données master. La création d’un utilisateur dans master permet à un utilisateur de se connecter à l’aide d’outils comme SSMS sans spécifier de nom de base de données. Il leur permet également d’utiliser l’Explorateur d’objets pour afficher toutes les bases de données sur un serveur.

-- Connect to master database and create a login
CREATE LOGIN ApplicationLogin WITH PASSWORD = 'Str0ng_password';
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Ensuite, connectez-vous à votre pool SQL dédié (anciennement SQL DW) avec votre connexion d’administrateur de serveur et créez un utilisateur de base de données en fonction de la connexion du serveur que vous avez créée.

-- Connect to the database and create a database user
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Pour accorder à un utilisateur l’autorisation d’effectuer des opérations supplémentaires telles que la création de connexions ou la création de nouvelles bases de données, affectez-lui les rôles Loginmanager et dbmanager dans la base de données maître.

Pour plus d’informations sur ces rôles supplémentaires et l’authentification auprès d’une base de données SQL, consultez Gestion des bases de données et des connexions dans Azure SQL Database. Pour plus d’informations sur la connexion à l’aide de l’ID Microsoft Entra, consultez Connexion à l’aide de l’authentification Microsoft Entra.

Autorisation

L’autorisation fait référence à ce que vous pouvez faire dans une base de données une fois que vous êtes authentifié et connecté. Les privilèges d’autorisation sont déterminés par les appartenances aux rôles et les autorisations. En guise de bonne pratique, vous devez accorder aux utilisateurs les privilèges minimum nécessaires. Pour gérer les rôles, vous pouvez utiliser les procédures stockées suivantes :

EXEC sp_addrolemember 'db_datareader', 'ApplicationUser'; -- allows ApplicationUser to read data
EXEC sp_addrolemember 'db_datawriter', 'ApplicationUser'; -- allows ApplicationUser to write data

Le compte d’administrateur de serveur avec lequel vous vous connectez est membre de db_owner, qui a l’autorité de faire quoi que ce soit dans la base de données. Enregistrez ce compte pour déployer des mises à niveau de schéma et d’autres opérations de gestion. Utilisez le compte « ApplicationUser » avec des autorisations plus limitées pour vous connecter à partir de votre application à la base de données avec les privilèges minimum nécessaires par votre application.

Il existe des façons de limiter davantage ce qu’un utilisateur peut faire dans la base de données :

• Les autorisations granulaires vous permettent de contrôler les opérations que vous pouvez effectuer sur des colonnes, des tables, des vues, des schémas, des procédures et d’autres objets de la base de données. Utilisez des autorisations granulaires pour avoir le plus de contrôle et accorder les autorisations minimales nécessaires.
• Les rôles de base de données autres que db_datareader et db_datawriter peuvent être utilisés pour créer des comptes d’utilisateur d’application plus puissants ou des comptes de gestion moins puissants. Les rôles de base de données fixes intégrés offrent un moyen simple d’accorder des autorisations, mais peuvent entraîner l’octroi de plus d’autorisations que nécessaire.
• Les procédures stockées peuvent être utilisées pour restreindre les actions possibles sur la base de données.

L’exemple suivant accorde l’accès en lecture à un schéma défini par l’utilisateur.

--CREATE SCHEMA Test
GRANT SELECT ON SCHEMA::Test to ApplicationUser

La gestion des bases de données et des serveurs à partir du portail Azure ou l’utilisation de l’API Azure Resource Manager est contrôlée par les attributions de rôles de votre compte d’utilisateur du portail. Pour plus d’informations, consultez Attribuer des rôles Azure en utilisant le portail Azure.

Chiffrement

Transparent Data Encryption (TDE) permet de se protéger contre la menace d’une activité malveillante en chiffrant et en déchiffrant vos données au repos. Lorsque vous chiffrez votre base de données, les sauvegardes associées et les fichiers journaux des transactions sont chiffrés sans nécessiter de modifications apportées à vos applications. TDE chiffre le stockage d’une base de données entière à l’aide d’une clé symétrique appelée clé de chiffrement de base de données.

Dans SQL Database, la clé de chiffrement de base de données est protégée par un certificat de serveur intégré. Le certificat de serveur intégré est unique pour chaque serveur. Microsoft fait pivoter automatiquement ces certificats au moins tous les 90 jours. L’algorithme de chiffrement utilisé est AES-256. Pour obtenir une description générale de TDE, consultez Transparent Data Encryption.

Vous pouvez chiffrer votre base de données à l’aide du portail Azure ou de T-SQL.

Étapes suivantes

Pour plus d’informations et des exemples sur la connexion à votre entrepôt avec différents protocoles, consultez Se connecter au pool SQL dédié (anciennement SQL DW) .