(Data Protection key management and lifetime in ASP.NET Core) Gültigkeitsdauer und Verwaltung von Schlüsseln für den Schutz von Daten in ASP.NET Core

Von Rick Anderson

Schlüsselverwaltung

Die App versucht, ihre Betriebsumgebung zu erkennen und die Schlüsselkonfiguration selbst zu behandeln.

  1. Wenn die App in Azure Apps gehostet wird, werden Schlüssel im Ordner %HOME%\ASP.NET\DataProtection-Keys beibehalten. Dieser Ordner wird von einem Netzwerkspeicher unterstützt und mit allen Computern, auf denen die App gehostet wird, synchronisiert.

    • Ruhende Schlüssel werden nicht geschützt.
    • Der Ordner "DataProtection-Keys " stellt den Schlüsselring für alle Instanzen einer App in einem einzelnen Bereitstellungsplatz bereit.
    • Separate Bereitstellungsslots, wie Staging und Produktion, verwenden keinen gemeinsamen Schlüsselbund. Wenn Sie zwischen Bereitstellungsplatzen wechseln, z. B. die Bereitstellungsbereitstellung in Produktion oder die Verwendung von A/B-Tests, kann jede App, die Datenschutz verwendet, keine gespeicherten Daten mithilfe des Schlüsselrings innerhalb des vorherigen Steckplatzes entschlüsseln. Dies führt dazu, dass Benutzer von einer App abgemeldet werden, die die standard-ASP.NET Core-Authentifizierung cookie verwendet, da sie den Datenschutz verwendet, um seine cookieS zu schützen. Wenn Sie slotunabhängige Schlüsselringe wünschen, verwenden Sie einen externen Schlüsselringanbieter, z. B. Azure Blob Storage, Azure Key Vault, einen SQL-Speicher oder Redis-Cache.
  2. Wenn das Benutzerprofil verfügbar ist, werden die Schlüssel im Ordner %LOCALAPPDATA%\ASP.NET\DataProtection-Keys beibehalten. Wenn das Betriebssystem Windows ist, werden die Schlüssel mit DPAPI verschlüsselt.

    Das setProfileEnvironment-Attribut des App-Pools muss ebenfalls aktiviert sein. Der Standardwert von setProfileEnvironment ist true. In einigen Szenarien (z.B. Windows-Betriebssystem) ist setProfileEnvironment auf false festgelegt. Gehen Sie folgendermaßen vor, wenn Schlüssel nicht wie erwartet im Benutzerprofilverzeichnis gespeichert werden:

    1. Navigieren Sie zum Ordner %windir%/system32/inetsrv/config.
    2. Öffnen Sie die Datei applicationHost.config.
    3. Suchen Sie das Element <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> .
    4. Bestätigen Sie, dass das setProfileEnvironment-Attribut nicht vorhanden ist, das standardmäßig den Wert true aufweist, oder legen Sie den Wert des Attributs explizit auf true fest.
  3. Wenn die App in IIS gehostet wird, werden Schlüssel in der HKLM-Registrierung in einem speziellen Registrierungsschlüssel beibehalten, der nur für das Arbeitsprozesskonto verwendet wird. Schlüssel werden im Ruhezustand mit DPAPI verschlüsselt.

  4. Wenn keine dieser Bedingungen übereinstimmen, werden schlüssel außerhalb des aktuellen Prozesses nicht beibehalten. Wenn der Prozess heruntergefahren wird, gehen alle generierten Schlüssel verloren.

Der Entwickler ist immer in voller Kontrolle und kann außer Kraft setzen, wie und wo Schlüssel gespeichert werden. Die ersten drei oben genannten Optionen sollten gute Standardeinstellungen für die meisten Apps bieten, die die ASP.NET <machineKey-Automatisch-Generation-Routinen> in der Vergangenheit funktionieren. Die endgültige Fallbackoption ist das einzige Szenario, in dem der Entwickler die Konfiguration vorgibt, wenn sie die Schlüsselpersistenz wünschen, aber dieser Fallback tritt nur in seltenen Situationen auf.

Beim Hosten in einem Docker-Container sollten Schlüssel in einem Ordner beibehalten werden, der ein Docker-Volume (ein freigegebenes Volume oder ein hostseitiges Volume, das über die Lebensdauer des Containers hinaus besteht) oder in einem externen Anbieter wie Azure Key Vault oder Redis beibehalten werden. Ein externer Anbieter ist auch in Webfarmszenarien nützlich, wenn Apps nicht auf ein freigegebenes Netzwerkvolume zugreifen können (siehe PersistKeysToFileSystem für weitere Informationen).

Warnung

Wenn der Entwickler die oben beschriebenen Regeln außer Kraft setzt und das Datenschutzsystem auf ein bestimmtes Schlüssel-Repository verweist, ist die automatische Verschlüsselung von Schlüsseln in Rest deaktiviert. Der Ruheschutz kann über die Konfiguration erneut aktiviert werden.

Schlüssellebensdauer

Schlüssel verfügen standardmäßig über eine Lebensdauer von 90 Tagen. Wenn ein Schlüssel abläuft, generiert die App automatisch einen neuen Schlüssel und legt den neuen Schlüssel als aktiven Schlüssel fest. Solange die eingestellten Schlüssel auf dem System verbleiben, kann Ihre App alle mit ihnen geschützten Daten entschlüsseln. Weitere Informationen finden Sie in der Schlüsselverwaltung .

Standardalgorithmen

Der standardmäßige Nutzlastschutzalgorithmus ist AES-256-CBC für Vertraulichkeit und HMACSHA256 für die Authentizität. Ein 512-Bit-Masterschlüssel, der alle 90 Tage geändert wurde, wird verwendet, um die beiden Unterschlüssel zu abgeleitet, die für diese Algorithmen auf einer Pro-Nutzlast-Basis verwendet werden. Weitere Informationen finden Sie unterschlüsselableitung .

Zusätzliche Ressourcen