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.

Upozorňující

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 se rozhodnout šifrovat klíče na restadrese , ale nezabráníte tomu, aby kyberattackers 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 přístup k danému identity adresáři má jen spuštěná webová aplikace pro čtení, zápis a vytvoření přístupu. Pokud používáte Službu Azure Blob Storage, měla by 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 zřetězí a nakonfigurovat možnosti ochrany dat.

Poznámka:

Tento článek byl napsán pro aplikaci, která běží v kontejneru Dockeru. V kontejneru Dockeru má aplikace vždy stejnou cestu, a proto je stejná aplikace diskriminující. 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

ProtectKeysWithAzureKeyVault

Přihlaste se k Azure pomocí rozhraní příkazového řádku, například:

az login

Pokud chcete spravovat klíče pomocí služby Azure Key Vault, nakonfigurujte systém pomocí ProtectKeysWithAzureKeyVault nástroje in Program.cs. blobUriWithSasToken je úplný identifikátor URI, do kterého se má soubor klíče uložit. Identifikátor URI musí obsahovat token SAS jako parametr řetězce dotazu:

builder.Services.AddDataProtection()
    .PersistKeysToAzureBlobStorage(new Uri("<blobUriWithSasToken>"))
    .ProtectKeysWithAzureKeyVault(new Uri("<keyIdentifier>"), new DefaultAzureCredential());

Aby aplikace komunikovala a autorizovala se službou KeyVault, musí se přidat balíček Azure.Identity

Nastavte umístění úložiště okruhu klíčů (například PersistKeysToAzureBlobStorage). Umístění musí být nastavené, protože volání ProtectKeysWithAzureKeyVault implementuje IXmlEncryptor nastavení automatické ochrany dat, včetně umístění úložiště okruhu klíčů. Předchozí příklad používá Azure Blob Storage k zachování okruhu klíčů. Další informace najdete v tématu Poskytovatelé úložiště klíčů: Azure Storage. Okruh klíčů můžete také zachovat místně pomocí funkce PersistKeysToFileSystem.

Jedná se keyIdentifier o identifikátor klíče trezoru klíčů, který se používá k šifrování klíčů. Například klíč vytvořený v trezoru klíčů pojmenovaný dataprotection v klíči contosokeyvault má identifikátor https://contosokeyvault.vault.azure.net/keys/dataprotection/klíče . Poskytněte aplikaci oprávnění Get, Unwrap Key a Wrap Key k trezoru klíčů.

ProtectKeysWithAzureKeyVault Přetížení:

• ProtectKeysWithAzureKeyVault(IDataProtectionBuilder, Uri, TokenCredential) povoluje použití identifikátoru URI keyIdentifier a tokenCredential, aby systém ochrany dat mohl používat trezor klíčů.
• ProtectKeysWithAzureKeyVault(IDataProtectionBuilder, String, IKeyEncryptionKeyResolver) povoluje použití řetězce keyIdentifier a IKeyEncryptionKeyResolver k povolení systému ochrany dat používat trezor klíčů.

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 Azure.Extensions.AspNetCore.DataProtection.Blobs a Azure.Extensions.AspNetCore.DataProtection.Keys. Tyto balíčky jsou tam, kde jsou k dispozici nové aktualizace, a řeší některé klíčové problémy se zabezpečením a stabilitou u starších balíčků.

builder.Services.AddDataProtection()
    // This blob must already exist before the application is run
    .PersistKeysToAzureBlobStorage("<storageAccountConnectionString", "<containerName>", "<blobName>")
    // Removing this line below for an initial run will ensure the file is created correctly
    .ProtectKeysWithAzureKeyVault(new Uri("<keyIdentifier>"), new DefaultAzureCredential());

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\"));

Upozorňující

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

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.

ProtectKeysWith*

Systém můžete nakonfigurovat tak, aby chránil klíče rest voláním některého z konfiguračních rozhraní API ProtectKeysWith* . Podívejte se na následující příklad, který ukládá klíče ve sdílené složce UNC a šifruje tyto klíče rest pomocí konkrétního certifikátu X.509:

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

Můžete zadat X509Certificate2 ProtectKeysWithCertificatenapříklad certifikát načtený ze souboru:

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

Další příklady a diskuze o integrovaných mechanismech šifrování klíčů najdete v tématu Šifrování Rest klíčů.

UnprotectKeysWithAnyCertificate

Certifikáty a dešifrovací klíče rest můžete otáčet pomocí pole X509Certificate2 certifikátů pomocí 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"]));

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));

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 zásobníku rozhraní API služby 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 diskriminátoru rozhraním protokolovat s následujícím kódem umístěným po WebApplication sestavení 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í

Upozorňující

V .NET 6 normalizuje kořenovou cestu k obsahu tak, WebApplicationBuilder aby končila na .DirectorySeparatorChar Například ve Windows kořenová cesta obsahu končí a \ v Linuxu /. Ostatní hostitelé cestu nenormalizují. Většina aplikací migruje nebo HostBuilder WebHostBuilder nesdílí stejný název aplikace, protože nebude mít ukončení 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 Microsoft.AspNetCore.DataProtection;
using System.Reflection;

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();

DisableAutomaticKeyGeneration

Můžete mít scénář, kdy nechcete, aby aplikace automaticky vyřazuje klíče (vytvářet 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 tenanta, a proto IDataProtector root pro každou danou aplikaci automaticky zahrne ID aplikace jako nediskriminační (ApplicationDiscriminator). Jedinečné ID aplikace je fyzická cesta aplikace:

• U aplikací hostovaných ve službě IIS je jedinečné ID fyzickou cestou služby IIS aplikace. 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 na stejném úložišti klíčů uvedeno více aplikací, 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 odvozených od klíčů zadaných klíči. 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íčů, která se mezi aplikacemi nesdílí.

• Používá se k tomu, aby různé aplikace sdílely stejný materiál hlavního klíče,ApplicationDiscriminator ale aby jejich kryptografické datové části zůstaly odlišné od sebe. 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é této aplikaci také považovány za ohrožené bez ohledu na stav ochranyrest . 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 tyto dvě aplikace používají různé mechanismy pro ochranu klíčů na restadrese . Obvykle se nejedná o očekávanou konfiguraci. Mechanismus ochrany at-rest je určen k zajištění ochrany v případě, že cyberattacker 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íčů. Přirozeně se tím vyčlení 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

Stack 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 z 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í, které UseCryptographicAlgorithms přepíše výchozí zásadu.

Volání UseCryptographicAlgorithms umožňuje zadat požadovaný algoritmus z předdefinovaného 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í, okamžité (prostřednictvím veřejných bezparametrových ctor) implementací SymmetricAlgorithm a KeyedHashAlgorithm, i když systém speciální případy některé hodnoty jako pro typeof(Aes) usnadnění.

Poznámka:

SymetrickýAlgorithm musí mít délku klíče ≥ 128 bitů a velikost bloku ≥ 64 bitů a musí podporovat šifrování v režimu CBC s odsazením PKCS #7. KeyedHashAlgorithm musí mít velikost >hodnoty hash = 128 bitů a musí podporovat klíče délky, které se rovnají délce hash algoritmu hash. 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
    });

Poznámka:

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 velikost >hodnoty hash = 128 bitů a musí podporovat otevření 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
    });

Poznámka:

Š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í. Další informace najdete v tématu IAuthenticatedEncryptor Rozšiřitelnost kryptografie core.

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, která se zachovává nad rámec životnosti kontejneru, jako je sdílený svazek nebo svazek připojený k hostiteli.
• Externí poskytovatel, například Azure Blob Storage (zobrazený v ProtectKeysWithAzureKeyVault části) nebo Redis.

Uchování klíčů pomocí Redisu

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.

Protokolování ochrany dat

Povolte Information protokolování úrovně ochrany dat, které pomáhá diagnostikovat problém. Následující appsettings.json soubor umožňuje protokolování informací rozhraní DATAProtection API:

{
  "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 Core a ASP.NET Core.

Další materiály

• 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