ASP.NET Core-Datenschutz – Übersicht

Der ASP.NET Core-Datenschutz bietet eine kryptografische API zum Schutz von Daten, einschließlich Schlüsselverwaltung und Rotation.

Webanwendungen müssen oft sicherheitsrelevante Daten speichern. Windows bietet eine Datenschutz-API, DPAPI, aber Windows DPAPI ist nicht für die Verwendung in Webanwendungen gedacht.

Der ASP.NET Core-Datenschutzstapel ist als langfristiger Ersatz für das <machineKey>-Element in ASP.NET 1.x – 4.x gedacht. Er wurde entwickelt, um viele der Unzulänglichkeiten des alten Krypto-Stacks zu beheben und gleichzeitig eine sofort einsatzbereite Lösung für die meisten Anwendungsfälle zu bieten, die bei modernen Anwendungen auftreten können.

Problembeschreibung

Die allgemeine Problemstellung lässt sich in einem einzigen Satz zusammenfassen: Ich muss vertrauenswürdige Informationen für einen späteren Abruf aufbewahren, aber ich traue dem Persistenzmechanismus nicht. Im Web könnte man das so ausdrücken: „Ich muss einen vertrauenswürdigen Zustand über einen nicht vertrauenswürdigen Client weiterleiten.“

Das kanonische Beispiel hierfür ist ein Authentifizierungs-cookie oder ein Bearertoken. Der Server generiert ein „Ich bin Groot und habe xyz Berechtigungen“-Token und übergibt es an den Client. Zu einem späteren Zeitpunkt wird der Client dem Server dieses Token zurückgeben, aber der Server benötigt eine Art von Sicherheit, dass der Client das Token nicht gefälscht hat. Daher die erste Anforderung: Authentizität (auch bekannt als Integrität, Manipulationssicherheit).

Da der Server dem persistierten Status vertraut, gehen wir davon aus, dass dieser Status Informationen enthalten könnte, die für die Betriebsumgebung spezifisch sind. Dies kann in Form eines Dateipfads, einer Berechtigung, eines Handles oder eines anderen indirekten Verweises oder anderer serverspezifischer Daten geschehen. Solche Informationen sollten generell nicht an einen nicht vertrauenswürdigen Client weitergegeben werden. Daher die zweite Anforderung: Vertraulichkeit.

Da moderne Anwendungen aus Komponenten bestehen, haben wir festgestellt, dass einzelne Komponenten die Vorteile dieses Systems ohne Rücksicht auf andere Komponenten im System nutzen wollen. Wenn z. B. eine Bearertoken-Komponente diesen Stack verwendet, sollte sie ohne Störungen durch einen Anti-CSRF-Mechanismus arbeiten, der möglicherweise denselben Stack verwendet. Daher die letzte Anforderung: Isolation.

Wir können weitere Einschränkungen vorgeben, um den Umfang unserer Anforderungen einzugrenzen. Wir gehen davon aus, dass alle Vorgänge innerhalb des Kryptosystems gleichermaßen vertrauenswürdig sind und dass die Daten nicht außerhalb der von uns direkt kontrollierten Dienste erzeugt oder verbraucht werden müssen. Außerdem müssen die Vorgänge so schnell wie möglich ablaufen, da jede Anforderung an den Webdienst das Kryptosystem ein oder mehrere Male durchlaufen kann. Das macht die symmetrische Kryptographie ideal für unser Szenario, und wir können die asymmetrische Kryptographie außer Acht lassen, bis wir sie brauchen.

Designphilosophie

Wir haben zunächst die Probleme mit dem vorhandenen Stapel identifiziert. Danach haben wir die Landschaft der bestehenden Lösungen untersucht und sind zu dem Schluss gekommen, dass keine der bestehenden Lösungen die von uns gewünschten Funktionen bietet. Wir haben dann eine Lösung entwickelt, die auf mehreren Leitprinzipien basiert.

  • Das System sollte einfach zu konfigurieren sein. Im Idealfall wäre das System konfigurationsfrei und die Entwickler könnten sofort loslegen. In Situationen, in denen Entwickler einen bestimmten Aspekt konfigurieren müssen (z. B. das Schlüssel-Repository), sollte darauf geachtet werden, diese spezifischen Konfigurationen einfach zu gestalten.

  • Bieten Sie eine einfache API für Verbraucher an. Die APIs sollten einfach richtig zu verwenden und schwer falsch zu verwenden sein.

  • Entwickler sollten die Prinzipien der Schlüsselverwaltung nicht lernen müssen. Das System sollte die Auswahl des Algorithmus und die Lebensdauer des Schlüssels im Namen des Entwicklers übernehmen. Im Idealfall sollte der Entwickler nicht einmal Zugang zu dem rohen Schlüsselmaterial haben.

  • Schlüssel sollten, wenn möglich, im Ruhezustand geschützt werden. Das System sollte einen geeigneten Standard-Schutzmechanismus finden und diesen automatisch anwenden.

Mit diesen Prinzipien im Hinterkopf haben wir einen einfachen, benutzerfreundlichen Datenschutz-Stapel entwickelt.

Die ASP.NET Core-Datenschutz-APIs sind nicht in erster Linie für die unbestimmte Persistenz vertraulicher Nutzdaten vorgesehen. Andere Technologien wie Windows CNG DPAPI und Azure Rights Management eignen sich besser für das Szenario der unbegrenzten Speicherung und verfügen über entsprechend starke Schlüsselverwaltungsfunktionen. Es spricht jedoch nichts dagegen, dass ein Entwickler die ASP.NET Core Datenschutz-APIs für den langfristigen Schutz vertraulicher Daten verwendet.

Zielgruppe

Das Datensicherungssystem ist in fünf Hauptpakete unterteilt. Verschiedene Aspekte dieser APIs richten sich an drei Hauptzielgruppen;

  1. Die Zielgruppen der Consumer-APIs Overview sind Anwendungs- und Frameworkentwickler.

    „Ich möchte nicht lernen, wie der Stack funktioniert oder wie er konfiguriert ist. Ich möchte einfach nur einen Vorgang so einfach wie möglich durchführen und dabei mit hoher Wahrscheinlichkeit die APIs erfolgreich nutzen.“

  2. Die Zielgruppen der Konfigurations-APIs sind Anwendungsentwickler und Systemadministratoren.

    „Ich muss dem Datenschutzsystem mitteilen, dass die Pfade oder Einstellungen meiner Umgebung von den Standardeinstellungen abweichen.“

  3. Die Zielgruppe der Erweiterbarkeits-APIs sind Entwickler, die für die Implementierung benutzerdefinierter Richtlinien zuständig sind. Diese APIs werden nur selten verwendet und auch dann nur von erfahrenen, sicherheitsbewussten Entwicklern.

    „Ich muss eine gesamte Komponente innerhalb des Systems ersetzen, da ich wirklich einzigartige Verhaltensanforderungen habe. Ich bin bereit, selten genutzte Teile der API-Oberfläche zu lernen, um ein Plugin zu erstellen, das meine Anforderungen erfüllt.“

Paketlayout

Der Datenschutzstapel besteht aus fünf Paketen.

Zusätzliche Ressourcen