Ejercicio: Limitar el acceso público a la base de datos para los servicios de Azure

En esta unidad, reemplazará la regla de firewall de PostgreSQL que permite los intentos de conexión de todas las direcciones IPv4 públicas por la excepción Azure-services. La base de datos conserva su punto de conexión público. La excepción permite a los servicios y recursos de Azure, incluida esta aplicación de Quarkus, que intenten conexiones autenticadas; no restringe el acceso a esta aplicación ni al entorno de Container Apps.

Continúe en el mismo shell de Bash local o WSL en Windows, con AZ_* variables de los ejercicios anteriores. Ejecute las comprobaciones de base de datos desde una red de origen pública que no sea Azure. Utilice CLI de Azure 2.87.0 o posterior y no vuelva a ejecutar la configuración del nombre del recurso o de la contraseña.

Acceda al servidor PostgreSQL mediante la CLI

En primer lugar, confirme que puede consultar el servidor postgreSQL desde la red de cliente actual:

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

Compruebe que la consulta devuelve los elementos to-do que creó anteriormente. Esto confirma la conectividad desde la red de origen de tu shell, no desde todas las redes cliente. Resuelva cualquier error de consulta antes de cambiar el firewall para que tenga una línea base de trabajo para las pruebas posteriores.

Eliminación de la regla de firewall permisiva

Al crear el nuevo servidor PostgreSQL, --public-access All se habilitó su punto de conexión público y se creó una regla de firewall para todas las direcciones IPv4 públicas.

Resuelva cualquier comando de firewall fallido antes de continuar; un comando rechazado no cambia el firewall. Enumere las reglas existentes en el servidor propio del ejercicio:

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

Busque la regla en la que StartIpAddress es 0.0.0.0 y EndIpAddress es 255.255.255.255. El nombre generado en la Name columna varía. Esta debe ser la única regla en el nuevo servidor que se usa en este módulo. Si el resultado difiere, confirme que usa el servidor propiedad del ejercicio y resuelva la discrepancia antes de continuar. No elimine reglas no relacionadas de un servidor existente o compartido.

Este intervalo permite que cualquier dirección de origen IPv4 pública intente una conexión de base de datos. Los clientes siguen necesitando credenciales válidas de PostgreSQL. Quite esta regla antes de agregar la excepción Azure-services más adelante, en el ejercicio.

Las actualizaciones del firewall de PostgreSQL pueden tardar hasta cinco minutos en aplicarse. Espere un tiempo después de cada cambio realizado correctamente antes de comprobar la conectividad. Repita la consulta de la CLI en una nueva invocación para probar una conexión de base de datos nueva; una solicitud HTTP a la aplicación es una comprobación de nivel de aplicación independiente.

En el siguiente comando, reemplace <allow-all-rule-name> por el Name real de la regla de todas las direcciones que acaba de mostrar. Quite los signos de ángulo, mantenga las comillas y elimine solo esa regla:

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

Después de que la eliminación se realice correctamente, vuelva a enumerar las reglas:

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

El comando list correcto ahora no debe devolver ninguna regla. Si el comando falla o queda alguna regla, resuelva esa situación antes de continuar. Una lista vacía confirma las reglas configuradas, pero no que se ha propagado la actualización de red.

Después de permitir el tiempo de propagación, vuelva a ejecutar la consulta para realizar una nueva conexión de base de datos directa:

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

Una vez que la eliminación surte efecto, se debe rechazar una nueva conexión de base de datos. El texto del error depende del cliente y la ruta de acceso de red; Por ejemplo, PostgreSQL puede notificar que no hay ninguna entrada coincidente pg_hba.conf . No espere un mensaje de tiempo de espera determinado. Una consulta correcta inmediatamente después de la eliminación puede significar que el cambio del firewall todavía se está propagando.

Esta etapa sin reglas bloquea intencionadamente nuevas conexiones de la aplicación a la base de datos después de que el cambio surta efecto. El punto de conexión HTTPS de la aplicación sigue siendo público. Quarkus usa conexiones de base de datos agrupadas, por lo que una solicitud HTTP no abre necesariamente una nueva conexión de base de datos. Inspeccione el estado y el cuerpo de HTTP, pero no use una respuesta inmediata como prueba de que se ha completado la propagación del firewall:

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

La --include opción muestra los encabezados de respuesta HTTP, así como el cuerpo. De forma predeterminada, curl no trata un estado de error HTTP como un fallo del comando, por lo que inspecciona el estado en lugar de confiar en su código de salida. Para obtener más información, consulte el manual de curl.

Agregar la excepción Azure-services

Agregue la excepción Azure-services para que la aplicación implementada pueda volver a conectarse a la base de datos:

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"

Los valores 0.0.0.0 iniciales y finales permiten permitir el acceso público desde cualquier servicio de Azure dentro de Azure a este servidor, como se describe en Reglas de firewall de PostgreSQL. Se trata de una excepción definida por el servicio para el punto de conexión público de la base de datos, no de un intervalo de direcciones IP privadas.

Una vez creada correctamente, vuelva a listar las reglas:

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

La única regla de este nuevo servidor ahora debe ser Allow_Azure-services, con StartIpAddress y EndIpAddress establecidos en 0.0.0.0. Si se produce un error en el comando o las reglas no coinciden con este resultado, resuelva la discrepancia antes de probar la conectividad. Espere hasta cinco minutos para que el cambio surta efecto.

Comprobación del acceso a la base de datos y a la aplicación

Después de permitir el tiempo de propagación, ejecute el siguiente comando en una nueva invocación desde el equipo de desarrollo local en una red de origen pública que no sea Azure. Use las mismas credenciales de base de datos de trabajo que la consulta inicial. Se debe denegar la conexión de base de datos cuando ninguna otra regla de firewall permita esa dirección de origen.

Las reglas de firewall evalúan la dirección de origen, no si el cliente es CLI de Azure. No utilice Azure Cloud Shell para esta prueba negativa: la excepción Azure-services puede permitir su conexión. Una consulta correcta de un cliente hospedado en Azure con credenciales válidas no demuestra que la actualización del firewall haya fallado.

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

Después de permitir que la excepción de servicios de Azure surta efecto, recupere los elementos to-do a través de la aplicación implementada. Busque HTTP 200 y una matriz JSON que contenga los elementos to-do que creó anteriormente:

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

Si una conexión de base de datos nueva sigue teniendo un resultado inesperado después de la ventana de propagación, inspeccione las reglas de firewall reales y la red de origen del cliente antes de cambiar las credenciales. Una respuesta de aplicación sin HTTP 200 y los datos JSON esperados no pasa la comprobación positiva.

Las conexiones directas de PostgreSQL desde direcciones de origen que no son de Azure se bloquean cuando ninguna otra regla las permite. Los clientes con origen en Azure con credenciales de base de datos válidas todavía pueden conectarse. La API HTTPS de la aplicación sigue siendo pública; estas comprobaciones no establecen el aislamiento de la base de datos exclusivo para la aplicación.