Integrera Azure Key Vault med Azure Policy
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änsten.
Exempel på användningsscenarier:
- Du vill förbättra företagets säkerhetsstatus genom att implementera krav kring minsta nyckelstorlekar och maximala giltighetsperioder för certifikat i företagets nyckelvalv, men du vet inte vilka team som är kompatibla och vilka som inte är det.
- 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 självsignerade certifikat, 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 i händelse av 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
När du framtvingar en princip kan du fastställa dess effekt över den resulterande utvärderingen. Med varje principdefinition kan du välja en av flera effekter. Principtillämpningen kan därför fungera annorlunda beroende på vilken typ av åtgärd du utvärderar. I allmänhet omfattar effekterna för principer som integreras med Key Vault:
Granskning: när effekten av en princip är inställd på
Auditkommer principen inte att orsaka några icke-bakåtkompatibla ändringar i din miljö. Den varnar dig bara för komponenter som certifikat 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å
Denyblockerar principen skapandet av nya komponenter, till exempel certifikat, samt blockerar nya versioner av befintliga komponenter som inte följer principdefinitionen. Befintliga icke-kompatibla resurser i ett nyckelvalv påverkas inte. Granskningsfunktionerna fortsätter att fungera.Inaktiverad: när effekten av en princip har angetts till
Disabledutvärderas principen fortfarande men tillämpningen börjar inte gälla, vilket är kompatibelt för villkoret medDisabledverkan. Det här är användbart om du vill inaktivera principen för ett visst villkor i stället för alla villkor.Ändra: när effekten av en princip är inställd på kan du lägga till
Modifyresurstaggar, till exempel lägga till taggen iDenyett nätverk. Det här är användbart för att inaktivera åtkomst till ett offentligt nätverk för Azure Key Vault-hanterad HSM. Det är nödvändigt att konfigurera en hanterad identitet för principdefinitionen via parameternroleDefinitionIdsför att använda effektenModify.DeployIfNotExists: när effekten av en princip har angetts till
DeployIfNotExistskörs en distributionsmall när villkoret uppfylls. Detta kan användas för att konfigurera diagnostikinställningar för Key Vault till log analytics-arbetsytan. Det är nödvändigt att konfigurera en hanterad identitet för principdefinitionen via parameternroleDefinitionIdsför att använda effektenDeployIfNotExists.AuditIfNotExists: när effekten av en princip är inställd på
AuditIfNotExistskan du identifiera resurser som saknar de egenskaper som anges i informationen om principvillkoret. Det här är användbart för att identifiera nyckelvalv som inte har några resursloggar aktiverade. Det är nödvändigt att konfigurera en hanterad identitet för principdefinitionen via parameternroleDefinitionIdsför att använda effektenDeployIfNotExists.
Tillgängliga inbyggda principdefinitioner
Fördefinierade principer, som kallas "inbyggda", underlättar styrningen av dina nyckelvalv så att du inte behöver skriva anpassade principer i JSON-format för att framtvinga vanliga regler som är associerade med bästa säkerhetsmetoder. Även om inbyggda objekt är förutbestämda kräver vissa principer att du definierar parametrar. Genom att till exempel definiera effekten av principen kan du granska nyckelvalvet och dess objekt innan du framtvingar en neka-åtgärd för att förhindra avbrott. Aktuella inbyggda objekt för Azure Key Vault kategoriseras i fyra större grupper: nyckelvalv, certifikat, nycklar och hemlighetshantering. Inom varje kategori grupperas principer för att driva specifika säkerhetsmål.
Nyckelvalv
Åtkomstkontroll
Med hjälp av Azure Policy-tjänsten kan du styra migreringen till RBAC-behörighetsmodellen i dina valv. Läs mer i Migrera från åtkomstprincip för valv till en rollbaserad åtkomstkontrollsmodell i Azure
| Policy | Effekter |
|---|---|
| Azure Key Vault bör använda RBAC-behörighetsmodellen | Granskning (standard), Neka, Inaktiverad |
Nätverksåtkomst
Minska risken för dataläckage genom att begränsa åtkomsten till det offentliga nätverket, aktivera Azure Private Link-anslutningar , skapa privata DNS-zoner för att åsidosätta DNS-matchning för en privat slutpunkt och aktivera brandväggsskydd så att nyckelvalvet inte är tillgängligt som standard för offentliga IP-adresser.
Borttagningsskydd
Förhindra permanent dataförlust av ditt nyckelvalv och dess objekt genom att aktivera skydd mot mjuk borttagning och rensning. Med mjuk borttagning kan du återställa ett nyckelvalv som tagits bort av misstag under en konfigurerbar kvarhållningsperiod, men rensningsskyddet skyddar dig mot insiderattacker genom att framtvinga en obligatorisk kvarhållningsperiod för mjukt borttagna nyckelvalv. Rensningsskydd kan bara aktiveras när mjuk borttagning har aktiverats. Ingen i din organisation eller Microsoft kommer att kunna rensa dina nyckelvalv under kvarhållningsperioden för mjuk borttagning.
| Policy | Effekter |
|---|---|
| Key Vaults ska ha mjuk borttagning aktiverat | Granskning (standard), Neka, Inaktiverad |
| Key Vaults bör ha rensningsskydd aktiverat | Granskning (standard), Neka, Inaktiverad |
| Azure Key Vault Managed HSM bör ha rensningsskydd aktiverat | Granskning (standard), Neka, Inaktiverad |
Diagnostik
Aktivera resursloggar för att återskapa aktivitetsloggar som ska användas i undersökningssyfte när en säkerhetsincident inträffar eller när nätverket komprometteras.
| Policy | Effekter |
|---|---|
| Distribuera diagnostikinställningar för Key Vaults till en händelsehubb | DeployIfNotExists (standard) |
| Distribuera – Konfigurera diagnostikinställningar för Key Vault-hanterade HSM:er till en händelsehubb | DeployIfNotExists (standard), Inaktiverad |
| Distribuera – Konfigurera diagnostikinställningar för Key Vaults till Log Analytics-arbetsytan | DeployIfNotExists (standard), Inaktiverad |
| Resursloggar i Key Vaults ska vara aktiverade | AuditIfNotExists (standard), Inaktiverad |
| Resursloggar i Key Vault-hanterade HSM:er ska vara aktiverade | AuditIfNotExists (standard), Inaktiverad |
Certifikat
Livscykel för certifikat
Främja användningen av kortlivade certifikat för att minimera oupptäckta attacker genom att minimera tidsramen för pågående skador och minska värdet på certifikatet för angripare. När du implementerar kortlivade certifikat rekommenderar vi att du regelbundet övervakar deras förfallodatum för att undvika avbrott, så att de kan roteras tillräckligt innan de upphör att gälla. Du kan också styra den livslängdsåtgärd som har angetts för certifikat som antingen är inom ett visst antal dagar efter att de har upphört att gälla eller som har nått en viss procentandel av deras användbara livslängd.
| Policy | Effekter |
|---|---|
| [Förhandsversion]: Certifikaten bör ha den angivna maximala giltighetsperioden | Effekter: Granskning (standard), Neka, Inaktiverad |
| [Förhandsversion]: Certifikat bör inte upphöra att gälla inom det angivna antalet dagar | Effekter: Granskning (standard), Neka, Inaktiverad |
| Certifikaten ska ha de angivna utlösarna för livslängdsåtgärden | Effekter: Granskning (standard), Neka, Inaktiverad |
Kommentar
Vi rekommenderar att du tillämpar certifikatets förfalloprincip flera gånger med olika tröskelvärden för förfallodatum, till exempel vid tröskelvärdena 180, 90, 60 och 30 dagar.
Certifikatutfärdare
Granska eller framtvinga valet av en specifik certifikatutfärdare för att utfärda dina certifikat, antingen beroende av en av Azure Key Vaults integrerade certifikatutfärdare (Digicert eller GlobalSign) eller en icke-integrerad certifikatutfärdare som du föredrar. Du kan också granska eller neka skapandet av självsignerade certifikat.
| Policy | Effekter |
|---|---|
| Certifikat ska utfärdas av den angivna integrerade certifikatutfärdare | Granskning (standard), Neka, Inaktiverad |
| Certifikat ska utfärdas av den angivna icke-integrerade certifikatutfärdare | Granskning (standard), Neka, Inaktiverad |
Certifikatattribut
Begränsa typen av nyckelvalvscertifikat till RSA, ECC eller HSM-stödda. Om du använder elliptisk kurvkryptografi eller ECC-certifikat kan du anpassa och välja kurvnamn som P-256, P-256K, P-384 och P-521. Om du använder RSA-certifikat kan du välja en minsta nyckelstorlek för att dina certifikat ska vara 2 048 bitar, 3 072 bitar eller 4 096 bitar.
| Policy | Effekter |
|---|---|
| Certifikat bör använda tillåtna nyckeltyper | Granskning (standard), Neka, Inaktiverad |
| Certifikat som använder elliptisk kurvkryptografi bör ha tillåtna kurvnamn | Granskning (standard), Neka, Inaktiverad |
| Certifikat som använder RSA-kryptografi bör ha den angivna minsta nyckelstorleken | Granskning (standard), Neka, Inaktiverad |
Nycklar
HSM-backade nycklar
En HSM är en maskinvarusäkerhetsmodul som lagrar nycklar. En HSM ger ett fysiskt skydd för kryptografiska nycklar. Den kryptografiska nyckeln kan inte lämna en fysisk HSM som ger en högre säkerhetsnivå än en programvarunyckel. Vissa organisationer har efterlevnadskrav som kräver användning av HSM-nycklar. Du kan använda den här principen för att granska alla nycklar som lagras i ditt Key Vault som inte är HSM-stödda. Du kan också använda den här principen för att blockera skapandet av nya nycklar som inte stöds av HSM. Den här principen gäller för alla nyckeltyper, inklusive RSA och ECC.
| Policy | Effekter |
|---|---|
| Nycklar bör säkerhetskopieras av en maskinvarusäkerhetsmodul (HSM) | Granskning (standard), Neka, Inaktiverad |
Nycklars livscykel
Med inbyggda livscykelhanteringsfunktioner kan du flagga eller blockera nycklar som inte har ett utgångsdatum, få aviseringar när fördröjningar i nyckelrotationen kan leda till avbrott, förhindra att nya nycklar skapas nära utgångsdatumet, begränsa nycklars livslängd och aktiva status för att driva nyckelrotation och förhindra att nycklar är aktiva i mer än ett angivet antal dagar.
| Policy | Effekter |
|---|---|
| Nycklar bör ha en rotationsprincip som säkerställer att rotationen schemaläggs inom det angivna antalet dagar efter att de har skapats | Granskning (standard), inaktiverad |
| Key Vault-nycklar bör ha ett utgångsdatum | Granskning (standard), Neka, Inaktiverad |
| [Förhandsversion]: Hanterade HSM-nycklar bör ha ett förfallodatum | Granskning (standard), Neka, Inaktiverad |
| Nycklar bör ha fler än det angivna antalet dagar innan de upphör att gälla | Granskning (standard), Neka, Inaktiverad |
| [Förhandsversion]: Azure Key Vault Managed HSM-nycklar bör ha fler än det angivna antalet dagar innan de upphör att gälla | Granskning (standard), Neka, Inaktiverad |
| Nycklarna ska ha den angivna maximala giltighetsperioden | Granskning (standard), Neka, Inaktiverad |
| Nycklar bör inte vara aktiva längre än det angivna antalet dagar | Granskning (standard), Neka, Inaktiverad |
Viktigt!
Om nyckeln har angett ett aktiveringsdatum beräknar principen ovan antalet dagar som har förflutit från aktiveringsdatumet för nyckeln till det aktuella datumet. Om antalet dagar överskrider tröskelvärdet som du anger markeras nyckeln som icke-kompatibel med principen. Om nyckeln inte har angett något aktiveringsdatum beräknar principen antalet dagar som har förflutit från det datum då nyckeln skapades till det aktuella datumet. Om antalet dagar överskrider tröskelvärdet som du anger markeras nyckeln som icke-kompatibel med principen.
Nyckelattribut
Begränsa typen av nyckelvalv till RSA, ECC eller HSM-backad. Om du använder elliptisk kurvkryptografi eller ECC-nycklar kan du anpassa och välja kurvnamn som P-256, P-256K, P-384 och P-521. Om du använder RSA-nycklar kan du kräva att en minsta nyckelstorlek används för att aktuella och nya nycklar ska vara 2 048 bitar, 3 072 bitar eller 4 096 bitar. Tänk på att användning av RSA-nycklar med mindre nyckelstorlekar inte är en säker designmetod. Därför rekommenderar vi att du blockerar skapandet av nya nycklar som inte uppfyller minimikraven för storlek.
| Policy | Effekter |
|---|---|
| Nycklar ska vara den angivna kryptografiska typen RSA eller EC | Granskning (standard), Neka, Inaktiverad |
| Nycklar som använder elliptisk kurvkryptografi ska ha de angivna kurvnamnen | Granskning (standard), Neka, Inaktiverad |
| [Förhandsversion]: Azure Key Vault Managed HSM-nycklar med hjälp av elliptisk kurvkryptografi bör ha de angivna kurvnamnen | Granskning (standard), Neka, Inaktiverad |
| Nycklar som använder RSA-kryptografi bör ha en angiven minsta nyckelstorlek | Granskning (standard), Neka, Inaktiverad |
| [Förhandsversion]: Azure Key Vault Managed HSM-nycklar med RSA-kryptografi bör ha en angiven minsta nyckelstorlek | Granskning (standard), Neka, Inaktiverad |
Hemligheter
Hemligheternas livscykel
Med inbyggda livscykelhanteringsfunktioner kan du flagga eller blockera hemligheter som inte har ett förfallodatum, få aviseringar när fördröjningar i hemlig rotation kan leda till ett avbrott, förhindra att nya nycklar skapas nära deras förfallodatum, begränsa livslängden och den aktiva statusen för nycklar för att driva nyckelrotation och förhindra att nycklar är aktiva i mer än ett angivet antal dagar.
| Policy | Effekter |
|---|---|
| Hemligheter bör ha ett utgångsdatum | Granskning (standard), Neka, Inaktiverad |
| Hemligheter bör ha mer än det angivna antalet dagar innan de upphör att gälla | Granskning (standard), Neka, Inaktiverad |
| Hemligheter bör ha den angivna maximala giltighetsperioden | Granskning (standard), Neka, Inaktiverad |
| Hemligheter bör inte vara aktiva längre än det angivna antalet dagar | Granskning (standard), Neka, Inaktiverad |
Viktigt!
Om din hemlighet har angett ett aktiveringsdatum beräknar principen ovan antalet dagar som har förflutit från aktiveringsdatumet för hemligheten till det aktuella datumet. Om antalet dagar överskrider tröskelvärdet som du anger markeras hemligheten som icke-kompatibel med principen. Om din hemlighet inte har angett något aktiveringsdatum beräknar den här principen antalet dagar som har förflutit från det datum då hemligheten skapades till det aktuella datumet. Om antalet dagar överskrider tröskelvärdet som du anger markeras hemligheten som icke-kompatibel med principen.
Hemliga attribut
All oformaterad text eller kodad fil kan lagras som en Azure-nyckelvalvshemlighet. Din organisation kanske dock vill ange olika rotationsprinciper och begränsningar för lösenord, anslutningssträng eller certifikat som lagras som nycklar. En innehållstyptagg kan hjälpa en användare att se vad som lagras i ett hemligt objekt utan att läsa hemlighetens värde. Du kan granska hemligheter som inte har en tagguppsättning för innehållstyp eller förhindra att nya hemligheter skapas om de inte har en tagguppsättning för innehållstyp.
| Policy | Effekter |
|---|---|
| Hemligheter bör ha en uppsättning innehållstyper | Granskning (standard), Neka, Inaktiverad |
Exempel på ett scenario
Du hanterar ett nyckelvalv som används av flera team som innehåller 100 certifikat och du vill se till att inget av certifikaten i nyckelvalvet är giltiga i mer än 2 år.
- Du tilldelar certifikaten ska ha den angivna principen för maximal giltighetsperiod , anger att den maximala giltighetsperioden för ett certifikat är 24 månader och anger effekten av principen till "granskning".
- Du visar efterlevnadsrapporten på Azure-portalen och upptäcker att 20 certifikat är inkompatibla och giltiga i > två år och att de återstående certifikaten är kompatibla.
- Du kontaktar ägarna till dessa certifikat och meddelar det nya säkerhetskravet att certifikat inte kan vara giltiga längre än två år. Vissa team svarar och 15 av certifikaten förnyades med en maximal giltighetsperiod på 2 år eller mindre. Andra team svarar inte och du har fortfarande 5 icke-kompatibla certifikat i ditt nyckelvalv.
- Du ändrar effekten av principen som du tilldelade till "neka". De 5 icke-kompatibla certifikaten återkallas inte och de fortsätter att fungera. De kan dock inte förnyas med en giltighetsperiod som är längre än 2 år.
Aktivera och hantera en key vault-princip via Azure-portalen
Välj en principdefinition
Logga in på Azure Portal.
Sök efter "princip" i sökfältet och välj princip.
I fönstret Princip väljer du Definitioner.
I kategorifiltret avmarkerar du Välj alla och väljer Nyckelvalv.
Nu bör du kunna se alla principer som är tillgängliga för offentlig förhandsversion för Azure Key Vault. Kontrollera att du har läst och förstått avsnittet principvägledning ovan och välj en princip som du vill tilldela till ett omfång.
Tilldela en princip till ett omfång
Välj en princip som du vill tillämpa. I det här exemplet visas principen Hantera certifikatets giltighetsperiod . Klicka på knappen Tilldela i det övre vänstra hörnet.
Välj den prenumeration där du vill att principen ska tillämpas. Du kan välja att begränsa omfånget till endast en enskild resursgrupp i en prenumeration. Om du vill tillämpa principen på hela prenumerationen och exkludera vissa resursgrupper kan du även konfigurera en undantagslista. Ange principens tvingande väljare till Aktiverad om du vill att effekten av principen (granskning eller neka) ska inträffa eller Inaktiverad för att inaktivera effekten (granskning eller neka).
Klicka på fliken parametrar överst på skärmen för att ange den maximala giltighetsperioden i månader som du vill använda. Om du behöver ange parametrarna kan du avmarkera alternativet Visa endast parametrar som behöver indata eller granskning. Välj granska eller neka för effekten av principen enligt riktlinjerna i avsnitten ovan. Välj sedan knappen granska + skapa.
Visa kompatibilitetsresultat
Gå tillbaka till bladet Princip och välj fliken Efterlevnad. Klicka på den principtilldelning som du vill visa kompatibilitetsresultat för.
På den här sidan kan du filtrera resultat efter kompatibla eller icke-kompatibla valv. Här kan du se en lista över icke-kompatibla nyckelvalv inom omfånget för principtilldelningen. Ett valv anses vara inkompatibelt om någon av komponenterna (certifikaten) i valvet inte är kompatibla. Du kan välja ett enskilt valv för att visa enskilda icke-kompatibla komponenter (certifikat).
Visa namnet på komponenterna i ett valv som inte är kompatibelt
Om du behöver kontrollera om användare nekas möjligheten att skapa resurser i nyckelvalvet kan du klicka på fliken Komponenthändelser (förhandsversion) för att visa en sammanfattning av nekade certifikatåtgärder med begäranden och tidsstämplar för begäranden.
Funktionsbegränsningar
Att tilldela en princip med en "neka"-effekt kan ta upp till 30 minuter (genomsnittligt fall) och 1 timme (värsta fall) för att börja neka skapandet av icke-kompatibla resurser. Fördröjningen avser följande scenarier –
- En ny princip tilldelas.
- En befintlig principtilldelning ändras.
- En ny KeyVault (resurs) skapas i ett omfång med befintliga principer.
Principutvärderingen av befintliga komponenter i ett valv kan ta upp till 1 timme (genomsnittligt fall) och 2 timmar (värsta fall) innan efterlevnadsresultat kan visas i portalgränssnittet.
Om kompatibilitetsresultatet visas som "Inte startat" kan det bero på följande:
- Principvärdering har inte slutförts ännu. Den inledande utvärderingsfördröjningen kan ta upp till 2 timmar i värsta fall.
- Det finns inga nyckelvalv i principtilldelningens omfång.
- Det finns inga nyckelvalv med certifikat inom omfånget för principtilldelningen.
Kommentar
Azure Policy-resursproviderlägen, till exempel de för Azure Key Vault, ger information om efterlevnad på sidan Komponentefterlevnad.
Nästa steg
- Loggning och vanliga frågor och svar om Azure Policy för Key Vault
- Läs mer om Azure Policy-tjänsten
- Se Key Vault-exempel: Inbyggda principdefinitioner för Key Vault
- Lär dig mer om Microsofts prestandamått för molnsäkerhet i Key Vault