Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Wanneer het systeem voor gegevensbeveiliging wordt geïnitialiseerd, worden standaardinstellingen toegepast op basis van de operationele omgeving. Deze instellingen zijn geschikt voor apps die op één computer worden uitgevoerd. Er zijn echter gevallen waarin een ontwikkelaar mogelijk de standaardinstellingen wilt wijzigen:
- De app is verspreid over meerdere computers.
- Voor nalevingsredenen.
Voor deze scenario's biedt het Data Protection-systeem een uitgebreide configuratie-API.
Warning
Net als bij configuratiebestanden moet de sleutelring voor gegevensbeveiliging worden beveiligd met de juiste machtigingen. U kunt ervoor kiezen om sleutels in rust te versleutelen, maar dit voorkomt niet dat cyberaanvallen nieuwe sleutels maken. De beveiliging van uw app wordt dus beïnvloed. De opslaglocatie die is geconfigureerd met Data Protection, moet de toegang tot de app zelf hebben, vergelijkbaar met de manier waarop u configuratiebestanden zou beveiligen. Als u bijvoorbeeld ervoor kiest om uw sleutelring op schijf op te slaan, gebruikt u bestandssysteemmachtigingen. Zorg ervoor dat alleen de identiteit waaronder uw web-app wordt uitgevoerd, lees-, schrijf- en maaktoegang tot die map heeft. Als u Azure Blob Storage gebruikt, moet alleen de web-app de mogelijkheid hebben om nieuwe vermeldingen te lezen, schrijven of maken in de blobopslag, enzovoort.
De extensiemethode AddDataProtection retourneert een IDataProtectionBuilder.
IDataProtectionBuilder biedt uitbreidingsmethoden die u aan elkaar kunt koppelen om opties voor gegevensbescherming te configureren.
Note
Dit artikel is geschreven voor een app die wordt uitgevoerd in een Docker-container. In een Docker-container heeft de app altijd hetzelfde pad en daarom dezelfde toepassingsdiscriminator. Apps die in meerdere omgevingen moeten worden uitgevoerd (bijvoorbeeld lokaal en geïmplementeerd), moeten de standaardtoepassingsdiscriminatie voor de omgeving instellen. Het uitvoeren van een app in meerdere omgevingen valt buiten het bereik van dit artikel.
De volgende NuGet-pakketten zijn vereist voor de extensies voor gegevensbescherming die in dit artikel worden gebruikt:
Sleutels beveiligen met Azure Key Vault (ProtectKeysWithAzureKeyVault)
Als u lokaal wilt communiceren met Azure Key Vault met behulp van ontwikkelaarsreferenties, meldt u zich aan bij uw opslagaccount in Visual Studio of meldt u zich aan met de Azure CLI. Als u de Azure CLI nog niet hebt geïnstalleerd, raadpleegt u De Azure CLI installeren. U kunt de volgende opdracht uitvoeren in het deelvenster Developer PowerShell in Visual Studio of vanuit een opdrachtshell wanneer u Visual Studio niet gebruikt:
az login
Zie Aanmelden bij Azure met behulp van hulpprogramma's voor ontwikkelaars voor meer informatie.
Bij het tot stand brengen van de sleutelkluis in de Entra- of Azure-portal:
Configureer de sleutelkluis voor het gebruik van op rollen gebaseerd toegangsbeheer van Azure (RABC). Als u niet werkt in een virtueel Azure-netwerk, inclusief voor lokale ontwikkeling en testen, controleert u of openbare toegang in de netwerkstap is ingeschakeld (ingeschakeld). Als u openbare toegang inschakelt, wordt alleen het eindpunt van de sleutelkluis weergegeven. Geverifieerde accounts zijn nog steeds vereist voor toegang.
Maak een door Azure beheerde Identity (of voeg een rol toe aan de bestaande beheerde Identity die u wilt gebruiken) met de Key Vault Crypto User rol. Wijs het beheerde Identity toe aan de Azure App Service die de implementatie als host heeft: Instellingen>Identity>Door gebruiker toegewezen>Toevoegen.
Note
Als u ook van plan bent om een app lokaal uit te voeren met een geautoriseerde gebruiker voor blobtoegang met behulp van de Azure CLI of Azure Service Authentication van Visual Studio, voegt u uw Azure-gebruikersaccount voor ontwikkelaars toe in Access Control (IAM) met de rol Crypto-gebruiker van Key Vault . Als u de Azure CLI wilt gebruiken via Visual Studio, voert u de
az loginopdracht uit vanuit het deelvenster Ontwikkelaars powershell en volgt u de aanwijzingen om u te verifiëren bij de tenant.Wanneer sleutelversleuteling actief is, bevatten sleutels in het sleutelbestand de opmerking 'This key is encrypted with Azure Key Vault.' Nadat u de app hebt gestart, selecteert u de opdracht Weergeven/bewerken in het contextmenu aan het einde van de sleutelrij om te bevestigen dat er een sleutel aanwezig is met de beveiliging van de sleutelkluis.
U kunt desgewenst automatische sleutelrotatie van de sleutelkluis inschakelen zonder dat u zich zorgen hoeft te maken over het ontsleutelen van nettoladingen met gegevensbeveiligingssleutels op basis van verlopen/gedraaide sleutelkluissleutels. Elke gegenereerde sleutel voor gegevensbeveiliging bevat een verwijzing naar de sleutelkluissleutel die wordt gebruikt om deze te versleutelen. Zorg ervoor dat u verlopen sleutelkluissleutels behoudt, verwijder ze niet in de sleutelkluis. Gebruik ook een versieloze sleutel-id in de sleutelkluisconfiguratie van de app, waarbij aan het einde van de id geen sleutel-GUID wordt geplaatst (bijvoorbeeld:
https://contoso.vault.azure.net/keys/data-protection). Gebruik een vergelijkbare rotatieperiode voor beide sleutels, waarbij de sleutel in de sleutelkluis vaker wordt geroteerd dan de gegevensbeschermingssleutel, om ervoor te zorgen dat er een nieuwe sleutelkluis wordt gebruikt op het moment dat de gegevensbeschermingssleutel wordt geroteerd.
Als u sleutels beveiligt IXmlEncryptor met Azure Key Vault, worden instellingen voor automatische gegevensbeveiliging uitgeschakeld, inclusief de opslaglocatie van de sleutelring. Als u de Azure Blob Storage-provider wilt configureren voor het opslaan van de sleutels in blobopslag, volgt u de richtlijnen in Sleutelopslagproviders in ASP.NET Core en roept u een van de PersistKeysToAzureBlobStorage overbelastingen in de app aan. In het volgende voorbeeld wordt de overload-functie gebruikt die een blob-URI en een tokencredential accepteert (TokenCredential), afhankelijk van een door Azure beheerd Identity voor rolgebaseerd toegangsbeheer (RBAC).
Als u de Azure Key Vault-provider wilt configureren, roept u een van de ProtectKeysWithAzureKeyVault overloads aan. In het volgende voorbeeld wordt de overloadfunctie gebruikt die sleutel-id en tokenreferentie accepteert (TokenCredential), met afhankelijkheid van een Managed Identity voor RBAC in productie (ManagedIdentityCredential) of een DefaultAzureCredential tijdens het ontwikkelen en testen. Andere overload-methodes accepteren een key vault-client of een app-client-id met client-geheim. Zie Key Storage-providers in ASP.NET Corevoor meer informatie.
Zie .NET-apps verifiëren bij Azure-services met behulp van de Azure-bibliotheek Identity en toegang bieden tot Key Vault-sleutels, certificaten en geheimen met op rollen gebaseerd toegangsbeheer van Azure voor meer informatie over de API en verificatie van de Azure SDK. Voor richtlijnen voor logboekregistratie, zie Logboekregistratie met de Azure SDK voor .NET: Loggen zonder clientregistratie. Voor apps die gebruikmaken van afhankelijkheidsinjectie, kan een app AddAzureClientsCore aanroepen en true doorgeven voor enableLogForwarding om de logboekregistratie-infrastructuur te maken en in te stellen.
Als u een sleutel wilt maken in Azure Portal, raadpleegt u quickstart: Een sleutel instellen en ophalen uit Azure Key Vault met behulp van Azure Portal. Geef de sleutel ten minste Get, Unwrap Key, en Wrap Key machtigingen. Noteer de sleutel-id voor gebruik met de configuratie van de app. Als u van plan bent om automatische rotatie van de sleutelkluis in te schakelen, moet u de versieloze sleutel-id opnemen, waarbij aan het einde van de id geen sleutel-GUID wordt geplaatst (bijvoorbeeld: https://contoso.vault.azure.net/keys/data-protection).
In het Program bestand waarin services zijn geregistreerd:
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}: de door Azure beheerde Identity client-id (GUID).
{TENANT ID}: Tenant-ID.
{APPLICATION NAME}: SetApplicationName stelt de unieke naam van deze app in het systeem voor gegevensbeveiliging in. De waarde moet overeenkomen met alle implementaties van de app.
{BLOB URI}: Volledige URI naar het sleutelbestand. De URI wordt gegenereerd door Azure Storage wanneer u het sleutelbestand maakt. Gebruik geen SAS.
{KEY IDENTIFIER}: Azure Key Vault-sleutel-id die wordt gebruikt voor sleutelversleuteling. Met een toegangsbeleid heeft de toepassing toegang tot de sleutelkluis met Get, Unwrap Keyen Wrap Key machtigingen. De versie van de sleutel wordt verkregen uit de Entra- of Azure-portaal nadat deze is aangemaakt. Als u automatische rotatie van de sleutelkluissleutel inschakelt, moet u ervoor zorgen dat u een versieloze sleutel-id gebruikt in de sleutelkluisconfiguratie van de app, waarbij aan het einde van de id geen sleutel-GUID wordt geplaatst (bijvoorbeeld: https://contoso.vault.azure.net/keys/data-protection).
Om een app te laten communiceren en zichzelf te autoriseren met Azure Key Vault, moet er naar het Azure.Identity NuGet-pakket worden verwezen door de app.
Note
Zie voor richtlijnen over het toevoegen van pakketten aan .NET-apps de artikelen onder Pakketten installeren en beheren in de Package consumption workflow (NuGet-documentatie). Bevestig de juiste pakketversies op NuGet.org.
Note
In niet-productieomgevingen gebruikt DefaultAzureCredential het voorgaande voorbeeld om verificatie te vereenvoudigen tijdens het ontwikkelen van apps die in Azure worden geïmplementeerd door referenties te combineren die worden gebruikt in Azure-hostingomgevingen met referenties die worden gebruikt in lokale ontwikkeling. Zie Azure-gehoste .NET-apps verifiëren bij Azure-resources met behulp van een door het systeem toegewezen beheerde identiteit voor meer informatie.
Als de app gebruikmaakt van de oudere Azure-pakketten (Microsoft.AspNetCore.DataProtection.AzureStorage en Microsoft.AspNetCore.DataProtection.AzureKeyVault), raden we u aan deze verwijzingen te verwijderen en te upgraden naar de Azure.Extensions.AspNetCore.DataProtection.Blobs en Azure.Extensions.AspNetCore.DataProtection.Keys pakketten. Met de nieuwere pakketten worden belangrijke beveiligings- en stabiliteitsproblemen opgelost.
Alternatieve SAS-benadering (Shared Access Signature): Als alternatief voor het gebruik van een beheerde Identity methode voor toegang tot de sleutel-blob in Azure Blob Storage kunt u de PersistKeysToAzureBlobStorage overbelasting aanroepen die een blob-URI accepteert met een SAS-token. In het volgende voorbeeld wordt een ManagedIdentityCredential (productie) of DefaultAzureCredential (ontwikkeling en testen) gebruikt voor TokenCredential, zoals te zien is in het voorgaande voorbeeld.
builder.Services.AddDataProtection()
.SetApplicationName("{APPLICATION NAME}")
.PersistKeysToAzureBlobStorage(new Uri("{BLOB URI WITH SAS}"))
.ProtectKeysWithAzureKeyVault(new Uri("{KEY IDENTIFIER}"), credential);
{APPLICATION NAME}: SetApplicationName stelt de unieke naam van deze app in het systeem voor gegevensbeveiliging in. De waarde moet overeenkomen met alle implementaties van de app.
{BLOB URI WITH SAS}: De volledige URI waar het sleutelbestand moet worden opgeslagen met het SAS-token als een queryreeksparameter. De URI wordt gegenereerd door Azure Storage wanneer u een SAS aanvraagt voor het geüploade sleutelbestand.
{KEY IDENTIFIER}: Azure Key Vault-sleutel-id die wordt gebruikt voor sleutelversleuteling. Met een toegangsbeleid heeft de toepassing toegang tot de sleutelkluis met Get, Unwrap Keyen Wrap Key machtigingen. De versie van de sleutel wordt verkregen uit de Entra- of Azure-portaal nadat deze is aangemaakt. Als u automatische rotatie van de sleutelkluissleutel inschakelt, moet u ervoor zorgen dat u een versieloze sleutel-id gebruikt in de sleutelkluisconfiguratie van de app, waarbij aan het einde van de id geen sleutel-GUID wordt geplaatst (bijvoorbeeld: https://contoso.vault.azure.net/keys/data-protection).
Sleutels behouden in het bestandssysteem (PersistKeysToFileSystem)
Als u sleutels wilt opslaan op een UNC-share in plaats van op de %LOCALAPPDATA% standaardlocatie, configureert u het systeem met PersistKeysToFileSystem:
builder.Services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"));
Warning
Als u de locatie van de sleutelpersistentie wijzigt, versleutelt het systeem sleutels in rust niet meer automatisch, omdat het niet weet of DPAPI een geschikt versleutelingsmechanisme is.
Sleutels behouden in een database (PersistKeysToDbContext)
Als u sleutels wilt opslaan in een database met behulp van EntityFramework, configureert u het systeem met het pakket Microsoft.AspNetCore.DataProtection.EntityFrameworkCore :
builder.Services.AddDataProtection()
.PersistKeysToDbContext<SampleDbContext>();
In de voorgaande code worden de sleutels opgeslagen in de geconfigureerde database. De databasecontext die wordt gebruikt, moet IDataProtectionKeyContext implementeren.
IDataProtectionKeyContext legt de eigenschap bloot DataProtectionKeys
public DbSet<DataProtectionKey> DataProtectionKeys { get; set; } = null!;
Deze eigenschap vertegenwoordigt de tabel waarin de sleutels worden opgeslagen. Maak de tabel handmatig of met DbContext migraties. Zie DataProtectionKey voor meer informatie.
Configuratie-API voor sleutels beveiligen (ProtectKeysWith\*)
U kunt het systeem configureren om sleutels in rust te beveiligen door een van de ProtectKeysWith\* configuratie-API's aan te roepen. Bekijk het onderstaande voorbeeld, waarin sleutels op een UNC-share worden opgeslagen en die sleutels in rust worden versleuteld met een specifiek X.509-certificaat.
U kunt een X509Certificate2 vanuit een bestand aan ProtectKeysWithCertificate opgeven door X509CertificateLoader.LoadCertificateFromFile aan te roepen:
builder.Services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
.ProtectKeysWithCertificate(
new X509Certificate2("certificate.pfx", builder.Configuration["CertificatePassword"]));
In het volgende codevoorbeeld ziet u hoe u een certificaat laadt met behulp van een vingerafdruk:
builder.Services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
.ProtectKeysWithCertificate(builder.Configuration["CertificateThumbprint"]);
U kunt een X509Certificate2 opgeven aan ProtectKeysWithCertificate, zoals een certificaat dat uit een bestand is geladen.
builder.Services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
.ProtectKeysWithCertificate(
new X509Certificate2("certificate.pfx", builder.Configuration["CertificatePassword"]));
In het volgende codevoorbeeld ziet u hoe u een certificaat laadt met behulp van een vingerafdruk:
builder.Services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
.ProtectKeysWithCertificate(builder.Configuration["CertificateThumbprint"]);
Zie Sleutelversleuteling-at-rest in Windows en Azure met behulp van ASP.NET Core voor voorbeelden en discussie over de ingebouwde mechanismen voor sleutelversleuteling.
Beveiliging van sleutels opheffen met elk certificaat (UnprotectKeysWithAnyCertificate)
U kunt certificaten roteren en sleutels in rust ontsleutelen met behulp van een matrix met X509Certificate2 certificaten met 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"]));
De standaardlevensduur van de sleutel instellen (SetDefaultKeyLifetime)
Als u het systeem wilt configureren voor het gebruik van een sleutellevensduur van 14 dagen in plaats van de standaard 90 dagen, gebruikt u SetDefaultKeyLifetime:
builder.Services.AddDataProtection()
.SetDefaultKeyLifetime(TimeSpan.FromDays(14));
De naam van de toepassing instellen (SetApplicationName)
Standaard worden met het systeem voor gegevensbeveiliging apps van elkaar geïsoleerd op basis van hun inhoudshoofdpaden , zelfs als ze dezelfde fysieke-sleutelopslagplaats delen. Deze isolatie voorkomt dat de apps inzicht krijgen in elkaars beschermde gegevens.
Beveiligde inhoud delen tussen apps.
- Configureer SetApplicationName in elke app met dezelfde waarde.
- Gebruik dezelfde versie van de Data Protection-API-stack in de apps. Voer een van de volgende handelingen uit in de projectbestanden van de apps:
- Verwijs naar dezelfde gedeelde frameworkversie via de Microsoft.AspNetCore.App metapackage.
- Verwijs naar dezelfde versie van het Data Protection-pakket .
builder.Services.AddDataProtection()
.SetApplicationName("<sharedApplicationName>");
SetApplicationName intern sets DataProtectionOptions.ApplicationDiscriminator. Voor probleemoplossingsdoeleinden kan de waarde van de discriminator, die door het framework is toegewezen, worden vastgelegd met de volgende code die is geplaatst nadat WebApplication is gebouwd in Program.cs.
var discriminator = app.Services.GetRequiredService<IOptions<DataProtectionOptions>>()
.Value.ApplicationDiscriminator;
app.Logger.LogInformation("ApplicationDiscriminator: {ApplicationDiscriminator}", discriminator);
Zie de volgende secties verderop in dit artikel voor meer informatie over hoe de discriminator wordt gebruikt:
Warning
In .NET 6 WebApplicationBuilder normaliseert u het hoofdpad van de inhoud om te eindigen met een DirectorySeparatorChar. In Windows eindigt het hoofdpad van de inhoud bijvoorbeeld in \ en op Linux /. Andere hosts normaliseren het pad niet. De meeste apps die worden gemigreerd van HostBuilder of WebHostBuilder delen niet dezelfde appnaam omdat ze de afsluitende DirectorySeparatorChar niet hebben. U kunt dit probleem omzeilen door het scheidingsteken voor mappen te verwijderen en de naam van de app handmatig in te stellen, zoals wordt weergegeven in de volgende code:
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();
Automatische sleutelgeneratie uitschakelen (DisableAutomaticKeyGeneration)
Mogelijk hebt u een scenario waarin u niet wilt dat een app automatisch sleutels rolt (nieuwe sleutels maken) wanneer deze verlopen. Een voorbeeld van dit scenario kan zijn dat apps zijn ingesteld in een primaire/secundaire relatie, waarbij alleen de primaire app verantwoordelijk is voor belangrijke beheerproblemen en secundaire apps gewoon een alleen-lezenweergave van de sleutelring hebben. De secundaire apps kunnen worden geconfigureerd om de sleutelring als alleen-lezen te behandelen door het systeem te configureren met DisableAutomaticKeyGeneration:
builder.Services.AddDataProtection()
.DisableAutomaticKeyGeneration();
Isolatie per toepassing
Wanneer het systeem voor gegevensbeveiliging wordt geleverd door een ASP.NET Core-host, worden apps automatisch van elkaar geïsoleerd, zelfs als deze apps worden uitgevoerd onder hetzelfde werkprocesaccount en hetzelfde hoofdsleutelingsmateriaal gebruiken. Dit is vergelijkbaar met de IsolateApps-modifier van System.Web's <machineKey> element.
Het isolatiemechanisme werkt door elke app op de lokale computer als een unieke tenant te beschouwen, waardoor de IDataProtector geroote app automatisch de app-id als een discriminator (ApplicationDiscriminator) bevat. De unieke id van de app is het fysieke pad van de app:
- Voor apps die worden gehost in IIS, is de unieke id het fysieke IIS-pad van de app. Als een app wordt geïmplementeerd in een webfarmomgeving, is deze waarde stabiel, ervan uitgaande dat de IIS-omgevingen op dezelfde manier zijn geconfigureerd op alle computers in de webfarm.
- Voor zelf-hostende apps die op de Kestrel server worden uitgevoerd, is de unieke id het fysieke pad naar de app op schijf.
De unieke identificatie is ontworpen om zowel het opnieuw instellen van de afzonderlijke app als de computer zelf te kunnen overleven.
Bij dit isolatiemechanisme wordt ervan uitgegaan dat de apps niet schadelijk zijn. Een schadelijke app kan altijd van invloed zijn op elke andere app die wordt uitgevoerd onder hetzelfde werkprocesaccount. In een gedeelde hostingomgeving waarin apps wederzijds niet worden vertrouwd, moet de hostingprovider stappen ondernemen om isolatie op besturingssysteemniveau tussen apps te garanderen, waaronder het scheiden van de onderliggende sleutelopslagplaatsen van de apps.
Als het systeem voor gegevensbeveiliging niet wordt geleverd door een ASP.NET Core-host (bijvoorbeeld als u het instantiëren via het DataProtectionProvider concrete type) app-isolatie standaard is uitgeschakeld. Wanneer app-isolatie is uitgeschakeld, kunnen alle apps die worden ondersteund door hetzelfde sleutelmateriaal nettoladingen delen zolang ze de juiste doeleinden bieden. Als u app-isolatie in deze omgeving wilt bieden, roept u de SetApplicationName methode voor het configuratieobject aan en geeft u een unieke naam op voor elke app.
Gegevensbescherming en app-isolatie
Houd rekening met de volgende punten voor app-isolatie:
Wanneer meerdere apps naar dezelfde sleutelopslagplaats worden verwezen, is het de bedoeling dat de apps hetzelfde hoofdsleutelmateriaal delen. Data Protection wordt ontwikkeld met de veronderstelling dat alle apps die een sleutelring delen, toegang hebben tot alle items in die sleutelring. De unieke toepassings-id wordt gebruikt om toepassingsspecifieke sleutels te isoleren die zijn afgeleid van de verstrekte sleutelring. Er worden geen machtigingen op itemniveau verwacht, zoals machtigingen van Azure KeyVault die worden gebruikt om extra isolatie af te dwingen. Bij het uitvoeren van machtigingen op itemniveau worden toepassingsfouten gegenereerd. Als u niet wilt vertrouwen op de ingebouwde toepassingsisolatie, moeten afzonderlijke sleutelopslaglocaties worden gebruikt en niet worden gedeeld tussen toepassingen.
De toepassingsdiscriminatie (ApplicationDiscriminator) wordt gebruikt om verschillende apps toe te staan hetzelfde hoofdsleutelmateriaal te delen, maar om hun cryptografische nettoladingen van elkaar te onderscheiden. Om ervoor te zorgen dat de apps de cryptografische nettoladingen van elkaar kunnen lezen, moeten ze dezelfde toepassingsdiscriminator hebben, die kan worden ingesteld door aan te roepen
SetApplicationName.Als een app is gecompromitteerd (bijvoorbeeld door een RCE-aanval), moet alle hoofdsleutelmateriaal dat toegankelijk is voor die app, ook worden beschouwd als gecompromitteerd, ongeacht de beveiligings-at-rest-status. Dit impliceert dat als twee apps naar dezelfde opslagplaats worden verwezen, zelfs als ze verschillende app-discriminators gebruiken, een inbreuk van een app functioneel gelijk is aan een inbreuk van beide.
Deze clausule, die "functioneel gelijkwaardig is aan een compromis van beide", geldt zelfs als de twee apps verschillende mechanismen gebruiken voor sleutelbeveiliging terwijl ze in rust zijn. Dit is doorgaans geen verwachte configuratie. Het bescherming-in-rust-mechanisme is bedoeld om bescherming te bieden in het geval een cyberaanvaller leestoegang krijgt tot de opslagplaats. Een cyberaanval die schrijftoegang krijgt tot de opslagplaats (misschien omdat ze de machtiging voor het uitvoeren van code binnen een app hebben bereikt) kan schadelijke sleutels in de opslag invoegen. Het data protection-systeem biedt opzettelijk geen bescherming tegen een cyberaanval die schrijftoegang krijgt tot de sleutelopslagplaats.
Als apps echt van elkaar moeten worden geïsoleerd, moeten ze verschillende sleutelopslagplaatsen gebruiken. Dit valt natuurlijk buiten de definitie van 'geïsoleerd'. Apps worden niet geïsoleerd als ze allemaal lees- en schrijftoegang hebben tot elkaars gegevensarchieven.
Algoritmen wijzigen met UseCryptographicAlgorithms
Met de Data Protection-stack kunt u het standaardalgoritmen wijzigen dat wordt gebruikt door nieuw gegenereerde sleutels. De eenvoudigste manier om dit te doen, is door vanuit de callback van de configuratie aan te roepen UseCryptographicAlgorithms :
builder.Services.AddDataProtection()
.UseCryptographicAlgorithms(new AuthenticatedEncryptorConfiguration
{
EncryptionAlgorithm = EncryptionAlgorithm.AES_256_CBC,
ValidationAlgorithm = ValidationAlgorithm.HMACSHA256
});
Het standaard versleutelingsalgoritme is AES-256-CBC en het standaard validatie-algoritme is HMACSHA256. Het standaardbeleid kan worden ingesteld door een systeembeheerder via een machine-brede beleid, maar een expliciete oproep naar UseCryptographicAlgorithms overschrijft het standaardbeleid.
Met aanroepen UseCryptographicAlgorithms kunt u het gewenste algoritme opgeven vanuit een vooraf gedefinieerde ingebouwde lijst. U hoeft zich geen zorgen te maken over de implementatie van het algoritme. In het bovenstaande scenario probeert het data protection-systeem de CNG-implementatie van AES te gebruiken als deze wordt uitgevoerd in Windows. Anders valt deze terug op de beheerde System.Security.Cryptography.Aes klasse.
U kunt handmatig een implementatie opgeven via een aanroep naar UseCustomCryptographicAlgorithms.
Tip
Het wijzigen van algoritmen heeft geen invloed op bestaande sleutels in de sleutelring. Dit is alleen van invloed op nieuw gegenereerde sleutels.
Aangepaste beheerde algoritmen opgeven
Als u aangepaste beheerde algoritmen wilt opgeven, maakt u een ManagedAuthenticatedEncryptorConfiguration exemplaar dat verwijst naar de implementatietypen:
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)
});
Over het algemeen moeten de *Type-eigenschappen wijzen naar concrete, instantieerbare (via een openbare parameterloze ctor) implementaties van SymmetricAlgorithm en KeyedHashAlgorithm, hoewel het systeem sommige waarden zoals typeof(Aes) als speciale gevallen behandelt voor het gemak.
Note
De SymmetricAlgorithm moet een sleutellengte hebben van ≥ 128 bits en een blokgrootte van ≥ 64 bits en moet ondersteuning bieden voor CBC-modusversleuteling met PKCS #7 opvulling. De KeyedHashAlgorithm moet een digestgrootte hebben van >= 128 bits en moet sleutels van lengte ondersteunen die gelijk zijn aan de lengte van het hash-algoritme. De KeyedHashAlgorithm is niet strikt vereist om HMAC te zijn.
Aangepaste Windows CNG-algoritmen opgeven
Als u een aangepast Windows CNG-algoritme wilt opgeven met CBC-modusversleuteling met HMAC-validatie, maakt u een CngCbcAuthenticatedEncryptorConfiguration exemplaar met de algoritmegegevens:
builder.Services.AddDataProtection()
.UseCustomCryptographicAlgorithms(new CngCbcAuthenticatedEncryptorConfiguration
{
// Passed to BCryptOpenAlgorithmProvider
EncryptionAlgorithm = "AES",
EncryptionAlgorithmProvider = null,
// Specified in bits
EncryptionAlgorithmKeySize = 256,
// Passed to BCryptOpenAlgorithmProvider
HashAlgorithm = "SHA256",
HashAlgorithmProvider = null
});
Note
Het symmetrische blokcoderingsalgoritmen moeten een sleutellengte hebben van >= 128 bits, een blokgrootte van >= 64 bits en moet ondersteuning bieden voor CBC-modusversleuteling met PKCS #7-opvulling. Het hash-algoritme moet een digestgrootte van >= 128 bits hebben en moet ondersteuning bieden voor het openen met de vlag BCRYPT_ALG_HANDLE_HMAC_FLAG. De eigenschappen van *Provider kunnen worden ingesteld op null om de standaardprovider voor het opgegeven algoritme te gebruiken. Zie de documentatie van BCryptOpenAlgorithmProvider voor meer informatie.
Als u een aangepast Windows CNG-algoritme wilt opgeven met Galois/Counter Mode-versleuteling met validatie, maakt u een CngGcmAuthenticatedEncryptorConfiguration exemplaar dat de algoritmische informatie bevat:
builder.Services.AddDataProtection()
.UseCustomCryptographicAlgorithms(new CngGcmAuthenticatedEncryptorConfiguration
{
// Passed to BCryptOpenAlgorithmProvider
EncryptionAlgorithm = "AES",
EncryptionAlgorithmProvider = null,
// Specified in bits
EncryptionAlgorithmKeySize = 256
});
Note
Het symmetrische blokcoderingsalgoritmen moeten een sleutellengte hebben van >= 128 bits, een blokgrootte van precies 128 bits en moet GCM-versleuteling ondersteunen. U kunt de EncryptionAlgorithmProvider eigenschap instellen op null om de standaardprovider voor het opgegeven algoritme te gebruiken. Zie de documentatie van BCryptOpenAlgorithmProvider voor meer informatie.
Andere aangepaste algoritmen opgeven
Hoewel het niet beschikbaar is als een eersteklas API, is het systeem voor gegevensbeveiliging uitbreidbaar genoeg om vrijwel elk type algoritme op te geven. Het is bijvoorbeeld mogelijk om alle sleutels in een HSM (Hardware Security Module) te bewaren en een aangepaste implementatie van de kernversleutelings- en ontsleutelingsroutines te bieden. Zie voor meer informatie IAuthenticatedEncryptor in de uitbreidbaarheid van de kerncryptografie.
Persistente sleutels bij het hosten in een Docker-container
Bij het hosten in een Docker-container moeten sleutels worden onderhouden in:
- Een map die een Docker-volume is dat langer duurt dan de levensduur van de container, zoals een gedeeld volume of een door een host gekoppeld volume.
- Een externe provider, zoals Azure Blob Storage (weergegeven in de
ProtectKeysWithAzureKeyVaultsectie) of Redis.
Persistente sleutels in Redis
Alleen Redis-versies die Redis-gegevenspersistentie ondersteunen, moeten worden gebruikt om sleutels op te slaan. Azure Blob Storage is permanent en kan worden gebruikt voor het opslaan van sleutels. Zie dit GitHub-probleem voor meer informatie.
Logging
Schakel het Information of lagere logboekregistratieniveau in om problemen te diagnosticeren. Met het volgende appsettings.json bestand wordt logboekregistratie van gegevens van de Data Protection-API ingeschakeld:
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning",
"Microsoft.AspNetCore.DataProtection": "Information"
}
},
"AllowedHosts": "*"
}
Zie Logboekregistratie in .NET en ASP.NET Core voor meer informatie over logboekregistratie.
Aanvullende bronnen
Wanneer het systeem voor gegevensbeveiliging wordt geïnitialiseerd, worden standaardinstellingen toegepast op basis van de operationele omgeving. Deze instellingen zijn geschikt voor apps die op één computer worden uitgevoerd. Er zijn echter gevallen waarin een ontwikkelaar mogelijk de standaardinstellingen wilt wijzigen:
- De app is verspreid over meerdere computers.
- Voor nalevingsredenen.
Voor deze scenario's biedt het Data Protection-systeem een uitgebreide configuratie-API.
Warning
Net als bij configuratiebestanden moet de sleutelring voor gegevensbeveiliging worden beveiligd met de juiste machtigingen. U kunt ervoor kiezen om sleutels in rust te versleutelen, maar dit voorkomt niet dat cyberaanvallen nieuwe sleutels maken. De beveiliging van uw app wordt dus beïnvloed. De opslaglocatie die is geconfigureerd met Data Protection, moet de toegang tot de app zelf hebben, vergelijkbaar met de manier waarop u configuratiebestanden zou beveiligen. Als u bijvoorbeeld ervoor kiest om uw sleutelring op schijf op te slaan, gebruikt u bestandssysteemmachtigingen. Zorg ervoor dat alleen de identiteit waaronder uw web-app wordt uitgevoerd, lees-, schrijf- en maaktoegang tot die map heeft. Als u Azure Blob Storage gebruikt, moet alleen de web-app de mogelijkheid hebben om nieuwe vermeldingen in de blobstore te lezen, schrijven of maken.
De extensiemethode AddDataProtection retourneert een IDataProtectionBuilder, waarmee extensiemethoden worden weergegeven die u aan elkaar kunt koppelen om opties voor gegevensbescherming te configureren.
De volgende NuGet-pakketten zijn vereist voor de extensies voor gegevensbescherming die in dit artikel worden gebruikt:
Note
Zie voor richtlijnen over het toevoegen van pakketten aan .NET-apps de artikelen onder Pakketten installeren en beheren in de Package consumption workflow (NuGet-documentatie). Bevestig de juiste pakketversies op NuGet.org.
Sleutels beveiligen met Azure Key Vault (ProtectKeysWithAzureKeyVault)
Als u lokaal wilt communiceren met Azure Key Vault met behulp van ontwikkelaarsreferenties, meldt u zich aan bij uw opslagaccount in Visual Studio of meldt u zich aan met de Azure CLI. Als u de Azure CLI nog niet hebt geïnstalleerd, raadpleegt u De Azure CLI installeren. U kunt de volgende opdracht uitvoeren in het deelvenster Developer PowerShell in Visual Studio of vanuit een opdrachtshell wanneer u Visual Studio niet gebruikt:
az login
Zie Aanmelden bij Azure met behulp van hulpprogramma's voor ontwikkelaars voor meer informatie.
Bij het aanmaken van de sleutelkluis in de Entra- of Azure-portal:
Configureer de sleutelkluis voor het gebruik van op rollen gebaseerd toegangsbeheer van Azure (RABC). Als u niet werkt in een virtueel Azure-netwerk, inclusief voor lokale ontwikkeling en testen, controleert u of openbare toegang in de netwerkstap is ingeschakeld (ingeschakeld). Als u openbare toegang inschakelt, wordt alleen het eindpunt van de sleutelkluis weergegeven. Geverifieerde accounts zijn nog steeds vereist voor toegang.
Maak een door Azure beheerde Identity (of voeg een rol toe aan de bestaande beheerde Identity die u wilt gebruiken) met de Key Vault Crypto User rol. Wijs het beheerde Identity toe aan de Azure App Service die de implementatie als host heeft: Instellingen>Identity>Door gebruiker toegewezen>Toevoegen.
Note
Als u ook van plan bent om een app lokaal uit te voeren met een geautoriseerde gebruiker voor blobtoegang met behulp van de Azure CLI of Azure Service Authentication van Visual Studio, voegt u uw Azure-gebruikersaccount voor ontwikkelaars toe in Access Control (IAM) met de rol Crypto-gebruiker van Key Vault . Als u de Azure CLI wilt gebruiken via Visual Studio, voert u de
az loginopdracht uit vanuit het deelvenster Ontwikkelaars powershell en volgt u de aanwijzingen om u te verifiëren bij de tenant.Wanneer sleutelversleuteling actief is, bevatten sleutels in het sleutelbestand de opmerking 'This key is encrypted with Azure Key Vault.' Nadat u de app hebt gestart, selecteert u de opdracht Weergeven/bewerken in het contextmenu aan het einde van de sleutelrij om te bevestigen dat er een sleutel aanwezig is met de beveiliging van de sleutelkluis.
U kunt desgewenst automatische sleutelrotatie van de sleutelkluis inschakelen zonder dat u zich zorgen hoeft te maken over het ontsleutelen van nettoladingen met gegevensbeveiligingssleutels op basis van verlopen/gedraaide sleutelkluissleutels. Elke gegenereerde sleutel voor gegevensbeveiliging bevat een verwijzing naar de sleutelkluissleutel die wordt gebruikt om deze te versleutelen. Zorg ervoor dat u verlopen sleutelkluissleutels behoudt, verwijder ze niet in de sleutelkluis. Gebruik ook een versieloze sleutel-id in de sleutelkluisconfiguratie van de app, waarbij aan het einde van de id geen sleutel-GUID wordt geplaatst (bijvoorbeeld:
https://contoso.vault.azure.net/keys/data-protection). Gebruik een vergelijkbare rotatieperiode voor beide sleutels, waarbij de sleutel in de sleutelkluis vaker wordt geroteerd dan de gegevensbeschermingssleutel, om ervoor te zorgen dat er een nieuwe sleutelkluis wordt gebruikt op het moment dat de gegevensbeschermingssleutel wordt geroteerd.
Als u sleutels beveiligt IXmlEncryptor met Azure Key Vault, worden instellingen voor automatische gegevensbeveiliging uitgeschakeld, inclusief de opslaglocatie van de sleutelring. Als u de Azure Blob Storage-provider wilt configureren voor het opslaan van de sleutels in blobopslag, volgt u de richtlijnen in Sleutelopslagproviders in ASP.NET Core en roept u een van de PersistKeysToAzureBlobStorage overbelastingen in de app aan. In het volgende voorbeeld wordt de overload-functie gebruikt die een blob-URI en een tokencredential accepteert (TokenCredential), afhankelijk van een door Azure beheerd Identity voor rolgebaseerd toegangsbeheer (RBAC).
Als u de Azure Key Vault-provider wilt configureren, roept u een van de ProtectKeysWithAzureKeyVault overloads aan. In het volgende voorbeeld wordt de overloadfunctie gebruikt die sleutel-id en tokenreferentie accepteert (TokenCredential), met afhankelijkheid van een Managed Identity voor RBAC in productie (ManagedIdentityCredential) of een DefaultAzureCredential tijdens het ontwikkelen en testen. Andere overload-methodes accepteren een key vault-client of een app-client-id met client-geheim. Zie Key Storage-providers in ASP.NET Corevoor meer informatie.
Zie .NET-apps verifiëren bij Azure-services met behulp van de Azure-bibliotheek Identity en toegang bieden tot Key Vault-sleutels, certificaten en geheimen met op rollen gebaseerd toegangsbeheer van Azure voor meer informatie over de API en verificatie van de Azure SDK. Voor richtlijnen voor logboekregistratie, zie Logboekregistratie met de Azure SDK voor .NET: Loggen zonder clientregistratie. Voor apps die gebruikmaken van afhankelijkheidsinjectie, kan een app AddAzureClientsCore aanroepen en true doorgeven voor enableLogForwarding om de logboekregistratie-infrastructuur te maken en in te stellen.
Als u een sleutel wilt maken in Azure Portal, raadpleegt u quickstart: Een sleutel instellen en ophalen uit Azure Key Vault met behulp van Azure Portal. Geef de sleutel ten minste Get, Unwrap Key en Wrap Key machtigingen. Noteer de sleutel-id voor gebruik met de configuratie van de app. Als u van plan bent om automatische rotatie van de sleutel van de sleutelkluis in te schakelen, moet u de versieloze sleutel-ID vastleggen, waarbij aan het einde van de ID geen sleutel-GUID wordt geplaatst (bijvoorbeeld: https://contoso.vault.azure.net/keys/data-protection).
In het Program bestand waarin services zijn geregistreerd:
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}: de door Azure beheerde Identity client-id (GUID).
{TENANT ID}: Tenant-ID.
{APPLICATION NAME}: SetApplicationName stelt de unieke naam van deze app in het systeem voor gegevensbeveiliging in. De waarde moet overeenkomen met alle implementaties van de app.
{BLOB URI}: Volledige URI naar het sleutelbestand. De URI wordt gegenereerd door Azure Storage wanneer u het sleutelbestand maakt. Gebruik geen SAS.
{KEY IDENTIFIER}: Azure Key Vault-sleutel-id die wordt gebruikt voor sleutelversleuteling. Met een toegangsbeleid heeft de toepassing toegang tot de sleutelkluis met Get, Unwrap Keyen Wrap Key machtigingen. De versie van de sleutel wordt verkregen uit de Entra- of Azure-portaal nadat deze is aangemaakt. Als u automatische rotatie van de sleutelkluissleutel inschakelt, moet u ervoor zorgen dat u een versieloze sleutel-id gebruikt in de sleutelkluisconfiguratie van de app, waarbij aan het einde van de id geen sleutel-GUID wordt geplaatst (bijvoorbeeld: https://contoso.vault.azure.net/keys/data-protection).
Om een app te laten communiceren en zichzelf te autoriseren met Azure Key Vault, moet er naar het Azure.Identity NuGet-pakket worden verwezen door de app.
Note
Zie voor richtlijnen over het toevoegen van pakketten aan .NET-apps de artikelen onder Pakketten installeren en beheren in de Package consumption workflow (NuGet-documentatie). Bevestig de juiste pakketversies op NuGet.org.
Note
In niet-productieomgevingen gebruikt DefaultAzureCredential het voorgaande voorbeeld om verificatie te vereenvoudigen tijdens het ontwikkelen van apps die in Azure worden geïmplementeerd door referenties te combineren die worden gebruikt in Azure-hostingomgevingen met referenties die worden gebruikt in lokale ontwikkeling. Zie Azure-gehoste .NET-apps verifiëren bij Azure-resources met behulp van een door het systeem toegewezen beheerde identiteit voor meer informatie.
Als de app gebruikmaakt van de oudere Azure-pakketten (Microsoft.AspNetCore.DataProtection.AzureStorage en Microsoft.AspNetCore.DataProtection.AzureKeyVault), raden we u aan deze verwijzingen te verwijderen en te upgraden naar de Azure.Extensions.AspNetCore.DataProtection.Blobs en Azure.Extensions.AspNetCore.DataProtection.Keys pakketten. Met de nieuwere pakketten worden belangrijke beveiligings- en stabiliteitsproblemen opgelost.
Alternatieve SAS-benadering (Shared Access Signature): Als alternatief voor het gebruik van een beheerde Identity methode voor toegang tot de sleutel-blob in Azure Blob Storage kunt u de PersistKeysToAzureBlobStorage overbelasting aanroepen die een blob-URI accepteert met een SAS-token. In het volgende voorbeeld wordt een ManagedIdentityCredential (productie) of DefaultAzureCredential (ontwikkeling en testen) gebruikt voor TokenCredential, zoals te zien is in het voorgaande voorbeeld.
services.AddDataProtection()
.SetApplicationName("{APPLICATION NAME}")
.PersistKeysToAzureBlobStorage(new Uri("{BLOB URI WITH SAS}"))
.ProtectKeysWithAzureKeyVault(new Uri("{KEY IDENTIFIER}"), credential);
{APPLICATION NAME}: SetApplicationName stelt de unieke naam van deze app in het systeem voor gegevensbeveiliging in. De waarde moet overeenkomen met alle implementaties van de app.
{BLOB URI WITH SAS}: De volledige URI waar het sleutelbestand moet worden opgeslagen met het SAS-token als een queryreeksparameter. De URI wordt gegenereerd door Azure Storage wanneer u een SAS aanvraagt voor het geüploade sleutelbestand.
{KEY IDENTIFIER}: Azure Key Vault-sleutel-id die wordt gebruikt voor sleutelversleuteling. Met een toegangsbeleid heeft de toepassing toegang tot de sleutelkluis met Get, Unwrap Keyen Wrap Key machtigingen. De versie van de sleutel wordt verkregen uit de Entra- of Azure-portaal nadat deze is aangemaakt. Als u automatische rotatie van de sleutelkluissleutel inschakelt, moet u ervoor zorgen dat u een versieloze sleutel-id gebruikt in de sleutelkluisconfiguratie van de app, waarbij aan het einde van de id geen sleutel-GUID wordt geplaatst (bijvoorbeeld: https://contoso.vault.azure.net/keys/data-protection).
Sleutels behouden in het bestandssysteem (PersistKeysToFileSystem)
Als u sleutels wilt opslaan op een UNC-share in plaats van op de %LOCALAPPDATA% standaardlocatie, configureert u het systeem met PersistKeysToFileSystem:
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"));
}
Warning
Als u de locatie van de sleutelpersistentie wijzigt, versleutelt het systeem sleutels in rust niet meer automatisch, omdat het niet weet of DPAPI een geschikt versleutelingsmechanisme is.
Sleutels behouden in een database (PersistKeysToDbContext)
Als u sleutels wilt opslaan in een database met behulp van EntityFramework, configureert u het systeem met het pakket Microsoft.AspNetCore.DataProtection.EntityFrameworkCore :
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.PersistKeysToDbContext<DbContext>()
}
In de voorgaande code worden de sleutels opgeslagen in de geconfigureerde database. De databasecontext die wordt gebruikt, moet IDataProtectionKeyContext implementeren.
IDataProtectionKeyContext legt de eigenschap bloot DataProtectionKeys
public DbSet<DataProtectionKey> DataProtectionKeys { get; set; }
Deze eigenschap vertegenwoordigt de tabel waarin de sleutels worden opgeslagen. Maak de tabel handmatig of met DbContext migraties. Zie DataProtectionKey voor meer informatie.
Configuratie-API voor sleutels beveiligen (ProtectKeysWith\*)
U kunt het systeem configureren om sleutels in rust te beveiligen door een van de ProtectKeysWith\* configuratie-API's aan te roepen. Bekijk het onderstaande voorbeeld, waarin sleutels op een UNC-share worden opgeslagen en die sleutels in rust worden versleuteld met een specifiek X.509-certificaat:
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
.ProtectKeysWithCertificate(Configuration["Thumbprint"]);
}
U kunt een X509Certificate2 opgeven aan ProtectKeysWithCertificate, zoals een certificaat dat uit een bestand is geladen.
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
.ProtectKeysWithCertificate(
new X509Certificate2("certificate.pfx", Configuration["Thumbprint"]));
}
Zie Sleutelversleuteling-at-rest in Windows en Azure met behulp van ASP.NET Core voor meer voorbeelden en discussie over de ingebouwde mechanismen voor sleutelversleuteling.
Beveiliging van sleutels opheffen met elk certificaat (UnprotectKeysWithAnyCertificate)
U kunt certificaten roteren en sleutels in rust ontsleutelen met behulp van een matrix met X509Certificate2 certificaten met 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"]));
}
De standaardlevensduur van de sleutel instellen (SetDefaultKeyLifetime)
Als u het systeem wilt configureren voor het gebruik van een sleutellevensduur van 14 dagen in plaats van de standaard 90 dagen, gebruikt u SetDefaultKeyLifetime:
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.SetDefaultKeyLifetime(TimeSpan.FromDays(14));
}
De naam van de toepassing instellen (SetApplicationName)
Standaard worden met het systeem voor gegevensbeveiliging apps van elkaar geïsoleerd op basis van hun inhoudshoofdpaden , zelfs als ze dezelfde fysieke-sleutelopslagplaats delen. Deze isolatie voorkomt dat de apps inzicht krijgen in elkaars beschermde gegevens.
Beveiligde inhoud delen tussen apps.
- Configureer SetApplicationName in elke app met dezelfde waarde.
- Gebruik dezelfde versie van de Data Protection-API-stack in de apps. Voer een van de volgende handelingen uit in de projectbestanden van de apps:
- Verwijs naar dezelfde gedeelde frameworkversie via de Microsoft.AspNetCore.App metapackage.
- Verwijs naar dezelfde versie van het Data Protection-pakket .
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.SetApplicationName("{APPLICATION NAME}");
}
SetApplicationName intern sets DataProtectionOptions.ApplicationDiscriminator. Zie de volgende secties verderop in dit artikel voor meer informatie over hoe de discriminator wordt gebruikt:
Automatische sleutelgeneratie uitschakelen (DisableAutomaticKeyGeneration)
Mogelijk hebt u een scenario waarin u niet wilt dat een app automatisch sleutels rolt (nieuwe sleutels maken) wanneer deze verlopen. Een voorbeeld van dit scenario kan zijn dat apps zijn ingesteld in een primaire/secundaire relatie, waarbij alleen de primaire app verantwoordelijk is voor belangrijke beheerproblemen en secundaire apps gewoon een alleen-lezenweergave van de sleutelring hebben. De secundaire apps kunnen worden geconfigureerd om de sleutelring als alleen-lezen te behandelen door het systeem te configureren met DisableAutomaticKeyGeneration:
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.DisableAutomaticKeyGeneration();
}
Isolatie per toepassing
Wanneer het systeem voor gegevensbeveiliging wordt geleverd door een ASP.NET Core-host, worden apps automatisch van elkaar geïsoleerd, zelfs als deze apps worden uitgevoerd onder hetzelfde werkprocesaccount en hetzelfde hoofdsleutelingsmateriaal gebruiken. Dit is vergelijkbaar met de IsolateApps-modifier van System.Web's <machineKey> element.
Het isolatiemechanisme werkt door elke app op de lokale computer als een unieke tenant te beschouwen, waardoor de IDataProtector geroote app automatisch de app-id als een discriminator (ApplicationDiscriminator) bevat. De unieke id van de app is het fysieke pad van de app:
- Voor apps die worden gehost in IIS, is de unieke id het fysieke IIS-pad van de app. Als een app wordt geïmplementeerd in een webfarmomgeving, is deze waarde stabiel, ervan uitgaande dat de IIS-omgevingen op dezelfde manier zijn geconfigureerd op alle computers in de webfarm.
- Voor zelf-hostende apps die op de Kestrel server worden uitgevoerd, is de unieke id het fysieke pad naar de app op schijf.
De unieke identificatie is ontworpen om zowel het opnieuw instellen van de afzonderlijke app als de computer zelf te kunnen overleven.
Bij dit isolatiemechanisme wordt ervan uitgegaan dat de apps niet schadelijk zijn. Een schadelijke app kan altijd van invloed zijn op elke andere app die wordt uitgevoerd onder hetzelfde werkprocesaccount. In een gedeelde hostingomgeving waarin apps wederzijds niet worden vertrouwd, moet de hostingprovider stappen ondernemen om isolatie op besturingssysteemniveau tussen apps te garanderen, waaronder het scheiden van de onderliggende sleutelopslagplaatsen van de apps.
Als het systeem voor gegevensbeveiliging niet wordt geleverd door een ASP.NET Core-host (bijvoorbeeld als u het instantiëren via het DataProtectionProvider concrete type) app-isolatie standaard is uitgeschakeld. Wanneer app-isolatie is uitgeschakeld, kunnen alle apps die worden ondersteund door hetzelfde sleutelmateriaal nettoladingen delen zolang ze de juiste doeleinden bieden. Als u app-isolatie in deze omgeving wilt bieden, roept u de methode SetApplicationName aan op het configuratieobject en geeft u een unieke naam op voor elke app.
Gegevensbescherming en app-isolatie
Houd rekening met de volgende punten voor app-isolatie:
Wanneer meerdere apps naar dezelfde sleutelopslagplaats worden verwezen, is het de bedoeling dat de apps hetzelfde hoofdsleutelmateriaal delen. Data Protection wordt ontwikkeld met de veronderstelling dat alle apps die een sleutelring delen, toegang hebben tot alle items in die sleutelring. De unieke toepassings-id wordt gebruikt om toepassingsspecifieke sleutels te isoleren die zijn afgeleid van de verstrekte sleutelring. Er worden geen machtigingen op itemniveau verwacht, zoals machtigingen van Azure KeyVault die worden gebruikt om extra isolatie af te dwingen. Bij het uitvoeren van machtigingen op itemniveau worden toepassingsfouten gegenereerd. Als u niet wilt vertrouwen op de ingebouwde toepassingsisolatie, moeten afzonderlijke sleutelopslaglocaties worden gebruikt en niet worden gedeeld tussen toepassingen.
De toepassingsdiscriminatie (ApplicationDiscriminator) wordt gebruikt om verschillende apps toe te staan hetzelfde hoofdsleutelmateriaal te delen, maar om hun cryptografische nettoladingen van elkaar te onderscheiden. Om ervoor te zorgen dat de apps de cryptografische nettoladingen van elkaar kunnen lezen, moeten ze dezelfde toepassingsdiscriminator hebben, die kan worden ingesteld door aan te roepen
SetApplicationName.Als een app is gecompromitteerd (bijvoorbeeld door een RCE-aanval), moet alle hoofdsleutelmateriaal dat toegankelijk is voor die app, ook worden beschouwd als gecompromitteerd, ongeacht de beveiligings-at-rest-status. Dit impliceert dat als twee apps naar dezelfde opslagplaats worden verwezen, zelfs als ze verschillende app-discriminators gebruiken, een inbreuk van een app functioneel gelijk is aan een inbreuk van beide.
Deze clausule, die "functioneel gelijkwaardig is aan een compromis van beide", geldt zelfs als de twee apps verschillende mechanismen gebruiken voor sleutelbeveiliging terwijl ze in rust zijn. Dit is doorgaans geen verwachte configuratie. Het bescherming-in-rust-mechanisme is bedoeld om bescherming te bieden in het geval een cyberaanvaller leestoegang krijgt tot de opslagplaats. Een cyberaanval die schrijftoegang krijgt tot de opslagplaats (misschien omdat ze de machtiging voor het uitvoeren van code binnen een app hebben bereikt) kan schadelijke sleutels in de opslag invoegen. Het data protection-systeem biedt opzettelijk geen bescherming tegen een cyberaanval die schrijftoegang krijgt tot de sleutelopslagplaats.
Als apps echt van elkaar moeten worden geïsoleerd, moeten ze verschillende sleutelopslagplaatsen gebruiken. Dit valt natuurlijk buiten de definitie van 'geïsoleerd'. Apps worden niet geïsoleerd als ze allemaal lees- en schrijftoegang hebben tot elkaars gegevensarchieven.
Algoritmen wijzigen met UseCryptographicAlgorithms
Met de Data Protection-stack kunt u het standaardalgoritmen wijzigen dat wordt gebruikt door nieuw gegenereerde sleutels. De eenvoudigste manier om dit te doen, is door vanuit de callback van de configuratie aan te roepen UseCryptographicAlgorithms :
services.AddDataProtection()
.UseCryptographicAlgorithms(
new AuthenticatedEncryptorConfiguration()
{
EncryptionAlgorithm = EncryptionAlgorithm.AES_256_CBC,
ValidationAlgorithm = ValidationAlgorithm.HMACSHA256
});
Het standaard versleutelingsalgoritme is AES-256-CBC en het standaard validatie-algoritme is HMACSHA256. Het standaardbeleid kan worden ingesteld door een systeembeheerder via een machine-brede beleid, maar een expliciete oproep naar UseCryptographicAlgorithms overschrijft het standaardbeleid.
Met aanroepen UseCryptographicAlgorithms kunt u het gewenste algoritme opgeven vanuit een vooraf gedefinieerde ingebouwde lijst. U hoeft zich geen zorgen te maken over de implementatie van het algoritme. In het bovenstaande scenario probeert het data protection-systeem de CNG-implementatie van AES te gebruiken als deze wordt uitgevoerd in Windows. Anders valt deze terug op de beheerde System.Security.Cryptography.Aes klasse.
U kunt handmatig een implementatie opgeven via een aanroep naar UseCustomCryptographicAlgorithms.
Tip
Het wijzigen van algoritmen heeft geen invloed op bestaande sleutels in de sleutelring. Dit is alleen van invloed op nieuw gegenereerde sleutels.
Aangepaste beheerde algoritmen opgeven
Als u aangepaste beheerde algoritmen wilt opgeven, maakt u een ManagedAuthenticatedEncryptorConfiguration exemplaar dat verwijst naar de implementatietypen:
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)
});
Over het algemeen moeten de *Type-eigenschappen wijzen naar concrete, instantieerbare (via een openbare parameterloze ctor) implementaties van SymmetricAlgorithm en KeyedHashAlgorithm, hoewel het systeem sommige waarden zoals typeof(Aes) als speciale gevallen behandelt voor het gemak.
Note
De SymmetricAlgorithm moet een sleutellengte hebben van ≥ 128 bits en een blokgrootte van ≥ 64 bits en moet ondersteuning bieden voor CBC-modusversleuteling met PKCS #7 opvulling. De KeyedHashAlgorithm moet een digestgrootte hebben van >= 128 bits en moet sleutels van lengte ondersteunen die gelijk zijn aan de lengte van het hash-algoritme. De KeyedHashAlgorithm is niet strikt vereist om HMAC te zijn.
Aangepaste Windows CNG-algoritmen opgeven
Als u een aangepast Windows CNG-algoritme wilt opgeven met CBC-modusversleuteling met HMAC-validatie, maakt u een CngCbcAuthenticatedEncryptorConfiguration exemplaar met de algoritmegegevens:
services.AddDataProtection()
.UseCustomCryptographicAlgorithms(
new CngCbcAuthenticatedEncryptorConfiguration()
{
// Passed to BCryptOpenAlgorithmProvider
EncryptionAlgorithm = "AES",
EncryptionAlgorithmProvider = null,
// Specified in bits
EncryptionAlgorithmKeySize = 256,
// Passed to BCryptOpenAlgorithmProvider
HashAlgorithm = "SHA256",
HashAlgorithmProvider = null
});
Note
Het symmetrische blokcoderingsalgoritmen moeten een sleutellengte hebben van >= 128 bits, een blokgrootte van >= 64 bits en moet ondersteuning bieden voor CBC-modusversleuteling met PKCS #7-opvulling. Het hash-algoritme moet een digestgrootte van >= 128 bits hebben en moet ondersteuning bieden voor het openen met de vlag BCRYPT_ALG_HANDLE_HMAC_FLAG. De eigenschappen van *Provider kunnen worden ingesteld op null om de standaardprovider voor het opgegeven algoritme te gebruiken. Zie de documentatie van BCryptOpenAlgorithmProvider voor meer informatie.
Als u een aangepast Windows CNG-algoritme wilt opgeven met Galois/Counter Mode-versleuteling met validatie, maakt u een CngGcmAuthenticatedEncryptorConfiguration exemplaar dat de algoritmische informatie bevat:
services.AddDataProtection()
.UseCustomCryptographicAlgorithms(
new CngGcmAuthenticatedEncryptorConfiguration()
{
// Passed to BCryptOpenAlgorithmProvider
EncryptionAlgorithm = "AES",
EncryptionAlgorithmProvider = null,
// Specified in bits
EncryptionAlgorithmKeySize = 256
});
Note
Het symmetrische blokcoderingsalgoritmen moeten een sleutellengte hebben van >= 128 bits, een blokgrootte van precies 128 bits en moet GCM-versleuteling ondersteunen. U kunt de EncryptionAlgorithmProvider eigenschap instellen op null om de standaardprovider voor het opgegeven algoritme te gebruiken. Zie de documentatie van BCryptOpenAlgorithmProvider voor meer informatie.
Andere aangepaste algoritmen opgeven
Hoewel het niet beschikbaar is als een eersteklas API, is het systeem voor gegevensbeveiliging uitbreidbaar genoeg om vrijwel elk type algoritme op te geven. Het is bijvoorbeeld mogelijk om alle sleutels in een HSM (Hardware Security Module) te bewaren en een aangepaste implementatie van de kernversleutelings- en ontsleutelingsroutines te bieden. Zie voor meer informatie IAuthenticatedEncryptor in de uitbreidbaarheid van de kerncryptografie.
Persistente sleutels bij het hosten in een Docker-container
Bij het hosten in een Docker-container moeten sleutels worden onderhouden in:
- Een map die een Docker-volume is dat langer duurt dan de levensduur van de container, zoals een gedeeld volume of een door een host gekoppeld volume.
- Een externe provider, zoals Azure Blob Storage (weergegeven in de sectie Sleutels beveiligen met Azure Key Vault (
ProtectKeysWithAzureKeyVault) of Redis.
Persistente sleutels in Redis
Alleen Redis-versies die Redis-gegevenspersistentie ondersteunen, moeten worden gebruikt om sleutels op te slaan. Azure Blob Storage is permanent en kan worden gebruikt voor het opslaan van sleutels. Zie dit GitHub-probleem voor meer informatie.
Logging
Schakel het Information of lagere logboekregistratieniveau in om problemen te diagnosticeren. Met het volgende appsettings.json bestand wordt logboekregistratie van gegevens van de Data Protection-API ingeschakeld:
{
"Logging": {
"LogLevel": {
"Microsoft.AspNetCore.DataProtection": "Information"
}
}
}
Zie Logboekregistratie in .NET en ASP.NET Core voor meer informatie over logboekregistratie.