19.3.1. Метод аутентификации trust

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

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

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

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

19.3.2. Метод аутентификации password

Методы аутентификации с помощью пароля это md5 и password. Эти методы работает сходным образом, за исключением пути, по которому отсылается пароль во время подключения, а именно, хешируется через MD5 или обрабатывается как простой текст.

Если вас беспокоит возможность перехвата трафика, предпочтительнее использовать метод md5. Простого метода password следует избегать всегда, если возможно. Однако, md5 не может быть использован с параметром db_user_namespace. Если подключение зашифровано по SSL, тогда password тоже может быть использован без опасений (хотя аутентификация через SSL сертификат будет наилучшим выбором для тех, кто зависит от использования SSL).

База данных паролей PostgreSQL отделена от паролей пользователей операционной системы. Пароль для каждого пользователя базы данных хранится в системном каталоге pg_authid. Работать с паролями можно через команды SQL CREATE USER и ALTER ROLE, например, CREATE USER foo WITH PASSWORD 'secret'. Если для пользователя не было установлено пароля, пароль сохраняется как null, и аутентификация через пароль для данного пользователя будет невозможна.

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

GSSAPI является протоколом отраслевого стандарта для безопасной авторизации, определённым в RFC 2743. PostgreSQL поддерживает GSSAPI с Kerberos аутентификацией с соответствии с RFC 1964. GSSAPI обеспечивает автоматическую аутентификацию (single sign-on), для систем, которые её поддерживают. Сама по себе аутентификация безопасна, но данные, отсылаемые в ходе подключения к базе данных, не защищены, если не используется SSL.

Поддержка GSSAPI должна быть включена при сборке PostgreSQL; за дополнительными сведениями обратитесь к Главе 15.

При работе с Kerberos GSSAPI использует стандартные учётные записи в формате servicename/hostname@realm. Сервер PostgreSQL примет любого принципала, включённого в используемый сервером файл таблицы ключей, но необходимо проявить осторожность в указании корректных деталей принципала в ходе соединения с клиентом, применяющим параметр подключения krbsrvname. (См. также Подраздел 31.1.2.) Значение имени сервиса по умолчанию postgres может быть изменено во время сборки с помощью ./configure --with-krb-srvnam=whatever. В большинстве сред изменять данный параметр не требуется. Однако некоторые реализации Kerberos могут потребовать иного имени сервиса, например, Microsoft Active Directory требует, чтобы имя сервиса было набрано заглавными буквами (POSTGRES).

hostname здесь — это полное доменное имя компьютера, где работает сервер. Областью субъекта-службы является предпочитаемая область данного компьютера.

Клиентские принципалы в качестве первого компонента должны иметь свои имена пользователей базы данных PostgreSQL, например, pgusername@realm. В качестве альтернативы вы можете использовать файл сопоставления имени пользователя, чтобы соотнести первый компонент имени принципала с именем пользователя базы данных. По умолчанию, область клиента не проверяется PostgreSQL. Если у вас включена межобластная аутентификация и вам необходимо проверить область, используйте параметр krb_realm, или подключите include_realm, и используйте сопоставление имён пользователя для проверки области.

Убедитесь, что таблица ключей вашего сервера доступна для чтения учётной записи сервера PostgreSQL (и желательно, только им). (См. также Раздел 17.1.) Расположение таблицы ключей указывается параметром krb_server_keyfile. По умолчанию это /usr/local/pgsql/etc/krb5.keytab (или любой другой каталог, указанный при сборке как sysconfdir). Из соображений безопасности рекомендуется использовать отдельную таблицу ключей исключительно для нужд сервера PostgreSQL, а не открывать доступ к системному файлу таблицы ключей.

Файл таблицы ключей генерируется программным обеспечением Kerberos; подробнее это описано в документации Kerberos. Следующий пример для MIT-совместимых реализаций Kerberos 5:

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

При подключении к базе данных убедитесь, что у вас есть разрешение на сопоставление принципала с именем пользователя базы данных. Например, для имени пользователя базы данных fred, принципал fred@EXAMPLE.COM сможет подключиться. Чтобы дать разрешение на подключение принципалу fred/users.example.com@EXAMPLE.COM, используйте файл сопоставления имён пользователей, как описано в Разделе 19.2.

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

19.3.4. Метод аутентификации SSPI

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

Если используется аутентификация Kerberos, SSPI работает так же, как GSSAPI; подробнее об этом рассказывается в Подразделе 19.3.3.

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

19.3.5. Метод аутентификации Ident

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

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

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

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

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

19.3.6. Аутентификация peer

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

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

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

19.3.7. Метод аутентификации LDAP

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

Аутентификация LDAP может работать в двух режимах. Первый режим называется простое связывание. В ходе аутентификации сервер связывается с характерным именем, составленным следующим образом: prefix username suffix. Обычно, параметр prefix используется для указания cn= или DOMAIN\ в среде Active Directory. suffix используется для указания оставшейся части DN или в среде, отличной от Active Directory.

Второй режим называется поиск+связывание. В ходе аутентификации сервер сначала связывается с каталогом LDAP с закреплённым именем пользователя и паролем, указанным через ldapbinddn и ldapbindpasswd, и выполняет поиск пользователя, пытающегося подключиться к базе данных. Если нет сконфигурированных имени пользователя и пароля, происходит попытка связывания с каталогом. Поиск выполняется в поддереве в ldapbasedn в попытке выявить совпадение с атрибутом, указанном в ldapsearchattribute. Как только в результате поиска определяется пользователь, сервер отключается и заново связывается с каталогом уже как этот пользователь, используя пароль, указанный данным клиентом, чтобы подтвердить, что учётная запись корректна. Этот же режим используется в схемах LDAP-аутентификации в другом программном обеспечении, таком, как Apache mod_authnz_ldap и pam_ldap. Этот метод допускает значительно большую гибкость в том, где в каталоге могут располагаться пользовательские объекты, но в то же время приходится выполнять два отдельных подключения к серверу LDAP.

Следующие параметры конфигурации доступны при аутентификации в обоих режимах:

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

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

Нельзя путать параметры конфигурации для режима простого связывания с параметрами для режима поиск+связывание, это ошибка.

Это пример конфигурации LDAP для простого связывания:

host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"

Когда запрашивается подключение к серверу базы данных в качестве пользователя базы данных someuser, PostgreSQL пытается связаться с LDAP-сервером, используя DN cn=someuser, dc=example, dc=net и пароль, предоставленный клиентом. Если это подключение удалось, то доступ к базе данных будет открыт.

Пример конфигурации для режима поиск+связывание:

host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid

Когда запрашивается подключение к серверу базы данных в качестве пользователя базы данных someuser, PostgreSQL пытается связаться с сервером LDAP анонимно (поскольку ldapbinddn не был указан), выполняет поиск для (uid=someuser) под указанной базой DN. Если запись найдена, проводится попытка связывание с использованием найденной информации и паролем, предоставленным клиентом. Если вторая попытка подключения проходит успешно, предоставляется доступ к базе данных.

Пример той же конфигурации для режима поиск+связывание, но записанной в виде URL:

host ... ldap lapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"

Такой URL-формат используется и другим программным обеспечением, поддерживающим аутентификацию по протоколу LDAP, поэтому распространять такую конфигурацию будет легче.

19.3.8. Аутентификация RADIUS

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

В ходе аутентификации RADIUS на настроенный RADIUS-сервер посылается запрос доступа. Это сообщение типа Только Аутентификация, которое включает в себя параметры имя пользователя, пароль (зашифрованный) и идентификатор NAS. Запрос зашифровывается с использованием общего с сервером секрета. RADIUS-сервер отвечает на запрос сервера либо Доступ принят, либо Доступ отклонён. Система ведения учёта RADIUS не поддерживается.

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

19.3.9. Аутентификация по сертификату

Для аутентификации в рамках этого метода используется клиентский сертификат SSL, поэтому данный способ применим только для SSL подключений. Когда используется этот метод, сервер потребует от клиента предъявления действующего сертификата. Пароль у клиента не запрашивается. Атрибут cn (Обычное имя) сертификата сравнивается с запрашиваемым именем пользователя базы данных, и если они соответствуют, вход разрешается. Если cn отличается от имени пользователя базы данных, то может быть использован файл сопоставления имён пользователя.

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

19.3.10. Метод аутентификации PAM

Данный метод аутентификации работает сходным с методом password образом, за исключением того, что он использует подключаемые модули аутентификации (PAM) как механизм аутентификации. По умолчанию именем службы PAM является postgresql. PAM используется только для подтверждения пар "имя пользователя/пароль". Поэтому пользователь уже должен быть в базе данных, прежде чем механизм PAM может быть использован для аутентификации. Для получения более подробной информацией по PAM, прочтите Linux-PAM Page.

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