Ćwiczenie — ogranicz dostęp publicznej bazy danych do usług platformy Azure
W tej lekcji zastąp regułę zapory PostgreSQL, która zezwala na próby połączenia ze wszystkich publicznych adresów IPv4, wyjątkiem dla usług Azure. Baza danych zachowuje publiczny punkt końcowy dostępu. Wyjątek zezwala usługom i zasobom platformy Azure, w tym tej aplikacji Quarkus, na podejmowanie prób nawiązywania uwierzytelnionych połączeń; nie ogranicza dostępu do tej aplikacji ani środowiska usługi Azure Container Apps.
Kontynuuj w tej samej lokalnej powłoce Bash lub WSL w systemie Windows ze zmiennymi AZ_* z poprzednich ćwiczeń. Uruchom kontrole bazy danych z sieci publicznej innej niż Azure. Użyj Azure CLI 2.87.0 lub nowszej i nie uruchamiaj ponownie konfiguracji nazwy zasobu ani hasła.
Uzyskiwanie dostępu do serwera PostgreSQL przy użyciu interfejsu wiersza polecenia
Najpierw upewnij się, że możesz połączyć się z serwerem PostgreSQL z bieżącej sieci klienta:
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
Sprawdź, czy zapytanie zwraca utworzone wcześniej elementy to-do. Potwierdza to łączność z sieci źródłowej Twojej powłoki, a nie z każdej sieci klienckiej. Rozwiąż wszelkie błędy związane z zapytaniami przed zmianą zapory, aby mieć działający stan wyjściowy dla późniejszych testów.
Usuń regułę zapory ogniowej o zbyt dużych pozwoleniach
Po utworzeniu nowego serwera --public-access All PostgreSQL włączono publiczny punkt końcowy i utworzono jedną regułę zapory dla wszystkich publicznych adresów IPv4.
Note
Te polecenia zapory używają nazw parametrów wprowadzonych w Azure CLI 2.87.0: --server-name identyfikuje serwer i --name identyfikuje regułę zapory. Oddzielna az postgres flexible-server execute komenda nadal używa --name dla serwera. Aby uzyskać szczegółowe informacje o składni, zobacz dokumentację referencyjną polecenia zapory.
Napraw wszystkie nieudane polecenia zapory przed kontynuowaniem; odrzucone polecenie nie zmienia zapory. Wyświetl listę istniejących reguł na serwerze należącym do ćwiczenia:
az postgres flexible-server firewall-rule list \
--server-name "$AZ_POSTGRES_SERVER_NAME" \
--resource-group "$AZ_RESOURCE_GROUP" \
--output table
Znajdź regułę, której StartIpAddress to 0.0.0.0 i EndIpAddress to 255.255.255.255. Wygenerowana nazwa w kolumnie Name różni się. Ta reguła powinna być jedyną regułą na nowym serwerze używanym w tym module. Jeśli wynik się różni, upewnij się, że używasz serwera należącego do ćwiczenia i rozwiąż rozbieżność przed kontynuowaniem. Nie usuwaj niepowiązanych reguł z istniejącego lub udostępnionego serwera.
Ten zakres zezwala dowolnemu publicznemu adresowi źródłowemu IPv4 na próbę nawiązania połączenia z bazą danych. Klienci nadal potrzebują prawidłowych poświadczeń bazy danych PostgreSQL. Usuń tę regułę przed dodaniem wyjątku Azure-services w dalszej części ćwiczenia.
Aktualizacje zapory PostgreSQL mogą zacząć obowiązywać po maksymalnie pięciu minutach. Po każdej pomyślnej zmianie odczekaj chwilę przed sprawdzeniem łączności. Powtórz zapytanie CLI w nowym wywołaniu, aby przetestować nowe połączenie z bazą danych; żądanie HTTP do aplikacji jest oddzielnym sprawdzaniem na poziomie aplikacji.
W poniższym poleceniu zastąp <allow-all-rule-name> rzeczywistym Name reguły all-addresses, którą właśnie wymieniono. Usuń nawiasy kątowe, zachowaj znaki cudzysłowu i usuń tylko ową regułę:
az postgres flexible-server firewall-rule delete \
--server-name "$AZ_POSTGRES_SERVER_NAME" \
--resource-group "$AZ_RESOURCE_GROUP" \
--name "<allow-all-rule-name>" \
--yes
Po pomyślnym usunięciu ponownie wyświetl listę reguł:
az postgres flexible-server firewall-rule list \
--server-name "$AZ_POSTGRES_SERVER_NAME" \
--resource-group "$AZ_RESOURCE_GROUP" \
--output table
Pomyślne polecenie listy powinno teraz nie zwracać żadnych reguł. Jeśli polecenie zakończy się niepowodzeniem lub jakakolwiek reguła pozostanie, przed kontynuowaniem rozwiąż ten problem. Pusta lista potwierdza skonfigurowane reguły, ale nie potwierdza, że aktualizacja sieci została rozpropagowana.
Po umożliwieniu czasu propagacji utwórz nowe bezpośrednie połączenie z bazą danych, uruchamiając ponownie zapytanie:
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
Po wejściu usunięcia w życie nowe połączenie z bazą danych powinno zostać odrzucone. Tekst błędu zależy od klienta i ścieżki sieciowej; Na przykład usługa PostgreSQL może zgłosić, że nie ma pasującego pg_hba.conf wpisu. Nie oczekuj określonego komunikatu o przekroczeniu limitu czasu. Pomyślne zapytanie natychmiast po usunięciu może oznaczać, że zmiana zapory jest nadal propagowana.
Ten etap bez reguł celowo blokuje nowe połączenia z bazą danych z aplikacji po wprowadzeniu zmiany. Endpoint HTTPS aplikacji jest nadal publicznie dostępny. Aplikacja Quarkus używa połączeń bazy danych w puli, więc żądanie HTTP nie musi otwierać nowego połączenia z bazą danych. Sprawdź kod stanu HTTP i treść, ale nie używaj jednej natychmiastowej odpowiedzi jako potwierdzenia, że propagacja zapory została ukończona:
curl --include "https://$AZ_APP_URL/api/todos"
Opcja --include wyświetla nagłówki odpowiedzi HTTP oraz treść. Domyślnie program curl nie traktuje kodu stanu błędu HTTP jako błędu polecenia, więc sprawdź kod stanu zamiast polegać na kodzie zakończenia. Aby uzyskać szczegółowe informacje, zobacz podręcznik curl.
Dodaj wyjątek Azure-services
Dodaj wyjątek Azure-services, aby wdrożona aplikacja mogła ponownie nawiązać połączenie z bazą danych:
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"
Wartości 0.0.0.0 początkowe i końcowe umożliwiają zezwalanie na dostęp publiczny z dowolnej usługi Azure w Azure do tego serwera, zgodnie z opisem w Reguły zapory PostgreSQL. Jest to wyjątek zdefiniowany przez usługę w publicznym punkcie końcowym bazy danych, a nie zakres prywatnych adresów IP.
Important
Wyjątek zezwala również na próby nawiązania połączenia z zasobów platformy Azure w subskrypcjach innych klientów. Nie identyfikuje aplikacji Quarkus ani nie ogranicza dostępu do jednego środowiska, subskrypcji ani dzierżawcy. Klienci muszą nadal uwierzytelniać się. To ćwiczenie nie konfiguruje sieci prywatnej ani dostępu tylko do aplikacji.
Po pomyślnym utworzeniu ponownie wyświetl listę reguł:
az postgres flexible-server firewall-rule list \
--server-name "$AZ_POSTGRES_SERVER_NAME" \
--resource-group "$AZ_RESOURCE_GROUP" \
--output table
Jedyną regułą na tym nowym serwerze powinna być teraz Allow_Azure-services, z parametrami StartIpAddress i EndIpAddress ustawionymi na 0.0.0.0. Jeśli polecenie zakończy się niepowodzeniem lub reguły nie pasują do tego wyniku, rozwiąż rozbieżność przed przetestowaniem łączności. Poczekaj maksymalnie pięć minut na zastosowanie zmiany.
Weryfikowanie dostępu do bazy danych i aplikacji
Po odczekaniu czasu propagacji uruchom następujące polecenie w nowej sesji z lokalnego komputera programistycznego w sieci publicznej innej niż Azure. Użyj tych samych roboczych poświadczeń bazy danych co w początkowym zapytaniu. Połączenie z bazą danych powinno zostać odrzucone, gdy żadna inna reguła zapory nie zezwala na ten adres źródłowy.
Reguły zapory oceniają adres źródłowy, a nie to, czy klient jest Azure CLI. Nie używaj Azure Cloud Shell w tym teście negatywnym: wyjątek Azure-services może umożliwić jego połączenie. Pomyślne zapytanie z klienta hostowanego Azure z prawidłowymi poświadczeniami nie pokazuje, że aktualizacja zapory nie powiodła się.
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
Po odczekaniu, aż wyjątek Azure-services zacznie obowiązywać, pobierz elementy to-do za pośrednictwem wdrożonej aplikacji. Sprawdź kod HTTP 200 i tablicę JSON zawierającą utworzone wcześniej elementy to-do:
curl --include "https://$AZ_APP_URL/api/todos"
Jeśli nowo nawiązane połączenie z bazą danych nadal daje nieoczekiwany wynik po oknie propagacji, sprawdź rzeczywiste reguły zapory i sieć źródłową klienta przed zmianą poświadczeń. Odpowiedź aplikacji bez kodu odpowiedzi HTTP 200 i oczekiwanych danych JSON nie przechodzi pozytywnego sprawdzenia.
Połączenia direct PostgreSQL z adresów źródłowych innych niż Azure są blokowane, gdy nie zezwala na nie żadna inna reguła. Klienci pochodzący z platformy Azure z prawidłowymi poświadczeniami bazy danych nadal mogą się łączyć. Interfejs API HTTPS aplikacji pozostaje publiczny; te sprawdzenia nie ustanawiają izolacji bazy danych tylko dla aplikacji.