Zarządzanie kluczami ochrony danych i okres istnienia w programie ASP.NET Core

  • Artykuł

Autor: Rick Anderson

Zarządzanie kluczami

Aplikacja próbuje wykryć swoje środowisko operacyjne i samodzielnie obsłużyć konfigurację klucza.

  1. Jeśli aplikacja jest hostowana w aplikacja systemu Azure, klucze są utrwalane w folderze %HOME%\ASP.NET\DataProtection-Keys. Ten folder jest oparty na magazynie sieciowym i synchronizowany na wszystkich maszynach hostujących aplikację.

    • Klucze nie są chronione podczas przechowywania.
    • Folder DataProtection-Keys dostarcza pierścień kluczy do wszystkich wystąpień aplikacji w jednym miejscu wdrożenia.
    • Oddzielne miejsca wdrożenia, takie jak środowisko przejściowe i produkcyjne, nie mają wspólnego pierścienia kluczy. Podczas zamiany między miejscami wdrożenia, na przykład zamiana przejściowego na środowisko produkcyjne lub przy użyciu testowania A/B, każda aplikacja korzystająca z usługi Data Protection nie będzie mogła odszyfrować przechowywanych danych przy użyciu pierścienia kluczy wewnątrz poprzedniego miejsca. Prowadzi to do wylogowania użytkowników z aplikacji korzystającej ze standardowego uwierzytelniania ASP.NET Core cookie , ponieważ używa ochrony danych w celu ochrony swoich cookieelementów. Jeśli chcesz użyć pierścieni kluczy niezależnych od miejsca, użyj zewnętrznego dostawcy pierścienia kluczy, takiego jak Azure Blob Storage, Azure Key Vault, magazyn SQL lub pamięć podręczna Redis Cache.

  2. Jeśli profil użytkownika jest dostępny, klucze są utrwalane w folderze %LOCALAPPDATA%\ASP.NET\DataProtection-Keys . Jeśli system operacyjny to Windows, klucze są szyfrowane w spoczynku przy użyciu interfejsu DPAPI.

    Należy również włączyć atrybut setProfileEnvironment puli aplikacji. Wartość domyślna setProfileEnvironment to true. W niektórych scenariuszach (na przykład systemu operacyjnego Windows) opcja setProfileEnvironment jest ustawiona na wartość false. Jeśli klucze nie są przechowywane w katalogu profilu użytkownika zgodnie z oczekiwaniami:

    1. Przejdź do folderu %windir%/system32/inetsrv/config.
    2. Otwórz plik applicationHost.config.
    3. Znajdź element <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
    4. Upewnij się, że atrybut setProfileEnvironment nie występuje, co powoduje, że wartość domyślnie staje się równa true, lub jawnie ustaw wartość atrybutu na true.

  3. Jeśli aplikacja jest hostowana w usługach IIS, klucze są utrwalane w rejestrze HKLM w specjalnym kluczu rejestru, który jest acLed tylko do konta procesu roboczego. Klucze są szyfrowane w spoczynku przy użyciu interfejsu DPAPI.

  4. Jeśli żaden z tych warunków nie jest zgodny, klucze nie są utrwalane poza bieżącym procesem. Po zamknięciu procesu wszystkie wygenerowane klucze zostaną utracone.

Deweloper jest zawsze w pełnej kontroli i może zastąpić sposób i miejsce przechowywania kluczy. Pierwsze trzy powyższe opcje powinny zapewnić dobre wartości domyślne dla większości aplikacji podobnych do tego, jak w przeszłości działały procedury automatycznego generowania klawiszy machineKey> ASP.NET<. Ostatnia opcja rezerwowa jest jedynym scenariuszem, który wymaga od dewelopera określenia konfiguracji z góry, jeśli chce mieć kluczową trwałość, ale ta rezerwa występuje tylko w rzadkich sytuacjach.

W przypadku hostowania w kontenerze platformy Docker klucze powinny być utrwalane w folderze, który jest woluminem platformy Docker (woluminem udostępnionym lub woluminem zainstalowanym na hoście, który utrzymuje się poza okresem istnienia kontenera) lub dostawcą zewnętrznym, takim jak usługa Azure Key Vault lub redis. Dostawca zewnętrzny jest również przydatny w scenariuszach farmy internetowej, jeśli aplikacje nie mogą uzyskać dostępu do udostępnionego woluminu sieciowego (zobacz PersistKeysToFileSystem , aby uzyskać więcej informacji).

Ostrzeżenie

Jeśli deweloper zastąpi reguły opisane powyżej i wskazuje system ochrony danych w określonym repozytorium kluczy, automatyczne szyfrowanie kluczy magazynowanych jest wyłączone. Ochronę w spoczynku można ponownie włączyć za pomocą konfiguracji.

Okres istnienia klucza

Klucze mają domyślnie okres istnienia 90 dni. Po wygaśnięciu klucza aplikacja automatycznie generuje nowy klucz i ustawia nowy klucz jako aktywny klucz. Jeśli klucze wycofane pozostaną w systemie, aplikacja może odszyfrować wszystkie dane chronione przy użyciu tych kluczy. Aby uzyskać więcej informacji, zobacz zarządzanie kluczami .

Algorytmy domyślne

Domyślny używany algorytm ochrony ładunku to AES-256-CBC na potrzeby poufności i HMACSHA256 dla autentyczności. 512-bitowy klucz główny, zmieniany co 90 dni, służy do uzyskiwania dwóch kluczy podrzędnych używanych dla tych algorytmów na podstawie ładunku. Aby uzyskać więcej informacji, zobacz wyprowadzanie podklucza.

Dodatkowe zasoby