Bezpieczny dostęp sieciowy dla aplikacji funkcji

Aplikacja funkcji ze skonfigurowanym uwierzytelnianiem kontroluje, kto może go wywołać, ale punkt końcowy funkcji jest nadal dostępny z dowolnej ścieżki sieciowej — w tym z publicznego Internetu. Kontrolki sieci dodają oddzielną warstwę wymuszania: ograniczenie, które ścieżki sieciowe mogą dotrzeć do funkcji w ogóle, i kontrolowanie ścieżek sieci używanych przez funkcję na potrzeby własnych wywołań wychodzących. Uwierzytelnianie i izolacja sieci są niezależne i uzupełniające. Oba muszą być wdrożone, aby zapewnić odpowiedni poziom bezpieczeństwa.

Ograniczanie dostępu przychodzącego przy użyciu list dozwolonych adresów IP

Ograniczenia dostępu umożliwiają zdefiniowanie uporządkowanej priorytetowo listy reguł zezwalania i odmowy na podstawie źródłowego adresu IP, zakresu tras bezklasowych Inter-Domain (CIDR) lub tagu usługi Azure. Jeśli istnieje dowolna jawna reguła, niejawna reguła odmowy dotyczy całego ruchu, który nie jest zgodny — nie musisz ręcznie dodawać reguły odmowy.

W przypadku aplikacji funkcji, które powinny akceptować tylko wywołania przychodzące z określonych usług Azure, reguły tagów usług zapewniają czyste rozwiązanie. Na przykład aby akceptować wywołania webhooka tylko z usługi Azure Event Grid, dodaj regułę zezwalającą na tag usługi AzureEventGrid oraz odrzucającą cały pozostały ruch. Tag usługi obejmuje pełny zakres adresów IP używanych przez usługę Azure, więc nie trzeba zarządzać poszczególnymi zakresami adresów IP dla usług korzystających z pul adresów dynamicznych.

Ograniczenia dostępu są dostępne we wszystkich planach hostingu aplikacji Function App, w tym Consumption, Flex Consumption, Elastic Premium i Dedicated.

Wdrażanie prywatnego punktu końcowego na potrzeby dostępu przychodzącego

Jeśli ruch do aplikacji Function App nigdy nie powinien przechodzić przez publiczny internet, prywatny punkt końcowy całkowicie eliminuje publiczny punkt końcowy. Prywatny punkt końcowy przypisuje aplikacji Function App prywatny adres IP w obrębie sieci wirtualnej (sieci wirtualnej). Cały ruch przychodzący dociera przez ten prywatny adres IP — zewnętrzne osoby wywołujące nie mogą uzyskać dostępu do adresu URL funkcji z Internetu, ponieważ nie istnieje żadna trasa publiczna.

Prywatne punkty końcowe dla aplikacji Functions są obsługiwane w planach hostingu Flex Consumption, Elastic Premium i Dedicated (App Service). Standardowy plan Zużycie nie obsługuje prywatnych punktów końcowych.

Po skonfigurowaniu prywatnego punktu końcowego wywołujące w sieci wirtualnej — w tym inne usługi Azure połączone z tą samą siecią — rozpoznają nazwę hosta funkcji jako prywatny adres IP. To rozwiązywanie nazw wymaga prywatnych stref DNS platformy Azure. Jeśli funkcja jest zapleczem dla usługi Azure API Management lub usługi Application Gateway, te zasoby łączą się z aplikacją funkcji za pośrednictwem prywatnego punktu końcowego, a nie publicznego adresu URL, dzięki czemu cały ruch pozostaje w sieci szkieletowej Azure.

Konfigurowanie integracji sieci wirtualnej dla ruchu wychodzącego

Prywatne punkty końcowe kontrolują dostęp przychodzący — co może uzyskać dostęp do aplikacji funkcji. Integracja z siecią wirtualną kontroluje dostęp wychodzący — do czego może dotrzeć aplikacja funkcji. Są to odrębne mechanizmy kontroli i służą różnym celom.

Po włączeniu integracji z siecią wirtualną aplikacja funkcji kieruje wychodzący ruch sieciowy przez delegowaną podsieć w Twojej sieci wirtualnej. Dzięki temu funkcja może wywoływać zasoby, które nie są uwidocznione w publicznym Internecie: konto usługi Cosmos DB bez dostępu publicznego, konto magazynu zablokowane dla określonych podsieci sieci wirtualnej lub prywatny interfejs API REST hostowany na maszynie wirtualnej w tej samej sieci.

Regionalna integracja sieci wirtualnej jest dostępna w planach Flex Consumption, Elastic Premium i Dedicated oraz jest zalecaną konfiguracją dla większości scenariuszy. Aplikacja funkcji i sieć wirtualna muszą znajdować się w tym samym regionie Azure. Integracja korzysta z delegowanej podsieci — tej podsieci nie można używać w przypadku innych zasobów, takich jak maszyny wirtualne lub prywatne punkty końcowe.

Konfigurowanie mechanizmu CORS dla klientów opartych na przeglądarce

Współużytkowanie zasobów między źródłami (CORS) ma zastosowanie, gdy aplikacje internetowe oparte na przeglądarce wywołują bezpośrednio aplikacje funkcji wyzwalane przez protokół HTTP. Domyślnie przeglądarki blokują żądania między źródłami. Azure Functions umożliwia skonfigurowanie źródeł, które mogą wysyłać te żądania.

W środowisku produkcyjnym określ jawne dozwolone źródła — na przykład https://contoso-retail.com. Nigdy nie używaj symbolu wieloznakowego (*) w środowisku produkcyjnym. Konfiguracja mechanizmu CORS z symbolami wieloznacznymi umożliwia wszystkim źródłom wykonywanie żądań do aplikacji funkcji, co eliminuje ochronę między źródłami zapewnianą przez mechanizm CORS dla klientów opartych na przeglądarce.

Ograniczenia mechanizmu CORS dotyczą tylko klientów HTTP opartych na przeglądarce. Wywołania między serwerami — z usług backendowych, usług platformy Azure lub klientów HTTP niebędących przeglądarkami — nie podlegają egzekwowaniu mechanizmu CORS. MECHANIZM CORS to mechanizm zabezpieczeń przeglądarki, a nie kontrola dostępu po stronie serwera.

Odwołuj się do wpisów tajnych usługi Key Vault w ustawieniach aplikacji

Ustawienia aplikacji w Azure Functions są jedną z najczęstszych lokalizacji, w których parametry połączenia i klucze interfejsu API są przechowywane w postaci zwykłego tekstu. Wzorzec odwołania Key Vault zastępuje wartość ustawienia aplikacji w postaci zwykłego tekstu odwołaniem, które aplikacja funkcji rozpoznaje w czasie wykonywania przy użyciu tożsamości zarządzanej.

Składnia odwołania do usługi Key Vault w ustawieniu aplikacji jest następująca:

@Microsoft.KeyVault(SecretUri=https://<vault-name>.vault.azure.net/secrets/<secret-name>/<version>)

Jeśli pominiesz identyfikator wersji, aplikacja funkcji ustali najnowszą wersję klucza tajnego. Jest to przydatne w przypadku sekretów, które są regularnie rotowane — funkcja pobiera zaktualizowaną wartość w ciągu 24 godzin od rotacji, bez ponownego wdrożenia.

Aby użyć odwołań do usługi Key Vault:

1. Włącz tożsamość zarządzaną przypisaną przez system w aplikacji funkcji Function App.
2. Przypisz rolę Key Vault Secrets User do tożsamości zarządzanej w Key Vault.
3. Zastąp wartość zwykłego tekstu w każdym ustawieniu aplikacji składnią referencyjną @Microsoft.KeyVault(...).

Aplikacja funkcji Function rozwiązuje odwołanie podczas uruchamiania i wstrzykuje wartość klucza tajnego jako wartość ustawienia aplikacji. Kod funkcji odczytuje to ustawienie za pomocą Environment.GetEnvironmentVariable("SETTING_NAME") — czyli tego samego wywołania, które jest używane dla każdego innego ustawienia aplikacji, bez wiedzy o warstwie odwołań do usługi Key Vault.