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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приём

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

Перевод

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

Замещение

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

Увольнение

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

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

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

Проверьте:

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

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

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

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

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

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

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

Проверьте:

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

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

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

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

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

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

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

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