Azure Key Vault 보안 키 릴리스 정책 문법

아티클
09/27/2023

이 문서에서는 자체적으로 Azure Policy를 모델링한 보안 키 릴리스 정책에 대해 간소화된 EBNF 문법을 설명합니다. 보안 키 릴리스 정책의 전체 예제는 기밀 VM 키 릴리스 정책을 참조하세요.

(* 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 "]" "}";

클레임 조건

클레임 조건은 클레임 이름, 일치 조건 및 값을 식별하는 JSON 개체입니다. 예를 들면 다음과 같습니다.

{ 
  "claim": "<claim name>", 
  "equals": <value to match>
}

첫 번째 반복에서 허용되는 유일한 조건은 "같음"이지만 이후 반복에서는 Azure Policy와 유사한 다른 연산자를 허용할 수 있습니다(조건 섹션 참조). 지정된 클레임이 없으면 해당 조건이 충족되지 않은 것으로 간주됩니다.

클레임 이름은 JSON 개체 탐색이 가능하도록 "점 표기법"을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

{ 
  "claim": "object.object.claim", 
  "equals": <value to match>
}

배열 사양은 현재 지원되지 않습니다. 문법에 따라 개체는 일치 값으로 허용되지 않습니다.

AnyOf, AllOf 조건

AnOf 및 AllOf 조건 개체는 OR 및 AND의 모델링을 허용합니다. AnyOf의 경우 제공된 조건 중 true가 있으면 조건이 충족됩니다. AllOf의 경우 모든 조건이 true여야 합니다.

예제는 다음과 같습니다. 첫 번째에서 allOf는 모든 조건을 충족해야 합니다.

{
  "allOf":
  [
    { 
      "claim": "<claim_1>", 
      "equals": <value_1>
    },
    { 
      "claim": "<claim_2>", 
      "equals": <value_2>
    }
  ]
}

의미(claim_1 == value_1) &&(claim_2 == value_2).

이 예제에서 anyOf는 임의의 조건이 일치해야 합니다.

{
  "anyOf":
  [
    { 
      "claim": "<claim_1>", 
      "equals": <value_1>
    },
    { 
      "claim": "<claim_2>", 
      "equals": <value_2>
    }
  ]
}

즉, (claim_1 == value_2) || (claim_2 == value_2)여야 합니다.

anyOf 및 allOf 조건 개체는 중첩될 수 있습니다.

  "allOf":
  [
    { 
      "claim": "<claim_1>", 
      "equals": <value_1>
    },
    {
      "anyOf":
      [
        { 
          "claim": "<claim_2>", 
          "equals": <value_2>
        },
        { 
          "claim": "<claim_3>", 
          "equals": <value_3>
        }
      ]
    }
  ]

또는

{
  "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>
            }
          ]
        }
      ]
    }
  ]
}

키 릴리스 기관

조건은 Authority 문으로 수집되고 결합됩니다.

{
  "authority": "<issuer>",
  "allOf":
  [
    { 
      "claim": "<claim_1>", 
      "equals": <value_1>
    }
  ]
}

여기서

authority: 클레임을 하는 권한의 식별자입니다. 이 식별자는 JSON 웹 토큰의 iss 클레임과 동일한 방식으로 작동합니다. 환경 어설션에 서명하는 키를 간접적으로 참조합니다.
allOf: 릴리스 정책이 성공하기 위해 환경 어설션에서 충족해야 하는 클레임 및 값을 식별하는 하나 이상의 클레임 조건입니다. anyOf도 허용됩니다. 그러나 둘 다 함께 사용할 수는 없습니다.

키 릴리스 정책

릴리스 정책은 키 기관 배열을 포함하는 anyOf 조건입니다.

{
  "anyOf":
  [
    {
      "authority": "my.attestation.com",
      "allOf":
      [
        { 
          "claim": "mr-signer", 
          "equals": "0123456789"
        }
      ]
    }
  ]
}

키 릴리스 정책 인코딩

키 릴리스 정책은 JSON 문서이므로 Swagger 정의에서 전체 언어를 설명할 필요가 없도록 AKV에 대한 요청 및 응답으로 전달될 때 인코딩됩니다.

인코딩은 다음과 같습니다.

{
  "contentType": "application/json; charset=utf-8",
  "data": "<BASE64URL(JSON serialization of policy)>"
}

환경 어설션

환경 어설션은 신뢰할 수 있는 기관의 서명된 어설션(JSON 웹 토큰 형식)입니다. 환경 어설션은 키 릴리스 정책과 일치하는 대상 환경(예: TEE 유형, 게시자, 버전)에 대한 하나 이상의 클레임과 하나 이상의 키 암호화 키를 포함합니다. 키 암호화 키는 대상 실행 환경에서 소유하고 보호하는 공용 RSA 키로, 키 내보내기에 사용됩니다. TEE 키 클레임(x-ms-runtime/keys)에 표시되어야 합니다. 이 클레임은 JSON 웹 키 집합을 나타내는 JSON 개체입니다. JWKS 내에서 키 중 하나는 암호화 키로 사용하기 위한 요구 사항을 충족해야 합니다(key_use는 "enc"이거나 key_ops에 "encrypt"를 포함). 첫 번째 적합한 키가 선택됩니다.

Key Vault 및 관리형 HSM 증명 토큰 요구 사항

Azure Key Vault 프리미엄 및 관리형 HSM 보안 키 릴리스는 Microsoft Azure Attestation Service와 함께 설계되었지만 예상된 토큰 구조를 준수하고 OpenID 연결을 지원하며 예상 클레임이 있는 경우 증명 서버의 토큰과 함께 작동할 수 있습니다. DigiCert는 현재 Azure Key Vault 프리미엄 및 관리형 HSM이 증명 토큰 서명 인증서에 대해 신뢰하는 유일한 공용 CA입니다.

전체 요구 사항은 다음과 같습니다.

iss는 발급자를 식별하는 클레임이 필요하며 요청되는 키에 대한 SKR 정책과 일치합니다.
- 발급자는 DigiCert CA에 루트된 인증서를 사용하여 OpenID Connect 메타데이터를 지원해야 합니다.
- OpenID Connect 메타데이터에서 jwks_uri 클레임이 필요하며 JWKS(JSON Web Key 집합)에 대해 확인해야 합니다. 여기서 집합의 각 JWK에는 서명 인증서의 kid, kty 및 X5c 배열이 포함되어야 합니다.
x-ms-runtime 클레임은 다음을 포함하는 JSON 개체로 필요합니다.
- 증명된 환경에서 보유하는 키를 나타내는 키라는 JSON 웹 키의 배열입니다. 키는 일반 JWK 형식 또는 x5c 배열이어야 합니다(첫 번째 키는 서명 키로 사용되며 해당 kid는 OpenId Connect 메타데이터의 서명 키와 일치해야 합니다).
- kid가 필요합니다.
- 이러한 키 중 하나는 RSA여야 합니다.
- 암호화 key_use 또는 암호화 작업이 포함된 key_ops 배열로 표시됩니다.

샘플 토큰은 Azure Attestation 토큰의 예제를 참조하세요.

다음을 통해 공유