Облачный PostgreSQL: права доступа и технические границы управляемого сервиса

Суть модели DBaaS заключается в том, что пользователь получает готовую к работе базу данных, освобождаясь от рутинных задач администрирования. Вследствие этого, облачное решение PostgreSQL имеет ряд жестких ограничений, направленных на обеспечение стабильности и безопасности всей платформы. Пользователь не может выполнять действия, которые традиционно требуют прав суперпользователя или глубокого вмешательства в конфигурацию системы. К таким ограничениям относятся:

Невозможность изменения конфигурационных параметров самой базы данных. Настройки, такие как shared_buffers, work_mem или max_connections, управляются провайдером и недоступны для изменения через SQL-запросы.

Ограниченное управление пользователями и ролями. Хотя создание новых пользователей возможно, полный контроль над системой ролей, как это реализовано в классическом PostgreSQL, отсутствует.

Запрет на самостоятельное создание баз данных. Новые базы данных создаются исключительно через панель управления хостинг-провайдера, а не с помощью SQL-команды CREATE DATABASE.

Отсутствие возможности управления расширениями. Установка или удаление расширений PostgreSQL, таких как postgis или pg_cron, недоступна пользователю напрямую и требует обращения в службу поддержки.

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

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

Роли и привилегии: управление доступом в рамках ограничений

В PostgreSQL права доступа строятся на иерархии ролей и привилегий. Привилегия — это атомарное право на выполнение конкретного действия (например, SELECT или INSERT), а роль — это контейнер, объединяющий набор таких привилегий. В облачном PostgreSQL эта система сохраняется, но с важными оговорками.

Пользователь, создаваемый при инициализации облачной базы данных (обычно cloud_user), автоматически становится владельцем первой базы данных (например, default_db). Владелец обладает максимальным набором привилегий на свою базу данных, право выдавать и отзывать привилегии другим пользователям с помощью команд GRANT и REVOKE.

Но создание произвольных пользовательских ролей запрещено. Вместо этого провайдер предлагает использовать предопределенные специальные роли, которые можно назначать пользователям через панель управления:

cdb_monitor: Эта роль предназначена для мониторинга и предоставляет доступ к системным представлениям и функциям, содержащим информацию о производительности и состоянии сервера. По сути, она включает в себя привилегии стандартных ролей PostgreSQL pg_monitor и pg_read_all_stats

cdb_read_all_data: Роль для создания пользователей с правами «только для чтения». Она дает возможность выполнять SELECT-запросы ко всем таблицам, представлениям и последовательностям в базе данных, что эквивалентно стандартной роли pg_read_all_data

Назначение этих ролей через панель управления не предоставляет пользователю автоматического права на подключение (CONNECT) к базе данных. Это отдельная привилегия, которую необходимо выдавать явно. Если новый пользователь создается без наследования от владельца базы данных, он не сможет подключиться к ней, пока владелец не выполнит команду GRANT CONNECT ON DATABASE database_name TO username

Примеры управления правами

Рассмотрим типичные сценарии настройки доступа.

Сценарий 1: Создание пользователя для записи в конкретную таблицу. Для этого необходимо:

Создать нового пользователя (например, user1) в панели управления без специальных ролей.
Подключиться к базе данных от имени владельца (cloud_user).
Выдать привилегию на подключение: GRANT CONNECT ON DATABASE default_db TO user1;.
Выдать привилегию на вставку данных: GRANT INSERT ON example TO user1;.

Сценарий 2: Создание пользователя с правами «только для чтения» ко всей базе данных. В этом случае процесс немного отличается:

При создании пользователя user1 в панели управления ему сразу назначается специальная роль cdb_read_all_data.
После этого владелец базы данных должен подключиться и выдать только привилегию на подключение: GRANT CONNECT ON DATABASE default_db TO user1;.

В обоих случаях отзыв прав осуществляется с помощью команды REVOKE, например, REVOKE CONNECT ON DATABASE default_db FROM user1;.

Управление расширениями и внешний доступ

Как уже упоминалось, установка расширений PostgreSQL в облачной среде невозможна через стандартные SQL-команды. Если проекту требуется использование какого-либо расширения, единственный путь обратиться в техническую поддержку провайдера с соответствующим запросом.

Настройка внешнего доступа к базе данных выполняется исключительно через веб-интерфейс панели управления. По умолчанию доступ разрешен только из внутренней сети хостинг-провайдера. Для подключения извне необходимо явно указать список доверенных IP-адресов или подсетей в специальном поле настроек. Например, для предоставления доступа с любого IP-адреса используется универсальная подсеть 0.0.0.0/0. Система не допускает добавления пересекающихся подсетей, чтобы избежать конфликтов в правилах безопасности.