Byok-information (Bring Your Own Key) för Azure Information Protection
Kommentar
Letar du efter Microsoft Purview Information Protection, tidigare Microsoft Information Protection (MIP)?
Azure Information Protection-tillägget dras tillbaka och ersätts med etiketter som är inbyggda i dina Microsoft 365-appar och -tjänster. Läs mer om supportstatus för andra Azure Information Protection-komponenter.
Microsoft Purview Information Protection-klienten (utan tillägget) är allmänt tillgänglig.
Organisationer med en Azure Information Protection-prenumeration kan välja att konfigurera sin klientorganisation med sin egen nyckel i stället för en standardnyckel som genereras av Microsoft. Den här konfigurationen kallas ofta för BYOK (Bring Your Own Key).
BYOK och användningsloggning fungerar sömlöst med program som integreras med Azure Rights Management-tjänsten som används av Azure Information Protection.
Exempel på program som stöds är:
Molntjänster, till exempel Microsoft SharePoint eller Microsoft 365
Lokala tjänster som kör Exchange- och SharePoint-program som använder Azure Rights Management-tjänsten via RMS-anslutningstjänsten
Klientprogram som Office 2019, Office 2016 och Office 2013
Dricks
Om det behövs kan du tillämpa ytterligare säkerhet på specifika dokument med hjälp av en ytterligare lokal nyckel. Mer information finns i DKE-skydd (dubbel nyckelkryptering) (endast enhetlig etiketteringsklient).
Azure Key Vault-nyckellagring
Kundgenererade nycklar måste lagras i Azure Key Vault för BYOK-skydd.
Kommentar
Om du använder HSM-skyddade nycklar i Azure Key Vault krävs en Azure Key Vault Premium-tjänstnivå, vilket medför en extra månatlig prenumerationsavgift.
Dela nyckelvalv och prenumerationer
Vi rekommenderar att du använder ett dedikerat nyckelvalv för din klientnyckel. Dedikerade nyckelvalv hjälper till att säkerställa att anrop från andra tjänster inte leder till att tjänstgränserna överskrids. Om du överskrider tjänstgränserna för nyckelvalvet där din klientnyckel lagras kan svarstiden begränsas för Azure Rights Management-tjänsten.
Eftersom olika tjänster har olika krav på nyckelhantering rekommenderar Microsoft även att du använder en dedikerad Azure-prenumeration för ditt nyckelvalv. Dedikerade Azure-prenumerationer:
Skydda mot felkonfigurationer
Är säkrare när olika tjänster har olika administratörer
Om du vill dela en Azure-prenumeration med andra tjänster som använder Azure Key Vault kontrollerar du att prenumerationen delar en gemensam uppsättning administratörer. Att bekräfta att alla administratörer som använder prenumerationen har en gedigen förståelse för varje nyckel de kan komma åt innebär att de är mindre benägna att felkonfigurera dina nycklar.
Exempel: Använda en delad Azure-prenumeration när administratörerna för din Azure Information Protection-klientnyckel är samma personer som administrerar dina nycklar för Office 365-kundnyckeln och CRM online. Om nyckeladministratörerna för dessa tjänster skiljer sig rekommenderar vi att du använder dedikerade prenumerationer.
Fördelar med att använda Azure Key Vault
Azure Key Vault tillhandahåller en centraliserad och konsekvent nyckelhanteringslösning för många molnbaserade och lokala tjänster som använder kryptering.
Förutom att hantera nycklar erbjuder Azure Key Vault dina säkerhetsadministratörer samma hanteringsupplevelse för att lagra, komma åt och hantera certifikat och hemligheter (till exempel lösenord) för andra tjänster och program som använder kryptering.
Att lagra din klientnyckel i Azure Key Vault ger följande fördelar:
Fördel | beskrivning |
---|---|
Inbyggda gränssnitt | Azure Key Vault stöder ett antal inbyggda gränssnitt för nyckelhantering, inklusive PowerShell, CLI, REST API:er och Azure-portalen. Andra tjänster och verktyg har integrerats med Key Vault för optimerade funktioner för specifika uppgifter, till exempel övervakning. Du kan till exempel analysera dina nyckelanvändningsloggar med Operations Management Suite Log Analytics, ange aviseringar när angivna villkor uppfylls och så vidare. |
Rollavgränsning | Azure Key Vault tillhandahåller rollseparering som en erkänd metod för säkerhet. Rollavgränsning säkerställer att Azure Information Protection-administratörer kan fokusera på sina högsta prioriteter, inklusive hantering av dataklassificering och skydd, samt krypteringsnycklar och principer för specifika säkerhets- eller efterlevnadskrav. |
Huvudnyckelplats | Azure Key Vault är tillgängligt på flera olika platser och stöder organisationer med begränsningar där huvudnycklar kan finnas. Mer information finns på sidan Produkter som är tillgängliga per region på Azure-webbplatsen. |
Avgränsade säkerhetsdomäner | Azure Key Vault använder separata säkerhetsdomäner för sina datacenter i regioner som Nordamerika, EMEA (Europa, Mellanöstern och Afrika) och Asien. Azure Key Vault använder också olika instanser av Azure, till exempel Microsoft Azure Tyskland och Azure Government. |
Enhetlig upplevelse | Med Azure Key Vault kan även säkerhetsadministratörer lagra, komma åt och hantera certifikat och hemligheter, till exempel lösenord, för andra tjänster som använder kryptering. Att använda Azure Key Vault för dina klientnycklar ger en smidig användarupplevelse för administratörer som hanterar alla dessa element. |
De senaste uppdateringarna och information om hur andra tjänster använder Azure Key Vault finns i Azure Key Vault-teamets blogg.
Användningsloggning för BYOK
Användningsloggar genereras av varje program som skickar begäranden till Azure Rights Management-tjänsten.
Även om användningsloggning är valfritt rekommenderar vi att du använder användningsloggarna i nära realtid från Azure Information Protection för att se exakt hur och när din klientnyckel används.
Mer information om loggning av nyckelanvändning för BYOK finns i Logga och analysera skyddsanvändningen från Azure Information Protection.
Dricks
För ytterligare säkerhet kan Azure Information Protection-användningsloggning korsreferenseras med Azure Key Vault-loggning. Key Vault-loggar ger en tillförlitlig metod för att oberoende övervaka att din nyckel endast används av Azure Rights Management-tjänsten.
Om det behövs återkallar du omedelbart åtkomsten till din nyckel genom att ta bort behörigheter för nyckelvalvet.
Alternativ för att skapa och lagra din nyckel
Kommentar
Mer information om Managed HSM-erbjudandet och hur du konfigurerar ett valv och en nyckel finns i Dokumentation om Azure Key Vault.
Ytterligare instruktioner för att bevilja nyckelauktorisering beskrivs nedan.
BYOK stöder nycklar som skapas antingen i Azure Key Vault eller lokalt.
Om du skapar din nyckel lokalt måste du sedan överföra eller importera den till ditt Key Vault och konfigurera Azure Information Protection att använda nyckeln. Utför eventuell ytterligare nyckelhantering inifrån Azure Key Vault.
Alternativ för att skapa och lagra din egen nyckel:
Skapad i Azure Key Vault. Skapa och lagra din nyckel i Azure Key Vault som en HSM-skyddad nyckel eller en programvaruskyddad nyckel.
Skapat lokalt. Skapa din nyckel lokalt och överför den till Azure Key Vault med något av följande alternativ:
HSM-skyddad nyckel som överförs som en HSM-skyddad nyckel. Den vanligaste metoden som valts.
Även om den här metoden har de mest administrativa kostnaderna kan det krävas att din organisation följer specifika regler. De HSM:er som används av Azure Key Vault har FIPS 140-validering.
Programvaruskyddad nyckel som konverteras och överförs till Azure Key Vault som en HSM-skyddad nyckel. Den här metoden stöds endast när du migrerar från Active Directory Rights Management Services (AD RMS).
Skapat lokalt som en programvaruskyddad nyckel och överförts till Azure Key Vault som en programvaruskyddad nyckel. Den här metoden kräver en . PFX-certifikatfil.
Gör till exempel följande för att använda en nyckel som skapats lokalt:
Generera din klientnyckel lokalt, i enlighet med organisationens IT- och säkerhetsprinciper. Den här nyckeln är huvudkopian. Den är fortfarande lokal och du måste ha den för säkerhetskopieringen.
Skapa en kopia av huvudnyckeln och överför den på ett säkert sätt från din HSM till Azure Key Vault. Under hela den här processen lämnar huvudkopian av nyckeln aldrig maskinvaruskyddsgränsen.
När nyckeln har överförts skyddas kopian av nyckeln av Azure Key Vault.
Exportera din betrodda publiceringsdomän
Om du någonsin bestämmer dig för att sluta använda Azure Information Protection behöver du en betrodd publiceringsdomän (TPD) för att dekryptera innehåll som har skyddats av Azure Information Protection.
Det går dock inte att exportera din TPD om du använder BYOK för din Azure Information Protection-nyckel.
För att förbereda dig för det här scenariot måste du skapa en lämplig TPD i förväg. Mer information finns i Förbereda en Azure Information Protection-plan för "molnavslut".
Implementera BYOK för din Azure Information Protection-klientnyckel
Använd följande steg för att implementera BYOK:
Krav för BYOK
KRAVEN för BYOK varierar beroende på systemkonfigurationen. Kontrollera att systemet uppfyller följande krav efter behov:
Krav | Beskrivning |
---|---|
Azure-prenumeration | Krävs för alla konfigurationer. Mer information finns i Kontrollera att du har en BYOK-kompatibel Azure-prenumeration. |
AIPService PowerShell-modul för Azure Information Protection | Krävs för alla konfigurationer. Mer information finns i Installera AIPService PowerShell-modulen. |
Krav för Azure Key Vault för BYOK | Om du använder en HSM-skyddad nyckel som har skapats lokalt kontrollerar du att du också uppfyller kraven för BYOK som anges i Azure Key Vault-dokumentationen. |
Thales firmware version 11.62 | Du måste ha en thales-version av den inbyggda programvaran 11.62 om du migrerar från AD RMS till Azure Information Protection med hjälp av programvarunyckeln till maskinvarunyckeln och använder Thales inbyggda programvara för din HSM. |
Förbikoppling av brandvägg för betrodda Microsoft-tjänster | Om nyckelvalvet som innehåller klientnyckeln använder tjänstslutpunkter för virtuellt nätverk för Azure Key Vault måste du tillåta att betrodda Microsoft-tjänster kringgår brandväggen. Mer information finns i Tjänstslutpunkter för virtuellt nätverk för Azure Key Vault. |
Kontrollera att du har en BYOK-kompatibel Azure-prenumeration
Din Azure Information Protection-klient måste ha en Azure-prenumeration. Om du inte har något ännu kan du registrera dig för ett kostnadsfritt konto. Om du vill använda en HSM-skyddad nyckel måste du dock ha Azure Key Vault Premium-tjänstnivån.
Den kostnadsfria Azure-prenumerationen som ger åtkomst till Microsoft Entra-konfiguration och anpassad mallkonfiguration för Azure Rights Management räcker inte för att använda Azure Key Vault.
Kontrollera om du har en Azure-prenumeration som är kompatibel med BYOK genom att göra följande för att verifiera med hjälp av Azure PowerShell-cmdletar :
Starta en Azure PowerShell-session som administratör.
Logga in som global administratör för din Azure Information Protection-klientorganisation med hjälp av
Connect-AzAccount
.Kopiera token som visas till Urklipp. I en webbläsare går du sedan till https://microsoft.com/devicelogin och anger den kopierade token.
Mer information finns i Logga in med Azure PowerShell.
I PowerShell-sessionen anger du
Get-AzSubscription
och bekräftar att följande värden visas:- Ditt prenumerationsnamn och ID
- Ditt Klient-ID för Azure Information Protection
- Bekräftelse på att tillståndet är aktiverat
Om inga värden visas och du returneras till prompten har du ingen Azure-prenumeration som kan användas för BYOK.
Välja plats för nyckelvalvet
När du skapar ett nyckelvalv som ska innehålla nyckeln som ska användas som klientnyckel för Azure Information måste du ange en plats. Den här platsen är en Azure-region eller En Azure-instans.
Gör ditt val först för efterlevnad och sedan för att minimera nätverksfördröjningen:
Om du har valt BYOK-nyckelmetoden av efterlevnadsskäl kan dessa efterlevnadskrav även kräva vilken Azure-region eller instans som kan användas för att lagra din Azure Information Protection-klientnyckel.
Alla kryptografiska anrop för skyddskedja till din Azure Information Protection-nyckel. Därför kanske du vill minimera den nätverksfördröjning som dessa anrop kräver genom att skapa ditt nyckelvalv i samma Azure-region eller instans som din Azure Information Protection-klientorganisation.
Om du vill identifiera platsen för din Azure Information Protection-klient använder du PowerShell-cmdleten Get-AipServiceConfiguration och identifierar regionen från URL:erna. Till exempel:
LicensingIntranetDistributionPointUrl : https://5c6bb73b-1038-4eec-863d-49bded473437.rms.na.aadrm.com/_wmcs/licensing
Regionen kan identifieras från rms.na.aadrm.com, och i det här exemplet finns den i Nordamerika.
I följande tabell visas rekommenderade Azure-regioner och instanser för att minimera nätverksfördröjningen:
Azure-region eller instans | Rekommenderad plats för ditt nyckelvalv |
---|---|
Rms.na.aadrm.com | USA , norra centrala eller USA, östra |
Rms.eu.aadrm.com | Europa, norra eller Europa, västra |
Rms.ap.aadrm.com | Asien, östra eller Sydostasien |
Rms.sa.aadrm.com | USA , västra eller USA, östra |
Rms.govus.aadrm.com | USA , centrala eller USA, östra 2 |
Rms.aadrm.us | US Gov Virginia eller US Gov Arizona |
Rms.aadrm.cn | Kina, östra 2 eller Kina, norra 2 |
Skapa och konfigurera din nyckel
Viktigt!
Information som är specifik för hanterade HSM:er finns i Aktivera nyckelauktorisering för hanterade HSM-nycklar via Azure CLI.
Skapa ett Azure Key Vault och den nyckel som du vill använda för Azure Information Protection. Mer information finns i Dokumentationen om Azure Key Vault.
Observera följande för att konfigurera ditt Azure Key Vault och din nyckel för BYOK:
- Krav på nyckellängd
- Skapa en HSM-skyddad nyckel lokalt och överföra den till ditt nyckelvalv
- Konfigurera Azure Information Protection med ditt nyckel-ID
- Auktorisera Azure Rights Management-tjänsten att använda din nyckel
Krav på nyckellängd
När du skapar nyckeln kontrollerar du att nyckellängden antingen är 2 048 bitar (rekommenderas) eller 1 024 bitar. Andra viktiga längder stöds inte av Azure Information Protection.
Kommentar
1024-bitarsnycklar anses inte erbjuda en tillräcklig skyddsnivå för aktiva klientnycklar.
Microsoft stöder inte användning av lägre nyckellängder, till exempel 1024-bitars RSA-nycklar, och associerad användning av protokoll som erbjuder otillräckliga skyddsnivåer, till exempel SHA-1.
Skapa en HSM-skyddad nyckel lokalt och överföra den till ditt nyckelvalv
Om du vill skapa en HSM-skyddad nyckel lokalt och överföra den till ditt nyckelvalv som en HSM-skyddad nyckel följer du procedurerna i Azure Key Vault-dokumentationen: Så här genererar och överför du HSM-skyddade nycklar för Azure Key Vault.
För att Azure Information Protection ska kunna använda den överförda nyckeln måste alla Key Vault-åtgärder tillåtas för nyckeln, inklusive:
- kryptera
- Dekryptera
- wrapKey
- unwrapKey
- Tecken
- Kontrollera
Som standard tillåts alla Key Vault-åtgärder.
Om du vill kontrollera de tillåtna åtgärderna för en specifik nyckel kör du följande PowerShell-kommando:
(Get-AzKeyVaultKey -VaultName <key vault name> -Name <key name>).Attributes.KeyOps
Om det behövs lägger du till tillåtna åtgärder med hjälp av Update-AzKeyVaultKey och parametern KeyOps .
Konfigurera Azure Information Protection med ditt nyckel-ID
Nycklar som lagras i Azure Key Vault har var och en ett nyckel-ID.
Nyckel-ID:t är en URL som innehåller namnet på nyckelvalvet, nyckelcontainern, namnet på nyckeln och nyckelversionen. Till exempel: https://contosorms-kv.vault.azure.net/keys/contosorms-byok/aaaabbbbcccc111122223333
Konfigurera Azure Information Protection att använda din nyckel genom att ange url:en för nyckelvalvet.
Auktorisera Azure Rights Management-tjänsten att använda din nyckel
Azure Rights Management-tjänsten måste ha behörighet att använda din nyckel. Azure Key Vault-administratörer kan aktivera den här auktoriseringen med hjälp av Azure-portalen eller Azure PowerShell.
Aktivera nyckelauktorisering med hjälp av Azure-portalen
Logga in på Azure-portalen och gå till Nyckelvalv med nyckelvalvets<>namn>>Åtkomstprinciper>Lägg till ny.
I fönstret Lägg till åtkomstprincip i listrutan Konfigurera från mall (valfritt) väljer du Azure Information Protection BYOK och klickar sedan på OK.
Den valda mallen har följande konfiguration:
- Värdet Välj huvudnamn är inställt på Microsoft Rights Management Services.
- Bland de valda nyckelbehörigheterna finns Get, Decrypt och Sign.
Aktivera nyckelauktorisering med PowerShell
Kör Key Vault PowerShell-cmdleten Set-AzKeyVaultAccessPolicy och bevilja behörigheter till Tjänstens huvudnamn för Azure Rights Management med hjälp av GUID 00000012-0000-0000-c000-000000000000.
Till exempel:
Set-AzKeyVaultAccessPolicy -VaultName 'ContosoRMS-kv' -ResourceGroupName 'ContosoRMS-byok-rg' -ServicePrincipalName 00000012-0000-0000-c000-000000000000 -PermissionsToKeys decrypt,sign,get
Aktivera nyckelauktorisering för hanterade HSM-nycklar via Azure CLI
Om du vill ge tjänstens huvudnamn behörighet som hanterad HSM Crypto-användare kör du följande kommando:
az keyvault role assignment create --hsm-name "ContosoMHSM" --role "Managed HSM Crypto User" --assignee-principal-type ServicePrincipal --assignee https://aadrm.com/ --scope /keys/contosomhskey
Där:
- ContosoMHSM är ett HSM-exempelnamn. När du kör det här kommandot ersätter du det här värdet med ditt eget HSM-namn.
Användarrollen Hanterad HSM Crypto-användare gör att användaren kan dekryptera, signera och hämta behörigheter till nyckeln, som alla krävs för managed HSM-funktionen.
Konfigurera Azure Information Protection för att använda din nyckel
När du har slutfört alla steg ovan är du redo att konfigurera Azure Information Protection att använda den här nyckeln som organisationens klientnyckel.
Kör följande kommandon med Hjälp av Azure RMS-cmdletar:
Anslut till Azure Rights Management-tjänsten och logga in:
Connect-AipService
Kör cmdleten Use-AipServiceKeyVaultKey och ange nyckel-URL:en. Till exempel:
Use-AipServiceKeyVaultKey -KeyVaultKeyUrl "https://contosorms-kv.vault.azure.net/keys/contosorms-byok/<key-version>"
Viktigt!
I det här exemplet
<key-version>
är den version av nyckeln som du vill använda. Om du inte anger versionen används den aktuella versionen av nyckeln som standard och kommandot kan verka fungera. Men om nyckeln uppdateras eller förnyas senare slutar Azure Rights Management-tjänsten att fungera för din klientorganisation, även om du kör kommandot Use-AipServiceKeyVaultKey igen.Använd kommandot Get-AzKeyVaultKey efter behov för att hämta versionsnumret för den aktuella nyckeln.
Till exempel:
Get-AzKeyVaultKey -VaultName 'contosorms-kv' -KeyName 'contosorms-byok'
Kontrollera att nyckel-URL:en har angetts korrekt för Azure Information Protection genom att köra kommandot Get-AzKeyVaultKey i Azure Key Vault för att visa nyckel-URL:en.
Om Azure Rights Management-tjänsten redan är aktiverad kör du Set-AipServiceKeyProperties för att be Azure Information Protection att använda den här nyckeln som aktiv klientnyckel för Azure Rights Management-tjänsten.
Azure Information Protection har nu konfigurerats för att använda din nyckel i stället för standardnyckeln som skapats av Microsoft och som skapades automatiskt för din klientorganisation.
Nästa steg
När du har konfigurerat BYOK-skydd fortsätter du till Komma igång med klientorganisationens rotnyckel för mer information om hur du använder och hanterar din nyckel.