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

  • Artikel

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

Om Azure Policy for Key Vault

Azure Policy är ett styrningsverktyg som ger användarna möjlighet att granska och hantera sin Azure-miljö i stor skala. Azure Policy gör att du kan placera skyddsmekanismer 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, tillämpning i realtid 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 ökad 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 Storage-konto som du anger. Stegvisa anvisningar finns i Aktivera 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.

Anteckning

Du bör strikt reglera åtkomsten till övervakningsdata, särskilt loggfiler, eftersom de kan innehålla känslig information. Lär dig mer om hur du tillämpar den inbyggda övervakningsrollen i Azure och begränsar å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 ett angivet utgångsdatum. 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 Namnet på objektet
ObjectType Typ av nyckelvalvsobjekt: certifikat, hemlighet eller nyckel
IsComplianceCheck Sant om utvärderingen inträffade under granskning nattetid, falskt om utvärderingen gjordes 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
Resultatet 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 som blockeras av Azure Policy

En av orsakerna 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 är hä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 "recover". Valvet återställs med de egenskaper som fanns när det togs bort. Principer som blockerar begäranden om de inte har specifika egenskaper konfigurerade blockerar även återställningen av mjukt 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 vid borttagning av Azure-principtilldelning på 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".

Principutvärdering saknas när en hemlighet skapas via ARM-mallen

Dataplansprinciper som utvärderar skapande av hemligheter kan inte tillämpas på hemligheter som skapats via EN ARM-mall när hemligheten skapas. Efter 24 timmar, när den automatiserade kompatibilitetskontrollen skulle ske, och efterlevnadsresultaten kan granskas.

Nästa steg