Azure Key Vault der Richtliniengrammatik für sichere Schlüsselfreigaben
In diesem Artikel wird eine vereinfachte EBNF-Grammatik für die Richtlinie für die Freigabe sicherer Schlüssel beschrieben, die selbst auf der Azure Policy basiert. Ein vollständiges Beispiel für eine Freigaberichtlinie für sichere Schlüssel finden Sie in der Releaserichtlinie für vertrauliche VM-Schlüssel.
(* 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 "]" "}";
Anspruchsbedingung
Eine Anspruchsbedingung ist ein JSON-Objekt, das einen Anspruchsnamen, eine Bedingung für den Abgleich und einen Wert identifiziert, z. B.:
{
"claim": "<claim name>",
"equals": <value to match>
}
In der ersten Iteration ist die einzige zulässige Bedingung "equals", aber zukünftige Iterationen können andere Operatoren zulassen, die der Azure Policy ähneln (siehe Abschnitt zu Bedingungen). Wenn ein angegebener Anspruch nicht vorhanden ist, wird seine Bedingung als nicht erfüllt angesehen.
Anspruchsnamen ermöglichen "dot notation", um die JSON-Objektnavigation zu aktivieren, z. B.:
{
"claim": "object.object.claim",
"equals": <value to match>
}
Arrayspezifikationen werden derzeit nicht unterstützt. Nach der Grammatik sind Objekte nicht als Werte für den Abgleich zulässig.
AnyOf-, AllOf-Bedingungen
AnOf- und AllOf-Bedingungsobjekte ermöglichen die Modellierung von OR und AND. Wenn eine der angegebenen Bedingungen für AnyOf true ist, wird die Bedingung erfüllt. Für AllOf müssen alle Bedingungen erfüllt sein.
Im Anschluss finden Sie einige Beispiele. Im ersten Schritt erfordert allOf, dass alle Bedingungen erfüllt sind:
{
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"claim": "<claim_2>",
"equals": <value_2>
}
]
}
Bedeutung (claim_1 == value_1) && (claim_2 == value_2).
In diesem Beispiel erfordert anyOf, dass alle Bedingungen übereinstimmen:
{
"anyOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"claim": "<claim_2>",
"equals": <value_2>
}
]
}
Das bedeutet: (claim_1 == value_2) || (claim_2 == value_2)
Die AnyOf- und allOf-Bedingungsobjekte können geschachtelt sein:
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"anyOf":
[
{
"claim": "<claim_2>",
"equals": <value_2>
},
{
"claim": "<claim_3>",
"equals": <value_3>
}
]
}
]
Oder:
{
"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>
}
]
}
]
}
]
}
Schlüsselfreigabestelle
Bedingungen werden in Authority-Anweisungen gesammelt und kombiniert:
{
"authority": "<issuer>",
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
}
]
}
Hierbei gilt:
- authority: Ein Bezeichner für die Stelle, die die Ansprüche stellt. Dieser Bezeichner funktioniert auf die gleiche Weise wie der iss-Anspruch in JSON Web Token. Indirekt wird auf einen Schlüssel verwiesen, der die Umgebungs-Assertion signiert.
- allOf: Eine oder mehrere Anspruchsbedingungen, die Ansprüche und Werte identifizieren, die in der Umgebungs-Assertion erfüllt werden müssen, damit die Releaserichtlinie erfolgreich ist. anyOf ist ebenfalls zulässig. Beides ist jedoch nicht zusammen zulässig.
Schlüsselfreigaberichtlinie
Die Freigaberichtlinie ist eine anyOf-Bedingung, die ein Array von Schlüsselstellen enthält:
{
"anyOf":
[
{
"authority": "my.attestation.com",
"allOf":
[
{
"claim": "mr-signer",
"equals": "0123456789"
}
]
}
]
}
Richtlinie für die Codierungsschlüsselfreigabe
Da die Schlüsselfreigaberichtlinie ein JSON-Dokument ist, wird sie codiert, wenn sie in Anforderungen und antworten an AKV übertragen wird, um zu vermeiden, dass die vollständige Sprache in Swagger-Definitionen beschrieben werden muss.
Die Codierung lautet wie folgt:
{
"contentType": "application/json; charset=utf-8",
"data": "<BASE64URL(JSON serialization of policy)>"
}
Umgebungs-Assertion
Eine Umgebungs-Assertion ist eine signierte Assertion im JSON-Webtokenformat von einer vertrauenswürdigen Autorität. Eine Umgebungs-Assertion enthält mindestens einen Schlüsselverschlüsselungsschlüssel und mindestens einen Anspruch über die Zielumgebung (z. B. TEE-Typ, Herausgeber, Version), die mit der Schlüsselfreigaberichtlinie übereinstimmen. Der Schlüsselverschlüsselungsschlüssel ist ein öffentlicher RSA-Schlüssel, der im Besitz der Zielausführungsumgebung ist, die für den Schlüsselexport verwendet wird, und von dieser auch geschützt wird. Er muss im TEE-Schlüsselanspruch (x-ms-runtime/keys) vorkommen. Dieser Anspruch ist ein JSON-Objekt, das einen JSON Web Key darstellt. Innerhalb des JWKS muss einer der Schlüssel die Anforderungen für die Verwendung als Verschlüsselungsschlüssel erfüllen (key_use ist "enc", bzw. key_ops enthält "encrypt"). Der erste geeignete Schlüssel wird ausgewählt.
Anforderungen für Key Vault und Managed HSM Attestation Token
Azure Key Vault Premium und Managed HSM Secure Key Release wurden zusammen mit dem Microsoft Azure Attestation Service entwickelt, können aber mit den Token eines beliebigen Attestationsservers arbeiten, wenn dieser der erwarteten Tokenstruktur entspricht, OpenID Connect unterstützt und die erwarteten Ansprüche hat. DigiCert ist derzeit die einzige öffentliche Zertifizierungsstelle, der Azure Key Vault Premium und Managed HSM für das Signieren von Zertifikaten mit Attestierungstoken vertrauen.
Sämtliche Anforderungen sind:
iss-Anspruch, der den Aussteller identifiziert, ist erforderlich und wird mit der SKR-Richtlinie für den angeforderten Schlüssel abgeglichen.
Der Aussteller muss OpenID Connect Metadaten unterstützen, indem er ein Zertifikat verwendet, das von DigiCert CA stammt.
In den OpenID Connect-Metadaten ist der jwks_uri-Anspruch erforderlich und muss in ein JSON Web Key Set (JWKS) aufgelöst werden, wobei jedes JWK in der Gruppe kid, kty und ein X5c-Array von Signierzertifikaten enthalten muss.
Der x-ms-runtime-Anspruch wird als JSON-Objekt benötigt, das Folgendes enthält:
Ein Array von JSON Web Keys mit dem Namen keys, die die Schlüssel der bescheinigten Umgebung darstellen. Die Schlüssel müssen im einfachen JWK-Format oder als x5c-Array vorliegen (der erste Schlüssel wird als Signierschlüssel verwendet und sein kid muss mit einem Signierschlüssel in den OpenId Connect-Metadaten übereinstimmen).
Kid ist erforderlich.
Einer dieser Schlüssel muss ein RSA sein.
Gekennzeichnet mit key_use der Verschlüsselung oder einem key_ops-Array, das den Verschlüsselungsvorgang Encrypt enthält.
Ein Beispieltoken finden Sie unter Beispiele für ein Azure Attestation-Token (Nachweistoken).