Grammatica van beleid voor veilige sleutelrelease van Azure Key Vault
In dit artikel wordt een vereenvoudigde EBNF-grammatica voor beveiligd sleutelreleasebeleid, dat zelf is gemodelleerd in Azure Policy. Zie het beleid voor het vrijgeven van vertrouwelijke VM-sleutels voor een volledig voorbeeld van een beveiligd sleutelreleasebeleid.
(* 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 "]" "}";
Claimvoorwaarde
Een claimvoorwaarde is een JSON-object dat een claimnaam, een voorwaarde voor overeenkomst en een waarde identificeert, bijvoorbeeld:
{
"claim": "<claim name>",
"equals": <value to match>
}
In de eerste iteratie is de enige toegestane voorwaarde gelijk aan, maar toekomstige iteraties kunnen andere operators die vergelijkbaar zijn met Azure Policy toestaan (zie de sectie over Voorwaarden). Als een opgegeven claim niet aanwezig is, wordt de voorwaarde ervan beschouwd als niet voldaan.
Claimnamen staan 'punt notatie' toe om navigatie van JSON-objecten in te schakelen, bijvoorbeeld:
{
"claim": "object.object.claim",
"equals": <value to match>
}
Matrixspecificaties worden momenteel niet ondersteund. Volgens de grammatica zijn objecten niet toegestaan als waarden voor overeenkomende waarden.
AnyOf, AllOf-voorwaarden
AnOf- en AllOf-voorwaardeobjecten maken het modelleren van OR en AND mogelijk. Voor AnyOf, als aan een van de opgegeven voorwaarden is voldaan, wordt aan de voorwaarde voldaan. Voor AllOf moeten alle voorwaarden waar zijn.
Hieronder ziet u voorbeelden. In de eerste plaats vereist allOf dat aan alle voorwaarden wordt voldaan:
{
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"claim": "<claim_2>",
"equals": <value_2>
}
]
}
Betekenis (claim_1 == value_1) && (claim_2 == value_2).
In dit voorbeeld vereist anyOf dat een voorwaarde overeenkomt:
{
"anyOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"claim": "<claim_2>",
"equals": <value_2>
}
]
}
Betekenis (claim_1 == value_2) || (claim_2 == value_2)
De anyOf- en allOf-voorwaardeobjecten kunnen worden genest:
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"anyOf":
[
{
"claim": "<claim_2>",
"equals": <value_2>
},
{
"claim": "<claim_3>",
"equals": <value_3>
}
]
}
]
Of:
{
"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>
}
]
}
]
}
]
}
Instantie voor sleutelrelease
Voorwaarden worden verzameld in autoriteitsverklaringen en gecombineerd:
{
"authority": "<issuer>",
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
}
]
}
Hierin:
- instantie: een id voor de instantie die de claims maakt. Deze id werkt op dezelfde manier als de iss-claim in een JSON-webtoken. Het verwijst indirect naar een sleutel die de Environment Assertion ondertekent.
- allOf: een of meer claimvoorwaarden waarmee claims en waarden worden geïdentificeerd waaraan moet worden voldaan in de omgevingsverklaring om het releasebeleid te laten slagen. anyOf is ook toegestaan. Beide zijn echter niet samen toegestaan.
Beleid voor sleutelrelease
Releasebeleid is een anyOf-voorwaarde met een matrix met sleutelinstanties:
{
"anyOf":
[
{
"authority": "my.attestation.com",
"allOf":
[
{
"claim": "mr-signer",
"equals": "0123456789"
}
]
}
]
}
Sleutelreleasebeleid coderen
Omdat key release-beleid een JSON-document is, wordt het gecodeerd wanneer het wordt uitgevoerd in aanvragen en reactie op AKV om te voorkomen dat de volledige taal in Swagger-definities moet worden beschreven.
De codering is als volgt:
{
"contentType": "application/json; charset=utf-8",
"data": "<BASE64URL(JSON serialization of policy)>"
}
Omgevingsverklaring
Een omgevingsverklaring is een ondertekende assertie, in het formulier JSON-webtoken, van een vertrouwde instantie. Een omgevingsbeveiliging bevat ten minste een sleutelversleutelingssleutel en een of meer claims over de doelomgeving (bijvoorbeeld TEE-type, uitgever, versie) die overeenkomen met het sleutelreleasebeleid. De sleutelversleutelingssleutel is een openbare RSA-sleutel die eigendom is van en wordt beveiligd door de doeluitvoeringsomgeving die wordt gebruikt voor sleutelexport. Deze moet worden weergegeven in de TEE-sleutelsclaim (x-ms-runtime/keys). Deze claim is een JSON-object dat een JSON-websleutelset vertegenwoordigt. Binnen de JWKS moet een van de sleutels voldoen aan de vereisten voor gebruik als versleutelingssleutel (key_use is 'enc' of key_ops 'versleutelen' bevat). De eerste geschikte sleutel wordt gekozen.
Vereisten voor Key Vault- en beheerde HSM-attestation-token
Azure Key Vault Premium en Managed HSM Secure Key Release zijn ontworpen naast Microsoft Azure Attestation Service , maar kunnen werken met de tokens van een attestation-server als deze voldoet aan de verwachte tokenstructuur, ondersteuning biedt voor OpenID-verbinding en de verwachte claims heeft. DigiCert is momenteel de enige openbare CA die azure Key Vault Premium en beheerde HSM-vertrouwensrelatie voor certificaten voor attestation-tokenondertekening ondersteunt.
De volledige set vereisten is:
iss claim die de verlener identificeert is vereist en wordt vergeleken met het SKR-beleid voor de sleutel die wordt aangevraagd.
Verlener moet OpenID Verbinding maken Metagegevens ondersteunen met behulp van een certificaat dat is geroot in digicert-CA.
In de OpenID Verbinding maken Metagegevens is de jwks_uri claim vereist en moet deze worden omgezet in een JSON Web Key Set (JWKS), waarbij elke JWK in de set kind, kty en een X5c-matrix met handtekeningcertificaten moet bevatten.
x-ms-runtime-claim is vereist als een JSON-object met:
Een matrix van JSON-websleutels met de naam sleutels die de sleutels vertegenwoordigen die door de geteste omgeving worden bewaard. De sleutels moeten een gewone JWK-indeling of x5c-matrix zijn (de eerste sleutel wordt gebruikt als de ondertekeningssleutel en het kind moet overeenkomen met een ondertekeningssleutel in OpenId Verbinding maken metagegevens).
Kind is vereist.
Een van deze sleutels moet een RSA zijn.
Gemarkeerd met key_use van versleuteling of een key_ops-matrix die de bewerking Versleutelen bevat.
Zie Voorbeelden van een Azure Attestation-token voor een voorbeeldtoken.