Konfigurowanie funkcji Bring your own key (BYOK)

  • 7 min

Scenariusz

Klient usługi Key Vault chce bezpiecznie przenieść klucz z lokalnego sprzętowego modułu zabezpieczeń (HSM) spoza platformy Azure do modułu HSM, który wspiera usługę Azure Key Vault. Proces importowania klucza wygenerowanego poza usługą Key Vault jest określany jako Bring Your Own Key (BYOK).

Poniżej przedstawiono wymagania:

  • Klucz, który ma zostać przeniesiony, nigdy nie istnieje poza modułem HSM w postaci zwykłego tekstu.
  • Poza modułem HSM klucz, który ma zostać przeniesiony, jest zawsze chroniony przez klucz przechowywany w module HSM usługi Azure Key Vault.

Terminologia

Nazwa klucza Typ klucza Źródło Opis
Klucz wymiany kluczy (KEK) RSA Karta HSM usługi Azure Key Vault Para kluczy RSA z obsługą modułu HSM wygenerowana w usłudze Azure Key Vault
Klucz zawijania AES Moduł HSM dostawcy [efemeryczne] Klucz AES wygenerowany przez lokalny moduł HSM
Klucz docelowy RSA, EC, AES (tylko zarządzany moduł HSM) Moduł HSM dostawcy Klucz, który ma zostać przeniesiony do modułu HSM usługi Azure Key Vault

Klucz wymiany kluczy (KEK): jest to klucz oparty na module HSM generowany przez klienta w magazynie kluczy przeznaczonym do importowania klucza BYOK (Bring Your Own Key). Klucz KEK powinien mieć następujące właściwości:

  • Musi to być klucz RSA-HSM o rozmiarze 4096-bitowym, 3072-bitowym lub 2048-bitowym.
  • Jego kluczowe operacje (key_ops) są ograniczone do "importu", co pozwala na korzystanie wyłącznie z niego podczas procesu BYOK.
  • Musi znajdować się w tym samym magazynie, w którym ma zostać zaimportowany klucz docelowy.

Kroki użytkownika

Aby wykonać transfer klucza:

  1. Generowanie klucza KEK.
  2. Pobierz klucz publiczny klucza KEK.
  3. Za pomocą dostawcy modułu HSM dostarczonego przez narzędzie BYOK zaimportuj klucz KEK do docelowego modułu HSM i eksportuje klucz docelowy chroniony przez klucz KEK.
  4. Zaimportuj chroniony klucz docelowy do usługi Azure Key Vault.

Klienci używają narzędzia BYOK i dokumentacji dostarczonej przez dostawcę modułu HSM, aby wykonać kroki 3. Tworzy obiekt blob transferu kluczy (plik ".byok").

Ograniczenia modułu HSM

Istniejący moduł HSM może stosować ograniczenia dotyczące klucza, którymi zarządzają, w tym:

  • Może być konieczne skonfigurowanie modułu HSM w celu zezwolenia na eksportowanie oparte na zawijanie kluczy
  • Może być konieczne oznaczenie klucza docelowego atrybutu Cryptoki (CKA)_EXTRACTABLE dla modułu HSM w celu umożliwienia kontrolowanego eksportu
  • W niektórych przypadkach klucz KEK i klucz opakowujące mogą być oznaczone jako CKA_TRUSTED, co umożliwia jego użycie do opakowowania kluczy w module HSM.

Konfiguracja źródłowego modułu HSM jest ogólnie spoza zakresu tej specyfikacji. Firma Microsoft oczekuje, że dostawca modułu HSM utworzy dokumentację dołączącą do narzędzia BYOK, aby uwzględnił wszelkie takie kroki konfiguracji.

Uwaga

Kilka z tych kroków można wykonać przy użyciu innych interfejsów, takich jak program Azure PowerShell i witryna Azure Portal. Można je również wykonywać programowo przy użyciu równoważnych funkcji w zestawie SDK usługi Key Vault.

Generowanie klucza KEK

Użyj polecenia az keyvault key create, aby utworzyć klucz KEK z kluczami ustawionymi na import. Zanotuj identyfikator klucza "kid" zwrócony z poniższego polecenia.

az keyvault key create --kty RSA-HSM --size 4096 --name KEKforBYOK --ops import --vault-name ContosoKeyVaultHSM

Usługi obsługują różne długości klucza KEK; Na przykład usługa Azure SQL obsługuje tylko długości kluczy 2048 lub 3072 bajtów.

Pobieranie klucza publicznego klucza szyfrowania kluczy

Pobierz część klucza publicznego klucza kluczy publicznych i zapisz ją w pliku PEM.

az keyvault key download --name KEKforBYOK --vault-name ContosoKeyVaultHSM --file KEKforBYOK.publickey.pem

Generowanie obiektu blob transferu kluczy przy użyciu dostawcy modułu HSM dostarczonego przez narzędzie BYOK

Użyj dostawcy modułu HSM dostarczonego przez narzędzie BYOK, aby utworzyć obiekt blob transferu kluczy (przechowywany jako plik ".byok"). Klucz publiczny KEK jako . Privacy-Enhanced Mail (plik pem) będzie jednym z danych wejściowych tego narzędzia.

Obiekt blob transferu kluczy

W dłuższej perspektywie firma Microsoft chce użyć mechanizmu PKCS#11 CKM_RSA_AES_KEY_WRAP w celu przeniesienia klucza docelowego do usługi Azure Key Vault, ponieważ ten mechanizm tworzy pojedynczy obiekt blob, a co ważniejsze, pośredni klucz AES jest obsługiwany przez dwa moduły HSM i ma gwarancję efemerycznego. Ten mechanizm nie jest obecnie dostępny w niektórych modułach HSM, ale kombinacja ochrony klucza docelowego przy użyciu CKM_AES_KEY_WRAP_PAD przy użyciu klucza AES i ochrony klucza AES za pomocą CKM_RSA_PKCS_OAEP tworzy równoważny obiekt blob.

Klucz docelowy w postaci zwykłego tekstu zależy od typu klucza:

  • W przypadku klucza RSA kodowanie ASN.1 DER klucza prywatnego [RFC3447] opakowane w PKCS#8 [RFC5208]
  • W przypadku klucza EC kodowanie ASN.1 DER klucza prywatnego [RFC5915] opakowane w PKCS#8 [RFC5208]
  • W przypadku klucza oktetu nieprzetworzone bajty klucza

Bajty klucza zwykłego tekstu są następnie przekształcane przy użyciu mechanizmu CKM_RSA_AES_KEY_WRAP:

  • Efemeryczny klucz AES jest generowany i szyfrowany za pomocą opakowującego klucza RSA przy użyciu protokołu RSA-OAEP z algorytmem SHA1.
  • Zakodowany klucz zwykłego tekstu jest szyfrowany przy użyciu klucza AES przy użyciu zawijania klucza AES z wypełnieniem.
  • Zaszyfrowany klucz AES i zaszyfrowany klucz zwykłego tekstu są łączone w celu utworzenia końcowego obiektu blob szyfrowania.

Format transferu obiektu blob używa kompaktowej serializacji JSON Web Encryption (RFC7516) głównie jako pojazdu do dostarczania wymaganych metadanych do usługi w celu poprawnego odszyfrowywania.