152-ФЗ и безопасность
Практическое руководство: кто в какой роли выступает при работе с платформой, какие меры включены по умолчанию и что нужно подготовить перед промышленной эксплуатацией.
Роли в обработке персональных данных
| Сценарий | Оператор ПДн | Обработчик | Что это значит |
|---|---|---|---|
| Облако MindRoot.ru | Ваша организация | MindRoot.ru — по поручению (ст. 6 ч. 3) | Нужно соглашение о поручении на обработку; перечень действий и цели фиксируются в договоре |
| On-premise в вашем контуре | Ваша организация | Отсутствует — данных мы не получаем | Платформа передаётся как ПО, лицензия и обновления без доступа к данным |
| SaaS-коннекторы (CRM, 1С, ЭДО) | Ваша организация | Провайдер соответствующего сервиса | Плагин — лишь технический транспорт: не хранит и не кэширует содержимое документов, кроме метаданных сессии |
Меры, включённые по умолчанию
| Требование 152-ФЗ / практика | Как реализовано |
|---|---|
| Хранение данных на территории РФ (ч. 5 ст. 18) | Продовые контуры — Yandex Cloud, VK Cloud, Selectel; зарубежные регионы и CDN в пути ПДн не используются |
| Шифрование при передаче | TLS 1.3, отключены устаревшие шифры; внутренний трафик между сервисами также шифруется |
| Шифрование в покое | Диски и объектные хранилища шифруются; на тарифе «Бизнес» — ключами клиента (BYOK/KMS) |
| Минимизация данных | Каждый плагин декларирует compliance.pii_fields;
конструктор предупреждает, если маскирование отключено |
| Разграничение доступа | RBAC: наблюдатель / оператор / администратор; агент получает только включённые в его политику команды |
| Доказательная база действий | Аудит-журнал: команда, аргументы, результат, инициатор, время; выгрузка в SIEM клиента по API |
| Контроль изменяющих операций | Запись в CRM/1С/ЭДО по умолчанию требует подтверждения пользователя; суточные лимиты записей |
| Сроки хранения | Настраиваются в конструкторе (по умолчанию 90 дней); рекомендуется не хранить логи с ПДн дольше 180 дней |
| Изолированные контуры | Отдельный VPC на клиента, сетевые политики, отсутствие доступа агента к сети за пределами разрешённых адресов |
Пакет документов
Для тарифов «Бизнес» и «On-premise» предоставляются:
- Политика обработки персональных данных платформы и перечень мер защиты.
- Соглашение о поручении на обработку ПДн (шаблон для вашего юриста).
- Модель угроз и описание архитектуры с точками обработки ПДн.
- Реестр обработки: категории субъектов, перечень данных, цели, сроки хранения — заполняется по вашим сценариям с помощью конструктора.
- Уведомление в РКН (шаблон) и памятка о необходимости уведомления об обработке ПДн.
- Описание процесса реагирования на инциденты и уведомления РКН в течение 24 часов (ч. 3.1 ст. 21).
Юридические документы мы предоставляем как технические шаблоны
и не заменяем заключение юриста. Ответственность оператора ПДн остаётся
на вашей организации.
Чеклист перед промышленной эксплуатацией
- Определите перечень ПДн, которые будут проходить через агента, и внесите их в реестр обработки.
- Включите маскирование ПДн в конструкторе и проверьте, что оно работает в тестовом диалоге (телефоны и e-mail должны отображаться частично).
- Настройте срок хранения логов и канал их выгрузки (SIEM или архив).
- Создайте отдельные сервисные учётные записи в 1С, CRM и ЭДО с правами только на необходимые объекты (принцип минимальных привилегий).
- Для регулируемых отраслей (банки, медицина, госсектор) выберите on-premise развёртывание в изолированной сети.
- Проведите внутренний аудит сценариев: у каждого агента должен быть минимальный набор команд и подтверждение изменяющих операций.
- Зафиксируйте ответственных за эксплуатацию и порядок отзыва API-ключей.
Изоляция арендаторов и шифрование данных
Данные разных клиентов не смешиваются ни в API, ни на диске:
| Что защищаем | Как это сделано |
|---|---|
| Разделение клиентов | Каждый контур, секрет и запись журнала принадлежат организации. Чужие контуры не видны в списках и отвечают «не найдено» — существование объекта не подтверждается посторонним |
| Доступ сотрудников | Пять ролей с фиксированными правами; проверка на каждом вызове, включая страницы контуров; все действия пишутся в журнал организации |
| Секреты интеграций | На диске только шифротекст: ключ контура выводится из ключа организации
(HKDF-SHA256), шифр — AES-256-GCM. Ключи — 0600 в
data/accounts/keys/, каталог 0700 |
| Ротация | Смена ключа организации перешифровывает секреты всех её контуров; старый ключ после ротации не подходит |
| Пароли и ключи доступа | Пароли — PBKDF2-SHA256 (120 000 итераций, соль на пользователя); API-ключи хранятся как SHA-256, значение показывается один раз |
| Программный доступ | Ключ выдаётся с ролью (например, «оператор»), его можно отозвать в любой момент; отзыв действует немедленно |
Практический смысл для 152-ФЗ: персональные данные клиента лежат в его контуре
и зашифрованы ключом его организации — ключи разных клиентов не взаимозаменяемы,
а действия сотрудников фиксируются в журнале с указанием роли.
Безопасность платформы
- Регулярный аудит зависимостей и сканирование образов контейнеров.
- Секреты интеграций — только в защищённом хранилище (Vault/KMS), не в переменных окружения в открытом виде и не в образах.
- Проверка плагинов из маркетплейса до публикации: разрешения, обращения к сети, работа с ПДн, отсутствие «серых» каналов передачи данных.
- Тестирование на проникновение перед выводом крупных контуров в эксплуатацию.
- Резервное копирование конфигураций и журналов с проверкой восстановления.