ASP.NET Core Datenschutzübersicht

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

Webanwendungen müssen häufig sicherheitsrelevante Daten speichern. Windows stellt eine Datenschutz-API, DPAPI bereit, Windows DPAPI ist jedoch nicht für die Verwendung in Webanwendungen vorgesehen.

Der ASP.NET Core Datenschutzstapel dient als langfristiger Ersatz für das <machineKey-Element> in ASP.NET 1.x - 4.x. Es wurde entwickelt, um viele der Mängel des alten kryptografischen Stapels zu beheben, während eine out-of-the-box-Lösung für die meisten Anwendungsfälle, die moderne Anwendungen auftreten, wahrscheinlich auftreten.

Problembeschreibung

Die allgemeine Problemerklärung kann in einem einzigen Satz prägnant angegeben werden: Ich muss vertrauenswürdige Informationen für den späteren Abruf beibehalten, aber ich vertraue nicht dem Persistenzmechanismus. In Webbegriffen kann dies als "Ich muss den vertrauenswürdigen Zustand über einen nicht vertrauenswürdigen Client round-trip" schreiben.

Das kanonische Beispiel hierfür ist ein Authentifizierungs cookie - oder Bearertoken. Der Server generiert ein Token "Ich bin Groot und besitzt 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 gewisse Sicherheit, dass der Client das Token nicht geschmiedet hat. Die erste Anforderung: Echtheit (a.k.a. Integrität, Manipulationsprüfung).

Da der beibehaltene Zustand vom Server vertrauenswürdig ist, erwarten wir, dass dieser Zustand Informationen enthalten kann, die für die Betriebssystemumgebung spezifisch sind. Dies könnte sich in Form eines Dateipfads, einer Berechtigung, eines Handles oder eines anderen indirekten Verweises oder eines anderen Teils von serverspezifischen Daten befinden. Solche Informationen sollten in der Regel nicht an einen nicht vertrauenswürdigen Client weitergegeben werden. Die zweite Anforderung: Vertraulichkeit.

Schließlich, da moderne Anwendungen komponentenisiert werden, ist, was wir gesehen haben, dass einzelne Komponenten dieses Systems nutzen möchten, ohne auf andere Komponenten im System zu achten. Wenn beispielsweise eine Bearertokenkomponente diesen Stapel verwendet, sollte sie ohne Störungen von einem Anti-CSRF-Mechanismus funktionieren, der auch denselben Stapel verwendet. Somit ist die endgültige Anforderung: Isolation.

Wir können weitere Einschränkungen bereitstellen, um den Umfang unserer Anforderungen einzuschränken. Wir gehen davon aus, dass alle im Kryptosystem betriebenen Dienste gleichermaßen vertrauenswürdig sind und dass die Daten nicht außerhalb der Dienste unter unserer direkten Kontrolle generiert oder verbraucht werden müssen. Darüber hinaus erfordern wir, dass Vorgänge so schnell wie möglich sind, da jede Anforderung an den Webdienst ein oder mehrere Male durch das Kryptosystem durchlaufen kann. Dies macht symmetrische Kryptografie ideal für unser Szenario, und wir können asymmetrische Kryptografie bis zu einer solchen Zeit, die benötigt wird, abgleichen.

Designphilosophie

Wir haben begonnen, Probleme mit dem vorhandenen Stapel zu identifizieren. Nachdem wir dies hatten, haben wir die Landschaft bestehender Lösungen untersucht und festgestellt, dass keine vorhandene Lösung die von uns gesuchten Funktionen hatte. Anschließend haben wir eine Lösung basierend auf mehreren Leitprinzipien entwickelt.

  • Das System sollte die Einfachheit der Konfiguration bieten. Idealerweise wäre das System nullkonfiguration und Entwickler könnten den Boden erreichen. In Situationen, in denen Entwickler einen bestimmten Aspekt (z. B. das Schlüsselreppository) konfigurieren müssen, sollten diese spezifischen Konfigurationen einfach gestaltet werden.

  • Bieten Sie eine einfache verbraucherorientierte API an. Die APIs sollten problemlos ordnungsgemäß und schwer zu verwenden sein.

  • Entwickler sollten keine wichtigen Verwaltungsprinzipien lernen. Das System sollte die Algorithmusauswahl und die Schlüssellebensdauer im Namen des Entwicklers behandeln. Idealerweise sollte der Entwickler niemals Zugriff auf das Rohschlüsselmaterial haben.

  • Schlüssel sollten bei Bedarf ruhend geschützt werden. Das System sollte einen geeigneten Standardschutzmechanismus ermitteln und automatisch anwenden.

Mit diesen Prinzipien haben wir einen einfachen, einfach zu verwendenden Datenschutzstapel entwickelt.

Die ASP.NET Core Datenschutz-APIs sind nicht in erster Linie für unbefristete Persistenz vertraulicher Nutzlasten vorgesehen. Andere Technologien wie Windows CNG DPAPI und Azure Rights Management eignen sich besser für das Szenario unbestimmter Speicher, und sie verfügen über entsprechende wichtige Verwaltungsfunktionen. Das heißt, es gibt 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 zielen auf drei Hauptgruppen ab;

  1. Die Consumer-APIs –Übersicht über Zielanwendungs- und Frameworkentwickler.

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

  2. Die Konfigurations-APIs für Anwendungsentwickler und Systemadministratoren.

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

  3. Die Erweiterbarkeits-APIs zielen auf Entwickler ab, die für die Implementierung benutzerdefinierter Richtlinien zuständig 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 einzigartige 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