Gestione e durata delle chiavi di protezione dati in ASP.NET Core
Gestione delle chiavi
L'app tenta di rilevare l'ambiente operativo e gestire autonomamente la configurazione della chiave.
Se l'app è ospitata in app Azure, le chiavi vengono mantenute nella cartella %HOME%\ASP.NET\DataProtection-Keys. La cartella è associata all'archiviazione di rete e sincronizzata in tutti i computer che ospitano l'app.
- Le chiavi non sono protette in rest.
- La cartella DataProtection-Keys fornisce l'anello di chiave a tutte le istanze di un'app in un singolo slot di distribuzione.
- Gli slot di distribuzione separati, ad esempio gli slot di gestione temporanea e di produzione, non condividono un KeyRing. Quando si scambia tra slot di distribuzione, ad esempio lo scambio di staging in produzione o l'uso di test A/B, qualsiasi app che usa Protezione dati non sarà in grado di decrittografare i dati archiviati usando l'anello di tasti all'interno dello slot precedente. In questo modo, gli utenti vengono disconnessi da un'app che usa l'autenticazione standard ASP.NET Core cookie , perché usa la protezione dei dati per proteggere i cookie. Se si desiderano anelli di chiave indipendenti da slot, usare un provider del circuito di chiavi esterno, ad esempio Archiviazione BLOB di Azure, Azure Key Vault, un archivio SQL o una cache Redis.
Se il profilo utente è disponibile, le chiavi vengono mantenute nella cartella %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Se il sistema operativo è Windows, le chiavi vengono crittografate rest tramite DPAPI.
Deve essere abilitato anche l'attributo setProfileEnvironment del pool di app. Il valore predefinito di
setProfileEnvironmentètrue. In alcuni scenari (ad esempio, per il sistema operativo Windows),setProfileEnvironmentè impostato sufalse. Se le chiavi non vengono archiviate nella directory del profilo utente come previsto:- Passare alla cartella %windir%/system32/inetsrv/config.
- Aprire il file applicationHost.config.
- Individuare l'elemento
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>. - Verificare che l'attributo
setProfileEnvironmentnon sia presente, condizione che corrisponde all'impostazione predefinitatrue, o impostare in modo esplicito il valore dell'attributo sutrue.
Se l'app è ospitata in IIS, le chiavi vengono rese persistenti nel Registro di sistema HKLM in una chiave del Registro di sistema speciale che è ACLled solo per l'account del processo di lavoro. Le chiavi vengono crittografate rest tramite DPAPI.
Se nessuna di queste condizioni corrisponde, le chiavi non vengono mantenute al di fuori del processo corrente. Quando il processo viene arrestato, tutte le chiavi generate andranno perse.
Lo sviluppatore è sempre in controllo completo e può eseguire l'override di come e dove vengono archiviate le chiavi. Le prime tre opzioni precedenti dovrebbero fornire impostazioni predefinite valide per la maggior parte delle app in modo analogo a come funzionano le <routine di generazione automatica machineKey> ASP.NET in passato. L'opzione finale di fallback è l'unico scenario che richiede allo sviluppatore di specificare la configurazione in anticipo se vuole la persistenza delle chiavi, ma questo fallback si verifica solo in situazioni rare.
Quando si ospita in un contenitore Docker, le chiavi devono essere mantenute in una cartella che è un volume Docker (un volume condiviso o un volume montato su host che persiste oltre la durata del contenitore) o in un provider esterno, ad esempio Azure Key Vault o Redis. Un provider esterno è utile anche negli scenari di Web farm se le app non riescono ad accedere a un volume di rete condiviso (vedere PersistKeysToFileSystem per altre informazioni).
Avviso
Se lo sviluppatore esegue l'override delle regole descritte in precedenza e punta il sistema di protezione dei dati in un repository di chiavi specifico, la crittografia automatica delle chiavi in rest è disabilitata. La protezione at-rest può essere riabilitata tramite la configurazione.
Durata chiave
Per impostazione predefinita, le chiavi hanno una durata di 90 giorni. Quando una chiave scade, l'app genera automaticamente una nuova chiave e imposta la nuova chiave come chiave attiva. Finché le chiavi ritirate rimangono nel sistema, l'app può decrittografare tutti i dati protetti con essi. Per altre informazioni, vedere Gestione delle chiavi.
Algoritmi predefiniti
L'algoritmo di protezione del payload predefinito usato è AES-256-CBC per la riservatezza e HMACSHA256 per l'autenticità. Una chiave master a 512 bit, modificata ogni 90 giorni, viene usata per derivare le due sottochiavi usate per questi algoritmi in base al payload. Per altre informazioni, vedere derivazione della sottochiave .
Eliminare le chiavi
L'eliminazione di una chiave rende i dati protetti in modo permanente inaccessibili. Per ridurre il rischio, è consigliabile non eliminare le chiavi. L'accumulo di chiavi risultante in genere ha un impatto minimo perché sono di piccole dimensioni. In casi eccezionali, ad esempio servizi estremamente a esecuzione prolungata, è possibile eliminare le chiavi. Elimina solo le chiavi:
- Vecchio (non più in uso).
- Quando è possibile accettare il rischio di perdita di dati in cambio di risparmi di archiviazione.
È consigliabile non eliminare le chiavi di protezione dei dati.
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.");
}
Risorse aggiuntive
Gestione delle chiavi
L'app tenta di rilevare l'ambiente operativo e gestire autonomamente la configurazione della chiave.
Se l'app è ospitata in app Azure, le chiavi vengono mantenute nella cartella %HOME%\ASP.NET\DataProtection-Keys. La cartella è associata all'archiviazione di rete e sincronizzata in tutti i computer che ospitano l'app.
- Le chiavi non sono protette in rest.
- La cartella DataProtection-Keys fornisce l'anello di chiave a tutte le istanze di un'app in un singolo slot di distribuzione.
- Gli slot di distribuzione separati, ad esempio gli slot di gestione temporanea e di produzione, non condividono un KeyRing. Quando si scambia tra slot di distribuzione, ad esempio lo scambio di staging in produzione o l'uso di test A/B, qualsiasi app che usa Protezione dati non sarà in grado di decrittografare i dati archiviati usando l'anello di tasti all'interno dello slot precedente. In questo modo, gli utenti vengono disconnessi da un'app che usa l'autenticazione standard ASP.NET Core cookie , perché usa la protezione dei dati per proteggere i cookie. Se si desiderano anelli di chiave indipendenti da slot, usare un provider del circuito di chiavi esterno, ad esempio Archiviazione BLOB di Azure, Azure Key Vault, un archivio SQL o una cache Redis.
Se il profilo utente è disponibile, le chiavi vengono mantenute nella cartella %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Se il sistema operativo è Windows, le chiavi vengono crittografate rest tramite DPAPI.
Deve essere abilitato anche l'attributo setProfileEnvironment del pool di app. Il valore predefinito di
setProfileEnvironmentètrue. In alcuni scenari (ad esempio, per il sistema operativo Windows),setProfileEnvironmentè impostato sufalse. Se le chiavi non vengono archiviate nella directory del profilo utente come previsto:- Passare alla cartella %windir%/system32/inetsrv/config.
- Aprire il file applicationHost.config.
- Individuare l'elemento
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>. - Verificare che l'attributo
setProfileEnvironmentnon sia presente, condizione che corrisponde all'impostazione predefinitatrue, o impostare in modo esplicito il valore dell'attributo sutrue.
Se l'app è ospitata in IIS, le chiavi vengono rese persistenti nel Registro di sistema HKLM in una chiave del Registro di sistema speciale che è ACLled solo per l'account del processo di lavoro. Le chiavi vengono crittografate rest tramite DPAPI.
Se nessuna di queste condizioni corrisponde, le chiavi non vengono mantenute al di fuori del processo corrente. Quando il processo viene arrestato, tutte le chiavi generate andranno perse.
Lo sviluppatore è sempre in controllo completo e può eseguire l'override di come e dove vengono archiviate le chiavi. Le prime tre opzioni precedenti dovrebbero fornire impostazioni predefinite valide per la maggior parte delle app in modo analogo a come funzionano le <routine di generazione automatica machineKey> ASP.NET in passato. L'opzione finale di fallback è l'unico scenario che richiede allo sviluppatore di specificare la configurazione in anticipo se vuole la persistenza delle chiavi, ma questo fallback si verifica solo in situazioni rare.
Quando si ospita in un contenitore Docker, le chiavi devono essere mantenute in una cartella che è un volume Docker (un volume condiviso o un volume montato su host che persiste oltre la durata del contenitore) o in un provider esterno, ad esempio Azure Key Vault o Redis. Un provider esterno è utile anche negli scenari di Web farm se le app non riescono ad accedere a un volume di rete condiviso (vedere PersistKeysToFileSystem per altre informazioni).
Avviso
Se lo sviluppatore esegue l'override delle regole descritte in precedenza e punta il sistema di protezione dei dati in un repository di chiavi specifico, la crittografia automatica delle chiavi in rest è disabilitata. La protezione at-rest può essere riabilitata tramite la configurazione.
Durata chiave
Per impostazione predefinita, le chiavi hanno una durata di 90 giorni. Quando una chiave scade, l'app genera automaticamente una nuova chiave e imposta la nuova chiave come chiave attiva. Finché le chiavi ritirate rimangono nel sistema, l'app può decrittografare tutti i dati protetti con essi. Per altre informazioni, vedere Gestione delle chiavi.
Algoritmi predefiniti
L'algoritmo di protezione del payload predefinito usato è AES-256-CBC per la riservatezza e HMACSHA256 per l'autenticità. Una chiave master a 512 bit, modificata ogni 90 giorni, viene usata per derivare le due sottochiavi usate per questi algoritmi in base al payload. Per altre informazioni, vedere derivazione della sottochiave .
