Опыт использования облака в управлении контроля доступа к базам данных в программном проекте

Выражаем большое спасибо за подготовку статьи Синицину Николаю, старшему инженеру-программисту компании Аплана, за помощь в написании данной статьи. Остальные наши статьи по теме Azure можно найти по тегу azureweek


Привет!
Как-то в одном из проектов поставили задачу, условиями которой являлось обеспечение необходимости ПО обращения к различным базам данных с регламентацией доступа – буквально, у кого есть лицензия, тем давать доступ, иначе блокировать доступ. Дополнительно нужно было иметь возможность менять соединение на другую базу данных, и чтобы ПО узнало, что сменился адрес. Было найдено несколько способов это сделать, но в конце концов пришли к варианту использования облачных сервисов Azure – о том, как принималось решение и зачем и как мы использовали облако – читайте под катом.
Сначала думали пойти по пути достаточно очевидному — есть базы данных, на каждой базе данных заведены пользователи, у которых есть «лицензии». Проблему доступа решили, но, как вы наверняка понимаете, очень неудобно управлять подобной системой – добавлять, удалять пользователей. Дабы решить проблему смены серверов, необходимо было бы писать некий условный сервис, который бы также хранил в себе пользователей, у которых есть доступ. И все бы знали адрес, где располагается сервер базы данных.

У данного метода есть несколько минусов:

  • Нужно писать сервис;
  • Нет единого хранилища пользователей с доступом к системе;
  • Тяжело поддерживать актуальность данных по пользователям на различных БД.


Пройдемся по минусам.

Минус: Нужно писать сервис.

«Какой сервис нам необходим был», спросите Вы. Сервис по управлению контроля доступа к базам данных для программных продуктов развернутых на различных машинах. Написание сервисов – это неплохо. Но, когда необходимо писать сервис с нуля, есть возможность поймать различные ошибки, в т.ч. самые сложные – человеческие. Особенно это актуально, когда пишешь сервис контроля доступа и распределения ролей. Одна ошибка – и вместо того, чтобы дать одному пользователю права на ресурс, можно столкнуться с тем, что права даны бОльшему количеству. Цена ошибки очень велика.

Минус: Нет единого хранилища пользователей с доступом к системе.

Помимо того, что должен быть сервис, который позволит предоставлять различный доступ, необходим единая база данных пользователей и менеджер управления, который легко позволит управлять данной базой данных. Писать самому с самого начала = потратить много времени.

Минус: Тяжело поддерживать актуальность данных по пользователям на различных БД.

Если использовать вариант, в котором на каждой базе данных заведены пользователи, мы имеем проблему синхронизации нескольких баз данных между собой.

В связи с тем, что есть описанные проблемы, было принято решение посмотреть на облачные сервисы, которые позволят решить поставленные задачи и минимизировать или полностью избавиться от вышеперечисленных минусов + была возможность возникновение перехода на облачную базу данных и развертывание сайта в облаке.

t-z_7cj-5z01dm7cu7x53k14

Рассмотрим кратко облачные сервисы, которые были проанализированы и использованы в решении поставленной задачи:

Azure Active Directory (AAD или Azure AD) — многопользовательский облачный каталог и служба управления удостоверениями. Она схожа по работе с Active directory, которая поставляется совместно с Windows Server. Однако, AAD предназначена для работы пользователей не в локальной инфраструктуре компании, а при работе с облачными приложениями (Например Azure Key Vault) С помощью данного сервиса мы решаем проблемы «нет единого хранилища пользователей с доступом к системе» и «тяжело поддерживать актуальность данных по пользователям на различных БД». Недавно было анонсировано, что AAD будет поддерживать возможность развертывания доменов.

Azure Key VaultHMS as a Service (Hardware security module). HMS — это выделенное hardware, которое позволяет хранить, управлять ключами/секретами и шифровать/расшифровывать, ставить/проверять подписи максимально безопасным образом и достаточно быстро (специфичное железо, заточенное под шифрование, по заявлениям работает быстро, но на сколько или какие делались замеры- информации нет). Ранее KV был известен как BYOK (bring-your-own-key). (Ссылка на статью). С помощью данного сервиса можно хранить секреты связанные с доступом к той или иной БД (логин, пароль, адрес, тип БД и т.д.) Тем самым пользователей авторизованный с помощью AAD получает Token с помощью, которого получает доступ к секрету. И программа, исходя из этих данных, соединяется с нужной БД.

1ur1pkjxl4n-1d09o5lqu_a3m

Использование Azure Active Directory и Azure Key Vault

На схеме выше видно, что управление доступом, единое хранилище пользователей и менеджер управления передано на сторону облачных сервисов, таких как AAD и Azure Key Vault. Схема взаимодействия очень проста. Каждый пользователь ПО знает логин и пароль, который ему выдал администратор сервиса. С помощью него программа авторизуется в AAD и получает авторизационный токен, с помощью которого программный продукт получает доступ к сервису Azure Key Vault в котором хранятся секреты. Дальше используя секреты, ПО устанавливает соединение с базой данных.
В случае, если необходимо удалить доступ к БД, можно удалить пользователя из AAD и сгенерировать новый пароль к БД. Остальные системы, потеряв соединение запросят заново секрет и установят соединение.
Если мы меняем адрес или расположение БД, нам необходимо только поменять информацию в секрете и система автоматически соединится с другой БД, которая придет в информации от Key Vault.

Плюсы данного подхода:

  • Используется единая точка входа и управления доступом. Данный плюс позволяет с легкостью управлять всей системой взаимодействия с базой данных. Нет необходимости писать и проверять сервисы на ошибки, это все сделано за нас сотрудниками Microsoft и сообщества пользователей, пользующимися этими сервисами.
  • Простота расширения, так как мы можем переходить между БД легко, не меняя ничего. Мы можем поменять с БД развернутой на нашем хосте на БД в облаке.
  • Удобный интерфейс управления доступом. Нету необходимости тратить время и деньги на написание интерфейса управления доступом. Все сделано и вымерено временем.


Среди минусов можно выделить один — в данной реализации нам после удаления пользователя необходимо менять пароль к БД. А это не очень хорошо, так как системой уже пользуются.

Таков был опыт использования облака для решения конкретной задачи. Спасибо за внимание!

© Habrahabr.ru