Настройка dbt Cloud: защита аккаунта с помощью SSO и RBAC

Вы — администратор dbt Cloud и только что перешли на тариф Enterprise — поздравляем! dbt Cloud предлагает множество возможностей, таких как CI/CD, оркестрация, dbt Explorer, dbt Semantic Layer, dbt Mesh, визуальный редактор, dbt Copilot и многое другое. Но с чего начать?

Мы настоятельно рекомендуем, начиная внедрение функциональности dbt Cloud, в первую очередь настроить Single Sign-On (SSO) и Role-Based Access Control (RBAC). Этот базовый шаг позволяет вашей организации защитить пайплайны данных, упростить онбординг пользователей в dbt Cloud и оптимизировать затраты в долгосрочной перспективе.

Аутентификация vs. авторизация

Прежде чем углубляться в SSO, RBAC и другие темы, давайте разберёмся, как они соотносятся с двумя фундаментальными концепциями безопасности.

• Аутентификация: SSO настраивается для контроля аутентификации — он проверяет (через IdP), что пользователи действительно являются теми, за кого себя выдают, и могут войти в указанный аккаунт dbt Cloud.
• Авторизация: RBAC — это модель авторизации, которая определяет, что пользователи могут видеть и делать в dbt Cloud на основе назначенных им лицензий, групп и наборов прав.

Единый вход (SSO)

Шаги по настройке SSO зависят от вашего IdP, поэтому рекомендуем начать со страницы Обзор SSO и найти в этом разделе документацию для IdP, который используется в вашей конфигурации.

Независимо от того, какой IdP вы используете, одной из первых задач администратора dbt Cloud является задание значения login slug. Это должен быть уникальный идентификатор компании.

Имейте в виду, что выбранный slug будет добавлен в конец SSO URL, который пользователи будут использовать для входа в dbt Cloud. Например:

• Если задать login slug mynewco
• SSO URL будет выглядеть примерно так: https://cloud.getdbt.com/enterprise-login/mynewco.

На первый взгляд, на этом экране много информации и полей — но с документацией по SSO под рукой администраторы dbt Cloud готовы приступить к настройке удобных и масштабируемых рабочих процессов.

Страница настройки SSO в dbt Cloud

Разберём процесс на высоком уровне, чтобы его было проще воспринимать:

1. После настройки нужного идентификатора входа (login slug) администратор dbt Cloud перейдёт на страницу настройки SSO в dbt Cloud, скопирует всё содержимое раздела Identity provider values и передаст эти значения администратору IdP.
2. Администратор IdP создаст приложение dbt Cloud, а затем передаст значения из раздела dbt configuration администратору dbt Cloud.
   подсказка

   См. соответствующую документацию по настройке для Google Workspace, Okta, Microsoft Entra ID или SAML 2.0.

3. Администратор dbt Cloud заполняет полученные значения в секции dbt configuration на странице настройки SSO и нажимает Save, чтобы завершить процесс.

После завершения настройки:

• Мы настоятельно рекомендуем проверить, что SSO работает корректно, вставив SSO URL (он должен выглядеть примерно как https://cloud.getdbt.com/enterprise-login/dbtlabs) в приватное окно браузера.
• Затем попробуйте войти в аккаунт через IdP.
• Если SSO не работает должным образом, администратор аккаунта по‑прежнему сможет войти с помощью пароля и исправить конфигурацию.

подсказка

Обратите внимание на нашу политику обязательного использования SSO — после настройки SSO все пользователи без прав администратора должны будут входить через SSO в соответствии с рекомендациями по безопасности, тогда как администраторы аккаунта по умолчанию по-прежнему могут проходить аутентификацию с помощью пароля вместо многофакторной аутентификации (MFA).

После успешной настройки SSO у вас появляется несколько способов онбординга пользователей в dbt Cloud помимо отправки email‑приглашений:

• Предоставить пользователям SSO URL для доступа в dbt Cloud. Это называется SP-initiated flow (SP — Service Provider, в данном случае dbt Cloud).
• Настроить доступ к dbt Cloud через дашборд IdP. Это называется IdP-initiated flow.

Сценарии входа через SSO в dbt Cloud

Возникли сложности с настройкой SSO? Откройте тикет в поддержку, и один из наших Customer Solutions Engineers с радостью поможет вам!

Лицензии и группы

В dbt Cloud есть два основных рычага управления доступом пользователей:

• Licenses
• Groups

В качестве предварительного шага их необходимо настроить до конфигурации RBAC. Разберёмся подробнее.

Licenses

В dbt Cloud есть три типа лицензий:

• Developer: пользователю могут быть назначены любые права.
• Read-Only: пользователю назначаются права только на чтение для всех ресурсов dbt Cloud, независимо от ролевых разрешений.
• IT: пользователю назначаются права Security Admin и Billing Admin независимо от разрешений групп.

Скорее всего, большинство ваших пользователей — это разработчики или аналитики, которым потребуются лицензии Developer. Вы можете назначать лицензии по умолчанию на основе групп пользователей в IdP в разделе Account Settings → Groups & Licenses → License mappings.

Пример сопоставления лицензий

Если пользователь состоит в нескольких группах с разными типами лицензий, ему будет назначена лицензия с наивысшим уровнем — Developer.

Groups

Группы используются для управления разрешениями. Они определяют, что пользователь может видеть и какие действия может выполнять в проектах и средах. Рекомендуем ознакомиться с доступными наборами разрешений и определить, какие из них подходят вашим пользователям dbt Cloud.

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

Перейдя на страницу Groups & Licenses в dbt Cloud, вы увидите три группы по умолчанию — Everyone, Member и Owner. Также в правом верхнем углу доступна опция создания собственных групп.

Встроенные группы dbt Cloud

Кратко о группах по умолчанию:

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

Хотя мы рекомендуем создавать собственные группы и удалять группы по умолчанию, чтобы лучше адаптировать модель доступа под бизнес‑требования, удалять дефолтные группы следует только после создания собственных и привязки к ним наборов прав. Эти группы предназначены для быстрого старта работы с dbt Cloud. Вкратце: группа Owner даёт полный доступ администратора аккаунта, а группы Everyone и Member — полный доступ разработчика.

Для начала вот основные наборы прав, которые стоит назначить большинству пользователей:

Роль пользователя	Набор прав
dbt Cloud Admin	Account Admin
dbt Developer	Developer
dbt Analyst	Analyst

Также группы можно использовать для управления доступом к конкретным проектам и окружениям.

Создание группы dbt Cloud

Role-Based Access Control через IdP

Если вы дочитали до этого места — спасибо! Теперь мы готовы настроить RBAC, который назначает пользователей в нужные группы и, соответственно, нужные наборы прав после их аутентификации в dbt Cloud. Это основано на SSO group mapping, который настраивается внутри группы.

Например, предположим, что вы хотите, чтобы пользователи с SSO group mapping dbt-developer попадали в определённую группу. Обратите внимание, что можно указать несколько значений.

Настройка сопоставления с группой SSO

Для этого нужно:

1. Попросить администратора IdP создать группу dbt-developer в IdP.
2. Назначить пользователей, которые должны попасть в соответствующую группу dbt Cloud, в эту группу IdP.
3. Попросить пользователей войти в dbt Cloud и убедиться, что они автоматически назначены в нужную группу.

Довольно просто, верно? Главное — убедитесь, что соблюдены два условия для корректной работы RBAC между IdP и dbt Cloud:

• Названия групп должны полностью совпадать
• Регистр символов должен быть одинаковым

Пример сопоставления группы SSO с группой у поставщика удостоверений

Автоматизация SSO и RBAC: знакомство с SCIM

У нас отличные новости — поддержка System for Cross-Domain Identity Management (SCIM) станет общедоступной в мае 2025 года (для SCIM-совместимых поставщиков удостоверений (IdP) и Okta)! Если вы не знакомы с SCIM, его можно рассматривать как средство автоматического управления учетными записями пользователей в dbt Cloud. Оно повышает безопасность пользовательских данных и упрощает работу администраторов и пользователей за счет автоматизации жизненного цикла учетных записей пользователей и групп.

Вот почему администратору dbt Cloud стоит обратить внимание на SCIM:

1. Улучшенный опыт администраторов и конечных пользователей — благодаря автоматизации онбординга и оффбординга пользователей SCIM экономит время администраторов dbt Cloud, которые регулярно управляют большим количеством пользователей. При добавлении или удалении пользователя в IdP его лицензия и учётная запись автоматически добавляются или удаляются в dbt Cloud.
2. Упрощённый RBAC за счёт управления группами — администраторы могут упростить управление доступом, используя SCIM для обновления состава групп. В настоящее время SSO group mapping позволяет добавлять новых пользователей в группы при JIT‑провижининге. SCIM расширяет эту функциональность, позволяя управлять группами не только для новых, но и для существующих пользователей.

Заключение

Защита аккаунта с помощью SSO и RBAC должна быть одним из первых приоритетов после перехода на Enterprise plan.

Это не только повышает безопасность данных, но и позволяет масштабируемо онбордить пользователей в аккаунт. Хотя это может быть лишь началом вашего пути в dbt Cloud, выполнение этого важного шага закладывает основу для ответственного и зрелого использования dbt на уровне enterprise.