Безопасность
Эта страница переведена при помощи нейросети GigaChat.
Роль, используемая для подключения репликации, должна иметь атрибут REPLICATION (или быть суперпользователем). Если роль не имеет SUPERUSER и BYPASSRLS, политики безопасности строки издателя могут выполняться. Если роль не доверяет всем владельцам таблиц, включите options=-crow_security=off в строку подключения. Если владелец таблицы затем добавляет политику безопасности строки, эта настройка приведет к остановке репликации вместо выполнения политики. Доступ для роли должен быть настроен в pg_hba.conf и эта роль должна иметь атрибут LOGIN.
Чтобы иметь возможность копировать начальные данные таблицы, роль, используемая для подключения репликации, должна иметь привилегию SELECT на опубликованной таблице (или быть суперпользователем).
Для создания публикации пользователь должен иметь привилегию CREATE в базе данных.
Чтобы добавить таблицы в публикацию, пользователь должен обладать правами собственности на таблицу. Чтобы добавить все таблицы схемы в публикацию, пользователь должен быть суперпользователем. Для создания публикации, которая автоматически публикует все таблицы или все таблицы в схеме, пользователь также должен быть суперпользователем.
В настоящее время отсутствуют права доступа к публикациям. Любая подписка (которая может подключиться) имеет доступ ко всем публикациям. Таким образом, если хотите скрыть некоторую информацию от определенных подписчиков, например, используя фильтры строк или списки столбцов, или не включая всю таблицу в публикацию, имейте в виду, что другие публикации в той же базе данных могут раскрывать ту же самую информацию. Возможно, в будущем в PostgreSQL будут введены права доступа к публикациям, чтобы обеспечить более точное управление доступом.
Чтобы создать подписку, пользователь должен иметь привилегии роли pg_create_subscription, а также привилегии CREATE в базе данных.
Процесс применения подписки будет работать на уровне сеанса с привилегиями владельца подписки. Однако при выполнении операций вставки, обновления, удаления или усечения конкретной таблицы он переключится на роль владельца таблицы и выполнит операцию с привилегиями владельца таблицы. Это означает, что владельцу подписки нужно уметь SET ROLE каждой роли, владеющей реплицируемой таблицей.
Если подписка была сконфигурирована с параметром run_as_owner = true, то смена пользователей происходить не будет. Вместо этого все операции будут выполняться с разрешениями владельца подписки. В этом случае владельцу подписки нужны только привилегии на выполнение действий SELECT, INSERT, UPDATE и DELETE над целевой таблицей, ему не требуются привилегии на SET ROLE к владельцу таблицы. Однако это также означает, что любой пользователь, который владеет таблицей, в которую происходит репликация, может выполнять произвольный код с привилегиями владельца подписки. Например, они могли бы сделать это просто путем прикрепления триггера к одной из принадлежащих им таблиц. Поскольку обычно нежелательно разрешать одной роли свободно принимать привилегии другой, этот вариант следует избегать, если безопасность пользователя внутри базы данных вызывает беспокойство.
На издателях привилегии проверяются только один раз в начале соединения репликации и не перепроверяются при чтении каждой записи изменений.
На подписчике привилегии владельца подписки повторно проверяются для каждой транзакции при ее применении. Если рабочий процесс находится в процессе применения транзакции, когда владение подпиской изменяется одновременно с транзакцией, применение текущей транзакции будет продолжено с использованием привилегий старого владельца.