Методы аутентификации
Внешняя аутентификация
16
Авторские права
© Postgres Professional, 2017–2026
Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов, Алексей Береснев
Фото: Олег Бартунов (монастырь Пху и пик Бхрикути, Непал)
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
edu@postgrespro.ru
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Внешняя аутентификация
Аутентификация LDAP
Аутентификация GSSAPI
Аутентификация PAM
3
Внешняя аутентификация
peer [параметры]
проверка в операционной системе
ldap [параметры]
проверка в службе каталогов LDAP
gssapi [параметры]
использование GSSAPI, обычно Kerberos
sspi [параметры]
проверка средствами аутентификации Windows
pam [параметры]
проверка посредством подключаемых модулей PAM
Вместо того чтобы хранить пароль в системном каталоге и сверять его
с паролем, который передал пользователь, PostgreSQL может поручить
проверку подлинности пользователя внешней системе.
Метод аутентификации peer, рассмотренный в теме «Подключение и
аутентификация», относится к внешним, так как запрашивает имя
текущего пользователя у ядра ОС.
При использовании метода ldap PostgreSQL обращается к службе
каталогов LDAP.
GSSAPI (Generic Security Service Application Program Interface) —
универсальный интерфейс для служб аутентификации,
соответствующий спецификации RFC 2743. На практике используется
для аутентификации в UNIX/Linux средах Kerberos, где в PostgreSQL
используется метод аутентификации gssapi.
В аналогичных средах Windows, реализующих подход одноразовой
аутентификации (single sign-on), используется метод sspi.
Метод pam использует подключаемые модули аутентификации
(Pluggable Authentication Modules) — стандартный механизм Linux,
предоставляющий приложениям высокоуровневый API для
аутентификации с помощью внешних модулей.
4
Аутентификация LDAP
Служба каталогов
Простое связывание
Поиск + связывание
5
Служба каталогов
uid=alice uid=bob
dc=local
dc=course
ou=BioLab
DN: dc=local
DN: ou=BioLab, dc=course, dc=local
DN: dc=course, dc=local
DN: uid=alice, ou=BioLab, dc=course, dc=local
cn=admin
DN: cn=admin, dc=course, dc=local
DN: uid=bob, ou=BioLab, dc=course, dc=local
LDAP (Lightweight Directory Access Protocol) — протокол для доступа
к службе каталогов. Каталог представляет собой иерархию записей,
которые состоят из различных атрибутов и описывают какой-либо
объект: учетную запись пользователя, группу пользователей,
организацию, доменное имя, сетевую службу и т. п. В учетной записи
может храниться пароль, обычно в виде хеш-кода в атрибуте
userPassword.
Запись идентифицируется уникальным именем (DN, distinguished
name), составленным из DN родительской записи и, как правило,
некоторого атрибута текущей. Например, DN учетной записи Алисы на
слайде — «uid=alice,ou=BioLab,dc=course,dc=local»:
●
uid — идентификатор пользователя (user ID);
●
ou — подразделение (organization unit);
●
dc — домен (domain component).
6
LDAP
Простое связывание
ou=BioLab
uid=alice uid=bob
dc=local
dc=course
клиент
PostgreSQL
alice
ldapserver
ldapport
*****
ldapprefix
ldapsuffix
DN: uid= alice , ou=BioLab, dc=course, dc=local
*
*
*
*
*
В простом варианте СУБД связывается с сервером LDAP по
уникальному имени, составленному из префикса, имени
подключающейся роли и суффикса. Например, при подключении
клиента под ролью alice с параметрами метода ldap
●
префикс ldapprefix = «uid=»,
●
суффикс ldapsuffix = «,ou=BioLab,dc=course,dc=local»
PostgreSQL пошлет запрос аутентификации (bind) к серверу LDAP,
используя DN «uid=alice,ou=BioLab,dc=course,dc=local» и переданный
клиентом пароль. Адрес и порт сервера LDAP задаются параметрами
ldapserver и ldapport.
Если запрос выполняется успешно, аутентификация считается
пройденной.
8
LDAP
Поиск + связывание
ou=BioLab
uid=alice uid=bob
dc=local
dc=course
cn=admin
ou=ChemLab
uid=charlie
клиент
PostgreSQL
charlie
ldapbinddn
ldapsearchattribute = 'uid'
ldapbasedn
ldapserver
ldapport
*****
x
x
x
x
x
ldapbindpasswd
Если пользователи хранятся в разных поддеревьях, суффиксы
уникальных имен записей будут разными и возможностей простого
связывания не хватит. Например, записи alice и charlie заведены
в разных лабораториях: суффикс Алисы будет 'ou=BioLab', а Чарли —
'ou=ChemLab'.
Для таких случаев есть возможность провести аутентификацию в два
этапа.
Сначала выполняется поиск нужной записи (search). Для этого
PostgreSQL подключается к серверу LDAP под фиксированным именем
и паролем (ldapbinddn, ldapbindpasswd) и ищет в поддереве ldapbasedn
запись, у которой атрибут ldapsearchattribute равен имени
подключающейся роли.
Например, для роли charlie с настройками
●
ldapbasedn = 'dc=course,dc=local',
●
ldapsearchattribute = 'uid'
PostgreSQL обнаружит запись
«uid=charlie,ou=ChemLab,dc=course,dc=local».
9
Поиск + связывание
клиент
PostgreSQL
charlie
ldapserver
ldapport
LDAP
ou=BioLab
uid=alice uid=bob
dc=local
dc=course
cn=admin
ou=ChemLab
uid=charlie
*
*
*
*
*
*****
Второй этап выполняется так же, как при обычном связывании.
PostgreSQL отправляет запрос на аутентификацию, используя
найденную запись и пароль, переданный клиентом. Если запрос
выполняется, аутентификация считается пройденной.
11
Аутентификация GSSAPI
Kerberos и GSSAPI
Настройка клиента
Настройка сервера
Аутентификация
Запрос сеансового ключа
Передача ключа сервису
Коммуникация с сервисом
12
Kerberos и GSSAPI
Kerberos — протокол аутентификации
надежный обмен ключами и взаимная аутентификация
между клиентом и сервисом
симметричные ключи, доверенная третья сторона
разграничение доступа по областям (realm)
GSSAPI — универсальный интерфейс безопасности
поддерживает разные протоколы, в том числе Kerberos
Kerberos — протокол аутентификации, позволяющий клиентам
и сервисам (в нашем случае PostgreSQL) выполнить взаимную
аутентификацию с помощью доверенной третьей стороны — службы
Kerberos. Kerberos позволяет клиенту и сервису надежно обменяться
ключами для передачи данных по незащищенному каналу связи,
используя криптографию симметричных ключей.
Клиент один раз аутентифицируется службой Kerberos, а затем
получает билеты-разрешения, с которыми обращается к сервисам.
Билет гарантирует клиенту, что он подключится именно к запрошенному
сервису, а сервису — что клиент имеет право на подключение.
Kerberos рассчитан на большое количество пользователей и сервисов,
и не каждому пользователю нужно разрешать подключаться к любому
сервису. Для разграничения доступа существуют области (realm):
пользователь может получать билет для сервиса, только если они
входят в одну область. В нашем примере это область COURSE.LOCAL.
PostgreSQL работает с протоколом Kerberos не напрямую, а через
универсальный прикладной интерфейс GSSAPI (Generic Security
Services API), который, помимо Kerberos, поддерживает NTLM и другие
протоколы.
13
Настройки клиента
Параметр gssencmode
disable не использовать шифрование GSSAPI
prefer попытка использовать шифрование GSSAPI,
при неудаче — попытка соединиться без него
(по умолчанию)
require потребовать шифрование GSSAPI
Параметр krbsrvname
имя службы Kerberos для аутентификации
Аналогично тому, как при подключении клиент может попросить или
потребовать SSL-соединение с помощью параметра sslmode
библиотеки libpq, пожелания по использованию шифрования GSSAPI
определяются значением параметра gssencmode.
Клиент может запретить (disable) или потребовать (require) соединение
с шифрованием GSSAPI. Если сервер не разрешает желаемое
соединение, оно не будет установлено.
Клиент также может попросить шифрованное соединение, но если
такой возможности нет, согласиться на обычное (prefer, по умолчанию).
Также клиент может указать имя службы Kerberos, которая должна
использоваться для аутентификации (по умолчанию — postgres).
14
Настройки сервера
Параметры
krb_server_keyfile имя keytab-файла с ключом PostgreSQL
Типы сетевых подключений в pg_hba.conf
host любое сетевое подключение
hostgssenc подключение с шифрованием GSSAPI
hostnogssenc подключение без шифрования GSSAPI
Метод аутентификации
gss аутентификация с помощью GSSAPI
sspi аутентификация SSPI для Windows
Для аутентификации с помощью Kerberos необходимо указать метод
аутентификации gss. (В ОС Windows для работы с Kerberos
используется собственный интерфейс SSPI и соответствующий ему
метод аутентификации sspi, которые мы здесь не рассматриваем.)
В параметре krb_server_keyfile указывается расположение файла
с ключом PostgreSQL. Такие файлы, содержащие ключ Kerberos
определенного сервиса или клиента, называются keytab-файлами.
В качестве типа подключения при этом можно указать как простой тип
host, так и явно разделить соединения на использующие шифрование
GSSAPI (hostgssenc) и не использующие (hostnogssenc).
15
Аутентификация
PostgreSQLКлиент
Kerberos
запрос
аутенти-
фикации
временный
ключ
TGT
пароль
ключ
Алисы
ключ
PostgreSQL
ключ
Kerberos
Служба Kerberos хранит ключи всех пользователей и сервисов, которые
заранее созданы администратором. На иллюстрации это ключ
пользователя Алисы и ключ сервиса PostgreSQL. У Kerberos есть также
свой ключ, не известный никому.
Алиса входит в корпоративную систему и проходит аутентификацию.
Она вводит свой пароль, из которого с помощью специального
алгоритма генерируется ее ключ (тот самый, что хранится в Kerberos).
Клиент Алисы обращается к службе аутентификации Kerberos AS
(Authentication Service). Если Алиса ввела правильный пароль, ключи
совпадут. Тогда Kerberos генерирует временный ключ,
предназначенный для сеанса общения клиента и самого Kerberos,
и отправляет клиенту два сообщения:
●
Временный ключ, зашифрованный ключом Алисы. Клиент сможет его
расшифровать.
●
Временный ключ (плюс дополнительная служебная информация),
зашифрованный ключом Kerberos. Это сообщение называется TGT,
Ticket Granting Ticket — билет на получение билетов. Клиент не
может его расшифровать, но будет предъявлять его Kerberos в
доказательство того, что пользователь уже прошел аутентификацию.
17
Запрос сеансового ключа
PostgreSQLКлиент
Kerberos
запрос
доступа
к PostgreSQL
сеансовый
ключ
TGT
TGT
ST
Теперь Алиса хочет подключиться к PostgreSQL. Для этого ее клиент
отправляет запрос на получение доступа к сервису, подтверждая
аутентификацию Алисы с помощью полученного ранее TGT. Это
позволяет Алисе не вводить пароль каждый раз при подключении
к другим сервисам — то, что называется single sign-on.
Служба Kerberos TGS (Ticket Granting Service) генерирует сеансовый
ключ, которым должны обладать как клиент, так и сервис. Клиенту
снова передаются два сообщения:
●
Сеансовый ключ, зашифрованный временным ключом (который уже
есть у клиента).
●
Сеансовый ключ, зашифрованный ключом сервиса (которого у
клиента, конечно, нет). Это сообщение называется ST, Service
Ticket — билет сервиса, и предназначено для сервиса.
18
Передача ключа сервису
PostgreSQLКлиент
Kerberos
TGT
запрос
подключения
ST
Клиент Алисы подключается к PostgreSQL (который использует метод
аутентификации gssapi) и предъявляет полученный от Kerberos билет.
PostgreSQL расшифровывает его своим ключом, который хранится
в keytab-файле. Факт того, что билет зашифрован ключом PostgreSQL,
говорит о том, что он получен от Kerberos (больше никто не знает этот
ключ), следовательно, пользователь прошел аутентификацию и ему
можно доверять.
Из расшифрованного билета PostgreSQL извлекает сеансовый ключ
для общения с клиентом.
19
Коммуникация с сервисом
PostgreSQLКлиент
Kerberos
TGT
Теперь сеансовый ключ имеется и у клиента, и у сервиса. Он
используется для шифрования данных, пересылаемых по клиент-
серверному протоколу.
Билет TGT остается у клиента и будет использован для запросов на
подключения к другим сервисам, если они понадобятся пользователю.
21
pam [параметры]
проверяет пары «имя пользователя — пароль»
Аутентификация PAM
PostgreSQL
клиент
PAM
Authentication
Service Modules
alice
**********
alice
*****
Система PAM (Pluggable Authentication Modules — подключаемые
модули аутентификации) является стандартной инфраструктурой
в Linux и многих UNIX системах. Модули этой системы представляют
собой разделяемые библиотеки, реализующие четыре сервиса PAM:
●
библиотеки аутентификации (Authentication Service Modules),
посредством которых выполняется проверка подлинности;
●
библиотеки учетных записей (Account Service Modules),
выполняющих такие задачи, как проверка устаревания учетных
записей;
●
библиотеки сеансов (Session Service Modules), отвечающие за
действия, выполняемые при входе в сеанс;
●
библиотеки управления паролями (Password Service Modules).
Серьезным преимуществом использования PAM является возможность
динамической настройки сервисов и формирования стека модулей,
которые выполняются последовательно для решения одной задачи,
обычно связанной с аутентификацией или аудитом.
В PostgreSQL аутентификация PAM работает подобно методу password,
используя пары «имя пользователя — пароль». Сам же механизм
аутентификации может быть реализован, например, с помощью LDAP,
к которому будет обращаться модуль PAM.
22
Итоги
При аутентификации PostgreSQL может полагаться на
сторонние средства
Метод ldap запрашивает у клиента пароль и проверяет его
с помощью службы каталогов
Методы gss и sspi аутентифицируют соединения через
протокол Kerberos
Метод pam позволяет использовать для аутентификации
внешнюю библиотеку
23
Практика
1. Настройте аутентификацию ldap по методу «поиск +
связывание», как в демонстрации. Поддеревом для поиска
укажите ou=BioLab.
Проверьте, что Алиса и Боб могут подключиться
к серверу, а Чарли — нет.
2. Измените настройку так, чтобы все сетевые соединения
использовали шифрование GSSAPI, но аутентификация
по-прежнему происходила с помощью LDAP.
2. Такая настройка не имеет большого практического смысла, поскольку
для шифрования GSSAPI клиент все равно должен пройти
аутентификацию сервисом Kerberos.
24
Практика+
Настройте аутентификацию PAM, чтобы пароль пользователя
проверялся на соответствие паролю в операционной системе.
1. Настройте журналирование подключений PostgreSQL.
2. Зарегистрируйте средствами операционной системы
пользователя pamuser и назначьте ему пароль.
Зарегистрируйте одноименную роль pamuser в СУБД.
3. В pg_hba.conf настройте для pamuser аутентификацию PAM
с помощью сервиса login.
4. Обеспечьте доступ на чтение файла /etc/shadow
пользователю postgres, добавив его в группу shadow.
5. Перезапустите СУБД и проверьте возможность подключения
пользователем pamuser.
2. Для регистрации пользователя в операционной системе используйте
команду:
sudo useradd pamuser
Назначить пароль можно следующей командой (предложит ввести
пароль и подтвердить его):
sudo passwd pamuser
Также пароль для пользователя можно установить так:
echo 'pamuser:пароль' | sudo chpasswd
3. Вариант настройки аутентификации PAM для сервиса login:
# TYPE DATABASE USER ADDRESS METHOD
local all pamuser pam pamservice=login
4. Для предоставления доступа на чтение файла /etc/shadow для
пользователя postgres, добавьте его в группу shadow:
sudo gpasswd -a postgres shadow
После выполнения задания удалите postgres из группы:
sudo gpasswd -d postgres shadow
Доступ пользователей к /etc/shadow не рекомендуется в реальной
эксплуатации по соображениям безопасности.
