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

Как администратор dbt Cloud, вы только что перешли на dbt Cloud с тарифом Enterprise plan — поздравляем! dbt Cloud предлагает множество возможностей, таких как CI/CD, Orchestration, dbt Explorer, dbt Semantic Layer, dbt Mesh, Visual Editor, 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 на основе назначенных им лицензий, групп и наборов прав.

Single Sign-On (SSO)

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

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

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

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

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

dbt Cloud's SSO configuration page

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

1. После задания нужного login slug администратор dbt Cloud переходит на страницу настройки SSO и копирует все значения из секции Identity provider values, после чего передаёт их администратору IdP.
2. Администратор IdP создаёт dbt Cloud app и затем передаёт значения из секции 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 enforcement policy — после настройки SSO все пользователи, кроме администраторов аккаунта, должны будут входить только через SSO в целях безопасности, в то время как администраторы аккаунта по умолчанию могут продолжать аутентифицироваться с помощью пароля вместо multi-factor authentication (MFA).

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

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

SSO flows into 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.

An example license mapping

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

Groups

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

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

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

The out-of-the-box dbt Cloud groups you may use

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

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

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

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

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

Loading table...

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

Creating a new dbt Cloud group

Role-Based Access Control через IdP

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

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

Configuring a SSO group mapping within a group

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

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

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

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

Making a SSO group mapping work with your idenity provider

Автоматизация 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.