Übersicht über den Datenschutz ASP.NET Core

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

Web-Apps müssen häufig vertrauliche Daten speichern. Die Windows-Datenschutz-API (DPAPI) ist nicht für die Verwendung in Web-Apps vorgesehen.

Der ASP.NET Core Datenschutzstapel ist auf folgende Zwecke ausgelegt:

  • Stellen Sie eine integrierte Lösung für die meisten Webszenarien bereit.
  • Behandeln Sie viele Mängel des vorherigen Verschlüsselungssystems.
  • Dienen als Ersatz für das <machineKey>-Element in ASP.NET 1.x - 4.x.

Problembeschreibung

Ich muss vertrauenswürdige Informationen für den späteren Abruf beibehalten, aber ich vertraue dem Persistenzmechanismus nicht. Im Webkontext könnte diese Aussage so formuliert werden: Ich muss einen vertrauenswürdigen Status über einen nicht vertrauenswürdigen Client hin- und zurückübertragen.

Authentizität, Integrität und Manipulationsprüfung sind Anforderungen. Das kanonische Beispiel für dieses Szenario ist ein Authentifizierungs cookie - oder Bearertoken. Der Server generiert ein Ich bin Groot und habe xyz Berechtigungen-Token und sendet es an den Client. Der Client legt dieses Token dem Server erneut vor, aber der Server braucht eine gewisse Gewissheit, dass der Client das Token nicht gefälscht hat.

Vertraulichkeit ist eine Anforderung. Da der permanente Zustand vom Server als vertrauenswürdig eingestuft wird, enthält dieser Zustand möglicherweise Informationen, die nicht an einen nicht vertrauenswürdigen Client weitergegeben werden sollen. Zum Beispiel:

  • Ein Dateipfad
  • Eine Berechtigung
  • Ein Handle oder ein anderer indirekter Verweis
  • Einige serverspezifische Daten

Isolation ist eine Anforderung. Da moderne Apps komponentenisiert sind, möchten einzelne Komponenten dieses Systems nutzen, ohne dass andere Komponenten im System berücksichtigt werden. Erwägen Sie beispielsweise eine Bearertokenkomponente, die diesen Stapel verwendet. Es sollte ohne Beeinträchtigungen funktionieren, etwa durch einen Anti-CSRF-Mechanismus, der ebenfalls denselben Stack verwendet.

Einige gängige Annahmen können den Umfang der Anforderungen einschränken:

  • Alle im Kryptosystem tätigen Dienste sind gleichermaßen vertrauenswürdig.
  • Die Daten müssen nicht außerhalb der Dienste unter unserer direkten Kontrolle generiert oder genutzt werden.
  • Vorgänge müssen schnell sein, da jede Anforderung an den Webdienst ein oder mehrere Male das Kryptosystem durchlaufen kann. Die Geschwindigkeitsanforderung macht symmetrische Kryptografie ideal. Die asymmetrische Kryptografie wird erst verwendet, wenn sie erforderlich ist.

Designphilosophie

ASP.NET Core-Datenschutz ist ein einfach zu verwendender Datenschutz-Stack, der auf den folgenden Prinzipien basiert:

  • Die Konfiguration sollte einfach sein. Das System ist bestrebt, eine Nullkonfiguration zu erreichen. In Situationen, in denen Entwickler einen bestimmten Aspekt konfigurieren müssen, z. B. das Schlüssel-Repository, sind diese spezifischen Konfigurationen nicht schwierig.
  • Stellen Sie grundlegende APIs für Endverbraucher bereit. Die APIs sind einfach korrekt und schwer falsch zu verwenden.
  • Fordern Sie den Entwickler nicht auf, die Prinzipien der Verwaltung von Schlüsseln zu erlernen. Das System behandelt die Algorithmusauswahl und die Schlüssellebensdauer im Auftrag der Entwickler*innen. Entwickler haben keinen Zugriff auf das Rohmaterial, daher benötigen sie kein Expertenwissen über die Prinzipien.
  • Schützen Sie Schlüssel im Ruhezustand so weit wie möglich. Das System findet einen geeigneten Standard-Schutzmechanismus und wendet diesen automatisch an.

Die Datenschutz-APIs sind nicht primär für die unbegrenzte Speicherung vertraulicher Nutzdaten gedacht. Andere Technologien wie Windows CNG DPAPI und Azure Rights Management eignen sich besser für das Szenario des unbegrenzten Speichers. Sie verfügen über ebenso leistungsfähige Funktionen zur Schlüsselverwaltung. Das heißt, die ASP.NET Kerndatenschutz-APIs können zum langfristigen Schutz vertraulicher Daten verwendet werden.

Zielgruppe

Das Datenschutzsystem stellt APIs bereit, die auf drei Hauptgruppen abzielen:

  • Die Zielgruppen der Consumer-APIs sind Anwendungs- und Frameworkentwickler*innen.

    Ich möchte nicht lernen, wie der Stack funktioniert oder wie er konfiguriert ist. Ich möchte nur einige Vorgänge mit hoher Wahrscheinlichkeit, die APIs erfolgreich zu verwenden, ausführen.

  • Die Zielgruppen der Konfigurations-APIs sind Anwendungsentwickler*innen und Systemadministrator*innen.

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

  • Die Erweiterbarkeits-APIs richten sich an Entwickler, die für die Implementierung benutzerdefinierter Richtlinien zuständig sind. Die Verwendung dieser APIs ist auf seltene Situationen und Entwickler mit Sicherheitserfahrung 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, damit ich ein Plug-In erstellen kann, das meine Anforderungen erfüllt.

Paketanordnung

Der Datenschutzstapel besteht aus fünf Paketen:

Verwandte Inhalte

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

Web-Apps müssen häufig vertrauliche Daten speichern. Die Windows-Datenschutz-API (DPAPI) ist nicht für die Verwendung in Web-Apps vorgesehen.

Der ASP.NET Core-Datenschutzstack wurde entwickelt für:

  • Bereitstellen einer integrierten Lösung für die meisten Webszenarien.
  • Behandeln vieler der Mängel des vorherigen Verschlüsselungssystems.
  • Dienen als Ersatz für das <machineKey>-Element in ASP.NET 1.x - 4.x.

Problembeschreibung

Ich muss vertrauenswürdige Informationen für den späteren Abruf beibehalten, aber ich vertraue dem Persistenzmechanismus nicht. In Web-Begriffen könnte man das so ausdrücken: Ich muss einen vertrauenswürdigen Zustand über einen nicht vertrauenswürdigen Client hin- und zurückschicken.

Authentizität, Integrität und Manipulationssicherheit sind Voraussetzung. 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 sendet es an den Client. Der Client gibt dem Server dieses Token zurück, aber der Server benötigt eine Art von Sicherheit, dass der Client das Token nicht gefälscht hat.

Vertraulichkeit ist eine Anforderung. Da der permanente Zustand vom Server als vertrauenswürdig eingestuft wird, kann dieser Zustand Informationen enthalten, die nicht an einen nicht vertrauenswürdigen Client weitergegeben werden sollen. Zum Beispiel:

  • Ein Dateipfad.
  • Eine Berechtigung.
  • Ein Handle oder ein anderer indirekter Verweis.
  • Einige serverspezifische Daten.

Isolation ist eine Anforderung. Da moderne Apps komponentenisiert sind, wollen einzelne Komponenten dieses Systems nutzen, ohne dass andere Komponenten im System berücksichtigt werden. Erwägen Sie beispielsweise eine Bearertokenkomponente, die diesen Stapel verwendet. Es sollte ohne Beeinträchtigungen funktionieren, beispielsweise durch einen Anti-CSRF-Mechanismus, der ebenfalls denselben Stack verwendet.

Einige gängige Annahmen können den Umfang der Anforderungen einschränken:

  • Alle im Kryptosystem tätigen Dienste sind gleichermaßen vertrauenswürdig.
  • Die Daten müssen nicht außerhalb der Dienste unter unserer direkten Kontrolle generiert oder genutzt werden.
  • Vorgänge müssen schnell sein, da jede Anforderung an den Webdienst ein oder mehrere Male das Kryptosystem durchlaufen kann. Die Geschwindigkeitsanforderung macht symmetrische Kryptografie ideal. Die asymmetrische Kryptografie wird erst verwendet, wenn sie erforderlich ist.

Designphilosophie

ASP.NET-Kerndatenschutz ist ein einfach zu verwendender Datenschutzstapel. Es beruht auf den folgenden Prinzipien:

  • Einfache Konfiguration. Das System ist bestrebt, eine Nullkonfiguration zu erreichen. In Situationen, in denen Entwickler einen bestimmten Aspekt konfigurieren müssen, z. B. das Schlüssel-Repository, sind diese spezifischen Konfigurationen nicht schwierig.
  • Bieten Sie eine einfache verbraucherorientierte API an. Die APIs sind einfach korrekt zu verwenden und schwer falsch zu verwenden.
  • Entwickler*innen müssen keine Prinzipien der Schlüsselverwaltung erlernen. Das System behandelt die Algorithmusauswahl und die Schlüssellebensdauer im Auftrag der Entwickler*innen. Entwickler*innen haben keinen Zugriff auf das Rohschlüsselmaterial.
  • Schlüssel sind im Ruhezustand so weit wie möglich geschützt. Das System findet einen geeigneten Standard-Schutzmechanismus und wendet diesen automatisch an.

Die Datenschutz-APIs sind nicht primär für die unbegrenzte Speicherung vertraulicher Nutzdaten gedacht. Andere Technologien wie Windows CNG DPAPI und Azure Rights Management eignen sich besser für das Szenario des unbegrenzten Speichers. Sie verfügen über entsprechend leistungsfähige Funktionen zur Schlüsselverwaltung. Das heißt, die ASP.NET Kerndatenschutz-APIs können zum langfristigen Schutz vertraulicher Daten verwendet werden.

Zielgruppe

Das Datenschutzsystem stellt APIs bereit, die auf drei Hauptgruppen abzielen:

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

    Ich möchte nicht lernen, wie der Stack funktioniert oder wie er konfiguriert ist. Ich möchte nur einige Vorgänge mit hoher Wahrscheinlichkeit, die APIs erfolgreich zu verwenden, ausführen.

  2. Die Zielgruppen der Konfigurations-APIs sind Anwendungsentwickler*innen und Systemadministrator*innen.

    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. Die Verwendung dieser APIs ist auf seltene Situationen und Entwickler mit Sicherheitserfahrung beschränkt.

    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.

Paketanordnung

Der Datenschutzstapel besteht aus fünf Paketen:

Zusätzliche Ressourcen

  • Last updated on