Astra linux postgresql аутентификация

Для реализации требований защиты информации при работе с защищенной системой управления базами данных «PostgreSQL» (ЗСУБД) в операционной системе специального назначения «Astra Linux Special Edition» (ОССН «Astra Linux SE») необходимо использовать только методы аутентификации, при которых выполняется сопоставление пользователей (также известных как роли с привилегией «LOGIN») ЗСУБД с пользователями ОССН «Astra Linux SE». Для использования методов аутентификации, при которых выполняется сопоставление пользователей ЗСУБД с пользователями ОССН «Astra Linux SE», необходимо выполнить следующие действия: – предоставить пользователю, от имени которого работает ЗСУБД (как правило, это пользователь «postgres»), права на чтение информации о пользователях ОССН «Astra Linux SE»: usermod -a -G shadow postgres

и права на чтение информации о мандатных атрибутах: setfacl -d -m u:postgres:r /etc/parsec/macdb
setfacl -R -m u:postgres:r /etc/parsec/macdb
setfacl -m u:postgres:rx /etc/parsec/macdb setfacl -d -m u:postgres:r /etc/parsec/capdb
setfacl -R -m u:postgres:r /etc/parsec/capdb
setfacl -m u:postgres:rx /etc/parsec/capdb – установить у пользователей ОССН «Astra Linux SE», соответствущих пользователям ЗСУБД, мандатные атрибуты (даже если предполагается работа только с информацией, имеющей нулевые значения мандатных уровней и категорий): где – имя пользователя ОССН «Astra Linux SE». При использовании ЗСУБД в ОССН «Astra Linux SE» (1.5 «Смоленск») выяснилась еще одна особенность. Методы аутентификации, не предполагающие (в соответствии с описанием методов аутентификации в документации) сопоставления пользователей ЗСУБД с пользователями ОССН «Astra Linux SE» (например, метод «md5»), работают только при наличии в ОССН «Astra Linux SE» пользователей, соответствующих пользователям ЗСУБД.

Согласно информации, полученной от техподдержки ОССН «Astra Linux SE»: – указанная особенность является следствием доработки СУБД «PostgreSQL» разработчиками ОССН «Astra Linux SE»; – такое поведение можно изменить путем установки значения «yes» у параметра «zero_if_notfound» в файле «/etc/parsec/mswitch.conf». В этом случае методы аутентификации, не предполагающие сопоставления пользователей ЗСУБД с пользователями ОССН «Astra Linux SE», будут работать и при отсутствии в ОССН «Astra Linux SE» пользователей, соответствующих пользователям ЗСУБД. Однако тут всплыл нюанс. На практике выяснилось, что этот подход не работает в случае работы ЗСУБД в едином пространстве пользователей (ЕПП). Специалисты техподдержки ОССН «Astra Linux SE» сказали, что в дальнейшем постараются решить этот вопрос. С уважением, Анатолий Борисов, СПБ ЦГТ
17.02.2019 Источник

Операционные системы Astra Linux

Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. Astra Linux Common Edition предназначена для автоматизации коммерческих предприятий и органов государственного управления.

Astra Linux Special Edition предназначена для применения в автоматизированных системах в защищенном исполнении, обрабатывающих информацию ограниченного распространения, включая государственную тайну до степени секретности «особой важности» . На сайте представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения. Кроме того, предоставлена возможность скачать дистрибутивы и исходные тексты операционной системы Astra Linux Common Edition, а также задать интересующие вопросы разработчикам . Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи! Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков. Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить на нашем сайте. Источник

Операционные системы Astra Linux

Astra Linux Common Edition предназначена для автоматизации коммерческих предприятий и органов государственного управления. Astra Linux Special Edition предназначена для применения в автоматизированных системах в защищенном исполнении, обрабатывающих информацию ограниченного распространения, включая государственную тайну до степени секретности «особой важности» . На сайте представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения. Кроме того, предоставлена возможность скачать дистрибутивы и исходные тексты операционной системы Astra Linux Common Edition, а также задать интересующие вопросы разработчикам . Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи! Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков. Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить на нашем сайте. Источник

Ввод Astra Linux Special Edition 1.6 в Active Directory с настройкой SSO в PostgreSQL.

Настроим ОС Astra Linux SE 1.6 и введем в домен MS Active Directory . В процессе настроим SMABA, WINBIND и POSTGRESQL, а также настроим в POSTGRESQL SSO через GSSAPI. Данная настройка проводилась с обновлением ОС Astra Linux SE 1.6 — 20191029SE16 . Процесс обновления ОС не описан в процессе конфигурации.

Вводные данные

Контроллеры домена Active Directory

ОС — MS Windows Server 2012R2

Сервер c базой данных Postgresql

ОС – Astra Linux SE 1.6. Установлена без ALD и без режима киоска. Дополнительное ПО выбрано базовые средства, рабочий стол Fly, средства работы в сети, СУБД.

Разблокировка учетной записи ROOT

Для удобства настройки разблокируем учетную запись ROOT
Для безопасности по окончанию работ требуется заблокировать учетную запись ROOT!

Настройка сети на bd1

Приведем файл /etc/hosts к виду Проверим правильность имени машины в /etc/hostname Настроим статический IP-адрес, для этого внесем строки в файл /etc/network/interfaces Для автоматической генерации файла /etc/resolv.conf установим пакет resolvconf. Перезапустим службу сети Проверим, должен появиться интерфейс eth0 с назначенным нами адресом 192.168.0.100

Проверим доступность контроллеров домена Active Directory Настроим синхронизацию времени с контроллерами домена, для этого в файле /etc/ntp.conf добавим в секцию «You do need to talk to an NTP server or two (or three)»

Установим требуемые пакеты

Сначала проверим установлены ли пакеты SAMBA, WINBIND, NTP и POSTGRESQL

dpkg – l samba winbind ntp postgresql

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

apt-get install nscd nslcd libpam-winbind libpam-krb5 libsasl2-modules-gssapi-mit krb5-user libnss-winbind

Чтобы установить следующий пакет потребуется диск разработчика

apt-get install libsasl2-modules-ldap

Настройка конфигурационных файлов для работы с доменом Active Directory.

Отредактируем конфигурационный файл Kerberos /etc/krb5.conf и приведем его к виду Источник

Astra linux postgresql аутентификация

Следующие подразделы содержат более детальную информацию о методах аутентификации.

20.3.1. Аутентификация trust

Когда указан способ аутентификации trust , PostgreSQL предполагает, что любой подключающийся к серверу авторизован для доступа к базе данных вне зависимости от указанного имени пользователя базы данных (даже если это имя суперпользователя). Конечно, ограничения, прописанные в столбцах база и пользователь , продолжают работать. Этот метод должен применяться только в том случае, когда на уровне операционной системы обеспечена адекватная защита от подключений к серверу. Аутентификация trust очень удобна для локальных подключений на однопользовательской рабочей станции. Но сам по себе этот метод обычно не подходит для машин с несколькими пользователями. Однако вы можете использовать trust даже на многопользовательской машине, если ограничите доступ к файлу Unix-сокета сервера на уровне файловой системы. Для этого установите конфигурационные параметры unix_socket_permissions (и, возможно, unix_socket_group ) как описано в Разделе 19.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).

20.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, и аутентификация через пароль для данного пользователя будет невозможна.

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

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

hostname здесь — это полное доменное имя компьютера, где работает сервер. Областью субъекта-службы является предпочитаемая область данного компьютера. Принципалы клиентов могут быть сопоставлены с различными именами пользователей баз данных PostgreSQL в pg_ident.conf . Например, принципалу pgusername@realm может быть сопоставлено просто pgusername . Так же возможно использовать в качестве имени роли в PostgreSQL полное имя принципала username@realm без какого-либо сопоставления. PostgreSQL также поддерживает возможность убирать область из имени принципала. Эта возможность оставлена для обратной совместимости и использовать её крайне нежелательно, так как при этом оказывается невозможно различить разных пользователей, имеющих одинаковые имена, но приходящих из разных областей. Чтобы включить её, установите для include_realm значение 0. В простых конфигурациях с одной областью исключение области в сочетании с параметром krb_realm (который позволяет ограничить область пользователя одним значением, заданным в krb_realm parameter) будет безопасным, но менее гибким вариантом по сравнению с явным описанием сопоставлений в pg_ident.conf . Убедитесь, что файл ключей вашего сервера доступен для чтения (и желательно недоступен для записи) учётной записи сервера PostgreSQL . (См. также Раздел 18.1.) Расположение этого файла ключей указывается параметром krb_server_keyfile. По умолчанию это /usr/local/pgsql/etc/krb5.keytab (каталог может быть другим, в зависимости от значения sysconfdir при сборке). Из соображений безопасности рекомендуется использовать отдельный файл keytab для сервера PostgreSQL , а не открывать доступ к общесистемному файлу. Файл таблицы ключей генерируется программным обеспечением Kerberos; подробнее это описано в документации Kerberos. Следующий пример для MIT-совместимых реализаций Kerberos 5: При подключении к базе данных убедитесь, что у вас есть разрешение на сопоставление принципала с именем пользователя базы данных. Например, для имени пользователя базы данных fred , принципал fred@EXAMPLE.COM сможет подключиться. Чтобы дать разрешение на подключение принципалу fred/users.example.com@EXAMPLE.COM , используйте файл сопоставления имён пользователей, как описано в Разделе 20.2. Для метода GSSAPI доступны следующие параметры конфигурации:

Когда этот параметр равен 0, из принципала аутентифицированного пользователя убирается область, и оставшееся имя проходит сопоставление имён (см. Раздел 20.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся krb_realm . Более предпочтительный вариант — оставить значение include_realm по умолчанию (1) и задать в pg_ident.conf явное сопоставление для преобразования имён принципалов в имена пользователей PostgreSQL . map Разрешает сопоставление имён пользователей системы и пользователей баз данных. За подробностями обратитесь к Разделу 20.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 Устанавливает область, с которой будут сверяться имена принципалов пользователей. Если этот параметр задан, подключаться смогут только пользователи из этой области. Если не задан, подключаться смогут пользователи из любой области, в зависимости от установленного сопоставления имён пользователей.

20.3.4. Аутентификация SSPI

SSPI — технология Windows для защищённой аутентификации с единственным входом. PostgreSQL использует SSPI в режиме negotiate , который применяет Kerberos , когда это возможно, и автоматически возвращается к NTLM в других случаях. Аутентификация SSPI возможна только когда и сервер, и клиент работают на платформе Windows или на других платформах, где доступен GSSAPI . Если используется аутентификация Kerberos , SSPI работает так же, как GSSAPI ; подробнее об этом рассказывается в Подразделе 20.3.3. Для SSPI доступны следующие параметры конфигурации: Когда этот параметр равен 0, из принципала аутентифицированного пользователя убирается область, и оставшееся имя проходит сопоставление имён (см. Раздел 20.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся krb_realm . Более предпочтительный вариант — оставить значение include_realm по умолчанию (1) и задать в pg_ident.conf явное сопоставление для преобразования имён принципалов в имена пользователей PostgreSQL . compat_realm

Если равен 1, для параметра include_realm применяется имя домена, совместимое с SAM (также известное как имя NetBIOS). Это вариант по умолчанию. Если он равен 0, для имени принципала Kerberos применяется действительное имя области. Этот параметр можно отключить, только если ваш сервер работает под именем доменного пользователя (в том числе, виртуального пользователя службы на компьютере, включённом в домен) и все клиенты, проходящие проверку подлинности через SSPI, также используют доменные учётные записи; в противном случае аутентификация не будет выполнена. upn_username Если этот параметр включён вместе с compat_realm , для аутентификации применяется имя Kerberos UPN. Если он отключён (по умолчанию), применяется SAM-совместимое имя пользователя. По умолчанию у новых учётных записей эти два имени совпадают. Заметьте, что libpq использует имя, совместимое с SAM, если имя не задано явно. Если вы применяете libpq или драйвер на его базе, этот параметр следует оставить отключённым, либо явно задавать имя пользователя в строке подключения. map Позволяет сопоставить пользователей системы с пользователями баз данных. За подробностями обратитесь к Разделу 20.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 Устанавливает область, с которой будут сверяться имена принципалов пользователей. Если этот параметр задан, подключаться смогут только пользователи из этой области. Если не задан, подключаться смогут пользователи из любой области, в зависимости от установленного сопоставления имён пользователей.

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

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

Примечание

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

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

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

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

20.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. Следующие параметры конфигурации доступны при аутентификации в обоих режимах:

Имена и IP-адреса LDAP-серверов для связи. Можно указать несколько серверов, разделяя их пробелами. ldapport Номер порта для связи с LDAP-сервером. Если порт не указан, используется установленный по умолчанию порт библиотеки LDAP. ldaptls Равен 1 для установки соединения между PostgreSQL и LDAP-сервером с использованием TLS-шифрования. Имейте в виду, что так шифруется только обмен данными с LDAP-сервером, а клиентское подключение остаётся незашифрованным, если только не применяется SSL. Следующие параметры конфигурации доступны только при аутентификации в режиме простого связывания: Эта строка подставляется перед именем пользователя во время формирования DN для связывания при аутентификации в режиме простого связывания. ldapsuffix Эта строка размещается после имени пользователя во время формирования DN для связывания, при аутентификации в режиме простого связывания. Следующие параметры конфигурации доступны только при аутентификации поиск+связывание:

Корневая папка DN для начала поиска пользователя при аутентификации в режиме поиск+связывание. ldapbinddn DN пользователя для связи с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание. ldapbindpasswd Пароль пользователя для связывания с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание. ldapsearchattribute Атрибут для соотнесения с именем пользователя в ходе аутентификации поиск+связывание. Если атрибут не указан, будет использован атрибут uid . ldapurl Адрес RFC 4516 LDAP. Это альтернативный путь для написания некоторых функций LDAP в более компактной и стандартной форме. Формат записи таков: scope должен быть представлен или base , или one , или sub , обычно последним. Используется один атрибут, некоторые компоненты стандартных LDAP-адресов, такие, как фильтры и расширения, не поддерживаются. Для неанонимного связывания ldapbinddn и ldapbindpasswd должны быть указаны как раздельные параметры.

Для применения зашифрованных LDAP-подключений, в дополнение к параметру ldapurl необходимо использовать параметр ldaptls . URL-схема ldaps (прямое SSL-подключение) не поддерживается. В настоящее время URL-адреса LDAP поддерживаются только с OpenLDAP и не поддерживаются в Windows. Нельзя путать параметры конфигурации для режима простого связывания с параметрами для режима поиск+связывание, это ошибка. Это пример конфигурации LDAP для простого связывания: Когда запрашивается подключение к серверу базы данных в качестве пользователя базы данных someuser , PostgreSQL пытается связаться с LDAP-сервером, используя DN cn=someuser, dc=example, dc=net и пароль, предоставленный клиентом. Если это подключение удалось, то доступ к базе данных будет открыт. Пример конфигурации для режима поиск+связывание: Когда запрашивается подключение к серверу базы данных в качестве пользователя базы данных someuser , PostgreSQL пытается связаться с сервером LDAP анонимно (поскольку ldapbinddn не был указан), выполняет поиск для (uid=someuser) под указанной базой DN. Если запись найдена, проводится попытка связывание с использованием найденной информации и паролем, предоставленным клиентом. Если вторая попытка подключения проходит успешно, предоставляется доступ к базе данных.

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

Подсказка

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

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

Данный метод аутентификации работает сходным с методом password образом, за исключением того, что он использует RADIUS как метод проверки пароля. RADIUS используется только для подтверждения пары имя пользователя/пароль. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации будет использован RADIUS. В ходе аутентификации RADIUS настроенному RADIUS-серверу посылается запрос доступа. Это сообщение типа Authenticate Only (Только аутентификация), которое включает в себя параметры user name (имя пользователя), password (зашифрованный пароль) и NAS Identifier (идентификатор NAS). Запрос зашифровывается с использованием общего с сервером секрета. RADIUS-сервер отвечает на этот запрос либо Access Accept (Доступ принят), либо Access Reject (Доступ отклонён). Система ведения учёта RADIUS не поддерживается. Для метода RADIUS доступны следующие параметры конфигурации: Имя или IP-адрес целевого сервера RADIUS. Это обязательный параметр. radiussecret

Общий секрет, используемый при контактах с сервером RADIUS. Он должен иметь одинаковое значение на серверах PostgreSQL и RADIUS. Рекомендуется использовать строку как минимум из 16 символов. Это обязательный параметр.

Примечание

Шифровальный вектор будет достаточно эффективен только в том случае, если PostgreSQL собран с поддержкой OpenSSL . В противном случае передача данных серверу RADIUS будет лишь замаскированной, но не защищённой, поэтому необходимо принять дополнительные меры безопасности. Номер порта для связи с сервером RADIUS. Если порт не указан, по умолчанию используется порт 1812 . radiusidentifier Строка, используемая в запросах RADIUS как NAS Identifier (Идентификатор NAS). Этот параметр может использоваться как второй параметр, выявляющий, например, какой пользователь пытается подключиться под каким пользователем базы данных, что может быть использовано для формирования соответствий на сервере RADIUS. Если не указан идентификатор, по умолчанию используется postgresql .

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

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

В записи pg_hba.conf , описывающей аутентификацию по сертификату, параметр clientcert предполагается равным 1 , и его нельзя отключить, так как для этого метода клиентский сертификат является обязательным. Метод cert отличается от простой проверки пригодности сертификата clientcert только тем, что также проверяет, соответствует ли атрибут cn имени пользователя базы данных.

20.3.10. Аутентификация PAM

Данный метод аутентификации работает подобно методу password , но использует в качестве механизма проверки подлинности PAM (Pluggable Authentication Modules, Подключаемые модули аутентификации). По умолчанию имя службы PAM — postgresql . PAM используется только для проверки пар «имя пользователя/пароль» и может дополнительно проверять имя или IP-адрес удалённого компьютера. Поэтому пользователь должен уже существовать в базе данных, чтобы PAM можно было использовать для аутентификации. За дополнительной информацией о PAM обратитесь к Странице описания Linux-PAM . Для аутентификации PAM доступны следующие параметры конфигурации: Имя службы PAM pam_use_hostname Указывает, предоставляется ли модулям PAM через поле PAM_RHOST IP-адрес либо имя удалённого компьютера. По умолчанию выдаётся IP-адрес. Установите в этом параметре 1, чтобы использовать имя узла. Разрешение имени узла может приводить к задержкам при подключении. (Обычно конфигурации PAM не задействуют эту информацию, так что этот параметр следует учитывать, только если создана специальная конфигурация, в которой он используется.)

Примечание

Если PAM настроен для чтения /etc/shadow , произойдёт сбой аутентификации, потому что сервер PostgreSQL запущен не пользователем root. Однако это не имеет значения, когда PAM настроен для использования LDAP или других методов аутентификации.

20.3.11. Аутентификация BSD

Данный метод аутентификации работает подобно методу password , но использует для проверки пароля механизм аутентификации BSD. Аутентификация BSD используется только для проверки пар «имя пользователя/пароль». Поэтому роль пользователя должна уже существовать в базе данных, чтобы эта аутентификация была успешной. Механизм аутентификации BSD в настоящее время может применяться только в OpenBSD.

Для аутентификации BSD в PostgreSQL применяется тип входа auth-postgresql и класс postgresql , если он определён в login.conf . По умолчанию этот класс входа не существует и PostgreSQL использует класс входа по умолчанию.

Примечание

Для использования аутентификации BSD необходимо сначала добавить учётную запись пользователя PostgreSQL (то есть, пользователя ОС, запускающего сервер) в группу auth . Группа auth существует в системах OpenBSD по умолчанию. Источник