Минимальные права, search_path, RLS, пароли и защищённые соединения
Безопасная база следует принципу минимальных прав: каждое приложение и человек получает только те действия, которые нужны для работы. Если пароль утечёт или в коде найдётся ошибка, лишние права не увеличат ущерб.
В PostgreSQL и пользователи, и группы прав называются ролями. Роль с атрибутом
LOGIN может подключаться. Роль NOLOGIN хранит набор прав и выдаётся другим
ролям как группа.
CREATE ROLE app_read NOLOGIN;
CREATE ROLE app_write NOLOGIN;
CREATE ROLE app_runtime LOGIN;
GRANT app_read, app_write TO app_runtime;
GRANT USAGE ON SCHEMA marketplace TO app_read;
GRANT SELECT ON ALL TABLES IN SCHEMA marketplace TO app_read;USAGE разрешает обращаться к объектам схемы, а SELECT — читать таблицы.
Роль приложения не должна владеть таблицами или получать SUPERUSER,
CREATEROLE и BYPASSRLS. Миграции выполняет отдельная роль, которой не
пользуется обычный запрос приложения.
GRANT ... ON ALL TABLES действует на существующие таблицы. Для будущих нужны
права по умолчанию:
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA marketplace
GRANT SELECT ON TABLES TO app_read;Важна роль после FOR ROLE: именно она должна создавать будущие объекты.
Настройка прав по умолчанию для другого владельца не сработает.
search_path задаёт порядок схем для неполного имени. Если ранняя схема
доступна злоумышленнику для создания объектов, он может подложить функцию,
оператор или таблицу с ожидаемым именем.
Поэтому:
CREATE на общей схеме public;marketplace.orders;search_path;RLS (Row-Level Security) — защита на уровне строк. Она позволяет одной роли
читать одну таблицу, но видеть только строки своей организации.
ALTER TABLE marketplace.orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY orders_tenant_policy ON marketplace.orders
USING (org_id = current_setting('app.org_id')::bigint)
WITH CHECK (org_id = current_setting('app.org_id')::bigint);USING ограничивает строки, которые можно увидеть, изменить или удалить.
WITH CHECK проверяет новые значения после INSERT и UPDATE.
Приложение должно в начале транзакции установить app.org_id, а в пуле
соединений — гарантировать сброс состояния. Иначе следующее обращение может
унаследовать организацию предыдущего клиента.
Владелец таблицы обычно обходит RLS, если не включён
FORCE ROW LEVEL SECURITY. Роли SUPERUSER и BYPASSRLS тоже обходят
политику. Поэтому приложение не должно подключаться владельцем.
RLS — дополнительная граница. Она не заменяет составной внешний ключ, разделяющий организации, и проверку прав в приложении.
Файл pg_hba.conf определяет, кто, откуда, к какой базе и каким способом может
подключаться. PostgreSQL применяет первое подходящее правило, поэтому порядок
строк важен.
Для удалённых соединений обычно используют:
hostssl, чтобы разрешать только соединение с TLS;scram-sha-256 для проверки пароля;TLS шифрует канал и позволяет проверить сервер. Он не заменяет права роли и
RLS. Представление pg_hba_file_rules помогает проверить разобранные правила и
найти ошибки конфигурации.
В лаборатории 26
вы создадите роли приложения и проверите изоляцию двух организаций, включая
попытку вставить строку с чужим org_id.
Подробнее: роли базы, защита строк.
Вопросы ещё не добавлены
Вопросы для этой подтемы ещё не добавлены.
Далее: Резервные копии, восстановление и обновление