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.
- Verbinding maken 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 bij het diagnosticeren van problemen en om 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 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.
HTTPS vereisen
Clients kunnen standaard verbinding maken met functie-eindpunten met behulp van ZOWEL HTTP als HTTPS. U moet HTTP omleiden naar HTTPs omdat HTTPS gebruikmaakt van het SSL/TLS-protocol 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 Functions kunt u sleutels gebruiken om tijdens de ontwikkeling moeilijker toegang te krijgen tot uw HTTP-functie-eindpunten. Tenzij het HTTP-toegangsniveau voor een door HTTP geactiveerde functie is ingesteld anonymousop, moeten aanvragen een API-toegangssleutel in de aanvraag bevatten.
Hoewel sleutels een standaardbeveiligingsmechanisme bieden, kunt u andere opties overwegen om een HTTP-eindpunt in productie te beveiligen. Het is bijvoorbeeld geen goede gewoonte om gedeeld geheim te distribueren in openbare apps. Als uw functie wordt aangeroepen vanuit een openbare client, kunt u overwegen een ander beveiligingsmechanisme te implementeren. Zie Een HTTP-eindpunt beveiligen in productie voor meer informatie.
Wanneer u uw functiesleutelwaarden vernieuwt, moet u de bijgewerkte sleutelwaarden handmatig distribueren naar alle clients die uw functie aanroepen.
Autorisatiebereiken (functieniveau)
Er zijn twee toegangsbereiken voor sleutels op functieniveau:
Functie: Deze sleutels zijn alleen van toepassing op de specifieke functies waaronder ze zijn gedefinieerd. Wanneer deze worden gebruikt als API-sleutel, staan deze alleen toegang tot die functie toe.
Host: Sleutels met een hostbereik kunnen worden gebruikt voor toegang tot alle functies in de functie-app. Wanneer deze worden gebruikt als API-sleutel, hebben deze toegang tot elke functie in de functie-app.
Elke sleutel wordt genoemd als referentie en er is een standaardsleutel (met de naam 'standaard') op het functie- en hostniveau. Functietoetsen hebben voorrang op hostsleutels. Wanneer twee sleutels met dezelfde naam worden gedefinieerd, wordt de functiesleutel altijd gebruikt.
Hoofdsleutel (beheerniveau)
Elke functie-app heeft ook een hostsleutel op beheerniveau met de naam _master. Naast het bieden van toegang op hostniveau tot alle functies in de app, biedt de hoofdsleutel ook beheerderstoegang tot de RUNTIME REST API's. Deze sleutel kan niet worden ingetrokken. Wanneer u een toegangsniveau instelt admin, moeten aanvragen de hoofdsleutel gebruiken. Elke andere sleutel resulteert in toegangsfouten.
Let op
Vanwege de verhoogde machtigingen in uw functie-app die zijn verleend door de hoofdsleutel, moet u deze sleutel niet delen met derden of distribueren in systeemeigen clienttoepassingen. Wees voorzichtig bij het kiezen van het beheerderstoegangsniveau.
Systeemsleutel
Voor specifieke extensies is mogelijk een door het systeem beheerde sleutel vereist voor toegang tot webhook-eindpunten. Systeemsleutels zijn ontworpen voor extensiespecifieke functie-eindpunten die worden aangeroepen door interne onderdelen. De Event Grid-trigger vereist bijvoorbeeld dat het abonnement een systeemsleutel gebruikt bij het aanroepen van het triggereindpunt. Durable Functions maakt ook gebruik van systeemsleutels om API's voor durable task-extensie aan te roepen.
Het bereik van systeemsleutels wordt bepaald door de extensie, maar is over het algemeen van toepassing op de hele functie-app. Systeemsleutels kunnen alleen worden gemaakt door specifieke extensies en u kunt hun waarden niet expliciet instellen. Net als andere sleutels kunt u een nieuwe waarde genereren voor de sleutel vanuit de portal of met behulp van de sleutel-API's.
Vergelijking van sleutels
In de volgende tabel worden de toepassingen voor verschillende soorten toegangssleutels vergeleken:
| Actie | Bereik | Geldige toetsen |
|---|---|---|
| Een functie uitvoeren | Specifieke functie | Functie |
| Een functie uitvoeren | Elke functie | Functie of host |
| Een beheereindpunt aanroepen | Functie-app | Host (alleen hoofd) |
| Duurzame taakextensie-API's aanroepen | Functie-app1 | Systeem2 |
| Een extensiespecifieke webhook aanroepen (intern) | Functie-app1 | systeem2 |
1Bereik bepaald door de extensie.
2Specifieke namen die per extensie zijn ingesteld.
Zie het artikel over http-triggerbinding voor meer informatie over toegangssleutels.
Geheime opslagplaatsen
Sleutels worden standaard opgeslagen in een Blob Storage-container in het account dat door de AzureWebJobsStorage instelling wordt geleverd. U kunt de instelling AzureWebJobsSecretStorageType gebruiken om dit gedrag te overschrijven en sleutels op een andere locatie op te slaan.
| Locatie | Waarde | Beschrijving |
|---|---|---|
| Tweede opslagaccount | blob |
Slaat sleutels op in Blob Storage van een ander opslagaccount, op basis van de SAS-URL in AzureWebJobsSecretStorageSas. |
| Bestandssysteem | files |
Sleutels blijven behouden in het bestandssysteem. Dit is de standaardinstelling in Functions v1.x. |
| Azure Key Vault | keyvault |
De sleutelkluis die is ingesteld in AzureWebJobsSecretStorageKeyVaultUri wordt gebruikt om sleutels op te slaan. |
| Kubernetes Secrets | kubernetes |
De resource-set in AzureWebJobsKubernetesSecretName wordt gebruikt om sleutels op te slaan. Wordt alleen ondersteund bij het uitvoeren van de Functions-runtime in Kubernetes. De Azure Functions Core Tools genereert de waarden automatisch bij het implementeren in Kubernetes. |
Wanneer u Key Vault gebruikt voor sleutelopslag, zijn de app-instellingen die u nodig hebt, afhankelijk van het type beheerde identiteit. Functions runtime versie 3.x ondersteunt alleen door het systeem toegewezen beheerde identiteiten.
| Naam instelling | Door het systeem toegewezen | Door de gebruiker toegewezen | App-registratie |
|---|---|---|---|
| AzureWebJobsSecretStorageKeyVaultUri | ✓ | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientId | X | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | ✓ |
| AzureWebJobsSecretStorageKeyVaultTenantId | X | X | ✓ |
Verificatie/autorisatie
Hoewel functiesleutels 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.
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 diverse 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
Verbinding maken iontekenreeksen 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 uw toepassing en wordt verwijderd als uw 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.
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, moet de app-instelling in plaats daarvan verwijzen naar Azure Key Vault.
U kunt instellingen ook standaard versleutelen in het local.settings.json-bestand bij het 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 een centrale geheime opslagservice en verwijzingen naar deze service gebruiken 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-trigger- en bindingsextensies kunnen worden geconfigureerd met behulp van een op identiteit gebaseerde verbinding. Dit omvat tegenwoordig de Azure Blob - en Azure Queue-extensies . Zie How to use identity-based connections in Azure Functions (Op identiteit gebaseerde verbindingen gebruiken in Azure Functions) voor informatie over het configureren van deze extensies voor het gebruik van een identiteit.
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 som van 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 omhoog 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 Algemeen 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.
Gerelateerde resources beveiligen
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
Azure Functions-hulpprogramma's voor een integratie maken het eenvoudig om code van het lokale functieproject naar Azure te publiceren. 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 overeenkomstig 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 geavanceerde hulpprogrammafuncties 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 is beveiligd met service-eindpunten of privé-eindpunten. Zie Uw opslagaccount beperken tot een virtueel netwerk voor meer informatie.
Toegang tot privésite
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 (ASE) biedt een toegewezen hostingomgeving waarin u uw functies kunt uitvoeren. Met ASE 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.