Sdílet prostřednictvím

Zabezpečení azure Functions

  • Článek

Plánování zabezpečeného vývoje, nasazení a provozu bezserverových funkcí je v mnoha ohledech stejné jako u všech webových nebo cloudových aplikací hostovaných v cloudu. Aplikace Azure Service poskytuje hostingovou infrastrukturu pro vaše aplikace funkcí. Tento článek obsahuje strategie zabezpečení pro spouštění kódu funkce a způsob, jakým vám app Service může pomoct zabezpečit funkce.

Komponenty platformy služby App Service, včetně virtuálních počítačů Azure, úložiště, síťových připojení, webových architektur, funkcí správy a integrace, jsou aktivně zabezpečené a posílené. App Service průběžně prochází důslednými kontrolami dodržování předpisů, aby se zajistilo, že:

  • Prostředky vaší aplikace jsou zabezpečené z prostředků Azure ostatních zákazníků.
  • Instance virtuálních počítačů a software runtime se pravidelně aktualizují , aby se vyřešily nově zjištěná ohrožení zabezpečení.
  • Komunikace tajných kódů (například připojovací řetězec) mezi vaší aplikací a jinými prostředky Azure (jako je SQL Database) zůstává v Azure a nepřekračuje hranice sítě. Tajné kódy se při ukládání vždy šifrují.
  • Veškerá komunikace přes funkce připojení služby App Service, jako je například hybridní připojení, je šifrovaná.
  • Šifrují se připojení pomocí nástrojů pro vzdálenou správu, jako jsou Azure PowerShell, Azure CLI, sady Azure SDK, rozhraní REST API.
  • 24hodinová správa hrozeb chrání infrastrukturu a platformu před malwarem, distribuovaným odepřením služby (DDoS), man-in-the-middle (MITM) a dalšími hrozbami.

Další informace o zabezpečení infrastruktury a platformy v Azure najdete v Centru zabezpečení Azure.

Sadu doporučení zabezpečení, která se řídí srovnávacím testem zabezpečení cloudu Microsoftu, najdete v tématu Standardní hodnoty zabezpečení Azure pro Azure Functions.

Zabezpečená operace

Tato část vás provede co nejbezpečenější konfigurací a spuštěním aplikace funkcí.

Defender for Cloud

Defender for Cloud se integruje s vaší aplikací funkcí na portálu. Poskytuje zdarma rychlé posouzení potenciálních ohrožení zabezpečení souvisejících s konfigurací. Aplikace funkcí spuštěné ve vyhrazeném plánu můžou také využívat funkce rozšířeného zabezpečení v programu Defender for Cloud za další náklady. Další informace najdete v tématu Ochrana webových aplikací a rozhraní API služby Aplikace Azure.

Protokolování a monitorování

Jedním ze způsobů, jak detekovat útoky, je monitorování aktivit a protokolování analýzy. Funkce se integrují s Application Insights za účelem shromažďování dat protokolu, výkonu a chyb pro vaši aplikaci funkcí. Application Insights automaticky rozpozná anomálie výkonu a obsahuje výkonné analytické nástroje, které vám pomůžou diagnostikovat problémy a pochopit, jak se vaše funkce používají. Další informace najdete v tématu Monitorování azure Functions.

Funkce se také integruje s protokoly azure Monitoru, abyste mohli konsolidovat protokoly aplikací funkcí pomocí systémových událostí pro snadnější analýzu. Nastavení diagnostiky můžete použít ke konfiguraci streamování exportu protokolů platformy a metrik pro vaše funkce do zvoleného cíle, jako je pracovní prostor služby Logs Analytics. Další informace najdete v tématu Monitorování služby Azure Functions pomocí protokolů služby Azure Monitor.

Pro automatizaci hrozeb na podnikové úrovni streamujte protokoly a události do pracovního prostoru Služby Logs Analytics. Microsoft Sentinel pak můžete připojit k tomuto pracovnímu prostoru. Další informace najdete v tématu Co je Microsoft Sentinel.

Další doporučení zabezpečení pro pozorovatelnost najdete ve standardních hodnotách zabezpečení Azure pro Azure Functions.

Vyžadovat HTTPS

Ve výchozím nastavení se klienti můžou připojit ke koncovým bodům funkcí pomocí protokolu HTTP nebo HTTPS. Protokol HTTP byste měli přesměrovat na protokol HTTPs, protože protokol HTTPS používá protokol SSL/TLS k zajištění zabezpečeného připojení, které je šifrované i ověřené. Postup najdete v tématu Vynucení HTTPS.

Pokud potřebujete PROTOKOL HTTPS, měli byste také vyžadovat nejnovější verzi protokolu TLS. Postup najdete v tématu Vynucení verzí protokolu TLS.

Další informace najdete v tématu Zabezpečené připojení (TLS).

Přístupové klávesy funkce

Funkce umožňují používat klíče, které znesnadní přístup ke koncovým bodům funkce HTTP během vývoje. Pokud není anonymousnastavená úroveň přístupu HTTP u funkce aktivované protokolem HTTP, musí požadavky do požadavku obsahovat přístupový klíč rozhraní API.

Zatímco klíče poskytují výchozí mechanismus zabezpečení, můžete zvážit další možnosti zabezpečení koncového bodu HTTP v produkčním prostředí. Například není vhodné distribuovat sdílený tajný kód ve veřejných aplikacích. Pokud se vaše funkce volá z veřejného klienta, můžete zvážit implementaci jiného mechanismu zabezpečení. Další informace najdete v tématu Zabezpečení koncového bodu HTTP v produkčním prostředí.

Když obnovíte hodnoty klíče funkce, musíte aktualizované hodnoty klíče ručně distribuovat všem klientům, kteří vaši funkci volají.

Obory autorizace (úroveň funkce)

Pro klíče na úrovni funkce existují dva obory přístupu:

  • Funkce: Tyto klíče platí jenom pro konkrétní funkce, pod kterými jsou definované. Pokud se používá jako klíč rozhraní API, umožňují přístup pouze k této funkci.

  • Hostitel: Klíče s oborem hostitele je možné použít pro přístup ke všem funkcím v aplikaci funkcí. Pokud se používá jako klíč rozhraní API, umožňují přístup k libovolné funkci v aplikaci funkcí.

Každý klíč má název pro referenci a na úrovni funkce a hostitele je k dispozici výchozí klíč (s názvem "default"). Klíče funkcí mají přednost před klíči hostitele. Pokud jsou definovány dva klíče se stejným názvem, použije se vždy klíč funkce.

Hlavní klíč (úroveň správce)

Každá aplikace funkcí má také klíč hostitele na úrovni správce s názvem _master. Kromě poskytování přístupu na úrovni hostitele ke všem funkcím v aplikaci poskytuje hlavní klíč také přístup pro správu k rozhraním REST API modulu runtime. Tento klíč nelze odvolat. Když nastavíte úroveň adminpřístupu , požadavky musí používat hlavní klíč; všechny ostatní klíče způsobí selhání přístupu.

Upozornění

Vzhledem ke zvýšeným oprávněním v aplikaci funkcí udělených hlavním klíčem byste tento klíč neměli sdílet s třetími stranami ani ho distribuovat v nativních klientských aplikacích. Při výběru úrovně přístupu správce buďte opatrní.

Systémový klíč

Pro přístup ke koncovým bodům webhooku můžou konkrétní rozšíření vyžadovat klíč spravovaný systémem. Systémové klíče jsou navržené pro koncové body funkcí specifické pro rozšíření, které se volají interními komponentami. Například trigger Event Gridu vyžaduje, aby předplatné při volání koncového bodu triggeru používalo systémový klíč. Durable Functions také používá systémové klíče k volání rozhraní API rozšíření Durable Task.

Rozsah systémových klíčů je určen rozšířením, ale obecně platí pro celou aplikaci funkcí. Systémové klíče je možné vytvářet jenom konkrétními rozšířeními a nemůžete explicitně nastavit jejich hodnoty. Stejně jako jiné klíče můžete pro klíč vygenerovat novou hodnotu z portálu nebo pomocí rozhraní API klíčů.

Porovnání klíčů

Následující tabulka porovnává použití pro různé druhy přístupových klíčů:

Akce Obor Platné klávesy
Provedení funkce Konkrétní funkce Function
Provedení funkce Libovolná funkce Funkce nebo hostitel
Volání koncového bodu správce Aplikace funkcí Hostitel (pouze hlavní server)
Volání rozhraní API rozšíření Durable Task Aplikacefunkcí 1 Systém2
Volání webhooku specifického pro rozšíření (interní) Aplikacefunkcí 1 systém2

1Rozsah určený rozšířením.
2Konkrétní názvy nastavené rozšířením.

Další informace o přístupových klíčích najdete v článku o vazbě triggeru HTTP.

Úložiště tajných kódů

Ve výchozím nastavení jsou klíče uložené v kontejneru úložiště objektů blob v účtu poskytnutém nastavením AzureWebJobsStorage . Toto chování můžete přepsat nastavením AzureWebJobsSecretStorageType a uložit klíče do jiného umístění.

Umístění Hodnota Popis
Druhý účet úložiště blob Ukládá klíče do úložiště objektů blob jiného účtu úložiště na základě adresy URL SAS v AzureWebJobsSecretStorageSas.
Systém souborů files Klíče se uchovávají v systému souborů. Jde o výchozí možnost ve verzi Functions v1.x.
Azure Key Vault keyvault K ukládání klíčů se používá trezor klíčů nastavený v AzureWebJobsSecretStorageKeyVaultUri.
Tajné klíče Kubernetes kubernetes K ukládání klíčů se používá prostředek nastavený v AzureWebJobsKubernetesSecretName. Je to podporované jen při spouštění modulu runtime služby Functions v Kubernetes. Nástroje Azure Functions Core Tools tyto hodnoty generují automaticky při nasazování do Kubernetes.

Když pro úložiště klíčů používáte Key Vault, bude potřebné nastavení aplikace záležet na typu spravované identity. Modul runtime služby Functions verze 3.x podporuje jenom spravované identity přiřazené systémem.

Název nastavení Přiřazeno systémem Přiřazeno uživatelem Registrace aplikace
AzureWebJobsSecretStorageKeyVaultUri ✓ ✓ ✓
AzureWebJobsSecretStorageKeyVaultClientId X ✓ ✓
AzureWebJobsSecretStorageKeyVaultClientSecret X X ✓
AzureWebJobsSecretStorageKeyVaultTenantId X X ✓

Ověřování/autorizace

I když klíče funkcí můžou zajistit určité zmírnění nežádoucího přístupu, jediným způsobem, jak skutečně zabezpečit koncové body funkcí, je implementace pozitivního ověřování klientů, kteří přistupují k vašim funkcím. Pak můžete provádět rozhodnutí o autorizaci na základě identity.

Povolení ověřování/autorizace služby App Service

Platforma App Service umožňuje k ověřování klientů používat ID Microsoft Entra a několik zprostředkovatelů identity třetích stran. Tuto strategii můžete použít k implementaci vlastních autorizačních pravidel pro vaše funkce a můžete pracovat s informacemi o uživateli z kódu funkce. Další informace najdete v tématu Ověřování a autorizace ve službě Aplikace Azure Service a práce s identitami klientů.

Použití služby Azure API Management (APIM) k ověřování požadavků

APIM poskytuje různé možnosti zabezpečení rozhraní API pro příchozí požadavky. Další informace najdete v tématu Zásady ověřování služby API Management. Pomocí služby APIM můžete nakonfigurovat aplikaci funkcí tak, aby přijímala požadavky pouze z IP adresy vaší instance APIM. Další informace najdete v tématu Omezení IP adres.

Oprávnění

Stejně jako u jakékoli aplikace nebo služby je cílem spustit vaši aplikaci funkcí s nejnižšími možnými oprávněními.

Oprávnění pro správu uživatelů

Functions podporuje integrované řízení přístupu na základě role v Azure (Azure RBAC). Role Azure podporované funkcí jsou Přispěvatel, Vlastník a Čtenář.

Oprávnění jsou platná na úrovni aplikace funkcí. Role Přispěvatel je nutná k provádění většiny úloh na úrovni aplikace funkcí. K zobrazení dat protokolu v Application Insights potřebujete také roli Přispěvatel spolu s oprávněním Čtenář monitorování. Aplikaci funkcí může odstranit jenom role vlastníka.

Uspořádání funkcí podle oprávnění

Připojovací řetězce a další přihlašovací údaje uložené v nastavení aplikace poskytují všem funkcím v aplikaci funkcí stejnou sadu oprávnění v přidruženém prostředku. Zvažte minimalizaci počtu funkcí s přístupem ke konkrétním přihlašovacím údajům přesunutím funkcí, které tyto přihlašovací údaje nepoužívají do samostatné aplikace funkcí. K předávání dat mezi funkcemi v různých aplikacích funkcí můžete vždy použít techniky, jako je řetězení funkcí.

Spravované identity

Spravovaná identita z Microsoft Entra ID umožňuje vaší aplikaci snadný přístup k dalším prostředkům chráněným Microsoft Entra, jako je Azure Key Vault. Identitu spravuje platforma Azure a nevyžaduje, abyste zřizovali nebo rotovali tajné kódy. Další informace o spravovaných identitách v Microsoft Entra ID najdete v tématu Spravované identity pro prostředky Azure.

Vaší aplikaci je možné udělit dva typy identit:

  • Identita přiřazená systémem je svázaná s vaší aplikací a při odstranění aplikace se odstraní. Aplikace může mít pouze jednu identitu přiřazenou systémem.
  • Identita přiřazená uživatelem je samostatný prostředek Azure, který je možné přiřadit k vaší aplikaci. Aplikace může mít více identit přiřazených uživatelem.

Spravované identity je možné použít místo tajných kódů pro připojení z některých triggerů a vazeb. Viz Připojení založená na identitě.

Další informace najdete v tématu Použití spravovaných identit pro App Service a Azure Functions.

Omezení přístupu CORS

Sdílení prostředků mezi zdroji (CORS) je způsob, jak umožnit webovým aplikacím běžícím v jiné doméně provádět požadavky na koncové body triggeru HTTP. App Service poskytuje integrovanou podporu pro předání požadovaných hlaviček CORS v požadavcích HTTP. Pravidla CORS jsou definována na úrovni aplikace funkcí.

I když je lákavé použít zástupný znak, který umožňuje všem webům přístup k vašemu koncovému bodu, tento přístup porazí účel CORS, což je pomoct zabránit útokům na skriptování mezi weby. Místo toho přidejte samostatnou položku CORS pro doménu každé webové aplikace, která musí přistupovat k vašemu koncovému bodu.

Správa tajných kódů

Aby se mohly připojit k různým službám a prostředkům, které potřebují ke spuštění kódu, musí mít aplikace funkcí přístup k tajným kódům, jako jsou připojovací řetězec a klíče služby. Tato část popisuje, jak ukládat tajné kódy vyžadované vašimi funkcemi.

Nikdy neukládejte tajné kódy do kódu funkce.

Nastavení aplikace

Ve výchozím nastavení ukládáte připojovací řetězec a tajné kódy používané aplikací funkcí a vazby jako nastavení aplikace. Díky tomu jsou tyto přihlašovací údaje k dispozici pro kód funkce i různé vazby používané funkcí. Název nastavení aplikace (klíč) slouží k načtení skutečné hodnoty, což je tajný klíč.

Například každá aplikace funkcí vyžaduje přidružený účet úložiště, který používá modul runtime. Ve výchozím nastavení je připojení k tomuto účtu úložiště uloženo v nastavení aplikace s názvem AzureWebJobsStorage.

Nastavení aplikací a připojovací řetězec se ukládají zašifrované v Azure. Dešifrují se jenom před vložením do paměti procesu vaší aplikace při spuštění aplikace. Šifrovací klíče se pravidelně obměňují. Pokud místo toho dáváte přednost správě zabezpečeného úložiště tajných kódů, mělo by být nastavení aplikace odkazy na Azure Key Vault.

Nastavení můžete také ve výchozím nastavení zašifrovat v souboru local.settings.json při vývoji funkcí na místním počítači. Další informace najdete v tématu Šifrování místního souboru nastavení.

Reference ke službě Key Vault

I když nastavení aplikace stačí pro většinu funkcí, můžete chtít sdílet stejné tajné kódy napříč více službami. V takovém případě má redundantní úložiště tajných kódů za následek větší potenciální ohrožení zabezpečení. Bezpečnějším přístupem je centrální služba úložiště tajných kódů a místo samotných tajných kódů používejte odkazy na tuto službu.

Azure Key Vault je služba, která poskytuje centralizovanou správu tajných kódů s plnou kontrolou nad zásadami přístupu a historií auditu. Odkaz služby Key Vault můžete použít na místě připojovací řetězec nebo klíče v nastavení aplikace. Další informace najdete v tématu Použití referencí ke službě Key Vault pro App Service a Azure Functions.

Připojení založená na identitách

Identity se můžou používat místo tajných kódů pro připojení k některým prostředkům. To má výhodu, že nevyžaduje správu tajného kódu a poskytuje jemněji odstupňované řízení přístupu a auditování.

Při psaní kódu, který vytváří připojení ke službám Azure, které podporují ověřování Microsoft Entra, můžete místo tajného kódu nebo připojovací řetězec použít identitu. Podrobnosti o obou metodách připojení najdete v dokumentaci pro každou službu.

Některé triggery a rozšíření vazeb Azure Functions můžou být nakonfigurované pomocí připojení založeného na identitě. Dnes se jedná o rozšíření Azure Blob a Azure Queue . Informace o tom, jak tato rozšíření nakonfigurovat tak, aby používala identitu, najdete v tématu Použití připojení založených na identitě ve službě Azure Functions.

Nastavení kvót využití

Zvažte nastavení kvóty využití pro funkce spuštěné v plánu Consumption. Když nastavíte denní limit GB za sekundu na celkové spuštění funkcí ve vaší aplikaci funkcí, při dosažení limitu se provádění zastaví. To by mohlo potenciálně pomoct zmírnit riziko, že vaše funkce spouští škodlivý kód. Informace o odhadu spotřeby pro vaše funkce najdete v tématu Odhad nákladů na plán Consumption.

Ověření dat

Triggery a vazby používané funkcemi neposkytují žádné další ověření dat. Váš kód musí ověřit všechna data přijatá z triggeru nebo vstupní vazby. Pokud dojde k ohrožení zabezpečení upstreamové služby, nechcete, aby vaše funkce procházely nevalidovanými vstupy. Pokud například vaše funkce ukládá data z fronty Azure Storage do relační databáze, musíte data ověřit a parametrizovat příkazy, aby se zabránilo útokům prostřednictvím injektáže SQL.

Nepředpokládáme, že data přicházející do vaší funkce již byla ověřena nebo upravena. Je také vhodné ověřit, jestli jsou data zapsaná do výstupních vazeb platná.

Zpracování chyb

I když to vypadá jako základní, je důležité ve svých funkcích napsat dobré zpracování chyb. Neošetřené chyby se zobrazují na hostiteli a zpracovávají se modulem runtime. Různé vazby zpracovávají zpracování chyb odlišně. Další informace najdete v tématu Zpracování chyb ve službě Azure Functions.

Zakázání vzdáleného ladění

Ujistěte se, že je vzdálené ladění zakázané, s výjimkou případů, kdy aktivně ladíte funkce. Vzdálené ladění můžete zakázat na kartě Obecné nastavení aplikace funkcí na portálu.

Omezení přístupu CORS

Azure Functions podporuje sdílení prostředků mezi zdroji (CORS). CORS se konfiguruje na portálu a prostřednictvím Azure CLI. Seznam povolených zdrojů CORS se vztahuje na úrovni aplikace funkcí. S povoleným CORS zahrnují odpovědi hlavičku Access-Control-Allow-Origin . Další informace naleznete v tématu Sdílení prostředků různého původu.

Nepoužívejte v seznamu povolených původů zástupné cardy. Místo toho uveďte konkrétní domény, ze kterých očekáváte získání požadavků.

Ukládání šifrovaných dat

Azure Storage šifruje všechna neaktivní uložená data v účtu úložiště. Další informace najdete v tématu Šifrování služby Azure Storage pro neaktivní uložená data.

Ve výchozím nastavení se data šifrují pomocí klíčů spravovaných Microsoftem. Pro další kontrolu nad šifrovacími klíči můžete zadat klíče spravované zákazníkem, které se použijí k šifrování dat objektů blob a souborů. Tyto klíče musí být k dispozici ve službě Azure Key Vault, aby služba Functions mohla získat přístup k účtu úložiště. Další informace najdete v tématu Šifrování neaktivních uložených dat pomocí klíčů spravovaných zákazníkem.

Aplikace funkcí často závisí na dalších prostředcích, takže součástí zabezpečení aplikace je zabezpečení těchto externích prostředků. Minimálně většina aplikací funkcí zahrnuje závislost na Application Insights a Azure Storage. Pokyny k zabezpečení těchto prostředků najdete v standardních hodnotách zabezpečení Azure pro Azure Monitor a standardních hodnotách zabezpečení Azure pro službu Storage.

Důležité

Účet úložiště slouží k ukládání důležitých dat aplikace, někdy včetně samotného kódu aplikace. Přístup z jiných aplikací a uživatelů byste měli omezit na účet úložiště.

Měli byste se také podívat na pokyny pro všechny typy prostředků, na které vaše logika aplikace závisí, a to jak jako triggery, tak vazby i z kódu funkce.

Zabezpečené nasazení

Nástroje Azure Functions usnadňují publikování kódu projektu místních funkcí do Azure. Při zvažování zabezpečení topologie Azure Functions je důležité pochopit, jak funguje nasazení.

Přihlašovací údaje pro nasazení

Nasazení služby App Service vyžadují sadu přihlašovacích údajů nasazení. Tyto přihlašovací údaje pro nasazení se používají k zabezpečení nasazení aplikací funkcí. Přihlašovací údaje pro nasazení jsou spravované platformou služby App Service a jsou neaktivní neaktivní zašifrované.

Existují dva druhy přihlašovacích údajů nasazení:

  • Přihlašovací údaje na úrovni uživatele: jedna sada přihlašovacích údajů pro celý účet Azure. Dá se použít k nasazení do služby App Service pro libovolnou aplikaci v libovolném předplatném, ke kterému má účet Azure oprávnění pro přístup. Jedná se o výchozí sadu, která se zobrazí v grafickém uživatelském rozhraní portálu (například Přehleda Vlastnosti stránky prostředků aplikace). Když je uživateli udělen přístup k aplikaci prostřednictvím řízení přístupu na základě role (RBAC) nebo oprávnění spolusprávce, může tento uživatel používat své vlastní přihlašovací údaje na úrovni uživatele, dokud se přístup neodvolá. Tyto přihlašovací údaje nesdílejte s ostatními uživateli Azure.

  • Přihlašovací údaje na úrovni aplikace: jedna sada přihlašovacích údajů pro každou aplikaci. Dá se použít jenom k nasazení do této aplikace. Přihlašovací údaje pro každou aplikaci se automaticky vygenerují při vytváření aplikace. Není možné je konfigurovat ručně, ale můžete je kdykoli resetovat. Aby měl uživatel udělený přístup k přihlašovacím údajům na úrovni aplikace (RBAC), musí být v aplikaci přispěvatelem nebo vyšší (včetně předdefinované role Přispěvatel webu). Čtenáři nemůžou publikovat a nemají přístup k těmto přihlašovacím údajům.

V tuto chvíli se pro přihlašovací údaje nasazení nepodporuje služba Key Vault. Další informace o správě přihlašovacích údajů nasazení najdete v tématu Konfigurace přihlašovacích údajů nasazení pro službu Aplikace Azure Service.

Zakázání FTP

Ve výchozím nastavení má každá aplikace funkcí povolený koncový bod FTP. Koncový bod FTP se přistupuje pomocí přihlašovacích údajů nasazení.

Ftp se nedoporučuje pro nasazení kódu funkce. Nasazení FTP jsou ruční a vyžadují synchronizaci triggerů. Další informace najdete v tématu Nasazení FTP.

Pokud nechcete používat PROTOKOL FTP, měli byste ho zakázat na portálu. Pokud se rozhodnete používat protokol FTP, měli byste vynutit ftps.

Zabezpečení koncového bodu scm

Každá aplikace funkcí má odpovídající scm koncový bod služby, který používá služba Advanced Tools (Kudu) pro nasazení a další rozšíření webu služby App Service. Koncový bod scm pro aplikaci funkcí je vždy adresa URL ve formuláři https://<FUNCTION_APP_NAME.scm.azurewebsites.net>. Pokud k zabezpečení funkcí používáte izolaci sítě, musíte pro tento koncový bod také počítat.

Když máte samostatný koncový bod scm, můžete řídit nasazení a další pokročilé funkce nástrojů pro aplikaci funkcí, které jsou izolované nebo spuštěné ve virtuální síti. Koncový bod scm podporuje základní ověřování (pomocí přihlašovacích údajů pro nasazení) i jednotné přihlašování pomocí přihlašovacích údajů webu Azure Portal. Další informace najdete v tématu Přístup ke službě Kudu.

Průběžné ověřování zabezpečení

Vzhledem k tomu, že je potřeba zvážit zabezpečení v každém kroku procesu vývoje, je vhodné implementovat také ověřování zabezpečení v prostředí průběžného nasazování. Někdy se tomu říká DevSecOps. Pomocí Azure DevOps pro váš kanál nasazení můžete integrovat ověřování do procesu nasazení. Další informace najdete v tématu Přidání průběžného ověřování zabezpečení do kanálu CI/CD.

Zabezpečení sítě

Omezení síťového přístupu k vaší aplikaci funkcí umožňuje řídit, kdo má přístup k vašim koncovým bodům funkcí. Funkce využívají infrastrukturu služby App Service, která umožňuje vašim funkcím přístup k prostředkům bez použití internetových směrovatelných adres nebo omezení přístupu k internetu ke koncovému bodu funkce. Další informace o těchtomožnostch

Nastavení omezení přístupu

Omezení přístupu umožňují definovat seznamy pravidel povolení a zamítnutí pro řízení provozu do vaší aplikace. Pravidla se vyhodnocují v pořadí priority. Pokud nejsou definovaná žádná pravidla, aplikace přijme provoz z libovolné adresy. Další informace najdete v tématu Aplikace Azure Omezení přístupu ke službě.

Zabezpečení účtu úložiště

Když vytváříte aplikaci funkcí, musíte vytvořit nebo propojit účet Azure Storage pro obecné účely, který podporuje službu Blob, Queue a Table Storage. Tento účet úložiště můžete nahradit účtem, který je zabezpečený pomocí koncových bodů služby nebo privátních koncových bodů. Další informace najdete v části Omezení účtu úložiště na virtuální síť.

Privátní přístup k webu

Služba Azure Private Endpoint je síťové rozhraní, které umožňuje soukromé a bezpečné připojení ke službě, která používá technologii Azure Private Link. Privátní koncový bod používá privátní IP adresu vaší virtuální sítě a tím vlastně přináší službu do vaší virtuální sítě.

Privátní koncový bod můžete použít pro funkce hostované v plánech Premium a App Service .

Pokud chcete volat privátní koncové body, musíte se ujistit, že se vyhledávání DNS přeloží na privátní koncový bod. Toto chování můžete vynutit jedním z následujících způsobů:

  • Integrace s privátními zónami Azure DNS Pokud vaše virtuální síť nemá vlastní server DNS, provede se to automaticky.
  • Spravujte privátní koncový bod na serveru DNS používaném vaší aplikací. K tomu musíte znát adresu privátního koncového bodu a pak nasměrovat koncový bod, ke kterému se pokoušíte připojit pomocí záznamu A.
  • Nakonfigurujte vlastní server DNS tak, aby předával privátní zóny Azure DNS.

Další informace najdete v tématu Použití privátních koncových bodů pro Web Apps.

Nasazení aplikace funkcí izolovaně

Aplikace Azure Service Environment (ASE) poskytuje vyhrazené hostitelské prostředí, ve kterém můžete spouštět funkce. Služba ASE umožňuje nakonfigurovat jednu front-endovou bránu, kterou můžete použít k ověřování všech příchozích požadavků. Další informace najdete v tématu Konfigurace firewallu webových aplikací (WAF) pro službu App Service Environment.

Použití služby brány

Služby brány, jako je Aplikace Azure lication Gateway a Azure Front Door, umožňují nastavit firewall webových aplikací (WAF). Pravidla WAF slouží k monitorování nebo blokování zjištěných útoků, které poskytují další vrstvu ochrany vašich funkcí. Pokud chcete nastavit WAF, musí vaše aplikace funkcí běžet v ASE nebo používat privátní koncové body (Preview). Další informace najdete v tématu Použití privátních koncových bodů.

Další kroky