Übung – Einschränken des öffentlichen Datenbankzugriffs auf Azure Dienste
In dieser Einheit ersetzen Sie die PostgreSQL-Firewallregel, die Verbindungsversuche von allen öffentlichen IPv4-Adressen zulässt, durch die Ausnahme für Azure-Dienste. Die Datenbank behält ihren öffentlichen Endpunkt bei. Mit der Ausnahme können Azure-Dienste und -Ressourcen, einschließlich dieser Quarkus-Anwendung, authentifizierte Verbindungen herstellen; der Zugriff auf diese Anwendung oder die Container-Apps-Umgebung wird nicht eingeschränkt.
Fahren Sie mit den AZ_* Variablen aus den vorherigen Übungen in derselben lokalen Bash-Shell oder WSL auf Windows fort. Führen Sie die Datenbanküberprüfungen aus einem öffentlichen Quellnetzwerk außerhalb von Azure aus. Verwenden Sie Azure CLI 2.87.0 oder höher, und führen Sie die Einrichtung des Ressourcennamens oder Kennworts nicht erneut durch.
Zugreifen auf den PostgreSQL-Server mithilfe der CLI
Vergewissern Sie sich zunächst, dass Sie den PostgreSQL-Server von Ihrem aktuellen Clientnetzwerk abfragen können:
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
Stellen Sie sicher, dass die Abfrage die zuvor erstellten to-do Elemente zurückgibt. Dadurch wird die Konnektivität aus dem Quellnetzwerk Ihrer Shell bestätigt, nicht aus jedem Clientnetzwerk. Beheben Sie alle Abfragefehler, bevor Sie die Firewall so ändern, dass Sie für die späteren Tests über eine funktionierende Ausgangsbasis verfügen.
Entfernen der zulässigen Firewallregel
Wenn Sie den neuen PostgreSQL-Server erstellt haben, haben Sie --public-access All seinen öffentlichen Endpunkt aktiviert und eine Firewall-Regel für alle öffentlichen IPv4-Adressen erstellt.
Hinweis
Diese Firewallbefehle verwenden die in Azure CLI 2.87.0 eingeführten Parameternamen: --server-name identifiziert den Server und --name identifiziert die Firewallregel. Der separate az postgres flexible-server execute-Befehl verwendet weiterhin --name für den Server. Ausführliche Informationen zur Syntax finden Sie in der Firewallbefehlsreferenz.
Beheben Sie alle fehlgeschlagenen Firewallbefehle, bevor Sie fortfahren; Ein abgelehnter Befehl ändert die Firewall nicht. Listen Sie die vorhandenen Regeln auf Ihrem übungseigenen Server auf:
az postgres flexible-server firewall-rule list \
--server-name "$AZ_POSTGRES_SERVER_NAME" \
--resource-group "$AZ_RESOURCE_GROUP" \
--output table
Suchen Sie die Regel, deren StartIpAddress Ist 0.0.0.0 und EndIpAddress ist 255.255.255.255. Der generierte Name in der Name Spalte variiert. Dies sollte die einzige Regel auf dem neuen Server sein, der in diesem Modul verwendet wird. Wenn sich das Ergebnis unterscheidet, vergewissern Sie sich, dass Sie den übungseigenen Server verwenden, und lösen Sie die Diskrepanz, bevor Sie fortfahren. Löschen Sie keine nicht relevanten Regeln von einem vorhandenen oder freigegebenen Server.
Dieser Bereich ermöglicht es allen öffentlichen IPv4-Quelladressen, eine Datenbankverbindung herzustellen. Clients benötigen weiterhin gültige PostgreSQL-Anmeldeinformationen. Entfernen Sie diese Regel, bevor Sie die Ausnahme für Azure-Dienste später in der Übung hinzufügen.
Die Aktualisierungen der PostgreSQL-Firewall können bis zu fünf Minuten dauern. Warten Sie nach jeder erfolgreichen Änderung etwas, bevor Sie die Verbindung überprüfen. Wiederholen Sie die CLI-Abfrage in einem neuen Aufruf, um eine neue Datenbankverbindung zu testen; eine HTTP-Anforderung an die Anwendung ist eine separate Prüfung auf Anwendungsebene.
Ersetzen Sie im folgenden Befehl <allow-all-rule-name> durch den tatsächlichen Name-Wert der soeben aufgelisteten all-addresses-Regel. Entfernen Sie die spitzen Klammern, behalten Sie die Anführungszeichen bei, und löschen Sie nur diese Regel:
az postgres flexible-server firewall-rule delete \
--server-name "$AZ_POSTGRES_SERVER_NAME" \
--resource-group "$AZ_RESOURCE_GROUP" \
--name "<allow-all-rule-name>" \
--yes
Nachdem der Löschvorgang erfolgreich war, führen Sie die Regeln erneut auf:
az postgres flexible-server firewall-rule list \
--server-name "$AZ_POSTGRES_SERVER_NAME" \
--resource-group "$AZ_RESOURCE_GROUP" \
--output table
Der erfolgreich ausgeführte list-Befehl sollte jetzt keine Regeln zurückgeben. Wenn der Befehl fehlschlägt oder noch eine Regel besteht, beheben Sie dieses Ergebnis, bevor Sie fortfahren. Eine leere Liste bestätigt die konfigurierten Regeln, aber nicht, dass sich die Netzwerkaktualisierung im Netzwerk verbreitet hat.
Erstellen Sie nach dem Zulassen der Verteilungszeit eine neue direkte Datenbankverbindung, indem Sie die Abfrage erneut ausführen:
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
Nachdem der Löschvorgang wirksam wurde, sollte eine neue Datenbankverbindung abgelehnt werden. Fehlertext hängt vom Client- und Netzwerkpfad ab; Beispielsweise kann PostgreSQL melden, dass kein übereinstimmener pg_hba.conf Eintrag vorhanden ist. Erwarten Sie keine bestimmte Timeoutnachricht. Eine erfolgreiche Abfrage unmittelbar nach dem Löschen kann bedeuten, dass die Firewalländerung sich noch ausbreitet.
Diese Phase ohne Regel blockiert absichtlich neue Datenbankverbindungen von der Anwendung, nachdem die Änderung wirksam wird. Der HTTPS-Endpunkt der Anwendung bleibt öffentlich. Quarkus verwendet poolierte Datenbankverbindungen, sodass eine HTTP-Anforderung nicht unbedingt eine neue Datenbankverbindung öffnet. Überprüfen Sie den HTTP-Status und den Body, verwenden Sie jedoch keine sofortige Antwort als Nachweis, dass die Firewall-Propagierung abgeschlossen wurde:
curl --include "https://$AZ_APP_URL/api/todos"
Die --include Option zeigt die HTTP-Antwortheader sowie den Body an. Standardmäßig behandelt curl keinen HTTP-Fehlerstatus als Befehlsfehler. Prüfen Sie daher den Status, anstatt sich auf den Ausgangscode zu verlassen. Ausführliche Informationen finden Sie im Curl-Handbuch.
Ausnahme für Azure-Dienste hinzufügen
Fügen Sie die Ausnahme Azure-Dienste hinzu, damit die bereitgestellte Anwendung eine erneute Verbindung mit der Datenbank herstellen kann:
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"
Die Start- und Endwerte 0.0.0.0 ermöglichen den öffentlichen Zugriff von einem beliebigen Azure Dienst innerhalb Azure auf diesen Server, wie in PostgreSQL-Firewallregeln beschrieben. Hierbei handelt es sich um eine dienstdefinierte Ausnahme für den öffentlichen Endpunkt der Datenbank, nicht um einen privaten IP-Adressbereich.
Important
Die Ausnahme ermöglicht auch Verbindungsversuche von Azure-Ressourcen in Abonnements anderer Kunden. Es identifiziert weder die Quarkus-Anwendung noch schränkt den Zugriff auf eine Umgebung, ein Abonnement oder einen Mandanten ein. Clients müssen sich weiterhin authentifizieren. Diese Übung konfiguriert kein privates Netzwerk und keinen Zugriff ausschließlich für Anwendungen.
Nachdem die Erstellung erfolgreich war, führen Sie die Regeln erneut auf:
az postgres flexible-server firewall-rule list \
--server-name "$AZ_POSTGRES_SERVER_NAME" \
--resource-group "$AZ_RESOURCE_GROUP" \
--output table
Die einzige Regel auf diesem neuen Server sollte jetzt sein Allow_Azure-services, wobei sowohl StartIpAddress als auch EndIpAddress auf 0.0.0.0 gesetzt sind. Wenn der Befehl fehlschlägt oder die Regeln nicht mit diesem Ergebnis übereinstimmen, lösen Sie die Diskrepanz vor dem Testen der Konnektivität. Es kann bis zu fünf Minuten dauern, bis die Änderung wirksam wird.
Überprüfen des Datenbank- und Anwendungszugriffs
Nachdem Sie ausreichend Zeit für die Propagierung gewartet haben, führen Sie den folgenden Befehl in einer neuen Instanz von Ihrem lokalen Entwicklungscomputer aus, der sich in einem öffentlichen Quellnetzwerk außerhalb von Azure befindet. Verwenden Sie dieselben Arbeitsdatenbankanmeldeinformationen wie die ursprüngliche Abfrage. Die Datenbankverbindung sollte verweigert werden, wenn keine andere Firewallregel diese Quelladresse zulässt.
Firewallregeln bewerten die Quelladresse, nicht, ob der Client Azure CLI ist. Verwenden Sie Azure Cloud Shell für diesen negativen Test nicht: die Ausnahme für Azure-Dienste kann die Verbindung zulassen. Eine erfolgreiche Abfrage von einem Azure gehosteten Client mit gültigen Anmeldeinformationen zeigt nicht an, dass das Firewallupdate fehlgeschlagen ist.
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
Nachdem Sie ausreichend Zeit eingeräumt haben, damit die Azure-Dienste-Ausnahme wirksam wird, rufen Sie die To-do-Elemente über die bereitgestellte Anwendung ab. Überprüfen Sie auf HTTP 200 und ein JSON-Array, das die zuvor erstellten to-do Elemente enthält:
curl --include "https://$AZ_APP_URL/api/todos"
Sollte eine neue Datenbankverbindung auch nach Ablauf des Propagierungsfensters noch zu unerwarteten Ergebnissen führen, überprüfen Sie die aktuellen Firewall-Regeln und das Quellnetzwerk des Clients, bevor Sie die Anmeldedaten ändern. Eine Anwendungsantwort ohne HTTP 200 und die erwarteten JSON-Daten besteht die positive Prüfung nicht.
Direkte PostgreSQL-Verbindungen von nicht Azure Quelladressen werden blockiert, wenn keine andere Regel sie zulässt. Azure-Origin-Clients mit gültigen Datenbankanmeldeinformationen können weiterhin eine Verbindung herstellen. Die HTTPS-API der Anwendung bleibt öffentlich; diese Prüfungen stellen keine Isolation der Datenbank nur für die Anwendung her.