Безопасность движка (опционально)

Прежде чем проверять пароль, сервер решает, рассматривать ли это подключение вообще. Решает по файлу pg_hba.conf (host-based authentication). Каждая строка отвечает: «для такого типа соединения, такой базы, такой роли и такого адреса - проверять вот этим методом».

# TYPE  DATABASE  USER  ADDRESS         METHOD

local   all       all                   peer

host    all       all   10.0.0.0/8      scram-sha-256

host    all       all   0.0.0.0/0       trust          # ОПАСНО

Строки читаются сверху вниз, побеждает первая подходящая. Метод определяет, как проверять личность:

• scram-sha-256 - проверка пароля по современному протоколу, боевой вариант;
• peer - доверие на основе имени системного пользователя, для локального сокета;
• trust - пускать без проверки вообще.

trust означает «пускать кого угодно без пароля». Для локального одноразового сэндбокса это терпимо. Строка с trust на сетевом диапазоне (0.0.0.0/0 или подсеть) - открытая дверь: достаточно знать имя роли, и ты внутри, без всякого пароля.

Это одна из самых частых реальных дыр: trust, поставленный «на время отладки» и забытый. Боевое правило простое - на любом сетевом адресе метод scram-sha-256, trust только на локальном сокете и только если очень надо.

Проверить действующие правила можно прямо из SQL, не лазая в файл:

SELECT type, database, user_name, address, auth_method

FROM pg_hba_file_rules

WHERE auth_method = 'trust';

В PostgreSQL нет отдельно «пользователей» и «групп» - есть роль. Роль может логиниться (LOGIN), владеть объектами, входить в другие роли. Привилегии выдаются через GRANT и наследуются по членству.

Базовая гигиена - приложение не ходит суперпользователем. Причина не только в «вдруг что-то сломает»: под суперпользователем не проверяются права на таблицы и не работает row-level security. Один такой коннект, утёкший наружу, открывает вообще всё, никакие GRANT и политики его не остановят.

Поэтому приложению заводят отдельную роль с правами ровно на нужные таблицы и операции - принцип наименьших привилегий. Суперпользователь остаётся для миграций и администрирования, а не для повседневных запросов приложения.

Обычная функция (SECURITY INVOKER, по умолчанию) исполняется с правами того, кто её вызвал. Функция SECURITY DEFINER - с правами её владельца. Это законный и нужный механизм: дать пользователю выполнить контролируемое действие над данными, к которым у него нет прямого доступа.

Пример: пользователь не имеет права писать в таблицу аудита напрямую, но может вызвать SECURITY-DEFINER-функцию, принадлежащую администратору, которая добавит туда строго одну строку нужного формата. Доступ к таблице остаётся только у функции, не у пользователя.

Проблема в том, что вместе с правами владельца функция уносит и контекст вызвавшего - в частности, его search_path.

Вот коварная связка. search_path - порядок, в котором сервер ищет схемы для неквалифицированных имён (accounts без явной public.). Его задаёт вызывающий, и он наследуется внутрь SECURITY-DEFINER-функции.

Пусть функция принадлежит суперпользователю и содержит неквалифицированный вызов:

-- уязвимо: accounts без явной схемы

CREATE FUNCTION charge(amount numeric) RETURNS void

LANGUAGE sql SECURITY DEFINER

AS $$ UPDATE accounts SET balance = balance - amount $$;

Злоумышленник создаёт в своей схеме свою таблицу accounts, ставит свою схему первой в search_path и вызывает charge. Функция, исполняясь с правами суперпользователя, обратится к подделке - или, хуже, к функции-подделке с побочным эффектом. Это полноценная эскалация привилегий.

Защита - закрепить search_path на самой функции и квалифицировать имена схемой:

CREATE FUNCTION charge(amount numeric) RETURNS void

LANGUAGE sql SECURITY DEFINER

SET search_path = pg_catalog, public   -- фиксируем, не наследуем

AS $$ UPDATE public.accounts SET balance = balance - amount $$;

$$;

Правило без исключений: у каждой SECURITY DEFINER-функции явный SET search_path, и имена объектов квалифицированы схемой.

Свести три рубежа в проверяемый список:

• в pg_hba.conf нет trust на сетевых адресах, метод - scram-sha-256;
• приложение работает не под суперпользователем, права выданы по наименьшим привилегиям через GRANT;
• у каждой SECURITY DEFINER-функции закреплён search_path и имена квалифицированы схемой;
• row-level security включена там, где разграничение по строкам - часть модели доступа (и помни, что суперпользователь её обходит).

Этот список не заменяет полноценный аудит, но закрывает самые частые реальные дыры. Подробная справка - engine-security. А почему DROP без бэкапа - отдельная катастрофа, мы видели в главе про PITR.