Udostępnij za pośrednictwem


ASP.NET Core Data Protection — omówienie

ASP.NET Core udostępnia kryptograficzny interfejs API do ochrony danych, w tym zarządzanie kluczami i rotację.

Aplikacje internetowe często muszą przechowywać poufne dane. Interfejs API ochrony danych systemu Windows (DPAPI) nie jest przeznaczony do użycia w aplikacjach internetowych.

Stos ochrony danych ASP.NET Core został zaprojektowany w celu:

  • Udostępniaj wbudowane rozwiązanie dla większości scenariuszy sieci Web.
  • Rozwiąż wiele niedociągnięć poprzedniego systemu szyfrowania.
  • Służy jako zamiennik <machineKey> elementu w ASP.NET 1.x - 4.x.

Opis problemu

Chcę zachować zaufane informacje na potrzeby późniejszego pobierania, ale nie ufam mechanizmowi trwałości. W kategoriach internetowych może to być napisane, ponieważ muszę zaokrąglić zaufany stan za pośrednictwem niezaufanego klienta.

Wymagana jest autentyczność, integralność i weryfikacja manipulacji. Przykładem kanonicznym jest uwierzytelnianie cookie lub token elementu nośnego. Serwer generuje element Groot i ma token uprawnień xyz i wysyła go do klienta. Klient przedstawia ten token z powrotem na serwerze, ale serwer potrzebuje pewnego rodzaju pewności, że klient nie sfałszował tokenu.

Poufność jest wymagana. Ponieważ stan utrwalone jest zaufany przez serwer, ten stan może zawierać informacje, które nie powinny być ujawniane niezaufanym klientowi. Na przykład:

  • Ścieżka pliku.
  • Uprawnienie.
  • Dojście lub inne odwołanie pośrednie.
  • Niektóre dane specyficzne dla serwera.

Izolacja jest wymagana. Ponieważ nowoczesne aplikacje są kom składowane, poszczególne składniki chcą korzystać z tego systemu bez względu na inne składniki w systemie. Rozważmy na przykład składnik tokenu elementu nośnego przy użyciu tego stosu. Powinna działać bez żadnych zakłóceń, na przykład, z mechanizmu anty-CSRF również przy użyciu tego samego stosu.

Niektóre typowe założenia mogą zawęzić zakres wymagań:

  • Wszystkie usługi działające w systemie kryptograficznym są równie zaufane.
  • Dane nie muszą być generowane ani używane poza usługami pod naszą bezpośrednią kontrolą.
  • Operacje muszą być szybkie, ponieważ każde żądanie do usługi internetowej może przechodzić przez system kryptograficzny co najmniej raz. Wymaganie dotyczące szybkości sprawia, że kryptografia symetryczna jest idealna. Kryptografia asymetryczna nie jest używana, dopóki nie jest wymagana.

Filozofia projektowania

ASP.NET Podstawowa ochrona danych jest łatwym w użyciu stosem ochrony danych. Jest ona oparta na następujących zasadach:

  • Łatwość konfiguracji. System dąży do zerowej konfiguracji. W sytuacjach, w których deweloperzy muszą skonfigurować określony aspekt, taki jak repozytorium kluczy, te konkretne konfiguracje nie są trudne.
  • Oferowanie podstawowego interfejsu API dostępnego dla konsumentów. Interfejsy API są proste do poprawnego i trudnego do użycia niepoprawnie.
  • Deweloperzy nie muszą uczyć się kluczowych zasad zarządzania. System obsługuje wybór algorytmów i okres istnienia klucza w imieniu dewelopera. Deweloper nie ma dostępu do surowca klucza.
  • Klucze są chronione w rest jak największej ilości. System określa odpowiedni domyślny mechanizm ochrony i stosuje go automatycznie.

Interfejsy API ochrony danych nie są przeznaczone przede wszystkim do trwałego przechowywania poufnych ładunków. Inne technologie, takie jak Windows CNG DPAPI i Azure Rights Management , są bardziej dostosowane do scenariusza magazynu na czas nieokreślony. Mają one odpowiednio silne możliwości zarządzania kluczami. Oznacza to, że podstawowe interfejsy API ochrony danych ASP.NET mogą służyć do długoterminowej ochrony poufnych danych.

Odbiorcy

System ochrony danych udostępnia interfejsy API przeznaczone dla trzech głównych odbiorców:

  1. Interfejsy API konsumentów są przeznaczone dla deweloperów aplikacji i platform.

    Nie chcę dowiedzieć się, jak działa stos lub jak jest skonfigurowany. Chcę tylko wykonać operację z wysokim prawdopodobieństwem użycia interfejsów API pomyślnie.

  2. Interfejsy API konfiguracji są przeznaczone dla deweloperów aplikacji i administratorów systemu.

    Chcę poinformować system ochrony danych, że środowisko wymaga ścieżek lub ustawień innych niż domyślne.

  3. Interfejsy API rozszerzalności są przeznaczone dla deweloperów służących do implementowania zasad niestandardowych. Użycie tych interfejsów API jest ograniczone do rzadkich sytuacji i deweloperów ze środowiskiem zabezpieczeń.

    Muszę zastąpić cały składnik w systemie, ponieważ mam naprawdę unikatowe wymagania behawioralne. Chcę nauczyć się rzadko używanych części powierzchni interfejsu API, aby utworzyć wtyczkę spełniającą moje wymagania.

Układ pakietu

Stos ochrony danych składa się z pięciu pakietów:

Dodatkowe zasoby

ASP.NET Core udostępnia kryptograficzny interfejs API do ochrony danych, w tym zarządzanie kluczami i rotację.

Aplikacje internetowe często muszą przechowywać poufne dane. Interfejs API ochrony danych systemu Windows (DPAPI) nie jest przeznaczony do użycia w aplikacjach internetowych.

Stos ochrony danych ASP.NET Core został zaprojektowany w celu:

  • Udostępniaj wbudowane rozwiązanie dla większości scenariuszy sieci Web.
  • Rozwiąż wiele niedociągnięć poprzedniego systemu szyfrowania.
  • Służy jako zamiennik <machineKey> elementu w ASP.NET 1.x - 4.x.

Opis problemu

Chcę zachować zaufane informacje na potrzeby późniejszego pobierania, ale nie ufam mechanizmowi trwałości. W kategoriach internetowych może to być napisane, ponieważ muszę zaokrąglić zaufany stan za pośrednictwem niezaufanego klienta.

Wymagana jest autentyczność, integralność i weryfikacja manipulacji. Przykładem kanonicznym jest uwierzytelnianie cookie lub token elementu nośnego. Serwer generuje element Groot i ma token uprawnień xyz i wysyła go do klienta. Klient przedstawia ten token z powrotem na serwerze, ale serwer potrzebuje pewnego rodzaju pewności, że klient nie sfałszował tokenu.

Poufność jest wymagana. Ponieważ stan utrwalone jest zaufany przez serwer, ten stan może zawierać informacje, które nie powinny być ujawniane niezaufanym klientowi. Na przykład:

  • Ścieżka pliku.
  • Uprawnienie.
  • Dojście lub inne odwołanie pośrednie.
  • Niektóre dane specyficzne dla serwera.

Izolacja jest wymagana. Ponieważ nowoczesne aplikacje są kom składowane, poszczególne składniki chcą korzystać z tego systemu bez względu na inne składniki w systemie. Rozważmy na przykład składnik tokenu elementu nośnego przy użyciu tego stosu. Powinna działać bez żadnych zakłóceń, na przykład, z mechanizmu anty-CSRF również przy użyciu tego samego stosu.

Niektóre typowe założenia mogą zawęzić zakres wymagań:

  • Wszystkie usługi działające w systemie kryptograficznym są równie zaufane.
  • Dane nie muszą być generowane ani używane poza usługami pod naszą bezpośrednią kontrolą.
  • Operacje muszą być szybkie, ponieważ każde żądanie do usługi internetowej może przechodzić przez system kryptograficzny co najmniej raz. Wymaganie dotyczące szybkości sprawia, że kryptografia symetryczna jest idealna. Kryptografia asymetryczna nie jest używana, dopóki nie jest wymagana.

Filozofia projektowania

ASP.NET Podstawowa ochrona danych jest łatwym w użyciu stosem ochrony danych. Jest ona oparta na następujących zasadach:

  • Łatwość konfiguracji. System dąży do zerowej konfiguracji. W sytuacjach, w których deweloperzy muszą skonfigurować określony aspekt, taki jak repozytorium kluczy, te konkretne konfiguracje nie są trudne.
  • Oferowanie podstawowego interfejsu API dostępnego dla konsumentów. Interfejsy API są proste do poprawnego i trudnego do użycia niepoprawnie.
  • Deweloperzy nie muszą uczyć się kluczowych zasad zarządzania. System obsługuje wybór algorytmów i okres istnienia klucza w imieniu dewelopera. Deweloper nie ma dostępu do surowca klucza.
  • Klucze są chronione w rest jak największej ilości. System określa odpowiedni domyślny mechanizm ochrony i stosuje go automatycznie.

Interfejsy API ochrony danych nie są przeznaczone przede wszystkim do trwałego przechowywania poufnych ładunków. Inne technologie, takie jak Windows CNG DPAPI i Azure Rights Management , są bardziej dostosowane do scenariusza magazynu na czas nieokreślony. Mają one odpowiednio silne możliwości zarządzania kluczami. Oznacza to, że podstawowe interfejsy API ochrony danych ASP.NET mogą służyć do długoterminowej ochrony poufnych danych.

Odbiorcy

System ochrony danych udostępnia interfejsy API przeznaczone dla trzech głównych odbiorców:

  1. Interfejsy API konsumentów są przeznaczone dla deweloperów aplikacji i platform.

    Nie chcę dowiedzieć się, jak działa stos lub jak jest skonfigurowany. Chcę tylko wykonać operację z wysokim prawdopodobieństwem użycia interfejsów API pomyślnie.

  2. Interfejsy API konfiguracji są przeznaczone dla deweloperów aplikacji i administratorów systemu.

    Chcę poinformować system ochrony danych, że środowisko wymaga ścieżek lub ustawień innych niż domyślne.

  3. Interfejsy API rozszerzalności są przeznaczone dla deweloperów służących do implementowania zasad niestandardowych. Użycie tych interfejsów API jest ograniczone do rzadkich sytuacji i deweloperów ze środowiskiem zabezpieczeń.

    Muszę zastąpić cały składnik w systemie, ponieważ mam naprawdę unikatowe wymagania behawioralne. Chcę nauczyć się rzadko używanych części powierzchni interfejsu API, aby utworzyć wtyczkę spełniającą moje wymagania.

Układ pakietu

Stos ochrony danych składa się z pięciu pakietów:

Dodatkowe zasoby