ASP.NET Core-Datenschutz – Übersicht

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. Im Web könnte man das so ausdrücken: Ich muss einen vertrauenswürdigen Zustand über einen nicht vertrauenswürdigen Client weiterleiten.

Authentizitäts-, Integritäts- und Manipulationsprüfung ist eine 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 Störungen funktionieren, z. B. von einem Anti-CSRF-Mechanismus, der auch denselben Stapel 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 darauf ausgerichtet, einfach korrekt verwendet zu werden, und schwierig falsch.
  • 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 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 starke Verwaltungsfunktionen. 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.

Paketlayout

Der Datenschutzstapel besteht aus fünf Paketen:

Zusätzliche Ressourcen

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. Im Web könnte man das so ausdrücken: Ich muss einen vertrauenswürdigen Zustand über einen nicht vertrauenswürdigen Client weiterleiten.

Authentizitäts-, Integritäts- und Manipulationsprüfung ist eine 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 Störungen funktionieren, z. B. von einem Anti-CSRF-Mechanismus, der auch denselben Stapel 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 darauf ausgerichtet, einfach korrekt verwendet zu werden, und schwierig falsch.
  • 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 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 starke Verwaltungsfunktionen. 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.

Paketlayout

Der Datenschutzstapel besteht aus fünf Paketen:

Zusätzliche Ressourcen