Grammaire de la stratégie de mise en production de la clé de sécurité Azure Key Vault
Cet article documente une grammaire EBNF simplifiée pour la stratégie de mise en production de clé sécurisée, qui est modélisée sur Azure Policy. Pour obtenir un exemple complet de stratégie de mise en production de clé sécurisée, consultez la stratégie de mise en production de clé de machine virtuelle confidentielle.
(* 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 "]" "}";
Condition de revendication
Une condition de revendication est un objet JSON qui identifie un nom de revendication, une condition de correspondance et une valeur, par exemple :
{
"claim": "<claim name>",
"equals": <value to match>
}
Dans la première itération, la seule condition autorisée est « égal à », mais les itérations futures peuvent autoriser d’autres opérateurs similaires à Azure Policy (voir la section sur les Conditions). Si une revendication spécifiée n’est pas présente, sa condition est considérée comme n’ayant pas été remplie.
Les noms de revendications autorisent la « notation par points » pour activer la navigation dans les objets JSON, par exemple :
{
"claim": "object.object.claim",
"equals": <value to match>
}
Les spécifications de tableaux ne sont actuellement pas prises en charge. Selon la grammaire, les objets ne sont pas autorisés comme valeurs pour la correspondance.
Conditions AnyOf, AllOf
Les objets de condition AnOf et AllOf autorisent la modélisation de OR et AND. Pour AnyOf, si l’une des conditions fournies est vraie, la condition est remplie. Pour AllOf, toutes les conditions doivent avoir la valeur true.
Des exemples sont présentés ci-dessous. Dans le premier cas, AllOf requiert que toutes les conditions soient remplies :
{
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"claim": "<claim_2>",
"equals": <value_2>
}
]
}
Signification (claim_1 == value_1) && (claim_2 == value_2).
Dans cet exemple, AnyOf requiert que toutes les conditions correspondent :
{
"anyOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"claim": "<claim_2>",
"equals": <value_2>
}
]
}
Signification (claim_1 == value_2) || (claim_2 == value_2)
Les objets de condition AnyOf et AllOf peuvent être imbriqués :
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"anyOf":
[
{
"claim": "<claim_2>",
"equals": <value_2>
},
{
"claim": "<claim_3>",
"equals": <value_3>
}
]
}
]
Ou :
{
"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>
}
]
}
]
}
]
}
Autorité de mise en production de la clé
Les conditions sont collectées dans les instructions d’autorité et combinées :
{
"authority": "<issuer>",
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
}
]
}
Où :
- autorité : identificateur de l’autorité qui effectue les revendications. Cet identificateur fonctionne de la même façon que la revendication ISS dans un JSON Web Token. Il fait indirectement référence à une clé qui signe l’assertion de l’environnement.
- AllOf : une ou plusieurs conditions de revendication qui identifient les revendications et les valeurs devant être satisfaites dans l’assertion d’environnement pour que la stratégie de mise en production aboutisse. AnyOf est également autorisé. Toutefois, les deux ne sont pas autorisés ensemble.
Stratégie de mise en production de la clé
La stratégie de mise en production est une condition AnyOf contenant un tableau d’autorités de clé :
{
"anyOf":
[
{
"authority": "my.attestation.com",
"allOf":
[
{
"claim": "mr-signer",
"equals": "0123456789"
}
]
}
]
}
Stratégie de mise en production de la clé d’encodage
Étant donné que la stratégie de mise en production de la clé est un document JSON, elle est encodée quand elle est exécutée dans les demandes et la réponse à AKV pour éviter d’avoir à décrire la totalité du langage dans les définitions Swagger.
L’encodage est le suivant :
{
"contentType": "application/json; charset=utf-8",
"data": "<BASE64URL(JSON serialization of policy)>"
}
Assertion d’environnement
Une assertion d’environnement est une assertion signée, sous forme de jeton web JSON, d’une autorité approuvée. Une assertion d’environnement contient au moins une clé de chiffrement à clé et une ou plusieurs revendications relatives à l’environnement cible (par exemple, type TEE, éditeur, version) mises en correspondance avec la stratégie de mise en production de la clé. La clé de chiffrement de clé est une clé RSA publique détenue et protégée par l’environnement d’exécution cible utilisé pour l’exportation de clé. Elle doit apparaître dans la revendication de clés TEE (x-ms-runtime/keys). Cette revendication est un objet JSON qui représente un jeu de clés web JSON. Dans le jeu JWKS, l’une des clés doit remplir les exigences pour une utilisation en tant que clé de chiffrement (key_use est « enc », ou key_ops contient « encrypt »). La première clé appropriée est choisie.
Exigences relatives aux jetons d’attestation Key Vault et HSM managés
Azure Key Vault Premium et la mise en production de clé sécurisée HSM managée ont été conçus avec la Service Microsoft Azure Attestation, mais peuvent fonctionner avec les jetons du serveur d’attestation s’ils sont conformes à la structure attendue des jetons, prennent en charge la connexion OpenID et disposent des revendications attendues. DigiCert est actuellement la seule autorité de certification publique approuvée par Azure Key Vault Premium et HSM managé pour les certificats de signature de jetons d’attestation.
L’ensemble complet des exigences est :
La revendication iss, qui identifie l’émetteur, est obligatoire et est mise en correspondance avec la stratégie SKR sur la clé demandée.
L’émetteur doit prendre en charge les métadonnées OpenID Connect à l’aide d’un certificat enraciné à travers l’autorité de certification DigiCert.
Dans les métadonnées OpenID Connect, la revendication jwks_uri est requise et doit être résolue en un jeu de clés Web JSON (JWKS), où chaque clé Web JSON de l’ensemble doit contenir les paramètres kid, kty et un tableau X5c des certificats de signature.
La revendication x-ms-runtime est requise en tant qu’objet JSON contenant :
Un tableau de clés Web JSON, nommées clés, qui représentent les clés détenues par l’environnement attesté. Les clés doivent être au format brut de clé Web JSON ou tableau x5c (la première clé est prise comme clé de signature et son kid doit correspondre à une clé de signature dans les métadonnées OpenId Connect).
Le paramètre kid est obligatoire.
L’une de ces clés doit être une clé RSA.
Marqué avec key_use de chiffrement ou un tableau key_ops contenant l’opération de chiffrement.
Pour obtenir un échantillon de jeton, consultez Échantillon d’un jeton Azure Attestation.