Права доступа в B2B‑ПО: почему одной большой админ‑роли недостаточно

Почему одна большая роль администратора становится проблемой

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

Но это не длится вечно.

Как только реальные клиенты начинают просить исключения, роль администратора превращается в корзину для всех прав, которые модель не может объяснить. Один клиент хочет, чтобы сотрудник финансов видел счета и методы оплаты, но не приглашал пользователей. Другой — чтобы руководитель команды добавлял людей в один отдел, не меняя настройки аккаунта. Менеджеру поддержки нужен доступ к обращениям и отчётам, но он не должен иметь дело со счетами и настройками безопасности.

Если в продукте есть только «пользователь» и «админ», вы застреваете в двух плохих вариантах. Либо отказываете в разумном запросе, либо даёте слишком много прав.

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

Это создаёт напряжение внутри команды клиента. Финансы хотят разделения обязанностей. Руководители хотят автономии. Владельцы хотят меньше рисков. Когда продукт не умеет выражать эти ограничения, люди обходят систему: общие логины, ручные согласования или постоянные тикеты в поддержку.

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

Работа поддержки тоже становится сложнее. Когда спрашивают «Кто сменил эту настройку?», часто отвечают просто «админ». Это мало помогает. По мере роста аккаунтов аудитировать сложнее, ошибки расходятся шире, а ревью доступа занимают больше времени, чем нужно.

То, что казалось простым при пяти пользователях, часто тормозит при пятидесяти.

Начните с действий, а не с должностей

Большинство моделей прав ломаются с первого дня. Команды начинают с ярлыков вроде «админ», «менеджер» или «оператор», а затем угадывают, что каждый должен уметь. Это кажется быстрым, но чаще создает одну гигантскую роль администратора, которая постоянно растёт.

Лучше начинать с списка действий. Запишите, что люди действительно делают в продукте каждую неделю. Это даёт конкретику, вокруг которой можно проектировать.

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

В процессе разделите рутинные операции и редкие задачи настройки. Рутинная работа происходит каждый день: обновление записей, просмотр тикетов, назначение задач. Настройка — реже: изменение биллинга, подключение интеграции, установка правил безопасности. Редкие задачи вызывают проблемы, когда их упаковывают в ту же роль, что и повседневную работу.

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

Простой способ найти рискованные действия — спросить, влияют ли они на платежи или контракты, раскрывают ли регулируемые данные, меняют ли безопасность или интеграции, удаляют ли данные или меняют их глобально.

Не растягивайте список слишком сильно. Первый вариант должен быть достаточно коротким, чтобы протестировать его с реальными пользователями за неделю‑две. Если у вас получилось 80 действий до того, как вы поговорили с кем‑то, вы, вероятно, проектируете крайние случаи вместо нормальной работы.

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

Разделяйте роли и области доступа

Чистая модель прав состоит из двух частей. Роль отвечает на вопрос «что может делать человек?». Область отвечает «где он может это делать?». Когда один ярлык пытается решать оба вопроса, модель быстро превращается в кашу.

Если создавать отдельную роль для каждой границы доступа, вы получите копии одной и той же роли. «Админ команды», «региональный админ» и «админ проекта» часто разделяют большинство действий. Добавили одно новое действие — и редактировать нужно все копии.

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

Области добавляют ограду. Один менеджер может управлять только командой продаж. Другой — регионом ЕС. Подрядчик — только одним проектом. Роль остаётся одинаковой, меняется область.

На практике структура проста: роль определяет действия (view, edit, approve, invite и т. п.); область задаёт границу (одна команда, один регион, один проект или весь аккаунт); назначение даёт человеку определённую роль в конкретной области.

Это разделение также помогает отделить владение аккаунтом от операционного доступа. Владелец аккаунта должен контролировать редкие чувствительные действия: смену подписки, удаление рабочей области, передачу прав владения. Большинству людей такие права не нужны, даже если они руководят отделом.

Представьте клиентский аккаунт с несколькими командами. Операционный руководитель получает роль менеджера только для склада. Финансовый руководитель — доступ к биллингу по всему аккаунту. Никто из них не нуждается в широких правах администратора.

Именно для этого нужны роли и области: дать людям достаточно прав для работы, не превращая каждое исключение в ещё одно место администратора.

Стройте модель шаг за шагом

Начните с ресурсов, к которым люди обращаются в продукте, а не с готовых прав. Составьте список ресурсов: пользователи, счета, проекты, отчёты, настройки. Если вы что‑то упустите сейчас, это обычно вернётся позже в виде запутанного исключения.

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

Затем сгруппируйте действия в несколько стартовых ролей. Цель — роли, соответствующие типичным обязанностям: менеджер финплана, руководитель проекта, агент поддержки или владелец аккаунта. Четыре простые роли легче объяснить и протестировать, чем пятнадцать хитроумных.

После этого добавьте области доступа. Здесь вы отделяете «редактировать свои проекты» от «редактировать любые проекты в команде», и «одобрять счета в одном регионе» от «одобрять по всему аккаунту».

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

Перед релизом протестируйте каждую роль на реальной работе, а не просто просматривая таблицу прав. Попросите команду разыграть типичные задачи. Менеджер проекта обновляет проект своей команды. Финансовый руководитель одобряет счета своего региона. Агент поддержки открывает профиль пользователя, но не может менять биллинг. Владелец аккаунта меняет настройки рабочей области.

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

Такой подход делает модель проще для понимания и расширения. Когда приходит новая команда, обычно достаточно добавить область или скорректировать роль, а не создавать новый всесильный админ‑вариант.

Простой пример для мультикомандного аккаунта

Представьте компанию с одним аккаунтом, тремя отделами и людьми, которым каждый день нужны совершенно разные права. Если дать всем одну админ‑роль, рутинная работа быстро станет рисковой. Человек, которому надо только помогать клиентам, внезапно сможет менять цены, биллинг или управлять пользователями по всей компании.

Лучше связывать каждое действие с областью.

Представление поддержки видит заказы только тех команд, которые он поддерживает, но система блокирует изменения цен. Финансовый руководитель может одобрять возвраты только в рамках своего бизнес‑юнита. Руководитель команды может приглашать новых пользователей, но только в свой отдел. Владелец аккаунта контролирует биллинг, настройки входа и глобальные параметры.

Теперь у каждого достаточно прав для работы — и не больше. Поддержка отвечает на вопросы клиентов, не трогая настройки доходов. Финансы обрабатывает возвраты своего подразделения, не видя другие команды. Менеджерам дают возможность набирать и интегрировать людей без превращения их в мини‑админов.

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

Временный доступ помогает в редких случаях. Например, финансовому руководителю нужно проверить цены при споре в конце квартала, или менеджер покрывает коллегу в отпуске. Вместо создания ещё одной широкой админ‑роли, дайте временное разрешение с чёткой областью и сроком действия.

Простое правило часто работает лучше: повышенные права истекают автоматически через фиксированное время — час или день. Человек выполняет задачу, и право уходит, никому не нужно помнить о ручной очистке позже.

Это часто и есть разница между аккуратной моделью прав и ситуацией, где через шесть месяцев все говорят «ну просто сделайте его админом».

Ошибки, которые портят модель

Модели прав редко ломаются в одном релизе. Обычно они разваливаются через маленькие упрощения. Один клиент просит особую роль, появляется широкая роль «редактор», ей добавляют ещё одно право — и вскоре ваша команда не может объяснить, кто что изменяет.

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

Широкие роли «редактор» создают другую проблему. «Редактировать» кажется простым, но туда часто прячут удаление, одобрение, публикацию, приглашения и изменение настроек. Эти действия несут разный риск и не должны ехать в одном пакете с обычными правками контента.

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

Команды также забывают про действия вне основных экранов — и эти пробелы создают худшие сюрпризы. Экспорт важен, потому что он выносит данные наружу. Массовые правки и удаления важны, потому что одна ошибка затрагивает сотни записей. API‑токены, сервисные аккаунты и глобальные настройки аккаунта важны, потому что они могут затронуть сразу все команды.

Если пропустить это, роль может выглядеть безопасной в UI, но при этом позволять много урона одним кликом или скриптом.

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

Напишите тесты для нескольких реалистичных сценариев. Проверьте свежие приглашения, пользователя с двумя членствами, пользователя, который теряет одну область, и пользователя с API‑доступом без UI‑доступа. Если продукт может однозначно ответить на эти случаи, модель обычно остаётся чистой значительно дольше.

Обрабатывайте исключения, не делая новых админов

Большинство проблем с правами начинается, когда редкий запрос решают широкой ролью. Кому‑то нужно вернуть платёж, выгрузить данные аккаунта или разово изменить биллинг, и ему дают админ‑доступ навсегда. Это просто в моменте, но быстро ослабляет модель.

Лучше относиться к рискованным действиям как к исключениям, а не как к новым ролям. Если действие может поменять деньги, настройки безопасности, юридические параметры или структуру аккаунта — поместите его за механизмом одобрения. Один человек запрашивает. Другой одобряет. Система фиксирует, кто просил и кто одобрил, и когда это произошло.

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

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

Кому‑то всё ещё нужен временный расширенный доступ. Дайте его с автоматическим истечением, а не в постоянной роли. Если поддержке нужно посмотреть аккаунт клиента, позвольте им разблокировать нужное действие на час или день. После этого доступ сам пропадёт.

Начинайте сотрудников поддержки, success и аккаунт‑менеджеров с режима только для чтения, если их ежедневная работа действительно не требует большего. Многие команды раздают широкие права, чтобы избежать трения. Через полгода никто не помнит, кто что может. Режим «только чтение» — более безопасный по умолчанию, а потом можно добавлять небольшие исключения.

Запишите, кто может выдавать исключения и почему. Простые правила работают лучше. Назовите роли, которые могут одобрять, перечислите действия, которые они могут одобрять, и требуйте поле с обоснованием. Если никто не владеет выдачей исключений, они расползаются по Slack, личным договорённостям и памяти.

Короткая политика помогает больше, чем ещё одна роль администратора. Люди должны знать, когда обращаться, кто может сказать «да», на какой срок даётся доступ и где хранится запись. Это даёт гибкость без превращения каждого редкого случая в полный контроль.

Быстрые проверки перед релизом

Прогоните пять простых тестов на фейковом аккаунте клиента перед выпуском. Не тестируйте под своим супер‑админом — это скрывает пробелы.

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

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

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

Короткий чек‑лист релиза помогает поймать обычные ошибки:

• Обычный пользователь заканчивает рутинную работу без помощи админа.
• Руководитель персонала может приглашать без доступа к биллингу.
• Менеджер с областью действует только внутри своей команды, региона или клиентской группы.
• Аудит‑лог показывает, кто менял доступ, что изменилось и когда.
• Можно удалить или заменить роль, не заблокировав пользователей.

Последний пункт часто упускают. Роли меняются со временем, особенно в растущих аккаунтах. Если удаление старой роли ломает отчёты, одобрения или правила входа — модель слишком запутана.

Смотрите логи во время тестов. Вам нужна чёткая история для каждого изменения прав: кто, кого затронул и время. Когда клиент спрашивает «Кто дал этому человеку доступ?», поддержка должна ответить за секунды.

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

Что делать дальше

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

Затем возьмите один реальный аккаунт клиента и нарисуйте людей в нём. Не надо сразу картировать весь рынок. Один аккаунт с несколькими командами достаточно хорошо покажет типичные роли: владелец, финансовый сотрудник, руководитель, обычный пользователь и, возможно, внешнее лицо.

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

Короткий рабочий черновик обычно достаточен. Перечислите 10–20 самых частых действий, сгруппируйте их в небольшие роли, добавьте области — команда, проект, рабочая область или аккаунт — и отметьте рискованные действия, которые требуют дополнительной проверки.

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

Проведите одну столбовую (tabletop) репетицию перед развёртыванием. Возьмите пример‑аккаунт и задайте практические вопросы. Может ли руководитель команды приглашать людей только в свою команду? Может ли финансы смотреть счета, не меняя настройки аккаунта? Может ли подрядчик править один проект, не увидев всего остального? Вы быстро найдёте пробелы.

Если у продукта уже есть общие аккаунты, логи аудита, биллинг или регламентированные данные — часто стоит привлечь внешнего эксперта. Oleg Sotnikov at oleg.is работает как Fractional CTO и стартап‑советник; такого рода ревью модели прав и плана релиза естественно вписывается в эту работу.

Цель скромна: меньше тикетов про доступ, меньше случайных блокировок и гораздо меньше ситуаций, когда «просто сделайте его админом» кажется единственным решением.