Fonctionnalités et tâches de sécurité
Les services SQL Server et Azure SQL sont connus pour l’importance qu’ils accordent à la sécurité, notamment en tant que services de classe entreprise. Dans cette leçon, vous allez découvrir les différentes fonctionnalités liées à la sécurité réseau, ainsi qu’à la gestion des accès. Dans les leçons suivantes, vous allez acquérir une expérience pratique de certaines de ces fonctionnalités.
Sécurité du réseau
La première couche de sécurité inclut le réseau. Les fonctionnalités et les tâches liées au réseau différent entre Azure SQL Database et Azure SQL Managed Instance. Pour plus d’informations sur les capacités de mise en réseau Azure SQL Managed Instance, consultez Architecture de connectivité pour Azure SQL Managed Instance.
Sécurité réseau d’Azure SQL Database
Quand vous sécurisez votre réseau pour Azure SQL Database, quatre choix s’offrent à vous :
- Autoriser l’accès aux services Azure
- Utiliser des règles de pare-feu
- Utiliser des règles de réseau virtuel
- Utiliser Azure Private Link
En plus de ces choix principaux, vous avez la possibilité de bloquer tout accès public (uniquement avec Azure Private Link) et de forcer une version minimale du protocole TLS. La méthode la moins sécurisée, mais la plus facile à configurer, consiste à autoriser l’accès aux services Azure. La méthode la plus sécurisée consiste à utiliser Private Link. Les sections suivantes décrivent les fonctionnalités de chaque option, ainsi que la façon de configurer et de gérer chaque option.
Autoriser l’accès aux services Azure
Lors du déploiement d’Azure SQL Database, vous pouvez définir l’option Autoriser l’accès des services et ressources Azure à ce serveur sur Oui. En choisissant cette option, vous offrez à toutes les ressources d’une région ou d’un abonnement la possibilité d’accéder à votre ressource. Cette option facilite l’activation d’Azure SQL Database et sa connexion à d’autres services comme Machines virtuelles Azure, Azure App Service ou voire Azure Cloud Shell, car vous offrez à tout ce qui vient d’Azure la possibilité de se connecter.
Autoriser l’accès aux services Azure ne permet cependant pas l’accès à quoi que ce soit en dehors d’Azure (par exemple, votre environnement local).
La configuration la plus sure consiste à définir Autoriser l’accès des services et ressources Azure à ce serveur sur Non. Ceci bloque l’ensemble des connexions et réseaux, à l’exception de ceux que vous avez explicitement ajoutés avec les différentes options décrites dans les prochaines sections.
Règles de pare-feu
L’option suivante consiste à appliquer des règles de pare-feu. Les résultats que vous obtenez peuvent être semblables à ceux de l’option Autoriser les services et ressources Azure à accéder à ce serveur. Excepté que, pour chaque service (dans l’image suivante, une machine virtuelle), vous devez ajouter une règle de pare-feu unique pour l’autoriser à se connecter. Les règles de pare-feu permettent également à votre environnement local de se connecter à la ressource Azure SQL Database, car vous pouvez les ajouter pour des machines et applications de votre environnement local.
Pour obtenir une connectivité dans Azure, vous pouvez également autoriser l’accès aux services Azure, puis ajouter des règles de pare-feu pour votre connectivité locale uniquement. Comme mentionné précédemment, l’option Autoriser les services et ressources Azure à accéder à ce serveur n’est pas aussi sécurisée, car elle autorise tout le trafic Azure. Nous vous recommandons d’utiliser des règles de pare-feu exclusivement.
Examinons l’exemple précédent avec les règles de pare-feu configurées. À partir d’un outil compatible avec Transact-SQL (T-SQL) comme SQL Server Management Studio (SSMS), vous pouvez exécuter la requête suivante à partir votre machine virtuelle Azure dans le réseau virtuel SQLDBVNET-EUS :
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Le résultat devrait être 174.17.218.16. Il s’agit de l’adresse IP publique de la machine virtuelle Azure. Même si nous utilisons des règles de pare-feu, toutes les connexions établies sont publiques.
Règles de réseau virtuel
Si vous ne voulez utiliser que des règles de pare-feu, il peut s’avérer compliqué de le configurer. L’utilisation des règles de pare-feu uniquement implique de spécifier une série d’adresses IP pour toutes vos connexions ( certaines pouvant avoir des adresses IP dynamiques). Une alternative beaucoup plus simple consiste à utiliser des règles de réseau virtuel pour établir et gérer l’accès à partir de réseaux spécifiques contenant des machines virtuelles ou d’autres services qui ont besoin d’accéder aux données.
Si vous configurez l’accès à partir d’un réseau virtuel avec une règle de réseau virtuel, toutes les ressources de ce réseau virtuel peuvent accéder au serveur logique Azure SQL Database. Cela peut simplifier la configuration de l’accès à toutes les adresses IP statiques et dynamiques qui ont besoin d’accéder aux données. À l’aide de règles de réseau virtuel, vous pouvez spécifier un ou plusieurs réseaux virtuels, qui englobent toutes les ressources qu’ils contiennent. Vous pouvez également commencer à appliquer des technologies de réseau virtuel pour connecter des réseaux entre régions Azure et localement.
Dans cet exemple, comme dans la section précédente, vous pourriez exécuter la même requête à partir de votre machine virtuelle Azure dans le réseau virtuel SQLDBVNET-EUS :
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Le résultat serait alors 10.0.0.2, l’adresse IP privée de la machine virtuelle Azure. Cela vous permet de vous rapprocher de l’établissement de connexions privées à votre serveur logique Azure SQL Database, car les ressources se connectent maintenant par le biais du réseau virtuel.
Une autre stratégie courante pour analyser votre connexion consiste à examiner la hiérarchie DNS (Domain Name System). Dans la même machine virtuelle Azure, dans une invite de commandes, vous pouvez exécuter la commande suivante :
nslookup aw-server.database.windows.net
À l’aide de cette commande, vous pouvez accéder à des informations relatives à l’infrastructure DNS. Vous devez obtenir des résultats semblables à ce qui suit :
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: cr2.eastus1-a.control.database.windows.net
Address: 174.17.218.16
Aliases: aw-server.database.windows.net
dataslice2.eastus.database.windows.net
Dans le cadre de la réponse « ne faisant pas autorité », des points importants à examiner existent à :
- Nom : le point de terminaison commençant par
cr2fait partie de la hiérarchie DNS publique. Sans aller trop loin dans la hiérarchie, disons quecr2est l’anneau de contrôle 2, avec plusieurs « tranches » de données en dessous. - Adresse : l’adresse IP renvoyée ici doit correspondre à l’adresse IP publique de votre machine virtuelle Azure. Même si un outil tel qu’un tronçon final de SSMS se fait par l’adresse IP privée de votre machine virtuelle, l’adresse IP publique de votre machine virtuelle demeure utilisée pour se connecter à une certaine capacité.
- Alias : Les alias sont différents points dans la hiérarchie DNS, en l’occurrence la « tranche » de données spécifiques et le point de terminaison auquel vous vous connectez.
Remarque
Dans le précédent bloc de sortie, Adresse : 168.63.129.16 est une adresse IP publique virtuelle utilisée pour faciliter un canal de communication vers les ressources de la plateforme Azure. Elle s’applique à toutes les régions et à tous les clouds nationaux, et elle ne va pas changer.
Même si la connexion au travers de SSMS passe par l’adresse IP privée de la machine virtuelle Azure, vous vous connectez pour finir par un point de terminaison public.
Private Link pour une base de données Azure SQL
Vous avez vu comment configurer le réseau le plus sécurisé en utilisant votre base de données dans Azure SQL Database avec le point de terminaison public. Cette méthode de sécurisation d’une base de données dans SQL Database est utilisée depuis des années. Cependant, en 2019, Azure a commencé à s’orienter vers un concept de liaison privée, similaire à la façon de déployer Azure SQL Managed Instance. Avec Azure Private Link, vous pouvez vous connecter à votre base de données dans SQL Database et dans plusieurs autres offres PaaS (Platform as a Service) à l’aide d’un point de terminaison privé. Cela signifie qu’elle a une adresse IP privée au sein d’un réseau virtuel spécifique.
Dans l’exemple précédent, vous pouvez remarquer que l’infrastructure réseau générale n’a pas changé, et que vous pouvez toujours appliquer les stratégies de connectivité de réseau virtuel à partir des règles de réseau virtuel. Cependant, vous n’aurez pas besoin de créer des règles de réseau virtuel. Les ressources qui doivent se connecter au serveur de base de données doivent avoir accès au réseau virtuel où réside le point de terminaison. Dans l’exemple, le point de terminaison est SQLDBVNet-EUS. Seules les connexions passant par le point de terminaison privé ont accès. Toutes les autres connexions (par exemple, à partir d’Internet) sont refusées.
En continuant avec cet exemple, sur la machine virtuelle Azure dans le réseau virtuel SQLDBVNet-EUS, vous pouvez En continuant avec cet exemple, sur la machine virtuelle Azure dans le réseau virtuel « SQLDBVNET-EUS », vous pouvez à nouveau exécuter la commande T-SQL suivante :
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Le résultat est alors 10.0.0.2, soit l’adresse IP privée de la machine virtuelle Azure dans cet exemple. En ajoutant un accès à partir de votre réseau virtuel, les connexions à Azure SQL Database à partir de votre machine virtuelle vont sembler passer par l’adresse IP privée de votre machine virtuelle. Ce résultat est le même que celui que vous avez obtenu avec les règles de réseau virtuel.
Toutefois, vous souhaiterez peut-être utiliser l’invite de commandes pour examiner la hiérarchie DNS à l’aide de la commande suivante :
nslookup aw-server.database.windows.net
Si vous utilisez la commande précédente, vos résultats seront légèrement différents avec le point de terminaison privé configuré :
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: aw-server.privatelink.database.windows.net
Address: 10.0.0.5
Aliases: aw-server.database.windows.net
Dans le cadre de la réponse « ne faisant pas autorité », des points importants à examiner existent à :
- Nom : notez que vous ne pointez plus sur la hiérarchie DNS publique, mais sur le DNS de liaison privée. Cela signifie que moins d’informations sont révélées sur votre serveur de base de données.
- Adresses : Pour les règles de réseau virtuel, l’adresse renvoyée est l’adresse IP publique de votre machine virtuelle, mais cela doit désormais être une ou plusieurs adresses IP privées dans la hiérarchie Liaison privée (l’une d’entre elles est le point de terminaison privé de votre Azure SQL Database).
- Alias : comme dans le champ Nom, rien n’est en rapport avec la hiérarchie DNS, sauf que vous pouvez toujours vous connecter au nom de serveur (par exemple,
aw-server.database.windows.net).
Une question que vous pouvez vous poser, c’est, si vous vous connectez au point de terminaison privé, pourquoi utilisez-vous toujours le même nom de serveur ? Dans le backend, lorsque vous utilisez uniquement la méthode de connexion Private Link vers Azure SQL Database (c’est-à-dire sans pare-feu ni règles de réseau virtuel), les informations sont traitées comme suit :
aw-server.database.windows.net- Résolu par le service en
aw-server.privatelink.database.net- Résolu par le service en
10.0.0.5(adresse IP de votre point de terminaison privé)
- Résolu par le service en
- Résolu par le service en
De plus, le service vous empêche de vous connecter directement en utilisant autre chose que aw-server.database.windows.net.
Gestion de l’accès
Une fois que vous avez déterminé l’accès réseau, la couche suivante à examiner est la gestion de l’accès.
Contrôle d’accès en fonction du rôle
Tous les types d’opérations Azure pour Azure SQL Database sont contrôlés par le biais du contrôle d’accès en fonction du rôle (RBAC). Le contrôle RBAC est actuellement dissocié de la sécurité Azure SQL, mais vous pouvez considérer qu’il s’agit de droits de sécurité en dehors de votre base de données dans SQL Database, avec une étendue incluant l’abonnement, le groupe de ressources et la ressource. Ces droits s’appliquent aux opérations dans le portail Azure, Azure CLI et Azure PowerShell. RBAC permet la séparation des tâches entre le déploiement, la gestion et l’utilisation.
Des rôles intégrés sont disponibles pour réduire le besoin de rôles RBAC de niveau supérieur comme Propriétaire ou Contributeur. En effet, vous pouvez utiliser ces rôles pour que certaines personnes déploient des ressources Azure SQL (ou gèrent des stratégies de sécurité) mais qu’elles accordent à d’autres utilisateurs un accès réel pour utiliser ou gérer la base de données. Par exemple, un Contributeur SQL Server peut déployer un serveur et affecter un utilisateur en tant qu’administrateur du serveur et des bases de données. Les rôles intégrés pour Azure SQL Database sont les suivants :
- Contributeur de SQL DB : peut créer et gérer des bases de données mais ne peut pas accéder à la base de données (par exemple, ne peut pas se connecter et lire des données).
- Gestionnaire de sécurité SQL : peut gérer des stratégies de sécurité pour les bases de données et les instances (comme l’audit), mais n’y a pas accès
- Contributeur de SQL Server : peut gérer des serveurs et des bases de données, mais n’y a pas accès.
Authentification
Lors du déploiement du serveur logique Azure SQL Database, vous pouvez spécifier la Méthode d’authentification suivante :
- Utiliser uniquement l’authentification Microsoft Entra
- Utiliser l’authentification SQL et Microsoft Entra
- Utiliser l’authentification SQL
L’administrateur de serveur doit être défini pendant le déploiement. Pour les bases de données dans Azure SQL Database, l’administrateur de serveur est un principal au niveau du serveur pour le serveur logique Azure SQL Database.
Si vous effectuez la migration d’une charge de travail qui a besoin de l’Authentification Windows ou que votre organisation utilise Microsoft Entra ID, vous pouvez utiliser Microsoft Entra ID. Vous pouvez attribuer un administrateur du serveur Microsoft Entra à l’aide du portail ou d’outils en ligne de commande.
L’authentification Microsoft Entra uniquement est l’option par défaut lors de la configuration d’un nouveau serveur. Les connexions de serveur ont été introduites pour autoriser les principaux de serveur Microsoft Entra, qui sont des connexions dans la base de données virtuelle master d’une instance SQL Database. Vous pouvez créer des connexions Microsoft Entra à partir d’utilisateurs, de groupes et de principaux de service Microsoft Entra. Lors de l’utilisation de l’authentification Microsoft Entra uniquement, vous pouvez créer des connexions d’authentification SQL et les connexions existantes sont conservées. Toutefois, seuls les utilisateurs et les connexions d’authentification Microsoft Entra peuvent se connecter au serveur logique. Pour en savoir plus sur l’authentification Microsoft Entra uniquement, consultez Authentification Microsoft Entra uniquement avec Azure SQL.
Selon la façon dont votre organisation a configuré l’instance Microsoft Entra, vous pouvez vous y connecter à l’aide de l’une des trois méthodes suivantes (par exemple, dans SSMS) :
Microsoft Entra ID - Intégré : Méthode non interactive, que vous pouvez utiliser si vous vous êtes connecté à Windows à l’aide de vos informations d’identification Microsoft Entra à partir d’un domaine fédéré.
Microsoft Entra ID - Mot de passe : Méthode non interactive qui vous permet de vous connecter à un nom de principal Microsoft Entra à l’aide du domaine managé Microsoft Entra ID. Selon la documentation :
Cela peut s’appliquer aux utilisateurs Microsoft Entra natifs ou fédérés. Un utilisateur natif est un utilisateur explicitement créé dans Microsoft Entra ID et authentifié par un nom d’utilisateur et un mot de passe, tandis qu’un utilisateur fédéré est un utilisateur de Windows dont le domaine est fédéré avec Microsoft Entra. Cette dernière méthode (utilisant un nom d’utilisateur et un mot de passe) sert quand un utilisateur veut utiliser ses informations d’identification Windows, mais que sa machine locale n’est pas jointe au domaine (par exemple, avec un accès à distance). Dans ce cas, l’utilisateur Windows peut indiquer son compte de domaine et son mot de passe, et s’authentifier auprès de SQL Database ou Azure Synapse Analytics (anciennement SQL DW) en utilisant des informations d’identification fédérées.
Microsoft Entra ID - Universel avec authentification multifacteur (MFA) : Méthode interactive permettant de sauvegarder l’accès aux données tout en répondant à la demande de processus de connexion unique d’une organisation avec l’authentification multifacteur Microsoft Entra.
Dans Azure SQL Database, il y a quelques nuances. Vous pouvez avoir des connexions qui existent dans la base de données virtuelle master, les utilisateurs de base de données et même les utilisateurs de bases de données autonomes pour des comptes Microsoft Entra (recommandé). Même si l’administrateur de serveur pour Azure SQL Database a essentiellement des droits sysadmin, vous pouvez créer des administrateurs plus limités à l’aide de rôles au niveau du serveur ou au niveau de la base de données. Deux rôles au niveau de la base de données disponibles pour SQL Database n’existent que dans la base de données master virtuelle :
- loginmanager : Un rôle au niveau de la base de données permettant aux membres de créer des informations de connexion pour le serveur de base de données
- dbmanager : Un rôle au niveau de la base de données permettant aux membres de créer et de supprimer des bases de données pour le serveur de base de données
Voici la liste des rôles au niveau du serveur dans Azure SQL Database :
- ##MS_DatabaseConnector##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
Enfin, quand vous installez et configurez l’authentification et l’autorisation, vous devez suivre quatre recommandations :
- déployer avec un administrateur de serveur ;
- créer d’autres administrateurs si nécessaire ;
- les administrateurs peuvent créer des utilisateurs ;
- autoriser l’accès comme vous le feriez dans SQL Server.
Autres fonctionnalités
Après vous être entraîné avec quelques fonctionnalités de réseau et d’authentification, le module aborde plus loin d’autres fonctionnalités (et leurs tâches connexes) de protection, de supervision, de journalisation et d’audit des données.