Share via


Azure Functions beveiligen

Het plannen van veilige ontwikkeling, implementatie en werking van serverloze functies is op veel manieren hetzelfde als voor elke webtoepassing of in de cloud gehoste toepassing. Azure-app Service biedt de hostinginfrastructuur voor uw functie-apps. Dit artikel bevat beveiligingsstrategieën voor het uitvoeren van uw functiecode en hoe App Service u kan helpen uw functies te beveiligen.

De platformonderdelen van App Service, waaronder Azure-VM's, opslag, netwerkverbindingen, webframeworks, beheer- en integratiefuncties, worden actief beveiligd en beveiligd. App Service doorloopt doorlopend krachtige nalevingscontroles om ervoor te zorgen dat:

  • Uw app-resources worden beveiligd vanuit de Azure-resources van de andere klanten.
  • VM-exemplaren en runtimesoftware worden regelmatig bijgewerkt om nieuwe gedetecteerde beveiligingsproblemen op te pakken.
  • Communicatie van geheimen (zoals verbindingsreeks s) tussen uw app en andere Azure-resources (zoals SQL Database) blijft binnen Azure en overschrijdt geen netwerkgrenzen. Geheimen worden altijd versleuteld wanneer ze worden opgeslagen.
  • Alle communicatie via de App Service-connectiviteitsfuncties, zoals hybride verbinding, wordt versleuteld.
  • Verbindingen met hulpprogramma's voor extern beheer, zoals Azure PowerShell, Azure CLI, Azure SDK's, REST API's, worden allemaal versleuteld.
  • 24-uurs bedreigingsbeheer beschermt de infrastructuur en het platform tegen malware, gedistribueerde denial-of-service (DDoS), man-in-the-middle (MITM) en andere bedreigingen.

Zie Het Vertrouwenscentrum van Azure voor meer informatie over infrastructuur- en platformbeveiliging in Azure.

Zie Azure Security Baseline voor Azure Functions voor een set beveiligingsaanveling die de Microsoft-cloudbeveiligingsbenchmark volgt.

Beveiligde bewerking

In deze sectie wordt u begeleid bij het configureren en uitvoeren van uw functie-app zo veilig mogelijk.

Defender voor Cloud

Defender voor Cloud integreert met uw functie-app in de portal. Het biedt gratis een snelle evaluatie van mogelijke beveiligingsproblemen met betrekking tot configuratie. Functie-apps die in een speciaal abonnement worden uitgevoerd, kunnen ook gebruikmaken van de verbeterde beveiligingsfuncties van Defender voor Cloud voor extra kosten. Zie Uw Azure-app Service-web-apps en API's beveiligen voor meer informatie.

Logboeken en bewaking

Een manier om aanvallen te detecteren, is door middel van activiteitenbewaking en logboekregistratieanalyses. Functions kan worden geïntegreerd met Application Insights om logboek-, prestatie- en foutgegevens voor uw functie-app te verzamelen. Application Insights detecteert automatisch prestatieafwijkingen en bevat krachtige analysehulpprogramma's om u te helpen problemen vast te stellen en te begrijpen hoe uw functies worden gebruikt. Zie Azure Functions bewaken voor meer informatie.

Functies kunnen ook worden geïntegreerd met Azure Monitor-logboeken, zodat u functie-app-logboeken kunt samenvoegen met systeemevenementen voor eenvoudigere analyse. U kunt diagnostische instellingen gebruiken om de streaming-export van platformlogboeken en metrische gegevens voor uw functies te configureren naar de bestemming van uw keuze, zoals een Logs Analytics-werkruimte. Zie Azure Functions bewaken met Azure Monitor-logboeken voor meer informatie.

Voor automatisering van bedreigingsdetectie en -respons op ondernemingsniveau streamt u uw logboeken en gebeurtenissen naar een Logs Analytics-werkruimte. Vervolgens kunt u Microsoft Sentinel verbinden met deze werkruimte. Zie Wat is Microsoft Sentinel voor meer informatie.

Zie de Azure-beveiligingsbasislijn voor Azure Functions voor meer beveiligingsaan aanbevelingen voor waarneembaarheid.

HTTP-eindpunten beveiligen

HTTP-eindpunten die openbaar worden weergegeven, bieden een aanvalsvector voor kwaadwillende actoren. Wanneer u uw HTTP-eindpunten beveiligt, moet u een gelaagde beveiligingsbenadering gebruiken. Deze technieken kunnen worden gebruikt om het beveiligingsprobleem van openbaar blootgestelde HTTP-eindpunten te verminderen, gesorteerd van de meest eenvoudige naar de veiligste en beperkende:

HTTPS vereisen

Clients kunnen standaard verbinding maken met functie-eindpunten met behulp van HTTP of HTTPS. U moet HTTP omleiden naar HTTPS omdat HTTPS het SSL/TLS-protocol gebruikt om een beveiligde verbinding te bieden, die zowel versleuteld als geverifieerd is. Zie HTTPS afdwingen voor meer informatie.

Wanneer u HTTPS nodig hebt, moet u ook de nieuwste TLS-versie vereisen. Zie TLS-versies afdwingen voor meer informatie.

Zie Secure Connections (TLS) voor meer informatie.

Functietoegangssleutels

Met Functies kunt u sleutels gebruiken om het moeilijker te maken om toegang te krijgen tot uw functie-eindpunten. Tenzij het HTTP-toegangsniveau voor een door HTTP geactiveerde functie is ingesteld anonymousop, moeten aanvragen een toegangssleutel in de aanvraag bevatten. Zie Werken met toegangssleutels in Azure Functions voor meer informatie.

Hoewel toegangssleutels enige beperking kunnen bieden voor ongewenste toegang, is de enige manier om uw functie-eindpunten echt te beveiligen door positieve verificatie te implementeren van clients die toegang hebben tot uw functies. Vervolgens kunt u autorisatiebeslissingen nemen op basis van identiteit.

Voor het hoogste beveiligingsniveau kunt u ook de hele toepassingsarchitectuur in een virtueel netwerk beveiligen met behulp van privé-eindpunten of door geïsoleerd uit te voeren.

Beheereindpunten uitschakelen

Functie-apps kunnen beheereindpunten leveren onder de /admin route die kan worden gebruikt voor bewerkingen zoals het verkrijgen van hoststatusinformatie en het uitvoeren van test-aanroepen. Wanneer deze worden weergegeven, moeten aanvragen voor deze eindpunten de hoofdsleutel van de app bevatten. Beheerbewerkingen zijn ook beschikbaar via de Azure Resource Manager-APIMicrosoft.Web/sites, die Azure RBAC biedt. U kunt de /admin eindpunten uitschakelen door de functionsRuntimeAdminIsolationEnabled site-eigenschap in te stellen op true. Deze eigenschap kan niet worden ingesteld voor apps die worden uitgevoerd op de linux-verbruiks-SKU en kan niet worden ingesteld voor apps die worden uitgevoerd op versie 1.x van Azure Functions. Als u versie 1.x gebruikt, moet u eerst migreren naar versie 4.x.

App Service-verificatie/-autorisatie inschakelen

Met het App Service-platform kunt u Microsoft Entra ID en verschillende id-providers van derden gebruiken om clients te verifiëren. U kunt deze strategie gebruiken om aangepaste autorisatieregels voor uw functies te implementeren en u kunt werken met gebruikersgegevens uit uw functiecode. Zie Verificatie en autorisatie in Azure-app Service en werken met clientidentiteiten voor meer informatie.

Azure API Management (APIM) gebruiken om aanvragen te verifiëren

APIM biedt verschillende API-beveiligingsopties voor binnenkomende aanvragen. Zie API Management-verificatiebeleidsregels voor meer informatie. Met APIM kunt u uw functie-app zo configureren dat alleen aanvragen worden geaccepteerd vanaf het IP-adres van uw APIM-exemplaar. Zie IP-adresbeperkingen voor meer informatie.

Machtigingen

Net als bij elke toepassing of service is het doel om uw functie-app uit te voeren met de laagst mogelijke machtigingen.

Machtigingen voor gebruikersbeheer

Functions biedt ondersteuning voor ingebouwd op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). Azure-rollen die worden ondersteund door Functions zijn Inzender, Eigenaar en Lezer.

Machtigingen zijn effectief op het niveau van de functie-app. De rol Inzender is vereist om de meeste taken op app-niveau op functieniveau uit te voeren. U hebt ook de rol Inzender nodig, samen met de machtiging Lezer voor bewaking om logboekgegevens in Application Insights weer te geven. Alleen de rol Eigenaar kan een functie-app verwijderen.

Functies organiseren op bevoegdheid

Verbindingsreeksen en andere referenties die zijn opgeslagen in toepassingsinstellingen geven alle functies in de functie-app dezelfde set machtigingen in de bijbehorende resource. Overweeg het aantal functies met toegang tot specifieke referenties te minimaliseren door functies te verplaatsen die deze referenties niet gebruiken naar een afzonderlijke functie-app. U kunt altijd technieken zoals functieketens gebruiken om gegevens door te geven tussen functies in verschillende functie-apps.

Beheerde identiteiten

Met een beheerde identiteit van Microsoft Entra ID heeft uw app eenvoudig toegang tot andere met Microsoft Entra beveiligde resources, zoals Azure Key Vault. De identiteit wordt beheerd door het Azure-platform en u hoeft geen geheimen in te richten of te draaien. Zie Beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten in Microsoft Entra ID.

Aan uw toepassing kunnen twee typen identiteiten worden toegekend:

  • Een door het systeem toegewezen identiteit is gekoppeld aan de app en wordt verwijderd als de app wordt verwijderd. Een app kan slechts één door het systeem toegewezen identiteit hebben.
  • Een door de gebruiker toegewezen identiteit is een autonome Azure-resource die kan worden toegewezen aan uw app. Een app kan meerdere door de gebruiker toegewezen identiteiten hebben en één door de gebruiker toegewezen identiteit kan worden toegewezen aan meerdere Azure-resources, zoals twee App Service-apps.

Beheerde identiteiten kunnen worden gebruikt in plaats van geheimen voor verbindingen van sommige triggers en bindingen. Zie op identiteit gebaseerde verbindingen.

Zie Beheerde identiteiten gebruiken voor App Service en Azure Functions voor meer informatie.

CORS-toegang beperken

CorS (Cross-Origin Resource Sharing) is een manier om web-apps die in een ander domein worden uitgevoerd, toe te staan aanvragen te verzenden naar uw HTTP-triggereindpunten. App Service biedt ingebouwde ondersteuning voor het overhandigen van de vereiste CORS-headers in HTTP-aanvragen. CORS-regels worden gedefinieerd op het niveau van een functie-app.

Hoewel het verleidelijk is om een jokerteken te gebruiken waarmee alle sites toegang hebben tot uw eindpunt, is dit het doel van CORS, dat wil helpen bij het voorkomen van scriptaanvallen op meerdere sites. Voeg in plaats daarvan een afzonderlijke CORS-vermelding toe voor het domein van elke web-app die toegang moet hebben tot uw eindpunt.

Geheimen beheren

Om verbinding te kunnen maken met de verschillende services en resources die nodig zijn om uw code uit te voeren, moeten functie-apps toegang hebben tot geheimen, zoals verbindingsreeks s en servicesleutels. In deze sectie wordt beschreven hoe u geheimen opslaat die vereist zijn voor uw functies.

Sla nooit geheimen op in uw functiecode.

Toepassingsinstellingen

Standaard slaat u verbindingsreeks s en geheimen op die worden gebruikt door uw functie-app en bindingen als toepassingsinstellingen. Hierdoor zijn deze referenties beschikbaar voor zowel uw functiecode als de verschillende bindingen die door de functie worden gebruikt. De naam van de toepassingsinstelling (sleutel) wordt gebruikt om de werkelijke waarde op te halen. Dit is het geheim.

Voor elke functie-app is bijvoorbeeld een gekoppeld opslagaccount vereist dat wordt gebruikt door de runtime. Standaard wordt de verbinding met dit opslagaccount opgeslagen in een toepassingsinstelling met de naam AzureWebJobsStorage.

App-instellingen en verbindingsreeks s worden versleuteld opgeslagen in Azure. Ze worden alleen ontsleuteld voordat ze worden geïnjecteerd in het procesgeheugen van uw app wanneer de app wordt gestart. De versleutelingssleutels worden regelmatig geroteerd. Als u liever de beveiligde opslag van uw geheimen beheert, moeten de app-instellingen in plaats daarvan verwijzen naar Azure Key Vault-geheimen.

U kunt instellingen ook standaard versleutelen in het bestand bij het local.settings.json ontwikkelen van functies op uw lokale computer. Zie Het bestand met lokale instellingen versleutelen voor meer informatie.

Key Vault-verwijzingen

Hoewel toepassingsinstellingen voldoende zijn voor de meeste functies, wilt u mogelijk dezelfde geheimen delen in meerdere services. In dit geval leidt redundante opslag van geheimen tot meer potentiële beveiligingsproblemen. Een veiligere benadering is het gebruik van een centrale geheime opslagservice en het gebruik van verwijzingen naar deze service in plaats van de geheimen zelf.

Azure Key Vault is een service die gecentraliseerd geheimenbeheer biedt, met volledige controle over toegangsbeleid en controlegeschiedenis. U kunt een Key Vault-verwijzing gebruiken op de plaats van een verbindingsreeks of sleutel in uw toepassingsinstellingen. Zie Key Vault-verwijzingen gebruiken voor App Service en Azure Functions voor meer informatie.

Op identiteit gebaseerde verbindingen

Identiteiten kunnen worden gebruikt in plaats van geheimen om verbinding te maken met bepaalde resources. Dit heeft het voordeel dat het beheer van een geheim niet vereist is en het biedt nauwkeuriger toegangsbeheer en controle.

Wanneer u code schrijft waarmee de verbinding wordt gemaakt met Azure-services die Microsoft Entra-verificatie ondersteunen, kunt u ervoor kiezen om een identiteit te gebruiken in plaats van een geheim of verbindingsreeks. Details voor beide verbindingsmethoden worden behandeld in de documentatie voor elke service.

Sommige Azure Functions-bindingsextensies kunnen worden geconfigureerd voor toegang tot services met behulp van op identiteit gebaseerde verbindingen. Zie Een op identiteit gebaseerde verbinding configureren voor meer informatie.

Gebruiksquota instellen

Overweeg om een gebruiksquotum in te stellen voor functies die worden uitgevoerd in een verbruiksabonnement. Wanneer u een dagelijkse limiet voor GB per seconde instelt voor de totale uitvoering van functies in uw functie-app, wordt de uitvoering gestopt wanneer de limiet is bereikt. Dit kan helpen bij het beperken van schadelijke code die uw functies uitvoert. Zie Kosten van verbruiksabonnementen schatten voor meer informatie over het schatten van het verbruik voor uw functies.

Gegevensvalidatie

De triggers en bindingen die door uw functies worden gebruikt, bieden geen aanvullende gegevensvalidatie. Uw code moet alle gegevens valideren die zijn ontvangen van een trigger- of invoerbinding. Als een upstream-service is aangetast, wilt u geen niet-gevalideerde invoer die door uw functies stroomt. Als uw functie bijvoorbeeld gegevens opslaat uit een Azure Storage-wachtrij in een relationele database, moet u de gegevens valideren en uw opdrachten parameteriseren om SQL-injectieaanvallen te voorkomen.

Stel niet dat de gegevens die in uw functie binnenkomen, al zijn gevalideerd of opgeschoond. Het is ook een goed idee om te controleren of de gegevens die naar uitvoerbindingen worden geschreven, geldig zijn.

Afhandeling van fouten

Hoewel het eenvoudig lijkt, is het belangrijk om goede foutafhandeling in uw functies te schrijven. Niet-verwerkte fouten bellen naar de host en worden verwerkt door de runtime. Verschillende bindingen verwerken de verwerking van fouten anders. Zie Foutafhandeling van Azure Functions voor meer informatie.

Externe foutopsporing uitschakelen

Zorg ervoor dat externe foutopsporing is uitgeschakeld, behalve wanneer u actief fouten in uw functies opspoort. U kunt externe foutopsporing uitschakelen op het tabblad Algemene instellingen van de configuratie van uw functie-app in de portal.

CORS-toegang beperken

Azure Functions biedt ondersteuning voor cross-origin resource sharing (CORS). CORS wordt geconfigureerd in de portal en via de Azure CLI. De lijst met toegestane cors-origins is van toepassing op het niveau van de functie-app. Als CORS is ingeschakeld, bevatten antwoorden de Access-Control-Allow-Origin header. Zie voor meer informatie Cross-origin-resources delen.

Gebruik geen jokertekens in de lijst met toegestane origins. Vermeld in plaats daarvan de specifieke domeinen waaruit u verwacht aanvragen te ontvangen.

Versleutelde gegevens opslaan

Azure Storage versleutelt alle gegevens in een opslagaccount-at-rest. Zie Azure Storage-versleuteling voor data-at-rest voor meer informatie.

Standaard worden gegevens versleuteld met door Microsoft beheerde sleutels. Voor extra controle over versleutelingssleutels kunt u door de klant beheerde sleutels opgeven voor versleuteling van blob- en bestandsgegevens. Deze sleutels moeten aanwezig zijn in Azure Key Vault voor Functions om toegang te krijgen tot het opslagaccount. Zie Versleuteling-at-rest met behulp van door de klant beheerde sleutels voor meer informatie.

Een functie-app is vaak afhankelijk van aanvullende resources, dus een deel van het beveiligen van de app is het beveiligen van deze externe resources. De meeste functie-apps bevatten minimaal een afhankelijkheid van Application Insights en Azure Storage. Raadpleeg de Azure-beveiligingsbasislijn voor Azure Monitor en de Azure-beveiligingsbasislijn voor Opslag voor hulp bij het beveiligen van deze resources.

Belangrijk

Het opslagaccount wordt gebruikt voor het opslaan van belangrijke app-gegevens, soms inclusief de toepassingscode zelf. U moet de toegang van andere apps en gebruikers tot het opslagaccount beperken.

Raadpleeg ook de richtlijnen voor resourcetypen waarop uw toepassingslogica afhankelijk is, zowel als triggers en bindingen en vanuit uw functiecode.

Veilige implementatie

Dankzij de integratie van Hulpprogramma's van Azure Functions kunt u eenvoudig lokale functieprojectcode publiceren naar Azure. Het is belangrijk om te begrijpen hoe implementatie werkt bij het overwegen van beveiliging voor een Azure Functions-topologie.

Referenties voor implementatie

Voor App Service-implementaties is een set implementatiereferenties vereist. Deze implementatiereferenties worden gebruikt om uw implementaties van uw functie-app te beveiligen. Implementatiereferenties worden beheerd door het App Service-platform en worden in rust versleuteld.

Er zijn twee soorten implementatiereferenties:

  • Referenties op gebruikersniveau: één set referenties voor het hele Azure-account. Het kan worden gebruikt om te implementeren in App Service voor elke app, in elk abonnement, dat het Azure-account gemachtigd is voor toegang. Dit is de standaardset die wordt weergegeven in de portal-GUI (zoals het overzicht en de eigenschappen van de resourcepagina van de app). Wanneer een gebruiker app-toegang krijgt via op rollen gebaseerd toegangsbeheer (RBAC) of coadmin-machtigingen, kan die gebruiker hun eigen referenties op gebruikersniveau gebruiken totdat de toegang is ingetrokken. Deel deze referenties niet met andere Azure-gebruikers.

  • Referenties op app-niveau: één set referenties voor elke app. Het kan alleen worden gebruikt om in die app te implementeren. De referenties voor elke app worden automatisch gegenereerd bij het maken van de app. Ze kunnen niet handmatig worden geconfigureerd, maar kunnen op elk gewenst moment opnieuw worden ingesteld. Als een gebruiker toegang moet krijgen tot referenties op app-niveau via (RBAC), moet die gebruiker inzender of hoger zijn in de app (inclusief ingebouwde rol voor inzender voor websites). Lezers mogen deze referenties niet publiceren en hebben geen toegang tot deze referenties.

Op dit moment wordt Key Vault niet ondersteund voor implementatiereferenties. Zie Implementatiereferenties configureren voor Azure-app Service voor meer informatie over het beheren van implementatiereferenties.

FTP uitschakelen

Standaard is voor elke functie-app een FTP-eindpunt ingeschakeld. Het FTP-eindpunt wordt geopend met behulp van implementatiereferenties.

FTP wordt niet aanbevolen voor het implementeren van uw functiecode. FTP-implementaties zijn handmatig en vereisen dat u triggers synchroniseert. Zie FTP-implementatie voor meer informatie.

Wanneer u niet van plan bent FTP te gebruiken, moet u deze uitschakelen in de portal. Als u ervoor kiest FTP te gebruiken, moet u FTPS afdwingen.

Het scm eindpunt beveiligen

Elke functie-app heeft een bijbehorend scm service-eindpunt dat wordt gebruikt door de Kudu-service (Advanced Tools) voor implementaties en andere App Service-site-extensies. Het scm eindpunt voor een functie-app is altijd een URL in de vorm https://<FUNCTION_APP_NAME>.scm.azurewebsites.net. Wanneer u netwerkisolatie gebruikt om uw functies te beveiligen, moet u ook rekening houden met dit eindpunt.

Door een afzonderlijk scm eindpunt te hebben, kunt u implementaties en andere functies van Geavanceerde hulpprogramma's beheren voor functie-apps die zijn geïsoleerd of worden uitgevoerd in een virtueel netwerk. Het scm eindpunt ondersteunt zowel basisverificatie (met behulp van implementatiereferenties) als eenmalige aanmelding met uw Azure Portal-referenties. Zie Toegang tot de Kudu-service voor meer informatie.

Continue beveiligingsvalidatie

Omdat de beveiliging bij elke stap in het ontwikkelingsproces moet worden overwogen, is het zinvol om ook beveiligingsvalidaties in een continue implementatieomgeving te implementeren. Dit wordt ook wel DevSecOps genoemd. Met Azure DevOps voor uw implementatiepijplijn kunt u validatie integreren in het implementatieproces. Zie Meer informatie over het toevoegen van continue beveiligingsvalidatie aan uw CI/CD-pijplijn.

Netwerkbeveiliging

Door de netwerktoegang tot uw functie-app te beperken, kunt u bepalen wie toegang heeft tot uw functie-eindpunten. Functies maken gebruik van de App Service-infrastructuur om uw functies toegang te geven tot resources zonder internetrouteerbare adressen te gebruiken of om internettoegang tot een functie-eindpunt te beperken. Zie Azure Functions-netwerkopties voor meer informatie over deze netwerkopties.

Toegangsbeperkingen instellen

Met toegangsbeperkingen kunt u lijsten met regels voor toestaan/weigeren definiëren om verkeer naar uw app te beheren. Regels worden geëvalueerd in volgorde van prioriteit. Als er geen regels zijn gedefinieerd, accepteert uw app verkeer vanaf elk adres. Zie Azure-app Toegangsbeperkingen voor services voor meer informatie.

Het opslagaccount beveiligen

Wanneer u een functie-app maakt, moet u een Azure Storage-account voor algemeen gebruik maken of koppelen dat ondersteuning biedt voor Blob-, Queue- en Table-opslag. U kunt dit opslagaccount vervangen door een account dat wordt beveiligd door een virtueel netwerk met toegang die is ingeschakeld door service-eindpunten of privé-eindpunten. Zie Uw opslagaccount beperken tot een virtueel netwerk voor meer informatie.

Uw functie-app implementeren in een virtueel netwerk

Azure Private Endpoint is een netwerkinterface die u privé en veilig verbindt met een service die wordt ondersteund door Azure Private Link. Private Endpoint maakt gebruik van een privé-IP-adres van uw virtuele netwerk, waarbij de service effectief in uw virtuele netwerk wordt geplaatst.

U kunt een privé-eindpunt gebruiken voor uw functies die worden gehost in de Premium- en App Service-abonnementen.

Als u privé-eindpunten wilt aanroepen, moet u ervoor zorgen dat uw DNS-zoekopdrachten worden omgezet in het privé-eindpunt. U kunt dit gedrag op een van de volgende manieren afdwingen:

  • Integreren met privézones van Azure DNS. Wanneer uw virtuele netwerk geen aangepaste DNS-server heeft, wordt dit automatisch gedaan.
  • Beheer het privé-eindpunt in de DNS-server die door uw app wordt gebruikt. Hiervoor moet u het adres van het privé-eindpunt weten en vervolgens het eindpunt aanwijzen dat u naar dat adres probeert te bereiken met behulp van een A-record.
  • Configureer uw eigen DNS-server om door te sturen naar privézones van Azure DNS.

Zie voor meer informatie het gebruik van privé-eindpunten voor web-apps.

Uw functie-app in isolatie implementeren

Azure-app Service Environment biedt een toegewezen hostingomgeving waarin u uw functies kunt uitvoeren. Met deze omgevingen kunt u één front-endgateway configureren die u kunt gebruiken om alle binnenkomende aanvragen te verifiëren. Zie Een WaF (Web Application Firewall) configureren voor App Service Environment voor meer informatie.

Een gatewayservice gebruiken

Met gatewayservices, zoals Azure-toepassing Gateway en Azure Front Door, kunt u een Web Application Firewall (WAF) instellen. WAF-regels worden gebruikt voor het bewaken of blokkeren van gedetecteerde aanvallen, die een extra beveiligingslaag bieden voor uw functies. Als u een WAF wilt instellen, moet uw functie-app worden uitgevoerd in een ASE of met behulp van privé-eindpunten (preview). Zie Privé-eindpunten gebruiken voor meer informatie.

Volgende stappen