Опыт использования облака в управлении контроля доступа к базам данных в программном проекте
Выражаем большое спасибо за подготовку статьи Синицину Николаю, старшему инженеру-программисту компании Аплана, за помощь в написании данной статьи. Остальные наши статьи по теме Azure можно найти по тегу azureweek
Привет!
Как-то в одном из проектов поставили задачу, условиями которой являлось обеспечение необходимости ПО обращения к различным базам данных с регламентацией доступа – буквально, у кого есть лицензия, тем давать доступ, иначе блокировать доступ. Дополнительно нужно было иметь возможность менять соединение на другую базу данных, и чтобы ПО узнало, что сменился адрес. Было найдено несколько способов это сделать, но в конце концов пришли к варианту использования облачных сервисов Azure – о том, как принималось решение и зачем и как мы использовали облако – читайте под катом.
Сначала думали пойти по пути достаточно очевидному — есть базы данных, на каждой базе данных заведены пользователи, у которых есть «лицензии». Проблему доступа решили, но, как вы наверняка понимаете, очень неудобно управлять подобной системой – добавлять, удалять пользователей. Дабы решить проблему смены серверов, необходимо было бы писать некий условный сервис, который бы также хранил в себе пользователей, у которых есть доступ. И все бы знали адрес, где располагается сервер базы данных.
У данного метода есть несколько минусов:
- Нужно писать сервис;
- Нет единого хранилища пользователей с доступом к системе;
- Тяжело поддерживать актуальность данных по пользователям на различных БД.
Пройдемся по минусам.
Минус: Нужно писать сервис.
«Какой сервис нам необходим был», спросите Вы. Сервис по управлению контроля доступа к базам данных для программных продуктов развернутых на различных машинах. Написание сервисов – это неплохо. Но, когда необходимо писать сервис с нуля, есть возможность поймать различные ошибки, в т.ч. самые сложные – человеческие. Особенно это актуально, когда пишешь сервис контроля доступа и распределения ролей. Одна ошибка – и вместо того, чтобы дать одному пользователю права на ресурс, можно столкнуться с тем, что права даны бОльшему количеству. Цена ошибки очень велика.
Минус: Нет единого хранилища пользователей с доступом к системе.
Помимо того, что должен быть сервис, который позволит предоставлять различный доступ, необходим единая база данных пользователей и менеджер управления, который легко позволит управлять данной базой данных. Писать самому с самого начала = потратить много времени.
Минус: Тяжело поддерживать актуальность данных по пользователям на различных БД.
Если использовать вариант, в котором на каждой базе данных заведены пользователи, мы имеем проблему синхронизации нескольких баз данных между собой.
В связи с тем, что есть описанные проблемы, было принято решение посмотреть на облачные сервисы, которые позволят решить поставленные задачи и минимизировать или полностью избавиться от вышеперечисленных минусов + была возможность возникновение перехода на облачную базу данных и развертывание сайта в облаке.
Рассмотрим кратко облачные сервисы, которые были проанализированы и использованы в решении поставленной задачи:
Azure Active Directory (AAD или Azure AD) — многопользовательский облачный каталог и служба управления удостоверениями. Она схожа по работе с Active directory, которая поставляется совместно с Windows Server. Однако, AAD предназначена для работы пользователей не в локальной инфраструктуре компании, а при работе с облачными приложениями (Например Azure Key Vault) С помощью данного сервиса мы решаем проблемы «нет единого хранилища пользователей с доступом к системе» и «тяжело поддерживать актуальность данных по пользователям на различных БД». Недавно было анонсировано, что AAD будет поддерживать возможность развертывания доменов.
Azure Key Vault — HMS as a Service (Hardware security module). HMS — это выделенное hardware, которое позволяет хранить, управлять ключами/секретами и шифровать/расшифровывать, ставить/проверять подписи максимально безопасным образом и достаточно быстро (специфичное железо, заточенное под шифрование, по заявлениям работает быстро, но на сколько или какие делались замеры- информации нет). Ранее KV был известен как BYOK (bring-your-own-key). (Ссылка на статью). С помощью данного сервиса можно хранить секреты связанные с доступом к той или иной БД (логин, пароль, адрес, тип БД и т.д.) Тем самым пользователей авторизованный с помощью AAD получает Token с помощью, которого получает доступ к секрету. И программа, исходя из этих данных, соединяется с нужной БД.
Использование Azure Active Directory и Azure Key Vault
На схеме выше видно, что управление доступом, единое хранилище пользователей и менеджер управления передано на сторону облачных сервисов, таких как AAD и Azure Key Vault. Схема взаимодействия очень проста. Каждый пользователь ПО знает логин и пароль, который ему выдал администратор сервиса. С помощью него программа авторизуется в AAD и получает авторизационный токен, с помощью которого программный продукт получает доступ к сервису Azure Key Vault в котором хранятся секреты. Дальше используя секреты, ПО устанавливает соединение с базой данных.
В случае, если необходимо удалить доступ к БД, можно удалить пользователя из AAD и сгенерировать новый пароль к БД. Остальные системы, потеряв соединение запросят заново секрет и установят соединение.
Если мы меняем адрес или расположение БД, нам необходимо только поменять информацию в секрете и система автоматически соединится с другой БД, которая придет в информации от Key Vault.
Плюсы данного подхода:
- Используется единая точка входа и управления доступом. Данный плюс позволяет с легкостью управлять всей системой взаимодействия с базой данных. Нет необходимости писать и проверять сервисы на ошибки, это все сделано за нас сотрудниками Microsoft и сообщества пользователей, пользующимися этими сервисами.
- Простота расширения, так как мы можем переходить между БД легко, не меняя ничего. Мы можем поменять с БД развернутой на нашем хосте на БД в облаке.
- Удобный интерфейс управления доступом. Нету необходимости тратить время и деньги на написание интерфейса управления доступом. Все сделано и вымерено временем.
Среди минусов можно выделить один — в данной реализации нам после удаления пользователя необходимо менять пароль к БД. А это не очень хорошо, так как системой уже пользуются.
Таков был опыт использования облака для решения конкретной задачи. Спасибо за внимание!
