Роли и права

Права в ActionPulse описываются одним правилом: у каждого продуктового действия есть минимальная роль, и решение принимает сервер. Роль выдаётся на организацию и действует во всех её проектах; отдельных прав на конкретный проект не существует.

Эта страница — полная матрица «действие → минимальная роль», собранная по коду проверок, а не по логике «кому это, наверное, нужно». В кабинете (Настройки → Команда → Матрица прав) показана короткая сводка из шести строк; здесь развёрнутый вариант с именами прав. Как пригласить человека и поменять ему роль — в команде и ролях.

Четыре роли

Ролей ровно четыре: owner, admin, analyst, viewer. Они строго вложены — каждая следующая может всё, что предыдущая, плюс своё.

Роль	В интерфейсе	Уровень
viewer	Наблюдатель	1
analyst	Аналитик	2
admin	Админ	3
owner	Владелец	4

Вложенность означает, что таблицы ниже читаются по принципу «не ниже, чем»: если действие требует analyst, его выполняют analyst, admin и owner.

Матрица прав

Столбцы — роли, строки — действия. ✓ — разрешено, — — запрещено.

Действие	Наблюдатель	Аналитик	Админ	Владелец
Чтение отчётов и данных проекта	✓	✓	✓	✓
Создание отчётов и сегментов	—	✓	✓	✓
Запуск загрузки данных (импорт)	—	✓	✓	✓
SQL-консоль	—	✓	✓	✓
Просмотр записей сессий	—	✓	✓	✓
Управление ключами приёма	—	—	✓	✓
Приглашение людей	—	—	✓	✓
Изменение ролей участников	—	—	✓	✓
Настройки проекта	—	—	✓	✓
Удаление данных	—	—	✓	✓
Биллинг	—	—	—	✓

Дальше — то же самое, но с именами прав в коде и с представительным запросом, по которому право проверяется. Это уровень детализации для аудита и для разбора ответа 403.

Действие	Право в коде	Минимальная роль	Представительный запрос
Чтение отчётов и данных проекта	project.read	viewer	GET /projects/{id}/
Создание отчётов	reports.manage	analyst	POST /projects/{id}/reports
Создание сегментов	segments.manage	analyst	POST /projects/{id}/segments
Импорт	imports.manage	analyst	POST /projects/{id}/imports
SQL-консоль	sql.execute	analyst	POST /projects/{id}/sql
Просмотр записей сессий	replay.read	analyst	GET /projects/{id}/sessions
Управление ключами приёма	settings.project.manage	admin	POST /projects/{id}/keys
Приглашение людей	settings.team.manage	admin	POST /org/invites
Изменение ролей участников	settings.team.manage	admin	PATCH /org/members/{uid}
Настройки проекта	settings.project.manage	admin	PATCH /projects/{id}/
Настройки сбора и приватности	behavior.settings.manage	admin	PATCH /projects/{id}/behavior/settings
Удаление данных субъекта	settings.privacy.manage	admin	POST /projects/{id}/gdpr/forget
Удаление собранных данных форм	settings.privacy.manage	admin	POST /projects/{id}/behavior/forms/purge
Удаление проекта	settings.project.manage	admin	DELETE /projects/{id}/
Биллинг	settings.billing.manage	owner	POST /billing/checkout

Примечания к строкам, где право в коде не совпадает с названием действия — это важно знать до того, как вы начнёте искать отдельную настройку:

• Управление ключами приёма — отдельного права нет. Выпуск, ротация и отзыв ключей, а также просмотр самого списка ключей проверяются правом settings.project.manage, то есть требуют роли admin. Аналитик списка ключей не видит вообще, даже без секретных значений.
• Изменение ролей — отдельного права нет. Используется то же settings.team.manage, что и для приглашений, плюс отдельные правила про владельца (см. ниже).
• Удаление данных — это не одно действие. Удаление данных человека и удаление собранных данных форм закрыты правом settings.privacy.manage, а удаление проекта целиком — правом настроек проекта. Роль у всех трёх одна и та же — admin.
• Чтение — не всегда отдельное право. Право project.read проверяется на доступ к проекту, а чтение сохранённых отчётов, сегментов и списка заданий загрузки отдельным правом не ограничено: достаточно членства в организации и доступа к проекту. Поэтому «дать доступ только к одному отчёту» нельзя.
• Биллинг: чтение и изменение разделены. Страницу «Тариф и оплата» и потребление видит любой участник организации; оплата, смена тарифа, отмена, платёжные реквизиты и счета — только владелец.
• Удаления организации из кабинета нет ни у одной роли. Отдельные проекты удаляются в настройках проекта; всё остальное — через поддержку.

Остальные действия

Полный перечень прав, которые не попали в основную матрицу, но проверяются тем же механизмом:

Право в коде	Минимальная роль	О чём это
experiments.read	viewer	просмотр определений экспериментов
experiments.readout	viewer	расчёт разбора эксперимента
registry.events.manage	analyst	ведение реестра событий и семантики
labeled-events.manage	analyst	клиентские события без кода
dashboards.manage	analyst	сводные панели
alerts.manage	analyst	правила оповещений
alerts.digest.manage	analyst	еженедельный дайджест
alerts.release-markers.manage	analyst	маркеры релизов
experiments.manage	analyst	создание и изменение экспериментов
settings.sharing.manage	analyst	защищённые ссылки на отчёты
registry.mode.manage	admin	режим проверки реестра (наблюдение или строгий)
alerts.release-tokens.manage	admin	токены CI/CD для маркеров релизов
settings.sso.manage	owner	корпоративный вход организации
settings.license.manage	owner	установка лицензии в on-prem-установке

Что видит роль с минимальными правами

Наблюдатель — это полноценный читатель, а не урезанный доступ к паре экранов. Ему открыты обзор, события, реестр событий, проверка интеграции, воронки, удержание, инсайты, пути, сохранённые отчёты, отчёты «Формы» и «Поведение», диагностика, каналы, сводные панели, оповещения, маркеры релизов, список заданий загрузки, эксперименты и их разбор, а также страницы настроек проекта, сбора и приватности, команды, тарифа и своего профиля — на чтение.

Наблюдателю закрыты ровно пять мест:

Закрыто	Требуемая роль
SQL-консоль	analyst
Записи сессий — список и плеер	analyst
Защищённые ссылки на отчёты	analyst
Настройки → Данные (удаление данных)	admin
Журнал аудита	admin

Разделы не исчезают из навигации по роли: недоступная страница остаётся на месте и объясняет, что прав не хватает. Так видно, что раздел существует и о нём можно попросить администратора. Данные при этом не загружаются — страница отказа не делает запрос за содержимым.

Ещё одно свойство наблюдателя: он ничего не может изменить, но и не может ничего испортить чтением. Все ограничения на изменение сохранённых объектов — уровня analyst и выше.

Что нельзя делегировать

Часть решений принципиально не передаётся вниз по иерархии.

• Тариф и оплата — только владелец. Администратор видит страницу «Тариф и оплата» и потребление, но не может ни оплатить, ни сменить тариф, ни изменить платёжные реквизиты. Это единственное действие в матрице, доступное строго одной роли.
• Корпоративный вход и лицензия — только владелец. Настройка входа через внешнего поставщика учётных записей и установка лицензии в on-prem-установке не делегируются администратору.
• Роль владельца выдаёт и снимает только владелец. Администратор меняет роли в пределах viewer, analyst и admin; попытка выдать или снять owner отвечает 403.
• Приглашением роль владельца не выдаётся вообще. Форма и API приглашений принимают только admin, analyst и viewer. Владельцем можно сделать только уже принятого участника.
• Последнего владельца нельзя понизить или удалить. Запрос отклоняется с ошибкой валидации: организация не может остаться без владельца.
• Роль нельзя ограничить одним проектом. Она действует на всю организацию. Если нужно разделить доступ между командами, разделяйте организации, а не роли.

Двухфакторная защита и подтверждение опасных действий

Двухфакторная защита — личная настройка участника (Настройки → Профиль → Двухфакторная защита). К паролю добавляется одноразовый код по стандарту TOTP: шесть цифр, период 30 секунд, совместимо с Google Authenticator и аналогами. После подтверждения показываются десять резервных кодов — один раз; создание нового набора немедленно аннулирует прежний. Включение и отключение защиты завершают все прежние сессии участника.

Что здесь важно для безопасника:

• администратор не может включить второй фактор за другого участника;
• политики «второй фактор обязателен для всей организации» в продукте нет. Если он обязателен по вашим правилам, договаривайтесь с людьми или используйте корпоративный вход, где политику задаёт внешний поставщик учётных записей;
• для сессий, созданных через корпоративный вход, политику второго фактора определяет тот же внешний поставщик, а не ActionPulse.

Повышения прав перед опасным действием (step-up) в кабинете нет. Продукт не просит пароль и код повторно перед удалением данных. Вместо этого опасные действия закрыты явным подтверждением, и подтверждение проверяет сервер, а не только интерфейс:

Действие	Что требует сервер	Что требует кабинет
Удаление данных субъекта	заголовок X-Confirm-Forget: true, иначе 422 с кодом confirmation_required	ввести FORGET
Удаление собранных данных форм	заголовок X-Confirm-Purge: true, иначе тот же 422	ввести слово «удалить»
Смена пароля	текущий пароль	текущий пароль
Отключение защиты, новые резервные коды	пароль и текущий одноразовый код	то же
Удаление проекта, удаление участника	—	диалог подтверждения с именем объекта

Практический вывод: единственная реальная защита опасных действий — это состав роли admin и второй фактор у её носителей. Держите список администраторов коротким и проверяйте, что у каждого включена двухфакторная защита.

Как права проверяются на самом деле

Несколько свойств механизма, которые полезны и при разборе инцидента, и при настройке доступа.

Роль перечитывается из базы на каждом запросе. Она не берётся из выданного ранее токена, поэтому смена роли и удаление участника действуют с ближайшего запроса — ждать истечения сессии не нужно.

Проверка работает fail-closed. Неизвестное действие и неизвестная роль дают отказ, а не «разрешить на всякий случай».

Отказ и отсутствие различаются намеренно. Недостаточная роль — 403; обращение к проекту или объекту другой организации — 404, даже если объект существует. Так по ответу нельзя проверять существование чужих данных.

Матрица в интерфейсе — это UX, а не граница безопасности. Пока роль не загружена, элементы управления недоступны; неизвестная роль трактуется как отказ. Но авторитетен всегда сервер: прямой запрос к API проверяется так же строго, как нажатие кнопки в кабинете.

Read-only состояние организации выключает изменения поверх роли. Если триал закончился без оплаты или подписки нет, изменения отвечают 402 с кодом trial_expired или subscription_required — независимо от роли. Единственное исключение — самостоятельная оплата: она остаётся доступной владельцу, иначе из этого состояния нельзя было бы выйти.

Что проверить

• В организации не меньше двух владельцев.
• Список администраторов совпадает с тем, кто действительно должен выпускать ключи, менять настройки сбора и удалять данные.
• У всех владельцев и администраторов включена двухфакторная защита.
• Роль analyst выдана только тем, кому нужны SQL-консоль и записи сессий: это два самых чувствительных чтения в продукте.
• Для тех, кому нужны только отчёты, выдан viewer — он видит почти всё и не меняет ничего.
• Люди, которые больше не работают с продуктом, удалены из организации, а не понижены до наблюдателя.
• Если уходящий участник мог видеть серверный ключ, ключ ротирован отдельно — ключи к людям не привязаны, см. токен и секрет.