Как спроектировать роли и доступы корпоративного портала

Не начинайте с роли «администратор для всех»

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

Соберите типы пользователей и объектов: сотрудник, руководитель, кадровый специалист, редактор базы знаний; заявление, документ, карточка сотрудника, отчёт. Затем перечислите действия над ними. Просмотр, согласование и экспорт — разные возможности, даже если находятся на одном экране. Наличие доступа к карточке не обязательно разрешает массовую выгрузку.

Постройте матрицу с областью данных

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

Разделите роль и исключение

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

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

Проверяйте разрешение при обращении к данным

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

Ошибки не должны раскрывать лишние сведения о чужом документе. При этом уполномоченному сотруднику нужна понятная причина невозможного действия. Разделите публичное сообщение и внутренний журнал диагностики. В журнал не следует без необходимости копировать весь документ или секреты; для расследования важнее действие, объект, время и результат проверки.

Опишите жизненный цикл сотрудника

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

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

Учебный набор проверок

Руководитель одного отдела открывает свой документ, затем пытается получить документ другого отдела по известному идентификатору. Второе действие отклоняется без раскрытия содержимого. После перевода сотрудника доступ пересчитывается, а временное замещение прекращается в назначенный срок. Экспорт подчиняется той же области, что и просмотр.

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

Передайте правила владельцу портала

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

Заполненная матрица для заявки на закупку

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

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

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

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