19.3. Методы аутентификации
Следующие подразделы содержат более детальную информацию о методах аутентификации.
19.3.1. Аутентификация trust
Когда указан способ аутентификации trust
, Postgres Pro предполагает, что любой подключающийся к серверу авторизован для доступа к базе данных вне зависимости от указанного имени пользователя базы данных (даже если это имя суперпользователя). Конечно, ограничения, прописанные в столбцах база
и пользователь
, продолжают работать. Этот метод должен применяться только в том случае, когда на уровне операционной системы обеспечена адекватная защита от подключений к серверу.
Аутентификация 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).
База данных паролей Postgres Pro отделена от паролей пользователей операционной системы. Пароль для каждого пользователя базы данных хранится в системном каталоге pg_authid
. Работать с паролями можно через команды SQL CREATE USER и ALTER ROLE, например, CREATE USER foo WITH PASSWORD 'secret'
. Если для пользователя не было установлено пароля, пароль сохраняется как null, и аутентификация через пароль для данного пользователя будет невозможна.
19.3.3. Аутентификация GSSAPI
GSSAPI является протоколом отраслевого стандарта для безопасной авторизации, определённым в RFC 2743. Postgres Pro поддерживает GSSAPI с Kerberos аутентификацией с соответствии с RFC 1964. GSSAPI обеспечивает автоматическую аутентификацию (single sign-on), для систем, которые её поддерживают. Сама по себе аутентификация безопасна, но данные, отсылаемые в ходе подключения к базе данных, не защищены, если не используется SSL.
Поддержка GSSAPI должна быть включена при сборке Postgres Pro; за дополнительными сведениями обратитесь к Главе 15.
При работе с Kerberos GSSAPI использует стандартные учётные записи в формате
. Сервер Postgres Pro примет любого принципала, включённого в используемый сервером файл таблицы ключей, но необходимо проявить осторожность в указании корректных деталей принципала в ходе соединения с клиентом, применяющим параметр подключения servicename
/hostname
@realm
krbsrvname
. (См. также Подраздел 31.1.2.) Значение имени сервиса по умолчанию postgres
может быть изменено во время сборки с помощью ./configure --with-krb-srvnam=
whatever
. В большинстве сред изменять данный параметр не требуется. Однако некоторые реализации Kerberos могут потребовать иного имени сервиса, например, Microsoft Active Directory требует, чтобы имя сервиса было набрано заглавными буквами (POSTGRES
).
hostname
здесь — это полное доменное имя компьютера, где работает сервер. Областью субъекта-службы является предпочитаемая область данного компьютера.
Принципалы клиентов могут быть сопоставлены с различными именами пользователей баз данных Postgres Pro в pg_ident.conf
. Например, принципалу pgusername@realm
может быть сопоставлено просто pgusername
. Так же возможно использовать в качестве имени роли в Postgres Pro полное имя принципала username@realm
без какого-либо сопоставления.
Postgres Pro также поддерживает возможность убрать область из имени принципала. Эта возможность оставлена для обратной совместимости и использовать её крайне нежелательно, так как при этом оказывается невозможно различить разных пользователей, имеющих одинаковые имена, но приходящих из разных областей. Чтобы включить её, установите для include_realm
значение 0. В простых конфигурациях с одной областью применение include_realm
в сочетании с параметром krb_realm
(который позволяет ограничить область пользователя одним значением, заданным в krb_realm
parameter) будет безопасным, но менее гибким вариантом по сравнении с явным описанием сопоставлений в pg_ident.conf
.
Убедитесь, что таблица ключей вашего сервера доступна для чтения учётной записи сервера Postgres Pro (и желательно, только им). (См. также Раздел 17.1.) Расположение таблицы ключей указывается параметром krb_server_keyfile. По умолчанию это /usr/local/pgsql/etc/krb5.keytab
(или любой другой каталог, указанный при сборке как sysconfdir
). Из соображений безопасности рекомендуется использовать отдельную таблицу ключей исключительно для нужд сервера Postgres Pro, а не открывать доступ к системному файлу таблицы ключей.
Файл таблицы ключей генерируется программным обеспечением 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 доступны следующие параметры конфигурации:
include_realm
Когда этот параметр равен 0, из принципала аутентифицированного пользователя убирается область, и оставшееся имя проходит сопоставление имён (см. Раздел 19.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся
krb_realm
. Более предпочтительный вариант — оставить значение include_realm по умолчанию (1) и задать явное сопоставление вpg_ident.conf
.map
Разрешает сопоставление имён пользователей системы и пользователей баз данных. За подробностями обратитесь к Разделу 19.2. Для принципала GSSAPI/Kerberos, такого как
username@EXAMPLE.COM
(или более редкогоusername/hostbased@EXAMPLE.COM
), именем пользователя в сопоставлении будетusername@EXAMPLE.COM
(илиusername/hostbased@EXAMPLE.COM
, соответственно), еслиinclude_realm
не равно 0; в противном случае именем системного пользователя в сопоставлении будетusername
(илиusername/hostbased
).krb_realm
Устанавливает область, с которой будут сверяться имена принципалов пользователей. Если этот параметр задан, подключаться смогут только пользователи из этой области. Если не задан, подключаться смогут пользователи из любой области, в зависимости от установленного сопоставления имён пользователей.
19.3.4. Аутентификация SSPI
SSPI — технология Windows для защищённой аутентификации с единственным входом. Postgres Pro использует SSPI в режиме negotiate
, который применяет Kerberos, когда это возможно, и автоматически возвращается к NTLM в других случаях. Аутентификация SSPI возможна только когда и сервер, и клиент работают на платформе Windows или на других платформах, где доступен GSSAPI.
Если используется аутентификация Kerberos, SSPI работает так же, как GSSAPI; подробнее об этом рассказывается в Подразделе 19.3.3.
Для SSPI доступны следующие параметры конфигурации:
include_realm
Когда этот параметр равен 0, из принципала аутентифицированного пользователя убирается область, и оставшееся имя проходит сопоставление имён (см. Раздел 19.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся
krb_realm
. Более предпочтительный вариант — оставить значение include_realm по умолчанию (1) и задать явное сопоставление вpg_ident.conf
.map
Позволяет сопоставить пользователей системы с пользователями баз данных. За подробностями обратитесь к Разделу 19.2. Для принципала SSPI/Kerberos, такого как
username@EXAMPLE.COM
(или более редкогоusername/hostbased@EXAMPLE.COM
), именем пользователя в сопоставлении будетusername@EXAMPLE.COM
(илиusername/hostbased@EXAMPLE.COM
, соответственно), еслиinclude_realm
не равно 0; в противном случае именем системного пользователя в сопоставлении будетusername
(илиusername/hostbased
).krb_realm
Устанавливает область, с которой будут сверяться имена принципалов пользователей. Если этот параметр задан, подключаться смогут только пользователи из этой области. Если не задан, подключаться смогут пользователи из любой области, в зависимости от установленного сопоставления имён пользователей.
19.3.5. Аутентификация Ident
Метод аутентификации ident работает, получая имя пользователя операционной системы клиента от сервера Ident и используя его в качестве разрешённого имени пользователя базы данных (с возможным сопоставлением имён пользователя). Способ доступен только для подключений по TCP/IP.
Примечание
Когда для локального подключения (не TCP/IP) указан ident, вместо него используется метод аутентификации peer (см. Подраздел 19.3.6).
Для метода ident доступны следующие параметры конфигурации:
map
Позволяет сопоставить имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 19.2.
Протокол «Identification» (Ident) описан в RFC 1413. Практически каждая Unix-подобная операционная система поставляется с сервером Ident, по умолчанию слушающим TCP-порт 113. Базовая функция этого сервера — отвечать на вопросы, вроде «Какой пользователь инициировал подключение, которое идет через твой порт X
и подключается к моему порту Y
?». Поскольку после установления физического подключения Postgres Pro знает и X
, и Y
, он может опрашивать сервер Ident на компьютере клиента и теоретически может определять пользователя операционной системы при каждом подключении.
Недостатком этой процедуры является то, что она зависит от интеграции с клиентом: если клиентская машина не вызывает доверия или скомпрометирована, злоумышленник может запустить любую программу на порту 113 и вернуть любое имя пользователя на свой выбор. Поэтому этот метод аутентификации подходит только для закрытых сетей, где каждая клиентская машина находится под жёстким контролем и где администраторы операционных систем и баз данных работают в тесном контакте. Другими словами, вы должны доверять машине, на которой работает сервер Ident. Помните предупреждение:
Протокол Ident не предназначен для использования как протокол авторизации и контроля доступа. | ||
--RFC 1413 |
У некоторых серверов Ident есть нестандартная возможность, позволяющая зашифровать возвращаемое имя пользователя, используя ключ, который известен только администратору исходного компьютера. Эту возможность нельзя использовать с Postgres Pro, поскольку Postgres Pro не сможет расшифровать возвращаемую строку и получить фактическое имя пользователя.
19.3.6. Аутентификация peer
Метод аутентификации peer работает, получая имя пользователя операционной системы клиента из ядра и используя его в качестве разрешённого имени пользователя базы данных (с возможностью сопоставления имён пользователя). Этот метод поддерживается только для локальных подключений.
Для метода peer доступны следующие параметры конфигурации:
map
Позволяет сопоставить имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 19.2.
Аутентификация 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-аутентификации в другом программном обеспечении, например, в pam_ldap и mod_authnz_ldap в Apache. Данный вариант даёт больше гибкости в выборе расположения объектов пользователей, но при этом требует дважды подключаться к серверу LDAP.
Следующие параметры конфигурации доступны при аутентификации в обоих режимах:
ldapserver
Имена и IP-адреса LDAP-серверов для связи. Можно указать несколько серверов, разделяя их пробелами.
ldapport
Номер порта для связи с LDAP-сервером. Если порт не указан, используется установленный по умолчанию порт библиотеки LDAP.
ldaptls
Равен 1 для установки соединения между Postgres Pro и LDAP-сервером с использованием TLS-шифрования. Имейте в виду, что так шифруется только обмен данными с LDAP-сервером, а клиентское подключение остаётся незашифрованным, если только не применяется SSL.
Следующие параметры конфигурации доступны только при аутентификации в режиме простого связывания:
ldapprefix
Эта строка подставляется перед именем пользователя во время формирования DN для связывания при аутентификации в режиме простого связывания.
ldapsuffix
Эта строка размещается после имени пользователя во время формирования DN для связывания, при аутентификации в режиме простого связывания.
Следующие параметры конфигурации доступны только при аутентификации поиск+связывание:
ldapbasedn
Корневая папка DN для начала поиска пользователя при аутентификации в режиме поиск+связывание.
ldapbinddn
DN пользователя для связи с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание.
ldapbindpasswd
Пароль пользователя для связывания с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание.
ldapsearchattribute
Атрибут для соотнесения с именем пользователя в ходе аутентификации поиск+связывание. Если атрибут не указан, будет использован атрибут
uid
.ldapurl
Адрес RFC 4516 LDAP. Это альтернативный путь для написания некоторых функций LDAP в более компактной и стандартной форме. Формат записи таков:
ldap://
host
[:port
]/basedn
[?[attribute
][?[scope
]]]scope
должен быть представлен илиbase
, илиone
, илиsub
, обычно последним. Используется один атрибут, некоторые компоненты стандартных LDAP-адресов, такие, как фильтры и расширения, не поддерживаются.Для неанонимного связывания
ldapbinddn
иldapbindpasswd
должны быть указаны как раздельные параметры.Для применения зашифрованных LDAP-подключений, в дополнение к параметру
ldapurl
необходимо использовать параметрldaptls
. URL-схемаldaps
(прямое SSL-подключение) не поддерживается.В настоящее время URL-адреса LDAP поддерживаются только с OpenLDAP и не поддерживаются в Windows.
Нельзя путать параметры конфигурации для режима простого связывания с параметрами для режима поиск+связывание, это ошибка.
Это пример конфигурации LDAP для простого связывания:
host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
Когда запрашивается подключение к серверу базы данных в качестве пользователя базы данных someuser
, Postgres Pro пытается связаться с LDAP-сервером, используя DN cn=someuser, dc=example, dc=net
и пароль, предоставленный клиентом. Если это подключение удалось, то доступ к базе данных будет открыт.
Пример конфигурации для режима поиск+связывание:
host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid
Когда запрашивается подключение к серверу базы данных в качестве пользователя базы данных someuser
, Postgres Pro пытается связаться с сервером LDAP анонимно (поскольку ldapbinddn
не был указан), выполняет поиск для (uid=someuser)
под указанной базой DN. Если запись найдена, проводится попытка связывание с использованием найденной информации и паролем, предоставленным клиентом. Если вторая попытка подключения проходит успешно, предоставляется доступ к базе данных.
Пример той же конфигурации для режима поиск+связывание, но записанной в виде URL:
host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
Такой URL-формат используется и другим программным обеспечением, поддерживающим аутентификацию по протоколу LDAP, поэтому распространять такую конфигурацию будет легче.
Подсказка
Поскольку LDAP часто применяет запятые и пробелы для разделения различных частей DN, необходимо использовать кавычки при определении значения параметров, как показано в наших примерах.
19.3.8. Аутентификация RADIUS
Данный метод аутентификации работает сходным с методом password
образом, за исключением того, что он использует RADIUS как метод проверки пароля. RADIUS используется только для подтверждения пары имя пользователя/пароль. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации будет использован RADIUS.
В ходе аутентификации RADIUS настроенному RADIUS-серверу посылается запрос доступа. Это сообщение типа Только Аутентификация
, которое включает в себя параметры имя пользователя
, пароль
(зашифрованный) и идентификатор NAS
. Запрос зашифровывается с использованием общего с сервером секрета. RADIUS-сервер отвечает на запрос сервера либо Доступ принят
, либо Доступ отклонён
. Система ведения учёта RADIUS не поддерживается.
Для метода RADIUS доступны следующие параметры конфигурации:
radiusserver
Имя или IP-адрес сервера RADIUS, с которым будет проходить соединение. Это обязательный параметр.
radiussecret
Общий секрет, используемый при контактах с сервером RADIUS. Он должен иметь одинаковое значение на серверах Postgres Pro и RADIUS. Рекомендуется использовать строку как минимум из 16 символов. Это обязательный параметр.
Примечание
Шифровальный вектор будет достаточно эффективен только в том случае, если Postgres Pro собран с поддержкой OpenSSL. В противном случае передача данных серверу RADIUS будет лишь замаскированной, но не защищённой, поэтому необходимо принять дополнительные меры безопасности.
radiusport
Номер порта для связи с сервером RADIUS. Если порт не указан, по умолчанию используется порт
1812
.radiusidentifier
Строка, используемая в запросах сервера RADIUS как
Идентификатор NAS
. Этот параметр может использоваться как второй параметр, выявляющий, например, какой пользователь пытается подключиться под каким пользователем базы данных, что может быть использовано для формирования соответствий на сервере RADIUS. Если не указан идентификатор, по умолчанию используетсяpostgresql
.
19.3.9. Аутентификация по сертификату
Для аутентификации в рамках этого метода используется клиентский сертификат SSL, поэтому данный способ применим только для SSL подключений. Когда используется этот метод, сервер потребует от клиента предъявления действующего сертификата. Пароль у клиента не запрашивается. Атрибут cn
(Обычное имя) сертификата сравнивается с запрашиваемым именем пользователя базы данных, и если они соответствуют, вход разрешается. Если cn
отличается от имени пользователя базы данных, то может быть использован файл сопоставления имён пользователя.
Для аутентификации по SSL сертификату доступны следующие параметры конфигурации:
map
Позволяет сопоставить имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 19.2.
19.3.10. Аутентификация PAM
Данный метод аутентификации работает сходным с методом password
образом, за исключением того, что он использует подключаемые модули аутентификации (PAM) как механизм аутентификации. По умолчанию именем службы PAM является postgresql
. PAM используется только для подтверждения пар "имя пользователя/пароль". Поэтому пользователь уже должен быть в базе данных, прежде чем механизм PAM может быть использован для аутентификации. Для получения более подробной информацией по PAM, прочтите Linux-PAM Page.
Для аутентификации PAM доступны следующие параметры конфигурации:
pamservice
Имя службы PAM
Примечание
Если PAM настроен для чтения /etc/shadow
, произойдёт сбой аутентификации, потому что сервер Postgres Pro запущен не пользователем root. Однако это не имеет значения, когда PAM настроен для использования LDAP или других методов аутентификации.