Exercice : Limiter l’accès public à la base de données aux services Azure

Terminée

Dans cette unité, vous remplacez la règle de pare-feu PostgreSQL qui autorise les tentatives de connexion à partir de toutes les adresses IPv4 publiques par l’exception Azure-services. La base de données conserve son endpoint public. L’exception permet aux services et ressources Azure, y compris cette application Quarkus, de tenter des connexions authentifiées ; elle ne limite pas l’accès à cette application ou l’environnement Container Apps.

Continuez dans le même interpréteur de commandes Bash local ou WSL sur Windows, avec les AZ_* variables des exercices précédents. Exécutez les vérifications de base de données à partir d’un réseau source non Azure public. Utilisez Azure CLI 2.87.0 ou version ultérieure et ne réexécutez pas la configuration du nom de ressource ou du mot de passe.

Accéder au serveur PostgreSQL à l’aide de l’interface CLI

Tout d’abord, vérifiez que vous pouvez interroger le serveur PostgreSQL à partir de votre réseau client actuel :

az postgres flexible-server execute \
    --name "$AZ_POSTGRES_SERVER_NAME" \
    --database-name "$AZ_POSTGRES_DB_NAME" \
    --admin-user "$AZ_POSTGRES_USERNAME" \
    --admin-password="$AZ_POSTGRES_PASSWORD" \
    --querytext "select * from Todo" \
    --output table

Vérifiez que la requête retourne les éléments to-do que vous avez créés précédemment. Cela confirme la connectivité à partir du réseau source de votre interpréteur de commandes, et non à partir de chaque réseau client. Résolvez toute erreur de requête avant de modifier le pare-feu afin que vous disposiez d’une base de référence opérationnelle pour les tests ultérieurs.

Supprimer la règle de pare-feu permissive

Lorsque vous avez créé le nouveau serveur PostgreSQL, --public-access All a activé son point de terminaison public et a créé une règle de pare-feu pour toutes les adresses IPv4 publiques.

Note

Ces commandes de pare-feu utilisent les noms de paramètres introduits dans Azure CLI 2.87.0 : --server-name identifie le serveur et --name identifie la règle de pare-feu. La commande distincte az postgres flexible-server execute utilise --name toujours pour le serveur. Pour plus d’informations sur la syntaxe, consultez la référence de commande de pare-feu.

Résolvez toute commande de pare-feu ayant échoué avant de continuer ; une commande rejetée ne modifie pas le pare-feu. Répertoriez les règles existantes sur votre serveur de l’exercice :

az postgres flexible-server firewall-rule list \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --output table

Recherchez la règle dont StartIpAddress est 0.0.0.0 et EndIpAddress est 255.255.255.255. Le nom généré dans la Name colonne varie. Il doit s’agir de la seule règle utilisée dans ce module sur le nouveau serveur. Si le résultat diffère, vérifiez que vous utilisez le serveur appartenant à l’exercice et résolvez l’écart avant de continuer. Ne supprimez pas les règles non liées d’un serveur existant ou d’un serveur partagé.

Cette plage permet à n’importe quelle adresse source IPv4 publique de tenter une connexion de base de données. Les clients ont toujours besoin d’informations d’identification PostgreSQL valides. Supprimez cette règle avant d’ajouter l’exception Azure-services plus loin dans l’exercice.

Les mises à jour du pare-feu PostgreSQL peuvent prendre jusqu’à cinq minutes à prendre effet. Laissez le temps après chaque modification réussie avant de vérifier la connectivité. Répétez la requête CLI dans un nouvel appel pour tester une nouvelle connexion de base de données ; une requête HTTP adressée à l’application est une vérification distincte au niveau de l’application.

Dans la commande suivante, remplacez <allow-all-rule-name> par le Name réel de la règle all-addresses que vous venez de répertorier. Supprimez les chevrons, conservez les guillemets et supprimez uniquement cette règle :

az postgres flexible-server firewall-rule delete \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --name "<allow-all-rule-name>" \
    --yes

Une fois la suppression terminée, répertoriez à nouveau les règles :

az postgres flexible-server firewall-rule list \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --output table

La commande de liste réussie devrait désormais ne renvoyer aucune règle. Si la commande échoue ou si une règle subsiste, corrigez ce problème avant de continuer. Une liste vide confirme les règles configurées, mais pas que la mise à jour réseau a été propagée.

Après avoir autorisé le temps de propagation, créez une nouvelle connexion de base de données directe en exécutant à nouveau la requête :

az postgres flexible-server execute \
    --name "$AZ_POSTGRES_SERVER_NAME" \
    --database-name "$AZ_POSTGRES_DB_NAME" \
    --admin-user "$AZ_POSTGRES_USERNAME" \
    --admin-password="$AZ_POSTGRES_PASSWORD" \
    --querytext "select * from Todo" \
    --output table

Une fois la suppression effectuée, une nouvelle connexion de base de données doit être rejetée. Le texte d’erreur dépend du client et du chemin réseau ; par exemple, PostgreSQL peut signaler qu’il n’existe aucune entrée correspondante pg_hba.conf. Ne vous attendez pas à un message de délai d’attente particulier. Une requête réussie immédiatement après la suppression peut signifier que la modification du pare-feu est toujours propagée.

Cette étape sans règle bloque intentionnellement les nouvelles connexions de base de données de l’application après que la modification a pris effet. Le point de terminaison HTTPS de l’application reste public. Quarkus utilise des connexions de base de données mises en pool. Par conséquent, une requête HTTP n’ouvre pas nécessairement une nouvelle connexion de base de données. Inspectez l’état et le corps HTTP, mais n’utilisez pas une réponse immédiate comme preuve que la propagation du pare-feu s’est terminée :

curl --include "https://$AZ_APP_URL/api/todos"

L’option --include affiche les en-têtes de réponse HTTP ainsi que le corps. Par défaut, curl ne traite pas un état d’erreur HTTP comme un échec de commande, donc inspectez l’état au lieu de vous appuyer sur son code de sortie. Pour plus d’informations, consultez le manuel curl.

Ajouter l’exception Azure-services

Ajoutez l’exception Azure-services afin que l’application déployée puisse se reconnecter à la base de données :

az postgres flexible-server firewall-rule create \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --name "Allow_Azure-services" \
    --start-ip-address "0.0.0.0" \
    --end-ip-address "0.0.0.0"

Les valeurs 0.0.0.0 de début et de fin permettent d’autoriser l’accès public à partir de n’importe quel service Azure au sein de Azure à ce serveur, comme décrit dans les règles de pare-feu PostgreSQL. Il s’agit d’une exception définie par le service concernant le point de terminaison public de la base de données, et non d’une plage d’adresses IP privées.

Important

L'exception autorise également les tentatives de connexion à partir des ressources Azure dans les abonnements d'autres clients. Cela n’identifie pas l’application Quarkus et ne limite pas l’accès à un environnement, un abonnement ou un locataire en particulier. Les clients doivent toujours s’authentifier. Cet exercice ne configure ni l’accès au réseau privé ni l’accès réservé à l’application.

Une fois la création réussie, répertoriez à nouveau les règles :

az postgres flexible-server firewall-rule list \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --output table

La seule règle sur ce nouveau serveur doit maintenant être Allow_Azure-services, avec les deux StartIpAddress et EndIpAddress définis sur 0.0.0.0. Si la commande échoue ou si les règles ne correspondent pas à ce résultat, résolvez l’écart avant de tester la connectivité. Laissez jusqu’à cinq minutes pour que la modification prenne effet.

Vérifier l’accès à la base de données et aux applications

Après avoir attendu le délai de propagation, exécutez la commande suivante dans une nouvelle exécution à partir de votre ordinateur de développement local sur un réseau source public non Azure. Utilisez les mêmes informations d’identification de base de données de travail que la requête initiale. La connexion de base de données doit être refusée lorsqu’aucune autre règle de pare-feu n’autorise cette adresse source.

Les règles de pare-feu évaluent l’adresse source, et non si le client est Azure CLI. N’utilisez pas Azure Cloud Shell pour ce test négatif : l’exception pour les services Azure peut autoriser sa connexion. Une requête réussie à partir d'un client hébergé par Azure avec des informations d'identification valides ne montre pas que la mise à jour du pare-feu a échoué.

az postgres flexible-server execute \
    --name "$AZ_POSTGRES_SERVER_NAME" \
    --database-name "$AZ_POSTGRES_DB_NAME" \
    --admin-user "$AZ_POSTGRES_USERNAME" \
    --admin-password="$AZ_POSTGRES_PASSWORD" \
    --querytext "select * from Todo" \
    --output table

Après avoir attendu que l’exception Azure-services prenne effet, récupérez les éléments to-do via l’application déployée. Recherchez HTTP 200 et un tableau JSON contenant les éléments to-do que vous avez créés précédemment :

curl --include "https://$AZ_APP_URL/api/todos"

Si une nouvelle connexion de base de données a toujours un résultat inattendu après la fenêtre de propagation, inspectez les règles de pare-feu réelles et le réseau source du client avant de modifier les informations d’identification. Une réponse d’application sans HTTP 200 et les données JSON attendues ne passe pas la vérification positive.

Les connexions PostgreSQL directes à partir d’adresses sources non Azure sont bloquées lorsqu’aucune autre règle ne les autorise. Azure-origin clients disposant d’informations d’identification de base de données valides peuvent toujours se connecter. L’API HTTPS de l’application reste publique ; ces vérifications n’établissent pas une isolation de la base de données au niveau de l’application uniquement.