Serverlose Lösungen und PaaS sollen die Produktivität von Entwicklern durch Reduktion des Verwaltungsaufwands steigern. So können Sie sich auf das Wesentliche konzentrieren, nämliche Ihre Anwendungslogik. Das darf jedoch nicht zulasten der Sicherheit gehen, und Best Practices müssen einfach umzusetzen sein. Erfreulicherweise stellen die App Service- und die Azure Functions-Plattform zahlreiche Funktionen bereit, die den Aufwand beim Sichern von Apps drastisch reduzieren.

Heute stellen wir Ihnen neue Sicherheitsfunktionen vor, mit denen Sie weniger Code benötigen, um mit verwalteten Identitäten und Geheimnissen zu arbeiten. Dazu gehören:

• Key Vault-Verweise für Anwendungseinstellungen (Public Preview)
• Benutzerseitig zugewiesene verwaltete Identitäten (Public Preview)
• Verwaltete Identitäten in App Service unter Linux/Web-App für Container (Public Preview)
• ClaimsPrincipal-Datenbindung für Azure Functions
• Unterstützung für „Access-Control-Allow-Credentials“ in der CORS-Konfiguration

Wir arbeiten auch weiterhin am Azure Security Center als primären Sicherheitshub für Ihre Azure-Ressourcen, da Sie damit Konfigurationsschwachstellen ermitteln und beheben, Ihre Gefährdung einschränken oder Angriffe erkennen und folglich auf sie reagieren können. Womöglich denken Sie, dass alle Ihre Apps HTTPS verwenden – mit dem Security Center können Sie das überprüfen, um ganz sicher zu sein. Wenn Sie es nicht bereits getan haben, sollten Sie es unbedingt ausprobieren.

Dann sehen wir uns die neuen Features mal genauer an.

Key Vault-Verweise für Anwendungseinstellungen (Public Preview)

Auf der Microsoft Ignite 2018 gaben wir einen kleinen Einblick in eine neue Funktion, mit der Apps ihre Anwendungseinstellungen aus Key Vault einbinden können. Ich freue mich sehr, Ihnen mitteilen zu können, dass dieses Feature ab heute in der Public Preview verfügbar ist.

Immer mehr Organisationen verwenden Richtlinien zur sicheren Geheimnisverwaltung, was großartig ist. Azure Key Vault enthält alle wichtigen Informationen für Ihre Geheimnisse und bietet die uneingeschränkte Kontrolle über Zugriffsrichtlinien und den Überwachungsverlauf. Zwar verfügen auch App Service und Azure Functions über die Funktion „Anwendungseinstellungen“, die als sicher gilt und Geheimnisse im Ruhezustand verschlüsselt, doch sie bietet nicht die Verwaltungsfunktionen, die Sie womöglich benötigen.

Allerdings müssen Sie beim Verwenden von Key Vault einen neuen Code schreiben. Wir haben festgestellt, dass viele Teams nicht jeden Ort einfach aktualisieren können, an dem ihre Anwendung mit Geheimnissen arbeitet. Das gilt insbesondere für ältere Anwendungen. Azure Functions-Trigger sind ebenfalls ein Problem, da sie von der Plattform verwaltet werden. Die neue Funktion bietet einen Lösungsansatz für beide Szenarien.

Anwendungseinstellungen aus Key Vault einbinden

Mit der Funktion „Key Vault-Verweise“ kann Ihre App sich so verhalten, als würde sie unveränderte Anwendungseinstellungen verwenden, d.h. es sind keine Codeänderungen erforderlich. Einen ausführlichen Überblick finden Sie in der Dokumentation für Key Vault-Verweise. Ich skizziere hier nur die Grundlagen.

Diese Funktion erfordert eine systemseitig zugewiesene verwaltete Identität für Ihre App. Weiter unten in diesem Beitrag gehe ich auf benutzerseitig zugewiesene Identitäten ein. Wir betrachten diese Vorschauversionen jedoch vorerst getrennt.

Sie müssen eine Zugriffsrichtlinie in Ihrer Key Vault-Instanz konfigurieren, die Ihrer Anwendung die GET-Berechtigung für Geheimnisse erteilt. Lernen Sie dafür, wie Sie eine Zugriffsrichtlinie konfigurieren.

Legen Sie schließlich den Wert einer beliebigen Anwendungseinstellung auf einen Verweis im folgenden Format fest:

@Microsoft.KeyVault(SecretUri=Geheimnis_URI_mit_Version)

Dabei ist Geheimnis_URI_mit_Version der vollständige URI für ein Geheimnis in Key Vault. Das wäre beispielsweise https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931.

Das war es auch schon. Sie müssen keine Änderungen an Ihrem Code vornehmen.

Für diese erste Vorschauversion müssen Sie eine Geheimnisversion explizit festlegen, weil noch kein automatischer Versionswechsel integriert ist. Dieses Feature soll allerdings so schnell wie möglich bereitgestellt werden.

Benutzerseitig zugewiesene verwaltete Identitäten (Public Preview)

Die aktuelle Unterstützung für verwaltete Identitäten gilt nur für systemseitig zugewiesene Identitäten. Die Idee ist, dass die Identität von der Plattform für eine bestimmte Anwendung erstellt wird und an den Lebenszyklus der Anwendung gebunden ist. Wenn Sie die Anwendung löschen, wird die Identität sofort aus Azure Active Directory entfernt.

Heute sehen wir uns eine Vorschau der benutzerseitig zugewiesenen Identitäten an, die als eigene Azure-Ressource erstellt und dann einer bestimmten Anwendung zugewiesen werden. Eine benutzerseitig zugewiesene Identität kann mehreren Anwendungen zugeordnet werden, und eine Anwendung kann mehrere benutzerseitig zugewiesene Identitäten aufweisen.

Weitere Informationen zum Erstellen und Verwenden einer benutzerseitig zugewiesenen Identität finden Sie unter Erstellen, Auflisten, Löschen oder Zuweisen einer Rolle zu einer benutzerseitig zugewiesenen verwalteten Identität über das Azure-Portal. Wenn Sie die Identität erstellt haben, können Sie sie Ihrer App zuweisen, indem Sie Ihre App-Konfiguration mit einem Zeiger auf diese Identität aktualisieren. Mehr erfahren Sie in der Dokumentation zu verwalteten Identitäten. Diese Vorschauversion wird nicht in Sovereign Clouds unterstützt.

Wichtig: Sie können eine Identität zwar für mehrere Ressourcen verwenden, doch achten Sie darauf, nicht zu viele Identitäten freizugeben und Ressourcen nicht zu viele Berechtigungen zu erteilen, die nicht erforderlich sind. Beachten Sie immer das Prinzip der geringsten Rechte und erstellen Sie standardmäßig für jede Komponente Ihrer Anwendung eine separate Identität. Geben Sie diese nur frei, wenn es absolut notwendig ist.

Verwaltete Identitäten in App Service unter Linux/Web-App für Container (Public Preview)

Wir freuen uns auch, unsere Unterstützung für verwaltete Identitäten auf App Service unter Linux/Web-App für Container auszuweiten. Jetzt können auch Linux-Anwendungen die schlüsselfertige Service-to-Service-Authentifizierung nutzen, ohne Anmeldeinformationen verwalten zu müssen. Diese Vorschauversion enthält sowohl systemseitig als auch benutzerseitig zugewiesene Unterstützung. Neben einem Tokendienst, der das Anfordern des Zugriffs auf Ressourcen wie Key Vault und Azure Resource Manager vereinfacht, bietet die neue Unterstützung Linux-Anwendungen auch Zugriff auf die bereits erwähnte Funktion „Key Vault-Verweise“.

Wenn Sie mit Ihren Linux-Anwendungen starten möchten, befolgen Sie die Konfigurationsschritte in der Dokumentation Verwenden verwalteter Identitäten für App Service und Azure Functions.

ClaimsPrincipal-Datenbindung für Azure Functions

Seit der ersten Vorschauversion von Azure Functions können Sie mit der App Service-Authentifizierung/Autorisierung den Zugriff auf Ihre Funktions-Apps einschränken. Nun machen wir es noch einfacher, eingehende Identitäten aus Ihrem Funktionscode zu nutzen. Die Bereitstellung wird derzeit finalisiert und steht bis Ende der Woche für alle Funktions-Apps in Azure zur Verfügung.

Für .NET erfolgt die Bereitstellung in Form eines ClaimsPrincipal-Objekts, ähnlich wie in ASP.NET. Das Objekt wird automatisch eingefügt, wenn Sie ein ClaimsPrincipal-Objekt Ihrer Funktionssignatur hinzufügen, ähnlich wie bei ILogger.

using System.Net;
using Microsoft.AspNetCore.Mvc;
using System.Security.Claims;

public static IActionResult Run(HttpRequest req, ClaimsPrincipal principal, ILogger log)
{
     // ...
     return new OkResult();
}

Ein kommendes Update wird für andere Sprachen den Zugriff über das Kontextobjekt gewähren. Bis dahin lässt sich die Vorschauversion nur für .NET verwenden. Weitere Informationen zu dieser Funktion finden Sie in der Referenz für HTTP-Trigger.

Es ist großartig, wie damit identitätsabhängige Funktionen bereinigt werden. Diese Funktion entfernt gemeinsam mit der Tokenbindung entfernt Code, der nicht relevant für Ihre Geschäftslogik ist.

Unterstützung für „Access-Control-Allow-Credentials“ in der CORS-Konfiguration

Zu guter Letzt komme ich zu einem Update für die CORS-Funktion, mit der der „Access-Control-Allow-Credentials“-Header festgelegt werden kann. Diese Funktion ist erforderlich, um bei einem API-Aufruf Cookies oder Token zu senden. Wenn dieser Antwortheader nicht festgelegt wird, gibt der Browser keine Daten weiter.

Im Tutorial Hosten einer RESTful-API mit CORS in Azure App Service erfahren Sie mehr über das CORS-Feature und diese neue Einstellung. Um den Header zu aktivieren, müssen Sie nur Ihre CORS-Konfiguration aktualisieren, um „supportCredentials“ auf TRUE zu setzen.

Der „Access-Control-Allow-Credentials“-Header kann dank einem tollen Pull Request aus der Community auch im lokalen Functions-Host für Entwicklungszwecke aktiviert werden.

Zusammenfassung

Wie bei allen unseren Vorschauversionen würden wir uns freuen, wenn Sie diese Features testen und uns Ihre Meinung mitteilen würden.

Wenn Sie Anfragen zu neuen Features haben, posten Sie Ihre Idee bitte in UserVoice (für Functions oder App Service). Wenn bei Ihnen Functions-spezifische Probleme auftreten, melden Sie diese bitte im GitHub-Repository. Sie erreichen das Team auch über Twitter: @AzureFunctions.

Wir freuen uns auf Ihr Feedback und auf den weiteren Austausch. Und nun sichern Sie Ihre Apps.