Steg 2: Programvaruskyddad nyckel för migrering av HSM-skyddade nycklar

Gäller för:Active Directory Rights Management Services, Azure Information Protection

Relevant för:AIP unified labeling client and classic client

Obs!

För att ge en enhetlig och smidig kundupplevelse är den klassiska Azure Information Protection-klienten och Etiketthantering i Azure-portalen inaktuella sedan den 31 mars 2021. Inget ytterligare stöd tillhandahålls för den klassiska klienten och underhållsversioner kommer inte längre att släppas.

Den klassiska klienten upphör officiellt och slutar fungera den 31 mars 2022.

Alla aktuella kunder med Azure Information Protection för klassiska klienter måste migrera till Microsoft Information Protection unified labeling-plattformen och uppgradera till den enhetliga etikettklienten. Läs mer i vår migreringsblogg.

De här instruktionerna ingår i migreringsvägen från AD RMStill Azure Information Protection och gäller endast om AD RMS-nyckeln är programvaruskyddad och du vill migrera till Azure Information Protection med en HSM-skyddad klientnyckel i Azure-nyckelvalv.

Om det här inte är ditt konfigurationsscenario 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 procedur i fyra delar om du vill importera AD RMS-konfigurationen till Azure Information Protection, så att klientnyckeln för Azure Information Protection resulterar i att du (BYOK) hanteras av dig (BYOK) i Azure-nyckelvalv.

Du måste först extrahera din serverlicensorcertifikatnyckel (SLC) 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 komma åt 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-nyckelvalv hanteras av en annan administratör än du för din organisation måste du samordna och arbeta med den administratören för att slutföra de här procedurerna.

Innan du börjar kontrollerar du att din organisation har ett nyckelvalv som har skapats i Azure Key Vault och att det 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 för att tillåta Azure Rights Management-tjänsten från Azure Information Protection att komma åt det, så knapparna som lagras i det här nyckelvalvet ska vara begränsade till endast Azure Information Protection-nycklar.

Tips!

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 läsa Komma igång med Azure Key Vault.

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

  1. Azure-nyckelvalvsadministratör: För varje exporterad SNYCKEL-nyckel som du vill lagra i Azure-nyckelvalv följer du stegen i avsnittet Implementera bring your own key (BYOK) för Azure Key Vault i dokumentationen för Azure Key Vault:

    Följ inte anvisningarna för att generera din klientnyckel eftersom du redan har motsvarigheten i den exporterade konfigurationsdatafilen (.xml). I stället kör du ett verktyg för att extrahera nyckeln från filen och importera den till din lokala HSM. När du kör verktyget skapas två filer:

    • En ny konfigurationsdatafil utan nyckel, som sedan är klar att importeras till Azure Information Protection-klienten.

    • En PEM-fil (nyckelbehållare) med nyckeln, som sedan är klar att importeras till din lokala HSM.

  2. Azure Information Protection-administratör eller Azure Key Vault-administratör: På den frånkopplade arbetsstationen kör du verktyget TpdUtil från Azure RMS-migreringsverktyget. 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 filerna.

    Om du vill ha hjälp med 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 exporterade AD RMS-konfigurationsdatafilens fullständiga sökväg och namn. 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 används det ursprungliga filnamnet som standard i utdatafilen med suffixet _keylessoch det lagras i den aktuella mappen.

    • /opem: anger utdatafilens namn för PEM-filen, som innehåller den extraherade nyckeln. Det fullständiga parameternamnet är OutPemFile. Om du inte anger den här parametern används det ursprungliga filnamnet som standard i utdatafilen med suffixet _keysom 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 parameternamn) uppmanas du att ange det.

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

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

    Obs!

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

    Då genereras en utdataskärm som liknar följande:

    viktiga genereringsparametrar:

    åtgärdsåtgärd för import

    application simple

    verifiera säkerhet för konfigurationsnyckeln ja

    typ Nyckeltyp RSA

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

    ident Key identifier contosobyok

    plainname Key name ContosoBYOK

    Nyckeln har importerats.

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

Dessa utdata 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 SLC-nyckeln 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 säkert ta bort alla filer från E:-enheten.

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

Azure-nyckelvalvsadministratör: Använd följande steg för implementeringen av din egen nyckel (BYOK) för Azure-nyckelvalv för varje exporterad SNYCKEL-nyckel som du vill lagra i Azure-nyckelvalvet:

Följ inte anvisningarna för att generera ditt nyckelpar, 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 ska du se till att KeyTransferRemote.exe-verktyget returnerar Resultat: LYCKADES 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. Det kommer att se ut ungefär så https://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333 här: Notera URL-adressen eftersom Azure Information Protection-administratören behöver den för att Azure Rights Management-tjänsten från Azure Information Protection ska använda den här nyckeln som klientnyckel.

Använd sedan cmdleten Set-AzKeyVaultAccessPolicy för att auktorisera Azure Rights Management-tjänstens huvudnamn för att få åtkomst till nyckelvalvet. De behörigheter som krävs är dekryptera, kryptera, ta bort radbrytningar, radbrytningsnyckel, verifiera och signera.

Om nyckelvalvet som du har skapat för Azure Information Protection till exempel heter contosorms-byok-kv och resursgruppen heter contosorms-byok-rgkö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 HSM-nyckeln till Azure-nyckelvalvet är du redo att importera dina AD RMS-konfigurationsdata.

Del 3: Importera konfigurationsdata till Azure Information Protection

  1. Azure Information Protection-administratör: Kopiera över de nya konfigurationsdatafilerna (.xml) på den internetanslutna arbetsstationen och i PowerShell-sessionen som har tagits bort när du har kört verktyget TpdUtil.

  2. Upload varje .xml med hjälp av cmdleten Import-AipServiceTpd. Du bör till exempel ha minst en fil att importera om du har uppgraderat AD RMS-klustret för Cryptographic Mode 2.

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

    Om du till exempel använder en konfigurationsdatafil med en C:\contoso_keyless.xml och vårt viktiga URL-värde från föregående steg ska du först köra 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 ställs automatiskt in som arkiverad.

  3. När du har laddat upp varje fil kör du Set-AipServiceKeyProperties för att ange vilka importerade nycklar som matchar den aktiva SLC-nyckeln i AD RMS-klustret.

  4. Använd Disconnect-AipService-cmdleten för att koppla bort 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-nyckelvalv använder du cmdleten Get-AipServiceKeys Azure RMS.

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