ASP.NET Core Ochrana dat

Webové aplikace často potřebují ukládat data citlivá na zabezpečení. Windows poskytuje rozhraní data protection API (DPAPI) pro desktopové aplikace, ale Windows DPAPI není určené pro použití ve webových aplikacích. sada ASP.NET Core data protection stack nabízí jednoduché a snadno použitelné kryptografické rozhraní API, které může vývojář použít k ochraně dat, včetně správy klíčů a rotace.

sada ASP.NET Core data protection stack je navržena jako dlouhodobá náhrada < > elementu machineKey v ASP.NET 1. x-4. x. Byl navržen tak, aby využíval mnoho nedostatků starého kryptografického zásobníku a zároveň poskytovalo předem připravené řešení pro většinu případů použití moderních aplikací, které se mohou vyskytnout.

Popis problému

Celkový příkaz problému může být stručně uveden v jedné větě: Potřebuji zachovat důvěryhodné informace pro pozdější načtení, ale nedůvěřujete tak mechanismu trvalosti. Ve webových případech to může být zapsáno jako "Potřebuji k výměně důvěryhodného stavu prostřednictvím nedůvěryhodného klienta".

Kanonický příklad představuje ověřování cookie nebo nosný token. Server vygeneruje token "jsem Groot a má oprávnění xyz" a předá ho klientovi. V některých budoucích kalendářních verzích klienta předloží token zpátky na server, ale server potřebuje určitý druh záruky, že klient nezfalšovaný token. Proto první požadavek: pravost (označuje se také jako integrita, kontrola proti falšování).

Vzhledem k tomu, že trvalý stav je důvěryhodný pro server, předpokládáme, že tento stav může obsahovat informace, které jsou specifické pro operační prostředí. Může to být ve formě cesty k souboru, oprávnění, popisovače nebo jiného nepřímých odkazů nebo některých jiných dat specifických pro server. Tyto informace by obecně neměly být zveřejněné nedůvěryhodnému klientovi. Proto druhý požadavek: důvěrnost.

Nakonec vzhledem k tomu, že moderní aplikace jsou součástí komponenty, k čemu jsme zjistili, že jednotlivé komponenty budou chtít využít výhod tohoto systému bez ohledu na jiné součásti systému. Například pokud komponenta nosného tokenu používá tento zásobník, měla by fungovat bez rušivého mechanismu CSRF, který může také používat stejný zásobník. Proto konečný požadavek: izolace.

Abychom mohli zúžit rozsah našich požadavků, můžeme vám poskytnout další omezení. Předpokládáme, že všechny služby, které fungují v rámci cryptosystem, jsou stejně důvěryhodné a že je nemusíte vygenerovat ani spotřebovat mimo služby v rámci našeho přímého řízení. Kromě toho vyžadujeme, aby operace byly co nejrychlejší, protože každý požadavek na webovou službu může projít cryptosystem jednou nebo víckrát. To usnadňuje symetrickou kryptografii pro náš scénář a můžeme vyzvýhodněnit asymetrické šifrování až do doby, kdy je potřeba.

Filozofie návrhu

Zahájili jsme identifikaci problémů s existujícím zásobníkem. Až to máme, provedli jsme šetření na šířku stávajících řešení a uzavřeli jsme si, že žádné řešení ještě neobsahovalo možnosti, které jsme si vyžádali. Pak jsme navrhli řešení na základě několika principů pro GUID.

  • Systém by měl nabízet jednoduchost konfigurace. V ideálním případě by měl být systém nulový – konfigurace a vývojáři by mohli dosáhnout provozu. V situacích, kdy vývojáři potřebují nakonfigurovat konkrétní aspekt (například úložiště klíčů), je třeba zvážit, že tyto konkrétní konfigurace budou jednoduché.

  • Nabízí jednoduché rozhraní API zaměřené na uživatele. Rozhraní API by se mělo snadno používat správně a obtížné ho používat nesprávně.

  • Vývojáři se nedozvěděli o zásadách správy klíčů. Systém by měl zpracovat výběr algoritmu a životnost klíče jménem vývojáře. V ideálním případě by vývojář neměl nikdy mít přístup k nezpracovanému materiálu klíče.

  • Pokud je to možné, měly by se klíče chránit v klidovém umístění. Systém by měl zjistit vhodný výchozí mechanismus ochrany a použít ho automaticky.

Díky těmto principům jsme vyvinuli jednoduchý a snadno použitelný zásobník ochrany dat.

rozhraní api pro ochranu ASP.NET Core dat nejsou primárně určena pro neomezenou perzistenci důvěrných datových částí. další technologie, jako Windows CNG DPAPI a Azure Rights Management , jsou užitečnější pro scénář neurčitého úložiště a mají odpovídající možnosti silné správy klíčů. v takovém případě nebrání vývojářům v používání rozhraní api ochrany ASP.NET Core dat pro dlouhodobou ochranu důvěrných dat.

Cílová skupina

Systém ochrany dat je rozdělen na pět hlavních balíčků. Různé aspekty těchto rozhraní API cílí na tři hlavní cílové skupiny;

  1. Přehled rozhraní API pro uživatele cílí na vývojáře aplikací a platforem.

    "Nechci se dozvědět, jak zásobník funguje, nebo o tom, jak je nakonfigurované. Můžu jednoduše provést určitou operaci způsobem, jak je možné, s vysokou pravděpodobností používání rozhraní API úspěšně. "

  2. Rozhraní API pro konfiguraci vývojářů cílové aplikace a správce systému.

    "Potřebuji sdělit systém ochrany dat, že moje prostředí vyžaduje jiné než výchozí cesty nebo nastavení."

  3. Rozhraní API pro rozšiřitelnost cílí vývojářům při implementaci vlastních zásad. Použití těchto rozhraní API by se mělo omezit na výjimečné situace a zkušenosti, a to pro vývojáře v zabezpečení.

    "Musím v systému nahradit celou součást, protože mám skutečně jedinečné požadavky na chování. Beru na vyznámení s neobvyklými využitími plochy rozhraní API, aby bylo možné vytvořit modul plug-in, který splňuje požadavky. "

Rozložení balíčku

Zásobník ochrany dat se skládá z pěti balíčků.

Další materiály

Hostování ASP.NET Core ve webové farmě