Dela via

Felsöka problem med att implementera Azure-principer i Key Vault

  • Artikel

Den här artikeln beskriver hur du felsöker allmänna fel som kan uppstå när du konfigurerar Azure Policy for Key Vault och föreslår olika sätt att lösa dem.

Om Azure-princip för Key Vault

Azure Policy är ett styrningsverktyg som ger användarna möjlighet att granska och hantera sin Azure-miljö i stor skala. Med Azure Policy kan du 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.

Loggning

För att övervaka hur principutvärderingar utförs kan du granska Key Vault-loggarna. Aktivera loggning för Azure Key Vault, vilket sparar information i ett Azure-lagringskonto som du anger. Stegvisa anvisningar finns i Så här aktiverar du Key Vault-loggning.

När du aktiverar loggning skapas automatiskt en ny container med namnet AzurePolicyEvaluationDetails för att samla in principrelaterad loggningsinformation i ditt angivna lagringskonto.

Kommentar

Du bör strikt reglera åtkomsten till övervakningsdata, särskilt loggfiler, eftersom de kan innehålla känslig information. Lär dig mer om att tillämpa inbyggd övervakning av Azure-rollen och begränsa åtkomsten.

Enskilda blobbar lagras som text, formaterad som en JSON-blobb.

Nu ska vi titta på en exempelloggpost för en nyckelprincip: Nycklar ska ha förfallodatum angivet. Den här principen utvärderar alla nycklar i dina nyckelvalv och flaggor som inte har ett utgångsdatum inställt som icke-kompatibelt.

{
  "ObjectName": "example",
  "ObjectType": "Key",
  "IsComplianceCheck": false,
  "EvaluationDetails": [
    {
      "AssignmentId": "<subscription ID>",
      "AssignmentDisplayName": "[Preview]: Key Vault keys should have an expiration date",
      "DefinitionId": "<definition ID>",
      "DefinitionDisplayName": "[Preview]: Key Vault keys should have an expiration date",
      "Outcome": "NonCompliant",
      "ExpressionEvaluationDetails": [
        {
          "Result": "True",
          "Expression": "type",
          "ExpressionKind": "Field",
          "ExpressionValue": "Microsoft.KeyVault.Data/vaults/keys",
          "TargetValue": "Microsoft.KeyVault.Data/vaults/keys",
          "Operator": "Equals"
        },
        {
          "Result": "True",
          "Expression": "Microsoft.KeyVault.Data/vaults/keys/attributes.expiresOn",
          "ExpressionKind": "Field",
          "ExpressionValue": "******",
          "TargetValue": "False",
          "Operator": "Exists"
        }
      ]
    }
  ]
}

I följande tabell visas fältnamn och beskrivningar:

Fältnamn beskrivning
ObjectName Objektets namn
ObjectType Typ av nyckelvalvobjekt: certifikat, hemlighet eller nyckel
IsComplianceCheck Sant om utvärderingen inträffade under nattlig granskning, falskt om utvärderingen inträffade när resursen skapades eller uppdaterades
AssignmentId ID för principtilldelningen
AssignmentDisplayName Eget namn på principtilldelningen
DefinitionId ID för principdefinitionen för tilldelningen
DefinitionDisplayName Eget namn på principdefinitionen för tilldelningen
Utfall Resultatet av principutvärderingen
ExpressionEvaluationDetails Information om utvärderingarna som utförs under principutvärderingen
ExpressionValue Det faktiska värdet för det angivna fältet under principutvärderingen
TargetValue Förväntat värde för det angivna fältet

Vanliga frågor och svar

Key Vault-återställning blockerad av Azure-princip

En av anledningarna kan vara att din prenumeration (eller hanteringsgrupp) har en princip som blockerar återställningen. Korrigeringen är att justera principen så att den inte tillämpas när ett valv återställs.

Om du ser feltypen RequestDisallowedByPolicy för återställning på grund av den inbyggda principen kontrollerar du att du använder den mest uppdaterade versionen.

Om du har skapat en anpassad princip med din egen logik, här är ett exempel på en del av en princip som kan användas för att kräva mjuk borttagning. Återställningen av ett mjukt borttaget valv använder samma API som att skapa eller uppdatera ett valv. Men i stället för att ange egenskaperna för valvet har det en enda "createMode"-egenskap med värdet "återställ". Valvet återställs med de egenskaper det hade när det togs bort. Principer som blockerar begäranden om de inte har konfigurerade specifika egenskaper blockerar även återställningen av mjuka borttagna valv. Korrigeringen är att inkludera en -sats som gör att principen ignorerar begäranden där "createMode" är "recover":

Du ser att den har en -sats som gör att principen endast tillämpas när "createMode" inte är lika med "återställ":


    "policyRule": { 
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.KeyVault/vaults"
          }, 
          {
            "not": {
              "field": "Microsoft.Keyvault/vaults/createMode",
              "equals": "recover"
            }
          },
          {
            "anyOf": [
              {
                "field": "Microsoft.KeyVault/vaults/enableSoftDelete",
                "exists": "false"
              },
              {
                "field": "Microsoft.KeyVault/vaults/enableSoftDelete",
                "equals": "false"
              }
            ]
          }
        ]
      },
      "then": {
        "effect": "[parameters('effect')]"
      }
    }

Svarstid för borttagning av Azure-principtilldelning i Key Vault

Microsoft.KeyVault.Data: En borttagen principtilldelning kan ta upp till 24 timmar att sluta tillämpas.

Åtgärd: uppdatera principtilldelningens effekt till "Inaktiverad".

Hemlighetsskapande via ARM-mall går miste om principutvärdering

Dataplansprinciper som utvärderar skapandet av hemligheter skulle inte gälla för hemligheter som skapats via ARM-mallen när hemligheten skapades. Efter 24 timmar, när den automatiserade efterlevnadskontrollen skulle ske, kan efterlevnadsresultaten granskas.

Nästa steg