Sikker netværksadgang til Funktionsapps

  • 7 minutter

En Funktions-app med autentificering konfigureret kontrollerer, hvem der kan kalde den, men funktionsendepunktet er stadig tilgængeligt fra enhver netværkssti – inklusive det offentlige internet. Netværkskontroller tilføjer et separat håndhævelseslag: begrænser hvilke netværksstier der overhovedet kan nå funktionen, og kontrollerer hvilke netværksstier funktionen bruger til sine egne udgående opkald. Autentificering og netværksisolering er uafhængige og komplementære. Begge skal være på plads for at sikre en forsvarlig sikkerhedsholdning.

Begræns indgående adgang med IP-tilladelseslister

Adgangsbegrænsninger lader dig definere en prioriteret liste af tilladte og afviste regler baseret på kilde-IP-adresse, Classless Inter-Domain Route (CIDR)-område eller Azure servicetag. Når der findes en eksplicit regel, gælder en implicit afvist-alt for al trafik, der ikke matcher – du behøver ikke tilføje en nægte-regel manuelt.

For Funktions-apps, der kun bør acceptere indgående opkald fra specifikke Azure-tjenester, giver servicetag-reglerne en ren løsning. For eksempel, for kun at acceptere webhook-kald fra Azure Event Grid, tilføj en regel, der tillader servicetagget AzureEventGrid og afviser al anden trafik. Servicetagget dækker hele det område af IP-adresser, som den Azure-tjeneste bruger, så du behøver ikke administrere individuelle IP-områder for tjenester, der bruger dynamiske adressepuljer.

Adgangsbegrænsninger er tilgængelige på alle Funktionsapp-hostingplaner, herunder Consumption, Flex Consumption, Elastic Premium og Dedicated.

Tip

Konfigurer adgangsbegrænsninger til at nægte al trafik som standard, og tilføj eksplicitte tilladelsesregler for kendte kilder, før den udrulles til produktion. At starte med en afny-all-holdning er nemmere at revidere end at opbygge en blokliste mod en implicit allow-all.

Udrul et privat endpoint til indgående adgang

Når Function-app-trafik aldrig bør krydse det offentlige internet, fjerner et privat endepunkt det offentlige endepunkt helt. Et privat endpoint tildeler Funktionsappen en privat IP-adresse inden for dit virtuelle netværk (virtuelt netværk). Al indgående trafik ankommer via den private IP—eksterne opkaldere kan ikke nå funktions-URL'en fra internettet, fordi der ikke findes nogen offentlig rute.

Private endpoints for Function-apps understøttes i Flex Consumption, Elastic Premium og Dedicated (App Service) hostingplanerne. Den standard forbrugsplan understøtter ikke private endepunkter.

Når et privat endepunkt er konfigureret, ombestemmer kaldere inden for VNet'en – inklusive andre Azure-tjenester forbundet til det samme netværk – funktionens værtsnavn til den private IP-adresse. Denne navneopløsning kræver Azure DNS private zoner. Hvis din funktion er backend for Azure API Management eller en Application Gateway, forbinder disse ressourcer til Funktionsappen via det private endpoint i stedet for en offentlig URL, hvilket holder al trafik på Azure-backbone.

Vigtigt!

Efter at have oprettet et privat endepunkt til en Function-app, deaktiveres offentlig netværksadgang for at sikre, at al indgående trafik kun passerer gennem det private endepunkt. At lade offentlig adgang være aktiveret, mens et privat endepunkt eksisterer, skaber en split-path netværksstatus, som er svær at revidere.

Konfigurer virtuel netværksintegration for udgående trafik

Private endepunkter styrer indgående adgang—hvad der kan nå Funktionsappen. Virtuel netværksintegration styrer udgående adgang—hvad Funktions-appen kan nå. Disse er forskellige kontroller og tjener forskellige formål.

Med virtuel netværksintegration aktiveret dirigerer Funktionsappen sine udgående netværksopkald gennem et delegeret subnet i dit virtuelle netværk. Dette gør det muligt for funktionen at kalde ressourcer, der ikke er eksponeret til det offentlige internet: en Cosmos DB-konto uden offentlig adgang, en Storage-konto låst til specifikke virtuelle netværkssubnet, eller et privat REST API hostet på en VM i samme netværk.

Regional virtuel netværksintegration er tilgængelig i Flex Consumption, Elastic Premium og Dedicated planerne og anbefales til de fleste scenarier. Funktionsappen og det virtuelle netværk skal være i samme Azure-region. Integrationen bruger et delegeret subnet – det subnet kan ikke bruges til andre ressourcer såsom VM'er eller private endepunkter.

Vigtigt!

Virtuel netværksintegration alene ruter ikke al udgående trafik gennem det virtuelle netværk. Som standard går kun trafik, der er tiltænkt private IP-adresseområder (RFC 1918), gennem integrationssubnettet. For at tvinge al udgående trafik – inklusive opkald til offentlige internetadresser – gennem det virtuelle netværk, sæt applikationsindstillingen WEBSITE_VNET_ROUTE_ALL til 1, eller aktiver Rute al trafik i konfigurationsskærmen for integration af det virtuelle netværk.

Konfigurér CORS til browserbaserede klienter

Cross-origin resource sharing (CORS) gælder, når browserbaserede webapplikationer direkte kalder HTTP-udløste Funktionsapps. Som standard blokerer browsere cross-origin forespørgsler. Azure Functions lader dig konfigurere, hvilke origins der må lave disse forespørgsler.

I produktion angives eksplicitte tilladte oprindelser – for eksempel https://contoso-retail.com. Brug aldrig wildcard (*) i produktion. En wildcard CORS-konfiguration tillader enhver oprindelse at foretage anmodninger til din Funktions-app, hvilket fjerner den krydsoprindelsesbeskyttelse, som CORS giver til browserbaserede klienter.

CORS-begrænsninger gælder kun for browserbaserede HTTP-klienter. Server-til-server-kald—fra backend-tjenester, Azure-tjenester eller ikke-browser HTTP-klienter—er ikke underlagt CORS-håndhævelse. CORS er en browsersikkerhedsmekanisme, ikke en server-side adgangskontrol.

Referer til Key Vault-hemmeligheder i applikationsindstillinger

Applikationsindstillinger i Azure Functions er et af de mest almindelige steder, hvor forbindelsesstrenge og API-nøgler ender med at blive gemt i almindelig tekst. Key Vault-referencemønsteret erstatter en plain-text applikationsindstillingsværdi med en reference, som Funktions-appen løser under kørsel ved hjælp af sin administrerede identitet.

Syntaksen for en Key Vault-reference i en applikationsindstilling er:

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

Hvis du udelader versionsidentifizéiereren, løser Funktionsappen den nyeste version af hemmeligheden. Dette er nyttigt for hemmeligheder, der roterer regelmæssigt – funktionen opfanger den opdaterede værdi inden for 24 timer efter rotation, uden en genudrulning.

For at bruge Key Vault-referencer:

  1. Aktivér en systemtildelt administreret identitet i Funktionsappen.
  2. Tildel rollen Key Vault Secrets User til den administrerede identitet på Key Vault.
  3. Erstat klartekstværdien i hver applikationsindstilling med referencesyntaksen @Microsoft.KeyVault(...).

Funktionsappen løser referencen ved opstart og injicerer den hemmelige værdi som applikationsindstillingsværdien. Funktionskoden læser indstillingen ved hjælp af Environment.GetEnvironmentVariable("SETTING_NAME") – det samme kald, der bruges til enhver anden applikationsindstilling, uden kendskab til det Key Vault referencelag.

Bemærkning

Hvis Key Vault er konfigureret med netværksbegrænsninger – et privat endepunkt eller virtuelle netværksservice-endpoints – har Function-appen brug for virtuel netværksintegration for at nå vaulten. Konfigurer virtuel netværksintegration, før du tilføjer Key Vault-referencer til netværksbegrænsede vaults. Uden en netværkssti til vaulten kan Funktionsappen ikke løse referencen og starter ikke.