Перейти к основному содержимому

Авторизация и аутентификация. Защита аутентификационной информации

Идентификация и аутентификация​

Идентификация — действия по присвоению субъектам и объектам доступа идентификаторов и (или) действия по сравнению предъявляемого идентификатора (определение имени пользователя базы данных) с перечнем присвоенных идентификаторов. При работе в среде SQL по имени пользователя определяются права доступа к объектам базы данных для конкретного пользователя.

примечание

Запуск клиентских утилит (к которым относится psql) доступен под любым пользователем ОС.

Аутентификация — это действия по проверке подлинности субъекта доступа в информационной системе. Определение того, может ли клиентское приложение (или пользователь запустивший приложение) подключиться под указанным именем пользователя.

При аутентификации пользователя определяется логин пользователя, который далее идентифицирует его. Межсервисная идентификация осуществляется с помощью свойств сессии application_name (может быть задано аутентифицирующимся приложением для того, чтобы в логе СУБД отображалась данная информация), а также IP-адрес и клиентский порт.

При использовании сертификатов, сертификат безопасности клиента должен содержать поле CN, содержащее логин клиента и, опционально, поле SubjectAltName, содержащее один или несколько IP-адресов (возможен вариант указания подсети) и (или) DNS-имен клиента.

Примечание

Критерии параметраapplication_name: любая строка, не превышающая 64 печатных ASCII символов (остальные символы будут заменены знаками вопроса).

СУБД Pangolin поддерживает несколько методов аутентификации пользователей и сервисов:

  • trust — любой пользователь, подключающийся к серверу, авторизован для доступа;
  • password — авторизация с помощью пароля, передаваемого в виде хеша MD5 или открытым текстом;
  • GSSAPI — протокол авторизации по стандарту RFC 2743;
  • SSPI — технология защищенной аутентификации Windows;
  • ident — аутентификация с использованием сервера ident по стандарту RFC 1413;
  • peer — получение имени пользователя клиента из ядра и использование его в качестве авторизованного имени пользователя БД;
  • LDAP — аналогично password, но для подтверждения пары «имя пользователя/пароль» используется метод LDAP;
  • RADIUS — аналогично password, но для подтверждения пары «имя пользователя/пароль» используется метод RADIUS;
  • cert — аутентификация с использованием клиентского сертификата TLS. Применимо только для TLS-подключений;
  • PAM — аналогично password, но для подтверждения пары «имя пользователя/пароль» используется метод PAM. Также поддерживается проверка имени и IP удаленного компьютера;
  • BSD — аналогично password, но для подтверждения пары «имя пользователя/пароль» используется метод BSD;
  • 2f-scram-sha-256, 2f-md5, 2f-password или 2f-ldap — методы двухфакторной аутентификации (подробнее смотрите раздел «Двухфакторная аутентификация»).

Метод аутентификации конкретного клиентского соединения может основываться на адресе компьютера клиента, имени базы данных, имени пользователя. Более детально описано в разделе документации PostgreSQL «Аутентификация клиента».

Файл pg_hba.conf​

Аутентификация клиентов управляется конфигурационным файлом pg_hba.conf, расположенным в каталоге с данными кластера базы данных, либо секцией pg_hba конфигурационного файла postgres.yml кластерной конфигурации. Файл pg_hba.conf со стандартным содержимым создается командой initdb при инициализации каталога с данными. Располагается в каталоге PGDATA.

Общий формат файла pg_hba.conf — набор записей, по одной на строку. Пустые строки игнорируются, как и любой текст комментария после знака #. Запись состоит из нескольких полей, разделенных пробелами и/или табуляциями. Запись может быть продолжена на следующей строке, для этого нужно завершить строку обратной косой чертой (обратная косая черта является спецсимволом только в конце строки). Обратная косая черта обозначает перенос строки даже в тексте в кавычках или комментариях.

Каждая запись обозначает тип соединения, диапазон IP-адресов клиента (если он соотносится с типом соединения), имя базы данных, имя пользователя, и способ аутентификации, который будет использован для соединения в соответствии с этими параметрами.

Описание возможных полей и примеры заполнения представлены в разделе «Файл pg_hba.conf» документации PostgreSQL.

Сквозная аутентификация между Pangolin Pooler и Pangolin DBMS​

В Pangolin Pooler и Pangolin DBMS реализован механизм сквозной аутентификации. Программа Pangolin Pooler выступает в режиме проксирования данных аутентификации от клиента к Pangolin и обратно, аутентификация пользователя выполняется только на Pangolin.

Данная функциональность позволяет избежать:

  • порождения процессов на СУБД для целей аутентификации в избыточном количестве - в случае неуспешной аутентификации процесс, порожденный клиентским подключением, терминируется;
  • избыточных пользовательских аутентификаций;
  • хранения паролей в открытом виде с использованием параметра auth_file файла userlist.txt;
  • использования слабых типов аутентификации: trust, plain, password и peer;
  • рассинхронизации информации об имени и пароле пользователя;
  • ограничений ядра Pangolin Pooler в части аудирования действий пользователя.

Дополнительно она позволяет:

  • выполнять аутентификацию пользователей в Pangolin Pooler всеми поддерживаемыми способами СУБД Pangolin, включая LDAP;
  • повышает безопасность;
  • упрощает конфигурирование кластера СУБД.

Подробнее в разделе «Сквозная аутентификация».

Двухфакторная аутентификация​

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

Подключение пользователя к СУБД с помощью двухфакторной аутентификации может осуществляться:

Для реализации механизма двухфакторной аутентификации требуется:

  1. Настроить режим взаимодействия с клиентами по TLS.

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

    Сертификат безопасности клиента должен содержать поле CN, содержащее логин клиента и, опционально, поле SubjectAltName, содержащее один или несколько IP-адресов (возможен вариант указания подсети) и (или) DNS-имен клиента.

  2. Указать в конфигурации один из специальных методов аутентификации: 2f-scram-sha-256, 2f-ldap, 2f-md5 и 2f-password.

    Внимание!

    Необходимо учитывать, что разрешенными по умолчанию механизмами двухфакторной аутентификации являются 2f-scram-sha-256 и 2f-ldap.

    При необходимости использования методов аутентификации 2f-md5 и 2f-password нужно добавить эти методы в параметр enabled_extra_auth_methods в конфигурационном файле:

    • postgresql.conf для конфигурации сервера standalone;
    • postgres.yml для конфигурации cluster.

    Например:

    enabled_extra_auth_methods = '2f-md5, 2f-password'

Подробнее в разделе «Двухфакторная аутентификация».

Авторизация​

Авторизация – предоставление субъекту прав на доступ, а также предоставление доступа в соответствии с установленными правами на доступ.

Предоставление прав пользователям в СУБД Pangolin осуществляется в соответствии с ролевой моделью и механизмом защиты данных от привилегированных пользователей.

Системный каталог pg_authid содержит информацию об идентификаторах авторизации базы данных (роли). Роли включают понятия «пользователи» и «группы».

Примечание

Механизм реализации авторизации (присвоения ролей, выдачи прав пользователям, занесение DN/CN сертификата в списки доступа, настройки списков доступа) реализуется на стороне администратора системы.

Ролевая модель и права доступа​

Для обеспечения контроля доступа к защищаемым объектам базы данных применяется система разграничения доступа, основанная на ролях.

Права доступа пользователей устанавливаются политиками защиты (безопасности) в соответствии с ролевой моделью. Управление политиками описано в подразделе «Управление» раздела «Защита данных от привилегированных пользователей», а также в разделе «Разграничение доступа к данным» о ролевой модели и ее конфигурировании.

Автоматическое завершение неактивных соединений​

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

Процесс регулируется двумя параметрами:

  • check_idle_time_delay — интервал мониторинга в миллисекундах;
  • backend_idle_alive_time — допустимое время бездействия в секундах.

Если хотя бы один из этих параметров равен нулю, неактивные соединения завершаться не будут.

Более подробно в одноименном разделе данного документа.

Внешняя авторизация через LDAP​

Сведения

Функциональность доступна только для редакций Enterprise и Enterprise для ERP-систем.

Функциональность позволяет настраивать в централизованном LDAP-хранилище атрибуты прав пользователей (SUPERUSER, LOGIN, REPLICATION и другие) и вложенность ролей. После чего атрибуты и зависимость ролей можно получать из централизованного хранилища для всех экземпляров СУБД.

В LDAP-хранилище для каждой роли так же хранится список родительских ролей, в которые она входит (по аналогии с pg_auth_members), но конкретные полномочия всех этих ролей хранятся в СУБД. При этом из хранилища можно получать роли, которые не заведены в самой СУБД, и выполнять операции от их имени.

примечание

Функциональность не позволяет управлять через LDAP полномочиями отдельных ролей — только их вложенностью.

примечание

Любая нетривиальная команда UPDATE также требует привилегии SELECT, поскольку она должна ссылаться на столбцы таблицы, чтобы определить, какие строки обновить, и/или вычислить новые значения для столбцов.

В Pangolin реализована возможность настроить засекречивание запросов от сервера СУБД к AD (Active Directory). Для этого нужно настроить протокол LDAPS, использующий LDAP поверх SSL с протоколом шифрования TLS.

Более подробно в разделе «Внешняя авторизация через LDAP. Управление протоколом LDAPS».

Защита аутентификационной информации​

В утилите psql имелся механизм запоминания ранее выполненных запросов. Этот механизм позволял просмотреть историю ранее выполненных команд и повторно вызвать ранее выполненные запросы.

История запросов хранилась в открытом виде в файле ~/.psql_history. При выполнении запросов, содержащих пароли, это могло представлять угрозу безопасности, так как пароли хранились так же в незасекреченном виде.

В Pangolin реализована защита аутентификационной информации в процессе ее ввода. При аутентификации через утилиту psql вводимые пользователем символы пароля не отображаются.

Внимание!

Не рекомендуется передавать или хранить пароль в открытом виде в:

  • файле pgpass;
  • строке параметров подключения (Connection string);
  • переменной окружения PGPASSWORD.

В связи с новой функциональностью изменяется поведение утилиты psql по сравнению с имеющимся:

  • создание и чтение файла ~/.psql_history не производится;
  • влияние переменной окружения PSQL_HISTORY на работу утилиты psql отсутствует;
  • установка переменной HISTFILE в утилите psql не дает эффекта.

В файле конфигурации postgresql.conf вводится новый параметр psql.save_history, регулирующий сохранение истории. Если установить этот параметр в значение off, то создание, обновление и чтение файла ~/.psql_history производиться не будет.

Реализованная функциональность не приводит к удалению или очищению ранее созданных файлов истории запросов. После обновления продукта рекомендуется (если необходимо) удалить ранее созданные файлы истории, выполнив команду:

rm -f ~/.psql_history
Внимание!

При использовании оригинального libpq история запросов сохраняется, что создает угрозу безопасности. Обратите внимание, не гарантируется работоспособность сторонних решений.

Рекомендации​

Сведения

При реализации TLS/SSL-соединений в СУБД доступно использование каксгенерированных сертификатов, так и сертификатов PKCS#12.

Pangolin Pooler​

При большом количестве клиентских подключений, рекомендуется использование компонента Pangolin Pooler.

Текущая версия компонента Pangolin Pooler 3.2.0, основан на PgBouncer версии 1.24.0.

Компонент Pangolin Pooler – это менеджер пулов соединений Pangolin DBMS.

Предназначение компонента — минимизировать издержки, связанные с установлением новых подключений к Pangolin DBMS. Pangolin Pooler позволяет уменьшить накладные расходы на базу данных в случае, когда огромное количество физических соединений ведет к падению производительности СУБД Pangolin.

Любое клиентское приложение может подключиться к Pangolin Pooler, как если бы это был непосредственно сервер DBMS, и пулер создаст подключение к реальному серверу, либо задействует одно из ранее установленных подключений.

Информация по установке, настройке и управлению данного компонента представлена в разделе «Администрирование Pangolin Pooler» документа «Руководство администратора».

Правила задания и смены паролей​

Пароль считается стойким, если он удовлетворяет следующим условиям:

  • должен изменяться не менее 1 раза в 80 дней с момента последнего изменения;
  • должен быть сложен (обязательно использование строчных и прописных букв и цифр);
  • длина пароля — минимум 12 символов;
  • должен быть уникален, недопустимо использование одного и того же пароля для нескольких УЗ одного пользователя;
  • не должен содержать имя УЗ пользователя или какую-либо его часть;
  • в случае компрометации пароля необходимо незамедлительно его сменить;
  • должен храниться в засекреченном виде.

Парольные политики для Pangolin по умолчанию настроены следующим образом:

  • выключены для пользователей, проходящих внешнюю аутентификацию LDAP;

  • для локальных УЗ включено использование библиотеки zxcvb;

  • для специальных УЗ выключены проверки времени жизни пароля:

    SELECT * FROM set_role_policies('masteromni', max_age('0 sec'), min_age('0 sec'), check_syntax('1'), policy_enable('1'), lockout('0'), illegal_values('1'), use_password_strength_estimator('1'), password_strength_estimator_score('3'));
    SELECT * FROM set_role_policies('zabbix_oasubd', max_age('0 sec'), min_age('0 sec'), check_syntax('1'), policy_enable('1'), lockout('0'), illegal_values('1'), use_password_strength_estimator('1'), password_strength_estimator_score('3'));
    SELECT * FROM set_role_policies('monitoring_php', max_age('0'), min_age('0'), check_syntax('1'), policy_enable('1'), lockout('0'), illegal_values('1'), use_password_strength_estimator('1'), password_strength_estimator_score('3'));
    SELECT * FROM set_role_policies('auditor', max_age('0'), min_age('0'), check_syntax('1'), policy_enable('1'), lockout('0'), illegal_values('1'), use_password_strength_estimator('1'), password_strength_estimator_score('3'));
    SELECT * FROM set_role_policies('pstgcmdb', max_age('0'), min_age('0'), check_syntax('1'), policy_enable('1'), lockout('0'), illegal_values('1'), use_password_strength_estimator('1'), password_strength_estimator_score('3'));
    SELECT * FROM set_role_policies('as_TUZ', max_age('0'), min_age('0'), check_syntax('1'), policy_enable('1'), lockout('0'), illegal_values('1'), use_password_strength_estimator('1'), password_strength_estimator_score('3'));
    SELECT * FROM set_role_policies('as_admin', max_age('0'), min_age('0'), check_syntax('1'), policy_enable('1'), lockout('0'), illegal_values('1'), use_password_strength_estimator('1'), password_strength_estimator_score('3'));
    SELECT * FROM set_role_policies('db_admin', max_age('0'), min_age('0'), check_syntax('1'), policy_enable('1'), lockout('0'), illegal_values('1'), use_password_strength_estimator('1'), password_strength_estimator_score('3'));
    SELECT * FROM set_role_policies('postgres', max_age('0'), min_age('0'), check_syntax('1'), policy_enable('1'), lockout('0'), illegal_values('1'), use_password_strength_estimator('1'), password_strength_estimator_score('3'));

Утилиты засекречивания и хранения паролей​

В СУБД Pangolin реализован механизм защищенного хранения параметров подключения к базе данных (логинов, паролей и сопутствующих параметров). Механизм предназначен для исключения хранения паролей в открытом виде в конфигурационных файлах и для снижения риска их компрометации.

Защищенное хранилище представляет собой файл с параметрами подключения, сохраненными в засекреченном виде.

Особенности механизма:

  • параметры подключения не хранятся в открытом виде;
  • ключи кодирования уникальны в рамках узла;
  • ключи не сохраняются в явном виде, а вычисляются в процессе работы;
  • доступ к хранилищу ограничен системным пользователем postgres.

Утилиты, выполняющие автоматизированное подключение к БД, получают параметры подключения из защищенного хранилища и используют их для установления соединения.

Для управления хранилищем и засекречивания параметров подключения используется набор специализированных утилит:

  • pg_auth_config — утилита засекречивания/хранения параметров подключения к БД;
  • pg_auth_password — утилита засекречивания паролей. Позволяет получить пароль в засекреченном виде после ввода исходного пароля;
  • pangolin_password_hash - утилита для получения хеш-сумм паролей для заполнения пользовательского конфигурационного файла;
  • pangolin-auth-reencrypt – утилита перекодирования паролей, которая используется для восстановления работоспособности узла кластера при смене параметров сервера.

Более подробно о работе и установке данных утилит в разделе «Утилиты засекречивания и хранения параметров подключения».