Методы аутентификации в PostgreSQL

PostgreSQL предоставляет различные методы аутентификации пользователей (подробнее, на английском языке — здесь):

Trust authentication — доверительная аутентификация, которая просто доверяет тому, что пользователи являются теми, кем они себя называют..
Password authentication — аутентификация по паролю, которая требует, чтобы пользователи отправили пароль.
GSSAPI authentication — аутентификация GSSAPI, основанная на библиотеке безопасности, совместимой с GSSAPI. Обычно это используется для доступа к серверу аутентификации, например серверу Kerberos или Microsoft Active Directory.
SSPI authentication — аутентификация SSPI, использующая протокол, специфичный для Windows, аналогичный GSSAPI.
Ident authentication — идентификационная аутентификация, основанная на службе «Протокол идентификации» (RFC 1413) на клиентском компьютере. (В локальных соединениях через сокет Unix это рассматривается как одноранговая аутентификация.)
Peer authentication — одноранговая аутентификация, которая использует возможности операционной системы для идентификации процесса на другом конце локального соединения. Это не поддерживается для удаленных подключений.
LDAP authentication — аутентификация LDAP, основанная на сервере аутентификации LDAP.
RADIUS authentication — аутентификация RADIUS, основанная на сервере аутентификации RADIUS.
Certificate authentication — аутентификация при помощи сертификата, которая требует SSL-соединения и аутентифицирует пользователей, проверяя отправляемый ими SSL-сертификат.
PAM authentication — аутентификация PAM, основанная на библиотеке PAM (подключаемые модули аутентификации).
BSD authentication — аутентификация BSD, основанная на платформе аутентификации BSD (в настоящее время доступна только в OpenBSD).

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

Далее более подробно описывается каждый из этих методов аутентификации.

Trust authentication или доверительная аутентификация

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

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

Обычно он не используется на многопользовательской машине. Однако вы можете использовать доверие даже на многопользовательском компьютере, если ограничите доступ к файлу сокета Unix-домена сервера с помощью разрешений файловой системы. Для этого установите параметры конфигурации unix_socket_permissions (и, возможно, unix_socket_group). Или вы можете установить параметр конфигурации unix_socket_directories, чтобы поместить файл сокета в каталог с соответствующим ограничением.

Установка разрешений файловой системы помогает только для соединений через сокет Unix. Локальные соединения TCP/IP не ограничиваются разрешениями файловой системы. Поэтому, если вы хотите использовать разрешения файловой системы для локальной безопасности, удалите строку хоста … 127.0.0.1… из pg_hba.conf или измените ее на метод аутентификации без доверия.

Доверительная аутентификация подходит только для соединений TCP/IP, если вы доверяете каждому пользователю на каждом компьютере, которому разрешено подключение к серверу с помощью строк pg_hba.conf, определяющих доверие. Редко бывает разумно использовать доверие для каких-либо соединений TCP/IP, кроме соединений с локального хоста (127.0.0.1).

Password authentication или аутентификация по паролю

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

scram-sha-256

Метод scram-sha-256 выполняет аутентификацию SCRAM-SHA-256, как описано в RFC 7677. Это схема запрос-ответ, которая предотвращает перехват паролей в ненадежных соединениях и поддерживает хранение паролей на сервере в криптографически хешированной форме, которая считается чтобы быть в безопасности. Это наиболее безопасный из имеющихся в настоящее время методов, но он не поддерживается старыми клиентскими библиотеками.

md5

Метод md5 использует собственный менее безопасный механизм запроса-ответа. Он предотвращает перехват паролей и позволяет избежать хранения паролей на сервере в виде обычного текста, но не обеспечивает защиты, если злоумышленнику удастся украсть хэш пароля с сервера. Кроме того, алгоритм хэширования MD5 в настоящее время больше не считается защищенным от целенаправленных атак.

Метод md5 нельзя использовать с функцией db_user_namespace.

Чтобы облегчить переход от метода md5 к более новому методу SCRAM, если md5 указан как метод в pg_hba.conf, но пароль пользователя на сервере зашифрован для SCRAM (см. ниже), то вместо этого автоматически будет выбрана аутентификация на основе SCRAM.

password

Метод password отправляет пароль в виде открытого текста и поэтому уязвим для атак с перехватом пароля. По возможности всегда следует избегать этого. Однако если соединение защищено шифрованием SSL, пароль можно использовать безопасно. (Хотя проверка подлинности сертификата SSL может быть лучшим выбором, если вы зависите от использования SSL).

Пароли базы данных PostgreSQL отделены от паролей пользователей операционной системы. Пароль для каждого пользователя базы данных хранится в системном каталоге pg_authid. Паролями можно управлять с помощью команд SQL CREATE ROLE и ALTER ROLE, например, CREATE ROLE foo With LOGIN PASSWORD ‘secret’ или команды psql \password. Если для пользователя не установлен пароль, сохраненный пароль имеет значение NULL, и аутентификация по паролю для этого пользователя всегда будет завершаться неудачно.

Доступность различных методов аутентификации на основе пароля зависит от того, как пароль пользователя на сервере шифруется (или, точнее, хэшируется). Это контролируется параметром конфигурации pass_encryption во время установки пароля. Если пароль был зашифрован с использованием настройки scram-sha-256, то его можно использовать для методов аутентификации scram-sha-256 и пароля (но в последнем случае передача пароля будет осуществляться в виде открытого текста). Спецификация метода аутентификации md5 в этом случае автоматически переключится на использование метода scram-sha-256, как описано выше, поэтому он также будет работать. Если пароль был зашифрован с использованием настройки md5, то его можно использовать только для спецификаций md5 и метода аутентификации пароля (опять же, в последнем случае пароль передается в виде открытого текста). (Предыдущие выпуски PostgreSQL поддерживали хранение пароля на сервере в виде обычного текста. Это больше невозможно.) Чтобы проверить сохраненные в данный момент хэши паролей, обратитесь к системному каталогу pg_authid.

Чтобы обновить существующую установку с md5 до scram-sha-256, убедившись, что все используемые клиентские библиотеки достаточно новы для поддержки SCRAM, установите пароль_encryption = ‘scram-sha-256’ в postgresql.conf, сделайте так, чтобы все пользователи установили новый пароль и измените спецификации метода аутентификации в pg_hba.conf на scram-sha-256.

Аутентификация GSSAPI

GSSAPI — это стандартный протокол безопасной аутентификации, определенный в RFC 2743. PostgreSQL поддерживает GSSAPI для аутентификации, шифрования связи или того и другого. GSSAPI обеспечивает автоматическую аутентификацию (единый вход) для систем, которые его поддерживают. Сама аутентификация безопасна. Если используется шифрование GSSAPI или SSL, данные, передаваемые по соединению с базой данных, будут зашифрованы; в противном случае этого не произойдет.

Поддержка GSSAPI должна быть включена при сборке PostgreSQL.

Когда GSSAPI использует Kerberos, он использует стандартное имя субъекта-службы (идентификатор аутентификации) в формате имя_службы/имя_хоста@область. Имя участника, используемое конкретной установкой, никоим образом не кодируется на сервере PostgreSQL; скорее он указан в файле keytab, который сервер читает, чтобы определить его идентичность. Если в файле keytab указано несколько участников, сервер примет любого из них. Имя области сервера — это предпочтительная область, указанная в файлах конфигурации Kerberos, доступных серверу.

При подключении клиент должен знать основное имя сервера, к которому он собирается подключиться. Частью имени службы принципала обычно является postgres, но другое значение можно выбрать с помощью параметра подключения krbsrvname библиотеки libpq. Часть имени хоста — это полное имя хоста, к которому libpq сообщается о подключении. Имя области — это предпочтительная область, указанная в файлах конфигурации Kerberos, доступных клиенту.

Клиент также будет иметь имя принципала для своего удостоверения (и у него должен быть действительный билет для этого принципала). Чтобы использовать GSSAPI для аутентификации, клиентский субъект должен быть связан с именем пользователя базы данных PostgreSQL. Файл конфигурации pg_ident.conf можно использовать для сопоставления участников с именами пользователей; например, pgusername@realm можно сопоставить просто с pgusername. Альтернативно вы можете использовать полное имя пользователя@realm в качестве имени роли в PostgreSQL без какого-либо сопоставления.

PostgreSQL также поддерживает сопоставление принципалов клиента с именами пользователей, просто удаляя область из принципала. Этот метод поддерживается для обратной совместимости и настоятельно не рекомендуется, так как в этом случае невозможно отличить разных пользователей с одним и тем же именем пользователя, но принадлежащих разным областям. Чтобы включить это, установите для include_realm значение 0. Для простых установок с одной областью это в сочетании с установкой параметра krb_realm (который проверяет, соответствует ли область принципала тому, что указано в параметре krb_realm), по-прежнему безопасно; но это менее эффективный подход по сравнению с указанием явного сопоставления в pg_ident.conf.

Местоположение файла keytab сервера указывается параметром конфигурации krb_server_keyfile. По соображениям безопасности рекомендуется использовать отдельную таблицу ключей только для сервера PostgreSQL, а не разрешать серверу читать системный файл таблицы ключей. Убедитесь, что файл таблицы ключей вашего сервера доступен для чтения (и желательно только для чтения, а не для записи) учетной записью сервера PostgreSQL. (См. также раздел 19.1.)

Файл keytab создается с помощью программного обеспечения Kerberos; подробности см. в документации Kerberos. В следующем примере показано, как это сделать с помощью инструмента kadmin MIT Kerberos:

kadmin% addprinc -randkey postgres/server.my.domain.org
kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org

Для метода аутентификации GSSAPI поддерживаются следующие параметры аутентификации:

include_realm

Если установлено значение 0, имя области из аутентифицированного пользователя-участника удаляется перед передачей через сопоставление имен пользователей. Это не рекомендуется и в первую очередь доступно для обратной совместимости, поскольку это небезопасно в средах с несколькими областями, если также не используется krb_realm. Рекомендуется оставить для include_realm значение по умолчанию (1) и предоставить явное сопоставление в pg_ident.conf для преобразования имен участников в имена пользователей PostgreSQL.

map

Позволяет сопоставлять участников клиента с именами пользователей базы данных. Для субъекта GSSAPI/Kerberos, такого как username@EXAMPLE.COM (или, реже, username/hostbased@EXAMPLE.COM), имя пользователя, используемое для сопоставления, — username@EXAMPLE.COM (или username/hostbased@EXAMPLE.COM). , соответственно), если для параметра include_realm не установлено значение 0, в этом случае имя пользователя (или имя пользователя/на основе хоста) — это то, что рассматривается как имя системного пользователя при сопоставлении.

krb_realm

Устанавливает область для сопоставления имен участников-пользователей. Если этот параметр установлен, будут приниматься только пользователи этой области. Если он не установлен, пользователи любой области могут подключаться, независимо от того, какое сопоставление имен пользователей выполнено.

В дополнение к этим настройкам, которые могут различаться для разных записей pg_hba.conf, существует общесерверный параметр конфигурации krb_caseins_users. Если для этого параметра установлено значение true, субъекты клиента сопоставляются с записями карты пользователей без учета регистра. krb_realm, если он установлен, также сопоставляется без учета регистра.

SSPI-аутентификация

SSPI — это технология Windows для безопасной аутентификации с помощью единого входа. PostgreSQL будет использовать SSPI в режиме согласования, который будет использовать Kerberos, когда это возможно, и автоматически переключаться на NTLM в других случаях. SSPI и GSSAPI взаимодействуют как клиенты и серверы, например, клиент SSPI может проходить аутентификацию на сервере GSSAPI. Рекомендуется использовать SSPI на клиентах и серверах Windows и GSSAPI на платформах, отличных от Windows.

При использовании аутентификации Kerberos SSPI работает так же, как GSSAPI.

Для SSPI поддерживаются следующие параметры конфигурации:

include_realm

compat_realm

Если установлено значение 1, для параметра include_realm используется SAM-совместимое имя домена (также известное как NetBIOS-имя). Это значение по умолчанию. Если установлено значение 0, используется истинное имя области из имени основного пользователя Kerberos.

Не отключайте эту опцию, если ваш сервер не работает под учетной записью домена (включая учетные записи виртуальных служб в системе-члене домена) и все клиенты, проверяющие подлинность через SSPI, также используют учетные записи домена, иначе проверка подлинности завершится неудачей.

upn_username

Если этот параметр включен вместе с compat_realm, для аутентификации используется имя пользователя из UPN Kerberos. Если он отключен (по умолчанию), используется имя пользователя, совместимое с SAM. По умолчанию эти два имени идентичны для новых учетных записей пользователей.

Обратите внимание, что libpq использует имя, совместимое с SAM, если явное имя пользователя не указано. Если вы используете libpq или драйвер на ее основе, вам следует оставить эту опцию отключенной или явно указать имя пользователя в строке подключения.

map

Позволяет сопоставлять имена пользователей системы и базы данных. Для субъекта SSPI/Kerberos, такого как имя_пользователя@EXAMPLE.COM (или, реже, имя_пользователя/hostbased@EXAMPLE.COM), имя пользователя, используемое для сопоставления, — имя_пользователя@EXAMPLE.COM (или имя_пользователя/hostbased@EXAMPLE.COM). , соответственно), если для параметра include_realm не установлено значение 0, в этом случае имя пользователя (или имя пользователя/на основе хоста) — это то, что рассматривается как имя системного пользователя при сопоставлении.

krb_realm

Аутентификация ident

Метод аутентификации ident работает путем получения имени пользователя операционной системы клиента с сервера ident и использования его в качестве разрешенного имени пользователя базы данных (с дополнительным сопоставлением имени пользователя). Это поддерживается только для соединений TCP/IP.

Примечание!!!
Если для локального соединения (не TCP/IP) указан идентификатор, вместо него будет использоваться peer аутентификация.

Для ident поддерживаются следующие параметры конфигурации:

map

Позволяет сопоставлять имена пользователей системы и базы данных.

«Протокол идентификации» описан в RFC 1413. Практически каждая Unix-подобная операционная система поставляется с сервером идентификации, который по умолчанию прослушивает TCP-порт 113. Основная функциональность сервера идентификации — отвечать на такие вопросы, как «Какой пользователь инициировал соединение, которое выходит из вашего порта X и подключается к моему порту Y?». Поскольку PostgreSQL знает как X, так и Y, когда физическое соединение установлено, он может опрашивать сервер идентификации на хосте подключающегося клиента и теоретически может определить пользователя операционной системы для любого данного соединения.

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

Обратите внимание на предупреждение:

Протокол идентификации не предназначен для использования в качестве протокола авторизации или контроля доступа. --RFC 1413

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

Peer Authentication или одноранговая аутентификация

Метод Peer аутентификации работает путем получения имени пользователя операционной системы клиента из ядра и использования его в качестве разрешенного имени пользователя базы данных (с дополнительным сопоставлением имен пользователей). Этот метод поддерживается только для локальных подключений.

Для однорангового узла поддерживаются следующие параметры конфигурации:

map

Позволяет сопоставлять имена пользователей системы и базы данных.

Одноранговая аутентификация доступна только в операционных системах, предоставляющих функцию getpeereid(), параметр сокета SO_PEERCRED или аналогичные механизмы. В настоящее время сюда входят Linux, большинство разновидностей BSD, включая macOS, и Solaris.