Перейти к основному содержимому
Перейти к основному содержимому

Управление сервисными аккаунтами базы данных

Сервисные аккаунты базы данных могут представлять собой просто пользователя с отдельным паролем или сертификатом для аутентификации. Более опытные пользователи могут захотеть настроить аккаунты, в которых объём прав можно динамически изменять с помощью SET ROLE, чтобы быстро переключаться между профилями без выхода из системы и повторной загрузки содержимого.

Обзор​

SET ROLE можно использовать для динамического ограничения прав сервисного аккаунта в рамках сеанса. Это достигается за счёт того, что эффективные права пользователя ограничиваются только теми, которые предоставляет активированная роль или роли. У этого подхода есть несколько преимуществ:

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

На практике вы:

  1. Проектируете роли, задающие допустимые границы (read_only, maintenance и т. д.)
  2. Назначаете их сервисному аккаунту
  3. При подключении выбираете активную роль или роли через SET ROLE (или параметр роли), тем самым ограничивая возможности этого сеанса

Настройте сервисную роль​

Назначьте роли сервисному аккаунту​

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

CREATE ROLE read_only_role;
GRANT SELECT ON db1.* TO read_only_role;

CREATE ROLE maint_role;
GRANT SELECT, INSERT, ALTER on db1.* TO maint_role;

GRANT read_only_role, maint_role TO service_user;

Используйте SET ROLE, чтобы задать границы сеанса​

В начале сеанса сервисный аккаунт выбирает, какие роли будут активны:

-- Только доступ на чтение в этом сеансе
SET ROLE read_only_role;

или:

-- Использовать все назначенные роли (полный доступ)
SET ROLE ALL;

SET ROLE активирует роли для текущего пользователя; итоговые привилегии представляют собой объединение всех активных ролей и всех привилегий, напрямую назначенных пользователю.

Вы также можете деактивировать все роли:

SET ROLE NONE;

или активировать несколько ролей:

SET ROLE read_only_role, maint_role;

Текущие активные роли можно посмотреть в system.current_roles.

Задайте роли по умолчанию для сервисного аккаунта​

Чтобы сервисный аккаунт всегда начинал работу в ограниченном режиме, настройте роли по умолчанию:

SET DEFAULT ROLE read_only_role TO service_user;

или

SET DEFAULT ROLE ALL EXCEPT maint_role TO service_user;

Использование SET ROLE через HTTP / программно​

Если сервисный аккаунт подключается по HTTP, вы не можете отправить SET ROLE; SELECT ... как запрос из нескольких операторов. Вместо этого передайте роль как параметр запроса:

curl "https://host:8123?user=service_user&password=...&role=read_only_role" \
 --data-binary "SELECT * FROM db1.table1"

?role=... эквивалентно выполнению SET ROLE read_only_role перед запросом. Несколько параметров роли работают так же, как SET ROLE role 1, role 2.

Некоторые драйверы (например, ClickHouse Connect для Python) также поддерживают настройку роли, которая отправляется с каждым запросом и используется сервером как роль сеанса.