ASP.NET Core Data Protection — omówienie

  • Artykuł

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

Aplikacje internetowe często muszą przechowywać dane poufne zabezpieczeń. System Windows udostępnia interfejs API ochrony danych, DPAPI, ale interfejs DPAPI systemu Windows nie jest przeznaczony do użycia w aplikacjach internetowych.

Stos ochrony danych ASP.NET Core jest przeznaczony do obsługi długoterminowego zastąpienia <elementu machineKey> w ASP.NET 1.x - 4.x. Został zaprojektowany tak, aby rozwiązać wiele niedociągnięć starego stosu kryptograficznego, zapewniając gotowe rozwiązanie dla większości przypadków użycia nowoczesnych aplikacji może napotkać.

Opis problemu

Ogólną instrukcję problemu można zwięźle stwierdzić w jednym zdaniu: Muszę utrwalać zaufane informacje na potrzeby późniejszego pobierania, ale nie ufam mechanizmowi trwałości. W kategoriach internetowych może to być napisane jako "Muszę zaokrąglić zaufany stan za pośrednictwem niezaufanego klienta.

Przykładem kanonicznym jest uwierzytelnianie cookie lub token elementu nośnego. Serwer generuje token "I am Groot and have xyz permissions" (Mam uprawnienia Xyz) i przekazuje go klientowi. W przyszłości klient przedstawi ten token z powrotem na serwerze, ale serwer potrzebuje pewnego rodzaju pewności, że klient nie sfałszował tokenu. W związku z tym pierwsze wymaganie: autentyczność (tj. integralność, weryfikacja manipulacji).

Ponieważ stan utrwalone jest zaufany przez serwer, przewidujemy, że ten stan może zawierać informacje specyficzne dla środowiska operacyjnego. Może to być w postaci ścieżki pliku, uprawnienia, dojścia lub innego odwołania pośredniego lub innego elementu danych specyficznych dla serwera. Takie informacje nie powinny być ogólnie ujawniane niezaufanym klientowi. W związku z tym drugie wymaganie: poufność.

Na koniec, ponieważ nowoczesne aplikacje są kom składowane, widać, że poszczególne składniki będą chciały korzystać z tego systemu bez względu na inne składniki w systemie. Na przykład jeśli składnik tokenu elementu nośnego korzysta z tego stosu, powinien działać bez ingerencji mechanizmu anty-CSRF, który może również używać tego samego stosu. W związku z tym ostateczne wymaganie: izolacja.

Możemy zapewnić dalsze ograniczenia, aby zawęzić zakres naszych wymagań. Zakładamy, że wszystkie usługi działające w systemie kryptograficznym są równie zaufane i że dane nie muszą być generowane ani używane poza usługami pod naszą bezpośrednią kontrolą. Ponadto wymagamy, aby operacje przebiegały tak szybko, jak to możliwe, ponieważ każde żądanie do usługi internetowej może przechodzić przez system kryptograficzny co najmniej raz. Dzięki temu kryptografia symetryczna jest idealna dla naszego scenariusza i możemy zdyskontować kryptografię asymetryczną, dopóki nie będzie to potrzebne.

Filozofia projektowania

Zaczęliśmy od identyfikowania problemów z istniejącym stosem. Kiedy to zrobiliśmy, zbadaliśmy krajobraz istniejących rozwiązań i doszliśmy do wniosku, że żadne istniejące rozwiązanie nie miało możliwości, których szukaliśmy. Następnie zaprojektowaliśmy rozwiązanie na podstawie kilku wytycznych.

  • System powinien oferować prostotę konfiguracji. W idealnym przypadku system byłby zerową konfiguracją, a deweloperzy mogli uderzyć w działanie. W sytuacjach, w których deweloperzy muszą skonfigurować określony aspekt (taki jak repozytorium kluczy), należy wziąć pod uwagę, aby te konkretne konfiguracje były proste.

  • Oferowanie prostego interfejsu API dostępnego dla konsumentów. Interfejsy API powinny być łatwe do poprawnego użycia i trudne do nieprawidłowego użycia.

  • Deweloperzy nie powinni uczyć się kluczowych zasad zarządzania. System powinien obsługiwać wybór algorytmu i okres istnienia klucza w imieniu dewelopera. Najlepiej, aby deweloper nigdy nawet nie miał dostępu do surowca.

  • Klucze powinny być chronione w spoczynku, jeśli jest to możliwe. System powinien ustalić odpowiedni domyślny mechanizm ochrony i zastosować go automatycznie.

Mając na uwadze te zasady, opracowaliśmy prosty, łatwy w użyciu stos ochrony danych.

Podstawowe interfejsy API ochrony danych ASP.NET 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 bezterminowego i mają odpowiednio silne możliwości zarządzania kluczami. Oznacza to, że deweloper nie może używać interfejsów API ochrony danych ASP.NET Core w celu długoterminowej ochrony poufnych danych.

Odbiorcy

System ochrony danych jest podzielony na pięć głównych pakietów. Różne aspekty tych interfejsów API dotyczą trzech głównych odbiorców;

  1. Interfejsy API konsumentów — omówienie aplikacji docelowej i deweloperów platform.

    "Nie chcę dowiedzieć się, jak działa stos lub jak jest skonfigurowany. Chcę po prostu wykonać jakąś operację w najprostszy sposób, jak to możliwe z wysokim prawdopodobieństwem korzystania z interfejsów API pomyślnie."

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

    "Muszę 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 byłoby ograniczone do rzadkich sytuacji i doświadczonych, świadomych zabezpieczeń deweloperów.

    "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