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 häufig sicherheitssensible Daten speichern. Windows bietet eine Datenschutz-API , DPAPI, aber Windows DPAPI ist 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 bis 4.x. Es wurde entwickelt, um viele der Mängel des alten Kryptografiestapels zu beheben und gleichzeitig eine vorgeschachtelte Lösung für die meisten Anwendungsfälle zu bieten, auf die moderne Anwendungen wahrscheinlich stoßen.

Problembeschreibung

Die allgemeine Problemerklärung kann kurz in einem einzigen Satz angegeben werden: Ich muss vertrauenswürdige Informationen für den späteren Abruf beibehalten, vertrauenswürdige Informationen aber nicht dem Persistenzmechanismus vertrauen. Im Web kann dies als "Ich muss einen Roundtrip des vertrauenswürdigen Zustands über einen nicht vertrauenswürdigen Client" schreiben.

Das kanonische Beispiel hierfür ist ein Authentifizierungs- oder cookie Bearertoken. Der Server generiert ein Token "I am Groot and have xyz permissions" (Ich bin Groot und habe xyz-Berechtigungen) und übergibt es an den Client. An einem zukünftigen Datum wird der Client dieses Token dem Server wieder zur Verfügung stellen, aber der Server muss sicher sein, dass der Client das Token nicht gefälscht hat. Daher ist die erste Anforderung: Authentizität (Integrität, Manipulationsschutz).

Da der persistente 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 anderer serverspezifischer Daten sein. Solche Informationen sollten in der Regel nicht an einen nicht vertrauenswürdigen Client weitergegeben werden. Daher ist die zweite Anforderung: Vertraulichkeit.

Da moderne Anwendungen komponentenisiert sind, haben wir gesehen, dass einzelne Komponenten dieses System nutzen möchten, ohne andere Komponenten im System zu berücksichtigen. Wenn beispielsweise eine Bearertokenkomponente diesen Stapel verwendet, sollte sie ohne Störungen von einem Anti-CSRF-Mechanismus betrieben werden, 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 zu verengen. Wir gehen davon aus, dass alle Dienste, die innerhalb des Kryptosystems ausgeführt werden, gleichermaßen vertrauenswürdig sind und dass die Daten nicht außerhalb der Dienste unter unserer direkten Kontrolle generiert oder verwendet 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 Kryptosystem ein oder mehrere Male durchgehen kann. Dies macht die symmetrische Kryptografie ideal für unser Szenario, und wir können die asymmetrische Kryptografie so lange vergünstign, bis sie benötigt wird.

Entwurfsgedanke

Wir haben als Erstes Probleme mit dem vorhandenen Stapel identifiziert. Sobald wir dies hatten, haben wir die Landschaft der vorhandenen Lösungen durchkämpft und festgestellt, dass keine vorhandene Lösung über die von uns angestrebten Funktionen verfügt. Anschließend haben wir eine Lösung entwickelt, die auf mehreren Leitprinzipien basiert.

  • Das System sollte eine einfache Konfiguration bieten. Im Idealfall wäre das System eine Zero-Configuration-Konfiguration, und Entwickler könnten auf dem Laufenden bleiben. In Situationen, in denen Entwickler einen bestimmten Aspekt (z. B. das Schlüsselrepository) konfigurieren müssen, sollten Sie diese konfigurationen einfach machen.

  • Bieten Sie eine einfache, kundenorientierte API. Die APIs sollten einfach und schwer falsch zu verwenden sein.

  • Entwickler sollten keine wichtigen Verwaltungsprinzipien erlernen. Das System sollte die Algorithmusauswahl und Schlüssellebensdauer im Auftrag des Entwicklers verarbeiten. Im Idealfall sollte der Entwickler nie zugriff auf das Rohschlüsselmaterial haben.

  • Schlüssel sollten nach Möglichkeit im Ruhezeit-Bereich geschützt werden. Das System sollte einen geeigneten Standardschutzmechanismus herausfinden 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 die unbegrenzte Persistenz vertraulicher Nutzlasten vorgesehen. Andere Technologien wie Windows CNG DPAPI und Azure Rights Management eignen sich besser für das Szenario des unbegrenzten Speichers und verfügen entsprechend über starke Schlüsselverwaltungsfunktionen. Es gibt jedoch nichts, was einem Entwickler untersagt, 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 Hauptzielgruppe ab:

  1. Die Consumer-APIs – Übersicht zielen auf Anwendungs- und Frameworkentwickler ab.

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

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

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

  3. Die Erweiterbarkeits-APIs sind für Entwickler ausgelegt, 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 eindeutige Verhaltensanforderungen habe. Ich bin bereit, ungewöhnlich verwendete Teile der API-Oberfläche zu erlernen, um ein Plug-In zu erstellen, das meine Anforderungen erfüllt."

Paketlayout

Der Datenschutzstapel besteht aus fünf Paketen.

Zusätzliche Ressourcen