Konfigurace ochrany dat ASP.NET Core

Když se systém Ochrany dat inicializuje, použije výchozí nastavení na základě provozního prostředí. Tato nastavení jsou vhodná pro aplikace spuštěné na jednom počítači. Existují ale případy, kdy vývojář může chtít změnit výchozí nastavení:

• Aplikace se rozprostírá na více počítačích.
• Z důvodů dodržování předpisů.

V těchto scénářích systém Ochrany dat nabízí bohaté rozhraní API pro konfiguraci.

Warning

Podobně jako v konfiguračních souborech by měl být okruh klíčů ochrany dat chráněný pomocí příslušných oprávnění. Můžete zvolit šifrování klíčů v klidovém stavu, ale nezabráníte tomu, aby kyberútočníci vytvářeli nové klíče. V důsledku toho je ovlivněno zabezpečení vaší aplikace. Umístění úložiště nakonfigurované pomocí ochrany dat by mělo mít omezený přístup k samotné aplikaci, podobně jako byste chránili konfigurační soubory. Pokud se například rozhodnete uložit okruh klíčů na disk, použijte oprávnění systému souborů. Ujistěte se, že jen identita, pod kterou běží vaše webová aplikace, má přístup pro čtení, zápis a vytváření do tohoto adresáře. Pokud používáte Službu Azure Blob Storage, pouze webová aplikace by měla mít možnost číst, zapisovat nebo vytvářet nové položky v úložišti objektů blob atd.

Rozšiřující metoda AddDataProtection vrátí hodnotu IDataProtectionBuilder. IDataProtectionBuilder zveřejňuje rozšiřující metody, které můžete použít zřetězit a nakonfigurovat možnosti ochrany dat.

Note

Tento článek byl napsán pro aplikaci, která běží v kontejneru Dockeru. V kontejneru Docker má aplikace vždy stejnou cestu a tudíž stejný identifikátor aplikace. Aplikace, které musí běžet v několika prostředích (například v místním a nasazeném prostředí), musí nastavit výchozí diskriminátor aplikace pro dané prostředí. Spuštění aplikace ve více prostředích je nad rámec tohoto článku.

Následující balíčky NuGet jsou vyžadovány pro rozšíření Ochrany dat používaná v tomto článku:

• Azure.Extensions.AspNetCore.DataProtection.Blobs
• Azure.Extensions.AspNetCore.DataProtection.Keys

Ochrana klíčů pomocí služby Azure Key Vault (ProtectKeysWithAzureKeyVault)

Pokud chcete pracovat s Azure Key Vaultem místně pomocí přihlašovacích údajů pro vývojáře, přihlaste se ke svému účtu úložiště v sadě Visual Studio nebo se přihlaste pomocí Azure CLI. Pokud jste ještě nenainstalovali Azure CLI, přečtěte si, jak nainstalovat Azure CLI. Pokud nepoužíváte Visual Studio, můžete na panelu Developer PowerShellu v sadě Visual Studio nebo v příkazovém prostředí spustit následující příkaz:

az login

Další informace najdete v tématu Přihlášení k Azure pomocí vývojářských nástrojů.

Při zřizování trezoru klíčů na portálu Entra nebo Azure Portal:

• Nakonfigurujte trezor klíčů tak, aby používal řízení přístupu na základě role v Azure (RABC). Pokud nepracujete na Azure Virtual Network, včetně místního vývoje a testování, ověřte, že je ve veřejném přístupu v kroku Sítěpovoleno (zaškrtnuto). Povolení veřejného přístupu zveřejňuje jenom koncový bod trezoru klíčů. Pro přístup se stále vyžadují ověřené účty.

• Vytvořte spravovanou Identity službu Azure (nebo přidejte roli do existujícího spravovaného Identity, kterou plánujete použít) s rolí Key Vault Crypto User. Přiřaďte spravované Identity službě Azure App Service, která hostuje nasazení: Nastavení>Identity>uživatelsky přiřazené>Přidat.

  Note

  Pokud také plánujete spustit aplikaci místně s autorizovaným uživatelem pro přístup k objektům blob pomocí Azure CLI nebo ověřování služby Azure v sadě Visual Studio, přidejte svůj uživatelský účet Azure pro vývojáře do řízení přístupu (IAM) s rolí uživatele Key Vault Crypto. Pokud chcete použít Azure CLI prostřednictvím Visual Studio, spusťte az login příkaz z panelu Developer PowerShellu a postupujte podle pokynů k ověření nájemce.

• Pokud je šifrování klíčů aktivní, obsahují klíče v souboru klíče komentář "This key is encrypted with Azure Key Vault." Po spuštění aplikace vyberte příkaz Zobrazit/upravit z místní nabídky na konci řádku klíče, abyste potvrdili, že klíč existuje se zabezpečením trezoru klíčů.

• Volitelně můžete povolit automatickou rotaci klíčů v trezoru klíčů bez obav z dešifrování dat pomocí klíčů ochrany dat založených na klíčích trezoru, jejichž platnost vypršela nebo byly obměněny. Každý vygenerovaný klíč ochrany dat obsahuje odkaz na klíč trezoru klíčů, který se používá k zašifrování. Ujistěte se, že zachováváte klíče z klíčového trezoru s vypršenou platností a neodstraňujte je. Použijte také identifikátor klíče bez verzí v konfiguraci trezoru klíčů aplikace, kde není na konci identifikátoru umístěný žádný identifikátor GUID klíče (například: https://contoso.vault.azure.net/keys/data-protection). Použijte podobnou dobu rotace pro oba klíče, přičemž klíč trezoru klíčů se obměňuje častěji než klíč ochrany dat, aby se zajistilo, že se při obměně klíče ochrany dat použije nový klíč trezoru klíčů.

Ochrana klíčů pomocí služby Azure Key Vault implementuje IXmlEncryptor, který deaktivuje nastavení automatické ochrany dat, včetně umístění úložiště svazku klíčů. Pokud chcete nakonfigurovat poskytovatele služby Azure Blob Storage tak, aby ukládal klíče do úložiště objektů blob, postupujte podle pokynů v poskytovatelích úložiště klíčů v ASP.NET Core a volejte jedno z PersistKeysToAzureBlobStorage přetížení v aplikaci. Následující příklad používá přetížení, které přijímá identifikátor URI objektu blob a pověření tokenu (TokenCredential), spoléhající se na službu Azure Managed Identity pro řízení přístupu na základě role (RBAC).

Pokud chcete nakonfigurovat poskytovatele Azure Key Vault, zavolejte jednu z přetížených metod ProtectKeysWithAzureKeyVault. Následující příklad používá přetížení, které přijímá identifikátor klíče a přihlašovací údaje tokenu (TokenCredential), spoléhá na spravovanou entitu Identity pro RBAC v produkčním prostředí (ManagedIdentityCredential) nebo na DefaultAzureCredential během vývoje a testování. Jiná přetížení přijímají klienta trezoru klíčů nebo ID klienta aplikace s tajným klíčem klienta. Další informace najdete v tématu Poskytovatelé úložiště klíčů v ASP.NET Core.

Další informace o rozhraní API a ověřování sady Azure SDK najdete v tématu Ověřování aplikací .NET ve službách Azure pomocí knihovny Azure Identity a poskytnutí přístupu ke klíčům, certifikátům a tajným kódům služby Key Vault pomocí řízení přístupu na základě role v Azure. Pokyny k protokolování najdete v tématu Protokolování pomocí sady Azure SDK pro .NET: Protokolování bez registrace klienta. U aplikací využívajících injektáž závislostí může aplikace volat AddAzureClientsCore, předat trueenableLogForwarding, vytvořit a připojit infrastrukturu protokolování.

Pokud chcete vytvořit klíč na webu Azure Portal, přečtěte si článek Rychlý start: Nastavení a načtení klíče ze služby Azure Key Vault pomocí webu Azure Portal. Dejte klíči alespoň Get, Unwrap Key, a Wrap Key oprávnění. Poznamenejte si identifikátor klíče pro použití s konfigurací aplikace. Pokud plánujete povolit automatickou rotaci klíče v klíčovém trezoru, poznamenejte si identifikátor klíče bez verze, kde není na konci identifikátoru umístěn žádný identifikátor GUID klíče (příklad: https://contoso.vault.azure.net/keys/data-protection).

V souboru, Program kde jsou zaregistrované služby:

TokenCredential? credential;

if (builder.Environment.IsProduction())
{
    credential = new ManagedIdentityCredential("{MANAGED IDENTITY CLIENT ID}");
}
else
{
    // Local development and testing only
    DefaultAzureCredentialOptions options = new()
    {
        // Specify the tenant ID to use the dev credentials when running the app locally
        // in Visual Studio.
        VisualStudioTenantId = "{TENANT ID}",
        SharedTokenCacheTenantId = "{TENANT ID}"
    };

    credential = new DefaultAzureCredential(options);
}

builder.Services.AddDataProtection()
    .SetApplicationName("{APPLICATION NAME}")
    .PersistKeysToAzureBlobStorage(new Uri("{BLOB URI}"), credential)
    .ProtectKeysWithAzureKeyVault(new Uri("{KEY IDENTIFIER}"), credential);

{MANAGED IDENTITY CLIENT ID}: ID spravovaného Identity klienta Azure (GUID).

{TENANT ID}: ID nájemce.

{APPLICATION NAME}: SetApplicationName Nastaví jedinečný název této aplikace v rámci systému ochrany dat. Hodnota by se měla shodovat mezi nasazeními aplikace.

{BLOB URI}: Úplný identifikátor URI souboru klíče. Identifikátor URI se vygeneruje službou Azure Storage při vytváření souboru klíče. Nepoužívejte SAS.

{KEY IDENTIFIER}: Identifikátor klíče služby Azure Key Vault používaný k šifrování klíčů. Zásady přístupu umožňují aplikaci přistupovat k trezoru klíčů pomocí GetUnwrap KeyWrap Key a oprávnění. Verze klíče se získá z klíče na webu Entra nebo Azure Portal po jeho vytvoření. Pokud povolíte automatickou obměnu klíče trezoru klíčů, ujistěte se, že v konfiguraci trezoru klíčů aplikace používáte identifikátor bez verzí , kde na konci identifikátoru není umístěný žádný identifikátor GUID klíče (například: https://contoso.vault.azure.net/keys/data-protection).

Aby aplikace komunikovala a autorizovala se službou Azure Key Vault, Azure.Identity musí na balíček NuGet odkazovat aplikace.

Note

Pokyny k přidávání balíčků do aplikací .NET najdete v článcích v části Instalace a správa balíčků na webu Pracovní postup používání balíčků (dokumentace k NuGetu). Ověřte správné verze balíčků na NuGet.org.

Note

V neprodukčních prostředích se předchozí příklad používá DefaultAzureCredential ke zjednodušení ověřování při vývoji aplikací, které se nasazují do Azure zkombinováním přihlašovacích údajů používaných v hostitelských prostředích Azure s přihlašovacími údaji použitými v místním vývoji. Další informace najdete v tématu Ověřování aplikací .NET hostovaných v Azure v prostředcích Azure pomocí spravované identity přiřazené systémem.

Pokud aplikace používá starší balíčky Azure (Microsoft.AspNetCore.DataProtection.AzureStorage a Microsoft.AspNetCore.DataProtection.AzureKeyVault), doporučujeme tyto odkazy odebrat a upgradovat na tyto Azure.Extensions.AspNetCore.DataProtection.Blobs balíčky Azure.Extensions.AspNetCore.DataProtection.Keys . Novější balíčky řeší klíčové problémy se zabezpečením a stabilitou.

Alternativní přístup sdíleného přístupového podpisu (SAS): Alternativou k použití spravovaného Identity pro přístup ke klíčovému objektu blob ve službě Azure Blob Storage je volání PersistKeysToAzureBlobStorage verze přetížení, která přijímá identifikátor URI objektu blob s tokenem SAS. Následující příklad nadále používá ManagedIdentityCredential (produkční) nebo DefaultAzureCredential (vývoj a testování) pro svůj TokenCredential, jak je vidět v předchozím příkladu:

builder.Services.AddDataProtection()
    .SetApplicationName("{APPLICATION NAME}")
    .PersistKeysToAzureBlobStorage(new Uri("{BLOB URI WITH SAS}"))
    .ProtectKeysWithAzureKeyVault(new Uri("{KEY IDENTIFIER}"), credential);

{APPLICATION NAME}: SetApplicationName Nastaví jedinečný název této aplikace v rámci systému ochrany dat. Hodnota by se měla shodovat mezi nasazeními aplikace.

{BLOB URI WITH SAS}: Úplný identifikátor URI, do kterého se má soubor klíče uložit s tokenem SAS jako parametr řetězce dotazu. Identifikátor URI se vygeneruje službou Azure Storage, když požádáte o SAS pro nahraný soubor klíče.

{KEY IDENTIFIER}: Identifikátor klíče služby Azure Key Vault používaný k šifrování klíčů. Zásady přístupu umožňují aplikaci přistupovat k trezoru klíčů pomocí GetUnwrap KeyWrap Key a oprávnění. Verze klíče se získá z klíče na webu Entra nebo Azure Portal po jeho vytvoření. Pokud povolíte automatickou obměnu klíče trezoru klíčů, ujistěte se, že v konfiguraci trezoru klíčů aplikace používáte identifikátor bez verzí, kde na konci identifikátoru není umístěný žádný identifikátor GUID klíče (například: https://contoso.vault.azure.net/keys/data-protection).

Zachování klíčů v systému souborů (PersistKeysToFileSystem)

Pokud chcete ukládat klíče do sdílené složky UNC místo výchozího umístění %LOCALAPPDATA% , nakonfigurujte systém takto PersistKeysToFileSystem:

builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"));

Warning

Pokud změníte umístění trvalosti klíčů, systém už automaticky nešifruje neaktivní uložená klíče, protože neví, jestli je rozhraní DPAPI vhodným šifrovacím mechanismem.

Zachování klíčů v databázi (PersistKeysToDbContext)

Pokud chcete ukládat klíče do databáze pomocí EntityFramework, nakonfigurujte systém s balíčkem Microsoft.AspNetCore.DataProtection.EntityFrameworkCore :

builder.Services.AddDataProtection()
    .PersistKeysToDbContext<SampleDbContext>();

Předchozí kód ukládá klíče do nakonfigurované databáze. Použitý kontext databáze musí implementovat IDataProtectionKeyContext. IDataProtectionKeyContext zveřejňuje vlastnost. DataProtectionKeys

public DbSet<DataProtectionKey> DataProtectionKeys { get; set; } = null!;

Tato vlastnost představuje tabulku, ve které jsou klíče uloženy. Vytvořte tabulku ručně nebo pomocí DbContext Migrací. Další informace najdete na webu DataProtectionKey.

Ochrana konfiguračního rozhraní API klíčů (ProtectKeysWith\*)

Systém můžete nakonfigurovat pro ochranu klíčů v klidu voláním libovolného API rozhraní ProtectKeysWith\*. Podívejte se na následující příklad, který ukládá klíče do sdílené složky UNC a šifruje neaktivní uložené klíče pomocí konkrétního certifikátu X.509.

Můžete zadat X509Certificate2 z ProtectKeysWithCertificate souboru voláním X509CertificateLoader.LoadCertificateFromFile:

builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
    .ProtectKeysWithCertificate(
        new X509Certificate2("certificate.pfx", builder.Configuration["CertificatePassword"]));

Následující příklad kódu ukazuje, jak načíst certifikát pomocí kryptografického otisku:

builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
    .ProtectKeysWithCertificate(builder.Configuration["CertificateThumbprint"]);

Příklady a diskuze o integrovaných mechanismech šifrování klíčů najdete v tématu Šifrování neaktivních uložených klíčů ve Windows a Azure pomocí ASP.NET Core.

Odemknutí klíčů pomocí libovolného certifikátu (UnprotectKeysWithAnyCertificate)

Certifikáty můžete otáčet a klíče v klidu dešifrovat pomocí pole certifikátů X509Certificate2 s UnprotectKeysWithAnyCertificate:

builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
    .ProtectKeysWithCertificate(
        new X509Certificate2("certificate.pfx", builder.Configuration["CertificatePassword"]))
    .UnprotectKeysWithAnyCertificate(
        new X509Certificate2("certificate_1.pfx", builder.Configuration["CertificatePassword_1"]),
        new X509Certificate2("certificate_2.pfx", builder.Configuration["CertificatePassword_2"]));

Nastavení výchozí životnosti klíče (SetDefaultKeyLifetime)

Pokud chcete systém nakonfigurovat tak, aby používal životnost klíče 14 dnů místo výchozích 90 dnů, použijte SetDefaultKeyLifetime:

builder.Services.AddDataProtection()
    .SetDefaultKeyLifetime(TimeSpan.FromDays(14));

Nastavení názvu aplikace (SetApplicationName)

Ve výchozím nastavení systém Ochrany dat izoluje aplikace od sebe na základě jejich kořenových cest k obsahu, i když sdílejí stejné úložiště fyzického klíče. Tato izolace brání aplikacím v pochopení chráněných datových částí mezi sebou.

Sdílení chráněných datových částí mezi aplikacemi:

• Nakonfigurujte SetApplicationName v každé aplikaci stejnou hodnotu.
• V aplikacích použijte stejnou verzi sady API Data Protection. V souborech projektu aplikací proveďte jednu z následujících akcí:
  • Pomocí metabalíku Microsoft.AspNetCore.App odkazujte na stejnou verzi sdílené architektury.
  • Odkazujte na stejnou verzi balíčku Data Protection.

builder.Services.AddDataProtection()
    .SetApplicationName("<sharedApplicationName>");

SetApplicationName interně nastavuje DataProtectionOptions.ApplicationDiscriminator. Pro účely řešení potíží lze hodnotu přiřazenou k diskriminátoru rámcem zaznamenat následujícím kódem umístěným po sestavení WebApplication v Program.cs:

var discriminator = app.Services.GetRequiredService<IOptions<DataProtectionOptions>>()
    .Value.ApplicationDiscriminator;
app.Logger.LogInformation("ApplicationDiscriminator: {ApplicationDiscriminator}", discriminator);

Další informace o způsobu použití diskriminace najdete v následujících částech tohoto článku:

• Izolace pro jednotlivé aplikace
• Ochrana dat a izolace aplikací

Warning

V .NET 6 WebApplicationBuilder normalizuje kořenovou cestu k obsahu, aby končila na DirectorySeparatorChar. Například v systému Windows kořenová cesta obsahu končí na \ a v systému Linux na /. Ostatní hostitelé cestu nenormalizují. Většina aplikací migrujících z HostBuilder nebo WebHostBuilder nebude mít stejný název aplikace, protože postrádají ukončovací DirectorySeparatorChar. Chcete-li tento problém vyřešit, odeberte znak oddělovače adresáře a nastavte název aplikace ručně, jak je znázorněno v následujícím kódu:

using System.Reflection;
using Microsoft.AspNetCore.DataProtection;

var builder = WebApplication.CreateBuilder(args);

var trimmedContentRootPath = 
    builder.Environment.ContentRootPath.TrimEnd(Path.DirectorySeparatorChar);

builder.Services.AddDataProtection().SetApplicationName(trimmedContentRootPath);

var app = builder.Build();

app.MapGet("/", () => Assembly.GetEntryAssembly()!.GetName().Name);

app.Run();

Zakázání automatického generování klíčů (DisableAutomaticKeyGeneration)

Můžete mít scénář, kdy nechcete, aby aplikace automaticky měnila klíče (vytvářela nové klíče) při blížícím se vypršení platnosti. Jedním z příkladů tohoto scénáře může být nastavení aplikací v primárním nebo sekundárním vztahu, kdy za otázky správy klíčů zodpovídá jenom primární aplikace a sekundární aplikace mají jednoduše zobrazení okruhu klíčů jen pro čtení. Sekundární aplikace je možné nakonfigurovat tak, aby s okruhem klíčů zacházeli jen pro čtení, a to tak, že systém nakonfigurujete takto DisableAutomaticKeyGeneration:

builder.Services.AddDataProtection()
    .DisableAutomaticKeyGeneration();

Izolace pro jednotlivé aplikace

Když systém ochrany dat poskytuje hostitel ASP.NET Core, automaticky izoluje aplikace od sebe, i když jsou tyto aplikace spuštěné pod stejným účtem pracovního procesu a používají stejný hlavní klíčovací materiál. Podobá se modifikátoru IsolateApps z elementu <machineKey> System.Web.

Mechanismus izolace funguje tak, že zváží každou aplikaci na místním počítači jako jedinečného nájemníka, a proto IDataProtector kořenový adresář pro každou danou aplikaci automaticky zahrnuje ID aplikace jako rozlišovací prvek (ApplicationDiscriminator). Jedinečné ID aplikace je fyzická cesta aplikace:

• U aplikací hostovaných v IIS je jedinečné ID fyzická cesta aplikace v IIS. Pokud je aplikace nasazená v prostředí webové farmy, je tato hodnota stabilní za předpokladu, že se prostředí služby IIS konfigurují podobně na všech počítačích ve webové farmě.
• U aplikací v místním prostředí spuštěných na Kestrel serveru je jedinečné ID fyzickou cestou k aplikaci na disku.

Jedinečný identifikátor je navržený tak, aby přežil resetování – jak jednotlivé aplikace, tak i samotného počítače.

Tento mechanismus izolace předpokládá, že aplikace nejsou škodlivé. Škodlivá aplikace může mít vždycky vliv na jakoukoli jinou aplikaci spuštěnou pod stejným účtem pracovního procesu. Ve sdíleném hostitelském prostředí, kde jsou aplikace vzájemně nedůvěryhodné, by poskytovatel hostingu měl podniknout kroky k zajištění izolace na úrovni operačního systému mezi aplikacemi, včetně oddělení základních úložišť klíčů aplikací.

Pokud systém ochrany dat není poskytován hostitelem ASP.NET Core (například pokud vytvoříte instanci prostřednictvím konkrétního DataProtectionProvider typu), izolace aplikace je ve výchozím nastavení zakázaná. Když je izolace aplikace zakázaná, můžou všechny aplikace zálohované stejným klíčem sdílet datové části, pokud poskytují příslušné účely. Chcete-li poskytnout izolaci aplikace v tomto prostředí, zavolejte SetApplicationName metodu objektu konfigurace a zadejte jedinečný název pro každou aplikaci.

Ochrana dat a izolace aplikací

Pro izolaci aplikací zvažte následující body:

• Pokud je více aplikací namířeno na stejné úložiště klíčů, záměrem je, aby aplikace sdílely stejný materiál hlavního klíče. Ochrana dat se vyvíjí s předpokladem, že všechny aplikace sdílející okruh klíčů mají přístup ke všem položkám v daném okruhu klíčů. Jedinečný identifikátor aplikace slouží k izolaci klíčů specifických pro aplikaci, které jsou odvozeny od klíčů poskytnutých klíčovým prstencem. Neočekává oprávnění na úrovni položek, jako jsou oprávnění poskytovaná službou Azure KeyVault, která se použijí k vynucení extra izolace. Při pokusu o oprávnění na úrovni položky se generují chyby aplikace. Pokud nechcete spoléhat na integrovanou izolaci aplikací, měli byste použít samostatná umístění úložiště klíčů a nesdílet je mezi aplikacemi.

• Aplikační diskriminátor (ApplicationDiscriminator) se používá k tomu, aby různé aplikace mohly sdílet stejný materiál hlavního klíče, ale jejich kryptografické části zůstaly vzájemně oddělené. Aby si aplikace mohly navzájem číst kryptografické datové části, musí mít stejnou diskriminující aplikaci, kterou lze nastavit voláním SetApplicationName.

• Pokud dojde k ohrožení zabezpečení aplikace (například útokem RCE), musí být všechny hlavní klíčové materiály přístupné pro tuto aplikaci také považovány za ohrožené bez ohledu na stav ochrany v klidovém stavu. To znamená, že pokud jsou dvě aplikace zaměřeny na stejné úložiště, i když používají různé diskriminátory aplikací, kompromis jedné z nich je funkčně ekvivalentní kompromisu obou.

  Tato klauzule "funkčně ekvivalentní kompromisu obou" platí i v případě, že obě aplikace používají různé mechanismy pro ochranu klíčů v klidovém stavu. Obvykle se nejedná o očekávanou konfiguraci. Mechanismus ochrany v klidovém stavu je určený k zajištění ochrany v případě, že kyberútok získá přístup pro čtení k úložišti. Cyberattacker, který získá přístup k zápisu do úložiště (možná proto, že získal oprávnění ke spuštění kódu v aplikaci), může do úložiště vložit škodlivé klíče. Systém Ochrany dat záměrně neposkytuje ochranu před cyberattackerem, který získá přístup k zápisu do úložiště klíčů.

• Pokud aplikace potřebují zůstat skutečně izolované od sebe, měly by používat různá úložiště klíčů. Toto přirozeně vyplývá z definice "izolovaného". Aplikace nejsou izolované, pokud mají všichni přístup ke čtení a zápisu k úložištím dat.

Změna algoritmů pomocí UseCryptographicAlgorithms

Vrstva Data Protection umožňuje změnit výchozí algoritmus používaný nově vygenerovanými klíči. Nejjednodušším způsobem, jak to udělat, je volat UseCryptographicAlgorithms ze zpětného volání konfigurace.

builder.Services.AddDataProtection()
    .UseCryptographicAlgorithms(new AuthenticatedEncryptorConfiguration
    {
        EncryptionAlgorithm = EncryptionAlgorithm.AES_256_CBC,
        ValidationAlgorithm = ValidationAlgorithm.HMACSHA256
    });

Výchozí encryptionAlgorithm je AES-256-CBC a výchozí ValidationAlgorithm je HMACSHA256. Výchozí zásady může nastavit správce systému prostřednictvím zásad na úrovni počítače, ale explicitní volání přepíše výchozí zásady.

Volání UseCryptographicAlgorithms umožňuje zadat požadovaný algoritmus z předdefinovaného seznamu. Nemusíte se starat o implementaci algoritmu. Ve výše uvedeném scénáři se systém Ochrany dat pokusí použít implementaci AES CNG, pokud běží ve Windows. V opačném případě se vrátí do spravované System.Security.Cryptography.Aes třídy.

Implementaci můžete zadat ručně prostřednictvím volání UseCustomCryptographicAlgorithms.

Tip

Změna algoritmů nemá vliv na existující klíče v okruhu klíčů. Týká se to jenom nově generovaných klíčů.

Určení vlastních spravovaných algoritmů

Pokud chcete zadat vlastní spravované algoritmy, vytvořte ManagedAuthenticatedEncryptorConfiguration instanci, která odkazuje na typy implementace:

builder.Services.AddDataProtection()
    .UseCustomCryptographicAlgorithms(new ManagedAuthenticatedEncryptorConfiguration
    {
        // A type that subclasses SymmetricAlgorithm
        EncryptionAlgorithmType = typeof(Aes),

        // Specified in bits
        EncryptionAlgorithmKeySize = 256,

        // A type that subclasses KeyedHashAlgorithm
        ValidationAlgorithmType = typeof(HMACSHA256)
    });

Obecně platí, že vlastnosti *Type musí odkazovat na konkrétní, instanciovatelné (prostřednictvím veřejného bezparametrového konstruktoru) implementace SymmetricAlgorithm a KeyedHashAlgorithm, i když systém pro pohodlí speciálně zachází s některými hodnotami jako typeof(Aes).

Note

Symetrický algoritmus musí mít délku klíče ≥ 128 bitů a velikost bloku ≥ 64 bitů a musí podporovat šifrování v režimu CBC s vycpávkou PKCS #7. KeyedHashAlgorithm musí mít velikost výstupu hash >= 128 bitů a musí podporovat klíče o délce, která se rovná délce výstupu hash algoritmu. KeyedHashAlgorithm nemusí být výhradně HMAC.

Určení vlastních algoritmů CNG systému Windows

Pokud chcete zadat vlastní algoritmus CNG systému Windows pomocí šifrování VBC s ověřováním HMAC, vytvořte CngCbcAuthenticatedEncryptorConfiguration instanci obsahující algoritmické informace:

builder.Services.AddDataProtection()
    .UseCustomCryptographicAlgorithms(new CngCbcAuthenticatedEncryptorConfiguration
    {
        // Passed to BCryptOpenAlgorithmProvider
        EncryptionAlgorithm = "AES",
        EncryptionAlgorithmProvider = null,

        // Specified in bits
        EncryptionAlgorithmKeySize = 256,

        // Passed to BCryptOpenAlgorithmProvider
        HashAlgorithm = "SHA256",
        HashAlgorithmProvider = null
    });

Note

Algoritmus symetrického blokového šifrování musí mít délku >klíče = 128 bitů, velikost >bloku = 64 bitů a musí podporovat šifrování v režimu CBC s odsazením PKCS #7. Algoritmus hash musí mít délku hodnoty hash > = 128 bitů a musí podporovat být otevřen s příznakem BCRYPT_ALG_HANDLE_HMAC_FLAG. Vlastnosti *Provider lze nastavit na hodnotu null tak, aby používaly výchozího zprostředkovatele pro zadaný algoritmus. Další informace naleznete v dokumentaci BCryptOpenAlgorithmProvider .

Pokud chcete zadat vlastní algoritmus CNG systému Windows pomocí šifrování Galois/Counter Mode s ověřováním, vytvořte CngGcmAuthenticatedEncryptorConfiguration instanci obsahující algoritmické informace:

builder.Services.AddDataProtection()
    .UseCustomCryptographicAlgorithms(new CngGcmAuthenticatedEncryptorConfiguration
    {
        // Passed to BCryptOpenAlgorithmProvider
        EncryptionAlgorithm = "AES",
        EncryptionAlgorithmProvider = null,

        // Specified in bits
        EncryptionAlgorithmKeySize = 256
    });

Note

Šifrovací algoritmus symetrického bloku musí mít délku >klíče = 128 bitů, velikost bloku přesně 128 bitů a musí podporovat šifrování GCM. Vlastnost můžete nastavit EncryptionAlgorithmProvider na hodnotu null tak, aby používala výchozího zprostředkovatele pro zadaný algoritmus. Další informace naleznete v dokumentaci BCryptOpenAlgorithmProvider .

Určení dalších vlastních algoritmů

I když není vystavený jako prvotřídní rozhraní API, systém Ochrany dat je dostatečně rozšiřitelný, aby umožňoval zadávání téměř jakéhokoli druhu algoritmu. Je například možné zachovat všechny klíče obsažené v modulu hardwarového zabezpečení (HSM) a poskytnout vlastní implementaci základních rutin šifrování a dešifrování. Pro více informací se podívejte na IAuthenticatedEncryptor v rozšiřitelnosti základní kryptografie.

Zachování klíčů při hostování v kontejneru Dockeru

Při hostování v kontejneru Dockeru by se klíče měly udržovat v těchto případech:

• Složka, která je svazkem Dockeru a přetrvává i po dobu životnosti kontejneru, například sdílený svazek nebo svazek připojený k hostitelskému systému.
• Externí poskytovatel, například Azure Blob Storage (zobrazený v ProtectKeysWithAzureKeyVault části) nebo Redis.

Uchování klíčů pomocí Redis

K ukládání klíčů by měly být použity pouze verze Redis podporující trvalost dat Redis. Azure Blob Storage je trvalé a dá se použít k ukládání klíčů. Další informace najdete u tohoto problému na GitHubu.

Logging

Povolte Information nebo nižší úroveň protokolování pro diagnostiku problémů. Následující appsettings.json soubor umožňuje protokolování informací rozhraní API ochrany dat:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Microsoft.AspNetCore.DataProtection": "Information"
    }
  },
  "AllowedHosts": "*"
}

Další informace o protokolování najdete v tématu Protokolování v .NET a ASP.NET Core.

Dodatečné zdroje

• Scénáře ochrany dat v ASP.NET Core nevyužívající injektáž závislostí
• Podpora zásad ochrany dat na úrovni počítače v ASP.NET Core
• Hostování ASP.NET Core ve webové farmě
• Poskytovatelé úložiště klíčů v ASP.NET Core