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

Проблемы с правами обычно начинаются как небольшие неудобства. Приходит тикет: «Я — админ, но не вижу счета». Другой: «Почему мой коллега может редактировать настройки?» Люди кликают, догадываются и иногда делятся единым логином «владельца», потому что так быстрее, чем разбирать доступы.
Потом появляются временные решения. Команды придумывают роли вроде «Admin 2» или «Manager (no delete)». Инженеры добавляют одноразовые проверки вроде «если пользователь из Sales, разрешить экспорт», потому что это решает сегодняшнюю проблему. Через месяц никто не понимает, какие правила намеренные, а какие — случайные заплатки.
Ситуация ухудшается, когда вы добавляете больше клиентов. Правило, которое работало для одной компании ("админы видят все данные"), ломается при сотнях организаций с разными ожиданиями. Один заказчик хочет строгого разделения между отделами. Другой — общий рабочий процесс. Кто-то хочет, чтобы подрядчик имел доступ только к одному проекту. Если модель неясна, каждый новый клиент становится исключением.
Цель проста: предсказуемые правила доступа, которые можно объяснить за одну минуту. Например: «Организация владеет данными. Команды группируют людей. Роли определяют действия. Ресурсы принадлежат организации и иногда — команде. Совместный доступ следует нескольким дефолтным правилам.» Если вы не можете объяснить это просто, с этим будет трудно работать, тестировать и безопасно менять.
Обещание, которое стоит выполнить: меньше ролей, понятнее владение, безопасные дефолты. Начните с небольшого набора ролей, привязанных к реальным обязанностям, сделайте владение очевидным для каждого ресурса и по умолчанию давайте минимально необходимый доступ. Затем разрешайте совместный доступ целенаправленно, а не по случайности.
Если ваше приложение обслуживает более одного клиента, разберитесь в ментальной модели прежде, чем писать правила. Большая часть путаницы в мультиарендных SaaS возникает из-за размытых определений, когда одно и то же слово значит разное в разных частях продукта.
Выберите одно значение для границы арендатора и придерживайтесь его. Многие продукты используют «организацию» как арендатора: все данные живут внутри организации, и ничего не пересекает эту границу, если вы явно не реализуете шаринг.
Простая словарь, который останется понятным по мере роста:
«Один человек — много организаций» — нормально. Консультант может состоять в трех клиентских организациях, в каждой с разной ролью. Поэтому «пользователь» и «членство» должны быть раздельными. Проверки обычно зависят от членства, а не от пользователя в целом.
Команды полезны, когда они отражают реальные группы, такие как «Support» или «Finance». Они добавляют шум, когда превращаются во вторую систему прав. Полезный тест — можно ли объяснить команду в одном предложении без упоминания конкретного правила для фичи.
Пример: Мария входит в систему один раз и переключается между Организацией A и Организацией B. В Организации A она в Finance и может смотреть счета. В Организации B она — Viewer и может лишь читать проекты. Один и тот же пользователь, разные членства, единые типы ресурсов, четкие границы.
Права в мультиарендном SaaS остаются понятными, если вы разделите три вещи:
RBAC (role-based access control) означает: вы даете пользователю роль, и эта роль предоставляет разрешенные действия. Имена ролей должны описывать обязанности, а не статус. «Billing Admin» понятно. «Power User» обычно вызывает споры.
Относитесь к правам как к глаголам и держите их последовательными по всему продукту:
Добавьте область, чтобы один и тот же глагол мог применяться в разных местах. Так вы избежите создания 20 почти одинаковых ролей.
Распространенные области, которые остаются читаемыми:
Если вы ловите себя на создании ролей типа «Project Editor» и «Project Editor (Own)», обычно это проблема области, а не роли.
Пример: в CRM пусть «Sales Rep» создает и редактирует сделки, но ограничьте область «собственные элементы». «Sales Manager» может иметь те же глаголы с областью «только команда» или «вся организация». Вы получите меньше ролей, понятные правила и меньше сюрпризов при смене команды.
Хороший дефолт: роли дают глаголы, а владение (или назначение) ограничивает, где эти глаголы работают.
Если ваша модель работает для одного клиента, но ломается при десяти, вы, вероятно, смешали «кто может видеть» с «кто может делать» и «кому принадлежит». Разделите эти вещи, и система останется предсказуемой.
Набор правил, который масштабируется:
Пример: Сэм состоит в Организации A и Организации B. В Организации A он Member и может создавать и редактировать свои отчеты, но не менять биллинг. В Организации B он Billing Manager и может обновлять способы оплаты и скачивать счета, но по-прежнему не может видеть приватные проекты, если его членство не включает этот раздел.
Это делает рост скучным в хорошем смысле. Добавление новой организации — просто добавление членств и ролей. Базовые правила остаются теми же.
Напишите одну страницу, которую коллега сможет прочесть за две минуты. Если вы можете объяснить права без просмотра кода — вы на верном пути.
Держите части небольшими и предсказуемыми:
Используйте область (scope), чтобы избежать взрыва ролей. Многим продуктам хватает трех областей: own, team, org.
| Role | View | Edit | Invite users | Billing | Scope note |
|---|---|---|---|---|---|
| Owner | Да | Да | Да | Да | По всей организации, может передавать владение |
| Admin | Да | Да | Да | Нет/Да | По всей организации, без передачи владения |
| Member | Да | Ограничено | Нет | Нет | Своё + команда (где назначен) |
| Viewer | Да | Нет | Нет | Нет | Только чтение в назначенной области |
Проверка здравомыслия: покажите эту страницу нетехническому коллеге и спросите: «Может ли сотрудник поддержки редактировать Sales-отчет?» Если он сомневается, ваши области или определение команды неясны.
Чтобы права оставались понятными, решите, кто владеет каждым ресурсом, и ограничьте опции шаринга.
Сделайте большинство ресурсов собственностью организации. Клиенты обычно думают в терминах компании: счета, проекты, контакты, тикеты и автоматизации принадлежат организации, а не отдельному человеку.
Команды всё ещё полезны, но рассматривайте команду как метку рабочего процесса для маршрутизации и дефолтной видимости, а не как секретную логическую границу безопасности. Тег команды может управлять фильтрами, дашбордами, уведомлениями или очередями, в то время как доступ по-прежнему приходит из ролей и областей.
Ресурсы, принадлежащие пользователю, должны быть исключением и резервироваться для действительно личных вещей: черновики, приватные заметки, сохраненные представления, API-токены или персональные настройки. Если пользователь уходит, решите заранее, что происходит: удаление, передача или сохранение как приватное.
Небольшой набор правил шаринга, который остаётся читаемым:
Когда кто-то говорит «мне нужен доступ», уточняйте уровень: это его личный элемент, работа команды или вся организация. Если это не вписывается в эти три уровня, часто это признак того, что области неясны, а не того, что нужен новый режим шаринга.
Пример: тикет поддержки может быть собственностью организации (чтобы менеджеры могли формировать отчеты по всем тикетам), помечен командой Support (чтобы попасть в нужную очередь) и назначен Джордану (чтобы он был ответственным). Назначение не должно блокировать других ролей, у которых есть разрешение на просмотр.
Права часто ломаются во время «событий с людьми»: приглашение, перемещение между командами или удаление доступа. Эти потоки определяют, останется ли модель предсказуемой.
Рассматривайте приглашение как запрос на создание членства, а не как доступ само по себе. В приглашении должно быть указано, в какую организацию, в какую команду (опционально) и какую роль получит пользователь при принятии.
Держите правила жесткими:
Временный доступ тоже сюда вписывается. Вместо придумывания роли «временный пользователь», позвольте назначению роли иметь дату окончания. Когда срок истечет, доступ автоматически отзывается, а аудит остаётся чистым.
Когда человек покидает организацию, не догадывайтесь, что делать с его ресурсами. Если правило «ресурсы принадлежат организации», придерживайтесь его. Человек может оставаться автором для истории, но владельцем остаётся организация.
Если у вас есть ресурсы, принадлежащие пользователю, требуйте передачи перед удалением для всего чувствительного (проекты, документы, API-ключи).
Одна учетная запись может принадлежать многим организациям, но в приложении всегда должен быть один «текущий org». Делайте это очевидным в интерфейсе и ограничивайте каждое действие контекстом текущей организации.
Деактивация обычно лучше, чем удаление. Она убирает доступ сейчас, но сохраняет прошлые действия для аудита.
Большинство моделей прав терпят неудачу, потому что растут быстрее, чем правила. Защитите базовые вещи (граница арендатора, владение, область) и относитесь ко всему остальному как к деталям.
Взрыв ролей — классическая ловушка. Появляется крайний случай, и вы создаете новую роль вместо более ясного права или области. Через несколько месяцев никто не понимает, что значит «Manager Plus». Если специальный случай нужен часто — сделайте его первоклассным правом. Если редко — решайте временными правами с истечением.
Дрейф прав тихий, но хуже. Кто‑то добавляет «еще одно исключение» и забывает обновить одностраничную модель. Год спустя письменные правила и реальная система расходятся. Сначала обновляйте модель, затем реализуйте.
Команды как фальшивая граница безопасности вызывают постоянную путаницу. Если ресурсы можно шарить между командами внутри одной организации, скажите об этом ясно. Если нельзя — жёстко запрограммируйте это, а не полагайтесь на названия.
Красные флаги, которые стоит ловить рано:
Если служба поддержки просит «дать им глобального админа на минуту», это утечка границы арендатора. Предпочитайте явный, логируемый доступ с узким контекстом (одна организация, временное окно, конкретные действия).
Каждый запрос должен сначала разрешать активную организацию (по поддомену, заголовку, сессии или маршруту) и отклонять все, что не сопадает.
После контекста организации держите проверки в последовательном порядке: сначала членство (есть ли они в этой организации?), затем роль (что им разрешено здесь?), затем владение или шаринг (имеют ли доступ к этой записи?). Если делать проверку владения до членства, вы можете непреднамеренно раскрыть существование записей.
Прогоните небольшой набор end-to-end тестов с реальными аккаунтами, а не только unit-тестами:
Добавьте базовые события аудита для действий, меняющих полномочия или перемещающих данные: смены ролей, удаления членства, экспорты, удаления, обновления настроек. Не обязано быть идеальным с первого дня, но должно отвечать на вопрос «кто, что и когда сделал?».
Пересмотрите дефолты. Новые организации и новые участники должны начинать с наименьших прав, которые всё ещё позволяют работать. Короткая внутренняя справка по правам для поддержки и продаж тоже помогает, с примерами вроде «Видит ли лид команды другие команды?» и «Что происходит с доступом после удаления?».
Начните с небольшой реальной настройки: одна клиентская компания (одна организация) с двумя командами — Sales и Ops. Все заходят в систему один раз и затем выбирают организацию. Sales нужны карточки клиентов и коммерческие предложения. Ops нужны биллинг и внутренние настройки.
Держите команды как группировку и рабочий процесс, а не как главный переключатель прав. Они могут влиять на дефолты и маршрутизацию, но не должны быть единственным шлюзом.
Выберите небольшой набор ролей и держите их стабильными по мере добавления фич: Admin, Member, Viewer. Роль отвечает на вопрос «Что ты можешь делать в этой организации?». Область отвечает на «Где ты можешь это делать?».
Добавьте одно правило владения: у каждого ресурса есть организация и владелец (часто создатель). Редактирование разрешено, если вы Admin, или если вы владелец и ваша роль включает «редактировать свое». Просмотр разрешен, если ваша роль включает «просмотр» для данного типа ресурса.
Пример: Sales Member создает коммерческое предложение. Другой Sales Member может его просмотреть, но не редактировать, если оно не расшарено с командой или не переназначено. Ops Viewer может видеть его только если правила позволяют Ops просматривать ресурсы Sales.
Когда вы подключаете 200 клиентских организаций, вы переиспользуете те же роли и правила владения. Меняются только членства, а не модель.
Запросы в поддержку вроде «Можно дать доступ X?» превращаются в чеклист: подтвердите организацию и ресурс, проверьте роль пользователя в этой организации, проверьте владение и шаринг, затем измените роль или поделитесь ресурсом. Избегайте одноразовых исключений и оставляйте заметку в аудите.
Рассматривайте вашу одностраничную модель как контракт. Реализуйте только те правила, которые вы можете обеспечить в каждом API-вызове и на каждом экране UI, иначе права превратятся в «зависит от ситуации».
Начните с малого: несколько ролей, четкие области и простое владение. Когда приходит новый запрос («Добавить роль Editor-Manager?»), сначала ужесточите владение или область. Новые роли должны быть редки.
Для каждого нового ресурса обеспечьте базовую последовательность:
org_id (и team_id, если применимо)Тестируйте реальные потоки до того, как полировать крайние случаи: приглашения, переключение организаций, страницы админов и поведение при потере доступа в середине сессии.
Если вы строите с помощью чат-ориентированного конструктора приложений, полезно сначала написать модель прав простым языком и держать её рядом со спецификацией продукта. На Koder.ai (koder.ai) Planning Mode вместе со снимками и откатом — практичный способ прогнать сценарии и убедиться, что правила ведут себя одинаково в вебе, бекенде и мобильных клиентах.