Грамматика политики выпуска защищенного ключа Azure Key Vault

Статья
07/27/2023

В этой статье описывается упрощенная грамматика EBNF для политики выпуска защищенного ключа, которая основана на политике Azure. Полный пример политики выпуска безопасного ключа см. в политике выпуска ключа конфиденциальной виртуальной машины.

(* 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>
}

В первой итерации допускается только условие тождества "equals", но позднее могут быть добавлены другие операторы, как для Политики Azure (см. раздел об условиях). Если некоторое утверждение отсутствует, его условие считается несоблюденным.

Имена утверждений поддерживают "нотацию с точкой", что позволяет использовать навигацию по объектам JSON, как в этом примере:

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

Спецификации массивов в настоящее время не поддерживаются. В соответствии с грамматикой объекты не могут использоваться в качестве значений для сопоставления.

Условия AnyOf, AllOf

Объекты условий AnOf и AllOf позволяют моделировать логические операции И и ИЛИ. Если указано условие 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: идентификатор центра, создающего утверждения. Этот идентификатор действует так же, как утверждение ISS в JSON Web Token. Он косвенно ссылается на ключ, который подписывает утверждение среды.
allOf: одно или несколько условий утверждения, которые определяют утверждения и значения, которые должны соблюдаться в утверждении среды для успешного применения политики выпуска. Также допускается использование anyOf. Однако их нельзя использовать вместе.

Политика выпуска ключей

Политика выпуска — это условие anyOf, содержащее массив центров сертификации для ключей.

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

Политика выпуска ключей кодирования

Так как политика выпуска ключей имеет формат документа JSON, она кодируется при выполнении запросов и ответов AKV, что позволяет обойтись без полного описания языка в определениях Swagger.

Используется следующий формат кодирования:

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

Утверждение среды

Утверждение среды — это подписанное утверждение доверенного центра в формате JSON Web Token. Оно содержит по меньшей мере ключ шифрования ключа и одно или несколько утверждений о целевой среде (например, тип, издателя и версию TEE), соответствующие политике выпуска ключей. Ключ шифрования ключа — это открытый ключ RSA, принадлежащий целевой среде выполнения и защищенный ею, который используется для экспорта ключа. Он должен отображаться в утверждении ключей TEE (x-ms-runtime/keys). Это утверждение имеет формат объекта JSON и представляет набор веб-ключей JSON. Для JWKS один из этих ключей должен соответствовать требованиям, установленным для использования в качестве ключа шифрования (key_use имеет значение "enc" или key_ops содержит элемент "encrypt"). Будет выбран первый подходящий ключ.

Требования к токену аттестации HSM и Key Vault

Azure Key Vault Premium и управляемый выпуск защищенного ключа HSM были разработаны вместе со службой Microsoft Аттестация Azure, но могут работать с маркерами любого сервера аттестации, если он соответствует ожидаемой структуре токенов, поддерживает подключение OpenID и имеет ожидаемые утверждения. DigiCert в настоящее время является единственным общедоступным ЦС, который Azure Key Vault Premium и управляемое доверие HSM для сертификатов подписывания маркеров аттестации.

Полный набор требований:

— утверждение, определяющее, что издатель является обязательным и соответствует политике SKR для запрашиваемого ключа.
- Издатель должен поддерживать openID Подключение метаданные с помощью сертификата, корневого в ЦС DigiCert.
- В Подключение OpenID необходимы метаданные утверждения jwks_uri и должны разрешаться в набор веб-ключей JSON (JWKS), где каждый JWK в наборе должен содержать детей, kty и массив X5c подписывания сертификатов.
Утверждение x-ms-runtime требуется в качестве объекта JSON, содержащего:
- Массив именованных ключей JSON, представляющих ключи, содержащиеся в подтвержденной среде. Ключи должны быть обычными форматами JWK или массивом x5c (первый ключ берется в качестве ключа подписи, и его ребенок должен соответствовать ключу подписи в OpenId Подключение метаданных).
- Ребенок является обязательным.
- Один из этих ключей должен быть RSA.
- Помечены key_use шифрования или массива key_ops, содержащего операцию Encrypt.

Пример маркера см. в примерах маркера Аттестация Azure.

Поделиться через