omówienie ASP.NET Core Data Protection

  • Artykuł
  • Czas czytania: 4 min

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

Aplikacje internetowe często muszą przechowywać dane wrażliwe na zabezpieczenia. Windows udostępnia interfejs API ochrony danych DPAPI, ale Windows DPAPI nie jest przeznaczony do użycia w aplikacjach internetowych.

Stos ASP.NET Core ochrony <danych służy jako długoterminowe zastąpienie elementu machineKey> w programie ASP.NET 1.x–4.x. Został on zaprojektowany z myślą o rozwiązaniu wielu wad starego stosu kryptograficznego przy jednoczesnym zapewnieniu rozwiązania out-of-the-box dla większości przypadków użycia, które mogą napotkać nowoczesne aplikacje.

Opis problemu

Ogólne stwierdzenie problemu można zwięźle określić w jednym zdaniu: Chcę utrwalić zaufane informacje do późniejszego pobrania, ale nie ufam mechanizmowi trwałości. W kontekście internetowym może to być napisane jako "I need to round-trip trusted state via an untrusted client" (Muszę rundy stan zaufany za pośrednictwem niezaufanego klienta).

Kanonicznym przykładem jest token cookie uwierzytelniania lub element bearer. Serwer generuje token "Jestem Groot i mam uprawnienia xyz" i wydaje go klientowi. W przyszłości klient przedstawi ten token serwerowi, ale serwer wymaga pewnego rodzaju gwarancji, że klient nie podszył się pod token. W związku z tym pierwsze wymaganie: autentyczność (integralność, zabezpieczenie przed naruszeniami).

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

Wreszcie, ponieważ nowoczesne aplikacje są zeskładowe, zobaczyliśmy, że poszczególne składniki będą chciały korzystać z tego systemu bez względu na inne składniki w systemie. Jeśli na przykład składnik tokenu elementu bearer korzysta z tego stosu, powinien działać bez zakłóceń w mechanizmie anty CSRF, który może również używać tego samego stosu. W związku z tym ostateczne wymaganie: izolacja.

Możemy zapewnić dodatkowe ograniczenia, aby zawęzić zakres naszych wymagań. Zakładamy, że wszystkie usługi działające w ramach systemu kryptograficznego są równie zaufane i że dane nie muszą być generowane ani wykorzystywane poza usługami, które są pod naszą bezpośrednią kontrolą. Ponadto wymagamy, aby operacje wykonywane było tak szybko, jak to możliwe, ponieważ każde żądanie do usługi internetowej może przechodzić przez system kryptograficzny co najmniej jeden raz. Dzięki temu kryptografia symetryczna jest idealna dla naszego scenariusza, a kryptografię asymetryczną można dyskontować do takiego czasu, jaki jest potrzebny.

Projektowanie podejścia

Rozpoczęliśmy od zidentyfikowania problemów z istniejącym stosem. Gdy już to zrobiliśmy, sprawdziliśmy krajobraz istniejących rozwiązań i doszliśmy do wniosku, że żadne istniejące rozwiązanie nie ma jeszcze możliwości, których szukaliśmy. Następnie z myślą o rozwiązaniu schowaliśmy kilka wytycznych.

  • System powinien oferować prostotę konfiguracji. Najlepiej, aby system nie miał konfiguracji zerowej, a deweloperzy mogli trafić na powierzchnię. W sytuacjach, w których deweloperzy muszą skonfigurować określony aspekt (na przykład repozytorium kluczy), należy wziąć pod uwagę, że te konkretne konfiguracje są proste.

  • Zaoferuj prosty interfejs API dla klientów. Interfejsy API powinny być łatwe w użyciu prawidłowo i trudne do niepoprawnego 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. W idealnym przypadku deweloper nigdy nie powinien mieć nawet dostępu do nieprzetworznego materiału klucza.

  • Klucze powinny być chronione w spoczynku, gdy 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.

Interfejsy API ASP.NET Core ochrony danych nie są przeznaczone głównie do nieograniczonej trwałości poufnych ładunków. Inne technologie, takie jak Windows CNG DPAPI i Azure Rights Management, są bardziej odpowiednie do scenariusza nieokreślonych magazynów i mają odpowiednio silne możliwości zarządzania kluczami. Nie ma jednak nic, co zabrania deweloperowi używania interfejsów API ochrony danych ASP.NET Core do długoterminowej ochrony poufnych danych.

Grupy odbiorców

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

  1. Przegląd interfejsów API dla konsumentów jest ukierunkowany na deweloperów aplikacji i platform.

    "Nie chcę się dowiedzieć, jak działa stos ani jak jest skonfigurowany. Chcę po prostu wykonać jak najprościej operację z dużym prawdopodobieństwem pomyślnego użycia interfejsów API".

  2. Interfejsy API konfiguracji są kierowane do deweloperów aplikacji i administratorów systemu.

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

  3. Interfejsy API rozszerzalności są kierowane do deweloperów odpowiedzialnych za implementowanie 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 dotyczące zachowania. Chcę poznać rzadko używane części powierzchni interfejsu API w celu skompilowania wtyczki, która spełnia moje wymagania".

Układ pakietu

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

Dodatkowe zasoby