Zabezpečení síťového přístupu pro aplikace Function Apps
Aplikace funkcí s nakonfigurovaným ověřováním řídí, kdo ho může volat, ale koncový bod funkce je stále dostupný z jakékoli síťové cesty včetně veřejného internetu. Síťové ovládací prvky přidávají samostatnou vrstvu vynucení: omezení síťových cest, které mohou vůbec dosáhnout funkce, a řízení síťových cest, které funkce používá pro vlastní odchozí volání. Ověřování a izolace sítě jsou nezávislé a doplňkové. Obojí musí být zavedeno, aby byla zajištěna obhajitelná úroveň zabezpečení.
Omezení příchozího přístupu pomocí seznamů povolených IP adres
Omezení přístupu umožňují definovat seznam pravidel povolení a zamítnutí podle priority na základě zdrojové IP adresy, rozsahu CIDR (Classless Inter-Domain Route) nebo Azure značky služby. Pokud existuje jakékoli explicitní pravidlo, implicitní odepření platí pro veškerý provoz, který se neshoduje – pravidlo zamítnutí nemusíte přidávat ručně.
Pro aplikace funkcí, které by měly přijímat pouze příchozí volání z konkrétních Azure služeb, poskytují pravidla značek služeb čisté řešení. Pokud chcete například přijímat volání webhooku pouze z Azure Event Grid, přidejte pravidlo, které povoluje značku služby AzureEventGrid a odepřít veškerý ostatní provoz. Značka služby pokrývá celý rozsah IP adres používaných službou Azure, takže nemusíte spravovat jednotlivé rozsahy IP adres pro služby, které používají dynamické fondy adres.
Omezení přístupu jsou k dispozici ve všech plánech hostování aplikací Function App, včetně plánů Consumption, Flex Consumption, Elastic Premium a Dedicated.
Tip
Nakonfigurujte omezení přístupu tak, aby ve výchozím nastavení odepřela veškerý provoz, a před nasazením do produkčního prostředí přidejte explicitní pravidla povolení pro známé zdroje. Začít s modelem „vše zakázáno“ se snáze audituje než sestavovat seznam blokovaných položek při implicitním povolení všeho.
Nasazení privátního koncového bodu pro příchozí přístup
Pokud provoz aplikace Function App nemá nikdy procházet přes veřejný internet, privátní koncový bod veřejný koncový bod zcela eliminuje. Privátní koncový bod přiřadí aplikaci Function App privátní IP adresu ve vaší virtuální síti (virtuální síti). Veškerý příchozí provoz dorazí přes tuto privátní IP adresu – externí volající se z internetu nedostanou k adrese URL funkce, protože neexistuje žádná veřejná trasa.
Privátní koncové body pro aplikace funkcí se podporují v plánech hostování Flex Consumption, Elastic Premium a Dedicated (App Service). Plán Standard Consumption nepodporuje privátní koncové body.
Po nakonfigurování privátního koncového bodu přeloží volající v rámci virtuální sítě (včetně dalších služeb Azure připojených ke stejné síti) název hostitele funkce na privátní IP adresu. Tento překlad názvů vyžaduje privátní zóny Azure DNS. Pokud je vaše funkce back-endem pro Azure API Management nebo application Gateway, tyto prostředky se připojují k aplikaci funkcí prostřednictvím privátního koncového bodu místo veřejné adresy URL a udržují veškerý provoz v páteřní síti Azure.
Important
Po vytvoření privátního koncového bodu pro aplikaci funkcí zakažte přístup k veřejné síti, abyste zajistili, že veškerý příchozí provoz prochází jenom přes privátní koncový bod. Ponechání veřejného přístupu zapnutého, pokud současně existuje privátní koncový bod, vede k rozdělenému síťovému uspořádání, které se obtížně audituje.
Konfigurace integrace virtuální sítě pro odchozí provoz
Privátní koncové body řídí příchozí přístup – určují, co může přistupovat k aplikaci Function App. Integrace virtuální sítě řídí odchozí přístup – k čemu má aplikace Function App přístup. Jedná se o odlišné ovládací prvky a slouží k různým účelům.
Když je povolená integrace virtuální sítě, aplikace funkcí směruje odchozí síťová volání přes delegovanou podsíť ve vaší virtuální síti. Tato funkce umožňuje volat prostředky, které nejsou vystavené veřejnému internetu: účet Cosmos DB bez veřejného přístupu, účet úložiště uzamčený pro konkrétní podsítě virtuální sítě nebo privátní rozhraní REST API hostované na virtuálním počítači ve stejné síti.
Regionální integrace virtuálních sítí je dostupná v plánech Flex Consumption, Elastic Premium a Dedicated a je doporučenou konfigurací pro většinu scénářů. Aplikace funkcí a virtuální síť musí být ve stejné Azure oblasti. Integrace používá delegovanou podsíť – tuto podsíť nelze použít pro jiné prostředky, jako jsou virtuální počítače nebo privátní koncové body.
Important
Samotná integrace virtuální sítě nesměruje veškerý odchozí provoz přes virtuální síť. Ve výchozím nastavení se přes podsíť integrace směruje pouze provoz určený pro rozsahy privátních IP adres (RFC 1918). Pokud chcete vynutit veškerý odchozí provoz ( včetně volání veřejných internetových adres) prostřednictvím virtuální sítě, nastavte WEBSITE_VNET_ROUTE_ALL nastavení aplikace na 1hodnotu nebo povolte směrování veškerého provozu na obrazovce konfigurace integrace virtuální sítě.
Konfigurace CORS pro klienty založené na prohlížeči
Sdílení prostředků mezi různými zdroji (CORS) se používá, když webové aplikace spuštěné v prohlížeči přímo volají aplikace Function aktivované triggerem HTTP. Ve výchozím nastavení prohlížeče blokují požadavky z jiného původu. Azure Functions umožňuje nakonfigurovat, u kterých zdrojů je povoleno provádět tyto požadavky.
V produkčním prostředí zadejte konkrétně povolené zdroje, například https://contoso-retail.com. Nikdy nepoužívejte zástupný znak (*) v produkčním prostředí. Konfigurace CORS se zástupným znakem umožňuje libovolnému původu odesílat požadavky do vaší aplikace Function App, čímž se odstraní ochrana mezi zdroji, kterou CORS poskytuje klientům založeným na webovém prohlížeči.
Omezení CORS se vztahují pouze na klienty HTTP založené na prohlížeči. Volání mezi servery – z back-endových služeb, Azure služeb nebo nepovolených klientů HTTP – nejsou předmětem vynucení CORS. CORS je mechanismus zabezpečení prohlížeče, nikoli řízení přístupu na straně serveru.
Odkaz na tajné kódy služby Key Vault v nastavení aplikace
Nastavení aplikace v Azure Functions jsou jedním z nejběžnějších umístění, kde jsou připojovací řetězce a klíče rozhraní API uložené ve formátu prostého textu. Vzor odkazů na Key Vault nahrazuje hodnotu nastavení aplikace v prostém textu odkazem, který aplikace Function App vyhodnotí za běhu pomocí své spravované identity.
Syntaxe odkazu Key Vault v nastavení aplikace je:
@Microsoft.KeyVault(SecretUri=https://<vault-name>.vault.azure.net/secrets/<secret-name>/<version>)
Pokud identifikátor verze vynecháte, aplikace funkcí přeloží nejnovější verzi tajného kódu. To je užitečné pro tajné údaje, které se pravidelně obměňují – funkce načte aktualizovanou hodnotu do 24 hodin od obměny, bez nutnosti nového nasazení.
Použití referencí Key Vault:
- Povolte spravovanou identitu přiřazenou systémem pro Function App.
- Přiřaďte roli Key Vault Secrets User spravované identitě v Key Vault.
- Nahraďte v každém nastavení aplikace hodnotu ve formátu prostého textu referenční syntaxí
@Microsoft.KeyVault(...).
Aplikace Function App při spuštění vyhodnotí odkaz a vloží tajnou hodnotu jako hodnotu nastavení aplikace. Kód funkce čte nastavení pomocí Environment.GetEnvironmentVariable("SETTING_NAME") – stejné volání použité pro jakékoli jiné nastavení aplikace bez povědomí o referenční vrstvě Key Vault.
Note
Pokud je Key Vault nakonfigurovaná s omezeními sítě – privátním koncovým bodem nebo koncovými body služby virtuální sítě – aplikace funkcí potřebuje pro přístup k trezoru integraci virtuální sítě. Před přidáním odkazů na Key Vault do trezorů s omezeným přístupem k síti nakonfigurujte integraci virtuální sítě. Bez síťového přístupu k trezoru nemůže aplikace Function App tuto referenci vyhodnotit a její spuštění se nezdaří.