Konfigurera ASP.NET Core Data Protection

När dataskyddssystemet initieras tillämpas standardinställningarna baserat på driftmiljön. De här inställningarna är lämpliga för appar som körs på en enda dator. Det finns dock fall där en utvecklare kanske vill ändra standardinställningarna:

• Appen är spridd över flera datorer.
• Av efterlevnadsskäl.

I dessa scenarier erbjuder dataskyddssystemet ett omfattande konfigurations-API.

Följande NuGet-paket krävs för dataskyddstilläggen som används i den här artikeln:

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

Skydda nycklar med Azure Key Vault (ProtectKeysWithAzureKeyVault)

Om du vill interagera med Azure Key Vault lokalt med autentiseringsuppgifter för utvecklare loggar du antingen in på ditt lagringskonto i Visual Studio eller loggar in med Azure CLI. Om du inte redan har installerat Azure CLI kan du läsa Installera Azure CLI. Du kan köra följande kommando i PowerShell-panelen Utvecklare i Visual Studio eller från ett kommandogränssnitt när du inte använder Visual Studio:

az login

Mer information finns i Logga in på Azure med hjälp av utvecklarverktyg.

När du upprättar nyckelvalvet i Entra- eller Azure-portalen:

• Konfigurera nyckelvalvet så att det använder rollbaserad åtkomstkontroll i Azure (RABC). Om du inte arbetar i ett virtuellt Azure-nätverk, inklusive för lokal utveckling och testning, bekräftar du att offentlig åtkomst i nätverkssteget är aktiverad (markerad). Om du aktiverar offentlig åtkomst exponeras endast nyckelvalvets slutpunkt. Autentiserade konton krävs fortfarande för åtkomst.

• Skapa en Azure Managed Identity (eller lägg till en roll i den befintliga Hanterade Identity som du planerar att använda) med Key Vault Crypto User-rollen. Tilldela den hanterade Identity till den Azure App Service som är värd för distributionen: Inställningar>Identity>användartilldelad>Lägg till.

  Note

  Om du även planerar att köra en app lokalt med en behörig användare för blobåtkomst med hjälp av Azure CLI eller Visual Studio Azure Service Authentication lägger du till utvecklarens Azure-användarkonto i Åtkomstkontroll (IAM) med rollen Key Vault Crypto User . Om du vill använda Azure CLI via Visual Studio, kör kommandot az login från Utvecklar-PowerShell-panelen och följ anvisningarna för att autentisera med tenant.

• När nyckelkryptering är aktiv innehåller nycklarna i nyckelfilen kommentaren "This key is encrypted with Azure Key Vault." När du har startat appen väljer du kommandot Visa/redigera på snabbmenyn i slutet av nyckelraden för att bekräfta att en nyckel finns med key vault-säkerhet tillämpad.

• Du kan också aktivera automatisk nyckelrotation för nyckelvalv utan att behöva dekryptera nyttolaster med dataskyddsnycklar baserat på utgångna/roterade nyckelvalvnycklar. Varje genererad dataskyddsnyckel innehåller en referens till nyckelvalvsnyckeln som används för att kryptera den. Se bara till att du behåller utgångna nyckelvalvnycklar, ta inte bort dem i nyckelvalvet. Använd också en versionslös nyckelidentifierare i appens nyckelvalvskonfiguration, där inget nyckel-GUID placeras i slutet av identifieraren (exempel: https://contoso.vault.azure.net/keys/data-protection). Använd en liknande rotationsperiod för båda nycklarna där nyckelvalvsnyckeln roterar oftare än dataskyddsnyckeln för att säkerställa att en ny nyckel för nyckelvalv används vid tidpunkten för rotationen av dataskyddsnyckeln.

Skydda nycklar med Azure Key Vault implementerar en IXmlEncryptor som inaktiverar automatiska dataskyddsinställningar, inklusive lagringsplatsen för nyckelringen. Om du vill konfigurera Azure Blob Storage-providern att lagra nycklarna i bloblagring följer du riktlinjerna i Nyckellagringsproviders i ASP.NET Core och anropar en av PersistKeysToAzureBlobStorage överlagringarna i appen. I följande exempel används den överlagring som accepterar en blob-URI och tokenautentiseringsuppgifter (TokenCredential), som förlitar sig på en Azure Managed Identity för rollbaserad åtkomstkontroll (RBAC).

För att konfigurera Azure Key Vault-providern, anropa en av ProtectKeysWithAzureKeyVault överlagringarna. I följande exempel används den överlagring som accepterar nyckelidentifierare och tokenlegitimationer (TokenCredential), och som förlitar sig på en Hanterad Identity för RBAC i produktion, eller en ManagedIdentityCredential under utveckling och testning (DefaultAzureCredential). Andra överbelastningar accepterar antingen en klient för nyckelvalv eller ett appklient-ID med klientens hemlighet. Mer information finns i Nyckellagringsproviders i ASP.NET Core.

Mer information om Azure SDK:s API och autentisering finns i Autentisera .NET-appar till Azure-tjänster med hjälp av Azure-biblioteket Identity och Ge åtkomst till Key Vault-nycklar, certifikat och hemligheter med rollbaserad åtkomstkontroll i Azure. Information om loggning finns i Loggning med Azure SDK för .NET: Loggning utan klientregistrering. För appar som använder beroendeinjektion kan en app anropa AddAzureClientsCore, skicka true för enableLogForwarding för att skapa och koppla samman loggningsinfrastrukturen.

Information om hur du skapar en nyckel i Azure-portalen finns i Snabbstart: Ange och hämta en nyckel från Azure Key Vault med hjälp av Azure-portalen. Ge nyckeln minst Get, Unwrap Keyoch Wrap Key behörigheter. Registrera nyckelidentifieraren för användning med appens konfiguration. Om du planerar att aktivera automatisk rotation av nyckelvalvsnyckeln registrerar du den versionslösa nyckelidentifieraren, där inget nyckel-GUID placeras i slutet av identifieraren (exempel: https://contoso.vault.azure.net/keys/data-protection).

I filen Program där tjänster är registrerade:

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}: Azure Hanterad Identity Klient-ID (GUID).

{TENANT ID}: Hyresgäst-ID.

{APPLICATION NAME}: SetApplicationName anger det unika namnet på den här appen i dataskyddssystemet. Värdet ska matcha mellan distributioner av appen.

{BLOB URI}: Fullständig URI till nyckelfilen. URI:n genereras av Azure Storage när du skapar nyckelfilen. Använd inte en SAS.

{KEY IDENTIFIER}: Azure Key Vault-nyckelidentifierare som används för nyckelkryptering. Med en åtkomstprincip kan programmet komma åt nyckelvalvet med Getbehörigheterna , Unwrap Keyoch Wrap Key . Versionen av nyckeln hämtas från nyckeln i Entra- eller Azure-portalen när den har skapats. Om du aktiverar automatisk rotation av nyckelvalvsnyckeln kontrollerar du att du använder en versionslös nyckelidentifierare i appens nyckelvalvskonfiguration, där inget nyckel-GUID placeras i slutet av identifieraren (exempel: https://contoso.vault.azure.net/keys/data-protection).

För att en app ska kunna kommunicera och auktorisera sig själv med Azure Key Vault Azure.Identity måste NuGet-paketet refereras av appen.

Om appen använder de äldre Azure-paketen (Microsoft.AspNetCore.DataProtection.AzureStorage och Microsoft.AspNetCore.DataProtection.AzureKeyVault) rekommenderar vi att du tar bort dessa referenser och uppgraderar till paketen Azure.Extensions.AspNetCore.DataProtection.Blobs och Azure.Extensions.AspNetCore.DataProtection.Keys . De nyare paketen hanterar viktiga problem med säkerhet och stabilitet.

Alternativ sas-metod (signatur för delad åtkomst): Som ett alternativ till att använda en hanterad Identity för åtkomst till nyckelbloben i Azure Blob Storage kan du anropa överbelastningen PersistKeysToAzureBlobStorage som accepterar en blob-URI med en SAS-token. Följande exempel fortsätter att använda antingen en ManagedIdentityCredential (produktion) eller DefaultAzureCredential (utveckling och testning) för dess TokenCredential, enligt föregående exempel:

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

{APPLICATION NAME}: SetApplicationName anger det unika namnet på den här appen i dataskyddssystemet. Värdet ska matcha mellan distributioner av appen.

{BLOB URI WITH SAS}: Den fullständiga URI:n där nyckelfilen ska lagras med SAS-token som en frågesträngsparameter. URI:n genereras av Azure Storage när du begär en SAS för den uppladdade nyckelfilen.

{KEY IDENTIFIER}: Azure Key Vault-nyckelidentifierare som används för nyckelkryptering. Med en åtkomstprincip kan programmet komma åt nyckelvalvet med Getbehörigheterna , Unwrap Keyoch Wrap Key . Versionen av nyckeln hämtas från nyckeln i Entra- eller Azure-portalen när den har skapats. Om du aktiverar automatisk rotation av nyckelvalvsnyckeln kontrollerar du att du använder en versionslös nyckelidentifierare i appens nyckelvalvskonfiguration, där inget nyckel-GUID placeras i slutet av identifieraren (exempel: https://contoso.vault.azure.net/keys/data-protection).

Spara nycklar till filsystemet (PersistKeysToFileSystem)

Om du vill lagra nycklar på en UNC-resurs i stället för på den %LOCALAPPDATA% standardplatsen, konfigurerar du systemet med PersistKeysToFileSystem:

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

Spara nycklar i en databas (PersistKeysToDbContext)

Om du vill lagra nycklar i en databas med EntityFramework konfigurerar du systemet med paketet Microsoft.AspNetCore.DataProtection.EntityFrameworkCore :

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

Koden ovan lagrar nycklarna i den konfigurerade databasen. Databaskontexten som används måste implementera IDataProtectionKeyContext. IDataProtectionKeyContext exponerar egenskapen DataProtectionKeys

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

Den här egenskapen representerar tabellen där nycklarna lagras. Skapa tabellen manuellt eller med DbContext migreringar. Mer information finns i DataProtectionKey.

Skydda nycklars konfigurations-API (ProtectKeysWith\*)

Du kan konfigurera systemet för att skydda vilande nycklar genom att anropa någon av konfigurations-API ProtectKeysWith\* :erna. Tänk på exemplet nedan, som lagrar nycklar på en UNC-resurs och krypterar dessa nycklar i vila med ett specifikt X.509-certifikat.

Du kan tillhandahålla en X509Certificate2 från en fil till ProtectKeysWithCertificate genom att anropa X509CertificateLoader.LoadCertificateFromFile.

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

Följande kodexempel visar hur du läser in ett certifikat med ett tumavtryck:

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

Du kan ange ett X509Certificate2, som till exempel ett certifikat som lästs in från en fil:

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

Följande kodexempel visar hur du läser in ett certifikat med ett tumavtryck:

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

Exempel och diskussion om de inbyggda mekanismerna för nyckelkryptering finns i Nyckelkryptering i vila i Windows och Azure med hjälp av ASP.NET Core.

Ta bort skyddet av nycklar med valfritt certifikat (UnprotectKeysWithAnyCertificate)

Du kan rotera certifikat och dekryptera vilande nycklar med hjälp av en matris med X509Certificate2 certifikat 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"]));

Ange standardnyckelns livslängd (SetDefaultKeyLifetime)

Om du vill konfigurera systemet att använda en nyckellivslängd på 14 dagar i stället för standardvärdet 90 dagar använder du SetDefaultKeyLifetime:

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

Ange programnamnet (SetApplicationName)

Dataskyddssystemet isolerar som standard appar från varandra baserat på deras rotsökvägar för innehåll , även om de delar samma lagringsplats för fysiska nycklar. Den här isoleringen hindrar apparna från att förstå varandras skyddade nyttolaster.

Så här delar du skyddade nyttolaster mellan appar:

• Konfigurera SetApplicationName i varje app med samma värde.
• Använd samma version av Data Protection API-stacken i apparna. Utför något av följande i apparnas projektfiler:
  • Referera till samma delade ramverksversion via Microsoft.AspNetCore.App metapackage.
  • Referera till samma version av dataskyddspaketet .

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

SetApplicationName ställer in internt DataProtectionOptions.ApplicationDiscriminator. I felsökningssyfte kan värdet som tilldelats till diskriminatorn av ramverket loggas med följande kod placerad efter att WebApplication har skapats i Program.cs:

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

Mer information om hur diskrimineringen används finns i följande avsnitt senare i den här artikeln:

• Isolering per applikation
• Dataskydd och appisolering

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

Inaktivera automatisk nyckelgenerering (DisableAutomaticKeyGeneration)

Du kan ha ett scenario där du inte vill att en app automatiskt ska rulla nycklar (skapa nya nycklar) när de närmar sig förfallodatum. Ett exempel på det här scenariot kan vara appar som har konfigurerats i en primär/sekundär konfiguration, där endast den primära appen ansvarar för nyckelhanteringsfrågor och sekundära appar helt enkelt har enbart läsbar vy av nyckelringen. De sekundära apparna kan konfigureras för att behandla nyckelringen som skrivskyddad genom att konfigurera systemet med DisableAutomaticKeyGeneration:

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

Isolering per applikation

När dataskyddssystemet tillhandahålls av en ASP.NET Core-värd isoleras appar automatiskt från varandra, även om dessa appar körs under samma arbetsprocesskonto och använder samma huvudnyckelmaterial. Detta liknar isolateApps-modifieraren från System.Web-elementet <machineKey> .

Isoleringsmekanismen fungerar genom att betrakta varje app på den lokala datorn som en unik klientorganisation, vilket innebär att den IDataProtector-rotade strukturen för en viss app automatiskt innehåller app-ID:t som en diskriminator (ApplicationDiscriminator). Appens unika ID är appens fysiska sökväg:

• För appar som finns i IIS är det unika ID:t appens fysiska IIS-sökväg. Om en app distribueras i en webbgruppsmiljö är det här värdet stabilt förutsatt att IIS-miljöerna konfigureras på samma sätt för alla datorer i webbgruppen.
• För appar med egen värd som körs på Kestrel servern är det unika ID:t den fysiska sökvägen till appen på disken.

Den unika identifieraren är utformad för att överleva återställningar – både för den enskilda appen och för själva datorn.

Den här isoleringsmekanismen förutsätter att apparna inte är skadliga. En skadlig app kan alltid påverka alla andra appar som körs under samma arbetsprocesskonto. I en delad värdmiljö där appar är ömsesidigt obetrodda bör värdleverantören vidta åtgärder för att säkerställa isolering på operativsystemnivå mellan appar, inklusive att separera apparnas underliggande nyckellagringsplatser.

Om dataskyddssystemet inte tillhandahålls av en ASP.NET Core-värd (till exempel om du instansierar det via den DataProtectionProvider konkreta typen) inaktiveras appisolering som standard. När appisolering är inaktiverat kan alla appar som backas upp av samma nyckelmaterial dela nyttolaster så länge de tillhandahåller lämpliga syften. Om du vill tillhandahålla appisolering i den SetApplicationName här miljön anropar du metoden för konfigurationsobjektet och anger ett unikt namn för varje app.

Dataskydd och appisolering

Överväg följande punkter för appisolering:

• När flera appar pekas på samma nyckellagringsplats är avsikten att apparna delar samma huvudnyckelmaterial. Dataskydd utvecklas med antagandet att alla appar som delar en nyckelring kan komma åt alla objekt i nyckelringen. Programmets unika identifierare används för att isolera programspecifika nycklar som härleds från nyckelringens tillhandahållna nycklar. Den förväntar sig inte att behörigheter på objektnivå, till exempel de som tillhandahålls av Azure KeyVault, ska användas för att framtvinga extra isolering. Försök till behörigheter på objektnivå genererar programfel. Om du inte vill förlita dig på den inbyggda programisoleringen ska separata platser för nyckellagring användas och inte delas mellan program.

• Programdiskriminatorn (ApplicationDiscriminator) används för att tillåta att olika appar delar samma huvudnyckelmaterial, men för att hålla sina kryptografiska nyttolaster åtskilda från varandra. För att apparna ska kunna läsa varandras kryptografiska nyttolaster måste de ha samma programdiskriminator, som kan anges genom att anropa SetApplicationName.

• Om en app komprometteras (till exempel av en RCE-attack) måste även allt huvudnyckelmaterial som är tillgängligt för appen betraktas som komprometterat, oavsett dess skyddsstatus. Detta innebär att om två appar pekas på samma lagringsplats, även om de använder olika appdiskriminatorer, är en kompromiss av en funktionellt likvärdig med en kompromiss mellan båda.

  Den här "funktionella motsvarigheten till en kompromiss av båda" -satsen gäller även om de två apparna använder olika mekanismer för nyckelskydd i vila. Detta är vanligtvis inte en förväntad konfiguration. Skyddsmekanismen är avsedd att ge skydd i händelse av att en cyberangripare får läsåtkomst till lagringsplatsen. En cyberattacker som får skrivåtkomst till lagringsplatsen (kanske för att de har uppnått kodkörningsbehörighet i en app) kan infoga skadliga nycklar i lagringen. Dataskyddssystemet ger avsiktligt inte skydd mot en cyberattacker som får skrivåtkomst till nyckellagringsplatsen.

• Om appar måste förbli verkligt isolerade från varandra bör de använda olika viktiga lagringsplatser. Detta faller naturligtvis ur definitionen av "isolerad". Appar är inte isolerade om alla har läs- och skrivåtkomst till varandras datalager.

Ändra algoritmer med UseCryptographicAlgorithms

Med Data Protection-stacken kan du ändra standardalgoritmen som används av nyligen genererade nycklar. Det enklaste sättet att göra detta är att anropa UseCryptographicAlgorithms från konfigurationsåteranropet:

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

StandardkrypteringAlgoritm är AES-256-CBC och standardverifieringAlgoritm är HMACSHA256. Standardprincipen kan ställas in av en systemadministratör via en princip som gäller för hela maskinen, men ett explicit anrop till åsidosätter standardprincipen.

Med anrop UseCryptographicAlgorithms kan du ange önskad algoritm från en fördefinierad inbyggd lista. Du behöver inte bekymra dig om implementeringen av algoritmen. I scenariot ovan försöker dataskyddssystemet använda CNG-implementeringen av AES om det körs i Windows. Annars återgår den till den hanterade System.Security.Cryptography.Aes klassen.

Du kan ange en implementering manuellt via ett anrop till UseCustomCryptographicAlgorithms.

Specificera anpassade hanteringsalgoritmer

Om du vill ange anpassade hanterade algoritmer skapar du en ManagedAuthenticatedEncryptorConfiguration instans som pekar på implementeringstyperna:

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

I allmänhet måste *Typegenskaper peka på konkreta, instansierbara (via en offentlig parameterlös konstruktor) implementeringar av SymmetricAlgorithm och KeyedHashAlgorithm, även om systemet hanterar vissa värden som specialfall, som typeof(Aes), för att underlätta.

Ange anpassade Windows CNG-algoritmer

Om du vill ange en anpassad Windows CNG-algoritm med CBC-lägeskryptering med HMAC-validering skapar du en CngCbcAuthenticatedEncryptorConfiguration instans som innehåller algoritminformationen:

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

Om du vill ange en anpassad Windows CNG-algoritm med kryptering i Galois/Counter Mode med validering skapar du en CngGcmAuthenticatedEncryptorConfiguration instans som innehåller algoritminformationen:

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256
    });

Ange andra anpassade algoritmer

Även om det inte exponeras som ett förstklassigt API är dataskyddssystemet utökningsbart nog för att tillåta att nästan alla typer av algoritmer anges. Du kan till exempel behålla alla nycklar i en maskinvarusäkerhetsmodul (HSM) och tillhandahålla en anpassad implementering av kärnkrypterings- och dekrypteringsrutinerna. Mer information IAuthenticatedEncryptor finns i Utökningsbarhet för kärnkryptografi.

Bevarande av nycklar vid driften i en Docker-container

När du är värd för en Docker-container ska nycklar underhållas i något av följande:

• En mapp som är en Docker-volym som finns kvar utanför containerns livslängd, till exempel en delad volym eller en värdmonterad volym.
• En extern provider, till exempel Azure Blob Storage (visas i ProtectKeysWithAzureKeyVault avsnittet) eller Redis.

Bevara nycklar med Redis

Endast Redis-versioner som stöder Redis Data Persistence ska användas för att lagra nycklar. Azure Blob Storage är beständigt och kan användas för att lagra nycklar. Mer information finns i det här GitHub-problemet.

Logging

Aktivera Information eller en lägre loggningsnivå för att diagnostisera problem. Följande appsettings.json fil aktiverar informationsloggning av DATASKYDDS-API:et:

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

Mer information om loggning finns i Loggning i .NET och ASP.NET Core.

Ytterligare resurser

• Icke-DI-medvetna scenarier för dataskydd i ASP.NET Core
• Stöd för dataskyddsprinciper för hela datorn i ASP.NET Core
• Host ASP.NET Core i ett webbserverkluster
• Nyckellagringsproviders i ASP.NET Core

När dataskyddssystemet initieras tillämpas standardinställningarna baserat på driftmiljön. De här inställningarna är lämpliga för appar som körs på en enda dator. Det finns dock fall där en utvecklare kanske vill ändra standardinställningarna:

• Appen är spridd över flera datorer.
• Av efterlevnadsskäl.

I dessa scenarier erbjuder dataskyddssystemet ett omfattande konfigurations-API.

Följande NuGet-paket krävs för dataskyddstilläggen som används i den här artikeln:

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

Skydda nycklar med Azure Key Vault (ProtectKeysWithAzureKeyVault)

Om du vill interagera med Azure Key Vault lokalt med autentiseringsuppgifter för utvecklare loggar du antingen in på ditt lagringskonto i Visual Studio eller loggar in med Azure CLI. Om du inte redan har installerat Azure CLI kan du läsa Installera Azure CLI. Du kan köra följande kommando i PowerShell-panelen Utvecklare i Visual Studio eller från ett kommandogränssnitt när du inte använder Visual Studio:

az login

Mer information finns i Logga in på Azure med hjälp av utvecklarverktyg.

När du upprättar nyckelvalvet i Entra- eller Azure-portalen:

• Konfigurera nyckelvalvet så att det använder rollbaserad åtkomstkontroll i Azure (RABC). Om du inte arbetar i ett virtuellt Azure-nätverk, inklusive för lokal utveckling och testning, bekräftar du att offentlig åtkomst i nätverkssteget är aktiverad (markerad). Om du aktiverar offentlig åtkomst exponeras endast nyckelvalvets slutpunkt. Autentiserade konton krävs fortfarande för åtkomst.

• Skapa en Azure Managed Identity (eller lägg till en roll i den befintliga Hanterade Identity som du planerar att använda) med Key Vault Crypto User-rollen. Tilldela den hanterade Identity till den Azure App Service som är värd för distributionen: Inställningar>Identity>användartilldelad>Lägg till.

  Note

  Om du även planerar att köra en app lokalt med en behörig användare för blobåtkomst med hjälp av Azure CLI eller Visual Studio Azure Service Authentication lägger du till utvecklarens Azure-användarkonto i Åtkomstkontroll (IAM) med rollen Key Vault Crypto User . Om du vill använda Azure CLI via Visual Studio, kör kommandot az login från Utvecklar-PowerShell-panelen och följ anvisningarna för att autentisera med tenant.

• När nyckelkryptering är aktiv innehåller nycklarna i nyckelfilen kommentaren "This key is encrypted with Azure Key Vault." När du har startat appen väljer du kommandot Visa/redigera på snabbmenyn i slutet av nyckelraden för att bekräfta att en nyckel finns med key vault-säkerhet tillämpad.

• Du kan också aktivera automatisk nyckelrotation för nyckelvalv utan att behöva dekryptera nyttolaster med dataskyddsnycklar baserat på utgångna/roterade nyckelvalvnycklar. Varje genererad dataskyddsnyckel innehåller en referens till nyckelvalvsnyckeln som används för att kryptera den. Se bara till att du behåller utgångna nyckelvalvnycklar, ta inte bort dem i nyckelvalvet. Använd också en versionslös nyckelidentifierare i appens nyckelvalvskonfiguration, där inget nyckel-GUID placeras i slutet av identifieraren (exempel: https://contoso.vault.azure.net/keys/data-protection). Använd en liknande rotationsperiod för båda nycklarna där nyckelvalvsnyckeln roterar oftare än dataskyddsnyckeln för att säkerställa att en ny nyckel för nyckelvalv används vid tidpunkten för rotationen av dataskyddsnyckeln.

Skydda nycklar med Azure Key Vault implementerar en IXmlEncryptor som inaktiverar automatiska dataskyddsinställningar, inklusive lagringsplatsen för nyckelringen. Om du vill konfigurera Azure Blob Storage-providern att lagra nycklarna i bloblagring följer du riktlinjerna i Nyckellagringsproviders i ASP.NET Core och anropar en av PersistKeysToAzureBlobStorage överlagringarna i appen. I följande exempel används den överlagring som accepterar en blob-URI och tokenautentiseringsuppgifter (TokenCredential), som förlitar sig på en Azure Managed Identity för rollbaserad åtkomstkontroll (RBAC).

För att konfigurera Azure Key Vault-providern, anropa en av ProtectKeysWithAzureKeyVault överlagringarna. I följande exempel används den överlagring som accepterar nyckelidentifierare och tokenlegitimationer (TokenCredential), och som förlitar sig på en Hanterad Identity för RBAC i produktion, eller en ManagedIdentityCredential under utveckling och testning (DefaultAzureCredential). Andra överbelastningar accepterar antingen en klient för nyckelvalv eller ett appklient-ID med klientens hemlighet. Mer information finns i Nyckellagringsproviders i ASP.NET Core.

Mer information om Azure SDK:s API och autentisering finns i Autentisera .NET-appar till Azure-tjänster med hjälp av Azure-biblioteket Identity och Ge åtkomst till Key Vault-nycklar, certifikat och hemligheter med rollbaserad åtkomstkontroll i Azure. Information om loggning finns i Loggning med Azure SDK för .NET: Loggning utan klientregistrering. För appar som använder beroendeinjektion kan en app anropa AddAzureClientsCore, skicka true för enableLogForwarding för att skapa och koppla samman loggningsinfrastrukturen.

Information om hur du skapar en nyckel i Azure-portalen finns i Snabbstart: Ange och hämta en nyckel från Azure Key Vault med hjälp av Azure-portalen. Ge nyckeln minst Get, Unwrap Keyoch Wrap Key behörigheter. Registrera nyckelidentifieraren för användning med appens konfiguration. Om du planerar att aktivera automatisk rotation av nyckelvalvsnyckeln registrerar du den versionslösa nyckelidentifieraren, där inget nyckel-GUID placeras i slutet av identifieraren (exempel: https://contoso.vault.azure.net/keys/data-protection).

I filen Program där tjänster är registrerade:

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

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

{MANAGED IDENTITY CLIENT ID}: Azure Hanterad Identity Klient-ID (GUID).

{TENANT ID}: Hyresgäst-ID.

{APPLICATION NAME}: SetApplicationName anger det unika namnet på den här appen i dataskyddssystemet. Värdet ska matcha mellan distributioner av appen.

{BLOB URI}: Fullständig URI till nyckelfilen. URI:n genereras av Azure Storage när du skapar nyckelfilen. Använd inte en SAS.

{KEY IDENTIFIER}: Azure Key Vault-nyckelidentifierare som används för nyckelkryptering. Med en åtkomstprincip kan programmet komma åt nyckelvalvet med Getbehörigheterna , Unwrap Keyoch Wrap Key . Versionen av nyckeln hämtas från nyckeln i Entra- eller Azure-portalen när den har skapats. Om du aktiverar automatisk rotation av nyckelvalvsnyckeln kontrollerar du att du använder en versionslös nyckelidentifierare i appens nyckelvalvskonfiguration, där inget nyckel-GUID placeras i slutet av identifieraren (exempel: https://contoso.vault.azure.net/keys/data-protection).

För att en app ska kunna kommunicera och auktorisera sig själv med Azure Key Vault Azure.Identity måste NuGet-paketet refereras av appen.

Om appen använder de äldre Azure-paketen (Microsoft.AspNetCore.DataProtection.AzureStorage och Microsoft.AspNetCore.DataProtection.AzureKeyVault) rekommenderar vi att du tar bort dessa referenser och uppgraderar till paketen Azure.Extensions.AspNetCore.DataProtection.Blobs och Azure.Extensions.AspNetCore.DataProtection.Keys . De nyare paketen hanterar viktiga problem med säkerhet och stabilitet.

Alternativ sas-metod (signatur för delad åtkomst): Som ett alternativ till att använda en hanterad Identity för åtkomst till nyckelbloben i Azure Blob Storage kan du anropa överbelastningen PersistKeysToAzureBlobStorage som accepterar en blob-URI med en SAS-token. Följande exempel fortsätter att använda antingen en ManagedIdentityCredential (produktion) eller DefaultAzureCredential (utveckling och testning) för dess TokenCredential, enligt föregående exempel:

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

{APPLICATION NAME}: SetApplicationName anger det unika namnet på den här appen i dataskyddssystemet. Värdet ska matcha mellan distributioner av appen.

{BLOB URI WITH SAS}: Den fullständiga URI:n där nyckelfilen ska lagras med SAS-token som en frågesträngsparameter. URI:n genereras av Azure Storage när du begär en SAS för den uppladdade nyckelfilen.

{KEY IDENTIFIER}: Azure Key Vault-nyckelidentifierare som används för nyckelkryptering. Med en åtkomstprincip kan programmet komma åt nyckelvalvet med Getbehörigheterna , Unwrap Keyoch Wrap Key . Versionen av nyckeln hämtas från nyckeln i Entra- eller Azure-portalen när den har skapats. Om du aktiverar automatisk rotation av nyckelvalvsnyckeln kontrollerar du att du använder en versionslös nyckelidentifierare i appens nyckelvalvskonfiguration, där inget nyckel-GUID placeras i slutet av identifieraren (exempel: https://contoso.vault.azure.net/keys/data-protection).

Spara nycklar till filsystemet (PersistKeysToFileSystem)

Om du vill lagra nycklar på en UNC-resurs i stället för på den %LOCALAPPDATA% standardplatsen, konfigurerar du systemet med PersistKeysToFileSystem:

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

Spara nycklar i en databas (PersistKeysToDbContext)

Om du vill lagra nycklar i en databas med EntityFramework konfigurerar du systemet med paketet Microsoft.AspNetCore.DataProtection.EntityFrameworkCore :

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

Koden ovan lagrar nycklarna i den konfigurerade databasen. Databaskontexten som används måste implementera IDataProtectionKeyContext. IDataProtectionKeyContext exponerar egenskapen DataProtectionKeys

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

Den här egenskapen representerar tabellen där nycklarna lagras. Skapa tabellen manuellt eller med DbContext migreringar. Mer information finns i DataProtectionKey.

Skydda nycklars konfigurations-API (ProtectKeysWith\*)

Du kan konfigurera systemet för att skydda vilande nycklar genom att anropa någon av konfigurations-API ProtectKeysWith\* :erna. Tänk på exemplet nedan, som lagrar nycklar på en UNC-resurs och krypterar dessa nycklar i vila med ett specifikt X.509-certifikat:

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

Du kan ange ett X509Certificate2, som till exempel ett certifikat som lästs in från en fil:

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

Fler exempel och diskussioner om de inbyggda mekanismerna för nyckelkryptering finns i Nyckelkryptering i vila i Windows och Azure med hjälp av ASP.NET Core.

Ta bort skyddet av nycklar med valfritt certifikat (UnprotectKeysWithAnyCertificate)

Du kan rotera certifikat och dekryptera vilande nycklar med hjälp av en matris med X509Certificate2 certifikat 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"]));
}

Ange standardnyckelns livslängd (SetDefaultKeyLifetime)

Om du vill konfigurera systemet att använda en nyckellivslängd på 14 dagar i stället för standardvärdet 90 dagar använder du SetDefaultKeyLifetime:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .SetDefaultKeyLifetime(TimeSpan.FromDays(14));
}

Ange programnamnet (SetApplicationName)

Dataskyddssystemet isolerar som standard appar från varandra baserat på deras rotsökvägar för innehåll , även om de delar samma lagringsplats för fysiska nycklar. Den här isoleringen hindrar apparna från att förstå varandras skyddade nyttolaster.

Så här delar du skyddade nyttolaster mellan appar:

• Konfigurera SetApplicationName i varje app med samma värde.
• Använd samma version av Data Protection API-stacken i apparna. Utför något av följande i apparnas projektfiler:
  • Referera till samma delade ramverksversion via Microsoft.AspNetCore.App metapackage.
  • Referera till samma version av dataskyddspaketet .

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .SetApplicationName("{APPLICATION NAME}");
}

SetApplicationName ställer in internt DataProtectionOptions.ApplicationDiscriminator. Mer information om hur diskrimineringen används finns i följande avsnitt senare i den här artikeln:

• Isolering per applikation
• Dataskydd och appisolering

Inaktivera automatisk nyckelgenerering (DisableAutomaticKeyGeneration)

Du kan ha ett scenario där du inte vill att en app automatiskt ska rulla nycklar (skapa nya nycklar) när de närmar sig förfallodatum. Ett exempel på det här scenariot kan vara appar som har konfigurerats i en primär/sekundär konfiguration, där endast den primära appen ansvarar för nyckelhanteringsfrågor och sekundära appar helt enkelt har enbart läsbar vy av nyckelringen. De sekundära apparna kan konfigureras för att behandla nyckelringen som skrivskyddad genom att konfigurera systemet med DisableAutomaticKeyGeneration:

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

Isolering per applikation

När dataskyddssystemet tillhandahålls av en ASP.NET Core-värd isoleras appar automatiskt från varandra, även om dessa appar körs under samma arbetsprocesskonto och använder samma huvudnyckelmaterial. Detta liknar isolateApps-modifieraren från System.Web-elementet <machineKey> .

Isoleringsmekanismen fungerar genom att betrakta varje app på den lokala datorn som en unik klientorganisation, vilket innebär att den IDataProtector-rotade strukturen för en viss app automatiskt innehåller app-ID:t som en diskriminator (ApplicationDiscriminator). Appens unika ID är appens fysiska sökväg:

• För appar som finns i IIS är det unika ID:t appens fysiska IIS-sökväg. Om en app distribueras i en webbgruppsmiljö är det här värdet stabilt förutsatt att IIS-miljöerna konfigureras på samma sätt för alla datorer i webbgruppen.
• För appar med egen värd som körs på Kestrel servern är det unika ID:t den fysiska sökvägen till appen på disken.

Den unika identifieraren är utformad för att överleva återställningar – både för den enskilda appen och för själva datorn.

Den här isoleringsmekanismen förutsätter att apparna inte är skadliga. En skadlig app kan alltid påverka alla andra appar som körs under samma arbetsprocesskonto. I en delad värdmiljö där appar är ömsesidigt obetrodda bör värdleverantören vidta åtgärder för att säkerställa isolering på operativsystemnivå mellan appar, inklusive att separera apparnas underliggande nyckellagringsplatser.

Om dataskyddssystemet inte tillhandahålls av en ASP.NET Core-värd (till exempel om du instansierar det via den DataProtectionProvider konkreta typen) inaktiveras appisolering som standard. När appisolering är inaktiverat kan alla appar som backas upp av samma nyckelmaterial dela nyttolaster så länge de tillhandahåller lämpliga syften. Om du vill tillhandahålla appisolering i den här miljön anropar du metoden SetApplicationName i konfigurationsobjektet och anger ett unikt namn för varje app.

Dataskydd och appisolering

Överväg följande punkter för appisolering:

• När flera appar pekas på samma nyckellagringsplats är avsikten att apparna delar samma huvudnyckelmaterial. Dataskydd utvecklas med antagandet att alla appar som delar en nyckelring kan komma åt alla objekt i nyckelringen. Programmets unika identifierare används för att isolera programspecifika nycklar som härleds från nyckelringens tillhandahållna nycklar. Den förväntar sig inte att behörigheter på objektnivå, till exempel de som tillhandahålls av Azure KeyVault, ska användas för att framtvinga extra isolering. Försök till behörigheter på objektnivå genererar programfel. Om du inte vill förlita dig på den inbyggda programisoleringen ska separata platser för nyckellagring användas och inte delas mellan program.

• Programdiskriminatorn (ApplicationDiscriminator) används för att tillåta att olika appar delar samma huvudnyckelmaterial, men för att hålla sina kryptografiska nyttolaster åtskilda från varandra. För att apparna ska kunna läsa varandras kryptografiska nyttolaster måste de ha samma programdiskriminator, som kan anges genom att anropa SetApplicationName.

• Om en app komprometteras (till exempel av en RCE-attack) måste även allt huvudnyckelmaterial som är tillgängligt för appen betraktas som komprometterat, oavsett dess skyddsstatus. Detta innebär att om två appar pekas på samma lagringsplats, även om de använder olika appdiskriminatorer, är en kompromiss av en funktionellt likvärdig med en kompromiss mellan båda.

  Den här "funktionella motsvarigheten till en kompromiss av båda" -satsen gäller även om de två apparna använder olika mekanismer för nyckelskydd i vila. Detta är vanligtvis inte en förväntad konfiguration. Skyddsmekanismen är avsedd att ge skydd i händelse av att en cyberangripare får läsåtkomst till lagringsplatsen. En cyberattacker som får skrivåtkomst till lagringsplatsen (kanske för att de har uppnått kodkörningsbehörighet i en app) kan infoga skadliga nycklar i lagringen. Dataskyddssystemet ger avsiktligt inte skydd mot en cyberattacker som får skrivåtkomst till nyckellagringsplatsen.

• Om appar måste förbli verkligt isolerade från varandra bör de använda olika viktiga lagringsplatser. Detta faller naturligtvis ur definitionen av "isolerad". Appar är inte isolerade om alla har läs- och skrivåtkomst till varandras datalager.

Ändra algoritmer med UseCryptographicAlgorithms

Med Data Protection-stacken kan du ändra standardalgoritmen som används av nyligen genererade nycklar. Det enklaste sättet att göra detta är att anropa UseCryptographicAlgorithms från konfigurationsåteranropet:

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

StandardkrypteringAlgoritm är AES-256-CBC och standardverifieringAlgoritm är HMACSHA256. Standardprincipen kan ställas in av en systemadministratör via en princip som gäller för hela maskinen, men ett explicit anrop till åsidosätter standardprincipen.

Med anrop UseCryptographicAlgorithms kan du ange önskad algoritm från en fördefinierad inbyggd lista. Du behöver inte bekymra dig om implementeringen av algoritmen. I scenariot ovan försöker dataskyddssystemet använda CNG-implementeringen av AES om det körs i Windows. Annars återgår den till den hanterade System.Security.Cryptography.Aes klassen.

Du kan ange en implementering manuellt via ett anrop till UseCustomCryptographicAlgorithms.

Specificera anpassade hanteringsalgoritmer

Om du vill ange anpassade hanterade algoritmer skapar du en ManagedAuthenticatedEncryptorConfiguration instans som pekar på implementeringstyperna:

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

I allmänhet måste *Typegenskaper peka på konkreta, instansierbara (via en offentlig parameterlös konstruktor) implementeringar av SymmetricAlgorithm och KeyedHashAlgorithm, även om systemet hanterar vissa värden som specialfall, som typeof(Aes), för att underlätta.

Ange anpassade Windows CNG-algoritmer

Om du vill ange en anpassad Windows CNG-algoritm med CBC-lägeskryptering med HMAC-validering skapar du en CngCbcAuthenticatedEncryptorConfiguration instans som innehåller algoritminformationen:

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256,

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

Om du vill ange en anpassad Windows CNG-algoritm med kryptering i Galois/Counter Mode med validering skapar du en CngGcmAuthenticatedEncryptorConfiguration instans som innehåller algoritminformationen:

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256
    });

Ange andra anpassade algoritmer

Även om det inte exponeras som ett förstklassigt API är dataskyddssystemet utökningsbart nog för att tillåta att nästan alla typer av algoritmer anges. Du kan till exempel behålla alla nycklar i en maskinvarusäkerhetsmodul (HSM) och tillhandahålla en anpassad implementering av kärnkrypterings- och dekrypteringsrutinerna. Mer information IAuthenticatedEncryptor finns i Utökningsbarhet för kärnkryptografi.

Bevarande av nycklar vid driften i en Docker-container

När du är värd för en Docker-container ska nycklar underhållas i något av följande:

• En mapp som är en Docker-volym som finns kvar utanför containerns livslängd, till exempel en delad volym eller en värdmonterad volym.
• En extern provider, till exempel Azure Blob Storage (visas i avsnittet Skydda nycklar med Azure Key Vault (ProtectKeysWithAzureKeyVault) eller Redis.

Bevara nycklar med Redis

Endast Redis-versioner som stöder Redis Data Persistence ska användas för att lagra nycklar. Azure Blob Storage är beständigt och kan användas för att lagra nycklar. Mer information finns i det här GitHub-problemet.

Logging

Aktivera Information eller en lägre loggningsnivå för att diagnostisera problem. Följande appsettings.json fil aktiverar informationsloggning av DATASKYDDS-API:et:

{
  "Logging": {
    "LogLevel": {
      "Microsoft.AspNetCore.DataProtection": "Information"
    }
  }
}

Mer information om loggning finns i Loggning i .NET och ASP.NET Core.

Ytterligare resurser

• Icke-DI-medvetna scenarier för dataskydd i ASP.NET Core
• Stöd för dataskyddsprinciper för hela datorn i ASP.NET Core
• Host ASP.NET Core i ett webbserverkluster
• Nyckellagringsproviders i ASP.NET Core