Teilen über

(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

  • Artikel

Von Rick Anderson

Schlüsselverwaltung

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

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

    • Schlüssel werden bei rest nicht geschützt.
    • Der Ordner DataProtection-Keys stellt den Schlüsselbund für alle Instanzen einer App in einem einzigen Bereitstellungsslot bereit.
    • Separate Bereitstellungsslots, wie Staging und Produktion, verwenden keinen gemeinsamen Schlüsselbund. Wenn Sie zwischen Bereitstellungsslots wechseln, z. B. zwischen Staging und Produktion, oder wenn Sie A/B-Tests durchführen, kann eine App, die Data Protection verwendet, die gespeicherten Daten nicht mit dem Schlüsselbund im vorherigen Slot entschlüsseln. Dies führt dazu, dass Benutzende von einer App abgemeldet werden, die die standardmäßige ASP.NET Core-cookie-Authentifizierung verwendet, da sie Datenschutz zum Schutz ihrer Cookies verwendet. Wenn Sie einen slotunabhängige Schlüsselbund benötigen, verwenden Sie einen externen Schlüsselbundanbieter, 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 gespeichert. Wenn als Betriebssystem Windows verwendet wird, werden die Schlüssel im rest 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 die Schlüssel in der HKLM-Registrierung in einem speziellen Registrierungsschlüssel gespeichert, der nur in der ACL für das Workerprozesskonto angegeben ist. Schlüssel werden im rest Ruhezustand mit DPAPI verschlüsselt.

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

Die Entwickler*innen haben immer die volle Kontrolle und können festlegen, wie und wo die Schlüssel gespeichert werden. Die ersten drei der oben genannten Optionen sollten für die meisten Apps gute Standardwerte liefern, ähnlich wie die ASP.NET-Routinen zur automatischen <machineKey>-Generierung in der Vergangenheit. Die letzte Option ist das einzige Szenario, bei dem die Entwickler*innen die Konfiguration im Voraus angeben müssen, um Schlüsselpersistenz zu erreichen, aber dieser Fallback ist nur in seltenen Fällen notwendig.

Beim Hosting in einem Docker-Container sollten die Schlüssel in einem Ordner aufbewahrt werden, bei dem es sich um ein Docker-Volume (ein freigegebenes Volume oder ein vom Host eingebundenes Volume, das über die Lebensdauer des Containers hinaus bestehen bleibt) oder um einen externen Anbieter wie Azure Key Vault oder Redis handelt. Ein externer Anbieter ist auch in Webfarmszenarien nützlich, wenn Apps nicht auf ein freigegebenes Netzwerkvolume zugreifen können (weitere Informationen siehe PersistKeysToFileSystem).

Warnung

Wenn die Entwickler*innen die oben genannten Regeln außer Kraft setzen und das Data Protection-System auf ein bestimmtes Schlüsselrepository verweisen, wird die automatische Verschlüsselung der Schlüssel im rest deaktiviert. Der Schutz von Daten im restkann über die Konfiguration wieder aktiviert werden.

Lebensdauer der Schlüssel

Schlüssel haben standardmäßig eine Lebensdauer von 90 Tagen. Wenn ein Schlüssel abläuft, generiert die App automatisch einen neuen Schlüssel und legt diesen als aktiven Schlüssel fest. Solange die abgelaufenen Schlüssel auf dem System verbleiben, kann Ihre App alle damit geschützten Daten entschlüsseln. Weitere Informationen finden Sie unter Schlüsselverwaltung.

Standardalgorithmen

Der standardmäßig verwendete Algorithmus zum Schutz von Nutzdaten ist AES-256-CBC für die Vertraulichkeit und HMACSHA256 für die Authentizität. Zum Ableiten der beiden Unterschlüssel für diese Algorithmen auf Basis der jeweiligen Nutzdaten wird ein 512-Bit-Hauptschlüssel verwendet, der alle 90 Tage geändert wird. Weitere Informationen finden Sie unter Ableitung von Unterschlüsseln.

Löschen von Schlüsseln

Durch das Löschen eines Schlüssels können seine geschützten Daten dauerhaft unzugänglich werden. Um dieses Risiko zu verringern, wird empfohlen, Schlüssel nicht zu löschen. Die resultierende Anhäufung von Schlüsseln hat im Allgemeinen minimale Auswirkungen, weil sie klein sind. In Ausnahmefällen, z. B.wenn Dienste extrem lange ausgeführt werden, können Schlüssel gelöscht werden. Nur Schlüssel löschen:

  • Das ist alt (nicht mehr in Gebrauch).
  • Löschen Sie Schlüssel nur, wenn Sie das Risiko eines Datenverlusts nehmen wollen, um Speicherplatz einzusparen.

Wir empfehlen, Datenschutzschlüssel nicht zu löschen.

using Microsoft.AspNetCore.DataProtection.KeyManagement;

var services = new ServiceCollection();
services.AddDataProtection();

var serviceProvider = services.BuildServiceProvider();

var keyManager = serviceProvider.GetService<IKeyManager>();

if (keyManager is IDeletableKeyManager deletableKeyManager)
{
    var utcNow = DateTimeOffset.UtcNow;
    var yearAgo = utcNow.AddYears(-1);

    if (!deletableKeyManager.DeleteKeys(key => key.ExpirationDate < yearAgo))
    {
        Console.WriteLine("Failed to delete keys.");
    }
    else
    {
        Console.WriteLine("Old keys deleted successfully.");
    }
}
else
{
    Console.WriteLine("Key manager does not support deletion.");
}

Zusätzliche Ressourcen

Schlüsselverwaltung

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

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

    • Schlüssel werden bei rest nicht geschützt.
    • Der Ordner DataProtection-Keys stellt den Schlüsselbund für alle Instanzen einer App in einem einzigen Bereitstellungsslot bereit.
    • Separate Bereitstellungsslots, wie Staging und Produktion, verwenden keinen gemeinsamen Schlüsselbund. Wenn Sie zwischen Bereitstellungsslots wechseln, z. B. zwischen Staging und Produktion, oder wenn Sie A/B-Tests durchführen, kann eine App, die Data Protection verwendet, die gespeicherten Daten nicht mit dem Schlüsselbund im vorherigen Slot entschlüsseln. Dies führt dazu, dass Benutzende von einer App abgemeldet werden, die die standardmäßige ASP.NET Core-cookie-Authentifizierung verwendet, da sie Datenschutz zum Schutz ihrer Cookies verwendet. Wenn Sie einen slotunabhängige Schlüsselbund benötigen, verwenden Sie einen externen Schlüsselbundanbieter, 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 gespeichert. Wenn als Betriebssystem Windows verwendet wird, werden die Schlüssel im rest 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 die Schlüssel in der HKLM-Registrierung in einem speziellen Registrierungsschlüssel gespeichert, der nur in der ACL für das Workerprozesskonto angegeben ist. Schlüssel werden im rest Ruhezustand mit DPAPI verschlüsselt.

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

Die Entwickler*innen haben immer die volle Kontrolle und können festlegen, wie und wo die Schlüssel gespeichert werden. Die ersten drei der oben genannten Optionen sollten für die meisten Apps gute Standardwerte liefern, ähnlich wie die ASP.NET-Routinen zur automatischen <machineKey>-Generierung in der Vergangenheit. Die letzte Option ist das einzige Szenario, bei dem die Entwickler*innen die Konfiguration im Voraus angeben müssen, um Schlüsselpersistenz zu erreichen, aber dieser Fallback ist nur in seltenen Fällen notwendig.

Beim Hosting in einem Docker-Container sollten die Schlüssel in einem Ordner aufbewahrt werden, bei dem es sich um ein Docker-Volume (ein freigegebenes Volume oder ein vom Host eingebundenes Volume, das über die Lebensdauer des Containers hinaus bestehen bleibt) oder um einen externen Anbieter wie Azure Key Vault oder Redis handelt. Ein externer Anbieter ist auch in Webfarmszenarien nützlich, wenn Apps nicht auf ein freigegebenes Netzwerkvolume zugreifen können (weitere Informationen siehe PersistKeysToFileSystem).

Warnung

Wenn die Entwickler*innen die oben genannten Regeln außer Kraft setzen und das Data Protection-System auf ein bestimmtes Schlüsselrepository verweisen, wird die automatische Verschlüsselung der Schlüssel im rest deaktiviert. Der Schutz von Daten im restkann über die Konfiguration wieder aktiviert werden.

Lebensdauer der Schlüssel

Schlüssel haben standardmäßig eine Lebensdauer von 90 Tagen. Wenn ein Schlüssel abläuft, generiert die App automatisch einen neuen Schlüssel und legt diesen als aktiven Schlüssel fest. Solange die abgelaufenen Schlüssel auf dem System verbleiben, kann Ihre App alle damit geschützten Daten entschlüsseln. Weitere Informationen finden Sie unter Schlüsselverwaltung.

Standardalgorithmen

Der standardmäßig verwendete Algorithmus zum Schutz von Nutzdaten ist AES-256-CBC für die Vertraulichkeit und HMACSHA256 für die Authentizität. Zum Ableiten der beiden Unterschlüssel für diese Algorithmen auf Basis der jeweiligen Nutzdaten wird ein 512-Bit-Hauptschlüssel verwendet, der alle 90 Tage geändert wird. Weitere Informationen finden Sie unter Ableitung von Unterschlüsseln.

Zusätzliche Ressourcen