Как выбрать метод аутентификации пользователей в СУБД

Как грамотно выбрать надёжный метод аутентификации для пользователей в системе управления базами данных (СУБД), опираясь на такие критерии, как сложность и цена реализации, а также уровень безопасности? Как расширение и графический веб-интерфейс могут упростить работу? Рассмотрим на примере отечественной СУБД Jatoba.

1. Введение
2. Все ли методы аутентификации одинаково безопасны?
   
   1. 2.1. Аутентифицируйся и властвуй
3. Доменная аутентификация
4. Как расширение и веб-интерфейс могут упростить работу
5. Выводы

Введение

Безопасность системы управления базами данных начинается с надёжного механизма аутентификации её пользователей. Аутентификация — установление подлинности получающего доступ к автоматизированной системе лица путём сопоставления сообщённого им идентификатора и предъявленного подтверждающего фактора. Современные СУБД поддерживают множество механизмов аутентификации пользователей, различающихся сложностью, ценой реализации и, как следствие, уровнем безопасности. Что выбрать, если СУБД обслуживает задачи крупного и среднего бизнеса? Рассмотрим этот вопрос в статье на примере отечественной СУБД Jatoba.

Все ли методы аутентификации одинаково безопасны?

Методов аутентификации существует множество, СУБД Jatoba поддерживает следующие:

• Доверительный (trust authentication). Самый простой метод аутентификации. Вход разрешается любому пользователю с любого настроенного узла сети. Малоприменим из-за низкой степени защиты.
• Парольный (password authentication). Позволяет выполнять проверку пароля пользователя (хранится в системных таблицах СУБД в хешированном виде). Наиболее распространённый механизм аутентификации со сбалансированным уровнем защиты и удобством использования.
• С применением GSSAPI (Generic Security Services Application Programming Interface). Основывается на совместимой с GSSAPI библиотеке безопасности. Чаще всего этот метод используется для доступа к выделенному серверу аутентификации, например к серверу Kerberos или Microsoft Active Directory. Этот механизм очень удобен, когда управление учётными записями централизовано в домене, а решения класса IDM не используются.
• С применением SSPI (Security Support Provider Interface). Этот программный интерфейс в Microsoft Windows позволяет приложениям использовать различные провайдеры безопасности для аутентификации и является реализацией GSSAPI в Windows. Со стороны СУБД поддерживается Negotiate SSP (Security Service Provider), использующий протоколы аутентификации Kerberos или NTLM.
• Идентификационный (ident authentication). Аутентификация с использованием службы «Протокол идентификации» (RFC 1413) на клиентском компьютере. Может использоваться только для TCP/IP-соединений. Для локальных соединений через Unix-сокеты заменяется на метод «хостовой» (peer) аутентификации.
• Хостовый (peer authentication). Механизм использующий средства операционной системы (хоста) для идентификации пользователя при локальном подключении. СУБД в состоянии идентифицировать пользователя по его учётным данным в ОС. Этот механизм не используется для удалённых подключений.
• С использованием LDAP (Lightweight Directory Access Protocol).
• С использованием RADIUS (Remote Authentication in Dial-In User Service). 
• С использованием сертификатов (certificate authentication). Механизм аутентификации в защищённых SSL-соединениях, основанный на проверке сертификатов клиента и сервера.
• С использованием PAM (Pluggable Authentication Modules). Применяется собственная настроенная цепочка PAM-совместимых модулей, установленных в системе.
• С использованием BSD (Berkeley Software Distribution). Метод, который схож с аутентификацией по паролю, но использует фреймворк аутентификации BSD (в настоящее время доступен только в OpenBSD).

Выбор механизма аутентификации часто обусловлен внешними требованиями или желанием упростить и облегчить эксплуатацию базы данных (БД) в сложной ИТ-инфраструктуре. Это особенно актуально, когда серверов баз данных много.

Аутентифицируйся и властвуй

Сегодня мы остановимся на варианте аутентификации через GSSAPI с использованием сервера Active Directory (AD), так как этот механизм удобен для применения в инфраструктуре продуктов компании Microsoft, когда управление учётными записями централизовано в домене, а решения класса IDM не используются.

Важно понимать, что это — весьма надёжный способ аутентификации, однако при его выборе некоторым пользователям приходится испытывать ряд неудобств, связанных со сложностью синхронизации учётных записей. Расскажем, как эти проблемы решены в СУБД Jatoba. Общая схема аутентификации представлена на рисунке 1.

Рисунок 1. Общая схема аутентификации

Клиент БД, запрашивая через драйвер аутентификацию, предоставляет на сервер БД параметры учётной записи. Если в СУБД будет указана настройка «Password authentication», то сервер будет сравнивать хеш пароля с тем, что лежит в системных таблицах БД. При аутентификации с использованием внешних средств, в том числе LDAP, сервер БД будет перенаправлять запрос на аутентификацию на указанный внешний сервер.

Доменная аутентификация

Клиент аутентифицируется на сервере Active Directory и получает мандат безопасности. В терминах Kerberos-протокола это — «ticket granting ticket» (TGT). Далее этот мандат используется и передаётся для аутентификации на сервер СУБД, выступающий в роли сервиса и обладающий своим мандатом для аутентификации клиентов. После успешной проверки сервер БД в соответствии с настройками в конфигурационных файлах «pg_ident.conf» и «pg_hba.conf» соотносит пользователя домена с пользователем БД. Для этого запись пользователя БД со всеми привилегиями должна быть создана до начала аутентификации, но во многих популярных СУБД, например Jatoba / PostgreSQL, не предполагается штатное создание учётных записей в БД средствами самой базы данных, так как это не является задачей СУБД и относится к инфраструктурным решениям. Часто для этого используют отдельные средства-утилиты.

Как расширение и веб-интерфейс могут упростить работу

В СУБД Jatoba для синхронизации учётных записей с Active Directory созданы специальное расширение (extension) под названием «pg_ldaprolesync» и графический веб-интерфейс для удобства использования этого расширения. «pg_ldaprolesync» поставляется в комплекте с СУБД Jatoba и обеспечивает её взаимодействие с Active Directory во время синхронизации. При использовании механизма «LDAP authentication» наличие пользователя в БД на момент начала аутентификации обеспечивается синхронизацией учётных данных при помощи «pg_ldaprolesync». Такой подход позволяет штатными средствами безопасно и контролируемо производить манипуляции с учётными записями внутри СУБД, так как «pg_ldaprolesynс» является проверенным внутренним компонентом самой системы и выпускается её производителем.

Расширение предоставляет определённый набор функций, позволяющих настраивать подключения ко внешним LDAP-серверам (включая Active Directory) и правила синхронизации пользователей в определённых группах каталога и СУБД, а также выполнять саму синхронизацию. В рамках расширения ведётся собственный журнал сообщений, который доступен администратору для анализа результатов операций, выполняемых в ходе синхронизации.

Собственно синхронизацию учётных записей администратор может выполнять тремя способами:

• Использовать API расширения и самостоятельно писать соответствующие SQL-запросы для вызова функций по настройке и синхронизации.
• Использовать дополнительное расширение запуска запросов по расписанию (входит в состав СУБД Jatoba). Фактически этот способ автоматизирует предыдущий: администратор разово вносит все необходимые настройки синхронизации, а потом настраивает вызов функции по расписанию. Этот же способ работы возможен и с использованием инструментария операционных систем; тогда за расписание синхронизации отвечает некоторая системная служба управления фоновыми заданиями, а запуск задачи состоит в выполнении соответствующего SQL-запроса (классический пример — cron).
• Использовать веб-портал управления СУБД Jatoba Data Safe и в интерактивном режиме выполнять настройку и синхронизацию учётных записей. Фактически этот способ тоже повторяет первый, но уже с использованием наглядного пользовательского интерфейса, что позволяет исключать ошибки при написании соответствующих SQL-запросов по настройке и синхронизации и значительно экономить время администратора.

Более подробно опишем третий способ (с использованием портала управления СУБД Jatoba Data Safe): эти действия максимально наглядно покажут удобство инструмента. Для осуществления настройки и проведения синхронизации используется вкладка «LDAP Sync» в веб-портале управления СУБД Jatoba Data Safe.

В соответствующем разделе присутствуют основные информационные блоки, изображённые на рисунке 2:

1. раздел «Список профилей»;
2. раздел «Маппинг»;
3. раздел «Журнал».

Рисунок 2. Общий вид интерфейса LDAP Sync на портале Jatoba Data Safe

Для синхронизации требуется задать параметры подключения к Active Directory по протоколу LDAP. Обязательными параметрами должны быть: название профиля, имя пользователя и пароль для подключения, IP-адрес сервера домена. Совокупность этих параметров и правил соотнесения учётных записей пользователей AD и БД называется «Профиль».

Задать название «Профиля» и указать нужные параметры подключения к Active Directory можно в разделе «Список профилей», используя кнопку добавления / редактирования.

Рисунок 3. Добавление «Профиля»

Важной функцией, позволяющей реализовывать гибкие правила соотнесения пользователей из групп домена и пользователей с ролью в БД, является «Маппинг». На портале Jatoba Data Safe в разделе «LDAP Sync» под этим понимают набор правил соотнесения ролей в БД и правил поиска учётных записей в AD.

Рисунок 4. Создание правил маппинга

Ошибки и результаты выполнения синхронизации можно увидеть в информационном блоке «Журнал».

Рисунок 5. «Журнал» синхронизации

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

Выводы

Вы можете выбирать любой из способов аутентификации для вашей базы данных, однако специалисты «Газинформсервиса» рекомендуют учитывать, что надёжный способ аутентификации уменьшает вероятность ошибок интеграции и снижает риск несанкционированного доступа к данным, а следовательно, повышает уровень вашей информационной безопасности.