Azure Key Vault Preview

Буквально 8 января был выведен в стадию preview новый сервис Azure Key Vault.

Azure Key Vault это — HMS as a Service (Hardware security module ^[1]). HMS — это выделенное hardware, которое позволяет хранить, управлять ключами/секретами и шифровать/расшифровывать, ставить/проверять подписи максимально безопасным образом и достаточно быстро (специфичное железо, заточенное под шифрование, по заявлениям работает быстро, но на сколько или какие делались замеры- информации нет). Ранее KV был известен как BYOK (bring-your-own-key).

Теоретическая часть

Для понимания концепции нужно глянуть на несколько схем и это видео ^[2].
В концепции есть 3 выделенных роли.

1. Те, кто занимаются ключами.
2. Те, кто пишет софт, который использует ключи.
3. Те, кто следит за результатами работы приложений с ключами.

Из моего опыта: первые и третьи в 90% случаях сидят в одном и том-же отделе информационной безопасности, причем третьи смотрят за логами не через призму сопровождения и эксплуатации конкретных приложений, а вообще про использование криптографии. Microsoft выделила 3 роли, т.к. аудитор должен быть независимым от всей остальной компании, чтобы делать независимые оценки.

Для понимания механизма работы нам понадобятся еще 2 схемы

Схему нужно читать справа налево. Администратор создает в Azure Active Directory приложение, загружает в Key Vault ключи/секреты. Для упрощения считаем, что реальное приложение уже написано. Приложение, аутентифицировавшись в AAD, выполняет работу с шифрованием через Key Vault, используя полученный при авторизации токен.

Ниже на схеме показано что может делать каждая роль с key vault.

Как реально все это выглядит через Management Portal можно посмотреть в этой ^[3]и этой ^[4] статье, либо в видео.
Мне не хочется копипастить и к каждому пункту прикладывать powershell команду, их можно прочесть из статьи оригинала, но пример приложу:

Использование для шифрования

При создании Key Vault мы его как-то назвали. На пример mykeyvault.
Мы создали ключ, который будем использовать в примере key-name. У ключа может быть несколько версий (старая версия).
В URL мы должны указать тип операции, которую мы делаем. В примере sign- подпись.
Затем в теле сообщения в виде json передаем 2 параметра: алгоритм и текст, который мы хотим обработать.

В ответ мы получим идентификатор ключа и подписанный текст.

API

Про API, как всегда, особо разговаривать нечего. Microsoft всегда выпускает API ко всем своим сервисам, при этом сам Azure портал использует этот API для доступа.
Список методов- стандартный для шифрования:

У Вас есть 2 варианта работылибо самим написать клиент используя соответствующую документацию, либо использовать готовый .net клиент ^[5] и powershell командлеты ^[6] (сам .net клиент понятное дело в powershell не нуждается). Есть кое-какие примеры ^[7] работы.

API VERSION

API Version — это параметр, его текущее значение — «2014-12-08-preview».
Для тех, кто часто работает с API, необходимость этого параметра и проблемы при его отсутствии очевидны.
Как нетрудно догадаться, в мире нет ничего совершенного, и версия будет меняться, а сам API — становиться несовместимым. Разработчик, единожды написав код, планирует, что он будет работать вечно и далее редко следит за обновлениями сервиса, если по коду нет задач на доработку. Явное указание версии позволит контролировать эти изменения и не споткнуться об автообновление, когда мы ничего не меняли, а нас обвинят в поломке приложения.

Ошибки

О произошедших ошибках можно будет понять 3 способами.

• HTTP код ответа. Тут как всегда- 2** — хорошо, 3** — стоит обратить внимание, 4** — проблемы с авторизацией, 5** — azure плохо.
• В возвращаемом json может быть описание проблемы
  
• аудит

Аудит

Смысл аудита в том, чтобы видеть откуда какое приложение и какие ключи использует, когда оно это делало, а также ошибки.
Команда KV заявляет, что скоро будет доступна возможность мониторинга и аудита использования ключей, быстрый анализ на основе Hadoop… НО в данный момент этого нет.

Железо

Какие конкретно железки стоят в azure не раскрывается, однако, подчеркивается, что они соответствуют американскому стандарту FIPS_140-2 ^[8] (есть 3 версия стандарта от 2009 года) level 2 (всего 4 уровня, 4 самый жесткий.).

В чем я вижу огромный плюс этого сервис для разработчика

Работа с криптографией вынесена из вашего приложения в отдельный, доступный через web-api сервис, не на вашем сервере. Key Vault потенциально снимет кучу головной боли с разработчика (если вы можете использовать его в своем приложении по техническим характеристикам, и это не противоречит политическим мотивам).
Те, кто занимался криптографией на .net в Российских реалиях, не дадут соврать, что достаточно часто шифрование — это какие-нибудь подключаемые нативные библиотеки, которые работают часто только под 32-битной операционной системой, не старше чем какой-нибудь windows xp sp3. И тут либо ты сам выносишь шифрование в виде веб-сервиса и получаешь полный комплект радости от новой сущности (ее же надо мониторить, обучить работать с нею сопровождение, получить еще одну потенциальную точку отказа), либо вынужден согласиться использовать в 2014 году xp sp3 на 32-битной OS.
Еще хуже, когда шифрование предоставлено в виде программы .exe с командным интерфейсом, и приходится еще думать, как с ней взаимодействовать правильно, чтобы при этом выдерживать SLA.

В чем отделу информационной безопасности(ИБ) выгода?

На мой взгляд, отделу ИБ будет на порядок проще управлять ключам шифрования (создавать, отзывать), если они не будут раскиданы по десяткам серверов, а будут собраны в едином Key Vault. Как минимум, ключи нужно периодически менять (0.5-1 года) и сделать это на куче серверов — это обезьянья работа.

На уровне key vault можно ограничивать использование приложениями/пользователями разных ключей и типы операций, которые они могут делать.
Пример: пришел нам из Центрального банка архив, мы знаем, что на нем должна быть подпись, а на каждом файле в архиве — шифрование и авторизация. Соответственно, мы даем приложению, которое работает с этими файлами, права на расшифровку и проверку подписи, но не даем права на шифрование этим ключом и установку подписи и, тем самым, снижаем вероятность неверного использования.
Уверен, что отдел ИБ найдет десяток причин не использовать Key Vault если захочет, но это их работа — никому не доверять.

Цены:

Более детально можно узнать из статьи ^[9], особенно прочитав FAQ в конце статьи, а я расскажу основную мысль.
Есть 2 тарифных плана: standard, premium и есть всего 2 фичи, за которые берутся деньги. 1- это операции с использованием ключей, а 2- это хранение ключей в HSM. В итоге 2 плана отличаются тем, что в плане standard нет хранения ключей в HSM.

«Что такое операция?» — это первый возникающий вопрос! Процитируем:
“Every successfully authenticated REST API call counts as one operation. Examples of operations for keys: create, import, get, list, backup, restore, delete, update, sign, verify, wrap, unwrap, encrypt and decrypt. Examples of operations for secrets: create/update, get, list. ^[10]”
Говоря русским языком, это операции с ключами и секретами (создание ключей, обновление, шифрование, проверка подписей и т.д.).

И еще один хороший, вопрос: «А если ключи выпустил не я, а другой подписчик Azure, то кто платит?» Ответ: тот, кто выпустил, а не тот, кто пользуется.

Ссылки:

• Стартовая ^[11]
• Стартовая для документации ^[12]
• Блог команды авторов ^[13]
• Видео о том, что это такое. ^[2]
• Forum ^[14]
• Использование Key Vault в SQL сервер ^[15]
• Стартовая страница документации на MSDN ^[16]

Автор: SychevIgor

Источник ^[17]