ASP.NET Core Datenschutz

Webanwendungen müssen häufig sicherheitskritische Daten speichern. Windows stellt eine Datenschutz-API (Data Protection API, DPAPI) für Desktopanwendungen bereit, aber Windows DPAPI ist nicht für die Verwendung in Webanwendungen vorgesehen. Der ASP.NET Core Datenschutzstapel bietet eine einfache, einfach zu verwendende kryptografische API, die ein Entwickler zum Schutz von Daten verwenden kann, einschließlich Schlüsselverwaltung und -rotation.

Der ASP.NET Core Datenschutzstapel dient als langfristiger Ersatz für das < > machineKey-Element in ASP.NET 1.x bis 4.x. Es wurde entwickelt, um viele nachteile des alten kryptografischen Stapels zu beheben und gleichzeitig eine sofort einsatzbereite Lösung für die meisten Anwendungsfälle bereitzustellen, auf die moderne Anwendungen wahrscheinlich stoßen.

Problembeschreibung

Die allgemeine Problem-Anweisung kann kurz in einem einzigen Satz angegeben werden: Ich muss vertrauenswürdige Informationen für den späteren Abruf beibehalten, aber ich vertraue nicht dem Persistenzmechanismus. Im Web kann dies als "Ich muss einen Roundtrip für den vertrauenswürdigen Zustand über einen nicht vertrauenswürdigen Client erforderlich" schreiben.

Das kanonische Beispiel hierfür ist ein Authentifizierungs- cookie oder Bearertoken. Der Server generiert das Token "I am Groot and have xyz permissions" (Ich bin Groot und habe xyz-Berechtigungen) und übergibt es an den Client. Zu einem späteren Zeitpunkt stellt der Client dieses Token wieder auf dem Server bereit, aber der Server benötigt eine Art Zusicherung, dass der Client das Token nicht gefälscht hat. Daher ist die erste Anforderung: Authentizität (auch als Integrität, Manipulationsschutz).

Da der permanente Zustand vom Server als vertrauenswürdig eingestuft wird, gehen wir davon aus, dass dieser Zustand informationen enthalten kann, die spezifisch für die Betriebsumgebung sind. Dies kann in Form eines Dateipfads, einer Berechtigung, eines Handles oder eines anderen indirekten Verweises oder eines anderen serverspezifischen Datenteils erfolgen. Solche Informationen sollten in der Regel nicht für einen nicht vertrauenswürdigen Client offengelegt werden. Daher ist die zweite Anforderung: Vertraulichkeit.

Da moderne Anwendungen komponentenisiert sind, haben wir festgestellt, dass einzelne Komponenten dieses System ohne Berücksichtigung anderer Komponenten im System nutzen möchten. Wenn beispielsweise eine Bearertokenkomponente diesen Stapel verwendet, sollte sie ohne Beeinträchtigung durch einen Anti-CSRF-Mechanismus funktionieren, der möglicherweise auch denselben Stapel verwendet. Daher ist die letzte Anforderung: Isolation.

Wir können weitere Einschränkungen bereitstellen, um den Umfang unserer Anforderungen einzugrenzen. Wir gehen davon aus, dass alle Dienste, die innerhalb des Kryptografiesystems betrieben werden, gleichermaßen vertrauenswürdig sind und dass die Daten nicht außerhalb der Dienste unter unserer direkten Kontrolle generiert oder genutzt werden müssen. Darüber hinaus ist es erforderlich, dass Vorgänge so schnell wie möglich sind, da jede Anforderung an den Webdienst das Kryptografiesystem ein oder mehrmals durchlaufen kann. Dies macht die symmetrische Kryptografie ideal für unser Szenario, und wir können asymmetrische Kryptografie so lange rabatten, bis sie benötigt wird.

Designkonzeption

Wir haben damit begonnen, Probleme mit dem vorhandenen Stapel zu identifizieren. Danach haben wir die Landschaft vorhandener Lösungen untersucht und festgestellt, dass keine vorhandene Lösung über die gewünschten Funktionen verfügt. Anschließend haben wir eine Lösung entwickelt, die auf mehreren Leitprinzipien basiert.

  • Das System sollte die Einfachheit der Konfiguration bieten. Im Idealfall wäre das System 0 (null), und Entwickler könnten den Richtigen für die Ausführung finden. In Situationen, in denen Entwickler einen bestimmten Aspekt (z. B. das Schlüssel-Repository) konfigurieren müssen, sollten Sie berücksichtigen, diese spezifischen Konfigurationen einfach zu gestalten.

  • Bieten Sie eine einfache CONSUMER-API an. Die APIs sollten einfach und schwierig zu verwenden sein.

  • Entwickler sollten wichtige Verwaltungsprinzipien nicht erlernen. Das System sollte die Algorithmusauswahl und die Schlüssellebensdauer im Auftrag des Entwicklers behandeln. Im Idealfall sollte der Entwickler niemals zugriff auf das Rohschlüsselmaterial haben.

  • Schlüssel sollten nach Möglichkeit im Ruhezustand geschützt werden. Das System sollte einen geeigneten Standardschutzmechanismus finden und automatisch anwenden.

Unter Berücksichtigung dieser Prinzipien haben wir einen einfachen, einfach zu verwendenden Stapel für den Datenschutz entwickelt.

Die ASP.NET Core Datenschutz-APIs sind nicht in erster Linie für die unbegrenzte Persistenz vertraulicher Nutzlasten vorgesehen. Andere Technologien wie Windows CNG DPAPI und Azure Rights Management eignen sich besser für das Szenario mit unbegrenztem Speicher und verfügen über entsprechend starke Schlüsselverwaltungsfunktionen. Es gibt jedoch nichts, was einen Entwickler daran hindert, die ASP.NET Core Datenschutz-APIs für den langfristigen Schutz vertraulicher Daten zu verwenden.

Zielgruppe

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

  1. Die Übersicht über Consumer-APIs richtet sich an Anwendungs- und Frameworkentwickler.

    "Ich möchte nicht mehr darüber erfahren, wie der Stapel funktioniert oder wie er konfiguriert ist. Ich möchte einen Vorgang einfach so einfach wie möglich und mit hoher Wahrscheinlichkeit ausführen, dass die APIs erfolgreich verwendet werden."

  2. Die Konfigurations-APIs richten sich an Anwendungsentwickler und Systemadministratoren.

    "Ich muss dem Datenschutzsystem mitteilen, dass meine Umgebung nicht standardmäßige Pfade oder Einstellungen erfordert."

  3. Die Erweiterbarkeits-APIs richten sich an Entwickler, die für die Implementierung benutzerdefinierter Richtlinien verantwortlich sind. Die Verwendung dieser APIs wäre auf seltene Situationen und erfahrene, sicherheitsbewusste Entwickler beschränkt.

    "Ich muss eine gesamte Komponente innerhalb des Systems ersetzen, da ich wirklich eindeutige Verhaltensanforderungen habe. Ich bin bereit, ungewöhnlich verwendete Teile der API-Oberfläche zu lernen, um ein Plug-In zu erstellen, das meine Anforderungen erfüllt."

Paketlayout

Der Datenschutzstapel besteht aus fünf Paketen.

Zusätzliche Ressourcen

Hosten von ASP.NET Core in einer Webfarm