Роли и разрешения объяснены на понятных примерах — чтобы вы могли решить, что должны видеть владелец, менеджер, сотрудник и клиент, и предотвратить утечки данных.
«Утечка данных» на работе часто выглядит скучно. Агент поддержки открывает профиль клиента и видит всю историю платежей. Клиент заходит в систему и замечает внутренние заметки вроде «Дать 20% при жалобе» или реальную себестоимость и маржу в счёте. Пароль не украли — приложение просто показало не то.
Большинство утечек происходит случайно. Разрешения добавляют поздно, новая страница быстро уходит в релиз или кто‑то копирует старую роль, которая «подошла для теста». Потом небольшое изменение, например новое поле в таблице, тихо становится видно всем.
Вот почему роли и разрешения должны быть важной частью приложения, а не последней галочкой. Большинство малых бизнесов сводят набор ролей к четырём типам: Владелец, Менеджер, Сотрудник и Клиент.
Цель проста: каждый человек должен видеть только то, что нужно для работы, и ничего лишнего. Это касается данных «за кулисами», а не только ожидаемых экранов.
Если вы быстро собираете приложение на платформе без кода, например AppMaster, это ещё важнее. Скорость хороша, но она же упрощает случайное раскрытие приватных заметок, правил ценообразования или записей других клиентов, если доступ не продуман заранее.
Роли и разрешения — это правила, которые решают, кто что может делать в приложении.
Уровень доступа — практический результат этих правил. Двое людей могут быть «Сотрудниками», но у одного более высокий уровень доступа, потому что он может одобрять возвраты, а другой — нет.
Надёжный способ предотвратить ошибки — начинать с минимального доступа и добавлять только то, что человеку нужно для ежедневной работы. Если кто‑то никогда не редактирует счета, не давайте ему права на редактирование «на всякий случай». Добавить доступ позже проще, чем устранять последствия утечки.
Большинство разрешений сводится к небольшому набору действий: просмотр, создание, редактирование, удаление и несколько действий с высоким риском, например экспорт или утверждение.
Область отвечает на другой вопрос: «К каким записям это относится?» Кто‑то может иметь право смотреть счета, но только свои, а не все.
Типичные шаблоны области:
Продавец может создавать и просматривать свои коммерческие предложения, но не имеет права экспортировать полный список клиентов. Менеджер продаж может видеть предложения всей команды и одобрять скидки. Владелец видит всё и может экспортировать отчёты для бухгалтера.
Большинство приложений сводится к тем же четырём группам людей. Детали меняются, но шаблон остаётся. Если вы начнёте с прозрачных ролей и разрешений, то позже избежите множества неловких «почему они это видят?».
Владельцы обычно нуждаются в полном обзоре бизнеса. Это часто включает биллинг, настройки безопасности (правила паролей, MFA) и аудит — историю изменений, чтобы видеть, кто что и когда менял.
Менеджеры должны управлять командой, не будучи полноценными администраторами. Им обычно нужен обзор (видеть всё в своём отделе), право утверждать действия (скидки, возвраты, отпуска, изменения контента) и читать отчёты. Им могут понадобиться ограниченные админ‑функции, например приглашать сотрудников или сбрасывать пароль, но не доступ к биллингу или глобальным настройкам безопасности.
Сотрудники должны быстро выполнять повседневную работу при минимальном риске. Безопасный дефолт — «только то, что мне назначено». Агент поддержки видит только свои заявки, диспетчер — только маршруты на сегодня, продавец — только свои лиды. Экспорт и массовые загрузки по умолчанию выключены и включаются только при реальной необходимости.
Клиенты должны видеть только свои данные, даже если нескольким людям доступен один аккаунт. Разрешите им выполнять ограниченные действия (создавать запросы, оплачивать счета, обновлять профиль), но скрывайте внутренние заметки, комментарии персонала и внутренние статусы.
Набор дефолтов, который подходит многим компаниям:
Многие команды настраивают роли и разрешения по экранам: «Сотрудник может открыть страницу Заказы, клиент не может». Это помогает, но упускает реальный риск. Те же данные появляются в поиске, комментариях, уведомлениях, экспортах и вложениях.
Начните с перечисления областей данных, а не меню. Зоны с высоким риском обычно включают контакты клиентов, заказы и статус доставки, счета и статусы платежей, зарплаты и HR‑заметки, а также внутренние заметки или аналитику.
Затем решите, что каждая роль может делать с каждым типом данных: смотреть, создавать, редактировать, удалять, утверждать и шарить. Здесь важны правила на уровне полей. Один и тот же объект часто требует публичного и внутреннего представления.
Пример: в Заказе могут быть имя клиента, адрес доставки, цена, внутренняя маржа и внутренняя заметка вроде «Клиент часто жалуется, дать скидку». Клиент должен видеть адрес и статус, но никогда — маржу или внутреннюю заметку. Менеджер может видеть все поля и иметь возможность утверждать скидки. Сотрудник видит только поля, необходимые для выполнения, но не финансовые детали.
Вложения и файлы требуют повышенной осторожности. Договоры, удостоверения, квитанции и скриншоты часто содержат более чувствительную информацию, чем поля формы. Обращайтесь с ними как с отдельным набором разрешений: кто может загружать, кто скачивать и кто просматривать превью. Решите, наследует ли доступ к вложению доступ к родительской записи (например, счёту) или у файлов свои правила.
Наконец, не относитесь к экспортам и массовым действиям как к «включённым», только потому что кто‑то может увидеть список. Сделайте их явными: экспорт в CSV/PDF, массовая загрузка вложений, массовые изменения статуса (утвердить, отменить, вернуть), массовые рассылки (email/SMS/Telegram) и админ‑действия вроде перераспределения записей.
Представьте небольшой сервисный бизнес: владелец продаёт проекты, менеджеры курируют задания, сотрудники выполняют работу, а клиенты утверждают сметы и оплачивают счета. Самый быстрый путь избежать неловких ошибок — согласовать роли и права до первого входа пользователя.
Начните с денежных деталей. Цена может быть видна большему кругу людей, чем прибыль. Частое правило: сотрудник видит, сколько брать с клиента, но не почему вы поставили именно такую цену. Техник может видеть позиции счёта, чтобы объяснить клиенту, но не должен знать внутреннюю маржу, себестоимость поставщика или особую скидку, предоставленную для выигрыша сделки.
Данные клиентов — ещё одна горячая точка. Многие команды хотят, чтобы несколько человек могли видеть контактные данные (чтобы позвонить нужному человеку), но редактировать их могли только немногие. Иначе появляются случайные перезаписи, например заменяют адрес для выставления счёта на личный email, и платежи перестают доходить до бухгалтерии.
Простая настройка, которая хорошо работает в большинстве команд:
Ограничьте действия с высоким риском. Отметка счёта как оплаченного, возврат средств или смена способа оплаты должны быть ограничены владельцем (или доверенной ролью в финансах).
Служба поддержки кажется простой: клиенты отправляют сообщения, команда отвечает, тикеты закрываются. Проблемы начинаются, когда одно и то же представление тикета используют для всех. Одна неверная настройка — и клиенты видят внутренние заметки, теги или даже статистику работы персонала.
Представьте небольшой e‑commerce с общей почтой поддержки. В тикете есть сообщение клиента, детали заказа, статус доставки и внутренние заметки вроде «возможное мошенничество, проверить ID» или «VIP, приоритет». Этот внутренний контекст помогает команде, но никогда не должен быть виден клиенту.
Чёткое разделение, которое сохраняет данные в безопасности:
PII клиентов — следующая ловушка. Саппорт часто нужен телефон или адрес, но не на каждом тикете. Хорошее правило: показывайте чувствительные поля только тогда, когда рабочий процесс требует их. Например, показывайте адрес только после выбора «проблема с доставкой», а после закрытия тикета скрывайте его снова.
Держите внутренние метрики отдельными от клиентского опыта. Время до первого ответа, оценка агента или пометка «эскалировано в юристов» — всё это должно быть видно только персоналу и менеджерам.
Представьте склад и полевую команду, которые весь день занимаются доставками. Кто‑то планирует маршруты, кто‑то комплектует, водители выполняют остановки. Если приложение показывает неверные данные неверным людям, это не только неловко — могут раскрыться адреса клиентов, цены или внутренние заметки.
Начните с разделения того, что кому нужно каждый день.
Сотрудники (комплектовщики и водители) обычно нуждаются в узком, ориентированном на задачу представлении. Водитель должен открыть приложение и видеть только задания на сегодня: порядок остановок, контакт для каждой остановки и инструкции по доставке. Он не должен просматривать полный список клиентов или задания других водителей. Если требуется замена смены, менеджер может переназначить задачу, вместо того чтобы давать широкий доступ.
Менеджеры нуждаются в общей картине операций. Они должны видеть расписание всех команд, остатки на складе и текущие проблемы (просроченные доставки, неудачные попытки, повреждённые позиции, недостающие подписи). Им нужны инструменты для решения исключений: переназначить остановку, разделить маршрут или утвердить корректировку остатков.
Клиенты получают минимальное представление: только статус их доставки. Они могут отслеживать ETA, видеть подтверждение доставки и получать обновления вроде «выезде к доставке» или «задержка». Они не должны видеть других клиентов, карты маршрутов на весь день или внутренние заметки по исключениям.
Простой способ обеспечить правильные права здесь — ограничить доступ по назначению и по аккаунту клиента. Например, запись Delivery Job читаема только (1) назначенному сотруднику, (2) менеджерам и (3) клиенту, привязанному к этому заказу.
Начните с простого названия групп пользователей понятным языком. «Владелец», «Менеджер», «Сотрудник» и «Клиент» — хороший старт, но только если это соответствует вашей бизнес‑реальности. Для каждой группы опишите, что считается успехом в одном предложении, например: «Менеджеры могут назначать работу и видеть производительность команды, но не видят зарплаты».
Далее сопоставьте действия с областями данных. Не думайте сначала про экраны — думайте про существующие данные и что люди с ними делают. Простая таблица на бумаге вполне подойдёт:
Затем протестируйте черновик на реальных задачах, а не догадках. Пройдитесь по типичным сценариям: «создать заказ», «закрыть тикет», «скачать отчёт». Если задача вынуждает дать широкий доступ, вероятно, не хватает отдельного разрешения (например, «видеть суммы без права экспорта»).
Добавляйте утверждения там, где это связано с деньгами или чувствительными изменениями. Сотрудники могут составлять счёт, но только менеджер может его утвердить и отправить. Сотрудник может редактировать адрес доставки, но изменение банковских реквизитов требует одобрения владельца.
Большинство утечек в малых командах — не взломы. Они происходят, когда приложению по ошибке дают больше прав, чем нужно для работы. Роли и разрешения ломаются, когда их настроили один раз и больше не пересматривали.
Распространённая схема — дать кому‑то полный админ‑доступ «на время настройки». Случай проходит, а доступ остаётся. Через недели тот человек скачивает полный список клиентов «для отчёта», и приватные данные оказываются в таблице.
Ошибки, которые повторяются снова и снова:
Боковые двери — самые коварные. Можно заблокировать экран контрактов, но при этом отправлять PDF этим же сотрудникам по почте. Или мобильная вёрстка может показывать поля, скрытые на десктопе.
Практическое исправление — рассматривать экспорт и скачивание как отдельные разрешения, а не как естественное следствие права просмотра. Если роли нужен список, дайте отфильтрованное представление, а не полный экспорт.
Перед тем как приглашать реальных пользователей, считайте, что кто‑то нажмёт не ту кнопку, поделится экраном или скачаем файл, который не следовало. Несколько проверок сейчас сэкономят кучу проблем позже.
Начните с дефолтов. Когда создаёте нового пользователя, он должен автоматически получить самую низкую роль, без доступа к деньгам, экспортам и админ‑настройкам. Если нужно больше — это должно быть сознательное изменение.
Дальше протестируйте клиентский опыт как посторонний. Клиенты должны видеть только свои записи, даже если они меняют URL, ищут или фильтруют. Быстрый тест: войдите как Клиент A и попробуйте найти Клиента B по имени, номеру счёта или ID тикета.
Пять быстрых проверок, которые ловят большинство утечек:
Сделайте «тест на случайность». Попросите коллегу выполнить реальную задачу под аккаунтом сотрудника, затем повторите ту же задачу под аккаунтом клиента. Если клиент видит внутренние цены, скачивает полные списки клиентов или может инициировать возврат — права слишком широки.
Частая просьба звучит так: клиент хочет портал для «проверки статуса», но персонал уже использует ту же систему для работы. Без чётких ролей портал может раскрыть внутренние заметки, заказы других клиентов или цены для персонала.
Представьте типографию по индивидуальной печати. Один заказ проходит от сметы до производства, доставки и счёта — всё в одном приложении.
Вот что должна видеть каждая роль в этом потоке:
Два крайних случая обычно ломают модель.
Первый: менеджер временно закрывает другую команду. Не переводите его в Владелец. Вместо этого добавьте временную область, например доступ к заказам команды B на 7 дней. По окончании покрывающего периода доступ истечёт.
Второй: VIP‑клиент просит «больше прозрачности». Дайте больше контекста, но не больше данных. Покажите расширенный таймлайн или отдельную ветку сообщений, но не открывайте внутренние заметки вроде «клиент пропускает платежи» или «перепечатка из‑за нашей ошибки».
Обязанности меняются, поэтому относитесь к доступу как к тому, что нужно регулярно пересматривать. При смене роли не накидывайте дополнительные права. Уберите то, что больше не нужно, и добавьте минимальный набор для новой работы.
Начните с малого. Выберите один рабочий процесс, который важнее всего, например «создать счёт и принять оплату» или «зарегистрировать тикет и ответить». Сначала определите роли и разрешения для этого потока, затем расширяйте.
Соберите правила в одной простой таблице и относитесь к ней как к живому документу: роль, что можно, что нельзя и какие ограничения (например «только свои записи» или «только своя локация»). Когда кто‑то спросит «Могут ли сотрудники видеть телефоны клиентов?», таблица должна ответить за секунды.
Практическая схема внедрения:
Если вы строите на AppMaster (appmaster.io), полезно планировать роли вместе с моделью данных и бизнес‑логикой, чтобы правила применялись одинаково в web, мобильных приложениях и API.
Если хотите, составьте первую таблицу доступа уже сегодня и опробуйте её на одном рабочем процессе. Этот шаг предотвратит большинство случайных утечек данных.
Как проще всего начать определять роли и разрешения?Начните с перечисления данных, которые вы храните (клиенты, заказы, счета, внутренние заметки, файлы), а затем решите, кто должен иметь возможность просматривать, создавать, редактировать, удалять, утверждать и экспортировать каждую сущность. Стройте от минимального доступа и добавляйте только то, что нужно для ежедневной работы.
В чём разница между разрешениями и областью видимости (scope)?Разрешения определяют какие действия человек может совершать, а область (scope) — к каким записям эти действия применимы. Например, сотрудник может иметь право смотреть счета, но только те, которые ему назначены или привязаны к его локации.
Нужно ли мне обязательно иметь четыре роли (Владелец, Менеджер, Сотрудник, Клиент)?«Владелец, Менеджер, Сотрудник, Клиент» покрывают большинство малых бизнесов, потому что отражают, как обычно распределяется работа и риск. Если структура сложнее, добавьте специализированные роли (например, Финансы или Подрядчик), вместо того чтобы делать всех админами.
Что клиенты должны видеть в портале клиента?Безопасный дефолт: клиенты видят и могут действовать только с собственными записями, но не видят внутренние заметки, внутренние статусы, маржу или теги только для персонала. Если клиент просит больше прозрачности, дайте более подробный таймлайн или отдельную ветку сообщений, а не открывайте дополнительные поля.
Как не допустить, чтобы сотрудники видели маржу или чувствительные ценовые данные?Разделяйте «что взимать» и «почему такая цена». Сотрудникам обычно нужны позиции счёта и статус, но не маржа, себестоимость поставщика, история скидок или управление оплатой (например, пометить платёж как оплаченный).
Почему экспорт и массовые загрузки — такая большая угроза?Относитесь к экспортам как к более рискованному разрешению, а не как к автоматическому следствию права просмотра списка. Многие утечки происходят, когда кто‑то скачивает полный список клиентов или историю счетов в таблицу, не понимая объёма содержащихся там данных.
Почему просто «закрыть экран» недостаточно для предотвращения утечек?Экран — лишь одно место, где данные видны; они также появляются в поиске, уведомлениях, PDF, мобильных версиях, вложениях и API-ответах. Хорошая практика — сначала защитить слой данных и видимость полей, а затем строить экраны поверх этого.
Как управлять правами на файлы и вложения?Держите вложения под отдельными правилами: они часто содержат более чувствительную информацию, чем поля формы. Решите, кто может загружать, просматривать превью и скачивать файлы, и наследует ли доступ к файлу доступ к родительской записи (например, счёту) или требует отдельного разрешения.
Как не допустить, чтобы клиенты видели внутренние заметки в службе поддержки?Постройте два представления одной и той же заявки: клиент‑безопасное представление без внутренних заметок, тегов и метрик персонала и внутреннее представление с полным контекстом. Также показывайте чувствительные поля клиентов только тогда, когда рабочий процесс требует их (например, адрес — при выборе «проблема с доставкой»).
Какие быстрые тесты прав доступа стоит выполнить перед приглашением реальных пользователей?Создайте демо-аккаунты для каждой роли и прогоните реальные задачи от начала до конца, включая крайние случаи: поиск, фильтры, открытие вложений и создание документов. Также попробуйте «Клиент A пытается найти Клиента B» — по имени, ID и URL — чтобы убедиться, что область применена по‑всему.
21 янв. 2026 г.
1 мин
20 янв. 2026 г.1 мин
20 янв. 2026 г.1 минЭкспериментируйте с AppMaster с бесплатной подпиской.
Как только вы будете готовы, вы сможете выбрать подходящий платный план.
