OAuth2 и согласие пользователя

С 30.05.2025 ст. 13.11 КоАП действует в редакции ФЗ-420 с 18 частями. Для SaaS-продуктов, работающих через OAuth2, это означает: любая обработка профильных данных пользователя, полученных из стороннего провайдера, требует самостоятельного правового основания по ст. 6 ФЗ-152. Ниже — разбор четырёх ключевых вопросов для технического директора: где заканчивается OAuth2 и начинается 152-ФЗ, как правильно выстроить получение согласия, какой уровень защищённости нужен SaaS-системе и что происходит с данными пользователей при мультиарендной архитектуре.

Где OAuth2 заканчивается и где начинается 152-ФЗ?

OAuth2 решает задачу делегирования доступа: пользователь разрешает вашему приложению обратиться к API стороннего сервиса от его имени. Протокол описывает потоки токенов, scope-разрешения и жизненный цикл авторизации. Он не регулирует, что вы вправе делать с полученными данными после авторизации.

По ст. 3 ФЗ-152 вы становитесь оператором ПДн в момент, когда начинаете совершать любые действия с данными о физическом лице: запись, хранение, систематизацию, использование. Получив через OAuth2 email, имя и аватар пользователя от Google или Яндекса, вы уже обрабатываете персональные данные. Правовое основание для этой обработки — не scope-разрешение, а одно из 11 оснований ст. 6 ФЗ-152: согласие, исполнение договора, законная обязанность и другие.

Распространённая ошибка: разработчики считают, что если пользователь нажал «Разрешить» в окне OAuth2-провайдера, он дал согласие на обработку ПДн в вашем сервисе. Это неверно. Scope-разрешение подтверждает техническое право обратиться к API провайдера. Оно не содержит ни наименования вашей компании как оператора, ни перечня ваших целей обработки, ни срока — то есть не соответствует ни одному из обязательных реквизитов ст. 9 ФЗ-152.

Практическое следствие: в SaaS-продукте с OAuth2-авторизацией нужны два независимых механизма. Первый — OAuth2-flow для получения токена доступа. Второй — отдельная форма согласия на обработку ПДн, которую пользователь подписывает до начала обработки его данных в вашей системе. Эти механизмы не заменяют друг друга.

Какой уровень защищённости нужен SaaS-системе с OAuth2?

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

Для типового SaaS с OAuth2-авторизацией: если система обрабатывает только общие ПДн (имя, email, телефон), угрозы второго типа отсутствуют, а число пользователей меньше 100 000 — применяется УЗ-3. Меры защиты для УЗ-3 по Приказу ФСТЭК №21 от 18.02.2013 включают обязательные группы: идентификацию и аутентификацию (ИАФ), управление правами доступа (УПД), защиту носителей информации (ЗНИ), регистрацию событий безопасности (РСБ) и антивирусную защиту (АВЗ).

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

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

Как мультиарендная SaaS-архитектура влияет на роли по 152-ФЗ?

В мультиарендной (multi-tenant) SaaS-архитектуре данные нескольких организаций-клиентов хранятся в одной инфраструктуре с логическим разделением. Для 152-ФЗ это создаёт неочевидный вопрос: кто является оператором ПДн конечных пользователей?

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

В контексте OAuth2: если пользователь tenant-компании авторизуется в SaaS-продукте через OAuth2, scope-разрешения выдаются для инфраструктуры SaaS-провайдера, но правовые основания для обработки ПДн должен обеспечить tenant-оператор. Провайдер не вправе использовать эти данные для собственных целей, выходящих за рамки договора-поручения.

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

Типовые сценарии: OAuth2, согласие и ответственность

Сценарий 1. SaaS запрашивает email через OAuth2 и хранит его без отдельного согласия. Ситуация: B2C-сервис авторизует пользователей через OAuth2 Google, сохраняет email и имя в базе, использует для рассылок. Согласие включено в пользовательское соглашение. После 01.09.2025 такое согласие не соответствует ч. 1 ст. 9 ФЗ-152 в редакции ФЗ-156. Вероятный исход при проверке РКН: протокол по ч. 2 ст. 13.11 КоАП (штраф 300 000–700 000 руб.). Стратегия: до 01.09.2025 вывести отдельную форму согласия в OAuth2-callback-обработчике, встроить в онбординг-флоу.

Сценарий 2. SaaS-провайдер обрабатывает агрегированные данные tenants для обучения ML-модели без договора-поручения. Ситуация: провайдер агрегирует поведенческие данные пользователей нескольких B2B-клиентов для обучения рекомендательного алгоритма. Договоры-поручения не заключены, обезличивание не проведено по установленным методам. Квалификация: обработка ПДн за пределами целей, указанных в уведомлении РКН (ч. 1 ст. 13.11 КоАП, 150 000–300 000 руб.), плюс возможное нарушение ст. 5 ФЗ-152 (принцип несовместимости целей). Стратегия: заключить договоры-поручения, применить метод обезличивания до агрегации, обновить уведомление в реестре РКН.

Сценарий 3. Корпоративный SaaS с OAuth2 использует облачную инфраструктуру за рубежом без уведомления о трансграничной передаче. Ситуация: ИСПДн развёрнута в AWS EU (Ирландия), OAuth2-провайдер — Microsoft Azure AD. ПДн российских пользователей систематически передаются за рубеж. Уведомление о трансграничной передаче в РКН не подавалось. Квалификация: нарушение ч. 5 ст. 18 ФЗ-152 (локализация) и ст. 12 ФЗ-152 (трансграничная передача). Штраф по ч. 8 ст. 13.11 КоАП — 1 000 000–6 000 000 руб., повторно (ч. 9) — 6 000 000–18 000 000 руб. Стратегия: перенести первичное хранение и обработку в российский облачный регион, подать уведомление о трансграничной передаче в РКН.

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

Кейс 1. IT-компания из Северо-Западного ФО (осень 2025) развивала B2B SaaS для управления проектами с OAuth2-авторизацией через Microsoft и Google. При подготовке к проверке РКН юристы выявили: согласия пользователей встроены в условия использования сервиса, договоры-поручения с корпоративными клиентами не содержат перечня разрешённых действий с ПДн, облачная инфраструктура развёрнута частично в финском датацентре. Компания провела DPIA, перенесла первичную обработку в российский регион, оформила поручения и перевела согласия в отдельные документы. Предписание РКН по итогам внеплановой проверки было закрыто без административного производства.

Кейс 2. Финтех-стартап (Центральный ФО, начало 2026) использовал OAuth2-авторизацию для онбординга пользователей в мобильном приложении. Параллельно данные профилей обезличивались и передавались в ML-пайплайн для скоринга. Обезличивание проводилось собственным алгоритмом хеширования, не соответствующим ни одному из 5 методов по Приказу РКН 2025 года. После обращения субъекта в РКН с жалобой на использование его данных для целей, не указанных при авторизации, была инициирована проверка. Штраф составил несколько сотен тысяч рублей по ч. 1 ст. 13.11 КоАП. Компания пересмотрела алгоритм обезличивания и обновила уведомление в реестре РКН.

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

• DPIA (оценка воздействия) — оценка рисков SaaS-архитектуры с OAuth2 и мультиарендностью
• Аудит соответствия 152-ФЗ — проверка согласий, поручений, УЗ, уведомления РКН
• Комплект ОРД под ключ — договоры-поручения, согласия, политика, приказы

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

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

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

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

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

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

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

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

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

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

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

Итог

OAuth2 — инструмент авторизации, не замена согласию по 152-ФЗ. SaaS-продукт с OAuth2-авторизацией требует самостоятельного правового основания для каждой цели обработки ПДн, отдельного согласия в соответствии с ФЗ-156 с 01.09.2025, договоров-поручений с B2B-клиентами и локализации первичного хранения на территории России. Нарушения по ч. 2, 8 и 9 ст. 13.11 КоАП в совокупности создают риск штрафов от 700 000 до 18 000 000 руб. при первой проверке.

Практика DATUM сопровождает IT-компании и SaaS-провайдеров в классификации ИСПДн, построении корректных OAuth2-флоу с выполнением требований ст. 9 ФЗ-152, оформлении договоров-поручений и прохождении проверок РКН.