ASP.NET Core Veri Korumasını Yapılandırma

Data Protection sistemi başlatıldığında, işletim ortamına göre varsayılan ayarları uygular. Bu ayarlar tek bir makinede çalışan uygulamalar için uygundur. Ancak, bir geliştiricinin varsayılan ayarları değiştirmek isteyebileceği durumlar vardır:

• Uygulama birden çok makineye yayılır.
• Uyumluluk gereklilikleri nedeniyle.

Bu senaryolar için Veri Koruma sistemi zengin bir yapılandırma API'sini sunar.

Uyarı

Yapılandırma dosyalarına benzer şekilde, veri koruma anahtar halkası da uygun izinler kullanılarak korunmalıdır. Bekleyen anahtarları şifrelemeyi seçebilirsiniz, ancak bu, siber saldırganların yeni anahtarlar oluşturmasını engellemez. Sonuç olarak uygulamanızın güvenliği etkilenir. Data Protection ile yapılandırılan depolama konumunun erişimi, yapılandırma dosyalarını koruma yönteminize benzer şekilde uygulamanın kendisiyle sınırlı olmalıdır. Örneğin, anahtar halkanızı diskte depolamayı seçerseniz dosya sistemi izinlerini kullanın. Yalnızca web uygulamanızın çalıştığı kimliğin bu dizine okuma, yazma ve oluşturma erişimi olduğundan emin olun. Azure Blob Depolama kullanıyorsanız, yalnızca web uygulamasının blob deposunda yeni girdileri okuma, yazma veya oluşturma gibi özellikleri olmalıdır.

uzantı yöntemi AddDataProtection bir IDataProtectionBuilderdöndürür. IDataProtectionBuilder , Veri Koruma seçeneklerini yapılandırmak için birlikte zincirleyebileceğiniz uzantı yöntemlerini kullanıma sunar.

Not

Bu makale, docker kapsayıcısı içinde çalışan bir uygulama için yazılmıştır. Docker kapsayıcısında uygulama her zaman aynı yola ve dolayısıyla aynı uygulama ayırıcıya sahiptir. Birden çok ortamda (örneğin yerel ve dağıtılmış) çalışması gereken uygulamaların ortam için varsayılan uygulama ayırıcısını ayarlaması gerekir. Bir uygulamayı birden çok ortamda çalıştırmak bu makalenin kapsamının dışındadır.

Bu makalede kullanılan Data Protection uzantıları için aşağıdaki NuGet paketleri gereklidir:

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

Azure Key Vault ile anahtarları koruma (ProtectKeysWithAzureKeyVault)

Geliştirici kimlik bilgilerini kullanarak Azure Key Vault ile yerel olarak etkileşime geçmek için Visual Studio'da depolama hesabınızda oturum açın veya Azure CLI ile oturum açın. Azure CLI'yı henüz yüklemediyseniz bkz. Azure CLI'yi yükleme. Visual Studio'da Geliştirici PowerShell panelinde veya Visual Studio'yu kullanmadığınızda bir komut kabuğundan aşağıdaki komutu yürütebilirsiniz:

az login

Daha fazla bilgi için bkz. Geliştirici araçlarını kullanarak Azure'da oturum açma.

Entra veya Azure portalında anahtar kasasını oluştururken:

• Anahtar kasasını Azure rol tabanlı erişim denetimini (RABC) kullanacak şekilde yapılandırın. Yerel geliştirme ve test de dahil olmak üzere bir Azure Sanal Ağı üzerinde çalışmıyorsanız , Ağ adımında genel erişimin etkinleştirildiğini (işaretli) onaylayın. Genel erişimin etkinleştirilmesi yalnızca anahtar kasası uç noktasını gözler önüne serer. Kimliği doğrulanmış hesaplar hala erişim için gereklidir.

• Identity rolüyle bir Azure Yönetilen Identity Kaynağı oluşturun (veya kullanmayı planladığınız mevcut Yönetilen Kaynağına bir rol ekleyin). Yönetilen Identity'yi dağıtımı barındıran Azure App Service'e atayın: Ayarlar>Identity>Kullanıcı Tarafından Atanan>Ekle.

  Not

  Azure CLI veya Visual Studio'nun Azure Hizmet Kimlik Doğrulaması'nı kullanarak blob erişimi için yetkili bir kullanıcıyla uygulamayı yerel olarak çalıştırmayı planlıyorsanız, Key Vault Şifreleme Kullanıcısı rolüyle geliştirici Azure kullanıcı hesabınızı Erişim Denetimi'ne (IAM) ekleyin. Azure CLI'yi Visual Studio aracılığıyla kullanmak istiyorsanız, Geliştirici PowerShell panelinden az login komutunu yürüterek kiracı ile kimlik doğrulaması yapmak için istemleri takip edin.

• Anahtar şifrelemesi etkin olduğunda, anahtar dosyasındaki anahtarlar "This key is encrypted with Azure Key Vault." açıklamasını içerir. Uygulamayı başlattıktan sonra anahtar satırının sonundaki bağlam menüsünden Görüntüle/düzenle komutunu seçerek anahtar kasası güvenliği uygulanmış bir anahtarın mevcut olduğunu onaylayın.

• İsteğe bağlı olarak, süresi dolmuş veya yenilenmiş anahtar kasası anahtarlarına dayanan veri koruma anahtarlarıyla yüklerin şifresini çözme konusunda endişelenmeden, otomatik anahtar kasası anahtar yenilemeyi etkinleştirebilirsiniz. Oluşturulan her veri koruma anahtarı, şifrelemek için kullanılan anahtar kasası anahtarına bir başvuru içerir. Süresi dolan anahtar kasası anahtarlarını koruduğundan emin olun, bunları anahtar kasasında silmeyin. Ayrıca, uygulamanın anahtar kasası yapılandırmasında sürümsüz anahtar tanımlayıcısı kullanın; burada tanımlayıcının sonuna anahtar GUID'i yerleştirilmez (örnek: https://contoso.vault.azure.net/keys/data-protection). Her iki anahtar için de benzer bir döndürme süresi kullanarak, anahtar kasası anahtarının, veri koruma anahtarı döndürme sırasında yeni bir anahtar olarak kullanılmasını sağlamak adına anahtar kasası anahtarını veri koruma anahtarından daha sık döndürün.

Azure Key Vault IXmlEncryptor ile anahtarların korunması, anahtar halkası depolama konumu dahil olmak üzere otomatik veri koruma ayarlarını devre dışı bırakır. Azure Blob Depolama sağlayıcısını anahtarları blob depolamada depolamak üzere yapılandırmak için ASP.NET Core'daki Anahtar depolama sağlayıcıları'ndaki yönergeleri izleyin ve uygulamadaki PersistKeysToAzureBlobStorage aşırı yüklemelerden birini çağırın. Aşağıdaki örnek, rol tabanlı erişim denetimi (RBAC) için Azure Yönetilen'e TokenCredential bağlı olarak blob URI'sini ve belirteç kimlik bilgileriniIdentity () kabul eden aşırı yüklemeyi kullanır.

Azure Key Vault sağlayıcısını yapılandırmak için ProtectKeysWithAzureKeyVault aşırı yüklemelerden birini çağırın. Aşağıdaki örnek, anahtar tanımlayıcı ve belirteç kimlik bilgilerini (TokenCredential) kabul eden ve üretimde RBAC için Yönetilen Identity (ManagedIdentityCredential) veya geliştirme ve test sırasında bir DefaultAzureCredential kullanan aşırı yüklemeyi kullanır. Diğer aşırı yüklemeler, anahtar kasası istemcisini veya istemci gizli dizisine sahip bir uygulama istemci kimliğini kabul eder. Daha fazla bilgi için, bkz. ASP.NET Core'da anahtar depolama sağlayıcıları.

Azure SDK'sının API'si ve kimlik doğrulaması hakkında daha fazla bilgi için bkz. Azure kitaplığını kullanarak Azure hizmetlerinde .NET uygulamalarının kimliğini doğrulama ve Azure Identityrol tabanlı erişim denetimiyle Key Vault anahtarlarına, sertifikalarına ve gizli dizilerine erişim sağlama. Günlük tutma kılavuzu için bkz: .NET için Azure SDK ile günlük tutma: İstemci kaydı olmadan günlük tutma. Bağımlılık ekleme kullanan uygulamalar için, bir uygulama AddAzureClientsCore'yi çağırabilir ve true için enableLogForwarding geçirerek günlüğe kaydetme altyapısını oluşturup bağlayabilir.

Program Hizmetlerin kaydedildiği dosyada:

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 Yönetilen Identity İstemci Kimliği (GUID).

{TENANT ID}: Kiracı Kimliği.

{APPLICATION NAME}: SetApplicationName bu uygulamanın benzersiz adını veri koruma sistemi içinde ayarlar. Değer, uygulamanın dağıtımları arasında eşleşmelidir.

{BLOB URI}: Anahtar dosyasının tam URI'si. URI, anahtar dosyasını oluşturduğunuzda Azure Depolama tarafından oluşturulur. SAS kullanmayın.

{KEY IDENTIFIER}: Anahtar şifrelemesi için kullanılan Azure Key Vault anahtar tanımlayıcısı. Bir erişim ilkesi, uygulamanın Get, Unwrap Key ve Wrap Key izinleriyle anahtar kasasına erişmesini sağlar. Anahtarın sürümü, oluşturulduktan sonra Entra veya Azure portalındaki anahtardan alınır. Anahtar kasası anahtarının otomatik döndürmesini etkinleştirirseniz, uygulamanın anahtar kasası yapılandırmasında, tanımlayıcının sonuna anahtar GUID'sinin yerleştirilmediği sürümsüz bir anahtar tanımlayıcısı kullandığınızdan emin olun (örnek: https://contoso.vault.azure.net/keys/data-protection).

Bir uygulamanın Azure Key Vault ile iletişim kurması ve kendisini yetkilendirmesi için NuGetAzure.Identity paketine uygulama tarafından başvurulmalıdır.

Not

.NET uygulamalarına paket ekleme yönergeleri için Paket tüketimi iş akışı (NuGet belgeleri) sayfasındaki Paketleri yükleme ve yönetme altındaki makalelere bakın. NuGet.org'da doğru paket sürümlerini onaylayın.

Not

Üretim dışı ortamlarda, önceki örnek Azure barındırma ortamlarında kullanılan kimlik bilgilerini yerel geliştirmede kullanılan kimlik bilgileriyle birleştirerek Azure'a dağıtım yapan uygulamalar geliştirirken kimlik doğrulamasını basitleştirmek için kullanır DefaultAzureCredential . Daha fazla bilgi için bkz. Sistem tarafından atanan yönetilen kimliği kullanarak Azure kaynaklarına Azure tarafından barındırılan .NET uygulamalarının kimliğini doğrulama.

Uygulama eski Azure paketlerini (Microsoft.AspNetCore.DataProtection.AzureStorage ve Microsoft.AspNetCore.DataProtection.AzureKeyVault) kullanıyorsa, bu başvuruları kaldırmanızı ve Azure.Extensions.AspNetCore.DataProtection.Blobs ve Azure.Extensions.AspNetCore.DataProtection.Keys paketlerine yükseltmenizi öneririz. Daha yeni paketler önemli güvenlik ve kararlılık sorunlarını giderir.

Alternatif paylaşılan erişim imzası (SAS) yaklaşımı: Azure Blob Depolama'da anahtar bloba erişim için Yönetilen Identity kullanmaya alternatif olarak, SAS belirtecine sahip bir blob URI'sini kabul eden aşırı yüklemeyi çağırabilirsiniz PersistKeysToAzureBlobStorage . Aşağıdaki örnek, önceki örnekte görüldüğü gibi , ManagedIdentityCredentialiçin bir DefaultAzureCredential (üretim) veya TokenCredential (geliştirme ve test) kullanmaya devam eder:

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

{APPLICATION NAME}: SetApplicationName bu uygulamanın benzersiz adını veri koruma sistemi içinde ayarlar. Değer, uygulamanın dağıtımları arasında eşleşmelidir.

{BLOB URI WITH SAS}: Anahtar dosyasının SAS belirteciyle bir sorgu dizesi parametresi olarak depolanması gereken tam URI. URI, yüklenen anahtar dosyası için bir SAS istediğinizde Azure Depolama tarafından oluşturulur.

{KEY IDENTIFIER}: Anahtar şifrelemesi için kullanılan Azure Key Vault anahtar tanımlayıcısı. Bir erişim ilkesi, uygulamanın Get, Unwrap Key ve Wrap Key izinleriyle anahtar kasasına erişmesini sağlar. Anahtarın sürümü, oluşturulduktan sonra Entra veya Azure portalındaki anahtardan alınır. Anahtar kasası anahtarının otomatik döndürmesini etkinleştirirseniz, uygulamanın anahtar kasası yapılandırmasında, tanımlayıcının sonuna anahtar GUID'sinin yerleştirilmediği sürümsüz bir anahtar tanımlayıcısı kullandığınızdan emin olun (örnek: https://contoso.vault.azure.net/keys/data-protection).

Anahtarları dosya sisteminde kalıcı hale getirmek (PersistKeysToFileSystem)

Anahtarları %LOCALAPPDATA% varsayılan konumu yerine bir UNC paylaşımında depolamak için, sistemi PersistKeysToFileSystem ile yapılandırın.

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

Uyarı

Anahtar kalıcılığı konumunu değiştirirseniz, DPAPI'nin uygun bir şifreleme mekanizması olup olmadığını bilmediğinden sistem artık bekleyen anahtarları otomatik olarak şifrelemez.

Veritabanında anahtarları kalıcı hale ekleme (PersistKeysToDbContext)

EntityFramework kullanarak bir veritabanında anahtarları depolamak için sistemi Microsoft.AspNetCore.DataProtection.EntityFrameworkCore paketiyle yapılandırın:

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

Yukarıdaki kod anahtarları yapılandırılan veritabanında depolar. Kullanılan veritabanı bağlamı IDataProtectionKeyContext'i uygulamalıdır. IDataProtectionKeyContext özelliği ekrana getirir DataProtectionKeys

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

Bu özellik anahtarların depolandığı tabloyu temsil eder. Tabloyu elle veya Geçişler ile DbContext oluşturun. Daha fazla bilgi için bkz. DataProtectionKey.

Anahtar yapılandırma API'lerini koruma (ProtectKeysWith\*)

Yapılandırma API'lerinden herhangi birini ProtectKeysWith\* kullanarak sistemi dinlenme halinde olan anahtarları koruyacak şekilde yapılandırabilirsiniz. Anahtarları bir UNC paylaşımında depolayan ve bekleyen bu anahtarları belirli bir X.509 sertifikasıyla şifreleyen aşağıdaki örneği düşünün.

Dosyadan X509Certificate2 sağlamak için ProtectKeysWithCertificate çağrısı yaparak bir X509CertificateLoader.LoadCertificateFromFile sağlayabilirsiniz:

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

Aşağıdaki kod örneği, parmak izi kullanarak sertifika yükleme işlemini gösterir:

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

Yerleşik anahtar şifreleme mekanizmalarıyla ilgili örnekler ve tartışmalar için bkz. ASP.NET Core kullanarak Windows ve Azure'da anahtarların beklemede şifrelenmesi.

Herhangi bir sertifikayla anahtarların korumasını kaldırma (UnprotectKeysWithAnyCertificate)

Sertifikaları bir dizi X509Certificate2 sertifika ile UnprotectKeysWithAnyCertificate kullanarak döndürebilir ve beklemede olan anahtarların şifresini çözebilirsiniz.

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

Varsayılan anahtar ömrünü ayarlama (SetDefaultKeyLifetime)

Sistemi varsayılan 90 gün yerine 14 günlük bir anahtar ömrü kullanacak şekilde yapılandırmak için kullanın SetDefaultKeyLifetime:

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

Uygulama adını ayarlama (SetApplicationName)

Varsayılan olarak, Data Protection sistemi aynı fiziksel anahtar deposunu paylaşsalar bile uygulamaları içerik kök yollarına göre birbirinden ayırır. Bu yalıtım, uygulamaların birbirlerinin korumalı yüklerini anlamasını engeller.

Korumalı yükleri uygulamalar arasında paylaşmak için:

• Her uygulamada aynı değerle yapılandırın SetApplicationName .
• Uygulamalar genelinde Data Protection API yığınının aynı sürümünü kullanın. Uygulamaların proje dosyalarında aşağıdakilerden birini gerçekleştirin:
  • Microsoft.AspNetCore.App meta paketi aracılığıyla aynı paylaşılan çerçeve sürümüne başvurun.
  • Aynı Data Protection paketi sürümüne başvurun.

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

SetApplicationName, DataProtectionOptions.ApplicationDiscriminator'yi dahili olarak ayarlar. Sorun giderme amacıyla, çerçeve tarafından ayrıştırıcıya atanan değer, WebApplicationProgram.cs oluşturulduktan sonra yerleştirilen aşağıdaki kodla kaydedilebilir.

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

Ayırıcının nasıl kullanıldığı hakkında daha fazla bilgi için bu makalenin devamında yer alan aşağıdaki bölümlere bakın:

• Uygulama başına yalıtım
• Veri Koruması ve uygulama yalıtımı

Uyarı

.NET 6'da içerik WebApplicationBuilder kök yolunu ile DirectorySeparatorCharbitmesi için normalleştirir. Örneğin, Windows'ta içerik kök yolu ile linux \üzerinde biter/. Diğer konaklar yolu normalleştirmez. HostBuilder veya WebHostBuilder'den geçiş yapan çoğu uygulama, sonlandırıcı DirectorySeparatorChar'ye sahip olmayacakları için aynı uygulama adını paylaşmaz. Bu sorunu geçici olarak çözmek için dizin ayırıcı karakterini kaldırın ve uygulama adını aşağıdaki kodda gösterildiği gibi el ile ayarlayın:

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

Otomatik anahtar oluşturmayı devre dışı bırakma (DisableAutomaticKeyGeneration)

Bir uygulamanın süre sonu yaklaştıkça anahtarları otomatik olarak teslim etmelerini (yeni anahtarlar oluşturma) istemediğiniz bir senaryonuz olabilir. Bu senaryoya örnek olarak birincil/ikincil ilişkide ayarlanmış uygulamalar gösterilebilir. Burada anahtar yönetimi endişelerinden yalnızca birincil uygulama sorumludur ve ikincil uygulamalar yalnızca anahtar halkasının salt okunur bir görünümüne sahiptir. İkincil uygulamalar, ile sistemi DisableAutomaticKeyGenerationyapılandırarak anahtar halkasını salt okunur olarak değerlendirecek şekilde yapılandırılabilir:

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

Uygulama başına yalıtım

Data Protection sistemi bir ASP.NET Core konağı tarafından sağlandığında, bu uygulamalar aynı çalışan işlem hesabı altında çalışıyor olsa ve aynı ana anahtarlama malzemesini kullanıyor olsalar bile uygulamaları otomatik olarak birbirinden ayırır. Bu, System.Web öğesinden IsolateApps değiştiricisine <machineKey> benzer.

Yalıtım mekanizması, yerel makinedeki her uygulamayı benzersiz bir kiracı olarak dikkate alarak çalışır, bu nedenle IDataProtector belirli bir uygulamanın kökü otomatik olarak uygulama kimliğini ayrıştırıcı (ApplicationDiscriminator olarak) içerir. Uygulamanın benzersiz kimliği, uygulamanın fiziksel yoludur:

• IIS'de barındırılan uygulamalar için benzersiz kimlik, uygulamanın IIS fiziksel yoludur. Bir uygulama bir web grubu ortamında dağıtılırsa, IIS ortamlarının web grubundaki tüm makinelerde benzer şekilde yapılandırıldığı varsayıldığında bu değer kararlıdır.
• Kendi sunucusunda barındırılan uygulamalar için, benzersiz kimlik, disk üzerindeki uygulamanın fiziksel yoludur.

Benzersiz tanımlayıcı, hem tek tek uygulama hem de makinenin kendisi olmak üzere sıfırlamalara dayanacak şekilde tasarlanmıştır.

Bu yalıtım mekanizması, uygulamaların kötü amaçlı olmadığını varsayar. Kötü amaçlı bir uygulama her zaman aynı çalışan işlem hesabı altında çalışan diğer tüm uygulamaları etkileyebilir. Uygulamaların karşılıklı olarak güvenilmeyen paylaşılan bir barındırma ortamında, barındırma sağlayıcısı uygulamaların temel alınan anahtar depolarını ayırmak da dahil olmak üzere uygulamalar arasında işletim sistemi düzeyinde yalıtım sağlamak için adımlar atmalıdır.

Data Protection sistemi bir ASP.NET Core konağı tarafından sağlanmamışsa (örneğin, onu DataProtectionProvider somut tür aracılığıyla başlatırsanız) uygulama yalıtımı varsayılan olarak devre dışı bırakılır. Uygulama yalıtımı devre dışı bırakıldığında, aynı anahtarlama malzemesi tarafından yedeklenen tüm uygulamalar, uygun amaçları sağladığı sürece yükleri paylaşabilir. Bu ortamda uygulama yalıtımı sağlamak için yapılandırma nesnesinde yöntemini çağırın SetApplicationName ve her uygulama için benzersiz bir ad sağlayın.

Veri Koruması ve uygulama yalıtımı

Uygulama yalıtımı için aşağıdaki noktaları göz önünde bulundurun:

• Birden çok uygulama aynı anahtar deposuna işaret edildiğinde, uygulamaların aynı ana anahtar malzemesini paylaşması amaçlanır. Veri Koruması, anahtar kademesini paylaşan tüm uygulamaların bu anahtar kademedeki tüm öğelere erişebileceği varsayımıyla geliştirilmiştir. Uygulama benzersiz tanımlayıcısı, anahtar halkası tarafından sağlanan anahtarlardan türetilen uygulamaya özgü anahtarları yalıtmak için kullanılır. Ek yalıtımı zorlamak için Azure KeyVault tarafından sağlananlar gibi öğe düzeyi izinlerinin kullanılmasını beklemez. Öğe düzeyi izinlerinin denenilmesi uygulama hataları oluşturur. Yerleşik uygulama yalıtımına güvenmek istemiyorsanız, uygulamalar arasında ayrı anahtar deposu konumları kullanılmalı ve paylaşılmamalıdır.

• Uygulama ayırıcısı (ApplicationDiscriminator), farklı uygulamaların aynı ana anahtar malzemesini paylaşmasına izin vermek, ancak şifreleme yüklerini birbirinden ayrı tutmak için kullanılır. Uygulamaların birbirlerinin şifreleme yüklerini okuyabilmesi için, çağrılarak SetApplicationNameayarlanabilen aynı uygulama ayırıcısına sahip olmaları gerekir.

• Bir uygulamanın güvenliği aşılırsa (örneğin, bir RCE saldırısıyla), bu uygulamanın erişebildiği tüm anahtar malzemesinin de, dinlenme halindeki koruma durumundan bağımsız olarak gizliliği ihlal edilmiş olarak kabul edilmesi gerekir. İki uygulama aynı depoya işaret ettiğinde, farklı uygulama ayırıcıları kullansalar bile, birinin güvenliğinin zayıflatılması, işlevsel olarak her ikisinin de güvenliğinde bir zayıflamaya eşdeğerdir.

  Bu "işlevsel olarak her iki tarafın da güvenliğinin ihlaliyle eşdeğerdir" yan tümcesi, iki uygulama hareketsiz durumdaki anahtar koruması için farklı mekanizmalar kullansa bile geçerlidir. Bu genellikle beklenen bir yapılandırma değildir. Bekleme durumundaki koruma mekanizması, bir siber saldırganın depoya okuma erişimi kazanması durumunda koruma sağlamayı amaçlar. Depoya yazma erişimi kazanan bir siber saldırı uzmanı (bir uygulama içinde kod yürütme izni almış olabilir) depolama alanına kötü amaçlı anahtarlar ekleyebilir. Veri Koruma sistemi, temel depoya yazma erişimi kazanan bir siber saldırıda kasıtlı olarak koruma sağlamaz.

• Uygulamaların birbirinden gerçekten yalıtılmış kalması gerekiyorsa, farklı anahtar depoları kullanmalıdır. Bu doğal olarak "yalıtılmış" tanımından çıkar. Hepsinin birbirlerinin veri depolarına Okuma ve Yazma erişimi varsa uygulamalar yalıtılmaz .

Algoritmaları UseCryptographicAlgorithms ile değiştirme

Veri Koruma yığını, yeni oluşturulan anahtarlar tarafından kullanılan varsayılan algoritmayı değiştirmenize olanak tanır. Bunu yapmanın en basit yolu, yapılandırma geri çağrısından çağırmaktır UseCryptographicAlgorithms :

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

Varsayılan EncryptionAlgorithm AES-256-CBC'dir ve varsayılan ValidationAlgorithm HMACSHA256. Varsayılan ilke, makine genelinde bir ilke aracılığıyla sistem yöneticisi tarafından ayarlanabilir, ancak açık bir çağrı UseCryptographicAlgorithms varsayılan ilkeyi geçersiz kılar.

Çağırma UseCryptographicAlgorithms , önceden tanımlanmış yerleşik bir listeden istenen algoritmayı belirtmenize olanak tanır. Algoritmanın uygulanması konusunda endişelenmeniz gerekmez. Yukarıdaki senaryoda, Veri Koruma sistemi Windows üzerinde çalışıyorsa AES'nin CNG uygulamasını kullanmayı dener. Aksi takdirde System.Security.Cryptography.Aes yönetilen sınıfa geri döner.

Bir uygulamayı UseCustomCryptographicAlgorithms'e yapılan bir çağrı aracılığıyla el ile belirleyebilirsiniz.

İpucu

Algoritmaların değiştirilmesi, anahtar kademesindeki mevcut anahtarları etkilemez. Yalnızca yeni oluşturulan anahtarları etkiler.

Özel yönetilen algoritmaları belirtme

Özel yönetilen algoritmalar belirtmek için uygulama türlerine işaret eden bir ManagedAuthenticatedEncryptorConfiguration örnek oluşturun:

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

Genellikle *Tür özellikleri, SymmetricAlgorithm ve KeyedHashAlgorithm'in somut, örneklenebilir (genel parametresiz bir ctor ile) uygulamalarına işaret etmelidir, ancak sistem, kolaylık sağlamak için typeof(Aes) gibi bazı değerleri özel durum olarak ele alır.

Not

SymmetricAlgorithm'in anahtar uzunluğu ≥ 128 bit ve blok boyutu ≥ 64 bit olmalıdır ve PKCS #7 doldurma ile CBC modu şifrelemesini desteklemelidir. KeyedHashAlgorithm, >= 128 bitlik bir özet boyutuna sahip olmalı ve hash algoritmasının özet uzunluğuna eşit uzunluktaki anahtarları desteklemelidir. KeyedHashAlgorithm'in HMAC olması kesinlikle gerekli değildir.

Özel Windows CNG algoritmaları belirtme

HMAC doğrulaması ile CBC modu şifrelemesi kullanarak özel bir Windows CNG algoritması belirtmek için algoritma bilgilerini içeren bir CngCbcAuthenticatedEncryptorConfiguration örnek oluşturun:

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

Not

Simetrik blok şifreleme algoritmasının anahtar uzunluğu >= 128 bit, blok boyutu >= 64 bit olmalı ve PKCS #7 doldurma ile CBC modu şifrelemesini desteklemelidir. Karma algoritmasının >özet boyutu 128 bit veya daha büyük olmalıdır ve BCRYPT_ALG_HANDLE_HMAC_FLAG bayrağı kullanılarak açılması desteklenmelidir. *Sağlayıcı özellikleri, belirtilen algoritma için varsayılan sağlayıcıyı kullanmak üzere null olarak ayarlanabilir. Daha fazla bilgi için BCryptOpenAlgorithmProvider belgelerine bakın.

Doğrulama ile Galois/Sayaç Modu şifrelemesi kullanarak özel bir Windows CNG algoritması belirtmek için algoritma bilgilerini içeren bir CngGcmAuthenticatedEncryptorConfiguration örnek oluşturun:

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256
    });

Not

Simetrik blok şifreleme algoritmasının anahtar uzunluğu >= 128 bit, blok boyutu tam olarak 128 bit olmalıdır ve GCM şifrelemesini desteklemelidir. Belirtilen algoritma için EncryptionAlgorithmProvider varsayılan sağlayıcıyı kullanmak üzere özelliğini null olarak ayarlayabilirsiniz. Daha fazla bilgi için BCryptOpenAlgorithmProvider belgelerine bakın.

Diğer özel algoritmaları belirtme

Birinci sınıf API olarak sunulmasa da, Veri Koruma sistemi neredeyse her tür algoritmanın belirtilmesine izin verecek kadar genişletilebilir. Örneğin, donanım güvenlik modülünde (HSM) bulunan tüm anahtarları tutmak ve çekirdek şifreleme ve şifre çözme yordamlarının özel bir uygulamasını sağlamak mümkündür. Daha fazla bilgi için bkz IAuthenticatedEncryptor, Çekirdek şifreleme genişletilebilirliği.

Docker kapsayıcısında barındırırken anahtarları kalıcı hale getirme

Docker kapsayıcısında barındırılırken anahtarlar aşağıdakilerden herhangi biri içinde tutulmalıdır:

• Paylaşılan birim veya konağa bağlı birim gibi kapsayıcının ömrünü aşan bir Docker birimi olan klasör.
• Azure Blob Depolama (bölümde gösterilmiştirProtectKeysWithAzureKeyVault) veya Redis gibi bir dış sağlayıcı.

Redis ile kalıcı anahtarlar

Anahtarları depolamak için yalnızca Redis Veri Kalıcılığını destekleyen Redis sürümleri kullanılmalıdır. Azure Blob depolama kalıcıdır ve anahtarları depolamak için kullanılabilir. Daha fazla bilgi için bu GitHub konusuna bakın.

Ağaç kesimi

Sorunları tanılamak için Information veya daha düşük bir günlük düzeyini etkinleştirin. Aşağıdaki appsettings.json dosya, Veri Koruma API'sinin bilgi günlüğünü etkinleştirir:

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

Daha fazla bilgi için .NET Core ve ASP.NET Core'da Günlüğe Kaydetme'ye bakın.

Ek kaynaklar

• ASP.NET Core'de Veri Koruması için DI olmayan senaryolar
• ASP.NET Core'da Veri Koruma makine genelinde ilke desteği
• Web grubunda ASP.NET Core barındırma
• ASP.NET Core'daki önemli depolama sağlayıcıları