次の方法で共有

Azure Key Vault セキュリティーで保護されたキー リリース ポリシーの文法

  • [アーティクル]

この記事では、セキュリティで保護されたキー リリース ポリシー用の簡略化された EBNF 文法について取り上げ、それ自体は Azure Policy をモデルとしています。 セキュリティで保護されたキーのリリース ポリシーの完全な例については、機密 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 Web Token の iss 要求と同じ方法で機能します。 [環境アサーション] に署名するキーを間接的に参照します。
  • allOf: リリース ポリシーが成功するために環境アサーションで満たす必要がある要求と値を識別する 1 つ以上の要求条件。 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 Web トークン 形式) です。 環境アサーションには、少なくともキー暗号化キーと、キー リリース ポリシーと一致するターゲット環境に関する 1 つ以上の要求 (TEE の型、発行元、バージョンなど) が含まれます。 キー暗号化キーは、キーのエクスポートに使用されるターゲット実行環境によって所有および保護されている公開 RSA キーです。 TEE キー要求 (x-ms-runtime/keys) に表示する必要があります。 この要求は、JSON Web Key Set を表す JSON オブジェクトです。 JWKS 内では、キーの 1 つが暗号化キーとして使用する要件を満たしている必要があります (key_use は "enc"である、またはkey_ops には "encrypt" が含まれている)。 最初の適切なキーが選択されます。

Key Vault とマネージド HSM 構成証明トークンの要件

Azure Key Vault Premium およびマネージド HSM で保護されたキー リリースは、Microsoft Azure Attestation サービスに合わせて設計されています。ただ、想定されるトークン構造に準拠し、OpenID Connect をサポートし、想定される要求がある場合は、任意の構成証明サーバーのトークンで動作させることができます。 DigiCert は現在、構成証明トークン署名証明書に関して Azure Key Vault Premium とマネージド HSM が信頼する唯一のパブリック CA です。

すべての要件は以下のとおりです。

  • 発行者を識別する iss 要求は必須で、要求されているキーの SKR ポリシーに対して照合されます。

    • 発行者は、DigiCert CA をルートとする証明書を使用して OpenID Connect メタデータをサポートする必要があります。

    • OpenID Connect メタデータに jwks_uri 要求が必要で、JSON Web Key セット (JWKS) に解決される必要があります。ここで、セット内の各 JWK に kid、kty、署名証明書の X5c 配列が含まれている必要があります。

  • x-ms-runtime 要求は、以下を含む JSON オブジェクトとして必要です。

    • 構成証明された環境によって保持されるキーを表す、keys という名前の JSON Web Key の配列。 キーは、プレーン JWK 形式または x5c 配列である必要があります (最初のキーは署名キーとして取得され、その kid は OpenId Connect メタデータの署名キーと一致する必要があります)。

    • kid は必須です。

    • これらのキーの 1 つは RSA である必要があります。

    • 暗号化の key_use または Encrypt 操作を含む key_ops 配列でマークされます。

サンプル トークンについては、「Azure Attestation トークンの例」を参照してください。