Dela via


Hantering och livslängd för dataskyddsnycklar i ASP.NET Core

Av Rick Anderson

Nyckelhantering

Appen försöker identifiera sin driftsmiljö och hantera nyckelkonfigurationen på egen hand.

  1. Om appen finns i Azure Apps sparas nycklarna i mappen %HOME%\ASP.NET\DataProtection-Keys . Den här mappen backas upp av nätverkslagring och synkroniseras på alla datorer som är värdar för appen.

    • Nycklar skyddas inte i vila.
    • Mappen DataProtection-Keys tillhandahåller nyckelringen till alla instanser av en app i ett enda distributionsfack.
    • Separata utplaceringsplatser, till exempel Mellanlagring och Produktion, delar inte samma nyckelring. När du byter mellan distributionsfack, till exempel växlar mellanlagring till produktion eller använder A/B-testning, kommer alla appar som använder Dataskydd inte att kunna dekryptera lagrade data med hjälp av nyckelringen i föregående fack. Detta leder till att användare loggas ut från en app som använder standard-ASP.NET Core-autentisering cookie , eftersom den använder Dataskydd för att skydda sina cookies. Om du vill ha fackoberoende nyckelringar använder du en extern nyckelringsleverantör, till exempel Azure Blob Storage, Azure Key Vault, en SQL-lagring eller Redis-cache.
  2. Om användarprofilen är tillgänglig sparas nycklarna i mappen %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Om operativsystemet är Windows krypteras nycklarna i vila med DPAPI.

    Apppoolens setProfileEnvironment-attribut måste också vara aktiverat. Standardvärdet för setProfileEnvironment är true. I vissa scenarier (till exempel Windows OS) är setProfileEnvironment inställt på false. Om nycklar inte lagras i användarprofilkatalogen som förväntat:

    1. Gå till mappen %windir%/system32/inetsrv/config .
    2. Öppna filenapplicationHost.config .
    3. Leta upp elementet <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
    4. Bekräfta att attributet setProfileEnvironment inte finns, vilket standardvärdet är true, eller ange attributets värde som true.
  3. Om appen finns i IIS sparas nycklarna i HKLM-registret i en särskild registernyckel som endast är ACLed till arbetsprocesskontot. Nycklar krypteras i vila med DPAPI.

  4. Om inget av dessa villkor matchar, sparas nycklar inte utanför den aktuella processen. När processen stängs av går alla genererade nycklar förlorade.

Utvecklaren har alltid fullständig kontroll och kan åsidosätta hur och var nycklar lagras. De första tre alternativen ovan bör ge bra standardvärden för de flesta appar som liknar hur ASP.NET <machineKey> auto-generation rutiner fungerade tidigare. Det sista reservalternativet är det enda scenario som kräver att utvecklaren anger konfigurationen i förväg om de vill ha nyckelpersistence, men den här reserven sker bara i sällsynta situationer.

När du är värd för en Docker-container bör nycklar sparas i en mapp som är en Docker-volym (en delad volym eller en värdmonterad volym som finns kvar utanför containerns livslängd) eller i en extern provider, till exempel Azure Key Vault eller Redis. En extern provider är också användbar i webbgruppsscenarier om appar inte kan komma åt en delad nätverksvolym (se PersistKeysToFileSystem för mer information).

Varning

Om utvecklaren åsidosätter reglerna ovan och pekar dataskyddssystemet på en specifik nyckellagringsplats inaktiveras automatisk kryptering av vilande nycklar. Vilande skydd kan återaktiveras via konfiguration.

Nyckellivslängd

Nycklar har en livslängd på 90 dagar som standard. När en nyckel upphör att gälla genererar appen automatiskt en ny nyckel och anger den nya nyckeln som den aktiva nyckeln. Så länge tillbakadragna nycklar finns kvar i systemet kan appen dekryptera alla data som skyddas med dem. Mer information finns i Nyckelhantering .

Standardalgoritmer

Standardalgoritmen för nyttolastskydd som används är AES-256-CBC för konfidentialitet och HMACSHA256 för äkthet. En 512-bitars huvudnyckel, som ändras var 90:e dag, används för att härleda de två undernycklar som används för dessa algoritmer per nyttolast. För mer information, se härledning av undernycklar.

Ta bort nycklar

Om du tar bort en nyckel blir dess skyddade data permanent otillgängliga. För att minska den risken rekommenderar vi att du inte tar bort nycklar. Den resulterande ackumuleringen av nycklar har vanligtvis minimal påverkan eftersom de är små. I undantagsfall, till exempel extremt långvariga tjänster, kan nycklar tas bort. Ta endast bort nycklar:

  • Som är gamla (används inte längre).
  • När du kan acceptera risken för dataförlust i utbyte mot lagringsbesparingar.

Vi rekommenderar att du inte tar bort dataskyddsnycklar.

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.");
}

Ytterligare resurser

Nyckelhantering

Appen försöker identifiera sin driftsmiljö och hantera nyckelkonfigurationen på egen hand.

  1. Om appen finns i Azure Apps sparas nycklarna i mappen %HOME%\ASP.NET\DataProtection-Keys . Den här mappen backas upp av nätverkslagring och synkroniseras på alla datorer som är värdar för appen.

    • Nycklar skyddas inte i vila.
    • Mappen DataProtection-Keys tillhandahåller nyckelringen till alla instanser av en app i ett enda distributionsfack.
    • Separata utplaceringsplatser, till exempel Mellanlagring och Produktion, delar inte samma nyckelring. När du byter mellan distributionsfack, till exempel växlar mellanlagring till produktion eller använder A/B-testning, kommer alla appar som använder Dataskydd inte att kunna dekryptera lagrade data med hjälp av nyckelringen i föregående fack. Detta leder till att användare loggas ut från en app som använder standard-ASP.NET Core-autentisering cookie , eftersom den använder Dataskydd för att skydda sina cookies. Om du vill ha fackoberoende nyckelringar använder du en extern nyckelringsleverantör, till exempel Azure Blob Storage, Azure Key Vault, SQL-lagring eller Redis-cache.
  2. Om användarprofilen är tillgänglig sparas nycklarna i mappen %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Om operativsystemet är Windows krypteras nycklarna i vila med DPAPI.

    Apppoolens setProfileEnvironment-attribut måste också vara aktiverat. Standardvärdet för setProfileEnvironment är true. I vissa scenarier (till exempel Windows OS) är setProfileEnvironment inställt på false. Om nycklar inte lagras i användarprofilkatalogen som förväntat:

    1. Gå till mappen %windir%/system32/inetsrv/config .
    2. Öppna filenapplicationHost.config .
    3. Leta upp elementet <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
    4. Bekräfta att attributet setProfileEnvironment inte finns, vilket standardvärdet är true, eller ange attributets värde som true.
  3. Om appen är värd i IIS sparas appens nycklar i HKLM-registret i en särskild registernyckel som endast är åtkomlig för arbetsprocesskontot. Nycklar krypteras i vila med DPAPI.

  4. Om inget av dessa villkor matchar sparas inte nycklar utanför den aktuella processen. När processen stängs av går alla genererade nycklar förlorade.

Utvecklaren har alltid fullständig kontroll och kan åsidosätta hur och var nycklar lagras. De första tre alternativen ovan bör ge bra standardvärden för de flesta appar som liknar hur ASP.NET <machineKey> auto-generation rutiner fungerade tidigare. Det sista reservalternativet är det enda scenario som kräver att utvecklaren anger konfigurationen i förväg om de vill ha nyckelpersistence, men den här reserven sker bara i sällsynta situationer.

När du är värd för en Docker-container bör nycklar sparas i en mapp som är en Docker-volym (en delad volym eller en värdmonterad volym som finns kvar utanför containerns livslängd) eller i en extern provider, till exempel Azure Key Vault eller Redis. En extern provider är också användbar i webbgruppsscenarier om appar inte kan komma åt en delad nätverksvolym (se PersistKeysToFileSystem för mer information).

Varning

Om utvecklaren åsidosätter reglerna ovan och pekar dataskyddssystemet på en specifik nyckellagringsplats inaktiveras automatisk kryptering av vilande nycklar. Vilande skydd kan återaktiveras via konfiguration.

Nyckellivslängd

Nycklar har en livslängd på 90 dagar som standard. När en nyckel upphör att gälla genererar appen automatiskt en ny nyckel och anger den nya nyckeln som den aktiva nyckeln. Så länge tillbakadragna nycklar finns kvar i systemet kan appen dekryptera alla data som skyddas med dem. Mer information finns i Nyckelhantering .

Standardalgoritmer

Standardalgoritmen för nyttolastskydd som används är AES-256-CBC för konfidentialitet och HMACSHA256 för äkthet. En 512-bitars huvudnyckel, som ändras var 90:e dag, används för att härleda de två undernycklar som används för dessa algoritmer per nyttolast. För mer information, se härledning av undernyckel.

Ytterligare resurser