- B2B SaaS обрабатывает данные сотрудников клиентов — это тоже персональные данные по ФЗ-152.
- В многотенантной архитектуре данные разных клиентов должны быть изолированы на уровне хранения и доступа.
- Каждый корпоративный клиент — потенциальный источник DPA: договора поручения на обработку данных.
- Утечка через одного тенанта может затронуть данные других — это отдельный класс рисков B2B SaaS.
- Кто обязан соблюдать: B2B SaaS-платформы, корпоративные облачные сервисы, HR-системы, CRM, ERP и любые инструменты, в которых работают сотрудники клиентов
- Что грозит за нарушение: штрафы до 18 млн руб., потеря корпоративных контрактов, претензии клиентов при утечке их данных
- Что нужно сделать: проверить изоляцию тенантов, оформить DPA с клиентами, настроить права доступа и проверить локализацию
- Срок: до начала обработки данных сотрудников клиента в системе
B2B SaaS отличается от потребительских продуктов не только целевой аудиторией, но и особой структурой обработки персональных данных. Когда в вашей системе работают сотрудники десятков или сотен компаний-клиентов, каждый из этих сотрудников — субъект персональных данных. А значит, требования ФЗ-152 распространяются не только на прямых пользователей платформы, но и на всю цепочку обработки данных внутри корпоративных аккаунтов.
Если вы ещё не разобрались, почему SaaS вообще попадает под действие ФЗ-152 — начните с базового разбора для SaaS-сервисов. Эта статья — следующий уровень: для тех, кто работает по B2B-модели и хочет разобраться со спецификой многотенантной архитектуры и корпоративных договоров.
Почему данные сотрудников клиентов — это ваша ответственность
Распространённое заблуждение: «Мы работаем с юридическими лицами, а не с физическими — значит, ФЗ-152 к нам не относится». Это не так.
В любом B2B SaaS конечными пользователями являются люди: менеджеры, бухгалтеры, разработчики, HR-специалисты клиентов. Их имена, email-адреса, роли и история действий в системе — персональные данные по смыслу ст. 3 ФЗ-152. Неважно, что договор заключён с юридическим лицом.
Персональные данные — любая информация, относящаяся к прямо или косвенно определённому физическому лицу.
Статья 3, ФЗ-152На практике B2B SaaS может выступать в двух ролях одновременно:
| Роль | Когда возникает | Что требуется |
|---|---|---|
| Оператор | Собственные пользователи платформы (аккаунты, биллинг) | Политика, согласия, уведомление РКН |
| Обработчик | Данные сотрудников клиентов в их тенантах | DPA с каждым клиентом |
Путаница между этими ролями — один из главных источников юридических рисков в B2B SaaS.
Многотенантная архитектура: где возникают риски
В многотенантной архитектуре данные разных клиентов хранятся в одной инфраструктуре, но должны быть логически или физически изолированы. С точки зрения ФЗ-152 это создаёт несколько специфических рисков.
Изоляция данных тенантов
Если данные клиентов хранятся в общей базе с разграничением на уровне идентификатора тенанта, утечка на уровне архитектуры может привести к тому, что данные одного клиента окажутся доступны другому. Это нарушение сразу нескольких норм ФЗ-152 — и для платформы, и для пострадавшего клиента.
При ошибке в запросе или уязвимости в логике tenant_id сотрудник компании А может получить доступ к данным компании Б. Это не абстрактный риск — он реализовывался в крупных SaaS-продуктах. Изоляция на уровне хранения важнее, чем изоляция только на уровне UI.
Рекомендуемые подходы к изоляции:
- Физическая изоляция (отдельные базы данных на тенант) — максимальная защита, но дороже в эксплуатации
- Схема-изоляция (отдельные схемы в одной СУБД) — баланс между безопасностью и стоимостью
- Строковая изоляция (tenant_id в каждой таблице) — минимальная стоимость, но требует тщательного контроля каждого запроса
Права доступа сотрудников платформы
Разработчики, DevOps и служба поддержки вашего SaaS имеют техническую возможность получить доступ к данным любого тенанта. Это нарушение принципа минимизации доступа — каждый сотрудник должен видеть только те данные, которые необходимы для его функции.
Доступ технической поддержки к данным клиентского тенанта должен быть возможен только с явного согласия клиента, логироваться и автоматически завершаться по истечении временного окна. Постоянный «суперадмин-доступ» для всей команды — не норма, а нарушение.
DPA с корпоративными клиентами: что это и зачем нужно
Когда корпоративный клиент загружает в вашу платформу данные своих сотрудников или пользователей, он фактически поручает вам обработку персональных данных. По ст. 6 ФЗ-152 это требует договора поручения (DPA — Data Processing Agreement).
Готовый шаблон договора поручения на обработку данных и разбор обязательных условий — в статье «Шаблон DPA с подрядчиком». Там же — типичные ошибки при согласовании DPA с корпоративными клиентами.
На практике B2B SaaS часто уклоняется от оформления DPA, считая это излишней бюрократией. Но при проверке РКН или претензии клиента отсутствие DPA означает, что передача данных была без надлежащего основания.
Что должно быть в DPA для B2B SaaS:
| Блок | Содержание |
|---|---|
| Предмет | Какие категории данных и в каком объёме обрабатываются |
| Цели | Только в рамках предоставления сервиса клиенту |
| Доступ | Технические условия доступа к тенанту, в том числе для поддержки |
| Защита | Меры безопасности, сертификаты, логирование |
| Субобработчики | Облачные провайдеры, сервисы аналитики, CDN |
| Удаление | Сроки и процедура удаления данных при расторжении |
| Уведомление | Порядок информирования клиента об инцидентах |
API-интеграции как источник рисков
Большинство B2B SaaS предоставляет API для интеграции с другими системами клиента. Каждая такая интеграция — потенциальный канал передачи персональных данных, который нужно учитывать.
Типичные сценарии:
- Интеграция с CRM клиента: через API поступают контактные данные клиентов заказчика — это уже передача ПД от одного оператора к другому
- Вебхуки с событиями: события могут содержать идентификаторы пользователей, email, действия — всё это ПД
- SSO через корпоративный IdP: при входе через корпоративный Active Directory или Okta передаются данные сотрудника Для каждого из этих сценариев в DPA должно быть явно прописано: какие данные передаются, в каком направлении, с какой целью, на каком основании.
Локализация в контексте B2B SaaS
Многие B2B SaaS используют глобальную облачную инфраструктуру — AWS, GCP, Azure с дата-центрами вне России. Это создаёт риск нарушения локализации при наличии российских пользователей.
Требование простое: первичная запись данных граждан РФ должна происходить на серверах в России. Это касается не только потребительских данных, но и данных российских сотрудников корпоративных клиентов.
Практические варианты для B2B SaaS:
- Российский регион у облачного провайдера (Яндекс.Облако, VK Cloud, SberCloud) — данные российских тенантов хранятся в РФ
- Мультирегиональная архитектура — автоматическое определение страны тенанта и маршрутизация в нужный регион
- Отдельный российский кластер — выделенная инсталляция для клиентов из РФ
Детальный разбор требований к локализации, какие данные обязательно хранить в России и как это проверяет РКН — в статье «Локализация персональных данных».
Что проверять при аудите B2B SaaS
| Направление | Что проверяется |
|---|---|
| Архитектура | Механизм изоляции тенантов, права доступа команды |
| Документы | DPA с клиентами, политика, уведомление РКН |
| Инфраструктура | Регион хранения данных российских пользователей |
| API | Документирование потоков данных через API |
| Субобработчики | Список облачных провайдеров, их регион и DPA с ними |
| Инциденты | Процедура уведомления клиента при утечке в его тенанте |
Типичные ошибки B2B SaaS
- Нет DPA с корпоративными клиентами — передача данных без договорного основания.
- Поддержка имеет постоянный доступ к данным всех тенантов без логирования.
- Данные российских пользователей хранятся в дата-центрах за рубежом.
- Список субобработчиков не документирован и не раскрыт клиентам.
- API-интеграции не отражены в политике и DPA.
- При расторжении контракта данные тенанта не удаляются в установленный срок.
- Уведомление об инциденте не предусмотрено в DPA — клиент узнаёт об утечке из СМИ.
- Определены роли платформы (оператор / обработчик) для каждого сценарияобязательно
- Оформлены DPA с корпоративными клиентами, передающими данные своих сотрудниковобязательно
- Реализована изоляция данных тенантов на уровне хранения или схемобязательно
- Данные российских пользователей хранятся на серверах в РФобязательно
- Доступ технической поддержки к тенантам логируется и ограничен по времениобязательно
- Задокументированы все API-интеграции и потоки данных через них
- Список субобработчиков актуален и раскрыт в DPA
- Есть процедура удаления данных тенанта при расторжении контракта
- Предусмотрено уведомление клиента об инциденте с его данными
Частые вопросы о ФЗ-152 для B2B SaaS
Не уверены, как выстроен контроль данных тенантов в вашем B2B SaaS?
Проведём аудит архитектуры обработки данных, проверим DPA с клиентами и локализацию. Поможем выстроить соответствие, которое не тормозит продажи корпоративным клиентам.
Получить аудит