Управление командой и ролями

Renta использует модель Role-Based Access Control (RBAC) для управления доступом и безопасностью. Эта система позволяет организовать совместную работу над данными в изолированных средах, называемых Workspaces (рабочие пространства).

Workspaces (Рабочие пространства)

Workspace — это фундаментальная единица изоляции в Renta. Он функционирует как защищенный контейнер для вашей инфраструктуры данных.

Модель изоляции

Каждый workspace работает как полностью независимая среда. Ресурсы, созданные в одном пространстве, невидимы и недоступны из другого.

1. Изоляция данных. Источники (Sources), Назначения (Destinations) и Пайплайны (Pipelines) существуют только внутри своего родительского workspace.

2. Изоляция биллинга. У каждого workspace свой тарифный план и настройки оплаты.

3. Изоляция пользователей. Доступ предоставляется отдельно для каждого workspace. Роль Owner в "Workspace A" не дает никакого доступа к "Workspace B".

Резидентность данных (Data Residency)

При создании workspace вы должны выбрать Data Processing Location (Регион обработки данных). Эта настройка определяет физическое расположение облачной инфраструктуры, обрабатывающей ваши данные.

1. Europe (EU). Соответствует требованиям GDPR. Данные не покидают пределы ЕС.

2. United States (US). Оптимизирован для источников и назначений, расположенных в США.

Роли и права доступа

Renta предоставляет две предустановленные системные роли. Доступ бинарен: пользователи являются либо администраторами (Owner), либо стандартными операторами (Member).

Матрица прав доступа

В таблице ниже подробно описаны возможности каждой роли.

Описание ролей

В следующей таблице приведено описание возможностей каждой роли и типичные сценарии использования.

Owner (Владелец)

Роль Owner фактически является "Администратором Workspace". Владельцы имеют неограниченный доступ ко всем аспектам рабочего пространства.

1. Основная ответственность. Управление инфраструктурой, биллинг и безопасность команды.

2. Best practice. Назначайте эту роль Team Lead, DevOps-инженерам и руководителям проектов. Всегда имейте минимум двух Owners для резервирования доступа.

Member (Участник)

Роль Member предназначена для повседневной операционной работы. Участники могут создавать и обслуживать пайплайны, но не могут менять конфигурацию самого workspace или настройки безопасности.

1. Основная ответственность. Построение и мониторинг пайплайнов данных.

2. Best practice. Назначайте эту роль Data-инженерам, аналитикам и разработчикам.

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

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

Приглашение нового участника

Предоставьте доступ коллеге к рабочему пространству.

Перейдите в Team membersStep 1

Перейдите в раздел Settings > Team members. Нажмите кнопку Add member.

Настройте доступStep 2

В открывшейся боковой панели Add member введите email пользователя и выберите подходящую роль (Owner или Member).

Отправьте приглашениеStep 3

Нажмите Invite member. Пользователь получит email с защищенной ссылкой для входа. Статус приглашения останется Pending (Ожидание) до момента принятия.

Изменение ролей

Вы можете повысить Member до Owner или понизить Owner до Member в любой момент.

1. Перейдите в Settings > Team members.
2. Нажмите на пользователя в списке, чтобы открыть боковую панель Edit member.
3. В блоке Role selection выберите новую роль.
4. Нажмите Save, чтобы изменения вступили в силу.

Отзыв доступа

Чтобы удалить пользователя из workspace:

1. Перейдите в Settings > Team members.
2. Нажмите на пользователя в списке, чтобы открыть боковую панель Edit member.
3. Прокрутите вниз до секции Remove member.
4. Нажмите кнопку Remove member.

Выход из workspace: Участники (Members) могут самостоятельно покинуть рабочее пространство в любой момент, но не имеют прав на удаление других пользователей. Чтобы выйти, выполните те же действия для своего профиля.

Best practices

Следуйте этим рекомендациям для поддержания безопасной и эффективной среды в рабочем пространстве.

Безопасность и управление

1. Принцип минимальных привилегий (Least Privilege). По умолчанию назначайте роль Member для всех новых пользователей. Выдавайте права Owner только тем, кому действительно необходимо управлять оплатой или доступом других.

2. Регулярный аудит. Проверяйте список Team members ежеквартально. Отзывайте доступ у сотрудников, сменивших команду или покинувших компанию.

3. Сервисные аккаунты. Для API интеграций избегайте использования личных аккаунтов. Создайте выделенный email-алиас (например, etl-bot@company.com) и пригласите его как Member для генерации API ключей.

Стратегия окружений

Используйте несколько workspaces для реализации безопасного цикла разработки (SDLC).

1. Development workspace. Для тестирования новых источников и конфигураций. Здесь можно дать разработчикам упрощенный доступ уровня Owner.

2. Production workspace. Для реальных бизнес-данных. Ограничьте роль Owner строго для Senior DevOps или Team Lead. "Заморозьте" права доступа для обеспечения стабильности.