Dela via

Integrera Azure Managed HSM med Azure Policy

  • Artikel

Azure Policy är ett styrningsverktyg som ger användarna möjlighet att granska och hantera sin Azure-miljö i stor skala. Azure Policy ger möjlighet att placera skyddsräcken på Azure-resurser för att säkerställa att de är kompatibla med tilldelade principregler. Det gör det möjligt för användare att utföra granskning, realtidsframtvingande och reparation av sin Azure-miljö. Resultatet av granskningar som utförs av principen kommer att vara tillgängliga för användare på en instrumentpanel för efterlevnad där de kan se en detaljnivå för vilka resurser och komponenter som är kompatibla och vilka som inte är det. Mer information finns i Översikt över Azure Policy-tjänst.

Några exempel på användningsscenarios:

  • Du har för närvarande ingen lösning för att utföra en granskning i organisationen, eller så utför du manuella granskningar av din miljö genom att be enskilda team i organisationen att rapportera sin efterlevnad. Du letar efter ett sätt att automatisera den här uppgiften, utföra granskningar i realtid och garantera att granskningen är korrekt.
  • Du vill framtvinga företagets säkerhetsprinciper och hindra enskilda användare från att skapa vissa kryptografiska nycklar, men du har inget automatiserat sätt att blockera skapandet av dem.
  • Du vill lätta på vissa krav för testteamen, men du vill ha noggranna kontroller över produktionsmiljön. Du behöver ett enkelt automatiserat sätt att separera tillämpningen av dina resurser.
  • Du vill vara säker på att du kan återställa tillämpningen av nya principer om det finns ett problem med livewebbplatsen. Du behöver en lösning med ett klick för att inaktivera tillämpningen av principen.
  • Du förlitar dig på en tredjepartslösning för att granska din miljö och du vill använda ett internt Microsoft-erbjudande.

Typer av policyeffekter och vägledning

Granskning: När effekten av en princip är inställd på granskning orsakar principen inga icke-bakåtkompatibla ändringar i din miljö. Den varnar dig bara för komponenter som nycklar som inte följer principdefinitionerna inom ett angivet omfång genom att markera dessa komponenter som icke-kompatibla på instrumentpanelen för principefterlevnad. Granskning är standard om ingen principeffekt har valts.

Neka: När effekten av en princip är inställd på att neka blockera principen skapandet av nya komponenter, till exempel svagare nycklar, och blockerar nya versioner av befintliga nycklar som inte följer principdefinitionen. Befintliga icke-kompatibla resurser i en hanterad HSM påverkas inte. Granskningsfunktionerna fortsätter att fungera.

Nycklar som använder elliptisk kurvkryptografi bör ha de angivna kurvnamnen

Om du använder elliptisk kurvkryptografi eller ECC-nycklar kan du anpassa en lista över tillåtna kurvnamn i listan nedan. Standardalternativet tillåter alla följande kurvnamn.

  • P-256
  • P-256K
  • P-384
  • P-521

Nycklar bör ha förfallodatum angivna

Den här principen granskar alla nycklar i dina hanterade HSM:er och flaggar nycklar som inte har ett utgångsdatum inställt som icke-kompatibla. Du kan också använda den här principen för att blockera skapandet av nycklar som inte har något angivet förfallodatum.

Nycklar bör ha fler än det angivna antalet dagar innan de upphör att gälla

Om en nyckel är för nära förfallodatum kan en organisationsfördröjning för att rotera nyckeln leda till ett avbrott. Nycklar ska roteras vid ett angivet antal dagar innan de upphör att gälla för att ge tillräckligt med tid för att reagera på ett fel. Den här principen granskar nycklar som är för nära deras förfallodatum och gör att du kan ange det här tröskelvärdet i dagar. Du kan också använda den här principen för att förhindra att nya nycklar skapas för nära deras förfallodatum.

Nycklar som använder RSA-kryptografi bör ha en angiven minsta nyckelstorlek

Att använda RSA-nycklar med mindre nyckelstorlekar är inte en säker designmetod. Du kan omfattas av gransknings- och certifieringsstandarder som kräver användning av en minsta nyckelstorlek. Med följande princip kan du ange ett minsta nyckelstorlekskrav på din hanterade HSM. Du kan granska nycklar som inte uppfyller det här minimikravet. Den här principen kan också användas för att blockera skapandet av nya nycklar som inte uppfyller kravet på minsta nyckelstorlek.

Aktivera och hantera en hanterad HSM-princip via Azure CLI

Ge behörighet att skanna dagligen

För att kontrollera kompatibiliteten för poolens inventeringsnycklar måste kunden tilldela rollen "Hanterad HSM Crypto Auditor" till "Azure Key Vault Managed HSM Key Governance Service"(App-ID: a1b76039-a76c-499f-a2dd-846b4cc32627) så att den kan komma åt nyckelns metadata. Utan behörighet kommer inventeringsnycklar inte att rapporteras i Azure Policy-efterlevnadsrapporten. Endast nya nycklar, uppdaterade nycklar, importerade nycklar och roterade nycklar kontrolleras efter efterlevnad. För att göra det måste en användare som har rollen "Hanterad HSM-administratör" för managed HSM köra följande Azure CLI-kommandon:

I windows:

az ad sp show --id a1b76039-a76c-499f-a2dd-846b4cc32627 --query id

Kopiera utskriften id och klistra in den i följande kommando:

az keyvault role assignment create --scope / --role "Managed HSM Crypto Auditor" --assignee-object-id "the id printed in previous command" --hsm-name <hsm name>

På Linux- eller Windows-undersystem i Linux:

spId=$(az ad sp show --id a1b76039-a76c-499f-a2dd-846b4cc32627 --query id|cut -d "\"" -f2)
echo $spId
az keyvault role assignment create --scope / --role "Managed HSM Crypto Auditor" --assignee-object-id $spId --hsm-name <hsm name>

Skapa principtilldelningar – definiera granskningsregler och/eller neka

Principtilldelningar har konkreta värden som definierats för principdefinitionernas parametrar. I Azure-portalen går du till "Princip", filtrerar på kategorin "Key Vault" och letar upp dessa fyra principdefinitioner för förhandsversioner av nyckelstyrning. Välj en och välj sedan knappen "Tilldela" överst. Fyll i varje fält. Om principtilldelningen är för begärandenekanden använder du ett tydligt namn på principen eftersom principtilldelningens namn visas i felet när en begäran nekas. Välj Nästa, avmarkera "Visa endast parametrar som behöver indata eller granskning" och ange värden för parametrar i principdefinitionen. Hoppa över "Reparation" och skapa tilldelningen. Tjänsten behöver upp till 30 minuter för att framtvinga "Neka"-tilldelningar.

  • Azure Key Vault Managed HSM-nycklar bör ha ett förfallodatum
  • Azure Key Vault Managed HSM-nycklar med RSA-kryptografi bör ha en angiven minsta nyckelstorlek
  • Azure Key Vault Managed HSM-nycklar bör ha fler än det angivna antalet dagar innan de upphör att gälla
  • Azure Key Vault Managed HSM-nycklar med hjälp av elliptisk kurvkryptografi ska ha de angivna kurvnamnen

Du kan också utföra den här åtgärden med hjälp av Azure CLI. Se Skapa en principtilldelning för att identifiera icke-kompatibla resurser med Azure CLI.

Testa din inställning

Försök att uppdatera/skapa en nyckel som bryter mot regeln, om du har en principtilldelning med effekten "Neka" returneras 403 till din begäran. Granska genomsökningsresultatet från inventeringsnycklarna för granskningsprinciptilldelningar. Efter 12 timmar kontrollerar du policyns efterlevnadsmeny, filtrerar efter kategorin "Key Vault" och letar reda på dina tilldelningar. Välj var och en av dem för att kontrollera rapporten med efterlevnadsresultat.

Felsökning

Om det inte finns några efterlevnadsresultat för en pool efter en dag. Kontrollera om rolltilldelningen har utförts i steg 2. Utan steg 2 kommer nyckelstyrningstjänsten inte att kunna komma åt nyckelns metadata. Azure CLI-kommandot az keyvault role assignment list kan kontrollera om rollen har tilldelats.

Nästa steg