Gramática de la política de liberación de claves seguras de Azure Key Vault
En este artículo se documenta una gramática EBNF simplificada para la directiva de versión de clave segura, que a su vez se modela en Azure Policy. Para ver un ejemplo completo de una directiva de versión de clave segura, consulte la directiva de versión de clave de máquina virtual confidencial.
(* 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 "]" "}";
Condiciones de la notificación
Una condición de notificación es un objeto JSON que identifica un nombre de notificación, una condición para la coincidencia y un valor, por ejemplo:
{
"claim": "<claim name>",
"equals": <value to match>
}
En la primera iteración, la única condición permitida es "igual", pero las iteraciones futuras pueden permitir otros operadores similares a Azure Policy (consulte la sección en Condiciones). Si una notificación especificada no está presente, se considera que su condición no se ha cumplido.
Los nombres de notificación permiten la «notación de puntos» para habilitar la navegación de objetos JSON, por ejemplo:
{
"claim": "object.object.claim",
"equals": <value to match>
}
Actualmente no se admiten las especificaciones de matriz. Según la gramática, los objetos no se permiten como valores para la coincidencia.
Condiciones AnyOf, AllOf
Los objetos de condición AnOf y AllOf permiten el modelado de O e Y. Para AnyOf, si cualquiera de las condiciones proporcionadas es cierta, se cumple la condición. Para AllOf, todas las condiciones deben ser verdaderas.
A continuación se muestran ejemplos. En la primera, allOf requiere que se cumplen todas las condiciones:
{
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"claim": "<claim_2>",
"equals": <value_2>
}
]
}
Significado (claim_1 == value_1) && (claim_2 == value_2).
En este ejemplo, anyOf requiere que cualquier condición coincida:
{
"anyOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"claim": "<claim_2>",
"equals": <value_2>
}
]
}
Significado (claim_1 == value_2) || (claim_2 == value_2)
Los objetos de condición anyOf y allOf pueden estar anidados:
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"anyOf":
[
{
"claim": "<claim_2>",
"equals": <value_2>
},
{
"claim": "<claim_3>",
"equals": <value_3>
}
]
}
]
O:
{
"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>
}
]
}
]
}
]
}
Entidad de lanzamiento clave
Las condiciones se recopilan en instrucciones Authority y se combinan:
{
"authority": "<issuer>",
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
}
]
}
Donde:
- autoridad: identificador de la autoridad que realiza las notificaciones. Este identificador funciona de la misma manera que la notificación iss en un JSON Web Token. Hace referencia indirectamente a una clave que firma la aserción de entorno.
- allOf: una o varias condiciones de notificación que identifican las notificaciones y los valores que deben cumplirse en la aserción del entorno para que la directiva de versión se haga correctamente. también se permite anyOf. Sin embargo, ambos no se permiten juntos.
Política de liberación de claves
La política de versión es una condición anyOf que contiene una matriz de autoridades clave:
{
"anyOf":
[
{
"authority": "my.attestation.com",
"allOf":
[
{
"claim": "mr-signer",
"equals": "0123456789"
}
]
}
]
}
Política de versión de clave de codificación
Puesto que la directiva de versión de clave es un documento JSON, se codifica cuando se incluye en solicitudes y respuesta a AKV para evitar la necesidad de describir el lenguaje completo en las definiciones de Swagger.
La codificación es la siguiente:
{
"contentType": "application/json; charset=utf-8",
"data": "<BASE64URL(JSON serialization of policy)>"
}
Aserción de entorno
Una aserción de entorno es una aserción firmada de una entidad de confianza, en el formulario JSON Web Token. Contiene al menos una clave de cifrado de claves y una o más notificaciones sobre el entorno de destino (por ejemplo, tipo TEE, publicador o versión) que coinciden con la directiva de liberación de claves. La clave de cifrado de claves es una clave RSA pública propiedad del entorno de ejecución de destino y protegida por este que se usa para la exportación de claves. Debe aparecer en la notificación de claves TEE (x-ms-runtime/keys). Esta notificación es un objeto JSON que representa un JSON Web Key Set. Dentro de JWKS, una de las claves debe cumplir los requisitos para su uso como clave de cifrado (key_use es «enc» o key_ops contiene «encrypt»). Se elige la primera clave adecuada.
Requisitos del token de atestación de HSM administrado y Key Vault
Azure Key Vault Premium y la versión de la clave de seguridad de HSM administrado se diseñaron junto con Microsoft Azure Attestation Service, pero pueden funcionar con cualquier token del servidor de atestación siempre que se ajusten a la estructura de tokens esperada, admitan OpenID Connect y tengan las notificaciones esperadas. DigiCert es actualmente la única CA pública que Azure Key Vault Premium y la confianza de HSM administrado para los certificados de firma de tokens de atestación.
El conjunto completo de requisitos es:
La notificación iss que identifica el emisor es necesaria y coincide con la directiva SKR en la clave que se solicita.
El emisor debe admitir metadatos de OpenID Connect mediante un certificado raíz en la CA de DigiCert.
En los metadatos de OpenID Connect, se requiere la notificación jwks_uri y debe resolverse en un conjunto de claves web JSON (JWKS), donde cada JWK del conjunto debe contener un elemento kid, kty y una matriz X5c de certificados de firma.
La notificación x-ms-runtime es necesaria como un objeto JSON que contiene:
Una matriz de claves web JSON denominadas claves que representan las claves que contiene el entorno atestiguado. Las claves deben ser de formato JWK sin formato o matriz x5c (la primera clave se toma como clave de firma y la segunda debe coincidir con una clave de firma en los metadatos de OpenId Connect).
La segunda es necesaria.
Una de esas claves debe ser RSA.
Marcado con la key_use de cifrado o una matriz de key_ops que contiene la operación Encrypt.
Para obtener un token de ejemplo, consulte Ejemplos de un token de Azure Attestation.
Comentarios
Proximamente: Ao longo de 2024, retiraremos gradualmente GitHub Issues como mecanismo de comentarios sobre o contido e substituirémolo por un novo sistema de comentarios. Para obter máis información, consulte: https://aka.ms/ContentUserFeedback.
Enviar e ver os comentarios