Управление сайтом
Роли доступа: кто может читать, менять и публиковать
Правила, связывающие роль пользователя с разрешёнными действиями. Для каждого действия также определяют, к каким объектам и при каких условиях относится разрешение.
Редакция:
«Выдадим доступ администратора» оставляет открытыми несколько вопросов: сможет ли сотрудник видеть все черновики, менять чужие материалы, публиковать их и назначать права другим людям? До оценки сайта перечислите нужные действия и границы каждого разрешения.
Вход подтверждает личность пользователя. Проверка прав определяет, разрешено ли ему конкретное действие с конкретной записью. Сам факт успешного входа не даёт доступа ко всему содержимому системы.
Учебная матрица ROLE-37
В вымышленной редакции есть автор, выпускающий редактор и администратор учётных записей. Материалы относятся к разделам; автору назначают собственные черновики, редактору — раздел. Это пример требований, который нужно проверить в выбранной CMS. Он не описывает роли в проектах CoreWeb.
| Действие | Автор | Выпускающий редактор | Администратор учётных записей |
|---|---|---|---|
| Читать непубличный материал | Только назначенный ему черновик | Материалы назначенного раздела | Нет по этой роли |
| Менять содержание | Свой черновик до передачи на проверку | Материалы назначенного раздела | Нет по этой роли |
| Публиковать или снимать с публикации | Нет | В назначенном разделе после проверки | Нет по этой роли |
| Назначать пользователей на раздел | Нет | Нет | По утверждённой заявке владельца доступа |
| Выдавать роль редактора | Нет | Нет | По утверждённой заявке, с записью решения |
«Нет по этой роли» означает отсутствие разрешения в данной матрице. Если одному человеку нужны несколько ролей, отдельно согласуйте их сочетание и итоговые права. В ROLE-37 администратор не может сам утвердить себе редакторский доступ: для этого требуется решение владельца доступа. Возможность технически обойти такое разделение должна быть разобрана до приёмки.
Условие «свой черновик» — часть проверки прав. Два пользователя с одинаковой ролью автора получают разные наборы записей. Для публично опубликованных страниц действует отдельное правило чтения посетителями; ограничения таблицы относятся к непубличным материалам и операциям CMS.
Запрещённая публикация: что проверить
Для приёмки ROLE-37 подготовьте согласованную тестовую среду, два учебных черновика D37 и D38 и отдельные аккаунты. D37 назначен автору A37, D38 — другому автору. Ни один тестовый материал не должен попасть в публичный каталог. Проверки выполняет подрядчик в разрешённом контуре; реальные пользовательские данные для примера не нужны.
- Под A37 откройте D37, измените текст и сохраните черновик. Зафиксируйте новую версию: это разрешённая операция.
- Проверьте попытку публикации D37 под тем же аккаунтом через предусмотренный серверный интерфейс. Ожидается отказ: статус остаётся черновиком, публичная версия отсутствует. Скрытая кнопка в браузере подтверждает только поведение интерфейса.
- Под A37 запросите непубличный D38 и попробуйте его изменить. Ожидаются отказ в чтении содержимого и отсутствие изменений. Название, текст и вложения D38 не должны раскрываться в ответе об ошибке.
- Под редактором назначенного раздела проверьте разрешённую публикацию D37 на тестовом сайте. Затем проверьте отказ для материала другого раздела. Так проверяется граница разрешения, а не только работа одной кнопки.
- Отзовите у тестового редактора право публикации и повторите операцию из уже открытой сессии. В требованиях ROLE-37 отзыв действует на следующий запрос. Если выбранная система обновляет права с задержкой, согласуйте допустимый срок и способ прекращения старого доступа до запуска.
Протокол содержит роль, назначенный раздел, объект, действие, ожидаемый и фактический результат, состояние записи после попытки и ссылку на доказательство. Пароли, токены и содержимое реальных закрытых документов в протокол не включают. При отказе проверки остаётся открытый дефект; успешный вход или HTTP-ответ без проверки состояния записи его не закрывает.
Где должна действовать проверка
OWASP Authorization Cheat Sheet рекомендует минимальные необходимые права, отказ по умолчанию и проверку разрешений на каждом запросе. Это относится и к прямому запросу к серверу: скрытие элемента интерфейса не заменяет авторизацию. Источник проверен 2 ноября 2026 года.
В своих требованиях перечислите все пути к защищённому действию: форма CMS, API, импорт, экспорт или файл по ссылке — если они есть в проекте. Проверку следует проводить там, где принимается решение о доступе. Одна матрица без реализации и отрицательных тестов не доказывает защищённость сайта.
Как включить роли в объём проекта
Попросите подрядчика оценить настройку ролей, ограничения по записям и разделам, выдачу и отзыв доступа, журнал значимых действий и проверки. Уточните, какие правила поддерживаются системой, а какие потребуют разработки. Количество ролей само по себе не показывает сложность: ограничение одной роли по клиентским организациям может затрагивать множество операций.
Перенесите разрешённые и запрещённые действия в чек-лист приёмки сайта. Начните с пары «автор сохраняет свой черновик / автор не публикует его» и добавьте проверку чужой записи. Для выбора системы используйте демонстрационный сценарий CMS; для устройства материалов — разбор модели контента.
Согласуйте роли, операции, границы и отрицательные сценарии в матрице доступа сайта. Она сохраняет открытые вопросы и результаты ручной проверки в TXT; реальные права не меняет.