Az ASP.NET Core Data Protection konfigurálása

Az adatvédelmi rendszer inicializálásakor az üzemeltetési környezet alapján alkalmazza az alapértelmezett beállításokat . Ezek a beállítások megfelelőek az egyetlen gépen futó alkalmazásokhoz. Vannak azonban olyan esetek, amikor a fejlesztő módosítani szeretné az alapértelmezett beállításokat:

• Az alkalmazás több gépen is el van osztva.
• Megfelelőségi okokból.

Ezekben a forgatókönyvekben az Adatvédelmi rendszer gazdag konfigurációs API-t kínál.

Warning

A konfigurációs fájlokhoz hasonlóan az adatvédelmi kulcsgyűrűt megfelelő engedélyekkel kell védeni. Dönthet úgy, hogy inaktív kulcsokat titkosít, de ez nem akadályozza meg, hogy a kiberbűnözők új kulcsokat hozzanak létre. Következésképpen az alkalmazás biztonsága is érintett. Az Adatvédelemmel konfigurált tárolási helynek magának az alkalmazásnak kell korlátozott hozzáféréssel rendelkeznie, hasonlóan a konfigurációs fájlok védelméhez. Ha például úgy dönt, hogy lemezen tárolja a kulcsgyűrűt, használja a fájlrendszer engedélyeit. Győződjön meg arról, hogy csak a webalkalmazás futtatásához használt identitás rendelkezik olvasási, írási és létrehozási hozzáféréssel az adott könyvtárhoz. Ha Az Azure Blob Storage-t használja, csak a webalkalmazásnak kell tudnia új bejegyzéseket olvasni, írni vagy új bejegyzéseket létrehozni a blobtárolóban stb.

A bővítménymetódus AddDataProtection egy IDataProtectionBuilder-t ad vissza. IDataProtectionBuilder olyan bővítménymetóciókat tesz elérhetővé, amelyek összefűzhetők az adatvédelmi beállítások konfigurálásához.

Note

Ez a cikk egy docker-tárolón belül futó alkalmazáshoz készült. Egy Docker konténerben az alkalmazás mindig ugyanazzal az elérési útvonallal rendelkezik, és ezért ugyanaz az alkalmazás-diszkriminátor. Azoknak az alkalmazásoknak, amelyeknek több környezetben (például helyi és üzembe helyezett) kell futniuk, meg kell adniuk a környezet alapértelmezett alkalmazáskriminatív beállítását. Az alkalmazás több környezetben való futtatása meghaladja a jelen cikk hatókörét.

A cikkben használt adatvédelmi bővítményekhez a következő NuGet-csomagok szükségesek:

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

Kulcsok védelme az Azure Key Vaulttal (ProtectKeysWithAzureKeyVault)

Ha az Azure Key Vaultot helyileg szeretné használni fejlesztői hitelesítő adatokkal, jelentkezzen be a tárfiókba a Visual Studióban, vagy jelentkezzen be az Azure CLI-vel. Ha még nem telepítette az Azure CLI-t, olvassa el az Azure CLI telepítése című témakört. A Következő parancsot a Visual Studio Fejlesztői PowerShell paneljén vagy egy parancshéjból hajthatja végre, ha nem használja a Visual Studiót:

az login

További információ: Bejelentkezés az Azure-ba fejlesztői eszközökkel.

Az Entra vagy az Azure Portalon a kulcstár létrehozásakor:

• Konfigurálja a kulcstartót az Azure szerepköralapú hozzáférés-vezérlés (RABC) használatára. Ha nem Azure-beli virtuális hálózaton működik, beleértve a helyi fejlesztést és tesztelést is, ellenőrizze, hogy engedélyezve van-e a hálózati lépés nyilvános hozzáférése (bejelölve). A nyilvános hozzáférés engedélyezése csak a Key Vault végpontot teszi elérhetővé. A hozzáféréshez továbbra is hitelesített fiókok szükségesek.

• Hozzon létre egy Azure Felügyelt Identity (vagy adjon hozzá egy szerepkört a használni kívánt Felügyelt Identity-hez) a Key Vault Kripto Felhasználó szerepkörrel. Rendelje hozzá a Felügyelt Identitást Identity az üzembe helyezést üzemeltető Azure App Service-hez: Beállítások>Identity>Felhasználó által hozzárendelt>Hozzáadás.

  Note

  Ha azt is tervezi, hogy helyileg futtat egy alkalmazást egy jogosult felhasználóval blobhozzáféréshez az Azure CLI vagy a Visual Studio Azure Service Authentication használatával, adja hozzá fejlesztői Azure-felhasználói fiókját a Hozzáférés-vezérlés (IAM) szolgáltatáshoz a Key Vault titkosítási felhasználói szerepkörével. Ha az Azure CLI-t a Visual Studióban szeretné használni, hajtsa végre a parancsot a az login Fejlesztői PowerShell panelen, és kövesse az utasításokat a bérlővel való hitelesítéshez.

• Ha a kulcstitkosítás aktív, a kulcsfájlban lévő kulcsok tartalmazzák a következő megjegyzést: "This key is encrypted with Azure Key Vault." Az alkalmazás elindítása után válassza a Nézet/szerkesztés parancsot a kulcssor végén található helyi menüből, és győződjön meg arról, hogy a kulcs megtalálható a key vault biztonsági alkalmazásával.

• Opcionálisan engedélyezheti a kulcstárbeli kulcsok automatikus forgatását anélkül, hogy aggódnia kellene a lejárt vagy elforgatott kulcstári kulcsokon alapuló adatvédelmi kulcsokkal történő visszafejtés miatt. Minden létrehozott adatvédelmi kulcs tartalmaz egy hivatkozást a titkosított kulcstartó kulcsára. Csak győződjön meg arról, hogy megtartja a lejárt kulcstartókulcsokat, ne törölje őket a kulcstartóban. Emellett használjon verzió nélküli kulcsazonosítót az alkalmazás kulcstartójának konfigurációjában, ahol nincs kulcs GUID-azonosítója az azonosító végén (például: https://contoso.vault.azure.net/keys/data-protection). Használjon hasonló rotációs időszakot mindkét kulcshoz, de a kulcstár kulcs gyakrabban forogjon, mint az adatvédelmi kulcs, hogy az adatvédelmi kulcs elforgatásakor új kulcstár kulcs legyen használatban.

Az Azure Key Vaulttal történő kulcsvédelem egy olyan megvalósítást IXmlEncryptor valósít meg, amely letiltja az automatikus adatvédelmi beállításokat, beleértve a kulcsgyűrű tárolási helyét is. Ha úgy szeretné konfigurálni az Azure Blob Storage-szolgáltatót, hogy a kulcsokat blobtárolóban tárolja, kövesse a ASP.NET Core kulcstároló-szolgáltatóinak útmutatását, és hívja meg az PersistKeysToAzureBlobStorage alkalmazás egyik túlterhelését. Az alábbi példa azt a túlterhelést használja, amely egy blob URI-t és token hitelesítő adatokat (TokenCredential) fogad, és amely az Azure által kezelt szerepköralapú hozzáférés-vezérlésre (RBAC) támaszkodik Identity.

Az Azure Key Vault-szolgáltató konfigurálásához hívja meg az ProtectKeysWithAzureKeyVault egyik túlterhelést. Az alábbi példa azt a túlterhelést használja, amely elfogadja a kulcsazonosítót és a token hitelesítő adatait (TokenCredential), az éles környezetben egy Felügyelt Identity RBAC-re támaszkodva (ManagedIdentityCredential), vagy a fejlesztés és tesztelés során a DefaultAzureCredential-ra. Más túlterhelések elfogadnak egy key vault-ügyfelet vagy egy ügyfélkóddal rendelkező alkalmazásügyfél-azonosítót. További információ: Kulcstároló-szolgáltatók a ASP.NET Core-ban.

Az Azure SDK API-jával és hitelesítésével kapcsolatos további információkért tekintse meg a .NET-alkalmazások Azure-szolgáltatásokba való hitelesítését az Azure-kódtár Identity használatával , és hozzáférést biztosít a Key Vault kulcsaihoz, tanúsítványaihoz és titkos kulcsaihoz az Azure szerepköralapú hozzáférés-vezérlésével. A naplózással kapcsolatos útmutatásért lásd : Naplózás az Azure SDK for .NET-hez: Naplózás ügyfélregisztráció nélkül. Azokat az alkalmazásokat, amelyek függőséginjektálást használnak, meghívhatják a AddAzureClientsCore-t, átadva true-t enableLogForwarding-nek, hogy létrehozzák és összekapcsolják a naplózási infrastruktúrát.

Kulcs azure portalon való létrehozásához tekintse meg a következő rövid útmutatót: Kulcs beállítása és lekérése az Azure Key Vaultból az Azure Portal használatával. Adja meg a kulcsnak legalább Get, Unwrap Key, és Wrap Key engedélyeket. Jegyezze fel az alkalmazás konfigurációjával használható kulcsazonosítót. Ha engedélyezni szeretné a kulcstartó kulcsának automatikus elforgatását, jegyezze fel a verzió nélküli kulcsazonosítót, ahol nincs kulcs GUID-azonosítója az azonosító végén (például: https://contoso.vault.azure.net/keys/data-protection).

Abban a fájlban, amelyben a Program szolgáltatások regisztrálva vannak:

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}: Az Azure-beli felügyelt Identity ügyfél azonosítója (GUID).

{TENANT ID}: Bérlőazonosító.

{APPLICATION NAME}: SetApplicationName beállítja az alkalmazás egyedi nevét az adatvédelmi rendszeren belül. Az értéknek meg kell egyeznie az alkalmazás üzembe helyezései között.

{BLOB URI}: A kulcsfájl teljes URI-ja. Az URI-t az Azure Storage hozza létre a kulcsfájl létrehozásakor. Ne használjon SAS-t.

{KEY IDENTIFIER}: Kulcstitkosításhoz használt Azure Key Vault-kulcsazonosító. A hozzáférési szabályzat lehetővé teszi, hogy az alkalmazás hozzáférjen a kulcstartóhoz Get, Unwrap Keyés Wrap Key engedélyekkel. A kulcs verzióját az Entra vagy az Azure Portal kulcsából szerzi be a rendszer a létrehozás után. Ha engedélyezi a kulcstartó kulcsának automatikus elforgatását, győződjön meg arról, hogy verzió nélküli kulcsazonosítót használ az alkalmazás kulcstartójának konfigurációjában, ahol a kulcs guid azonosítója nem található az azonosító végén (például: https://contoso.vault.azure.net/keys/data-protection).

Ahhoz, hogy egy alkalmazás kommunikáljon és engedélyezze magát az Azure Key Vaulttal, az alkalmazásnak hivatkoznia kell a Azure.Identity NuGet-csomagra .

Note

A csomagok .NET-alkalmazásokhoz való hozzáadásáról a Csomagok telepítése és kezelésea csomaghasználati munkafolyamatban (NuGet-dokumentáció) című cikkben talál útmutatást. Ellenőrizze a megfelelő csomagverziókat a NuGet.org.

Note

Nem éles környezetekben az előző példa a DefaultAzureCredential segítségével leegyszerűsíti a hitelesítést. Az Azure-ba telepítendő alkalmazások fejlesztése során az Azure-beli üzemeltetési környezetek hitelesítő adatait a helyi fejlesztés hitelesítő adataival kombinálja. További információ: Azure-ban üzemeltetett .NET-alkalmazások hitelesítése Azure-erőforrásokra rendszer által hozzárendelt felügyelt identitás használatával.

Ha az alkalmazás a régebbi Azure-csomagokat (Microsoft.AspNetCore.DataProtection.AzureStorageésMicrosoft.AspNetCore.DataProtection.AzureKeyVault) használja, javasoljuk, hogy távolítsa el ezeket a hivatkozásokat, és frissítsen a Azure.Extensions.AspNetCore.DataProtection.Blobs csomagokra.Azure.Extensions.AspNetCore.DataProtection.Keys Az újabb csomagok a legfontosabb biztonsági és stabilitási problémákat kezelik.

Alternatív közös hozzáférésű jogosultságkód (SAS) megközelítés: Az Azure Blob Storage kulcsblobjához való hozzáférés felügyelt használatára Identity szolgáló alternatív megoldásként meghívhatja azt a PersistKeysToAzureBlobStorage túlterhelést, amely SAS-jogkivonattal fogadja a blob URI-t. Az alábbi példa továbbra is egy ManagedIdentityCredential (éles) vagy DefaultAzureCredential (fejlesztési és tesztelési) célt használ a TokenCredential esetében, ahogyan az az előző példában látható:

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

{APPLICATION NAME}: SetApplicationName beállítja az alkalmazás egyedi nevét az adatvédelmi rendszeren belül. Az értéknek meg kell egyeznie az alkalmazás üzembe helyezései között.

{BLOB URI WITH SAS}: A teljes URI, ahol a kulcsfájlt az SAS-jogkivonattal kell tárolni lekérdezési karakterlánc paramétereként. Az URI-t az Azure Storage hozza létre, amikor SAS-t kér a feltöltött kulcsfájlhoz.

{KEY IDENTIFIER}: Kulcstitkosításhoz használt Azure Key Vault-kulcsazonosító. A hozzáférési szabályzat lehetővé teszi, hogy az alkalmazás hozzáférjen a kulcstartóhoz Get, Unwrap Keyés Wrap Key engedélyekkel. A kulcs verzióját az Entra vagy az Azure Portal kulcsából szerzi be a rendszer a létrehozás után. Ha engedélyezi a kulcstartó kulcsának automatikus elforgatását, győződjön meg arról, hogy verzió nélküli kulcsazonosítót használ az alkalmazás kulcstartójának konfigurációjában, ahol a kulcs guid azonosítója nem található az azonosító végén (például: https://contoso.vault.azure.net/keys/data-protection).

A fájlrendszer kulcsainak megőrzése (PersistKeysToFileSystem)

A kulcsok UNC-megosztáson való tárolásához, nem az %LOCALAPPDATA% alapértelmezett helyen, konfigurálja a rendszert a következővel PersistKeysToFileSystem:

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

Warning

Ha módosítja a kulcsmegőrzés helyét, a rendszer többé nem titkosítja automatikusan a inaktív kulcsokat, mivel nem tudja, hogy a DPAPI megfelelő titkosítási mechanizmus-e.

Kulcsok megőrzése egy adatbázisban (PersistKeysToDbContext)

Ha az EntityFramework használatával szeretne kulcsokat tárolni egy adatbázisban, konfigurálja a rendszert a Microsoft.AspNetCore.DataProtection.EntityFrameworkCore csomaggal:

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

Az előző kód a kulcsokat a konfigurált adatbázisban tárolja. A használt adatbázis-környezetnek implementálnia IDataProtectionKeyContextkell. IDataProtectionKeyContext elérhetővé teszi a tulajdonságot DataProtectionKeys

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

Ez a tulajdonság azt a táblát jelöli, amelyben a kulcsok vannak tárolva. Hozza létre a táblát manuálisan vagy a DbContext Migrations eszközzel. További információ: DataProtectionKey.

Kulcskonfigurációs API védelme (ProtectKeysWith\*)

A rendszer úgy konfigurálható, hogy az inaktív kulcsokat a konfigurációs API-k bármelyikének ProtectKeysWith\* meghívásával védje. Vegyük az alábbi példát, amely egy UNC-megosztáson tárolja a kulcsokat, és egy adott X.509-tanúsítvánnyal titkosítja az inaktív kulcsokat.

Egy fájlból való X509Certificate2 átadásához ProtectKeysWithCertificate felé, hívja a X509CertificateLoader.LoadCertificateFromFile-t:

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

Az alábbi példakód bemutatja, hogyan tölthet be tanúsítványt ujjlenyomattal:

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

A beépített kulcstitkosítási mechanizmusokkal kapcsolatos példákért és vitafórumért lásd a Windows és az Azure inaktív kulcstitkosítását a ASP.NET Core használatával.

Kulcsok védelmének feloldása bármilyen tanúsítvánnyal (UnprotectKeysWithAnyCertificate)

A tanúsítványok és a visszafejtési kulcsok inaktív állapotban a következő tanúsítványtömbökkel X509Certificate2UnprotectKeysWithAnyCertificateelforgathatók:

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

Az alapértelmezett kulcs élettartamának beállítása (SetDefaultKeyLifetime)

Ha úgy szeretné konfigurálni a rendszert, hogy az alapértelmezett 90 nap helyett 14 napos kulcsélettartamot használjon, használja a következőt SetDefaultKeyLifetime:

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

Az alkalmazás nevének beállítása (SetApplicationName)

Az Adatvédelmi rendszer alapértelmezés szerint elkülöníti az alkalmazásokat egymástól a tartalom gyökérútvonalai alapján, még akkor is, ha ugyanazzal a fizikai kulcstárházzal rendelkeznek. Ez az elkülönítés megakadályozza, hogy az alkalmazások megértsék egymás védett adatátviteleiket.

Az alkalmazások között védett hasznos terheket/osztott tartalmakat megosztani:

• Konfiguráljon SetApplicationName minden alkalmazásban ugyanazzal az értékkel.
• Használja a Data Protection API-verem ugyanazon verzióját az alkalmazásokban. Hajtsa végre az alábbi műveletek egyikét az alkalmazások projektfájljaiban:
  • A Microsoft.AspNetCore.App metapackage-en keresztül hivatkozzon ugyanarra a megosztott keretrendszer-verzióra.
  • Hivatkozzon ugyanarra az adatvédelmi csomagverzióra .

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

SetApplicationName belsőleg beállítja DataProtectionOptions.ApplicationDiscriminator. Hibaelhárítási célokból a keretrendszer által a diszkriminatívhoz rendelt érték a következő kóddal naplózható, miután a WebApplication rendszer be van építve Program.cs:

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

A diszkriminatív alkalmazásával kapcsolatos további információkért tekintse meg a cikk későbbi szakaszait:

• Alkalmazásonkénti elkülönítés
• Adatvédelem és alkalmazáselkülönítés

Warning

.NET 6 esetén a tartalom gyökérútvonalát WebApplicationBuilder normalizálja, hogy DirectorySeparatorChar-ra/ta végződjön. Windows rendszeren például a tartalom gyökérútvonala Linuxon \ és Linuxon /végződik. Más gazdagépek nem normalizálják az elérési utat. A legtöbb alkalmazás, amely a HostBuilder vagy WebHostBuilder alól migrál, nem fogja ugyanazt az alkalmazásnevet viselni, mert nem fog szerepelni a végén DirectorySeparatorChar. A probléma megoldásához távolítsa el a címtárelválasztó karaktert, és állítsa be manuálisan az alkalmazás nevét az alábbi kódban látható módon:

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

Automatikus kulcslétrehozás letiltása (DisableAutomaticKeyGeneration)

Előfordulhat, hogy olyan forgatókönyve van, amelyben nem szeretné, hogy egy alkalmazás automatikusan kulcsokat állíthasson be (új kulcsokat hozzon létre) a lejárat közeledtével. Ilyen eset lehet például az elsődleges/másodlagos kapcsolatban beállított alkalmazások, ahol csak az elsődleges alkalmazás felelős a kulcskezelési problémákért, a másodlagos alkalmazások pedig egyszerűen csak olvasható nézettel rendelkeznek a kulcsgyűrűről. A másodlagos alkalmazások konfigurálhatók úgy, hogy a kulcsgyűrűt írásvédettként kezeljék a rendszer konfigurálásával a következővel DisableAutomaticKeyGeneration:

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

Alkalmazásonkénti elkülönítés

Ha az adatvédelmi rendszert egy ASP.NET Core-gazdagép biztosítja, automatikusan elkülöníti az alkalmazásokat egymástól, még akkor is, ha ezek az alkalmazások ugyanazon feldolgozói folyamatfiók alatt futnak, és ugyanazt a főkulcs-anyagot használják. Ez hasonló a System.Web elemében található IsolateApps-módosítóhoz <machineKey> .

Az elkülönítési mechanizmus úgy működik, hogy a helyi gépen lévő alkalmazásokat egyedi bérlőként tekinti, így az IDataProtector adott alkalmazás gyökerében automatikusan szerepel az alkalmazásazonosító diszkriminatív (ApplicationDiscriminator). Az alkalmazás egyedi azonosítója az alkalmazás fizikai elérési útja:

• Az IIS-ben üzemeltetett alkalmazások esetében az egyedi azonosító az alkalmazás IIS fizikai elérési útja. Ha egy alkalmazás webfarm-környezetben van üzembe helyezve, ez az érték stabil, feltéve, hogy az IIS-környezetek hasonlóan vannak konfigurálva a webfarm összes gépén.
• A kiszolgálón futó saját üzemeltetésű alkalmazások esetében az Kestrelegyedi azonosító az alkalmazás fizikai elérési útja a lemezen.

Az egyedi azonosító úgy lett kialakítva, hogy túlélje az alaphelyzetbe állításokat – az egyes alkalmazásokat és magát a gépet is.

Ez az elkülönítési mechanizmus feltételezi, hogy az alkalmazások nem rosszindulatúak. A rosszindulatú alkalmazások mindig hatással lehetnek az ugyanazon a feldolgozói folyamatfiókon futó többi alkalmazásra. Olyan megosztott üzemeltetési környezetben, ahol az alkalmazások kölcsönösen nem megbízhatók, a szolgáltatónak lépéseket kell tennie az alkalmazások operációsrendszer-szintű elkülönítésének biztosítására, beleértve az alkalmazások mögöttes kulcstárolóinak elkülönítését is.

Ha az adatvédelmi rendszert nem egy ASP.NET Core-gazdagép biztosítja (például ha konkrét típuson keresztül DataProtectionProvider hozza létre), az alkalmazáselkülönítés alapértelmezés szerint le van tiltva. Ha az alkalmazáselkülönítés le van tiltva, az ugyanazon kulcsanyag által támogatott alkalmazások mindaddig megoszthatják az adatterheket, amíg megadják a megfelelő célokat. Ha alkalmazáselkülönítést szeretne biztosítani ebben a környezetben, hívja meg a SetApplicationName konfigurációs objektum metódusát, és adjon meg egy egyedi nevet az egyes alkalmazásoknak.

Adatvédelem és alkalmazáselkülönítés

Az alkalmazáselkülönítéshez vegye figyelembe a következő szempontokat:

• Ha több alkalmazás is ugyanarra a kulcstárházra mutat, a cél az, hogy az alkalmazások ugyanazt a főkulcs-anyagot használják. Az Adatvédelem azzal a feltételezéssel van kialakítva, hogy a kulcsgyűrűt használó összes alkalmazás hozzáférhet a kulcsgyűrű összes eleméhez. Az alkalmazás egyedi azonosítója a megadott kulcsok kulcsgyűrűből származó alkalmazásspecifikus kulcsok elkülönítésére szolgál. Nem számít az elemszintű engedélyekre, például az Azure KeyVault által biztosított engedélyekre a további elkülönítés kikényszerítéséhez. Az elemszintű engedélyek megkísérlése alkalmazáshibákat okoz. Ha nem szeretne a beépített alkalmazáselkülönítésre támaszkodni, külön kulcstároló helyeket kell használnia, és nem kell megosztania az alkalmazások között.

• Az alkalmazásmegkülönböztető (ApplicationDiscriminator) lehetővé teszi, hogy a különböző alkalmazások ugyanazt a főkulcsanyagot használják, de titkosítási tartalmaik különbözzenek egymástól. Ahhoz, hogy az alkalmazások képesek legyenek olvasni egymás titkosított adatcsomagjait, ugyanazzal az alkalmazásmeghatározóval kell rendelkezniük, amelyet a SetApplicationName hívásával lehet beállítani.

• Ha egy alkalmazás biztonsága sérül (például RCE-támadás), az alkalmazáshoz elérhető összes főkulcs-anyagot is sérültnek kell tekinteni, függetlenül attól, hogy a védelem inaktív állapotban van-e. Ez azt jelenti, hogy ha két alkalmazás ugyanarra az adattárra mutat, még akkor is, ha különböző alkalmazásmegkülönböztetőket használnak, az egyik feltörése funkcionálisan egyenértékű mindkettő feltörésével.

  Ez a "funkcionálisan egyenértékű a kettő kompromisszumával" záradék akkor is érvényes, ha a két alkalmazás különböző mechanizmusokat használ a kulcsvédelemhez inaktív állapotban. Ez általában nem várt konfiguráció. A nyugalmi állapotban lévő védelem mechanizmusának célja, hogy védelmet nyújtson abban az esetben, ha egy kibertámadó olvasási hozzáférést szerez az adattárhoz. Egy kiberbűnöző, aki írási hozzáférést szerez az adattárhoz (talán azért, mert kódvégrehajtási engedélyt szerzett egy alkalmazásban), rosszindulatú kulcsokat szúrhat be a tárolóba. Az adatvédelmi rendszer szándékosan nem nyújt védelmet egy kiberbűnözővel szemben, aki írási hozzáférést szerez a kulcstárhoz.

• Ha az alkalmazásoknak valóban el kell különülniük egymástól, különböző kulcstárakat kell használniuk. Ez természetesen kiesik az "izolált" definícióból. Az alkalmazások nem különíthetők el, ha mind olvasási és írási hozzáféréssel rendelkeznek egymás adattáraihoz.

Algoritmusok változtatása UseCryptographicAlgorithms

Az Adatvédelmi modul lehetővé teszi az újonnan létrehozott kulcsok által használt alapértelmezett algoritmus módosítását. A legegyszerűbb módja ennek, ha a UseCryptographicAlgorithms-t a konfigurációs visszahívásból hívjuk meg.

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

Az alapértelmezett EncryptionAlgorithm az AES-256-CBC, az alapértelmezett ValidationAlgorithm pedig HMACSHA256. Az alapértelmezett házirendet a rendszergazda gépi szintű szabályzaton keresztül állíthatja be, de explicit hívással UseCryptographicAlgorithms felülbírálhatja az alapértelmezett szabályzatot.

A hívással UseCryptographicAlgorithms megadhatja a kívánt algoritmust egy előre definiált beépített listából. Nem kell aggódnia az algoritmus implementációja miatt. A fenti forgatókönyvben az adatvédelmi rendszer megkísérli használni az AES CNG-implementációját, ha Windows rendszeren fut. Ellenkező esetben visszaesik a felügyelt System.Security.Cryptography.Aes osztályba.

Az implementációt manuálisan is megadhatja egy hívással.UseCustomCryptographicAlgorithms

Tip

Az algoritmusok módosítása nem befolyásolja a kulcsgyűrű meglévő kulcsait. Csak az újonnan létrehozott kulcsokat érinti.

Egyéni felügyelt algoritmusok megadása

Egyéni kezelt algoritmusok megadásához hozzon létre egy ManagedAuthenticatedEncryptorConfiguration példányt, amely a megvalósítási típusokra mutat:

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

A *Típustulajdonságoknak általában konkrét, példányosítható (nyilvános paraméter nélküli ctoron keresztüli) implementációkra kell mutatniuk SymmetricAlgorithm , és KeyedHashAlgorithmbár a rendszer speciális esetekben bizonyos értékeket, például typeof(Aes) a kényelem kedvéért használ.

Note

A szimmetrikus algoritmus kulcshosszának ≥ 128 bitnek kell lennie, blokkméretének pedig ≥ 64 bitnek, és támogatnia kell a CBC-módú titkosítást a PKCS#7 kitöltéssel. A KeyedHashAlgorithm kivonatoló méretének >= 128 bitnek kell lennie, és támogatnia kell a kivonatoló algoritmus kivonatolási hosszával egyenlő hosszúságú kulcsokat. A KeyedHashAlgorithm-nek nem feltétlenül kell HMAC-nak lennie.

Egyéni Windows CNG-algoritmusok megadása

Ha egyéni Windows CNG-algoritmust szeretne megadni CBC-módú titkosítással HMAC-ellenőrzéssel, hozzon létre egy olyan példányt CngCbcAuthenticatedEncryptorConfiguration , amely tartalmazza az algoritmikus információkat:

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

A szimmetrikus blokktitkosító algoritmusnak 128 bites kulcshosszúsággal >, 64 bites blokkmérettel > kell rendelkeznie, és támogatnia kell a CBC-módú titkosítást PKCS #7 kitöltéssel. A kivonatoló algoritmusnak = 128 bites kivonatmérettel kell rendelkeznie >, és támogatnia kell a BCRYPT_ALG_HANDLE_HMAC_FLAG jelzővel való megnyitást. A *Szolgáltató tulajdonságai null értékre állíthatók a megadott algoritmus alapértelmezett szolgáltatójának használatához. További információt a BCryptOpenAlgorithmProvider dokumentációjában talál.

Ha egyéni Windows CNG-algoritmust szeretne megadni Galois/Counter Mode titkosítással és ellenőrzéssel, hozzon létre egy CngGcmAuthenticatedEncryptorConfiguration példányt, amely tartalmazza az algoritmikus információkat.

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

        // Specified in bits
        EncryptionAlgorithmKeySize = 256
    });

Note

A szimmetrikus blokktitkosítási algoritmusnak = 128 bites kulcshosszúságúnak >, pontosan 128 bites blokkméretnek kell lennie, és támogatnia kell a GCM-titkosítást. A tulajdonságot null értékre állíthatja EncryptionAlgorithmProvider a megadott algoritmus alapértelmezett szolgáltatójának használatához. További információt a BCryptOpenAlgorithmProvider dokumentációjában talál.

Egyéb egyéni algoritmusok megadása

Bár első osztályú API-ként nem érhető el, az adatvédelmi rendszer elég bővíthető ahhoz, hogy szinte bármilyen algoritmust meghatározhasson. Például megtarthatja az összes kulcsot egy hardveres biztonsági modulban (HSM), és egyéni implementációt biztosíthat az alapvető titkosítási és visszafejtési rutinokhoz. További információkért lásd IAuthenticatedEncryptor a Core titkosítási bővíthetőségét.

Kulcsok megőrzése Docker-tárolóban való üzemeltetéskor

Docker-tárolóban való üzemeltetéskor a kulcsokat a következő esetekben kell fenntartani:

• A Docker-kötetként funkcionáló mappa, amely a tároló élettartamán túl is fennmarad, mint például egy megosztott kötet vagy egy gazdagéphez csatlakoztatott kötet.
• Egy külső szolgáltató, például az Azure Blob Storage (a szakaszban látható) vagy a ProtectKeysWithAzureKeyVaultRedis.

Kulcsok megőrzése a Redis használatával

Kulcsok tárolásához csak a Redis Adatmegőrzést támogató Redis-verziók használhatók. Az Azure Blob Storage állandó, és kulcsok tárolására használható. További információ: a GitHub-probléma.

Logging

A problémák diagnosztizálásához engedélyezze a Information vagy alacsonyabb szintű naplózást. Az alábbi appsettings.json fájl lehetővé teszi az adatvédelmi API információnaplózását:

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

További információ a naplózásról: Naplózás a .NET-ben és a ASP.NET Core-ban.

További erőforrások

• A ASP.NET Core adatvédelemmel kapcsolatos, nem DI-alapú forgatókönyvei
• Adatvédelmi gépszintű szabályzattámogatás a ASP.NET Core-ban
• ASP.NET Core üzemeltetése egy webfarmban
• ASP.NET Core kulcstároló-szolgáltatók