Логи в облаке (CloudWatch, Stackdriver)

Облачный logging — CloudWatch в AWS, Cloud Logging (Stackdriver) в GCP, Log Analytics в Azure — фиксирует IP-адреса, user-agent, идентификаторы сессий, email-адреса и другие атрибуты запросов. Роскомнадзор квалифицирует эти данные как персональные, если они позволяют идентифицировать пользователя. С 30.05.2025 требования ст. 13.11 КоАП кардинально ужесточились: появилось 18 составов вместо прежних 7. CISO, не выстроивший политику работы с логами, рискует лично попасть под ст. 272.1 УК и обеспечить компании оборотный штраф. Ниже — как устроены требования, что надо сделать и где возникают типовые ошибки.

Когда логи становятся персональными данными и какой УЗ применяется?

Логи — это не просто технические записи. IP-адрес, связанный с действием конкретного пользователя, является персональными данными по ст. 3 ФЗ-152. Идентификатор сессии, сопоставленный с аккаунтом, — тоже. Email в строке запроса, номер телефона в URL, геолокация в заголовках — всё это ПДн, даже если находятся в сервисном журнале, а не в основной базе данных.

Уровень защищённости информационной системы определяется по ПП РФ №1119 от 01.11.2012. Для SaaS с логами, где обрабатываются общие ПДн более 100 000 субъектов и угрозы второго типа не актуальны — это УЗ-3. Если специальные категории (здоровье, биометрия) попадают в логи диагностики — уровень поднимается до УЗ-2 или УЗ-1. Ошибка в определении УЗ означает, что базовый набор мер по Приказу ФСТЭК №21 не выполнен, а это состав нарушения по ч. 1 ст. 13.11 КоАП.

Практически: если CloudWatch хранит access-логи с IP и user_id, а система обрабатывает более 100 000 активных пользователей — это ИСПДн как минимум УЗ-3. Требуется документальное определение УЗ в акте классификации, согласование с CISO, фиксация в модели угроз. Отсутствие акта — самостоятельное нарушение при проверке РКН.

Как документировать поручение обработки при использовании CloudWatch и Stackdriver?

AWS, Google Cloud, Microsoft Azure — это лица, осуществляющие обработку ПДн по поручению оператора. Правовая конструкция — п. 3 ст. 6 ФЗ-152. Без надлежащего договора поручения (Data Processing Agreement, DPA) оператор несёт ответственность за все нарушения, допущенные облачным провайдером при работе с логами.

Стандартные соглашения AWS Data Processing Addendum и Google Cloud Data Processing Addendum по форме соответствуют требованиям ст. 6 ФЗ-152 к договору поручения — но только при условии, что регион хранения данных выбран правильно. Если логи уходят в регионы eu-west-1 или us-east-1, возникает нарушение ч. 5 ст. 18 ФЗ-152 о локализации. Требование локализации распространяется на операции записи, систематизации, накопления, хранения, уточнения и извлечения ПДн граждан РФ — логи, содержащие ПДн российских пользователей, подпадают под это правило.

Дополнительно: если облачный провайдер обрабатывает логи за пределами России, это трансграничная передача по ст. 12 ФЗ-152. США, GCP-регионы в ЕС — не входят в перечень стран с адекватной защитой. Значит, до начала обработки требуется уведомление РКН о трансграничной передаче.

Как выстроить политику логирования под требования ФЗ-152 и Приказа ФСТЭК №21?

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

В контексте CloudWatch: необходимо настроить retention policy (срок хранения логов), ограничить IAM-доступ к лог-группам, включить шифрование KMS для хранимых журналов, настроить экспорт в S3 с политикой bucket versioning и MFA delete. В Stackdriver — аналогично: Log Router для маршрутизации только необходимых событий, Log Sink с ограниченным доступом, CMEK для шифрования.

Ключевая проблема — избыточность. CloudWatch по умолчанию собирает всё: запросы, заголовки, тела ответов. Если в теле ответа API-метода присутствуют ПДн (имя, email, номер договора) — они попадают в лог. Принцип минимизации данных по ст. 5 ФЗ-152 требует, чтобы состав логируемых полей был ограничен тем, что необходимо для целей безопасности, а не всем подряд.

Что такое обезличивание для ML и как применять его к логам?

Машинное обучение на логах — типовой сценарий: аномалии, fraud detection, предиктивный мониторинг. Если логи содержат ПДн, их использование для обучения модели требует либо отдельного согласия субъектов (ст. 9 ФЗ-152), либо обезличивания. Первый путь практически нереализуем в масштабе. Второй — регулируется приказом РКН об обезличивании.

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

Для логов наиболее применимы методы введения идентификаторов и обобщения. IP-адрес → хэш с солью (salt не хранится вместе с данными) или маскирование последнего октета. User_id → суррогатный ключ. Email → хэш SHA-256 без возможности обратного преобразования. После обезличивания данные выходят из-под режима ФЗ-152 — но только если обезличивание необратимо. Псевдонимизация (токенизация с хранением таблицы соответствия) — это не обезличивание, ПДн остаются под 152-ФЗ.

Как применяется ст. 272.1 УК РФ к инцидентам с логами в облаке?

Статья 272.1 УК РФ введена ФЗ-421 от 30.11.2024, действует с 11.12.2024. Состав — незаконное использование, передача, сбор или хранение компьютерной информации, содержащей ПДн. Применительно к логам: если сотрудник скачивает лог-файлы с ПДн без оснований, экспортирует их в личное хранилище или передаёт третьим лицам — это основание для уголовного преследования. Максимум по ч. 5 (тяжкие последствия) — лишение свободы до 10 лет.

Для CISO это означает: система управления доступом к журналам должна быть документирована. IAM-политики CloudWatch, разграничение Log Buckets в GCP, аудит запросов к Log Analytics — всё это не просто конфигурация безопасности, а доказательная база. При расследовании инцидента отсутствие ролевого доступа и журналов аудита самих логов превращает CISO из свидетеля в подозреваемого.

Параллельно работает административная ответственность: утечка ПДн из лог-хранилища — это ч. 12–14 ст. 13.11 КоАП (3–15 млн ₽ в зависимости от числа субъектов), плюс ч. 11 той же статьи за неуведомление РКН в течение 24 часов (1–3 млн ₽). При повторности — оборотный штраф по ч. 15: 1–3% совокупной годовой выручки, не менее 20 млн ₽ и не более 500 млн ₽.

Типовые сценарии: как это выглядит на практике

Сценарий 1. Логи AWS в регионе us-east-1. SaaS-компания (Центральный ФО, 2025) использовала CloudWatch для сбора access-логов. Регион хранения — us-east-1. Уведомление о трансграничной передаче в РКН не подавалось. РКН возбудил дело по ч. 8 ст. 13.11 КоАП (нарушение локализации). Компания не оспаривала протокол. Штраф — в нижней части диапазона 1–6 млн ₽. После инцидента компания перевела logging в российский регион облачного провайдера, переработала DPA и подала уведомление о намерении обрабатывать ПДн по ст. 22 ФЗ-152.

Сценарий 2. Утечка логов через misconfigured S3 Bucket. FinTech-компания (Северо-Западный ФО, начало 2026) настроила экспорт CloudWatch-логов в S3 без ограничений публичного доступа. Исследователь безопасности обнаружил открытый bucket с access-логами: IP, user_id, суммы транзакций. РКН уведомлён в течение 20 часов (норма — 24 часа по ч. 3.1 ст. 21 ФЗ-152). CISO подготовил отчёт за 68 часов (норма — 72 часа). Арбитражный суд региона, рассматривавший дело по ч. 12 ст. 13.11, применил смягчающие обстоятельства — оперативное уведомление и меры по устранению. Штраф ниже среднего диапазона 3–5 млн ₽. ⚠️ Конкретный номер дела и точная сумма — менеджер уточняет при публикации.

Мультиарендность SaaS и вопрос об операторе: кто отвечает по ФЗ-152?

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

Логи находятся в зоне ответственности вендора. Если CloudWatch собирает ПДн конечных пользователей клиента — вендор должен иметь договор поручения с каждым клиентом (п. 3 ст. 6 ФЗ-152) или определить, что является самостоятельным оператором. Ни одна из ролей не снимает ответственности за инцидент: практика применения ФЗ-152 подтверждает, что оператор отвечает за утечку через подрядчика.

КИИ-аспект: если SaaS относится к критической информационной инфраструктуре по ФЗ-187, требования к логированию дополняются обязанностью подключения к ГосСОПКА. Логи безопасности (SIEM-события, попытки НСД) должны передаваться в установленном формате. Совмещение требований ФЗ-152 и ФЗ-187 — отдельная задача для CISO.

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

• Аудит соответствия 152-ФЗ — классификация ИСПДн, анализ состава логов, план устранения за 2–3 недели
• DPIA (оценка воздействия) — анализ рисков ML-обучения на логах, требования к обезличиванию
• Комплект ОРД под ключ — политика логирования, акт классификации, договор поручения, регламент реагирования

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

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

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

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

Использовать можно, но с ограничениями. Требование локализации по ч. 5 ст. 18 ФЗ-152 распространяется на шесть операций с ПДн граждан РФ: запись, систематизацию, накопление, хранение, уточнение, извлечение. Эти операции должны выполняться в базах данных на территории РФ. Логи с ПДн российских пользователей нельзя хранить только в регионах us-east-1, eu-west-1 и аналогичных — необходимо зеркалирование или первичное размещение в российском регионе. Если логи уходят за рубеж — до начала обработки требуется уведомление РКН о трансграничной передаче по ст. 12 ФЗ-152.

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

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

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

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

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

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

Итог

Логи в облачных сервисах — CloudWatch, Stackdriver, Log Analytics — содержат персональные данные и подпадают под полный режим ФЗ-152. Уровень защищённости, документирование поручения обработки, локализация, обезличивание для ML и управление доступом к журналам — не опции архитектуры, а юридические обязательства с конкретными штрафными санкциями. С 30.05.2025 нарушения по ст. 13.11 КоАП исчисляются миллионами рублей; с 11.12.2024 ст. 272.1 УК создаёт личную уголовную ответственность для лиц, управляющих инфраструктурой.

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