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

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 w usłudze rest.
   • 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ż chroni pliki cookie przy użyciu ochrony danych. 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 przy rest 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 przy użyciu interfejsu rest 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 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 rest w lokalizacji jest wyłączone. Ochrona at-rest 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.

Usuwanie kluczy

Usunięcie klucza sprawia, że jego chronione dane są trwale niedostępne. Aby ograniczyć to ryzyko, zalecamy, aby nie usuwać kluczy. Wynikowa akumulacja kluczy zwykle ma minimalny wpływ, ponieważ są małe. W wyjątkowych przypadkach, takich jak niezwykle długotrwałe usługi, można usunąć klucze. Usuń tylko klucze:

• To jest stare (nie jest już używane).
• Kiedy można zaakceptować ryzyko utraty danych w zamian za oszczędności magazynu.

Nie zalecamy usuwania kluczy ochrony danych.

using Microsoft.AspNetCore.DataProtection.KeyManagement;

var services = new ServiceCollection();
services.AddDataProtection();

var serviceProvider = services.BuildServiceProvider();

var keyManager = serviceProvider.GetService<IKeyManager>();

if (keyManager is IDeletableKeyManager deletableKeyManager)
{
    var utcNow = DateTimeOffset.UtcNow;
    var yearAgo = utcNow.AddYears(-1);

    if (!deletableKeyManager.DeleteKeys(key => key.ExpirationDate < yearAgo))
    {
        Console.WriteLine("Failed to delete keys.");
    }
    else
    {
        Console.WriteLine("Old keys deleted successfully.");
    }
}
else
{
    Console.WriteLine("Key manager does not support deletion.");
}

Dodatkowe zasoby

• Rozszerzalność zarządzania kluczami w programie ASP.NET Core
• Hostowanie aplikacji ASP.NET Core na farmie internetowej