Права доступа и безопасность Битрикс24: практический минимум

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

Конкретные настройки зависят от редакции Битрикс24, структуры портала и применимых правил компании. Ниже — организационный минимум, который нужно превратить в проверяемую матрицу.

Проведите инвентаризацию данных

Сначала определите, какие категории информации есть в системе и чем опасен лишний доступ.

Рассмотрите:

• контакты и обращения;
• договорные данные;
• финансовые поля;
• кадровую информацию;
• внутренние комментарии;
• вложения;
• отчёты и выгрузки;
• учётные данные интеграций;
• настройки процессов.

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

Создайте ролевую матрицу

Матрица связывает роль, объект, действие и основание. Фамилии назначаются на роли отдельно.

Для каждой роли определите:

• какие записи можно видеть;
• какие поля доступны;
• что можно создавать и изменять;
• кто принимает решение;
• разрешены ли экспорт и удаление;
• доступны ли отчёты;
• какие настройки можно менять;
• кто подтверждает назначение.

Принцип минимально необходимых прав означает, что доступ выдаётся для конкретной задачи, а не «чтобы не мешало работать».

Разделите пользовательские и административные полномочия

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

Назначьте владельца административных доступов и порядок их пересмотра. Не используйте общую учётную запись: она не позволяет надёжно связать действие с человеком.

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

Управляйте жизненным циклом пользователя

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

Приём

Доступ выдаётся по подтверждённой роли. До начала работы проверяется только необходимый набор систем и данных.

Перевод

Старые полномочия пересматриваются, а не просто дополняются новыми. Иначе сотрудник постепенно накапливает доступы из всех прежних функций.

Замещение

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

Увольнение

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

Проверьте интеграции и приложения

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

Проверьте:

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

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

Ограничьте экспорт и внешнюю передачу

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

Отдельно проверьте публичные ссылки, формы, внешние страницы и уведомления. Например, клиентский статус-информер должен показывать минимальный разрешённый набор и не раскрывать существование чужой записи.

Тестируйте под реальными ролями

Проверка от имени администратора не обнаруживает многих ошибок доступа. Создайте безопасные тестовые сценарии для разных ролей.

Проверьте:

1. просмотр своей и чужой карточки;
2. видимость чувствительного поля;
3. изменение этапа;
4. выгрузку;
5. доступ к отчёту;
6. открытие вложения по прямой ссылке;
7. временное замещение;
8. отключённого пользователя;
9. интеграционную учётную запись;
10. мобильный интерфейс, если он используется.

Результат фиксируется как сценарий с ожидаемым и фактическим поведением.

Введите регулярный пересмотр

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

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

Чек-лист безопасности

• Категории данных и владельцы определены.
• Каждая роль имеет обоснованный набор действий.
• Административные права ограничены.
• Общие учётные записи не используются.
• При переводе старые права пересматриваются.
• Временные доступы имеют срок.
• Интеграции внесены в реестр.
• Секреты не хранятся в рабочих карточках.
• Экспорт и публичные ссылки проверены.
• Тесты выполняются под разными ролями.
• Назначен регулярный пересмотр.

Проверку доступов можно включить в аудит Битрикс24. Для новых проектов требования фиксируются в техническом задании и проверяются до общего запуска внедрения.