Správa a životnost klíčů ochrany dat v ASP.NET Core
Autor: Rick Anderson
Správa klíčů
Aplikace se pokusí zjistit jeho provozní prostředí a zpracovat konfiguraci klíče samostatně.
Pokud je aplikace hostovaná v Aplikace Azure, klíče se zachovají do složky %HOME%\ASP.NET\DataProtection-Keys. Tato složka je zálohovaná síťovým úložištěm a synchronizuje se napříč všemi počítači, které jsou hostitelem příslušné aplikace.
- Klíče nejsou chráněné na adrese rest.
- Složka DataProtection-Keys poskytuje okruh klíčů všem instancím aplikace v jednom slotu nasazení.
- Jednotlivé sloty nasazení, jako jsou přípravný a produkční, nesdílejí svazky klíčů. Když prohodíte sloty nasazení, například prohození přípravného prostředí do produkčního prostředí nebo pomocí testování A/B, nebude moct žádná aplikace používající ochranu dat dešifrovat uložená data pomocí okruhu klíčů uvnitř předchozího slotu. To vede k tomu, že se uživatelé odhlásí z aplikace, která používá standardní ověřování ASP.NET Core cookie , protože k ochraně souborů cookie používá ochranu dat. Pokud si přejete okruhy klíčů nezávislých na slotech, použijte zprostředkovatele externího okruhu klíčů, jako je Azure Blob Storage, Azure Key Vault, úložiště SQL nebo mezipaměť Redis.
Pokud je profil uživatele dostupný, klíče se zachovají do složky %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Pokud je operační systém Windows, klíče se šifrují pomocí rest rozhraní DPAPI.
Musí být povolený také atribut setProfileEnvironment fondu aplikací. Výchozí hodnota atributu
setProfileEnvironment
jetrue
. V některých scénářích (například v operačním systému Windows) je atributsetProfileEnvironment
nastavený na hodnotufalse
. Pokud se klíče neuchovávají v adresáři profilu uživatele podle očekávání:- Přejděte do složky %windir%/system32/inetsrv/config.
- Otevřete soubor applicationHost.config.
- Vyhledejte element
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>
. - Ověřte, že není k dispozici atribut
setProfileEnvironment
, aby se použila výchozí hodnotatrue
, nebo explicitně nastavte hodnotu tohoto atributu natrue
.
Pokud je aplikace hostovaná ve službě IIS, klíče se zachovají do registru HKLM ve speciálním klíči registru, který je ACLLed pouze pro účet pracovního procesu. Klíče se šifrují pomocí rest rozhraní DPAPI.
Pokud se žádná z těchto podmínek neshoduje, klíče se nezachovají mimo aktuální proces. Když se proces vypne, ztratí se všechny vygenerované klíče.
Vývojář je vždy v plném řízení a může přepsat, jak a kde se klíče ukládají. První tři výše uvedené možnosti by měly poskytovat dobré výchozí hodnoty pro většinu aplikací podobných tomu, jak <v minulosti fungovaly rutiny automatického generování ASP.NET machineKey> . Poslední záložní možnost je jediný scénář, který vyžaduje, aby vývojář zadal konfiguraci předem, pokud chce trvalost klíče, ale tato záložní varianta se vyskytuje pouze ve výjimečných situacích.
Při hostování v kontejneru Dockeru by se klíče měly uchovávat ve složce, která je svazkem Dockeru (sdíleným svazkem nebo svazkem připojeným k hostiteli, který se zachovává nad rámec životnosti kontejneru) nebo v externím poskytovateli, jako je Azure Key Vault nebo Redis. Externí zprostředkovatel je také užitečný ve scénářích webové farmy, pokud aplikace nemají přístup ke sdílenému síťovému svazku (další informace najdete v části PersistKeysToFileSystem ).
Upozorňující
Pokud vývojář přepíše výše uvedená pravidla a odkazuje systém Ochrany dat na konkrétní úložiště klíčů, automatické šifrování klíčů rest je zakázané. Ochranu at-at-canrest be re-enabled via configuration.
Životnost klíče
Klíče mají ve výchozím nastavení 90denní životnost. Když vyprší platnost klíče, aplikace automaticky vygeneruje nový klíč a nastaví nový klíč jako aktivní klíč. Dokud vyřazené klíče zůstanou v systému, může vaše aplikace dešifrovat všechna data chráněná s nimi. Další informace najdete v tématu Správa klíčů.
Výchozí algoritmy
Výchozí použitý algoritmus ochrany datové části je AES-256-CBC pro důvěrnost a HMACSHA256 pro pravost. 512bitový hlavní klíč, změněný každých 90 dnů, se používá k odvození dvou dílčích klíčů používaných pro tyto algoritmy na základě datové části. Další informace najdete v části Odvození podklíče .
Odstranění klíčů
Odstraněním klíče jsou chráněná data trvale nepřístupná. Pokud chcete toto riziko zmírnit, doporučujeme neodstraňovat klíče. Výsledná akumulace klíčů má obecně minimální dopad, protože jsou malé. Ve výjimečných případech, jako jsou extrémně dlouhotrvající služby, je možné klíče odstranit. Odstranit pouze klíče:
- Jsou staré (už se nepoužívají).
- Pokud můžete přijmout riziko ztráty dat výměnou za úspory úložiště.
Nedoporučujeme odstraňovat klíče ochrany dat.
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.");
}
Další materiály
Správa klíčů
Aplikace se pokusí zjistit jeho provozní prostředí a zpracovat konfiguraci klíče samostatně.
Pokud je aplikace hostovaná v Aplikace Azure, klíče se zachovají do složky %HOME%\ASP.NET\DataProtection-Keys. Tato složka je zálohovaná síťovým úložištěm a synchronizuje se napříč všemi počítači, které jsou hostitelem příslušné aplikace.
- Klíče nejsou chráněné na adrese rest.
- Složka DataProtection-Keys poskytuje okruh klíčů všem instancím aplikace v jednom slotu nasazení.
- Jednotlivé sloty nasazení, jako jsou přípravný a produkční, nesdílejí svazky klíčů. Když prohodíte sloty nasazení, například prohození přípravného prostředí do produkčního prostředí nebo pomocí testování A/B, nebude moct žádná aplikace používající ochranu dat dešifrovat uložená data pomocí okruhu klíčů uvnitř předchozího slotu. To vede k tomu, že se uživatelé odhlásí z aplikace, která používá standardní ověřování ASP.NET Core cookie , protože k ochraně souborů cookie používá ochranu dat. Pokud si přejete okruhy klíčů nezávislých na slotech, použijte zprostředkovatele externího okruhu klíčů, jako je Azure Blob Storage, Azure Key Vault, úložiště SQL nebo mezipaměť Redis.
Pokud je profil uživatele dostupný, klíče se zachovají do složky %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Pokud je operační systém Windows, klíče se šifrují pomocí rest rozhraní DPAPI.
Musí být povolený také atribut setProfileEnvironment fondu aplikací. Výchozí hodnota atributu
setProfileEnvironment
jetrue
. V některých scénářích (například v operačním systému Windows) je atributsetProfileEnvironment
nastavený na hodnotufalse
. Pokud se klíče neuchovávají v adresáři profilu uživatele podle očekávání:- Přejděte do složky %windir%/system32/inetsrv/config.
- Otevřete soubor applicationHost.config.
- Vyhledejte element
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>
. - Ověřte, že není k dispozici atribut
setProfileEnvironment
, aby se použila výchozí hodnotatrue
, nebo explicitně nastavte hodnotu tohoto atributu natrue
.
Pokud je aplikace hostovaná ve službě IIS, klíče se zachovají do registru HKLM ve speciálním klíči registru, který je ACLLed pouze pro účet pracovního procesu. Klíče se šifrují pomocí rest rozhraní DPAPI.
Pokud se žádná z těchto podmínek neshoduje, klíče se nezachovají mimo aktuální proces. Když se proces vypne, ztratí se všechny vygenerované klíče.
Vývojář je vždy v plném řízení a může přepsat, jak a kde se klíče ukládají. První tři výše uvedené možnosti by měly poskytovat dobré výchozí hodnoty pro většinu aplikací podobných tomu, jak <v minulosti fungovaly rutiny automatického generování ASP.NET machineKey> . Poslední záložní možnost je jediný scénář, který vyžaduje, aby vývojář zadal konfiguraci předem, pokud chce trvalost klíče, ale tato záložní varianta se vyskytuje pouze ve výjimečných situacích.
Při hostování v kontejneru Dockeru by se klíče měly uchovávat ve složce, která je svazkem Dockeru (sdíleným svazkem nebo svazkem připojeným k hostiteli, který se zachovává nad rámec životnosti kontejneru) nebo v externím poskytovateli, jako je Azure Key Vault nebo Redis. Externí zprostředkovatel je také užitečný ve scénářích webové farmy, pokud aplikace nemají přístup ke sdílenému síťovému svazku (další informace najdete v části PersistKeysToFileSystem ).
Upozorňující
Pokud vývojář přepíše výše uvedená pravidla a odkazuje systém Ochrany dat na konkrétní úložiště klíčů, automatické šifrování klíčů rest je zakázané. Ochranu at-at-canrest be re-enabled via configuration.
Životnost klíče
Klíče mají ve výchozím nastavení 90denní životnost. Když vyprší platnost klíče, aplikace automaticky vygeneruje nový klíč a nastaví nový klíč jako aktivní klíč. Dokud vyřazené klíče zůstanou v systému, může vaše aplikace dešifrovat všechna data chráněná s nimi. Další informace najdete v tématu Správa klíčů.
Výchozí algoritmy
Výchozí použitý algoritmus ochrany datové části je AES-256-CBC pro důvěrnost a HMACSHA256 pro pravost. 512bitový hlavní klíč, změněný každých 90 dnů, se používá k odvození dvou dílčích klíčů používaných pro tyto algoritmy na základě datové části. Další informace najdete v části Odvození podklíče .