konfigurace ochrany ASP.NET Core dat

Po inicializaci systému ochrany dat se použije výchozí nastavení na základě operačního prostředí. Tato nastavení jsou obecně vhodná pro aplikace běžící na jednom počítači. V některých případech může vývojář chtít změnit výchozí nastavení:

• Aplikace je rozdělená mezi několik počítačů.
• Z důvodu dodržování předpisů.

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

az login

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .PersistKeysToAzureBlobStorage(new Uri("<blobUriWithSasToken>"))
        .ProtectKeysWithAzureKeyVault(new Uri("<keyIdentifier>"), new DefaultAzureCredential());
}

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

Chcete-li uložit klíče ve sdílené složce UNC místo ve výchozím umístění % localappdata% , nakonfigurujte systém pomocí PersistKeysToFileSystem:

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

PersistKeysToDbContext

Chcete-li uložit klíče v databázi pomocí EntityFramework, nakonfigurujte systém pomocí balíčku Microsoft. AspNetCore. DataProtection. EntityFrameworkCore :

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

Předchozí kód uloží klíče do nakonfigurované databáze. Je nutné implementovat kontext databáze, který se používá IDataProtectionKeyContext . IDataProtectionKeyContext zpřístupní vlastnost DataProtectionKeys

public DbSet<DataProtectionKey> DataProtectionKeys { get; set; }

Tato vlastnost představuje tabulku, ve které jsou klíče uložené. Vytvořte tabulku ručně nebo s DbContext migracemi. Další informace naleznete v tématu DataProtectionKey.

ProtectKeysWith*

Systém můžete nakonfigurovat tak, aby chránil klíče v klidovém umístění voláním libovolného rozhraní API pro konfiguraci ProtectKeysWith * . Vezměte v úvahu následující příklad, který ukládá klíče do sdílené složky UNC a šifruje tyto klíče v klidovém formátu pomocí konkrétního certifikátu X. 509:

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

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í klíčů v klidovém umístění .

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í namí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 navzájem na základě jejich kořenových cest obsahu , i když sdílí stejné fyzické úložiště klíčů. To aplikacím brání v porozumění chráněným datovým částem.

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

• Nakonfigurujte SetApplicationName v každé aplikaci stejnou hodnotu.
• Používejte stejnou verzi Data Protection API stacku napříč aplikacemi. V souborech projektu aplikace proveďte jednu z následujících akcí:
  • Odkázat na stejnou verzi sdíleného rozhraní prostřednictvím Microsoft.AspNetCore.app Metapackage.
  • Odkaz na stejnou verzi balíčku ochrany dat

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

DisableAutomaticKeyGeneration

Můžete mít situaci, kdy nechcete, aby aplikace automaticky nastavila klíče (vytváření nových klíčů) při přístupu k vypršení platnosti. Příkladem může být aplikace nastavovaná v relaci primárního a sekundárního, kde pouze primární aplikace zodpovídá za důležité aspekty správy klíčů a sekundární aplikace má pouze pohled jen pro čtení ve službě Key Ring. Sekundární aplikace je možné nakonfigurovat tak, aby považovaly klíčový prstenec za jen pro čtení, a to konfigurací systému pomocí DisableAutomaticKeyGeneration :

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .DisableAutomaticKeyGeneration();
}

Izolace podle aplikace

když je systém ochrany dat poskytovaný ASP.NET Core hostitelem, automaticky izoluje aplikace od sebe navzájem, i když tyto aplikace běží pod stejným účtem pracovního procesu a používají stejný hlavní materiál klíčů. To je trochu podobné modifikátoru IsolateApps z prvku System. Web <machineKey> .

Mechanismus izolace funguje tak, že zvažuje každou aplikaci v místním počítači jako jedinečného tenanta, takže IDataProtector Kořenová složka pro všechny dané aplikace automaticky zahrnuje ID aplikace jako diskriminátor. Jedinečným ID aplikace je fyzická cesta aplikace:

• Pro aplikace hostované ve službě IIS je jedinečným ID fyzická cesta k aplikaci služby IIS. Pokud je aplikace nasazená ve webové farmě, je tato hodnota stabilní za předpokladu, že prostředí služby IIS se konfigurují podobně napříč všemi počítači ve webové farmě.
• Pro samoobslužné aplikace běžící na Kestrel serveruje jedinečné ID fyzická cesta k aplikaci na disku.

Jedinečný identifikátor je navržený tak, aby se předržel — jak jednotlivé aplikace, tak i samotný počítač.

Tento mechanismus izolace předpokládá, že aplikace nejsou škodlivé. Škodlivá aplikace může vždycky ovlivnit jakoukoli jinou aplikaci spuštěnou v rámci stejného účtu pracovního procesu. Ve sdíleném hostitelském prostředí, kde jsou aplikace vzájemně nedůvěryhodné, by měl poskytovatel hostingu 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 není systém ochrany dat poskytovaný ASP.NET Corem hostitelem (například při vytvoření instance prostřednictvím DataProtectionProvider konkrétního typu), je ve výchozím nastavení zakázána izolace aplikace. Pokud je izolace aplikace zakázaná, můžou všechny aplikace, které používá stejný materiál klíče, sdílet datové části, pokud poskytují vhodné účely. Pokud chcete v tomto prostředí poskytnout izolaci aplikace, zavolejte metodu SetApplicationName na 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í:

• Pokud jsou více aplikací odkazovány v rámci stejného úložiště klíčů, je záměrem, 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í ke službě Key Ring mají přístup ke všem položkám ve službě Key Ring. Jedinečný identifikátor aplikace se používá k izolaci klíčů specifických pro aplikaci odvozených od poskytnutých klíčů klíčového kruhu. Neočekává oprávnění na úrovni položek, jako jsou ta, která poskytuje Azure webrecovery, k vykonání další izolace. Pokus o oprávnění na úrovni položky generuje chyby aplikace. Pokud nechcete spoléhat na vestavěnou izolaci aplikace, měli byste použít oddělené umístění úložiště klíčů a nemusíte je sdílet mezi aplikacemi.

• Diskriminátor aplikace se používá k tomu, aby mohly různé aplikace sdílet stejné klíčové materiály, ale jejich kryptografické datové části se liší od sebe navzájem. Aby mohly aplikace číst kryptografické datové části, musí mít stejný diskriminátor aplikace.

• Pokud dojde k ohrožení zabezpečení aplikace (například při útoku RCE), musí být všechny materiály hlavního klíče dostupné pro tuto aplikaci rovněž považovány za napadené, bez ohledu na její stav ochrany při současném přihlášení. To znamená, že pokud jsou dvě aplikace odkazovány ve stejném úložišti, a to i v případě, že používají jiné diskriminátory aplikací, ohrožení bezpečnosti jednoho z nich funkčně odpovídá ohrožení obou.

  Tato "funkčně rovnocenná" ohrožení obou klauzulí "mají i v případě, že tyto dvě aplikace používají pro ochranu klíčů v klidovém případě různé mechanismy. Obvykle to není očekávaná konfigurace. Mechanismus ochrany proti REST je určený k zajištění ochrany v případě, že nežádoucí osoba získá přístup pro čtení do úložiště. Nežádoucí osoba, který získá přístup pro zápis do úložiště (třeba kvůli tomu, že v rámci aplikace dosáhli oprávnění pro spuštění kódu), může do úložiště vložit škodlivé klíče. Systém ochrany dat úmyslně neposkytuje ochranu proti nežádoucí osoba, který získá přístup pro zápis do úložiště klíčů.

• Pokud je potřeba, aby aplikace zůstaly vzájemně izolované, měla by používat jiná úložiště klíčů. Přirozeně nespadají do definice "izolované". Aplikace nejsou izolované, Pokud všechny mají přístup pro čtení a zápis do úložišť dat ostatních.

Změna algoritmů pomocí UseCryptographicAlgorithms

Zásobník ochrany dat umožňuje změnit výchozí algoritmus používaný nově generovanými klíči. Nejjednodušší způsob, jak to provést, je volat UseCryptographicAlgorithms z zpětného volání konfigurace:

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

services.AddDataProtection()
    .UseCryptographicAlgorithms(
        new AuthenticatedEncryptionSettings()
    {
        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 pomocí zásad pro celé počítače, ale explicitní volání UseCryptographicAlgorithms přepisu výchozích zásad.

Volání UseCryptographicAlgorithms umožňuje zadat požadovaný algoritmus z předdefinovaného předdefinovaného seznamu. Nemusíte si dělat starosti s implementací algoritmu. Ve výše uvedeném scénáři se systém ochrany dat pokusí použít implementaci CNG pro AES, pokud je spuštěný v Windows. V opačném případě se vrátí do spravované třídy System. Security. Cryptography. AES .

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

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

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

serviceCollection.AddDataProtection()
    .UseCustomCryptographicAlgorithms(
        new ManagedAuthenticatedEncryptionSettings()
    {
        // A type that subclasses SymmetricAlgorithm
        EncryptionAlgorithmType = typeof(Aes),

        // Specified in bits
        EncryptionAlgorithmKeySize = 256,

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

Obecně * musí být vlastnosti typu odkazovány na konkrétní instantiable (prostřednictvím neveřejných konstruktorů konstruktoru bez parametrů ) SymmetricAlgorithm a KeyedHashAlgorithm, i když systémové speciální případy některé hodnoty jako typeof(Aes) pro pohodlí.

určení vlastních algoritmů Windows CNG

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256,

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

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256,

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

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256
    });

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256
    });

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

I když není zveřejněné jako rozhraní API první třídy, je systém ochrany dat dostatečně rozšiřitelný, aby bylo možné zadat skoro jakýkoli druh algoritmu. Například je možné uchovávat všechny klíče obsažené v modulu hardwarového zabezpečení (HSM) a poskytovat vlastní implementaci základních rutin šifrování a dešifrování. Další informace najdete v tématu IAuthenticatedEncryptor v části rozšiřitelná kryptografie .

Trvalé ukládání klíčů při hostování v kontejneru Docker

Při hostování v kontejneru Docker by měly být klíče uchovávány v těchto umístěních:

• Složka, která je dokovacím svazkem, který přetrvává mimo dobu života kontejneru, jako je například sdílený svazek nebo svazek připojený k hostiteli.
• externí poskytovatel, jako je například Azure Blob Storage (zobrazený v ProtectKeysWithAzureKeyVault části) nebo Redis.

Trvalé ukládání klíčů pomocí Redis

Pro ukládání klíčů by měly být použity pouze verze Redis podporující Trvalost dat Redis . Úložiště objektů BLOB v Azure je trvalé a dá se použít k ukládání klíčů. další informace najdete v tomto GitHub problému.

Protokolování DataProtection

Povolit Information protokolování na úrovni pro DataProtection za účelem usnadnění diagnostiky. Následující appsetting.jsv souboru umožňují protokolování informací rozhraní API DataProtection.

{
  "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, které se nepoužívají při ochraně dat v ASP.NET Core
• Podpora zásad ochrany dat na úrovni počítače v ASP.NET Core
• Hostování ASP.NET Core ve webové farmě
• Zprostředkovatelé úložiště klíčů v ASP.NET Core