company_banner

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

    Выражаем большое спасибо за подготовку статьи Синицину Николаю, старшему инженеру-программисту компании Аплана, за помощь в написании данной статьи. Остальные наши статьи по теме 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 и сообщества пользователей, пользующимися этими сервисами.
    • Простота расширения, так как мы можем переходить между БД легко, не меняя ничего. Мы можем поменять с БД развернутой на нашем хосте на БД в облаке.
    • Удобный интерфейс управления доступом. Нету необходимости тратить время и деньги на написание интерфейса управления доступом. Все сделано и вымерено временем.

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

    Таков был опыт использования облака для решения конкретной задачи. Спасибо за внимание!
    Microsoft
    Microsoft — мировой лидер в области ПО и ИТ-услуг

    Комментарии 4

      0
      А как по описанной схеме происходит актуализация данных пользователей во всех связанных базах (например, ФИО, день рождения и т.п.)?
        0
        Здравствуйте.

        Вы работаете одновременно с несколькими базами? И встает вопрос синхронизации данных?

        Наш продукт работал всегда с одной БД. Когда стала необходимость перехода на другую вычислительную мощность в другом месте, мы среплицировали данные на другой сервер и поменяли ConnectingString.В итоге система сама переподсоединилась к другой бд.
          0
          С переносом одной базы — это понятно. Мы же работаем с несколькими базами, совершая в них единый вход с сайта.
            0
            Я вижу здесь 2 решения:
            1) Если данные заполняются общие редко, то можно настроить синхронизацию средствами Azure, которая будет синхронизировать БД раз в 5 минут вроде (минимум)
            2) Если в обоих БД находится разные данные, кроме авторизационных, то эти данные вынести в отдельную БД, и предоставлять доступ после проверки авторизации к 2м БД, в зависимости от настроек.
            Чтобы помочь необходимо четкое понимание, структуры взаимодействия.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое