Бизнес всё активнее автоматизирует процессы с помощью BPM‑систем: согласование договоров, обслуживание клиентов, управление закупками, кадровые процессы и многое другое. Но вместе с ростом удобства и прозрачности появляется и новая зона риска — информационная безопасность.
Ниже — практическая статья для Дзена: что именно учесть при внедрении BPM‑системы, чтобы не получить утечки данных, простои и претензии регуляторов.
Зачем вообще думать о безопасности BPM‑системы
BPM‑платформа становится точкой, через которую проходят:
- персональные данные клиентов и сотрудников;
- коммерческая тайна;
- финансовые показатели и договоры;
- внутренние регламенты и управленческие решения.
И фактически превращается в единый «нервный центр» компании. Любой сбой или компрометация такой системы — это:
- риски утечки данных;
- остановка ключевых процессов (продажи, выплаты, закупки);
- штрафы регуляторов и удар по репутации.
Поэтому при внедрении BPM‑системы важно сразу закладывать безопасность в архитектуру, а не пытаться «прикрутить» её потом.
1. С чего начать: понять, какие данные вы доверяете системе
Перед стартом проекта стоит ответить на несколько простых, но очень важных вопросов:
1. Какие данные будут обрабатываться в BPM‑системе?
- Персональные данные (ПДн) — сотрудников, клиентов, партнёров;
- финансовая информация — счета, платежи, бюджеты;
- договоры и юридически значимые документы;
- данные о производстве, логистике, внутренней аналитике.
2. Насколько критична их утечка или потеря?
- Что будет, если система встанет на 2–4 часа?
- А если данные будут повреждены или удалены?
- А если доступ к ним получат посторонние?
От ответов зависит:
- выбор архитектуры (локально, облако или гибрид);
- набор требований по защите данных и соответствию законам (152‑ФЗ, GDPR и др.);
- правила разграничения доступа.
2. Подключать безопасность нужно до «старта», а не «под конец»
Самая частая ошибка — «зовём безопасность, когда всё почти готово». В итоге:
- приходится менять архитектуру;
- переписывать интеграции;
- откладывать запуск и увеличивать бюджет.
Правильный подход:
- подключить специалистов по ИБ и IT‑инфраструктуре ещё на этапе планирования;
- вместе с ними определить требования:где будут храниться данные;
какие средства защиты нужны;
как будут разграничены права доступа;
какие журналы и логи необходимо вести.
3. Архитектура: локально, в облаке или гибрид
Сегодня есть три основных варианта размещения BPM‑системы.
Локальное размещение (on‑premise)
Система установлена в инфраструктуре самой компании.
Подходит, если:
- жёсткие требования регуляторов;
- чувствительные персональные данные;
- закрытый периметр (например, госсектор, финансы, медицина).
Что важно:
- сегментировать сеть (отдельный контур для BPM);
- ограничить доступ к серверам и БД;
- обеспечить резервирование (кластер, резервные сервера, бэкапы).
Облачное размещение
Система размещена у провайдера (SaaS/IaaS).
Плюсы:
- быстрое развертывание;
- лёгкая масштабируемость;
- отсутствие затрат на «железо».
Но важно проверить:
- где физически находятся дата‑центры;
- есть ли сертификации и соблюдение требований по защите данных;
- как разделены данные разных клиентов;
- как шифруются данные в хранилище и при передаче.
Гибридная схема
Часть компонентов — в облаке, чувствительные данные — в локальном контуре.
Это гибкий подход, но он требует:
- защищённых каналов связи между контурами;
- продуманной схемы интеграций;
- чётких регламентов, какие данные где могут храниться.
4. Управление доступом: кто и что видит в системе
Ролевая модель
В BPM‑системах обычно развита ролевая модель. Главное — не свести её к хаосу.
Лучшие практики:
- Строить права по ролям, а не по конкретным людям:
«менеджер по продажам», «руководитель отдела», «юрист», «администратор». - Использовать принцип минимально необходимого доступа:
у каждого пользователя есть только те права, которые реально нужны. - Разделять роли:бизнес‑пользователи (работают с задачами);
администраторы приложений;
администраторы инфраструктуры;
безопасники/аудиторы.
Опасная ситуация: когда один человек и разворачивает систему, и разрабатывает процессы, и администрирует, и имеет полный доступ ко всем данным.
Интеграция с корпоративным каталогом
Лучший вариант — связать BPM‑систему с корпоративным AD/LDAP или другой системой управления учётными записями:
- единый логин и пароль;
- автоматическое отключение доступа при увольнении;
- применение общих политик паролей.
Для критичных ролей (администраторы, разработчики процессов, руководители с доступом к чувствительным данным) обязательно стоит включить двухфакторную аутентификацию (MFA).
5. Защита данных: шифрование и работа с копиями
Шифрование
- На уровне хранения (диски, базы данных, бэкапы):
особенно важно, если есть риск физического доступа к носителям или данные размещены в облаке. - На уровне передачи:
только защищённые протоколы (HTTPS/TLS) для веб‑доступа и API.
Тестовые среды и обезличивание
Очень частая и очень опасная практика — копировать боевую базу «как есть» в тестовую:
- там уровни защиты ниже;
- доступ имеют разработчики и подрядчики;
- часто тесты «живут» на менее защищённых серверах.
Правильный подход:
- либо совсем не использовать реальные ПДн в тесте;
- либо применять маскирование и обезличивание данных.
6. Интеграции: самая слабая цепочка
BPM‑система почти всегда связана с другими:
- CRM, ERP, склад, бухгалтерия;
- кадровые системы;
- файловые хранилища, электронный документооборот;
- внешние сервисы (банки, госуслуги, партнёры).
Типичные проблемы:
- «универсальные» учётки с полными правами;
- открытые API без ограничений по IP;
- пароли и ключи в конфигурационных файлах в открытом виде;
- нешифрованный трафик между системами.
Что делать:
- для каждой интеграции — отдельная сервисная учётная запись с минимальными правами;
- доступ по API — только по защищённым каналам, с ограничением по IP/диапазонам;
- ключи и пароли хранить в специализированных хранилищах (vault‑решения);
- включить журналирование всех интеграционных вызовов.
7. Логи, аудит и мониторинг
Без логов невозможно:
- расследовать инциденты;
- доказать, что «мы ни при чём»;
- понять, кто и какие данные менял или выгружал.
Что желательно логировать:
- авторизации пользователей (успешные и неуспешные);
- изменения прав и ролей;
- изменения в настройках процессов и конфигурации;
- создание, изменение и удаление критичной информации;
- действия администраторов и интеграционных сервисов.
Хороший уровень зрелости — когда:
- логи централизованно собираются;
- интегрируются с SIEM или аналогичной системой;
- настроены оповещения по аномалиям (подбор пароля, массовые выгрузки, резкие изменения прав доступа).
8. Как внедрять изменения безопасно: DEV–TEST–PROD
BPM‑система — живой организм: процессы постоянно дорабатываются, добавляются новые сценарии.
Чтобы не «сломать» боевую среду и не открыть новые уязвимости:
- разделите контуры:DEV — разработка;
TEST — тестирование;
PROD — боевая эксплуатация. - установите процедуру:разработка и ревью (желательно с участием ИБ при чувствительных изменениях);
тестирование функциональности и производительности;
тестирование безопасности для критичных процессов;
формализованное согласование и только потом — перенос в PROD.
Особенно важно контролировать:
- изменения, влияющие на права доступа;
- интеграции с внешними системами;
- работу с персональными и финансовыми данными.
9. Люди — главный фактор риска
Даже идеальная система не спасёт, если:
- пароль администратора записан на стикере;
- доступы пересылают в мессенджере;
- данные выгружают в личные облака «для удобства».
Внедрение BPM‑системы — хороший момент, чтобы:
- провести обучающие сессии по безопасной работе:что можно выгружать, а что нет;
как работать с документами;
почему нельзя передавать логины и пароли. - обновить внутренние политики:правила доступа к системе;
ответственность за нарушения;
порядок действий при подозрении на инцидент.
10. Законы и регуляторы: о чём нельзя забывать
Если через BPM‑систему проходят персональные или иные чувствительные данные, нужно учитывать:
- национальное законодательство по защите ПДн;
- возможные требования по защите критической инфраструктуры;
- отраслевые нормативы (банки, медицина, госсектор и т.п.).
Важные моменты:
- местоположение серверов и дата‑центров;
- наличие сертифицированных средств защиты (если требуется);
- регламенты по хранению, обработке и уничтожению данных;
- срок и формат уведомления регуляторов при инцидентах.
Такой подход позволяет внедрить BPM‑систему не только как удобный инструмент автоматизации, но и как устойчивую, контролируемую и безопасную платформу для управления бизнесом.
Читайте, если вам близка автоматизация без иллюзий.
Low-code, BPM, гибкие подходы и честные истории изнутри проектов.