Absichern von Azure Functions
In vielerlei Hinsicht ist die Planung einer sicheren Entwicklung, Bereitstellung und Ausführung serverloser Funktionen vergleichbar mit der Planung einer webbasierten oder in der Cloud gehosteten Anwendung. Azure App Service stellt die Hostinginfrastruktur für Ihre Funktions-Apps bereit. In diesem Artikel werden Sicherheitsstrategien für die Ausführung Ihres Funktionscodes vorgestellt. Außerdem erfahren Sie, wie App Service Ihnen helfen kann, Ihre Funktionen abzusichern.
Die Plattformkomponenten von App Service werden aktiv geschützt und gehärtet. Zu diesen Komponenten zählen unter anderem virtuelle Azure-Computer, Speicher, Netzwerkverbindungen und Webframeworks sowie Verwaltungs- und Integrationsfeatures. Die Konformität von App Service wird kontinuierlich und streng geprüft, um Folgendes zu gewährleisten:
- Ihre App-Ressourcen sind zu ihrem Schutz von den Azure-Ressourcen anderer Kunden isoliert.
- VM-Instanzen und Laufzeitsoftware werden regelmäßig aktualisiert, um auf neu entdeckte Sicherheitsrisiken zu reagieren.
- Die Weitergabe von Geheimnissen (etwa Verbindungszeichenfolgen) zwischen Ihrer App und anderen Azure-Ressourcen (etwa SQL-Datenbank) erfolgt innerhalb von Azure und überschreitet keine Netzwerkgrenzen. Gespeicherte Geheimnisse werden immer verschlüsselt.
- Die gesamte Kommunikation über die App Service-Verbindungsfeatures (beispielsweise Hybridverbindung) wird verschlüsselt.
- Verbindungen mit Remoteverwaltungstools wie Azure PowerShell, Azure CLI, Azure SDKs und REST-APIs werden jeweils verschlüsselt.
- Das Bedrohungsmanagement schützt die Infrastruktur und die Plattform rund um die Uhr vor Schadsoftware sowie vor DDoS-Angriffen (Distributed Denial of Service), MITM-Angriffen (Man in the Middle) und anderen Bedrohungen.
Weitere Informationen zur Infrastruktur und Plattform-Sicherheit in Azure finden Sie unter Azure Trust Center.
Weitere Empfehlungen zur Sicherheit gemäß der Microsoft-Benchmark für Cloudsicherheit finden Sie unter Azure-Sicherheitsbaseline für Azure Functions.
Sichere Ausführung
In diesem Abschnitt erfahren Sie, wie Sie Ihre Funktions-App so sicher wie möglich konfigurieren und ausführen können.
Defender für Cloud
Defender für Cloud kann im Portal in Ihre Funktions-App integriert werden. Es ermöglicht kostenlos eine schnelle Bewertung potenzieller konfigurationsbezogener Sicherheitsrisiken. Funktions-Apps, die in einem dedizierten Plan genutzt werden, können gegen einen Aufpreis auch die erweiterten Sicherheitsfunktionen von Defender für Cloud nutzen. Weitere Informationen finden Sie unter Schützen Ihrer Azure App Service-Web-Apps und -APIs.
Protokollieren und Überwachen
Eine Möglichkeit, Angriffe zu erkennen, besteht in der Aktivitätsüberwachung und Protokollanalyse. Azure Functions und Application Insights sind integriert, um Protokoll-, Leistungs- und Fehlerdaten für Ihre Funktions-App zu sammeln. Application Insights erkennt Leistungsanomalien automatisch und verfügt über leistungsstarke Analysetools, mit denen Sie Probleme untersuchen und nachvollziehen können, wie Ihre Funktionen verwendet werden. Weitere Informationen finden Sie unter Überwachen von Azure Functions.
Zudem sind Azure Functions und Azure Monitor-Protokolle integriert, um Ihnen zu ermöglichen, Protokolle von Funktions-Apps mit Systemereignissen zur einfacheren Analyse zusammenzuführen. Sie können Diagnoseeinstellungen nutzen, um den Export von Plattformprotokollen und Metriken für Ihre Funktionen durch Streamen zum Ziel Ihrer Wahl festzulegen, z. B. einem Log Analytics-Arbeitsbereich. Weitere Informationen finden Sie unter Überwachen von Azure Functions mit Azure Monitor-Protokollen.
Zur Erkennung von Bedrohungen auf Unternehmensebene und zur Automatisierung der Reaktion können Sie Ihre Protokolle und Ereignisse in einen Log Analytics-Arbeitsbereich streamen. Sie können dann Microsoft Sentinel mit diesem Arbeitsbereich verbinden. Weitere Informationen finden Sie unter Was ist Microsoft Sentinel .
Weitere Empfehlungen zu Einblicken in die Sicherheit finden Sie unter Azure-Sicherheitsbaseline für Azure Functions.
Erzwingen von HTTPS
Clients können sich standardmäßig über HTTP oder HTTPS mit Endpunkten von Funktionen verbinden. Sie sollten HTTP zu HTTPS umleiten, da für HTTPS das SSL-/TLS-Protokoll verwendet wird. Es ermöglicht eine sichere Verbindung, die zugleich verschlüsselt und authentifiziert ist. Weitere Informationen dazu finden Sie unter Erzwingen von HTTPS.
Wenn Sie HTTPS erzwingen, sollten Sie auch die neueste TLS-Version erzwingen. Weitere Informationen finden Sie unter Erzwingen von TLS-Versionen.
Weitere Informationen finden Sie unter Sichere Verbindungen (TLS).
Funktionszugriffsschlüssel
Mit Functions können Sie Schlüssel verwenden, wodurch der Zugriff auf Ihre HTTP-Funktionsendpunkte während der Entwicklung erschwert wird. Sofern die HTTP-Zugriffsebene für eine über HTTP ausgelöste Funktion nicht auf anonymous festgelegt ist, müssen Anforderungen einen API-Zugriffsschlüssel in der Anforderung enthalten.
Schlüssel bieten zwar einen Standardsicherheitsmechanismus, für den Schutz eines HTTP-Endpunkts in der Produktion sollten jedoch gegebenenfalls andere Optionen in Erwägung gezogen werden. So ist es beispielsweise nicht empfehlenswert, den gemeinsamen geheimen Schlüssel in öffentlichen Apps zu verteilen. Wenn Ihre Funktion über einen öffentlichen Client aufgerufen wird, empfiehlt es sich gegebenenfalls, einen anderen Sicherheitsmechanismus zu implementieren. Weitere Informationen hierzu finden Sie unter Schützen eines HTTP-Endpunkts in einer Produktionsumgebung.
Wenn Sie Ihre Funktionsschlüsselwerte erneuern, müssen die aktualisierten Schlüsselwerte manuell an alle Clients verteilt werden, von denen Ihre Funktion aufgerufen wird.
Autorisierungsbereiche (Funktionsebene)
Es gibt zwei Zugriffsbereiche für Schlüssel auf Funktionsebene:
Funktion: Diese Schlüssel gelten nur für die Funktionen, für die sie definiert sind. Bei Verwendung als API-Schlüssel ermöglichen diese nur Zugriff auf diese spezielle Funktion.
Host: Schlüssel mit einem Hostbereich können für den Zugriff auf alle Funktionen in der Funktions-App verwendet werden. Bei Verwendung als API-Schlüssel ermöglichen diese Zugriff auf jede Funktion in der Funktionen-App.
Jeder Schlüssel ist zu Referenzzwecken benannt. Auf Funktions- und Hostebene gibt es einen Standardschlüssel (mit dem Namen „default“). Funktionsschlüssel haben Vorrang vor Hostschlüsseln. Wenn zwei Schlüssel mit dem gleichen Namen definiert wurden, wird immer der Funktionsschlüssel verwendet.
Hauptschlüssel (Administratorebene)
Jede Funktions-App verfügt außerdem über einen Hostschlüssel auf Administratorebene mit dem Namen _master. Zusätzlich zur Bereitstellung des Zugriffs auf Hostebene auf alle Funktionen in der App bietet der Hauptschlüssel auch administrativen Zugriff auf die Laufzeit-REST-APIs. Dieser Schlüssel kann nicht widerrufen werden. Wenn Sie die Zugriffsebene admin festlegen, muss für Anforderungen der Hauptschlüssel verwendet werden. Alle anderen Schlüssel führen zu einem Zugriffsfehler.
Achtung
Aufgrund der erhöhten Berechtigungen, die der Hauptschlüssel in Ihrer Funktions-App erteilt, sollten Sie diesen Schlüssel nicht für Dritte freigeben oder in nativen Clientanwendungen verteilen. Gehen Sie umsichtig vor, wenn Sie die Zugriffsebene „Administrator“ auswählen.
Systemschlüssel
Für bestimmte Erweiterungen kann ein vom System verwalteter Schlüssel für den Zugriff auf Endpunkte von Webhooks erforderlich sein. Systemschlüssel sind für erweiterungsspezifische Funktionsendpunkte vorgesehen, die von internen Komponenten aufgerufen werden. Beispielsweise erfordert der Event Grid-Auslöser, dass das Abonnement beim Aufruf des Endpunkts des Auslösers einen Systemschlüssel nutzt. Das Feature „Durable Functions“ nutzt auch Systemschlüssel zum Aufrufen von Durable Task-Erweiterungs-APIs.
Der Geltungsbereich von Systemschlüsseln wird von der Erweiterung bestimmt, gilt aber in der Regel für die gesamte Funktions-App. Systemschlüssel können nur von bestimmten Erweiterungen erstellt werden. Ihre Werte können nicht explizit festgelegt werden. Wie bei anderen Schlüsseln können Sie einen neuen Wert für den Schlüssel über das Portal oder mithilfe der Schlüssel-APIs generieren.
Vergleich der Schlüssel
In der folgenden Tabelle wird der Zweck der verschiedenen Arten von Zugriffsschlüsseln verglichen:
| Aktion | `Scope` | Gültige Schlüssel |
|---|---|---|
| Funktion ausführen | Spezifische Funktion | Funktion |
| Funktion ausführen | Beliebige Funktion | Funktion oder Host |
| Administratorendpunkt aufrufen | Funktionen-App | Host (nur Master) |
| Durable Task-Erweiterungs-APIs aufrufen | Funktions-App1 | System2 |
| Erweiterungsspezifischen Webhook (intern) aufrufen | Funktions-App1 | System2 |
1Von der Erweiterung bestimmter Geltungsbereich.
2Von der Erweiterung festgelegte spezifische Namen.
Weitere Informationen über Zugriffsschlüssel finden Sie im Artikel zur Bindung von HTTP-Auslösern.
Geheimnis-Repositorys
Standardmäßig werden Schlüssel in einem Blob Storage-Container in dem Konto gespeichert, das von der AzureWebJobsStorage Einstellung bereitgestellt wird. Sie können die Einstellung AzureWebJobsSecretStorageType verwenden, um dieses Verhalten außer Kraft zu setzen und Schlüssel an einem anderen Ort zu speichern.
| Standort | Wert | Beschreibung |
|---|---|---|
| Konto für zweiten Speicher | blob |
Speichert Schlüssel im Blob-Speicher eines anderen Speicherkontos, basierend auf der SAS-URL in AzureWebJobsSecretStorageSas. |
| Dateisystem | files |
Schlüssel werden im Dateisystem persistent gespeichert. Dies ist die Standardeinstellung in Functions v1.x. |
| Azure-Schlüsseltresor | keyvault |
Der in AzureWebJobsSecretStorageKeyVaultUri festgelegte Schlüsseltresor wird zum Speichern von Schlüsseln verwendet. |
| Kubernetes-Geheimnisse | kubernetes |
Der Ressourcensatz in AzureWebJobsKubernetesSecretName wird zum Speichern von Schlüsseln verwendet. Nur unterstützt, wenn die Functions-Laufzeit in Kubernetes ausgeführt wird. Die Azure Functions Core Tools generieren die Werte automatisch bei Bereitstellung in Kubernetes. |
Wenn Sie Key Vault als Schlüsselspeicher verwenden, hängen die von Ihnen benötigten App-Einstellungen vom Typ der verwalteten Identität ab. Version 3.x der Functions-Runtime unterstützt nur systemseitig zugewiesene verwaltete Identitäten.
| Einstellungsname | Systemseitig zugewiesen | Benutzerseitig zugewiesen | App-Registrierung |
|---|---|---|---|
| AzureWebJobsSecretStorageKeyVaultUri | ✓ | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientId | X | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | ✓ |
| AzureWebJobsSecretStorageKeyVaultTenantId | X | X | ✓ |
Authentifizierung/Autorisierung
Funktionsschlüssel können zwar einen gewissen Schutz vor unerwünschtem Zugriff bieten. Doch die einzige Möglichkeit, Ihre Funktionsendpunkte wirksam abzusichern, ist die Implementierung einer positiven Authentifizierung von Clients, die auf Ihre Funktionen zugreifen. Sie können dann Autorisierungsentscheidungen auf Grundlage der Identität treffen.
Aktivieren der App Service-Authentifizierung/-Autorisierung
Die App Service-Plattform ermöglicht die Verwendung von Microsoft Entra ID sowie von verschiedenen anderen Identitätsanbietern zum Authentifizieren von Clients. Sie können diese Strategie zum Implementieren von benutzerdefinierten Autorisierungsregeln für Ihre Funktionen sowie Benutzerinformationen aus Ihrem Funktionscode verwenden. Weitere Informationen finden Sie unter Authentifizierung und Autorisierung in Azure App Service und Arbeiten mit Clientidentitäten.
Verwenden von Azure API Management (APIM) zum Authentifizieren von Anforderungen
APIM stellt verschiedene API-Sicherheitsoptionen für eingehende Anforderungen bereit. Weitere Informationen hierzu finden Sie unter API Management-Authentifizierungsrichtlinien. Wenn APIM vorhanden ist, können Sie Ihre Funktions-App so konfigurieren, dass Anforderungen nur von den IP-Adressen Ihrer APIM-Instanz angenommen werden. Weitere Informationen hierzu finden Sie unter Einschränkungen für IP-Adressen.
Berechtigungen
Wie bei allen Anwendungen oder Diensten besteht das Ziel darin, Ihre Funktions-App mit den geringstmöglichen Berechtigungen auszuführen.
Berechtigungen für die Benutzerverwaltung
Azure Functions unterstützt die integrierte rollenbasierte Zugriffssteuerung (Azure RBAC) von Azure. Von Functions unterstützte Azure-Rollen sind Mitwirkender, Besitzer und Leser.
Berechtigungen gelten auf Funktions-App-Ebene. Die Rolle „Mitwirkender“ ist zur Ausführung der meisten Aufgaben auf Funktions-App-Ebene erforderlich. Sie benötigen außerdem die Rolle „Mitwirkender“ zusammen mit der Berechtigung Überwachungsleser, um Protokolldaten in Application Insights anzeigen zu können. Nur die Rolle „Besitzer“ kann eine Funktions-App löschen.
Organisieren von Funktionen nach Berechtigungen
Verbindungszeichenfolgen und andere in den Anwendungseinstellungen gespeicherte Anmeldeinformationen erteilen allen Funktionen in der Funktions-App die gleichen Berechtigungen in der zugehörigen Ressource. Erwägen Sie, die Anzahl der Funktionen mit Zugriff auf bestimmte Anmeldeinformationen zu minimieren, indem Sie Funktionen, die diese Anmeldeinformationen nicht nutzen, in eine separate Funktions-App verlagern. Sie können stets Techniken wie Funktionsverkettung nutzen, um Daten in verschiedenen Funktions-Apps zwischen Funktionen zu übergeben.
Verwaltete Identitäten
Eine verwaltete Identität von Microsoft Entra ID ermöglicht es Ihrer App, einfach auf andere durch Microsoft Entra geschützte Ressourcen wie Azure Key Vault zuzugreifen. Da die Identität von der Azure-Plattform verwaltet wird, müssen Sie keine Geheimnisse bereitstellen oder rotieren. Weitere Informationen zu verwalteten Identitäten in Microsoft Entra ID finden Sie unter Verwaltete Identitäten für Azure-Ressourcen.
Ihrer Anwendung können zwei Arten von Identitäten zugewiesen werden:
- Eine systemseitig zugewiesene Identität ist an Ihre Anwendung gebunden und wird gelöscht, wenn Ihre App gelöscht wird. Eine App kann nur über eine systemseitig zugewiesene Identität verfügen.
- Eine benutzerseitig zugewiesene Identität ist eine eigenständige Azure-Ressource, die Ihrer App zugewiesen werden kann. Eine App kann über mehrere benutzerseitig zugewiesene Identitäten verfügen.
Verwaltete Identitäten können anstelle von Geheimnissen für Verbindungen von einigen Triggern und Bindungen verwendet werden. Siehe identitätsbasierte Verbindungen.
Weitere Informationen finden Sie unter Verwenden verwalteter Identitäten für App Service und Azure Functions.
Beschränken des CORS-Zugriffs
CORS (Cross-Origin Resource Sharing) ist eine Möglichkeit, Web-Apps, die in einer anderen Domäne ausgeführt werden, das Stellen von Anforderungen an Ihre HTTP-Auslöserendpunkte zu ermöglichen. App Service bietet integrierte Unterstützung für die Übergabe der erforderlichen CORS-Header in HTTP-Anforderungen. CORS-Regeln werden auf Funktions-App-Ebene definiert.
Während es verlockend ist, eine Wildcard zu verwenden, die allen Websites den Zugriff auf Ihren Endpunkt ermöglicht, widerstrebt dies dem Zweck von CORS, was dazu dient, websiteübergreifende Skriptangriffe zu verhindern. Fügen Sie stattdessen einen separaten CORS-Eintrag für die Domäne jeder Web-App hinzu, die auf Ihren Endpunkt zugreifen muss.
Verwaltung geheimer Schlüssel
Um eine Verbindung mit den verschiedenen Diensten und Ressourcen herstellen zu können, die für die Ausführung Ihres Codes benötigt werden, müssen Funktions-Apps auf Geheimnisse zugreifen können, wie z. B. Verbindungszeichenfolgen und Dienstschlüssel. In diesem Abschnitt wird beschrieben, wie Sie die für Ihre Funktionen erforderlichen Geheimnisse speichern können.
Speichern Sie Geheimnisse niemals in Ihrem Funktionscode.
Anwendungseinstellungen
Standardmäßig speichern Sie Verbindungszeichenfolgen und -geheimnisse, die von Ihrer Funktions-App und Bindungen genutzt werden, als Anwendungseinstellungen. Dadurch stehen diese Anmeldeinformationen sowohl Ihrem Funktionscode als auch den verschiedenen von der Funktion genutzten Bindungen zur Verfügung. Der Name der Anwendungseinstellung (des Schlüssels) dient zum Abrufen des tatsächlichen Werts, der das Geheimnis darstellt.
Beispielsweise benötigt jede Funktions-App ein zugehöriges Speicherkonto, das von der Runtime genutzt wird. Standardmäßig wird die Verbindung mit diesem Speicherkonto in der Anwendungseinstellung AzureWebJobsStorage festgelegt.
App-Einstellungen und Verbindungszeichenfolgen werden verschlüsselt in Azure gespeichert. Diese Angaben werden erst entschlüsselt, wenn sie beim Start der App in deren Prozessspeicher eingefügt werden. Die Verschlüsselungsschlüssel werden regelmäßig rotiert. Wenn Sie es stattdessen vorziehen, die sichere Speicherung Ihrer Geheimnisse zu verwalten, sollte die Anwendungseinstellung stattdessen aus Verweisen auf Azure Key Vault bestehen.
Sie können Einstellungen in der Datei „local.settings.json“ auch standardmäßig verschlüsseln, wenn Sie Funktionen auf dem lokalen Computer entwickeln. Weitere Informationen finden Sie unter Verschlüsseln der Datei für lokale Einstellungen.
Key Vault-Verweise
Während Anwendungseinstellungen für die meisten Funktionen ausreichend sind, möchten Sie möglicherweise die gleichen Geheimnisse für mehrere Dienste gemeinsam nutzen. In diesem Fall führt die redundante Speicherung von Geheimnissen zu mehr potenziellen Sicherheitsrisiken. Ein sichererer Ansatz ist das Einrichten eines zentralen Geheimnisspeicherdiensts und das Arbeiten mit Verweisen auf diesen Dienst statt mit den Geheimnissen selbst.
Azure Key Vault ist ein Dienst, der eine zentralisierte Verwaltung von Geheimnissen mit voller Kontrolle über Zugriffsrichtlinien und Überprüfungsverlauf ermöglicht. Sie können in Ihren Anwendungseinstellungen einen Key Vault-Verweis anstelle einer Verbindungszeichenfolge oder eines Schlüssels nutzen. Weitere Informationen finden Sie unter Verwenden von Key Vault-Verweisen in App Service und Azure Functions.
Identitätsbasierte Verbindungen
Identitäten können anstelle von Geheimnissen verwendet werden, um eine Verbindung mit einigen Ressourcen herzustellen. Dies hat den Vorteil, dass die Verwaltung eines Geheimnisses nicht erforderlich ist, und bietet eine präzisere Zugriffssteuerung und Überwachung.
Wenn Sie Code schreiben, der die Verbindung mit Azure-Diensten herstellt, die Microsoft Entra-Authentifizierung unterstützen, können Sie wahlweise eine Identität anstelle eines Geheimnisses oder einer Verbindungszeichenfolge verwenden. Details zu beiden Verbindungsmethoden finden Sie in der Dokumentation zu den einzelnen Diensten.
Einige Azure Functions-Trigger und -Bindungserweiterungen können mithilfe einer identitätsbasierten Verbindung konfiguriert werden. Zurzeit umfasst dies die Erweiterungen Azure-Blob und Azure-Warteschlangen. Informationen zum Konfigurieren dieser Erweiterungen für die Verwendung einer Identität finden Sie unter Verwenden von identitätsbasierten Verbindungen in Azure Functions.
Festlegen von Nutzungskontingenten
Erwägen Sie das Festlegen eines Nutzungskontingents für Funktionen, die in einem Verbrauchstarif ausgeführt werden. Wenn Sie einen täglichen Grenzwert für GB pro Sekunde für die gesamte Ausführung von Funktionen in Ihrer Funktions-App festlegen, wird die Ausführung bei Erreichen des Grenzwerts beendet. Dies könnte möglicherweise dazu beitragen, bösartigen Code zu entschärfen, der Ihre Funktionen ausführt. Weitere Informationen zum Abschätzen des Verbrauchs für Ihre Funktionen finden Sie unter Abschätzen der Kosten des Verbrauchstarifs.
Datenüberprüfung
Die von Ihren Funktionen genutzten Auslöser und Bindungen bieten keine zusätzliche Datenüberprüfung. Ihr Code muss alle von einem Auslöser oder einer Eingabebindung empfangenen Daten überprüfen. Wenn ein vorgelagerter Dienst kompromittiert wird, möchten Sie nicht, dass ungeprüfte Eingaben durch Ihre Funktionen geleitet werden. Wenn Ihre Funktion z. B. Daten aus einer Azure Storage-Warteschlange in einer relationalen Datenbank speichert, müssen Sie die Daten überprüfen und Ihre Befehle parametrisieren, um Angriffe durch Einschleusung von SQL-Befehlen zu vermeiden.
Gehen Sie nicht davon aus, dass die Daten, die in Ihre Funktion eingehen, bereits überprüft oder bereinigt wurden. Es ist auch eine gute Idee, zu prüfen, ob die Daten, die in Ausgabebindungen geschrieben werden, gültig sind.
Fehlerbehandlung
Auch wenn es einfach erscheint, ist es wichtig, eine effiziente Fehlerbehandlung in Ihre Funktionen zu schreiben. Unbehandelte Fehler fließen in den Host und werden von der Runtime behandelt. Verschiedene Bindungen handhaben die Fehlerbehandlung unterschiedlich. Weitere Informationen finden Sie unter Azure Functions – Fehlerbehandlung.
Deaktivieren des Remotedebuggen
Stellen Sie sicher, dass das Remotedebuggen deaktiviert ist, außer wenn Sie Ihre Funktionen aktiv debuggen. Sie können das Remotedebuggen auf der Registerkarte Allgemeine Einstellungen in der Konfiguration Ihrer Funktions-App im Portal festlegen.
Beschränken des CORS-Zugriffs
Azure Functions unterstützt jetzt die Ressourcenfreigabe zwischen verschiedenen Ursprüngen (Cross-Origin Resource Sharing, CORS). CORS wird im Portal und über die Azure-Befehlszeilenschnittstelle konfiguriert. Die CORS-Liste der zulässigen Ursprünge gilt auf Funktions-App-Ebene. Wenn CORS aktiviert ist, enthalten Antworten den Access-Control-Allow-Origin-Header. Weitere Informationen finden Sie unter Cross-Origin Resource Sharing (CORS).
Verwenden Sie keine Platzhalter in der Liste der zulässigen Ursprünge. Listen Sie stattdessen die spezifischen Domänen auf, von denen Sie voraussichtlich Anforderungen erhalten werden.
Daten verschlüsselt speichern
Azure Storage verschlüsselt alle Daten in einem ruhenden Speicherkonto. Weitere Informationen finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten.
Standardmäßig werden Daten mit von Microsoft verwalteten Schlüsseln verschlüsselt. Für eine zusätzliche Kontrolle über die Verschlüsselungsschlüssel können Sie vom Kunden verwaltete Schlüssel bereitstellen, mit denen Blob- und Dateidaten verschlüsselt werden können. Diese Schlüssel müssen in Azure Key Vault vorhanden sein, damit Functions auf das Speicherkonto zugreifen kann. Weitere Informationen finden Sie unter Verschlüsselung im Ruhezustand mithilfe von kundenseitig verwalteten Schlüsseln.
Verwandte Ressourcen schützen
Eine Funktions-App ist häufig von zusätzlichen Ressourcen abhängig, sodass die Sicherung dieser externen Ressourcen auch die Sicherung der App ist. Die meisten Funktions-Apps enthalten mindestens eine Abhängigkeit von Application Insights und Azure Storage. Anleitungen zum Schützen dieser Ressourcen finden Sie in der Azure-Sicherheitsbaseline für Azure Monitor und in der Azure-Sicherheitsbaseline für Azure Storage.
Wichtig
Das Speicherkonto wird verwendet, um wichtige App-Daten zu speichern, manchmal einschließlich des Anwendungscodes. Sie sollten den Zugriff von anderen Anwendungen und Benutzer*innen auf das Speicherkonto beschränken.
Sie sollten auch die Anleitung für alle Ressourcentypen lesen, von der ihre Anwendungslogik abhängig ist, sowohl als Trigger als auch als Bindungen und von Ihrem Funktionscode.
Sichere Bereitstellung
Die Azure Functions-Tools und -Integration machen es einfach, lokalen Projektcode von Funktionen in Azure zu veröffentlichen. Wichtig ist es zu verstehen, wie die Bereitstellung funktioniert, wenn es um die Sicherheit einer Azure Functions-Topologie geht.
Anmeldeinformationen für Bereitstellung
App Service-Bereitstellungen erfordern eine Reihe von Anmeldeinformationen für die Bereitstellung. Diese Anmeldeinformationen für die Bereitstellung werden zur Absicherung Ihrer Funktions-App-Bereitstellungen genutzt. Anmeldeinformationen für die Bereitstellung werden von der App Service-Plattform verwaltet und im Ruhezustand verschlüsselt.
Es gibt zwei Arten von Anmeldeinformationen für die Bereitstellung:
Anmeldeinformationen auf Benutzerebene: ein Satz von Anmeldeinformationen für das gesamte Azure-Konto. Hiermit können Sie App Service für alle Apps in allen Abonnements bereitstellen, für die das Azure-Konto über Zugriffsberechtigungen verfügt. Dies ist der Standardsatz, der auf der Benutzeroberfläche des Portals angezeigt wird (z.B. Übersicht und Eigenschaften auf der Ressourcenseite der App). Wenn ein Benutzer App-Zugriff über rollenbasierte Zugriffssteuerung (RBAC) oder Co-Administrator-Berechtigungen erhält, kann er die eigenen Anmeldeinformationen auf Benutzerebene verwenden, bis der Zugriff widerrufen wird. Teilen Sie diese Anmeldeinformationen nicht mit anderen Azure-Benutzern.
Anmeldeinformationen auf App-Ebene: ein Satz von Anmeldeinformationen für jede App. Er kann nur verwendet werden, um diese App bereitzustellen. Die Anmeldeinformationen für eine App werden bei der Erstellung jeder App automatisch generiert. Sie können nicht manuell konfiguriert, jedoch jederzeit zurückgesetzt werden. Damit ein Benutzer Zugriff auf Anmeldeinformationen auf App-Ebene über die rollenbasierte Zugriffssteuerung (RBAC) erhalten kann, muss er in der App mindestens ein Mitwirkender sein (einschließlich der integrierten Rolle „Websitemitwirkender“). Benutzer mit Leseberechtigung dürfen nicht veröffentlichen und haben keinen Zugriff auf diese Anmeldeinformationen.
Derzeit wird Key Vault nicht für Anmeldeinformationen für die Bereitstellung unterstützt. Weitere Informationen zum Verwalten von Anmeldeinformationen für die Bereitstellung finden Sie unter Konfigurieren der Anmeldeinformationen für die Bereitstellung für App Service.
Deaktivieren von FTP
Standardmäßig ist bei jeder Funktions-App ein FTP-Endpunkt aktiviert. Auf den FTP-Endpunkt wird mit Anmeldeinformationen für die Bereitstellung zugegriffen.
FTP wird für die Bereitstellung Ihres Funktionscodes nicht empfohlen. FTP-Bereitstellungen erfolgen manuell und erfordern die Synchronisierung von Auslösern. Weitere Informationen finden Sie unter FTP-Bereitstellung.
Wenn Sie nicht vorhaben, FTP zu nutzen, sollten Sie es im Portal deaktivieren. Wenn Sie FTP nutzen möchten, sollten Sie FTPS erzwingen.
Absichern des SCM-Endpunkts
Jede Funktions-App hat einen entsprechenden scm-Dienstendpunkt, der vom Dienst „Erweiterte Tools (Kudu)“ für Bereitstellungen und andere App Service-scm genutzt wird. Der SCM-Endpunkt für eine Funktions-App ist stets eine URL der Form https://<FUNCTION_APP_NAME.scm.azurewebsites.net>. Wenn Sie die Netzwerkisolation zur Absicherung Ihrer Funktionen nutzen, müssen Sie auch diesen Endpunkt berücksichtigen.
Durch einen separaten SCM-Endpunkt können Sie die Bereitstellung und andere erweiterte Toolfunktionen für Funktions-Apps steuern, die isoliert sind oder in einem virtuellen Netzwerk ausgeführt werden. Der SCM-Endpunkt unterstützt sowohl die Standardauthentifizierung (unter Verwendung der Anmeldeinformationen für die Bereitstellung) als auch einmaliges Anmelden mit Ihren Anmeldeinformationen für das Azure-Portal. Weitere Informationen finden Sie unter Zugreifen auf den Kudu-Dienst.
Laufende Sicherheitsüberprüfung
Da Sicherheit bei jedem Schritt im Entwicklungsprozess berücksichtigt werden muss, ist es sinnvoll, Sicherheitsüberprüfungen auch in einer Continuous Deployment-Umgebung umzusetzen. Dies wird auch als DevSecOps bezeichnet. Wenn Sie Azure DevOps für Ihre Bereitstellungspipeline nutzen, können Sie die Überprüfung in den Bereitstellungsprozess integrieren. Weitere Informationen finden Sie unter Hinzufügen einer ständigen Sicherheitsüberprüfung zu Ihrer CI-/CD-Pipeline.
Netzwerksicherheit
Durch Einschränkung des Netzwerkzugriffs auf Ihre Funktions-App können Sie steuern, wer auf die Endpunkte Ihrer Funktionen zugreifen darf. Azure Functions nutzt die Infrastruktur von App Service, um Ihren Funktionen den Zugriff auf Ressourcen ohne Verwendung von im Internet routingfähigen Adressen zu ermöglichen oder den Internetzugriff auf einen Funktionsendpunkt zu beschränken. Weitere Informationen zu diesen Netzwerkoptionen finden Sie unter Netzwerkoptionen von Azure Functions.
Festlegen von Zugriffsbeschränkungen
Zugriffsbeschränkungen ermöglichen Ihnen, Listen mit Zulassungs-/Verweigerungsregeln zu definieren, um den Datenverkehr zu Ihrer App zu steuern. Regeln werden in der Reihenfolge ihrer Priorität ausgewertet. Wenn keine Regeln definiert sind, akzeptiert Ihre App Datenverkehr von jeder beliebigen Adresse. Weitere Informationen finden Sie unter Azure App Service – Zugriffseinschränkungen.
Sichern des Speicherkontos
Beim Erstellen einer Funktions-App müssen Sie ein allgemeines Azure Storage-Konto erstellen oder verknüpfen, das Blob-, Queue- und Table Storage unterstützt. Sie können dieses Speicherkonto durch eines ersetzen, das mit Dienstendpunkten oder privaten Endpunkten geschützt ist. Weitere Informationen finden Sie unter Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk.
Privater Websitezugriff
Ein privater Azure-Endpunkt ist eine Netzwerkschnittstelle, die Sie privat und sicher mit einem Dienst verbindet, der von Azure Private Link unterstützt wird. Ein privater Endpunkt verwendet eine private IP-Adresse aus Ihrem virtuellen Netzwerk und macht den Dienst so in Ihrem virtuellen Netzwerk verfügbar.
Sie können einen privaten Endpunkt für ihre Funktionen verwenden, die in den Plänen Premium und App Service gehostet werden.
Wenn Sie Aufrufe an private Endpunkte durchführen möchten, müssen Sie sicherstellen, dass Ihre DNS-Suchen zu dem privaten Endpunkt aufgelöst werden. Sie können dieses Verhalten auf eine der folgenden Arten erzwingen:
- Integrieren mit private Azure DNS-Zonen. Wenn Ihr virtuelles Netzwerk nicht über einen benutzerdefinierten DNS-Server verfügt, erfolgt dies automatisch.
- Verwalten des privaten Endpunkts im DNS-Server, der von Ihrer App verwendet wird. Hierzu müssen Sie die Adresse des privaten Endpunkts kennen und dann den Endpunkt, den Sie erreichen möchten, mit einem A-Eintrag auf diese Adresse verweisen lassen.
- Konfigurieren Ihres eigenen DNS-Servers zur Weiterleitung an private Azure DNS-Zonen.
Weitere Informationen finden Sie unter Verwenden privater Endpunkte für Web-Apps.
Isoliertes Bereitstellen Ihrer Funktions-App
Die Azure App Service-Umgebung (ASE) stellt eine spezielle Hostingumgebung bereit, in der Sie Ihre Funktionen ausführen können. Mit ASE können Sie ein Front-End-Gateway konfigurieren, das Sie zum Authentifizieren aller eingehenden Anforderungen verwenden können. Weitere Informationen hierzu finden Sie unter Konfigurieren einer Web Application Firewall (WAF) für eine App Service-Umgebung.
Verwenden eines Gatewaydiensts
Mit Gatewaydiensten wie z. B. Azure Application Gateway und Azure Front Door können Sie eine Web Application Firewall (WAF) einrichten. WAF-Regeln dienen der Überwachung oder Blockierung erkannter Angriffe, wodurch eine zusätzliche Schutzebene für Ihre Funktionen geschaffen wird. Um eine WAF einzurichten, muss Ihre Funktions-App in einer App Service-Umgebung laufen oder private Endpunkte (Vorschau) nutzen. Weitere Informationen finden Sie unter Verwenden privater Endpunkte.