Open source альтернативы SaaS

К середине 2025 года большинство российских IT-команд прошли первый этап замещения: сменили американские и европейские SaaS-платформы на self-hosted решения — Nextcloud вместо Google Workspace, Mattermost вместо Slack, Gitlab CE вместо GitHub, Metabase вместо Looker. Проблема в том, что регуляторная логика при этом не изменилась. Когда обработка ПДн была в чужом облаке, оператором нередко оставался вендор — компания лишь передавала данные по поручению. Теперь компания развернула платформу у себя, стала оператором, но не всегда оформила это юридически и технически. Ниже — анализ того, как open source альтернативы SaaS вписываются в требования 152-ФЗ, Приказа ФСТЭК №21 и ПП РФ №1119, а также где возникают нарушения, которые РКН фиксирует при проверках.

Как определить уровень защищённости (УЗ) для self-hosted платформы?

Уровень защищённости ИСПДн определяется по трём параметрам из ПП РФ №1119: категория данных (специальные, биометрические, общедоступные, иные), тип актуальных угроз (1, 2 или 3) и число субъектов — порог 100 000 человек.

Типовые случаи для open source инфраструктуры:

• Корпоративный мессенджер (Mattermost, Rocket.Chat) с данными сотрудников — иные ПДн, угрозы 3-го типа, до 100 000 субъектов — УЗ-4. Достаточно организационных мер и базового набора ФСТЭК.
• HR-платформа (Seafile, Nextcloud) с медицинскими данными или данными о судимостях — специальные категории, угрозы 2-го типа — УЗ-2. Требуются средства защиты информации (СЗИ) с сертификатом ФСТЭК.
• ML-платформа (Jupyter, MLflow) на данных о физических лицах более 100 000 — даже иные ПДн при угрозах 2-го типа дают УЗ-2.
• Биометрическая идентификация (СКУД на OpenCV + FaceNet) — УЗ-1. Самые жёсткие требования: защита от НСД, аттестация, регламент доступа.

Практическая ошибка: многие команды при миграции с SaaS не проводят классификацию ИСПДн заново. Категория данных и количество субъектов в self-hosted системе могут быть выше, чем в облачном сервисе, — потому что теперь в одной базе агрегируются данные из нескольких источников.

Какие меры ФСТЭК обязательны для open source ИСПДн?

Приказ ФСТЭК №21 от 18.02.2013 определяет состав мер защиты в 15 функциональных группах. Для каждого УЗ есть базовый набор — перечень мер, которые оператор обязан реализовать. Для УЗ-3 и УЗ-4 часть мер может быть компенсирована организационными решениями; для УЗ-1 и УЗ-2 — нет.

Применительно к self-hosted open source критичны следующие группы:

• ИАФ (идентификация и аутентификация): обязательна двухфакторная аутентификация для привилегированных пользователей. Большинство open source платформ поддерживают TOTP или LDAP с 2FA — но его нужно включить и задокументировать.
• УПД (управление правами доступа): ролевая модель, принцип минимальных привилегий. В GitLab CE, Nextcloud, Mattermost она есть — требует настройки под конкретные роли компании.
• РСБ (регистрация событий безопасности): логирование доступа к ПДн. Это отдельный вопрос — ниже.
• АВЗ (антивирусная защита): для УЗ-2 и выше — только сертифицированное ФСТЭК ПО (например, Dr.Web для файловых серверов).
• ЗНИ (защита носителей информации): шифрование дисков на серверах с ПДн. Open source инструменты (LUKS, VeraCrypt) принимаются, но для УЗ-1 нужно сертифицированное СКЗИ.
• ЗИС (защита информационной системы): сегментация сети, межсетевое экранирование. Iptables или nftables не являются сертифицированными МЭ — для УЗ-2 и выше нужен аттестованный МЭ.

Частая проблема при самостоятельном развёртывании open source: команда реализует технические меры, но не документирует их. Отсутствие документации о составе мер защиты — самостоятельное нарушение при проверке РКН, даже если меры фактически применены.

Логирование как ПДн: что нужно знать CTO?

Лог-файлы системы часто содержат данные, подпадающие под определение ПДн: IP-адреса, идентификаторы сессий, связанные с конкретным пользователем, временные метки действий с именем пользователя. С позиции РКН совокупность таких записей — ПДн, обработка которых требует правового основания по ст. 6 ФЗ-152.

Для логирования как меры РСБ по Приказу ФСТЭК №21 это создаёт юридически парадоксальную ситуацию: мера защиты, которую оператор обязан применить, сама является обработкой ПДн. Выход — закрепить обработку логов в политике конфиденциальности как самостоятельную цель, обеспечить соответствующий срок хранения и ограничить доступ к логам только администраторам безопасности.

Практические требования к журналам событий в ИСПДн:

• Хранить журналы в защищённой системе, отдельной от основной ИСПДн (или в изолированном разделе).
• Обеспечить целостность записей — защиту от изменения и удаления (append-only хранилище или WORM-раздел).
• Определить срок хранения в ОРД — как правило, не менее 1 года для УЗ-2 и выше.
• Ограничить доступ к логам ролевой моделью: только роль «аудитор безопасности».

Обезличивание для ML: когда open source данные становятся безопасными?

Многие компании используют open source ML-платформы (MLflow, DVC, Airflow) для обучения моделей на данных о пользователях — рекомендательные системы, антифрод, скоринг. Ключевой вопрос: является ли датасет для обучения обработкой ПДн?

Ответ РКН однозначен: до момента обезличивания — является. Обезличивание по методам, утверждённым приказом РКН, прекращает статус ПДн для конкретного набора данных. После этого ML-модель, обученная на таких данных, не считается создателем новых ПДн.

Приказ РКН об обезличивании устанавливает 5 методов, применимых в разных сценариях:

• Введение идентификаторов — замена прямых идентификаторов (ФИО, телефон) на псевдонимы. Применимо к табличным датасетам. Обратима при наличии таблицы соответствий — хранить её отдельно с ограниченным доступом.
• Изменение состава и семантики — удаление или модификация атрибутов, позволяющих идентифицировать субъекта. Для текстовых данных (чаты, обращения в поддержку) — NER-маскирование именованных сущностей.
• Декомпозиция — разбивка набора атрибутов по разным хранилищам без возможности связать их без специального ключа.
• Перемешивание — изменение порядка записей, нарушающее связь между строками из разных таблиц.
• Обобщение (агрегация) — замена точных значений диапазонами или агрегатами. Возраст 34 года → «30–40 лет».

Для CTO важно: обезличивание должно применяться до начала обучения модели, а не после. Постфактическое обезличивание готового датасета часто невозможно технически (данные уже в весах модели), но не освобождает от ответственности за период обработки до обезличивания.

Кто оператор в мультиарендной SaaS на open source?

Мультиарендность (multitenancy) в self-hosted SaaS создаёт неочевидное распределение ответственности. Компания развернула GitLab CE или Nextcloud, предоставляет доступ нескольким клиентам — каждый из которых хранит свои данные в отдельном пространстве. Кто оператор — платформа или клиент?

По ст. 3 и ст. 6 ФЗ-152: оператор — тот, кто определяет цели и состав обработки ПДн. В мультиарендной модели клиент определяет цели для своих данных, но платформа технически обрабатывает эти данные (хранит, передаёт, резервирует). Это классическая конструкция «обработчик по поручению» из п. 3 ст. 6 ФЗ-152.

Без договора поручения обработки (DPA) компания-оператор платформы несёт самостоятельную ответственность за обработку ПДн клиентов своих арендаторов. При проверке РКН отсутствие DPA с каждым арендатором — нарушение п. 3 ст. 6 ФЗ-152.

Обязательные элементы договора поручения обработки при SaaS-мультиарендности:

• Перечень действий с ПДн, которые платформа вправе совершать (хранение, резервное копирование, передача в дата-центр).
• Цели обработки — строго в рамках целей клиента-арендатора.
• Обязанность платформы соблюдать конфиденциальность и применять меры защиты по ст. 19 ФЗ-152.
• Запрет обрабатывать ПДн в иных целях без отдельного согласования.
• Порядок уничтожения ПДн при расторжении договора аренды.

Облако в РФ: что означает локализация для self-hosted платформ?

Ч. 5 ст. 18 ФЗ-152 требует, чтобы первичная запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан России осуществлялись в базах данных, физически расположенных в России. Это требование не зависит от того, используется ли проприетарный SaaS или open source решение.

С 01.07.2025 (поправки, уточняющие понятие «база данных на территории РФ») трактовка нормы стала строже: первичная обработка должна происходить именно в РФ. Это означает, что даже резервные копии, синхронизируемые с зарубежным облаком, могут создавать нарушение локализации при определённых конфигурациях.

Типовые риски для self-hosted open source:

• Репозиторий GitLab CE на серверах в РФ, но CI/CD-агенты на GitHub Actions (иностранный сервер) — передача кода с ПДн в логах в иностранную инфраструктуру.
• Nextcloud в РФ с функцией External Storage, подключённой к AWS S3 Frankfurt — хранение за рубежом.
• Metabase в РФ с источником данных в облачном Snowflake (EU-регион) — первичное извлечение за пределами РФ.

Штраф за нарушение локализации — ч. 8 ст. 13.11 КоАП: 1 000 000–6 000 000 ₽. При повторном нарушении (ч. 9) — 6 000 000–18 000 000 ₽.

Практика: как эти риски проявляются в реальных проектах

Кейс 1. IT-компания в Сибирском ФО (осень 2025) перевела внутренние HR и аналитические системы с Workday и Tableau на self-hosted Odoo CE и Metabase. Через 4 месяца после миграции произошла утечка через незащищённый API Metabase: данные о 14 000 сотрудников (ФИО, табельные номера, зарплатные диапазоны) стали доступны внешнему запросу без аутентификации. Классификация ИСПДн по ПП РФ №1119 проведена не была, СЗИ по Приказу ФСТЭК №21 не внедрены. РКН возбудил дело по ч. 13 ст. 13.11 КоАП (утечка 10 000–100 000 субъектов). Штраф — в диапазоне 5–10 млн ₽; технический директор дополнительно фигурирует в проверке по ст. 272.1 УК РФ.

Кейс 2. Финтех-компания в Центральном ФО (начало 2026) использовала open source MLflow для обучения антифрод-модели на транзакционных данных 200 000 клиентов. Датасет содержал ФИО, номера карт (усечённые), временные метки и суммы. Обезличивание применено не было. По результатам внутреннего аудита (инициированного новым CTO) компания самостоятельно уведомила РКН, до начала внешней проверки провела DPIA и внедрила метод введения идентификаторов. Это позволило избежать возбуждения дела по ч. 2 ст. 13.11 КоАП: РКН ограничился предписанием об устранении нарушений.

Услуги DATUM по теме

• Аудит соответствия 152-ФЗ — классификация ИСПДн, анализ мер ФСТЭК, отчёт с приоритетами.
• DPIA (оценка воздействия) — для ML-пайплайнов, мультиарендных платформ, трансграничных конфигураций.
• Комплект ОРД под ключ — политика, приказы, DPA с подрядчиками, регламент логирования.

Частые вопросы

1. Какой УЗ выбрать для SaaS?

УЗ определяется по матрице ПП РФ №1119: категория ПДн (специальные, биометрические, иные, общедоступные), тип актуальных угроз (1–3) и число субъектов (до 100 000 или более). Для большинства корпоративных платформ с данными сотрудников — УЗ-3 или УЗ-4. Для систем с медицинскими данными или биометрией — УЗ-2 или УЗ-1. Самостоятельно определить УЗ без модели угроз невозможно: оператор должен либо разработать модель угроз сам (по методике ФСТЭК), либо привлечь лицензиата. Ошибочно выбранный УЗ влечёт применение недостаточного набора мер защиты — нарушение ст. 19 ФЗ-152.

2. Можно ли использовать иностранные облака?

Первичная запись, хранение и систематизация ПДн граждан РФ должны осуществляться в базах данных на территории России (ч. 5 ст. 18 ФЗ-152). Использование иностранных облаков (AWS, GCP, Azure) для хранения первичных данных — нарушение локализации. Штраф по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽, при повторном нарушении — 6–18 млн ₽. Трансграничная передача после первичной обработки в РФ допустима при уведомлении РКН по ст. 12 ФЗ-152 и выполнении требований к стране-получателю.

3. Что такое обезличивание для ML?

Обезличивание — приведение ПДн в форму, при которой невозможно определить принадлежность данных конкретному субъекту без дополнительной информации (ст. 3 ФЗ-152). После обезличивания по методам, утверждённым приказом РКН, набор данных перестаёт быть ПДн и может обрабатываться без ограничений 152-ФЗ. Для ML-датасетов применяются методы введения идентификаторов (псевдонимизация), изменения состава и семантики (NER-маскирование), а также обобщения (замена точных значений диапазонами). Обезличивание должно применяться до начала обучения модели.

4. Кто оператор в мультиарендной SaaS?

В мультиарендной SaaS оператором является клиент-арендатор: он определяет цели обработки своих данных. Компания-платформа выступает обработчиком по поручению (п. 3 ст. 6 ФЗ-152) и обязана заключить договор поручения (DPA) с каждым арендатором. Без DPA платформа несёт самостоятельную ответственность оператора за обработку данных арендаторов. Это особенно критично для платформ с арендаторами из разных отраслей — медицины, финтеха, HR, где категории ПДн и требования к защите различаются.

5. Какие СЗИ обязательны?

Конкретный состав сертифицированных средств защиты информации (СЗИ) определяется Приказом ФСТЭК №21 в зависимости от УЗ. Для УЗ-4 — можно обойтись несертифицированными решениями при обосновании; для УЗ-3 — часть мер требует сертифицированных инструментов; для УЗ-1 и УЗ-2 — антивирусы, МЭ, СКЗИ и средства контроля НСД должны иметь действующий сертификат ФСТЭК или ФСБ. Open source инструменты (ClamAV, iptables, LUKS) для УЗ-1 и УЗ-2 не принимаются как замена сертифицированным СЗИ.

Итог

Переход на open source альтернативы SaaS меняет техническую архитектуру, но не снижает регуляторную нагрузку — в большинстве случаев увеличивает её. Компания из клиента чужого облака превращается в полноценного оператора ИСПДн с обязательствами по классификации систем, внедрению мер ФСТЭК, оформлению поручений обработки и соблюдению требований локализации.

Практика DATUM показывает: наиболее частые нарушения при миграции с SaaS — отсутствие акта классификации ИСПДн, незадокументированный состав мер защиты и отсутствие DPA с субарендаторами и дата-центрами. Эти нарушения выявляются в первые часы плановой проверки РКН. DATUM сопровождает IT-компании на всех этапах: от классификации систем и разработки модели угроз до подготовки полного ОРД-пакета и представления интересов при проверке.