ASP.NET Core Data Protection nach CVE-2026-40372 in 7 Schritten haerten — die Anleitung die mir 2 Produktions-Incidents erspart haette

Die ASP.NET Core CVE-2026-40372 vom 22. April 2026 zwingt deutsche Entwicklerteams zu einer schnellen und disziplinierten Reaktion. In den letzten 24 Stunden haben wir zwei Kundenstacks koordiniert gepatcht und den Key Ring rotiert. Hier ist die 7-Schritte Anleitung, die uns zwei Produktions-Incidents erspart haette, wenn wir sie vor der Saison 2025 gehabt haetten.

Schritt 1: Exposition identifizieren und Inventar aller .NET 10 Services erstellen

Bevor irgendetwas gepatcht wird, braucht man ein vollstaendiges Inventar. Ausfuehren:

# In jedem Repo
grep -rE "Microsoft.AspNetCore.DataProtection" *.csproj *.fsproj

# Ueber alle Docker Images
docker image ls | grep -E "aspnet:10|dotnet:10"

# Versionen auflisten
dotnet list package | grep DataProtection

Ergebnis: eine Tabelle mit Service-Name, .NET Version, DataProtection Version, Key Ring Storage Location (Azure Key Vault, Filesystem, Redis), und CI/CD Pipeline. Diese Tabelle wird der Sachstand fuer das BaFin Report und die BSI Kommunikation.

Schritt 2: Upgrade auf Microsoft.AspNetCore.DataProtection 10.0.7

In der csproj Datei die Version updaten:

<PackageReference Include="Microsoft.AspNetCore.DataProtection" Version="10.0.7" />

Dann dotnet restore, Unit Tests laufen lassen, Integrationstests ausfuehren. Ein 5-Minuten Build + Tests Zyklus sollte reichen. Deployment in Staging zuerst, Production nach 30 Minuten Beobachtung. Diese Schritte gelten auch fuer abhaengige Pakete wie Microsoft.AspNetCore.Authentication.Cookies und Microsoft.AspNetCore.Antiforgery, die indirekt von DataProtection abhaengen.

Schritt 3: Azure Key Vault fuer Key Ring Storage konfigurieren

Wenn der Key Ring aktuell im Dateisystem oder in Redis liegt, ist jetzt der richtige Moment zum Umzug auf Azure Key Vault oder HashiCorp Vault. Konfiguration in Program.cs:

builder.Services.AddDataProtection()
    .PersistKeysToAzureBlobStorage(blobClient)
    .ProtectKeysWithAzureKeyVault(keyVaultKeyUri, credential)
    .SetDefaultKeyLifetime(TimeSpan.FromDays(90))
    .SetApplicationName("MeineApp");

Wichtig: die Azure Key Vault Region auf germanywestcentral oder germanynorth setzen, um BaFin-konforme Datenresidenz zu garantieren. Fuer on-premise souveraene Setups bevorzugen wir HashiCorp Vault self-hosted mit TLS Mutual Authentication.

Schritt 4: Key Ring koordiniert rotieren und waehrend der Uebergangsphase ueberlappen

Eine forcierte Rotation kann via C# ausgefuehrt werden:

var keyManager = app.Services.GetRequiredService<IKeyManager>();
var newKey = keyManager.CreateNewKey(
    activationDate: DateTimeOffset.UtcNow,
    expirationDate: DateTimeOffset.UtcNow.AddDays(90));

Nach der Erstellung des neuen Schluessels hat man eine Ueberlappungsphase von 24-48 Stunden, in der sowohl alte als auch neue Schluessel gueltig sind. Neue Tokens werden mit dem neuen Schluessel signiert. Alte Schluessel koennen nach der Ueberlappung via keyManager.RevokeKey widerrufen werden.

Wichtig fuer Microservices: alle Services muessen das aktualisierte Key Ring laden, bevor die Rotation wirksam wird. Implementieren Sie einen Reload-Mechanismus (Polling Azure Key Vault alle 60 Sekunden) oder forcieren Sie ein rolling Restart.

Schritt 5: Ausgestellte Tokens waehrend des verwundbaren Zeitfensters widerrufen

Der kritische Schritt, den viele ueberspringen. Alle Tokens, die zwischen dem 10.0.0 Release und dem 10.0.7 Deployment ausgestellt wurden, muessen als potentiell kompromittiert behandelt werden. Konkret:

• Alle aktiven Sessions beenden und Re-Login erzwingen.
• Alle Password Reset Links aus dieser Periode invalidieren.
• Alle API Keys rotieren.
• Alle OAuth Refresh Tokens widerrufen und neu ausstellen.
• MFA-Backup-Codes fuer alle Admin-Konten regenerieren.

Fuer Kunden-Kommunikation: eine klare E-Mail mit Hinweis auf den Sicherheitsvorfall, die Maßnahmen des Unternehmens und die Aufforderung zum Re-Login. Unsere Kollegen bei hiredeveloper.sg beschreiben dasselbe Protokoll fuer Singapurer Banken.

Schritt 6: Monitoring und Alerting fuer anomale Session-Muster aufsetzen

Monitoring fuer ungewoehnliche Authentifizierungs-Muster einrichten. Datadog, Azure Monitor oder OpenTelemetry zur Erkennung von:

• Sprungartigen Zunahmen von Login-Events aus unbekannten Geo-Locations.
• Ungewoehnlichen Re-Auth Raten nach der Rotation.
• Failed HMAC Validations (sollten nach Patch = 0 sein).
• Anomalen Antiforgery Token Fehlern.

Alerts auf PagerDuty oder OpsGenie mit Severity 2 konfigurieren. Fuer den Mittelstand ist Datadog am schnellsten zu konfigurieren. Fuer BaFin-regulierte Institute empfehlen wir eine Integration mit Splunk oder IBM QRadar. Verwandte SRE-Praktiken beschreiben wir in unserem Leitfaden zu DevOps Berlin.

Schritt 7: Red Team Review und Quarterly Key Ring Hygiene einfuehren

Einmal pro Quartal einen Red Team Penetrationstest auf das DataProtection Ecosystem durchfuehren. Ziel: herausfinden, ob die Rotation wirklich erzwingt, was erwartet wird, und ob kein Token mit gehackten Schluesseln wiedereingespielt werden kann.

Den Key Ring Review in die CI/CD Pipeline einbauen: ein CI-Check, der prueft, ob die DataProtection Version aktuell ist, die Rotation regelmaessig durchgefuehrt wurde, und die Konfiguration den internen Security Policies entspricht. Pro-Aktiv bleiben statt reaktiv.

FAQ: ASP.NET Core Data Protection haerten

Kann man eine Data Protection Key Ring Rotation ohne Ausfallzeit durchfuehren?

Ja, mit sorgfaeltiger Planung. Die Rotation fuegt einen neuen Schluessel zum Key Ring hinzu, ohne die alten zu loeschen. Neue ausgestellte Tokens werden mit dem neuen Schluessel signiert, bestehende Sessions bleiben mit alten Schluesseln gueltig. Nach einer Uebergangsphase von 24 bis 48 Stunden koennen die alten Schluessel revoked werden. Benutzer mit aktiven Sessions muessen sich dann erneut anmelden. Bankenumgebungen koordinieren diese Rotation meist ausserhalb der Geschaeftszeiten, typischerweise am Wochenende.

Welche Alternativen zu Azure Key Vault gibt es fuer den Key Ring Storage?

Drei praktikable Alternativen. HashiCorp Vault self-hosted: ideal fuer souveraene oder on-premise Umgebungen, breit in deutschen Banken eingesetzt. Dateisystem mit Dataprotection EncryptToCertificate: einfach fuer kleinere Umgebungen aber schwer zu rotieren. Redis mit Azure Managed Redis: fuer Multi-Region Setups. Fuer BaFin-regulierte Institute ist HashiCorp Vault oder Azure Key Vault im Deutschland-Region die pragmatische Wahl.

Wie erkennt man, welche Tokens waehrend des verwundbaren Zeitfensters ausgestellt wurden?

Die meisten ASP.NET Core Apps protokollieren keine detaillierten Token-Ausstellungen. Ohne vorhandene Logs muessen Sie das gesamte verwundbare Zeitfenster (Anfang Januar 2026 Release von 10.0.0 bis zum Patch-Deployment) als kompromittiert betrachten und alle Sessions, Password Reset Links und API Keys aus dieser Periode widerrufen. Fuer zukuenftige CVEs empfehlen wir strukturiertes Audit Logging mit Serilog oder OpenTelemetry.

Wie haeufig sollte man den Data Protection Key Ring rotieren?

Best Practice 2026: automatische Rotation alle 90 Tage mit einer Ueberlappungsphase von 14 Tagen. ASP.NET Core verwaltet dies nativ ueber die Konfiguration SetDefaultKeyLifetime. Nach einer CVE wie 2026-40372 ist eine manuelle Sofortrotation noetig, die den 90-Tage-Zyklus ersetzt. Banken mit BaFin-Regulierung rotieren oft alle 60 Tage.