Steg 2: Migrering av programvaruskyddad nyckel till HSM-skyddad nyckel

  • Artikel

De här instruktionerna är en del av migreringsvägen från AD RMS till Azure Information Protection och gäller endast om din AD RMS-nyckel är programvaruskyddad och du vill migrera till Azure Information Protection med en HSM-skyddad klientnyckel i Azure Key Vault.

Om detta inte är det valda konfigurationsscenariot går du tillbaka till steg 4. Exportera konfigurationsdata från AD RMS och importera dem till Azure RMS och välj en annan konfiguration.

Det är en fyradelad procedur för att importera AD RMS-konfigurationen till Azure Information Protection för att resultera i din Azure Information Protection-klientnyckel som hanteras av dig (BYOK) i Azure Key Vault.

Du måste först extrahera din SLC-nyckel (Server Licensor Certificate) från AD RMS-konfigurationsdata och överföra nyckeln till en lokal nCipher HSM, nästa paket och överföra din HSM-nyckel till Azure Key Vault, sedan auktorisera Azure Rights Management-tjänsten från Azure Information Protection för att få åtkomst till ditt nyckelvalv och sedan importera konfigurationsdata.

Eftersom din Azure Information Protection-klientnyckel lagras och hanteras av Azure Key Vault kräver den här delen av migreringen administration i Azure Key Vault, utöver Azure Information Protection. Om Azure Key Vault hanteras av en annan administratör än du för din organisation måste du samordna och samarbeta med administratören för att slutföra dessa procedurer.

Innan du börjar kontrollerar du att din organisation har ett nyckelvalv som har skapats i Azure Key Vault och att den har stöd för HSM-skyddade nycklar. Även om det inte krävs rekommenderar vi att du har ett dedikerat nyckelvalv för Azure Information Protection. Det här nyckelvalvet konfigureras så att Azure Rights Management-tjänsten från Azure Information Protection kan komma åt det, så nycklarna som nyckelvalvet lagrar bör begränsas till endast Azure Information Protection-nycklar.

Dricks

Om du utför konfigurationsstegen för Azure Key Vault och du inte är bekant med den här Azure-tjänsten kan det vara bra att först granska Komma igång med Azure Key Vault.

Del 1: Extrahera din SLC-nyckel från konfigurationsdata och importera nyckeln till din lokala HSM

  1. Azure Key Vault-administratör: För varje exporterad SLC-nyckel som du vill lagra i Azure Key Vault använder du följande steg i avsnittet Implementera BYOK (Bring Your Own Key) för Azure Key Vault i Azure Key Vault-dokumentationen:

    Följ inte stegen för att generera klientnyckeln eftersom du redan har motsvarande i den exporterade konfigurationsdatafilen (.xml). I stället kör du ett verktyg för att extrahera den här nyckeln från filen och importera den till din lokala HSM. Verktyget skapar två filer när du kör det:

    • En ny konfigurationsdatafil utan nyckeln, som sedan är redo att importeras till din Azure Information Protection-klientorganisation.

    • En PEM-fil (nyckelcontainer) med nyckeln, som sedan är redo att importeras till din lokala HSM.

  2. Azure Information Protection-administratör eller Azure Key Vault-administratör: Kör TpdUtil-verktyget från Azure RMS-migreringsverktyget på den frånkopplade arbetsstationen. Om verktyget till exempel är installerat på din E-enhet där du kopierar konfigurationsdatafilen med namnet ContosoTPD.xml:

    E:\TpdUtil.exe /tpd:ContosoTPD.xml /otpd:ContosoTPD.xml /opem:ContosoTPD.pem

    Om du har fler än en RMS-konfigurationsdatafil kör du det här verktyget för resten av dessa filer.

    Om du vill se Hjälp för det här verktyget, som innehåller en beskrivning, användning och exempel, kör du TpdUtil.exe utan parametrar

    Ytterligare information för det här kommandot:

    • / tpd: anger den fullständiga sökvägen och namnet på den exporterade AD RMS-konfigurationsdatafilen. Det fullständiga parameternamnet är TpdFilePath.

    • /otpd: anger utdatafilens namn för konfigurationsdatafilen utan nyckeln. Det fullständiga parameternamnet är OutPfxFile. Om du inte anger den här parametern är utdatafilen standard för det ursprungliga filnamnet med suffixet _keyless och lagras i den aktuella mappen.

    • / opem: anger namnet på utdatafilen för PEM-filen, som innehåller den extraherade nyckeln. Det fullständiga parameternamnet är OutPemFile. Om du inte anger den här parametern är utdatafilen standard för det ursprungliga filnamnet med suffixet _key och lagras i den aktuella mappen.

    • Om du inte anger lösenordet när du kör det här kommandot (med hjälp av det fullständiga parameternamnet TpdPassword eller pwd short parameter name) uppmanas du att ange det.

  3. På samma frånkopplade arbetsstation ansluter och konfigurerar du din nCipher HSM enligt din nCipher-dokumentation. Nu kan du importera nyckeln till din anslutna nCipher HSM med hjälp av följande kommando där du behöver ersätta ditt eget filnamn med ContosoTPD.pem:

    generatekey --import simple pemreadfile=e:\ContosoTPD.pem plainname=ContosoBYOK protect=module ident=contosobyok type=RSA

    Kommentar

    Om du har fler än en fil väljer du den fil som motsvarar den HSM-nyckel som du vill använda i Azure RMS för att skydda innehåll efter migreringen.

    Detta genererar en utdatavisning som liknar följande:

    nyckelgenereringsparametrar:

    åtgärdsåtgärd för att utföra import

    application Application simple

    verifiera verifiera säkerheten för konfigurationsnyckeln ja

    typ Nyckeltyp RSA

    pemreadfile PEM-fil som innehåller RSA-nyckel e:\ContosoTPD.pem

    ident-nyckelidentifierare contosobyok

    plainname Nyckelnamn ContosoBYOK

    Nyckeln har importerats.

    Sökväg till nyckel: C:\ProgramData\nCipher\Key Management Data\local\key_simple_contosobyok

Det här resultatet bekräftar att den privata nyckeln nu migreras till din lokala nCipher HSM-enhet med en krypterad kopia som sparas till en nyckel (i vårt exempel "key_simple_contosobyok").

Nu när din SLC-nyckel har extraherats och importerats till din lokala HSM är du redo att paketera den HSM-skyddade nyckeln och överföra den till Azure Key Vault.

Viktigt!

När du har slutfört det här steget kan du på ett säkert sätt radera dessa PEM-filer från den frånkopplade arbetsstationen för att säkerställa att de inte kan nås av obehöriga personer. Kör till exempel "chiffer /w: E" för att på ett säkert sätt ta bort alla filer från E:-enheten.

Del 2: Paketera och överföra din HSM-nyckel till Azure Key Vault

Azure Key Vault-administratör: För varje exporterad SLC-nyckel som du vill lagra i Azure Key Vault använder du följande steg i avsnittet Implementera BYOK (Bring Your Own Key) för Azure Key Vault i Azure Key Vault-dokumentationen:

Följ inte stegen för att generera nyckelparet eftersom du redan har nyckeln. I stället kör du ett kommando för att överföra den här nyckeln (i vårt exempel använder vår KeyIdentifier-parameter "contosobyok") från din lokala HSM.

Innan du överför nyckeln till Azure Key Vault kontrollerar du att verktyget KeyTransferRemote.exe returnerar Result: SUCCESS när du skapar en kopia av nyckeln med nedsatt behörighet (steg 4.1) och när du krypterar nyckeln (steg 4.3).

När nyckeln laddas upp till Azure Key Vault visas egenskaperna för nyckeln, som innehåller nyckel-ID:t. Det ser ut ungefär som https://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333. Anteckna den här URL:en eftersom Azure Information Protection-administratören behöver den för att be Azure Rights Management-tjänsten från Azure Information Protection att använda den här nyckeln för sin klientnyckel.

Använd sedan cmdleten Set-AzKeyVaultAccessPolicy för att ge Azure Rights Management-tjänstens huvudnamn åtkomst till nyckelvalvet. De behörigheter som krävs är dekryptera, kryptera, unwrapkey, wrapkey, verify och sign.

Om nyckelvalvet som du har skapat för Azure Information Protection till exempel heter contosorms-byok-kv och resursgruppen heter contosorms-byok-rg kör du följande kommando:

Set-AzKeyVaultAccessPolicy -VaultName "contosorms-byok-kv" -ResourceGroupName "contosorms-byok-rg" -ServicePrincipalName 00000012-0000-0000-c000-000000000000 -PermissionsToKeys decrypt,encrypt,unwrapkey,wrapkey,verify,sign,get

Nu när du har överfört din HSM-nyckel till Azure Key Vault är du redo att importera AD RMS-konfigurationsdata.

Del 3: Importera konfigurationsdata till Azure Information Protection

  1. Azure Information Protection-administratör: På den Internetanslutna arbetsstationen och i PowerShell-sessionen kopierar du över dina nya konfigurationsdatafiler (.xml) som tar bort SLC-nyckeln när du har kört TpdUtil-verktyget.

  2. Ladda upp varje .xml-fil med hjälp av cmdleten Import-AipServiceTpd . Du bör till exempel ha minst en ytterligare fil att importera om du har uppgraderat DITT AD RMS-kluster för kryptografiskt läge 2.

    Om du vill köra den här cmdleten behöver du lösenordet som du angav tidigare för konfigurationsdatafilen och URL:en för nyckeln som identifierades i föregående steg.

    Om du till exempel använder en konfigurationsdatafil med C:\contoso_keyless.xml och nyckel-URL-värdet från föregående steg kör du först följande för att lagra lösenordet:

     $TPD_Password = Read-Host -AsSecureString

    Ange det lösenord som du angav för att exportera konfigurationsdatafilen. Kör sedan följande kommando och bekräfta att du vill utföra den här åtgärden:

    Import-AipServiceTpd -TpdFile "C:\contoso_keyless.xml" -ProtectionPassword $TPD_Password –KeyVaultStringUrl https://contoso-byok-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333 -Verbose

    Som en del av den här importen importeras SLC-nyckeln och anges automatiskt som arkiverad.

  3. När du har laddat upp varje fil kör du Set-AipServiceKeyProperties för att ange vilken importerad nyckel som matchar den aktiva SLC-nyckeln i DITT AD RMS-kluster.

  4. Använd cmdleten Disconnect-AipServiceService för att koppla från Azure Rights Management-tjänsten:

    Disconnect-AipServiceService

Om du senare behöver bekräfta vilken nyckel din Azure Information Protection-klientnyckel använder i Azure Key Vault använder du Cmdleten Get-AipServiceKeys Azure RMS.

Nu är du redo att gå till steg 5. Aktivera Azure Rights Management-tjänsten.