Автоматизация ИБ без ручного контроля: модуль «Правила» в BearPass
Типичная ситуация в компании: сотрудник уволился, а его доступы ещё активны. Проектный менеджер случайно расшарил папку клиента всем подряд. Инженер опечатался в названии записи, и интеграция сломалась. Во всех этих случаях ИБ-специалист узнаёт о проблеме постфактум — когда ущерб уже нанесён.
Модуль «Правила» в BearPass решает именно эту задачу: он позволяет настроить автоматические реакции на события в системе — без написания кода, без постоянного мониторинга вручную. Система либо уведомит нужных людей, либо сразу заблокирует нежелательное действие.
Разбираем, как это работает и для каких задач подходит.
Что такое модуль «Правила» и как он устроен
Правило в BearPass — это конструкция из трёх частей: событие → условия → действие.
Событие — это то, что происходит в системе и запускает проверку. Доступны следующие типы событий:
- создание элемента,
- обновление элемента,
- перемещение в корзину и удаление из корзины,
- просмотр пароля,
- обновление права доступа к элементу,
- авторизация пользователя.
Условия — логическая цепочка проверок, которая определяет, должно ли правило сработать именно сейчас. Например: «событие совершил пользователь не с ролью admin» И «название элемента содержит слово "Секретно"». Условия можно комбинировать через операторы «И» / «ИЛИ» и группировать в вложенные блоки для сложной логики.
Действие — то, что система выполнит при совпадении условий. Доступны два варианта: отправить почтовое уведомление или запретить действие с показом сообщения пользователю.
Все правила управляются через административный раздел — пункт меню «Правила». Каждое правило можно активировать или деактивировать, не удаляя его.
Как строить условия: операторы и группы
Конструктор условий работает по принципу визуального построителя логики. Вы добавляете условия и группы кнопками — никакого кода.
Одиночное условие — проверяет один параметр. Например: «Email пользователя содержит @yandex.ru» или «Название элемента начинается с "DEV_"».
Группа условий — объединяет несколько условий под одним оператором. Группы можно вкладывать друг в друга для построения сложной логики. Например: проверить, что пользователь не администратор И при этом либо элемент находится в корневой папке, либо его название содержит «Секретно».
Доступные операторы для строковых параметров: «содержит», «не содержит», «равно», «не равно», «начинается с», «заканчивается на», а также «совпадает с шаблоном» и «не совпадает с шаблоном» — для тех, кто хочет использовать регулярные выражения.
Важный нюанс: операторы типа «содержит» работают с учётом регистра. То есть условие «содержит Финанс» не сработает для «финансовые показатели». Если нужна регистронезависимая проверка — используйте регулярное выражение с флагом (?i).
Переменные в уведомлениях
В текстах уведомлений и писем можно использовать переменные — специальные коды, которые система автоматически заменяет реальными данными в момент срабатывания. Например, %user.name% подставит имя пользователя, %item.name% — название элемента.
Список доступных переменных зависит от типа события и отображается прямо в интерфейсе при составлении уведомления. Достаточно навести курсор на нужную переменную, чтобы скопировать её код.
Это позволяет делать уведомления информативными: вместо сухого «Выполнено запрещённое действие» администратор получает письмо с именем сотрудника, названием элемента, временем события.
Четыре реальных кейса из практики
Ниже — задачи, с которыми реальные клиенты обращались в поддержку BearPass, и как они решаются через модуль «Правила».
1. Запретить менеджерам расшаривать корневые папки клиентов
Задача. Каждый клиент — отдельная папка в корне BearPass. Проектный менеджер управляет своей папкой, но иногда случайно расшаривает её целиком всем сотрудникам подряд.
Решение. Создаём правило на событие «Обновление права доступа к элементу» с условиями:
- Код роли пользователя не равно admin,
- Глубина элемента равна 0 (то есть элемент находится в корневой папке).
Действие — «Запретить действие» с текстом уведомления: «Выдача прав доступа к корневым папкам заблокирована. Обратитесь к администратору.»
Теперь менеджеры могут свободно расшаривать содержимое внутри своих папок, но не могут трогать саму корневую папку.
2. Уведомление при входе сервисного аккаунта
Задача. Один сервисный аккаунт используют несколько сотрудников. Нужно фиксировать каждую авторизацию этого аккаунта.
Решение. Правило на событие «Авторизация пользователя» с условием: «Email пользователя равно service@company.ru».
Действие — «Отправить почтовое уведомление» на адрес ИБ-отдела. В тексте письма используем переменные: %user.email% авторизовался %event.datetime%.
Теперь каждый вход этого аккаунта автоматически фиксируется письмом. Никаких ручных проверок журнала.
3. Контроль доступа к конкретному паролю
Задача. Нужно знать, когда кто-то просматривает, изменяет пароль или получает к нему права доступа.
Решение. Три правила на разные события — «Просмотр пароля», «Обновление элемента», «Обновление права доступа» — с одним и тем же условием: «Название элемента содержит [название сервиса]».
Для каждого правила действие — уведомление на почту ответственного. В письме — кто именно и что сделал, с переменными %user.name% и %item.name%.
Таким образом, вокруг чувствительного пароля выстраивается автоматическая «охрана» без постоянного мониторинга журнала вручную.
4. Проверка соответствия названий паролей шаблону
Задача. Интеграции работают только если названия записей соответствуют определённому формату. Десяток инженеров регулярно вбивают записи вручную — опечатки неизбежны.
Решение. Правило на событие «Создание элемента» и «Обновление элемента» с условием: «Название элемента не совпадает с шаблоном» — и здесь используется регулярное выражение, описывающее допустимый формат названия.
Действие — «Запретить действие» с текстом: «Название записи не соответствует принятому формату. Проверьте шаблон: DEV_[название]_[среда].»
Инженер не сможет сохранить запись с некорректным именем. Интеграции больше не ломаются из-за человеческой ошибки.
Когда модуль «Правила» особенно полезен
Модуль не заменяет RBAC и журнал событий — он дополняет их. Там, где роль разрешает действие в принципе, но в конкретном контексте оно нежелательно, правила добавляют ещё один уровень контроля.
Несколько сценариев, где он даёт максимальный эффект:
Сервисные аккаунты с широким доступом, которые используют несколько сотрудников — правила позволяют отслеживать каждое использование без ручного аудита.
Критически важные пароли (production-серверы, облачные учётки, платёжные системы) — правила мгновенно уведомляют ответственного при любом взаимодействии.
Разграничение зон ответственности между командами — когда нужно не просто разграничить права ролью, но и запретить конкретные операции в определённом контексте.
Команды с высокой текучкой или внешними подрядчиками — правила помогают контролировать действия без расширения прав администратора для каждого нового участника.
Как начать
Модуль доступен в административном разделе BearPass под пунктом меню «Правила» — при условии, что ваша роль имеет доступ к этому функционалу. Если пункт меню не отображается, обратитесь к администратору системы.
Для начала удобнее всего взять один из кейсов выше и воспроизвести его в своей системе — конструктор интуитивный, первое рабочее правило настраивается за несколько минут.
Если у вас есть задача, которую вы не можете решить стандартными ролями и правами, напишите в поддержку BearPass — возможно, именно ваш кейс войдёт в следующую версию документации по модулю.
