Esercizio - Limitare l'accesso pubblico al database ai servizi di Azure

In questa unità si sostituisce la regola del firewall PostgreSQL che consente i tentativi di connessione da tutti gli indirizzi IPv4 pubblici con l'eccezione Azure-services. Il database mantiene l'endpoint pubblico. L'eccezione consente ai servizi e alle risorse di Azure, inclusa questa applicazione Quarkus, di tentare connessioni autenticate; non limita l'accesso a questa applicazione o all'ambiente Container Apps.

Continuare nella stessa shell Bash locale o WSL in Windows, con le AZ_* variabili degli esercizi precedenti. Eseguire i controlli del database da una rete di origine pubblica non Azure. Usare interfaccia della riga di comando di Azure 2.87.0 o versione successiva e non eseguire nuovamente la configurazione del nome della risorsa o della password.

Accedere al server PostgreSQL usando l'interfaccia della riga di comando

Prima di tutto, verificare che sia possibile eseguire una query sul server PostgreSQL dalla rete client corrente:

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

Verificare che la query restituisca i to-do elementi creati in precedenza. Ciò conferma la connettività dalla rete di origine della tua shell, non da ogni rete client. Risolvere eventuali errori di query prima di modificare il firewall in modo da disporre di una baseline funzionante per i test successivi.

Rimuovere la regola del firewall permissiva

Quando hai creato il nuovo server PostgreSQL, --public-access All hai abilitato il relativo endpoint pubblico e hai creato una regola del firewall per tutti gli indirizzi IPv4 pubblici.

Risolvere eventuali comandi firewall non riusciti prima di continuare; un comando rifiutato non modifica il firewall. Elencare le regole esistenti nel server dell'esercitazione:

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

Trovare la regola di cui StartIpAddress è 0.0.0.0 e EndIpAddress è 255.255.255.255. Il nome generato nella Name colonna varia. Questa deve essere l'unica regola nel nuovo server usato in questo modulo. Se il risultato è diverso, verificare di usare il server di proprietà dell'esercizio e risolvere la discrepanza prima di continuare. Non eliminare regole non correlate da un server esistente o condiviso.

Questo intervallo consente a qualsiasi indirizzo di origine IPv4 pubblico di tentare una connessione al database. I clienti necessitano ancora di credenziali PostgreSQL valide. Rimuovere questa regola prima di aggiungere l'eccezione Azure-services più avanti nell'esercizio.

L'applicazione degli aggiornamenti del firewall postgreSQL può richiedere fino a cinque minuti. Attendere dopo ogni modifica riuscita prima di controllare la connettività. Ripetere la query della CLI in una nuova chiamata per testare una nuova connessione al database; una richiesta HTTP all'applicazione è un controllo a livello di applicazione separato.

Nel comando seguente sostituire <allow-all-rule-name> con il valore effettivo di Name della regola all-addresses appena elencata. Rimuovere le parentesi angolari, mantenere le virgolette ed eliminare solo tale regola:

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

Al termine dell'eliminazione, elencare di nuovo le regole:

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

Se il comando list ha esito positivo, ora non dovrebbe restituire alcuna regola. Se il comando ha esito negativo o rimane ancora qualche regola, risolvere tale problema prima di procedere. Un elenco vuoto conferma le regole configurate, ma non che l'aggiornamento di rete sia stato propagato.

Dopo aver consentito il tempo di propagazione, effettuare una nuova connessione diretta al database eseguendo di nuovo la query:

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 volta applicata l'eliminazione, deve essere rifiutata una nuova connessione di database. Il testo dell'errore dipende dal client e dal percorso di rete; Ad esempio, PostgreSQL può segnalare che non esiste alcuna voce corrispondente pg_hba.conf . Non aspettarsi un determinato messaggio di timeout. Una query con esito positivo immediatamente dopo l'eliminazione può indicare che la modifica del firewall è ancora in corso di propagazione.

Questa fase no-rule blocca intenzionalmente le nuove connessioni al database dall'applicazione dopo che la modifica entra in vigore. L'endpoint HTTPS dell'applicazione rimane pubblico. Quarkus usa connessioni di database in pool, quindi una richiesta HTTP non apre necessariamente una nuova connessione al database. Esaminare lo stato e il corpo HTTP, ma non usare una risposta immediata come prova che la propagazione del firewall è stata completata:

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

L'opzione --include visualizza le intestazioni di risposta HTTP e il corpo. Per impostazione predefinita, curl non considera uno stato di errore HTTP come un fallimento del comando, quindi controllare lo stato anziché basarsi sul codice di uscita. Per dettagli, vedere il manuale di curl.

Aggiungere l'eccezione Azure-services

Aggiungere l'eccezione Azure-services in modo che l'applicazione distribuita possa riconnettersi al database:

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"

I valori iniziali e finali 0.0.0.0 consentono di abilitare Consenti l'accesso pubblico da qualsiasi servizio Azure all'interno di Azure a questo server, come descritto in Regole del firewall di PostgreSQL. Si tratta di un'eccezione definita dal servizio nell'endpoint pubblico del database, non in un intervallo di indirizzi IP privati.

Al termine della creazione, elencare di nuovo le regole:

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

L'unica regola in questo nuovo server dovrebbe ora essere Allow_Azure-services, con StartIpAddress e EndIpAddress impostati su 0.0.0.0. Se il comando non riesce o le regole non corrispondono a questo risultato, risolvere la discrepanza prima di testare la connettività. Attendere fino a cinque minuti per rendere effettiva la modifica.

Verificare l'accesso al database e all'applicazione

Dopo aver consentito il tempo di propagazione, eseguire il comando seguente in una nuova esecuzione dal computer di sviluppo locale in una rete di origine pubblica non Azure. Usare le stesse credenziali del database di lavoro della query iniziale. La connessione al database deve essere negata quando nessun'altra regola del firewall consente tale indirizzo di origine.

Le regole del firewall valutano l'indirizzo di origine, non se il client è interfaccia della riga di comando di Azure. Non usare Azure Cloud Shell per questo test negativo: l'eccezione Azure-services può consentirne la connessione. Una query eseguita correttamente da un client ospitato in Azure con credenziali valide non dimostra che l'aggiornamento del firewall sia riuscito.

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

Dopo aver atteso il tempo necessario affinché l'eccezione Azure-services diventi effettiva, recuperare gli elementi to-do tramite l'applicazione distribuita. Verificare la presenza di HTTP 200 e di un array JSON contenente gli elementi to-do creati in precedenza:

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

Se una nuova connessione al database ha ancora un risultato imprevisto dopo la finestra di propagazione, esaminare le regole del firewall effettive e la rete di origine del client prima di modificare le credenziali. Una risposta dell'applicazione priva di HTTP 200 o dei dati JSON previsti non supera il controllo positivo.

Le connessioni PostgreSQL dirette da indirizzi di origine non Azure vengono bloccate quando nessun'altra regola le consente. i client di origine Azure con credenziali di database valide possono comunque connettersi. L'API HTTPS dell'applicazione rimane pubblica; questi controlli non stabiliscono l'isolamento del database solo per l'applicazione.