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.

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

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í

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.

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í.

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

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

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

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.

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 ukládat klíče ve službě Startup Azure Key Vault, nakonfigurujte systém ve ProtectKeysWithAzureKeyVault třídě. 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:

public void ConfigureServices(IServiceCollection services)
{
    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ů.

services.AddDataProtection()
    //This blob must already exist before the application is run
    .PersistKeysToAzureBlobStorage("<storage account connection string", "<key store container name>", "<key store blob name>")
    //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:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"));
}

PersistKeysToDbContext

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

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .PersistKeysToDbContext<DbContext>()
}

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

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:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
        .ProtectKeysWithCertificate(Configuration["Thumbprint"]);
}

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

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
        .ProtectKeysWithCertificate(
            new X509Certificate2("certificate.pfx", Configuration["Thumbprint"]));
}

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:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
        .ProtectKeysWithCertificate(
            new X509Certificate2("certificate.pfx", Configuration["MyPasswordKey"));
        .UnprotectKeysWithAnyCertificate(
            new X509Certificate2("certificate_old_1.pfx", Configuration["MyPasswordKey_1"]),
            new X509Certificate2("certificate_old_2.pfx", Configuration["MyPasswordKey_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:

public void ConfigureServices(IServiceCollection services)
{
    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.

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .SetApplicationName("shared app name");
}

SetApplicationName interně nastavuje DataProtectionOptions.ApplicationDiscriminator. 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í

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:

public void ConfigureServices(IServiceCollection services)
{
    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. Pokud chcete poskytnout izolaci aplikace v tomto prostředí, zavolejte metodu SetApplicationName pro objekt 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:

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.

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

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

serviceCollection.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í.

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:

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256,

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

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:

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256
    });

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": {
      "Microsoft.AspNetCore.DataProtection": "Information"
    }
  }
}

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