Skydda Azure Functions
På många sätt är planeringen för säker utveckling, distribution och drift av serverlösa funktioner ungefär densamma som för alla webbaserade program eller molnbaserade program. Azure App Service tillhandahåller värdinfrastrukturen för dina funktionsappar. Den här artikeln innehåller säkerhetsstrategier för att köra funktionskoden och hur App Service kan hjälpa dig att skydda dina funktioner.
Plattformskomponenterna i App Service, däribland virtuella Azure-datorer, lagring, nätverksanslutningar, webbramverk, hanterings- och integreringsfunktioner, är aktivt skyddade och förstärkta. App Service genomgår kontinuerligt kraftfulla efterlevnadskontroller för att se till att:
- Dina appresurser skyddas från de andra kundernas Azure-resurser.
- VM-instanser och runtime-programvara uppdateras regelbundet för att åtgärda nyligen identifierade sårbarheter.
- Kommunikation av hemligheter (till exempel anslutningssträng) mellan din app och andra Azure-resurser (till exempel SQL Database) finns kvar i Azure och går inte över några nätverksgränser. Hemligheter krypteras alltid när de lagras.
- All kommunikation via App Service-anslutningsfunktionerna, till exempel hybridanslutning, krypteras.
- Anslut med fjärrhanteringsverktyg som Azure PowerShell, Azure CLI, Azure SDK:er, REST-API:er krypteras alla.
- 24-timmars hothantering skyddar infrastrukturen och plattformen mot skadlig kod, distribuerad denial of service (DDoS), man-in-the-middle (MITM) och andra hot.
Mer information om infrastruktur- och plattformssäkerhet i Azure finns i Azure Trust Center.
En uppsättning säkerhetsrekommendationer som följer Microsofts prestandamått för molnsäkerhet finns i Azure Security Baseline för Azure Functions.
Säker åtgärd
Det här avsnittet beskriver hur du konfigurerar och kör funktionsappen så säkert som möjligt.
Defender för molnet
Defender för molnet integreras med din funktionsapp i portalen. Det ger kostnadsfritt en snabb utvärdering av potentiella konfigurationsrelaterade säkerhetsrisker. Funktionsappar som körs i en dedikerad plan kan också använda Defender för molnet förbättrade säkerhetsfunktioner till en extra kostnad. Mer information finns i Skydda dina Azure App Service-webbappar och API:er.
Logga och övervaka
Ett sätt att identifiera attacker är genom aktivitetsövervakning och loggningsanalys. Functions integreras med Application Insights för att samla in logg-, prestanda- och feldata för din funktionsapp. Application Insights identifierar automatiskt prestandaavvikelser och innehåller kraftfulla analysverktyg som hjälper dig att diagnostisera problem och förstå hur dina funktioner används. Mer information finns i Övervaka Azure Functions.
Functions integreras också med Azure Monitor-loggar så att du kan konsolidera funktionsapploggar med systemhändelser för enklare analys. Du kan använda diagnostikinställningar för att konfigurera direktexport av plattformsloggar och mått för dina funktioner till valfri mål, till exempel en Logs Analytics-arbetsyta. Mer information finns i Övervaka Azure Functions med Azure Monitor-loggar.
För hotidentifiering på företagsnivå och automatisering av svar kan du strömma dina loggar och händelser till en Logs Analytics-arbetsyta. Du kan sedan ansluta Microsoft Sentinel till den här arbetsytan. Mer information finns i Vad är Microsoft Sentinel.
Fler säkerhetsrekommendationer för observerbarhet finns i Azure-säkerhetsbaslinjen för Azure Functions.
Kräv HTTPS
Som standard kan klienter ansluta till funktionsslutpunkter med hjälp av både HTTP eller HTTPS. Du bör omdirigera HTTP till HTTPs eftersom HTTPS använder SSL/TLS-protokollet för att tillhandahålla en säker anslutning, som både är krypterad och autentiserad. Mer information finns i Framtvinga HTTPS.
När du behöver HTTPS bör du även kräva den senaste TLS-versionen. Mer information finns i Framtvinga TLS-versioner.
Mer information finns i Säkra anslutningar (TLS).
Funktionsåtkomstnycklar
Med Functions kan du använda nycklar för att göra det svårare att komma åt http-funktionsslutpunkterna under utvecklingen. Om inte HTTP-åtkomstnivån på en HTTP-utlöst funktion är inställd anonymouspå måste begäranden innehålla en API-åtkomstnyckel i begäran.
Även om nycklar är en standardsäkerhetsmekanism kanske du vill överväga andra alternativ för att skydda en HTTP-slutpunkt i produktion. Det är till exempel inte en bra idé att distribuera delad hemlighet i offentliga appar. Om funktionen anropas från en offentlig klient kan du överväga att implementera en annan säkerhetsmekanism. Mer information finns i Skydda en HTTP-slutpunkt i produktion.
När du förnyar funktionsnyckelvärdena måste du manuellt omdistribuera de uppdaterade nyckelvärdena till alla klienter som anropar funktionen.
Auktoriseringsomfång (funktionsnivå)
Det finns två åtkomstomfattningar för nycklar på funktionsnivå:
Funktion: Dessa nycklar gäller endast för de specifika funktioner som de definieras under. När de används som en API-nyckel tillåter dessa endast åtkomst till den funktionen.
Värd: Nycklar med ett värdomfång kan användas för att komma åt alla funktioner i funktionsappen. När de används som en API-nyckel tillåter dessa åtkomst till alla funktioner i funktionsappen.
Varje nyckel är namngiven som referens och det finns en standardnyckel (med namnet "standard") på funktions- och värdnivå. Funktionsnycklar har företräde framför värdnycklar. När två nycklar definieras med samma namn används alltid funktionsnyckeln.
Huvudnyckel (administratörsnivå)
Varje funktionsapp har också en värdnyckel på administratörsnivå med namnet _master. Förutom att ge åtkomst på värdnivå till alla funktioner i appen ger huvudnyckeln även administrativ åtkomst till REST-API:erna för körning. Det går inte att återkalla den här nyckeln. När du anger en åtkomstnivå för adminmåste begäranden använda huvudnyckeln. Alla andra nycklar resulterar i åtkomstfel.
Varning
På grund av de utökade behörigheterna i funktionsappen som har beviljats av huvudnyckeln bör du inte dela den här nyckeln med tredje part eller distribuera den i interna klientprogram. Var försiktig när du väljer administratörsåtkomstnivå.
Systemnyckel
Specifika tillägg kan kräva en systemhanterad nyckel för åtkomst till webhook-slutpunkter. Systemnycklar är utformade för tilläggsspecifika funktionsslutpunkter som anropas av interna komponenter. Event Grid-utlösaren kräver till exempel att prenumerationen använder en systemnyckel när du anropar utlösarslutpunkten. Durable Functions använder också systemnycklar för att anropa API:er för durable task-tillägget.
Omfånget för systemnycklar bestäms av tillägget, men det gäller vanligtvis för hela funktionsappen. Systemnycklar kan bara skapas med specifika tillägg och du kan inte uttryckligen ange deras värden. Precis som andra nycklar kan du generera ett nytt värde för nyckeln från portalen eller med hjälp av nyckel-API:erna.
Jämförelse av nycklar
I följande tabell jämförs användningarna för olika typer av åtkomstnycklar:
| Åtgärd | Omfång | Giltiga nycklar |
|---|---|---|
| Köra en funktion | Specifik funktion | Function |
| Köra en funktion | Alla funktioner | Funktion eller värd |
| Anropa en administratörsslutpunkt | Funktionsapp | Värd (endast huvud) |
| Anropa API:er för durable task-tillägget | Funktionsapp1 | System2 |
| Anropa en tilläggsspecifik Webhook (intern) | Funktionsapp1 | system2 |
1Omfång som bestäms av tillägget.
2Specifika namn som anges efter tillägg.
Mer information om åtkomstnycklar finns i artikeln HTTP-utlösarbindning.
Hemliga lagringsplatser
Som standard lagras nycklar i en Blob Storage-container i det konto som anges av inställningen AzureWebJobsStorage . Du kan använda inställningen AzureWebJobsSecretStorageType för att åsidosätta det här beteendet och lagra nycklar på en annan plats.
| Plats | Värde | Beskrivning |
|---|---|---|
| Andra lagringskonto | blob |
Lagrar nycklar i Blob Storage för ett annat lagringskonto, baserat på SAS-URL:en i AzureWebJobsSecretStorageSas. |
| Filsystem | files |
Nycklar sparas i filsystemet, vilket är standardinställningen i Functions v1.x. |
| Azure Key Vault | keyvault |
Nyckelvalvet som anges i AzureWebJobsSecretStorageKeyVaultUri används för att lagra nycklar. |
| Kubernetes-hemligheter | kubernetes |
Resursen som anges i AzureWebJobsKubernetesSecretName används för att lagra nycklar. Stöds endast när du kör Functions-körmiljön i Kubernetes. Azure Functions Core Tools genererar värdena automatiskt när de distribueras till Kubernetes. |
När du använder Key Vault för nyckellagring beror de appinställningar du behöver på den hanterade identitetstypen. Version 3.x av körmiljön för Functions stöder endast systemtilldelade hanterade identiteter.
| Inställningsnamn | Systemtilldelad | Användartilldelad | Appregistrering |
|---|---|---|---|
| AzureWebJobsSecretStorageKeyVaultUri | ✓ | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientId | X | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | ✓ |
| AzureWebJobsSecretStorageKeyVaultTenantId | X | X | ✓ |
Autentisering/auktorisering
Även om funktionsnycklar kan ge viss lindring för oönskad åtkomst är det enda sättet att skydda funktionsslutpunkterna genom att implementera positiv autentisering av klienter som har åtkomst till dina funktioner. Du kan sedan fatta auktoriseringsbeslut baserat på identitet.
Aktivera App Service-autentisering/auktorisering
Med App Service-plattformen kan du använda Microsoft Entra-ID och flera identitetsprovidrar från tredje part för att autentisera klienter. Du kan använda den här strategin för att implementera anpassade auktoriseringsregler för dina funktioner och du kan arbeta med användarinformation från funktionskoden. Mer information finns i Autentisering och auktorisering i Azure App Service och Arbeta med klientidentiteter.
Använda Azure API Management (APIM) för att autentisera begäranden
APIM innehåller en mängd olika API-säkerhetsalternativ för inkommande begäranden. Mer information finns i API Management-autentiseringsprinciper. Med APIM på plats kan du konfigurera funktionsappen så att den endast accepterar begäranden från IP-adressen för din APIM-instans. Mer information finns i BEGRÄNSNINGAR för IP-adresser.
Behörigheter
Precis som med alla program eller tjänster körs målet din funktionsapp med lägsta möjliga behörighet.
Behörigheter för användarhantering
Functions har stöd för inbyggd rollbaserad åtkomstkontroll i Azure (Azure RBAC). Azure-roller som stöds av Functions är deltagare, ägare och läsare.
Behörigheter gäller på funktionsappsnivå. Deltagarrollen krävs för att utföra de flesta funktionsaktiviteter på appnivå. Du behöver också rollen Deltagare tillsammans med behörigheten Övervakningsläsare för att kunna visa loggdata i Application Insights. Endast rollen Ägare kan ta bort en funktionsapp.
Ordna funktioner efter behörighet
Anslut ionssträngar och andra autentiseringsuppgifter som lagras i programinställningarna ger alla funktioner i funktionsappen samma uppsättning behörigheter i den associerade resursen. Överväg att minimera antalet funktioner med åtkomst till specifika autentiseringsuppgifter genom att flytta funktioner som inte använder dessa autentiseringsuppgifter till en separat funktionsapp. Du kan alltid använda tekniker som funktionslänkning för att skicka data mellan funktioner i olika funktionsappar.
Hanterade identiteter
Med en hanterad identitet från Microsoft Entra-ID kan din app enkelt komma åt andra Microsoft Entra-skyddade resurser, till exempel Azure Key Vault. Identiteten hanteras av Azure-plattformen och kräver inte att du etablerar eller roterar några hemligheter. Mer information om hanterade identiteter i Microsoft Entra-ID finns i Hanterade identiteter för Azure-resurser.
Ditt program kan beviljas två typer av identiteter:
- En systemtilldelad identitet är kopplad till ditt program och tas bort om appen tas bort. En app kan bara ha en systemtilldelad identitet.
- En användartilldelad identitet är en fristående Azure-resurs som kan tilldelas till din app. En app kan ha flera användartilldelade identiteter.
Hanterade identiteter kan användas i stället för hemligheter för anslutningar från vissa utlösare och bindningar. Se Identitetsbaserade anslutningar.
Mer information finns i Använda hanterade identiteter för App Service och Azure Functions.
Begränsa CORS-åtkomst
Resursdelning mellan ursprung (CORS) är ett sätt att tillåta webbappar som körs i en annan domän att göra begäranden till HTTP-utlösarslutpunkterna. App Service har inbyggt stöd för att ge nödvändiga CORS-huvuden i HTTP-begäranden. CORS-regler definieras på funktionsappsnivå.
Det är frestande att använda ett jokertecken som gör att alla webbplatser kan komma åt din slutpunkt, men detta motverkar syftet med CORS, vilket är att förhindra skriptattacker mellan webbplatser. Lägg i stället till en separat CORS-post för domänen för varje webbapp som måste komma åt slutpunkten.
Hantera hemligheter
För att kunna ansluta till de olika tjänsterna och resurserna måste du köra koden, och funktionsappar måste kunna komma åt hemligheter, till exempel anslutningssträng och tjänstnycklar. I det här avsnittet beskrivs hur du lagrar hemligheter som krävs av dina funktioner.
Lagra aldrig hemligheter i funktionskoden.
Programinställningar
Som standard lagrar du anslutningssträng och hemligheter som används av funktionsappen och bindningar som programinställningar. Detta gör dessa autentiseringsuppgifter tillgängliga för både funktionskoden och de olika bindningar som används av funktionen. Namnet på programinställningen (nyckel) används för att hämta det faktiska värdet, som är hemligheten.
Till exempel kräver varje funktionsapp ett associerat lagringskonto, som används av körningen. Som standard lagras anslutningen till det här lagringskontot i en programinställning med namnet AzureWebJobsStorage.
Appinställningar och anslutningssträng lagras krypterade i Azure. De dekrypteras bara innan de matas in i appens processminne när appen startar. Krypteringsnycklarna roteras regelbundet. Om du föredrar att i stället hantera säker lagring av dina hemligheter bör appinställningen i stället vara referenser till Azure Key Vault.
Du kan också kryptera inställningar som standard i filen local.settings.json när du utvecklar funktioner på den lokala datorn. Mer information finns i Kryptera filen med lokala inställningar.
Key Vault-referenser
Även om programinställningarna räcker för de flesta funktioner kanske du vill dela samma hemligheter mellan flera tjänster. I det här fallet resulterar redundant lagring av hemligheter i fler potentiella sårbarheter. En säkrare metod är att använda en central hemlig lagringstjänst och använda referenser till den här tjänsten i stället för själva hemligheterna.
Azure Key Vault är en tjänst som tillhandahåller centraliserad hantering av hemligheter med fullständig kontroll över åtkomstprinciper och granskningshistorik. Du kan använda en Key Vault-referens i stället för en anslutningssträng eller nyckel i programinställningarna. Mer information finns i Använda Key Vault-referenser för App Service och Azure Functions.
Identitetsbaserade anslutningar
Identiteter kan användas i stället för hemligheter för att ansluta till vissa resurser. Detta har fördelen att inte kräva hantering av en hemlighet, och det ger mer detaljerad åtkomstkontroll och granskning.
När du skriver kod som skapar anslutningen till Azure-tjänster som stöder Microsoft Entra-autentisering kan du välja att använda en identitet i stället för en hemlighet eller anslutningssträng. Information om båda anslutningsmetoderna beskrivs i dokumentationen för varje tjänst.
Vissa Azure Functions-utlösare och bindningstillägg kan konfigureras med hjälp av en identitetsbaserad anslutning. I dag omfattar detta Azure Blob - och Azure Queue-tilläggen . Information om hur du konfigurerar dessa tillägg för att använda en identitet finns i Använda identitetsbaserade anslutningar i Azure Functions.
Ange användningskvoter
Överväg att ange en användningskvot för funktioner som körs i en förbrukningsplan. När du anger en daglig GB-sek-gräns för total körning av funktioner i funktionsappen stoppas körningen när gränsen nås. Detta kan potentiellt bidra till att minimera skadlig kod som kör dina funktioner. Information om hur du beräknar förbrukning för dina funktioner finns i Beräkna kostnader för förbrukningsplan.
Datavalidering
Utlösare och bindningar som används av dina funktioner ger ingen ytterligare dataverifiering. Koden måste verifiera alla data som tas emot från en utlösare eller indatabindning. Om en överordnad tjänst komprometteras vill du inte att ovaliderade indata flödar genom dina funktioner. Om din funktion till exempel lagrar data från en Azure Storage-kö i en relationsdatabas måste du verifiera data och parametrisera dina kommandon för att undvika SQL-inmatningsattacker.
Anta inte att data som kommer till din funktion redan har verifierats eller sanerats. Det är också en bra idé att kontrollera att data som skrivs till utdatabindningar är giltiga.
Hantera fel
Även om det verkar grundläggande är det viktigt att skriva bra felhantering i dina funktioner. Ohanterade fel bubblar upp till värden och hanteras av körningen. Olika bindningar hanterar bearbetning av fel på olika sätt. Mer information finns i Felhantering i Azure Functions.
Inaktivera fjärrfelsökning
Kontrollera att fjärrfelsökning är inaktiverat, förutom när du aktivt felsöker dina funktioner. Du kan inaktivera fjärrfelsökning på fliken Allmänt Inställningar i funktionsappen Konfiguration i portalen.
Begränsa CORS-åtkomst
Azure Functions stöder resursdelning mellan ursprung (CORS). CORS konfigureras i portalen och via Azure CLI. CORS-listan över tillåtna ursprung gäller på funktionsappsnivå. När CORS är aktiverat innehåller Access-Control-Allow-Origin svaren rubriken. Mer information finns i Cross-origin resource sharing.
Använd inte jokertecken i listan över tillåtna ursprung. Ange i stället de specifika domäner som du förväntar dig att få förfrågningar från.
Lagra data krypterade
Azure Storage krypterar alla data i ett lagringskonto i vila. För mer information, se Azure Storage-kryptering för vilande data.
Som standard krypteras data med Microsoft-hanterade nycklar. För ytterligare kontroll över krypteringsnycklar kan du ange kundhanterade nycklar som ska användas för kryptering av blob- och fildata. Dessa nycklar måste finnas i Azure Key Vault för att Functions ska kunna komma åt lagringskontot. Mer information finns i Kryptering i vila med kundhanterade nycklar.
Skydda relaterade resurser
En funktionsapp är ofta beroende av ytterligare resurser, så en del av att skydda appen är att skydda dessa externa resurser. De flesta funktionsappar är som minst beroende av Application Insights och Azure Storage. Mer information om hur du skyddar dessa resurser finns i Azure-säkerhetsbaslinjen för Azure Monitor och Azure-säkerhetsbaslinjen för Storage .
Viktigt!
Lagringskontot används för att lagra viktiga appdata, ibland inklusive själva programkoden. Du bör begränsa åtkomsten från andra appar och användare till lagringskontot.
Du bör också läsa vägledningen för alla resurstyper som din programlogik är beroende av, både som utlösare och bindningar och från funktionskoden.
Säker distribution
Azure Functions-verktyg för integrering gör det enkelt att publicera projektkod för lokala funktioner till Azure. Det är viktigt att förstå hur distributionen fungerar när du överväger säkerhet för en Azure Functions-topologi.
Autentiseringsuppgifter
App Service-distributioner kräver en uppsättning autentiseringsuppgifter för distribution. Dessa autentiseringsuppgifter för distribution används för att skydda dina funktionsappdistributioner. Autentiseringsuppgifter för distribution hanteras av App Service-plattformen och krypteras i vila.
Det finns två typer av autentiseringsuppgifter för distribution:
Autentiseringsuppgifter på användarnivå: en uppsättning autentiseringsuppgifter för hela Azure-kontot. Den kan användas för att distribuera till App Service för alla appar, i valfri prenumeration, som Azure-kontot har behörighet att komma åt. Det är standarduppsättningen som visas i portalens GUI (till exempel Översikt och Egenskaper för appens resurssida). När en användare beviljas appåtkomst via rollbaserad åtkomstkontroll (RBAC) eller coadmin-behörigheter kan användaren använda sina egna autentiseringsuppgifter på användarnivå tills åtkomsten har återkallats. Dela inte dessa autentiseringsuppgifter med andra Azure-användare.
Autentiseringsuppgifter på appnivå: en uppsättning autentiseringsuppgifter för varje app. Den kan endast användas för att distribuera till den appen. Autentiseringsuppgifterna för varje app genereras automatiskt när appen skapas. De kan inte konfigureras manuellt, men kan återställas när som helst. För att en användare ska beviljas åtkomst till autentiseringsuppgifter på appnivå via (RBAC) måste den användaren vara deltagare eller högre i appen (inklusive den inbyggda rollen Webbplatsdeltagare). Läsare får inte publicera och kan inte komma åt dessa autentiseringsuppgifter.
För närvarande stöds inte Key Vault för autentiseringsuppgifter för distribution. Mer information om hur du hanterar autentiseringsuppgifter för distribution finns i Konfigurera autentiseringsuppgifter för distribution för Azure App Service.
Inaktivera FTP
Som standard har varje funktionsapp en FTP-slutpunkt aktiverad. FTP-slutpunkten används med hjälp av autentiseringsuppgifter för distribution.
FTP rekommenderas inte för att distribuera funktionskoden. FTP-distributioner är manuella och kräver att du synkroniserar utlösare. Mer information finns i FTP-distribution.
När du inte planerar att använda FTP bör du inaktivera det i portalen. Om du väljer att använda FTP bör du framtvinga FTPS.
Skydda scm-slutpunkten
Varje funktionsapp har en motsvarande scm tjänstslutpunkt som används av Kudu-tjänsten (Advanced Tools) för distributioner och andra App Service-webbplatstillägg. SCM-slutpunkten för en funktionsapp är alltid en URL i formuläret https://<FUNCTION_APP_NAME.scm.azurewebsites.net>. När du använder nätverksisolering för att skydda dina funktioner måste du även ta hänsyn till den här slutpunkten.
Genom att ha en separat scm-slutpunkt kan du styra distributioner och andra avancerade verktygsfunktioner för funktionsappar som är isolerade eller körs i ett virtuellt nätverk. Scm-slutpunkten stöder både grundläggande autentisering (med autentiseringsuppgifter för distribution) och enkel inloggning med dina autentiseringsuppgifter för Azure-portalen. Mer information finns i Åtkomst till Kudu-tjänsten.
Kontinuerlig säkerhetsverifiering
Eftersom säkerhet måste beaktas i varje steg i utvecklingsprocessen är det klokt att även implementera säkerhetsvalidering i en kontinuerlig distributionsmiljö. Detta kallas ibland DevSecOps. Med Hjälp av Azure DevOps för din distributionspipeline kan du integrera validering i distributionsprocessen. Mer information finns i Lär dig hur du lägger till kontinuerlig säkerhetsverifiering i din CI/CD-pipeline.
Nätverkssäkerhet
Genom att begränsa nätverksåtkomsten till funktionsappen kan du styra vem som kan komma åt dina funktionsslutpunkter. Functions utnyttjar App Service-infrastrukturen för att göra det möjligt för dina funktioner att komma åt resurser utan att använda internetroutningsbara adresser eller för att begränsa Internetåtkomsten till en funktionsslutpunkt. Mer information om de här nätverksalternativen finns i Nätverksalternativ för Azure Functions.
Ange åtkomstbegränsningar
Med åtkomstbegränsningar kan du definiera listor med regler för att tillåta/neka för att styra trafiken till din app. Regler utvärderas i prioritetsordning. Om inga regler har definierats accepterar appen trafik från valfri adress. Mer information finns i Åtkomstbegränsningar för Azure App Service.
Skydda lagringskontot
När du skapar en funktionsapp måste du skapa eller länka till ett allmänt Azure Storage-konto som stöder blob-, kö- och tabelllagring. Du kan ersätta det här lagringskontot med ett som skyddas med tjänstslutpunkter eller privata slutpunkter. Mer information finns i Begränsa ett lagringskonto till ett virtuellt nätverk.
Åtkomst till privat plats
Azure privat slutpunkt är ett nätverksgränssnitt som ansluter dig privat och säkert till en tjänst som drivs av Azure Private Link. Privat slutpunkt använder en privat IP-adress från ditt virtuella nätverk, vilket effektivt tar in tjänsten i ditt virtuella nätverk.
Du kan använda privat slutpunkt för dina funktioner som finns i Premium- och App Service-abonnemangen.
Om du vill göra anrop till privata slutpunkter måste du se till att DNS-sökningarna matchar den privata slutpunkten. Du kan tillämpa det här beteendet på något av följande sätt:
- Integrera med privata Azure DNS-zoner. När det virtuella nätverket inte har någon anpassad DNS-server görs detta automatiskt.
- Hantera den privata slutpunkten på DEN DNS-server som används av din app. För att göra detta måste du känna till den privata slutpunktsadressen och sedan peka slutpunkten som du försöker nå till den adressen med hjälp av en A-post.
- Konfigurera din egen DNS-server så att den vidarebefordrar till privata Azure DNS-zoner.
Mer information finns i Använda privata slutpunkter för Web Apps.
Distribuera funktionsappen isolerat
Azure App Service-miljön (ASE) tillhandahåller en dedikerad värdmiljö där du kan köra dina funktioner. Med ASE kan du konfigurera en enskild klientdelsgateway som du kan använda för att autentisera alla inkommande begäranden. Mer information finns i Konfigurera en brandvägg för webbaserade program (WAF) för App Service-miljön.
Använda en gatewaytjänst
Med gatewaytjänster som Azure Application Gateway och Azure Front Door kan du konfigurera en brandvägg för webbprogram (WAF). WAF-regler används för att övervaka eller blockera identifierade attacker, vilket ger ett extra skydd för dina funktioner. För att konfigurera en WAF måste funktionsappen köras i en ASE eller använda privata slutpunkter (förhandsversion). Mer information finns i Använda privata slutpunkter.