SSO и федеративная аутентификация

SSO-решения упрощают жизнь пользователям, но умножают правовые риски для CTO. Один провайдер идентичности собирает в одном месте данные всех субъектов — сотрудников, клиентов, партнёров. При утечке из IdP количество затронутых субъектов определяет, по какой части ст. 13.11 КоАП будет выписан штраф: от 3 млн ₽ (ч. 12, от 1 000 субъектов) до оборотного (ч. 15, повторно). С 30.05.2025 нормы ФЗ-420 действуют в полном объёме. Ниже — разбор архитектурных решений в связке с требованиями ФЗ-152, ПП РФ № 1119, Приказа ФСТЭК № 21 и требований к локализации.

Что меняет SSO с точки зрения 152-ФЗ?

В классической схеме каждое приложение самостоятельно аутентифицирует пользователя и хранит его учётные данные. При переходе на SSO появляется выделенный IdP, который централизует обработку: принимает запрос на аутентификацию, верифицирует субъекта, выдаёт токен (SAML assertion, JWT, OIDC id_token) и передаёт атрибуты в целевые системы (Service Provider, SP). С позиции ст. 3 ФЗ-152 IdP обрабатывает персональные данные: собирает, хранит, передаёт идентификаторы субъектов. Это делает его оператором или, если IdP развёрнут сторонним подрядчиком, — лицом, осуществляющим обработку по поручению (ст. 6 ч. 3 ФЗ-152).

Ключевое следствие централизации — концентрация риска. Если в распределённой архитектуре утечка из одного приложения затрагивает только его пользователей, то утечка из IdP затрагивает всех. Для компании с 50 000 пользователей это автоматически квалифицирует инцидент по ч. 13 ст. 13.11 КоАП (от 10 000 до 100 000 субъектов, штраф 5–10 млн ₽). При повторном нарушении включается оборотный штраф по ч. 15: 1–3% совокупной выручки за предшествующий год, не менее 20 млн ₽, не более 500 млн ₽.

Федеративная аутентификация добавляет ещё одно измерение: атрибуты субъекта передаются между доменами — между IdP и SP, между организациями в случае cross-domain federation (например, B2B SaaS с клиентским IdP). Каждая такая передача должна быть обоснована одним из правовых оснований ст. 6 ФЗ-152. Если SP находится в иностранной юрисдикции — это трансграничная передача по ст. 12 ФЗ-152, требующая предварительного уведомления РКН.

Как определить уровень защищённости ИСПДн с SSO?

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

Для IdP в SaaS-продукте типичная матрица выглядит так. Если IdP обрабатывает только логины и email сотрудников (иные ПДн), угрозы 3-го типа актуальны, число субъектов менее 100 000 — минимальный УЗ-4. Если IdP хранит биометрию (изображение лица для входа через Face ID) — автоматически УЗ-3 при угрозах 3-го типа. Если система относится к КИИ по ФЗ-187 — необходим отдельный анализ категории значимости объекта и дополнительные требования ФСБ.

Базовый набор мер по Приказу ФСТЭК № 21 привязан к УЗ. Для УЗ-4 обязательны: идентификация и аутентификация (ИАФ), управление правами доступа (УПД), регистрация событий безопасности (РСБ), антивирусная защита (АВЗ), обеспечение целостности (ОЦЛ). Для УЗ-3 добавляются: обнаружение вторжений (СОВ), анализ защищённости (АНЗ), защита информационной системы (ЗИС). Выбор конкретных мер — через процедуру адаптации и уточнения базового набора с обоснованием в модели угроз.

Специфика SSO: один IdP может обслуживать несколько ИСПДн разных категорий. В этом случае уровень защищённости IdP определяется по наивысшей категории из всех подключённых систем. Если хотя бы один SP обрабатывает специальные ПДн (медданные, религиозные убеждения) — IdP должен соответствовать УЗ, установленному для специальных категорий.

Какие требования к логированию в SSO и является ли лог-файл ПДн?

Лог аутентификации IdP содержит: timestamp, идентификатор пользователя, IP-адрес, User-Agent, результат аутентификации (успех / отказ), идентификатор сессии. IP-адрес в связке с идентификатором пользователя — это персональные данные по ст. 3 ФЗ-152, поскольку позволяет идентифицировать конкретного субъекта. Роскомнадзор придерживается расширительного толкования: данные, которые в совокупности идентифицируют физлицо, являются ПДн.

Это означает: лог-файлы SSO подпадают под требования ФЗ-152. Срок хранения логов должен быть обоснован в политике обработки ПДн и не превышать необходимого для достижения целей (принцип ст. 5 ч. 4 ФЗ-152). Типовой срок хранения технических логов для ИБ-расследований — 3–12 месяцев; хранение свыше года требует отдельного обоснования цели. Меры защиты логов определяются по УЗ ИСПДн, в которой они хранятся.

Требования РСБ (регистрация событий безопасности) по Приказу ФСТЭК № 21 предписывают фиксировать события доступа к ИСПДн, изменения прав, попытки несанкционированного доступа. Для IdP это означает необходимость собирать события аутентификации в SIEM-систему. Важно: сама SIEM-система при хранении в ней идентифицирующих данных также становится ИСПДн и требует защиты соответствующего УЗ. Часть команд решает это обезличиванием в pipeline перед попаданием в SIEM — это приемлемый подход при соблюдении методов Приказа РКН об обезличивании.

Обезличивание для ML: как правильно использовать данные из IdP?

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

Приказ РКН устанавливает 5 методов обезличивания: введение идентификаторов (псевдонимизация), изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Для ML-задач наиболее применимы псевдонимизация (замена реального идентификатора на технический UUID) и агрегация (замена точного timestamp на временной интервал). После обезличивания данные выходят из-под режима ФЗ-152 при условии, что обратное соотнесение невозможно без дополнительных данных, хранимых отдельно.

Практическое правило для CTO: обезличивание должно происходить до загрузки данных в ML-платформу, а не после. Если ML-платформа работает в облаке — необходимо убедиться, что туда передаются только обезличенные данные. Передача необезличенных ПДн в иностранную ML-платформу (AWS SageMaker, Google Vertex AI) — это трансграничная передача по ст. 12 ФЗ-152 плюс нарушение локализации по ч. 5 ст. 18.

Кто оператор в мультиарендной SaaS с федеративной аутентификацией?

В мультиарендной SaaS (multi-tenant) IdP может принадлежать вендору, а клиент-арендатор подключает собственный корпоративный IdP через federation protocol (SAML, OIDC). В этой конфигурации возникает вопрос о распределении ролей оператора и обработчика.

Вендор SaaS, принимающий токены от клиентского IdP и обрабатывающий атрибуты пользователей в своей системе, является оператором — он самостоятельно определяет состав и цели обработки в части функциональности платформы. Клиент-арендатор, управляющий своим IdP и направляющий атрибуты пользователей в SaaS, также является оператором — он определяет, каких пользователей допускать и какие атрибуты передавать. Это схема совместных операторов, и для неё необходимо соглашение, распределяющее ответственность по ст. 18.1 ФЗ-152.

Если вендор SaaS обрабатывает ПДн исключительно по инструкции клиента (например, только хранит и отображает), не определяя самостоятельно цели, — он является обработчиком по поручению (ст. 6 ч. 3 ФЗ-152). В этом случае необходим договор поручения, а вендор обязан соблюдать конфиденциальность и применять меры защиты, согласованные с клиентом-оператором. Смешение ролей без оформления документов — типичная ошибка при внедрении корпоративного SSO.

Как это применяется на практике

Кейс 1. IT-компания (Центральный ФО, весна 2025) внедрила корпоративный SSO на базе зарубежного облачного IdP для 3 800 сотрудников. При подготовке к аудиту выяснилось: директория пользователей физически расположена в дата-центре в Ирландии, договор поручения обработки с провайдером отсутствовал, уведомление РКН о трансграничной передаче не подавалось. Три нарушения квалифицировались по ч. 8 ст. 13.11 (локализация, 1–6 млн ₽), ч. 1 ст. 13.11 (обработка вне оснований, 150–300 тыс. ₽) и ч. 10 ст. 13.11 (неуведомление РКН, 100–300 тыс. ₽). CTO инициировал миграцию IdP в российское облако и оформил пакет ОРД до начала проверки.

Кейс 2. SaaS-вендор (Северо-Западный ФО, осень 2025) предоставлял мультиарендную платформу с поддержкой корпоративного SSO клиентов. При анализе выяснилось, что ML-модуль обрабатывал необезличенные логи аутентификации всех арендаторов для обучения модели детектирования аномалий. Клиенты-арендаторы не давали согласия на эту цель обработки, в уведомлениях РКН вендора цель ML не фигурировала. После консультации с юристами вендор внедрил pipeline обезличивания на основе псевдонимизации и агрегации временных меток, обновил уведомление РКН и добавил соответствующие условия в договоры с арендаторами. Претензии от РКН предотвращены до проверки.

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

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

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

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

Уровень защищённости ИСПДн определяется по ПП РФ № 1119 на основании трёх параметров: категория ПДн (специальные, биометрические, иные, общедоступные), тип актуальных угроз (1–3) и число субъектов (порог 100 000). Для типичного B2B SaaS с корпоративными пользователями и иными ПДн при угрозах 3-го типа и числе субъектов менее 100 000 устанавливается УЗ-4. При биометрии (вход по лицу) — не ниже УЗ-3. Если SaaS относится к объектам КИИ по ФЗ-187 — необходим отдельный анализ категории значимости с дополнительными требованиями ФСБ России.

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

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

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

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

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

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

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

Конкретный состав средств защиты информации определяется по результатам адаптации базового набора мер Приказа ФСТЭК № 21 к установленному УЗ. Для УЗ-4 базово обязательны: идентификация и аутентификация (ИАФ), управление правами доступа (УПД), регистрация событий (РСБ), антивирусная защита (АВЗ), обеспечение целостности (ОЦЛ). Для УЗ-3 добавляются обнаружение вторжений (СОВ) и анализ защищённости (АНЗ). Применение сертифицированных СЗИ (ФСТЭК или ФСБ) обязательно при наличии актуальных угроз 1-го и 2-го типов или требований регулятора по конкретной категории систем.

Итог

SSO и федеративная аутентификация — это не только архитектурное удобство, но и концентрация правовых рисков по ФЗ-152 в одной точке. Уровень защищённости IdP, локализация хранилища, договор поручения с провайдером, обезличивание для ML и разграничение ролей в мультиарендной SaaS — каждый из этих вопросов имеет прямое регуляторное последствие: от штрафа по ч. 8 ст. 13.11 (1–6 млн ₽) до оборотного по ч. 15 при повторном нарушении.

DATUM сопровождает IT-компании и SaaS-вендоров в оценке соответствия IdP-инфраструктуры требованиям ФЗ-152, ПП РФ № 1119 и Приказа ФСТЭК № 21, включая подготовку ОРД и оценку воздействия (DPIA) для сложных архитектур с федеративной аутентификацией.