Grammatik för säker nyckelfrisättningsprincip i Azure Key Vault

Artikel
08/10/2024

Den här artikeln dokumenterar en förenklad EBNF-grammatik för säker nyckelfrisättningsprincip, som i sig är modellerad enligt Azure Policy. Ett fullständigt exempel på en princip för säker nyckelutgivning finns i den konfidentiella principen för nyckelutgivning av virtuella datorer.

(* string and number from JSON *)
value =
  string |
  number |
  "true" |
  "false";

(* The operators supported for claim value comparison *)
operator =
  "equals:" |
  "notEquals:" |
  "less:" |
  "lessOrEquals:" |
  "greater:" |
  "greaterOrEquals:" |
  "exists:";

(* A JSON condition that evaluates the value of a claim *)
claim_condition =
  "{" "claim:", string "," operator, ":", value "}";

(* A JSON condition requiring any of the listed conditions to be true *)
anyof_condition =
  "{" "anyof:", condition_array "}";

(* A JSON condition requiring all of the listed conditions to be true *)
allof_condition =
  "{" "allof:", condition_array "}";

(* A condition is any of the allowed condition types *)
condition =
  claim_condition |
  anyof_condition |
  allof_condition;

(* A list of conditions, one is required *)
condition_list =
  condition { "," condition };

(* An JSON array of conditions *)
condition_array =
  "[" condition_list "]";

(* A JSON authority with its conditions *)
authority =
  "{" "authority:", string "," ( anyof_condition | allof_condition );

(* A list of authorities, one is required *)
authority_list =
  authority { "," authority_list };

(* A policy is an anyOf selector of authorities *)
policy = 
  "{" "version: \"1.0.0\"", "anyOf:", "[" authority_list "]" "}";

Anspråksvillkor

Ett anspråksvillkor är ett JSON-objekt som identifierar ett anspråksnamn, ett villkor för matchning och ett värde, till exempel:

{ 
  "claim": "<claim name>", 
  "equals": <value to match>
}

I den första iterationen är det enda tillåtna villkoret "lika med" men framtida iterationer kan tillåta andra operatorer som liknar Azure Policy (se avsnittet om villkor). Om ett angivet anspråk inte finns anses dess villkor inte ha uppfyllts.

Anspråksnamn tillåter "punkt notation" för att aktivera JSON-objektnavigering, till exempel:

{ 
  "claim": "object.object.claim", 
  "equals": <value to match>
}

Matrisspecifikationer stöds inte för närvarande. Enligt grammatiken tillåts inte objekt som värden för matchning.

Villkor för AnyOf, AllOf

AnOf- och AllOf-villkorsobjekt tillåter modellering av OR och AND. För AnyOf uppfylls villkoret om något av de angivna villkoren är uppfyllda. För AllOf måste alla villkor vara sanna.

Exempel visas nedan. I det första kräver allOf att alla villkor uppfylls:

{
  "allOf":
  [
    { 
      "claim": "<claim_1>", 
      "equals": <value_1>
    },
    { 
      "claim": "<claim_2>", 
      "equals": <value_2>
    }
  ]
}

Betyder (claim_1 == value_1) && (claim_2 == value_2).

I det här exemplet kräver anyOf att alla villkor matchar:

{
  "anyOf":
  [
    { 
      "claim": "<claim_1>", 
      "equals": <value_1>
    },
    { 
      "claim": "<claim_2>", 
      "equals": <value_2>
    }
  ]
}

Betydelse (claim_1 == value_2) || (claim_2 == value_2)

Villkorsobjekten anyOf och allOf kan vara kapslade:

  "allOf":
  [
    { 
      "claim": "<claim_1>", 
      "equals": <value_1>
    },
    {
      "anyOf":
      [
        { 
          "claim": "<claim_2>", 
          "equals": <value_2>
        },
        { 
          "claim": "<claim_3>", 
          "equals": <value_3>
        }
      ]
    }
  ]

Eller:

{
  "allOf":
  [
    { 
      "claim": "<claim_1>", 
      "equals": <value_1>
    },
    {
      "anyOf":
      [
        { 
          "claim": "<claim_2>", 
          "equals": <value_2>
        },
        {
          "allOf":
          [
            { 
              "claim": "<claim_3>", 
              "equals": <value_3>
            },
            { 
              "claim": "<claim_4>", 
              "equals": <value_4>
            }
          ]
        }
      ]
    }
  ]
}

Utfärdare av viktig version

Villkoren samlas in i myndighetsuttryck och kombineras:

{
  "authority": "<issuer>",
  "allOf":
  [
    { 
      "claim": "<claim_1>", 
      "equals": <value_1>
    }
  ]
}

Där:

myndighet: En identifierare för den myndighet som gör anspråken. Den här identifieraren fungerar på samma sätt som iss-anspråket i en JSON-webbtoken. Den refererar indirekt till en nyckel som signerar miljökontroll.
allOf: Ett eller flera anspråksvillkor som identifierar anspråk och värden som måste uppfyllas i miljöpåståendet för att versionsprincipen ska lyckas. anyOf är också tillåtet. Båda tillåts dock inte tillsammans.

Princip för nyckelutgivning

Versionsprincip är ett anyOf-villkor som innehåller en matris med nyckelmyndigheter:

{
  "anyOf":
  [
    {
      "authority": "my.attestation.com",
      "allOf":
      [
        { 
          "claim": "mr-signer", 
          "equals": "0123456789"
        }
      ]
    }
  ]
}

Kodningsnyckelfrisättningsprincip

Eftersom nyckelfrigivningsprincipen är ett JSON-dokument kodas det när det utförs i begäranden och svar på AKV för att undvika behovet av att beskriva hela språket i Swagger-definitioner.

Kodningen är följande:

{
  "contentType": "application/json; charset=utf-8",
  "data": "<BASE64URL(JSON serialization of policy)>"
}

Miljökontroll

En miljökontroll är en signerad försäkran i formuläret JSON-webbtoken från en betrodd utfärdare. En miljökontroll innehåller minst en nyckelkrypteringsnyckel och ett eller flera anspråk om målmiljön (till exempel TEE-typ, utgivare, version) som matchas mot nyckelfrigöringsprincipen. Nyckelkrypteringsnyckeln är en offentlig RSA-nyckel som ägs och skyddas av målkörningsmiljön som används för nyckelexport. Det måste visas i TEE-nyckelanspråket (x-ms-runtime/keys). Det här anspråket är ett JSON-objekt som representerar en JSON-webbnyckeluppsättning. I JWKS måste en av nycklarna uppfylla kraven för användning som krypteringsnyckel (key_use är "enc" eller key_ops innehåller "kryptering"). Den första lämpliga nyckeln väljs.

Nyckelvalv och hanterade HSM-attesteringstokenkrav

Azure Key Vault Premium och Managed HSM Secure Key Release har utformats tillsammans med Microsoft Azure Attestation Service , men kan fungera med alla attesteringsserverns token om den överensstämmer med den förväntade tokenstrukturen, stöder OpenID Connect och har de förväntade anspråken. DigiCert är för närvarande den enda offentliga certifikatutfärdare som Azure Key Vault Premium och Managed HSM litar på för attesteringstokensigneringscertifikat.

Den fullständiga uppsättningen krav är:

iss-anspråk som identifierar utfärdaren krävs och matchas mot SKR-principen på nyckeln som begärs.
- Utfärdaren måste ha stöd för OpenID Connect-metadata med hjälp av ett certifikat som är rotat i DigiCert CA.
- I OpenID Connect-metadata krävs det jwks_uri anspråket och måste matchas mot en JSON-webbnyckeluppsättning (JWKS), där varje JWK i uppsättningen måste innehålla kid, kty och en X5c-matris med signeringscertifikat.
x-ms-runtime-anspråk krävs som ett JSON-objekt som innehåller:
- En matris med JSON-webbnycklar med namnet nycklar som representerar nycklarna som innehas av den intygade miljön. Nycklarna måste vara oformaterade JWK-format eller x5c-matriser (den första nyckeln tas som signeringsnyckel och dess unge måste matcha en signeringsnyckel i OpenId Connect-metadata).
- Barn krävs.
- En av dessa nycklar måste vara en RSA.
- Markerad med key_use kryptering eller en key_ops matris som innehåller krypteringsåtgärden.

En exempeltoken finns i Exempel på en Azure Attestation-token.

Dela via