Роли и права в личном кабинете: безопасный доступ клиентов и сотрудников

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

Разграничение прав доступа в личном кабинете начинается с вопроса, кто и какое действие может выполнить с конкретным объектом. Названия ролей в меню не решают этот вопрос. Клиент, сотрудник, руководитель и поддержка могут работать с одними сущностями по разным основаниям. Система должна проверять доступ на сервере и сохранять границы при экспорте, уведомлении, фоновой задаче и изменении роли. Разберём проектирование прав для клиентского и корпоративного кабинета: матрицу действий, отношения пользователей и организаций, приглашения, отзыв, административные операции и негативные тесты. Речь о технической модели, а не о юридической классификации данных. Требования к конкретному продукту согласуются с владельцами процессов и профильными специалистами. Что означает разграничение прав доступа Разграничение прав доступа — определение и проверка того, какие субъекты могут выполнять какие действия над какими объектами в заданном контексте. Для кабинета важно учитывать пользователя, организацию, роль, состояние объекта и дополнительные условия. Видимость кнопки помогает интерфейсу, но окончательное разрешение выдаёт защищённая часть системы. Различайте вход и разрешение. Аутентификация подтверждает идентичность, а авторизация — допустимость действия. Пользователь может успешно войти и не иметь права на чужой документ. Он может видеть заказ, но не отменять его. Он может управлять своей организацией, но не создавать новые полномочия платформы. Для понятной модели начните с словаря: субъект, объект, действие и контекст. Субъектом бывает человек или интеграция; объектом — заказ, файл, отчёт; действием — просмотр, изменение, согласование. Контекст включает отношения и состояние. Это помогает избежать универсальной роли «администратор», смысл которой различается на каждом экране. Инвентаризация действий Сначала перечислите операции, которые продукт позволяет выполнить. Не ограничивайтесь страницами. На одной странице могут быть просмотр, экспорт, назначение, отмена и загрузка документа. У этих действий разный риск и основание. Правило «есть доступ к странице» слишком грубо для сложного кабинета. Выделите массовые действия и внешние каналы. Возможность читать одну запись не всегда означает право выгрузить все. Фоновый отчёт, API партнёра и ссылка на файл должны иметь самостоятельные проверки. Если они появились позже интерфейса, нельзя считать, что исходная защита автоматически распространяется на них. Чтение списка и отдельной записи. Создание, изменение и удаление по согласованным условиям. Согласование, отмена и смена состояния. Назначение участников и ответственных. Загрузка, просмотр и скачивание файлов. Экспорт и массовое изменение. Настройка интеграций и выдача ключей. Управление ролями и приглашениями. Список проверяют с владельцем процесса. Техническая команда может не знать, что менеджер одного подразделения не должен видеть другой регион или что действие допустимо только до согласования. Эти условия должны стать частью модели и приёмки, а не остаться устной договорённостью. Матрица прав Матрица связывает роли с операциями и объектами. Для каждого разрешения укажите область: собственные данные, организация, подразделение или весь продукт. Если нужно дополнительное условие, запишите его. Одна галочка «редактирование» не объясняет, какие поля и состояния можно менять. Субъект Область Пример действия Условие Клиент Собственные заказы Просмотр и обращение Подтверждённая принадлежность Сотрудник организации Назначенные объекты Подготовка данных Действующее членство и роль Руководитель Согласованное подразделение Согласование Допустимое состояние объекта Поддержка Разрешённый контекст обращения Диагностика Ограниченный и прослеживаемый доступ Это учебный пример, который нельзя переносить в продукт без согласования. Добавьте отдельно экспорт, управление пользователями и изменение конфигурации. Если роль получает новое действие, оцените последствия для существующих участников. Массовое расширение прав не должно происходить незаметно вместе с обновлением интерфейса. Для сложного продукта полезно разделить базовую роль и дополнительные разрешения, но не создавать хаотичную комбинацию без проверяемых правил. Сотрудник должен понимать свои возможности, поддержка — объяснить отказ, разработчик — воспроизвести решение. Слишком гибкая конфигурация без ограничений усложняет все три задачи. Роли и отношения Роль описывает набор возможностей, отношения — область их применения. Руководитель может согласовывать документы своего подразделения, участник проекта — читать его задачи, клиент — видеть собственные заказы. Если учитывать только название роли, система может открыть все объекты одинакового типа. У пользователя может быть несколько отношений: сотрудник одной организации, партнёр другой и участник отдельного проекта. Они должны сохранять границы. При переключении контекста изменяются разрешения и видимые данные. Не копируйте права одного пространства в другое только потому, что аккаунт общий. Учебный пример: сотрудник видит проекты своего отдела и назначен участником проекта другого отдела. Модель должна объяснять, какие права даёт каждое основание и что происходит при отзыве назначения. Если правила складываются, определите конфликт запрета и разрешения. Не оставляйте это случайному порядку условий в коде. В OWASP Authorization Cheat Sheet рассматриваются рекомендации по проверке разрешений и безопасным значениям по умолчанию. Используйте их как ориентир при разработке, затем проверяйте собственную модель на конкретных объектах. Для нашего кабинета критерий — воспроизводимый разрешённый или запрещённый сценарий, а не наличие ссылки на стандарт. Состояние объекта как условие Право может зависеть от состояния. Автор редактирует черновик, но не утверждённый документ; клиент отменяет ещё не переданный заказ, но после начала исполнения создаёт запрос. Эти ограничения должны действовать на сервере и совпадать с тем, что объясняет интерфейс. Проверяйте переходы, а не только отдельные флаги. Если объект изменился между открытием формы и отправкой, прежнее разрешение может быть недействительным. Сервер должен проверить актуальное состояние и вернуть понятный результат. Пользовательская работа по возможности сохраняется, но недопустимое изменение не применяется. Учебная ситуация: два согласующих открыли документ. Один утвердил, другой отправляет изменение. Система должна применить выбранный процесс и не перезаписать состояние молча. Возможно создание новой версии или отказ с объяснением. Решение зависит от правил продукта, которые нужно согласовать заранее. Архив и удаление также влияют на действия. Возможность найти историческую запись не обязательно означает право изменить её. Восстановление — отдельная операция. Административный путь не должен обходить согласованные ограничения без полномочия и следа. Серверная проверка и прямые запросы Каждый разрешённый путь должен проверять субъект, объект и действие. Интерфейс может скрывать недоступную кнопку для удобства, но прямой запрос должен получить правильный результат. Это относится к обычному API, массовым операциям, импорту и административным инструментам. Не доверяйте идентификатору владельца, который прислал клиент. Сервер определяет допустимую принадлежность по проверенному контексту. Если пользователь изменил параметр запроса, он не должен создать запись у чужой организации. Связанные сущности проверяются совместно, а не только по существованию каждого идентификатора. Ошибка авторизации должна быть безопасной. Нельзя возвращать весь чужой объект и затем скрывать его на клиенте. Нельзя включать чувствительные подробности в текст отказа. Состав ответа должен помогать законному пользователю понять следующий шаг, не раскрывая сведения о чужих данных. Проверяйте серверные ветки, которые добавлены после основной реализации. Новый экспорт или внутренний метод может случайно использовать другой путь чтения. Общая модель и проверочный набор помогают удержать границы. При каждом расширении продукта нужно понимать, какие правила оно затрагивает. Приглашения и назначение роли Приглашение должно связывать организацию, адресата, роль, срок и состояние. Автор приглашения имеет право назначить только допустимые полномочия. Если сотрудник способен пригласить нового администратора без нужного основания, обычная функция превращается в расширение доступа. Принятие проверяет актуальность. Приглашение могло быть отозвано, роль изменена, организация закрыта. Повтор не должен создавать второе членство. Если вошедший пользователь отличается от ожидаемого адресата, нужен согласованный безопасный путь, а не молчаливое присоединение. Учебный пример: руководитель отправил приглашение с ограниченной ролью, затем повысил её перед принятием. Система должна знать, какая версия применяется и что подтверждает получатель. История изменения полезна для разбора. Нельзя полагаться только на текст первоначального письма. Передача владения организацией — отдельное существенное действие. Укажите условия, подтверждение и последствия для прежнего владельца. Если в продукте несколько владельцев, правила конфликтов и удаления тоже должны быть ясными. Не оставляйте организацию без управляющего доступа случайным удалением последнего участника. Отзыв прав и активные сессии Отзыв должен применяться в согласованном объёме к новым и текущим действиям. Пользователь может иметь открытую вкладку, сохранённую ссылку и фоновую задачу. Проверьте, что сервер использует актуальную модель там, где это требуется. Выход из интерфейса не является единственным способом ограничения. Кеш разрешений имеет условия обновления. Если он сохраняет прежние права, действие может оставаться доступным после отзыва. Выберите механизм и допустимый период с учётом риска продукта. Не обещайте мгновенный отзыв для всех каналов без проверенной реализации. Фоновая операция требует отдельного правила. Если экспорт начат с разрешением, а роль отозвана до готовности, кто может получить результат? Если действие уже изменило внешний сервис, отзыв не отменяет его автоматически. Опишите эти границы и проверяйте их на приёмке. При выходе сотрудника из организации проверьте интеграционные ключи, владельцев объектов и автоматические процессы. Личная учётная запись может быть связана с сервисной задачей. Нужно передать ответственность либо остановить её по согласованному плану, а не оставить скрытую зависимость. Файлы, документы и экспорт Файл проверяется как объект доступа, даже если хранится в другом сервисе. Постоянная публичная ссылка может нарушить границу правильно защищённой страницы. Механизм выдачи должен учитывать владельца, действие и срок доступности выбранного пути. Скачивание и предпросмотр проверяются отдельно. Экспорт объединяет много данных и требует соответствующего разрешения. Фильтр списка должен сохраняться в фоновом процессе, а не восстанавливаться по случайным параметрам. Если запрос касается организации, итог не должен содержать строки других контуров. Проверяйте также названия и метаданные. При пересылке документа нужно понимать, кому становится доступен результат. Техническая возможность создать ссылку не означает допустимость открыть её всем. Интерфейс должен объяснять выбранный режим и ограничения. Пользователь не должен случайно публиковать внутренний файл через привычную кнопку. Массовая загрузка тоже влияет на права. Вложение может привязаться к чужому объекту, если принадлежность не проверяется сервером. Устойчивое сопоставление и негативные тесты помогают обнаружить такой путь. Не проверяйте только открытие уже правильно созданного файла. Поддержка и административные действия Поддержке нужен ограниченный инструмент, а не общий доступ ко всем данным. Разделите диагностику, исправление и управление правами. Для каждого действия определите основание, роль и след. Если требуется работа в контексте клиента, это должно быть явно видно в служебной истории. Не используйте скрытый вход от имени пользователя как универсальный обход. Он затрудняет понимание, кто совершил действие, и может открыть лишние сведения. Пре

Автор: Никита Соловьёв, Senior Backend Developer, 404gen.