Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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.
Mechanizm 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 terminologii internetowej można by to ująć jako muszę przesłać i odebrać zaufany stan za pośrednictwem niezaufanego klienta (np. przeglądarki).
Wymagana jest autentyczność, integralność i odporność na manipulacje. Przykładem kanonicznym jest token uwierzytelniający cookie lub token użytkownika. Serwer generuje token jestem Groot i mam uprawnienia 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ż utrwalony stan jest uznawany za zaufany przez serwer, może zawierać informacje, które nie powinny być ujawniane niezaufanemu klientowi. Na przykład:
- Ścieżka pliku.
- Uprawnienie.
- Uchwyt 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, przez mechanizm anty-CSRF, który również wykorzystuje ten sam stos.
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ą łatwe do poprawnego użycia i trudne do niewłaściwego zastosowania.
- 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 surowego materiału klucza.
- Klucze są chronione w spoczynku w jak największym stopniu. 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:
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.
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.
Interfejsy API rozszerzalności są przeznaczone dla deweloperów odpowiedzialnych za implementowanie zasad niestandardowych. Użycie tych interfejsów API jest ograniczone do rzadkich sytuacji i deweloperów z doświadczeniem w zakresie bezpieczeństwa.
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:
Microsoft.AspNetCore.DataProtection.Abstractions zawiera:
- Interfejsy IDataProtectionProvider i IDataProtector do tworzenia usług ochrony danych.
- Przydatne metody rozszerzenia do pracy z tymi typami. na przykład IDataProtector.Protect
Jeśli system ochrony danych jest tworzony w innym miejscu i używasz interfejsu API, odwołaj się do
Microsoft.AspNetCore.DataProtection.Abstractions.Microsoft.AspNetCore.DataProtection zawiera podstawową implementację systemu ochrony danych, w tym:
- Podstawowe operacje kryptograficzne.
- Zarządzanie kluczami.
- Konfiguracja i rozszerzalność.
Aby utworzyć wystąpienie systemu ochrony danych, odwołaj się do
Microsoft.AspNetCore.DataProtection. Może być konieczne odwołanie się do systemu ochrony danych w następujących przypadkach:- Dodanie go do elementu IServiceCollection.
- Modyfikowanie lub rozszerzanie jego zachowania.
Microsoft.AspNetCore.DataProtection.Extensions zawiera dodatkowe interfejsy API, które deweloperzy mogą znaleźć przydatne, ale które nie należą do pakietu podstawowego. Na przykład ten pakiet zawiera:
- Metody fabryczne do tworzenia instancji systemu ochrony danych w celu przechowywania kluczy w lokalizacji w systemie plików bez użycia wstrzykiwania zależności. Zobacz: DataProtectionProvider.
- Metody rozszerzenia ograniczające okres istnienia chronionych ładunków. Zobacz: ITimeLimitedDataProtector.
Microsoft.AspNetCore.DataProtection.SystemWeb można zainstalować w istniejącej aplikacji ASP.NET 4.x, aby przekierować operacje
<machineKey>do korzystania z nowego stosu ochrony danych ASP.NET Core. Aby uzyskać więcej informacji, zobacz Zastępowanie ASP.NET machineKey w ASP.NET Core.Microsoft.AspNetCore.Cryptography.KeyDerivation zapewnia implementację procedury tworzenia skrótów haseł PBKDF2 i może być używana przez systemy, które muszą bezpiecznie obsługiwać hasła użytkowników. Aby uzyskać więcej informacji, zobacz Hash passwords in ASP.NET Core (Haszowanie haseł w ASP.NET Core).
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.
Mechanizm 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 terminologii internetowej można by to ująć jako muszę przesłać i odebrać zaufany stan za pośrednictwem niezaufanego klienta (np. przeglądarki).
Wymagana jest autentyczność, integralność i odporność na manipulacje. Przykładem kanonicznym jest token uwierzytelniający cookie lub token użytkownika. Serwer generuje token jestem Groot i mam uprawnienia 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ż utrwalony stan jest uznawany za zaufany przez serwer, może zawierać informacje, które nie powinny być ujawniane niezaufanemu klientowi. Na przykład:
- Ścieżka pliku.
- Uprawnienie.
- Uchwyt 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, przez mechanizm anty-CSRF, który również wykorzystuje ten sam stos.
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ą łatwe do poprawnego użycia i trudne do niewłaściwego zastosowania.
- 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 surowego materiału klucza.
- Klucze są chronione w spoczynku w jak największym stopniu. 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:
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.
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.
Interfejsy API rozszerzalności są przeznaczone dla deweloperów odpowiedzialnych za implementowanie zasad niestandardowych. Użycie tych interfejsów API jest ograniczone do rzadkich sytuacji i deweloperów z doświadczeniem w zakresie bezpieczeństwa.
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:
Microsoft.AspNetCore.DataProtection.Abstractions zawiera:
- Interfejsy IDataProtectionProvider i IDataProtector do tworzenia usług ochrony danych.
- Przydatne metody rozszerzenia do pracy z tymi typami. na przykład IDataProtector.Protect
Jeśli system ochrony danych jest tworzony w innym miejscu i używasz interfejsu API, odwołaj się do
Microsoft.AspNetCore.DataProtection.Abstractions.Microsoft.AspNetCore.DataProtection zawiera podstawową implementację systemu ochrony danych, w tym:
- Podstawowe operacje kryptograficzne.
- Zarządzanie kluczami.
- Konfiguracja i rozszerzalność.
Aby utworzyć wystąpienie systemu ochrony danych, odwołaj się do
Microsoft.AspNetCore.DataProtection. Może być konieczne odwołanie się do systemu ochrony danych w następujących przypadkach:- Dodanie go do elementu IServiceCollection.
- Modyfikowanie lub rozszerzanie jego zachowania.
Microsoft.AspNetCore.DataProtection.Extensions zawiera dodatkowe interfejsy API, które deweloperzy mogą znaleźć przydatne, ale które nie należą do pakietu podstawowego. Na przykład ten pakiet zawiera:
- Metody fabryczne do tworzenia instancji systemu ochrony danych w celu przechowywania kluczy w lokalizacji w systemie plików bez użycia wstrzykiwania zależności. Zobacz: DataProtectionProvider.
- Metody rozszerzenia ograniczające okres istnienia chronionych ładunków. Zobacz: ITimeLimitedDataProtector.
Microsoft.AspNetCore.DataProtection.SystemWeb można zainstalować w istniejącej aplikacji ASP.NET 4.x, aby przekierować operacje
<machineKey>do korzystania z nowego stosu ochrony danych ASP.NET Core. Aby uzyskać więcej informacji, zobacz Zastępowanie ASP.NET machineKey w ASP.NET Core.Microsoft.AspNetCore.Cryptography.KeyDerivation zapewnia implementację procedury tworzenia skrótów haseł PBKDF2 i może być używana przez systemy, które muszą bezpiecznie obsługiwać hasła użytkowników. Aby uzyskać więcej informacji, zobacz Hash passwords in ASP.NET Core (Haszowanie haseł w ASP.NET Core).