Gramatyka zasad bezpiecznego wydania kluczy w usłudze Azure Key Vault
W tym artykule dokumentacji uproszczonej gramatyki EBNF na potrzeby bezpiecznych zasad wydania kluczy, które są modelowane w usłudze Azure Policy. Pełny przykład zasad bezpiecznego wydania klucza można znaleźć w temacie Poufne zasady wydania klucza maszyny wirtualnej.
(* 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 "]" "}";
Warunek oświadczenia
Warunek oświadczenia jest obiektem JSON, który identyfikuje nazwę oświadczenia, warunek dopasowania i wartość, na przykład:
{
"claim": "<claim name>",
"equals": <value to match>
}
W pierwszej iteracji jedynym dozwolonym warunkiem jest "równa się", ale przyszłe iteracji mogą zezwalać na inne operatory podobne do usługi Azure Policy (zobacz sekcję Warunki). Jeśli określone oświadczenie nie jest obecne, jego warunek jest uznawany za nie spełniony.
Nazwy oświadczeń umożliwiają "notację kropki" w celu włączenia nawigacji obiektów JSON, na przykład:
{
"claim": "object.object.claim",
"equals": <value to match>
}
Specyfikacje tablic nie są obecnie obsługiwane. Zgodnie z gramatyką obiekty nie są dozwolone jako wartości do dopasowywania.
AnyOf, AllOf — warunki
Obiekty warunku AnOf i AllOf umożliwiają modelowanie obiektów OR i AND. W przypadku obiektu AnyOf, jeśli którykolwiek z podanych warunków jest spełniony, warunek zostanie spełniony. W przypadku elementu AllOf wszystkie warunki muszą być spełnione.
Poniżej przedstawiono przykłady. Po pierwsze, allOf wymaga spełnienia wszystkich warunków:
{
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"claim": "<claim_2>",
"equals": <value_2>
}
]
}
Znaczenie (claim_1 == value_1) && (claim_2 == value_2).
W tym przykładzie anyOf wymaga dopasowania dowolnego warunku:
{
"anyOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"claim": "<claim_2>",
"equals": <value_2>
}
]
}
Znaczenie (claim_1 == value_2) || (claim_2 == value_2)
Obiekty warunku anyOf i allOf mogą być zagnieżdżone:
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
},
{
"anyOf":
[
{
"claim": "<claim_2>",
"equals": <value_2>
},
{
"claim": "<claim_3>",
"equals": <value_3>
}
]
}
]
Lub:
{
"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>
}
]
}
]
}
]
}
Urząd wydania klucza
Warunki są zbierane w instrukcjach Authority i połączone:
{
"authority": "<issuer>",
"allOf":
[
{
"claim": "<claim_1>",
"equals": <value_1>
}
]
}
Gdzie:
- authority: identyfikator urzędu wysyłającego oświadczenia. Ten identyfikator działa w taki sam sposób, jak oświadczenie iss w tokenie sieci Web JSON. Pośrednio odwołuje się do klucza, który podpisuje asercji środowiska.
- allOf: co najmniej jeden warunek oświadczenia, który identyfikuje oświadczenia i wartości, które muszą być spełnione w asercji środowiska, aby zasady wydania powiodły się. obiekt anyOf jest również dozwolony. Jednak oba te elementy nie są dozwolone razem.
Zasady wydania klucza
Zasady wydania to warunek anyOf zawierający tablicę urzędów kluczy:
{
"anyOf":
[
{
"authority": "my.attestation.com",
"allOf":
[
{
"claim": "mr-signer",
"equals": "0123456789"
}
]
}
]
}
Zasady wydania klucza kodowania
Ponieważ zasady wydania klucza są dokumentem JSON, są kodowane podczas trwania żądań i odpowiedzi na usługę AKV, aby uniknąć konieczności opisywania kompletnego języka w definicjach struktury Swagger.
Kodowanie jest następujące:
{
"contentType": "application/json; charset=utf-8",
"data": "<BASE64URL(JSON serialization of policy)>"
}
Asercji środowiska
Asercji środowiska jest podpisaną asercją w formularzu tokenu internetowego JSON z zaufanego urzędu. Potwierdzenie środowiska zawiera co najmniej klucz szyfrowania klucza i co najmniej jedno oświadczenie dotyczące środowiska docelowego (na przykład typ TEE, wydawca, wersja), które są zgodne z zasadami wydania klucza. Klucz szyfrowania klucza jest publicznym kluczem RSA należącym do środowiska wykonawczego docelowego, który jest używany do eksportowania kluczy. Musi zostać wyświetlony w oświadczeniu kluczy TEE (x-ms-runtime/keys). To oświadczenie jest obiektem JSON reprezentującym zestaw kluczy sieci Web JSON. W usłudze JWKS jeden z kluczy musi spełniać wymagania dotyczące użycia jako klucza szyfrowania (key_use to "enc" lub key_ops zawiera "szyfrowanie"). Wybierany jest pierwszy odpowiedni klucz.
Usługa Key Vault i wymagania dotyczące tokenu zaświadczania zarządzanego modułu HSM
Usługa Azure Key Vault Premium i zarządzana wersja klucza bezpiecznego modułu HSM zostały zaprojektowane razem z usługą zaświadczania platformy Microsoft Azure, ale mogą współpracować z tokenami dowolnego serwera zaświadczania, jeśli jest zgodna z oczekiwaną strukturą tokenów, obsługuje połączenie OpenID i ma oczekiwane oświadczenia. Firma DigiCert jest obecnie jedynym publicznym urzędem certyfikacji, któremu ufa usługa Azure Key Vault Premium i zarządzanemu modułowi HSM na potrzeby certyfikatów podpisywania tokenu zaświadczania.
Pełny zestaw wymagań:
Iss oświadczenia, który identyfikuje wystawcę jest wymagany i jest zgodny z zasadami SKR w żądanym kluczu.
Wystawca musi obsługiwać metadane openID Połączenie przy użyciu certyfikatu rooted w urzędach certyfikacji firmy DigiCert.
W Połączenie OpenID metadanych wymagane jest oświadczenie jwks_uri i musi być rozpoznawane jako zestaw kluczy sieci Web JSON (JWKS), gdzie każdy zestaw JWK w zestawie musi zawierać elementy kid, kty i tablicę X5c certyfikatów podpisywania.
Oświadczenie x-ms-runtime jest wymagane jako obiekt JSON zawierający:
Tablica kluczy sieci Web JSON o nazwie klucze reprezentujące klucze przechowywane przez środowisko testowane. Klucze muszą być zwykłym formatem JWK lub tablicą x5c (pierwszy klucz jest traktowany jako klucz podpisywania, a jego dziecko musi odpowiadać kluczowi podpisywania w identyfikatorze OpenId Połączenie metadanych).
Dziecko jest wymagane.
Jednym z tych kluczy musi być RSA.
Oznaczony key_use szyfrowania lub tablicy key_ops zawierającej operację Szyfruj.
Aby uzyskać przykładowy token, zobacz Przykłady tokenu zaświadczania platformy Azure.