Exercice : Restreindre l’accès réseau

  • 25 minutes

Les utilisateurs se connectent à votre serveur d’applications pour entrer des commandes, mettre à jour leur compte et effectuer des activités similaires. À son tour, le serveur d’applications met à jour la base de données avec ces modifications. Comme les utilisateurs ont des données personnelles stockées dans la base de données, il est essentiel de garantir que vous autorisez l’accès uniquement à partir des ressources nécessaires et approuvées. Il existe plusieurs façons de contrôler l’accès à votre base de données SQL sur le réseau.

Règles de pare-feu

Azure SQL Database a un pare-feu intégré qui permet d’autoriser et de refuser l’accès réseau au serveur de base de données lui-même ainsi qu’aux bases de données individuelles. À la base, le pare-feu SQL Database bloque tout accès public à votre base de données Azure SQL. Pour accéder à votre serveur de base de données, vous devez spécifier une ou plusieurs règles de pare-feu IP au niveau du serveur qui permettent l’accès à votre base de données Azure SQL. Vous utilisez les règles de pare-feu IP pour spécifier les plages d’adresses IP Internet qui sont autorisées, et si les applications Azure peuvent essayer de se connecter à votre base de données Azure SQL.

Les règles de pare-feu sont configurées au niveau du serveur ou de la base de données. Les règles indiquent spécifiquement les ressources réseau autorisées à établir une connexion à la base de données. Selon le niveau, les règles que vous pouvez appliquer sont les suivantes :

  • Règles de pare-feu au niveau du serveur
    • Autoriser l’accès aux services Azure
    • Règles d’adresse IP
    • Règles de réseau virtuel
  • Règles de pare-feu au niveau de la base de données
    • Règles d’adresse IP

Notes

SQL Data Warehouse prend en charge uniquement les règles de pare-feu IP au niveau du serveur, pas les règles de pare-feu IP au niveau de la base de données.

Examinez comment ces règles fonctionnent.

Règles de pare-feu au niveau du serveur

Ces règles permettent aux clients d’accéder à la totalité de votre serveur Azure SQL, c’est-à-dire à toutes les bases de données au sein du même serveur logique. Il existe trois types de règles qui peuvent être appliqués au niveau du serveur.

La règle Autoriser l’accès aux services Azure permet à des services au sein d’Azure de se connecter à votre base de données SQL Azure. Quand il est activé, ce paramètre autorise les communications provenant de toutes les adresses IP publiques Azure. Cette communication inclut toute la plateforme Azure en tant que services PaaS, comme Azure App Service et Azure Container Service, ainsi que les machines virtuelles Azure qui ont un accès Internet sortant. Cette règle peut être configurée via l’option ACTIVÉ/DÉSACTIVÉ dans le volet du pare-feu du portail, ou par une règle d’adresse IP avec 0.0.0.0 comme adresses IP de début et de fin.

Diagramme montrant comment autoriser l’accès au réseau des services Azure.

Cette règle est utilisée quand vous avez des applications qui s’exécutent sur des services PaaS dans Azure, comme Azure Logic Apps ou Azure Functions, qui doivent accéder à votre base de données Azure SQL. Un grand nombre de ces services n’ont pas d’adresse IP statique. Cette règle garantit donc qu’ils sont en mesure de se connecter à la base de données.

Important

Cette option configure le pare-feu pour autoriser toutes les connexions à partir d’Azure, notamment les connexions provenant des abonnements d’autres clients. Quand vous sélectionnez cette option, vérifiez que votre connexion et vos autorisations utilisateur limitent l’accès uniquement aux utilisateurs autorisés.

Les Règles d’adresse IP sont des règles basées sur des plages d’adresses IP publiques spécifiques. Les adresses IP se connectant depuis une plage d’adresses IP publiques autorisées sont autorisées à se connecter à la base de données.

Le diagramme représente une règle d’adresse IP.

Vous pouvez utiliser ces règles quand vous avez une adresse IP publique statique qui doit accéder à votre base de données.

Les règles de réseau virtuel vous permettent d’autoriser explicitement la connexion à partir de sous-réseaux spécifiés à l’intérieur d’un ou de plusieurs réseaux virtuels Azure. Les règles de réseau virtuel peuvent fournir un meilleur contrôle de l’accès à vos bases de données et peuvent représenter la meilleure option. Comme les espaces d’adressage des réseaux virtuels Azure sont privés, vous pouvez éliminer efficacement l’exposition à des adresses IP publiques et sécuriser les connexions à ces adresses que vous contrôlez.

Le diagramme représente une règle de réseau virtuel.

Utilisez les règles de réseau virtuel quand vous avez des machines virtuelles Azure qui doivent accéder à votre base de données.

Pour les règles au niveau du serveur, toutes ces règles peuvent être créées et manipulées via le portail, PowerShell, l’interface CLI et Transact-SQL (T-SQL).

Règles de pare-feu au niveau de la base de données

Ces règles autorisent l’accès à une base de données individuelle sur un serveur logique et sont stockées dans la base de données elle-même. Pour les règles au niveau de la base de données, vous pouvez configurer uniquement des règles d’adresses IP. Elles fonctionnent comme quand elles sont appliquées au niveau du serveur, mais elles sont limitées à la base de données.

Le diagramme représente une règle réseau d’adresses IP de base de données.

Les avantages des règles au niveau de la base de données sont relatifs à leur portabilité. Lorsque vous répliquez une base de données sur un autre serveur, les règles au niveau de la base de données sont répliquées, car elles sont stockées dans la base de données elle-même.

L’inconvénient de ces règles est que vous pouvez utiliser seulement des règles d’adresse IP. Ces règles peuvent limiter la flexibilité dont vous disposez et augmenter les coûts d’administration.

Les règles de pare-feu au niveau de la base de données peuvent être créées et manipulées seulement via T-SQL.

Restreindre l’accès réseau en pratique

En guise de meilleure pratique, utilisez des règles de pare-feu IP au niveau de la base de données pour renforcer la sécurité et améliorer la portabilité de la base de données. Utilisez des règles de pare-feu IP au niveau du serveur pour les administrateurs quand vous avez plusieurs bases de données avec les même critères d’accès et que vous ne voulez pas les configurer une par une.

Examinez comment ces règles fonctionnent en pratique, et comment vous pouvez sécuriser l’accès réseau pour autoriser seulement ce qui est nécessaire. Rappelez-vous que vous avez créé un serveur logique Azure SQL Database, une base de données et la machine virtuelle linux appServer, qui fonctionne comme serveur d’applications. Ce scénario se produit souvent quand une base de données a été migrée vers Azure SQL Database et que des ressources à l’intérieur d’un réseau virtuel doivent y accéder. La fonctionnalité de pare-feu d’Azure SQL Database peut être utilisée dans de nombreux scénarios. Cet exemple a une applicabilité pratique et montre le fonctionnement de chacune des règles.

Passez en revue les paramètres du pare-feu et voyez comment ils fonctionnent. Pour ces exercices, vous allez utiliser le portail et Cloud Shell.

La base de données que vous avez créée n’autorise actuellement l’accès depuis aucune connexion. Cet accès limité est lié à la conception et basé sur les commandes que vous avez exécutées pour créer le serveur logique et la base de données. Confirmez qu’il n’y a pas d’accès.

  1. Dans Cloud Shell, connectez-vous avec SSH à votre machine virtuelle Linux si vous n’y êtes pas encore connecté. Remplacez nnn.nnn.nnn.nnn par la valeur de publicIpAddress dans l’unité précédente.

    ssh nnn.nnn.nnn.nnn

  2. Réexécutez la commande sqlcmd que vous avez récupérée précédemment pour tenter d’établir une connexion à la base de données. Remplacez [server-name] par le nom de votre serveur. Remplacez [username] et [password] par les informations d’identification de ADMINUSER que vous avez spécifiées dans l’unité précédente. Conservez les guillemets simples autour du nom d’utilisateur et du mot de passe pour que l’interpréteur de commandes interprète correctement les caractères spéciaux.

    sqlcmd -S tcp:[server-name].database.windows.net,1433 -d marketplaceDb -U '[username]' -P '[password]' -N -l 30

    Une erreur similaire à la sortie suivante doit s’afficher lorsque vous essayez de vous connecter. Cette sortie est attendue, car l’accès à la base de données n’est pas autorisé.

    Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Login timeout expired.
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : TCP Provider: Error code 0x2AF9.
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible.Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.

Accordez l’accès pour que vous puissiez vous connecter.

Utiliser la règle Autoriser l’accès aux services Azure au niveau du serveur

Parce que votre machine virtuelle a un accès Internet sortant, vous pouvez utiliser la règle Autoriser l’accès aux services Azure pour autoriser l’accès à partir de votre machine virtuelle.

  1. Connectez-vous au portail Azure en utilisant le même compte que celui avec lequel vous avez activé le bac à sable.

  2. Dans le champ Rechercher des ressources, services et documents en haut, recherchez le nom de votre serveur de base de données, server-name. Sélectionnez le serveur SQL.

  3. Dans le volet du serveur SQL, dans le menu de gauche, sous Sécurité, sélectionnez Mise en réseau.

  4. Faites défiler jusqu’à Exceptions, cochez la case Autoriser les services et les ressources Azure à accéder à ce serveur, puis sélectionnez Enregistrer. Attendez que le système accuse réception de cette modification.

  5. Revenez à votre session SSH et réessayez de vous connecter à votre base de données.

    sqlcmd -S tcp:[server-name].database.windows.net,1433 -d marketplaceDb -U '[username]' -P '[password]' -N -l 30

    À ce stade, vous devez pouvoir vous connecter. Si la connexion réussit, vous devez voir une invite sqlcmd.

    1>

Vous avez ouvert la connectivité, mais ce paramètre autorise l’accès depuis n’importe quelle ressource Azure, notamment des ressources en dehors de votre abonnement. Restreignez davantage cet accès de façon à limiter l’accès réseau uniquement aux ressources qui sont sous votre contrôle.

Utiliser une règle d’adresse IP au niveau de la base de données

Rappelez-vous que les règles d’adresse IP au niveau de la base de données autorisent seulement l’accès à une base de données individuelle sur un serveur logique. Vous allez utiliser ici une de ces règles pour accorder l’accès à l’adresse IP statique de votre machine virtuelle appServer.

Pour créer une règle d’adresse IP au niveau de la base de données, vous devez exécuter quelques commandes T-SQL. Créez une règle de base de données selon la convention suivante, où vous passez le nom de la règle, l’adresse IP de début et l’adresse IP de fin. En spécifiant les adresses IP de début et de fin pour qu’elles soient identiques, vous limitez l’accès à une seule adresse IP. Vous pouvez étendre la plage si vous avez un plus grand bloc d’adresses qui nécessitent un accès.

EXECUTE sp_set_database_firewall_rule N'My Firewall Rule', '40.112.128.214', '40.112.128.214'

  1. Toujours à l’invite sqlcmd, exécutez la commande suivante. Remplacez l’adresse IP publique de votre machine virtuelle appServer dans les deux emplacements.

    Conseil

    Lorsque vous exécutez des commandes T-SQL telles que les suivantes, le GO sur la deuxième ligne peut ne pas être copiée à l’invite sqlcmd. Vous devrez peut-être taper cette partie. La commande T-SQL ne fonctionnant pas sans celle-ci, veillez à exécuter la commande GO.

    EXECUTE sp_set_database_firewall_rule N'My Firewall Rule', '[From IP Address]', '[To IP Address]';
GO

    Une fois la commande terminée, entrez exit pour quitter sqlcmd. Restez connecté via SSH.

  2. Dans le portail Azure, dans le volet Mise en réseau de votre serveur SQL, décochez Autoriser les services et les ressources Azure à accéder à ce serveur, puis sélectionnez Enregistrer. Cette modification désactive l’accès à partir de tous les services Azure, mais vous pouvez vous connecter, car vous disposez d’une règle IP au niveau de la base de données pour votre serveur.

  3. De retour dans Cloud Shell, dans la machine virtuelle à laquelle vous êtes connecté via SSH, essayez de vous reconnecter à votre base de données.

    sqlcmd -S tcp:[server-name].database.windows.net,1433 -d marketplaceDb -U '[username]' -P '[password]' -N -l 30

    À ce stade, vous devez pouvoir vous connecter. Si la connexion réussit, vous voyez une invite sqlcmd.

    1>

L’utilisation d’une règle au niveau de la base de données permet d’isoler l’accès spécifiquement à la base de données. Cette règle peut être pratique si vous souhaitez conserver votre accès réseau configuré par base de données. Si plusieurs bases de données partagent le même niveau d’accès réseau, vous pouvez simplifier l’administration en utilisant une règle au niveau du serveur, de façon à appliquer le même accès à toutes les bases de données du serveur.

Utiliser une règle d’adresse IP au niveau du serveur

Les règles au niveau de la base de données sont une bonne option, mais que se passe-t-il si vous avez sur le même serveur plusieurs bases de données auxquelles votre machine virtuelle appServer doit se connecter ? Vous pouvez ajouter une règle au niveau de la base de données pour chaque base de données. Toutefois, cette opération demande plus de travail au fur et à mesure que vous ajoutez des bases de données. Pour réduire votre travail d’administration, autorisez l’accès avec une règle au niveau du serveur, qui s’appliquerait à toutes les bases de données présentes sur le serveur.

Utilisez une règle d’adresse IP au niveau du serveur pour limiter les systèmes qui peuvent se connecter.

  1. À l’invite sqlcmd, exécutez la commande suivante pour supprimer la règle d’adresse IP au niveau de la base de données.

    EXECUTE sp_delete_database_firewall_rule N'My Firewall Rule';
GO

    Une fois la commande terminée, entrez exit pour quitter sqlcmd. Restez connecté via SSH.

  2. De retour dans le portail Azure, dans le volet Mise en réseau de votre serveur SQL, sous Règles de pare-feu, sélectionnez Ajouter une règle de pare-feu. Nommez la règle Autoriser appServer, entrez l’adresse IP publique de la machine virtuelle appServer pour l’adresse IP de début et l’adresse IP de fin, puis sélectionnez OK.

  3. Sélectionnez Enregistrer.

    Capture d’écran du portail Azure montrant la création d’une règle de pare-feu de serveur.

  4. De retour dans Cloud Shell, sur votre machine virtuelle appServer, réessayez de vous connecter à votre base de données.

    sqlcmd -S tcp:[server-name].database.windows.net,1433 -d marketplaceDb -U '[username]' -P '[password]' -N -l 30

    À ce stade, vous devez pouvoir vous connecter. La règle au niveau du serveur autorise l’accès en fonction de l’adresse IP publique de la machine virtuelle appServer. Si la connexion réussit, vous devez voir une invite sqlcmd.

    1>

    Entrez exit pour quitter sqlcmd. Restez connecté via SSH.

Vous avez isolé la connectivité pour la réduire à la seule adresse IP que vous avez spécifiée dans la règle. Cette isolation fonctionne très bien, mais peut encore représenter une certaine charge de travail d’administration au fil de l’ajout de systèmes qui doivent se connecter. Elle nécessite également une adresse IP statique ou une adresse IP à partir d’une plage d’adresses IP définie.

Si l’adresse IP est dynamique et change, vous devez mettre à jour la règle pour garantir la connectivité. La machine virtuelle appServer est actuellement configurée avec une adresse IP dynamique. Cette adresse IP est susceptible de changer à un certain moment, ce qui casserait votre accès dès que cela se produirait. Examinez maintenant comment les règles de réseau virtuel peuvent être utiles dans votre configuration.

Utiliser une règle de réseau virtuel au niveau du serveur

Dans le cas présent, parce que votre machine virtuelle s’exécute dans Azure, vous pouvez utiliser une règle de réseau virtuel au niveau du serveur pour isoler l’accès et faciliter l’accès de services futurs à la base de données.

  1. De retour dans le portail Azure et toujours dans le volet Mise en réseau, sous Réseaux virtuels, sélectionnez Ajouter une règle de réseau virtuel.

  2. La boîte de dialogue Créer/mettre à jour une règle de réseau virtuel apparaît. Attribuez les valeurs suivantes.

    Paramètre Valeur
    Nom Conservez la valeur par défaut
    Abonnement Abonnement Concierge
    Réseau virtuel appServerVNET
    Nom du sous-réseau / préfixe d’adresse appServerSubnet / 10.0.0.0/24

  3. Sélectionnez Activer pour activer le point de terminaison de service sur le sous-réseau, puis OK une fois que le point de terminaison est activé pour créer la règle.

  4. Supprimez la règle d’adresse IP. Sélectionnez successivement ... à côté de votre règle Allow appServer, Supprimer, puis Enregistrer.

  5. De retour dans Cloud Shell, sur votre machine virtuelle appServer, réessayez de vous connecter à votre base de données.

    sqlcmd -S tcp:[server-name].database.windows.net,1433 -d marketplaceDb -U '[username]' -P '[password]' -N -l 30

    À ce stade, vous devez pouvoir vous connecter. Si la connexion réussit, vous voyez une invite sqlcmd.

    1>

Ce que vous avez fait ici supprime effectivement tout accès public au serveur SQL. Il autorise l’accès uniquement à partir du sous-réseau spécifique dans le réseau virtuel Azure que vous avez défini. Si vous ajoutez d’autres serveurs d’applications dans ce sous-réseau, aucune configuration supplémentaire n’est nécessaire. Tout serveur de ce sous-réseau aurait la possibilité de se connecter au serveur SQL.

Cette configuration limite votre exposition à des services en dehors de l’étendue de votre contrôle et facilite l’administration en cas d’ajout de serveurs supplémentaires. Cette méthode est efficace pour sécuriser l’accès réseau à Azure SQL Database.