Логи прокси-сервера

CISO сталкивается с двойным давлением: требования информационной безопасности и KII предписывают максимально детальное логирование, а 152-ФЗ обязывает минимизировать объём обрабатываемых персональных данных. Прокси-логи находятся на пересечении этих требований. Ниже — анализ правового статуса логов, требований к уровням защищённости по ПП РФ № 1119, обязательных мер ФСТЭК по Приказу № 21 и практики обезличивания для ML-задач.

Являются ли логи прокси-сервера персональными данными?

Ответ зависит от состава записи и технической возможности идентификации субъекта. Типичная строка прокси-лога включает: временну́ю метку, IP-адрес источника, запрошенный URL, HTTP-метод, код ответа, объём переданных данных и User-Agent. Каждый из этих элементов в отдельности может не быть персональными данными. Однако совокупность IP-адреса, временного штампа и идентификатора сессии, при наличии возможности соотнести её с конкретным физическим лицом — корпоративным пользователем или клиентом SaaS — переводит лог в категорию персональных данных по ст. 3 ФЗ-152.

Практическое следствие: если оператор ведёт DHCP-журнал, реестр VPN-подключений или таблицу соответствия «сотрудник — рабочая станция», прокси-лог становится косвенно идентифицирующей информацией. РКН при проверках запрашивает именно наличие такой возможности сопоставления, а не фактическое содержание каждой записи.

Для SaaS с мультиарендной архитектурой (multi-tenancy) ситуация сложнее. Лог содержит идентификаторы тенанта, user_id и session_id. Если платформа хранит маппинг user_id на ФИО клиента тенанта — весь лог становится ПДн. Это означает необходимость указания соответствующей ИСПДн в уведомлении РКН по ст. 22 ФЗ-152 и применения мер защиты согласно уровню защищённости.

Какой уровень защищённости (УЗ) применяется к ИСПДн с прокси-логами?

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

Для типичной корпоративной прокси-системы применим следующий расчёт. Категория ПДн в логах — «иные» (не специальные, не биометрические): IP, URL, временна́я метка. Тип угроз — как правило 3-й (НДВ отсутствуют в прикладном ПО, проверено актуальной моделью угроз). Число субъектов: если сотрудников меньше 100 000 — это критичный порог. При таких условиях минимально применимый уровень — УЗ-3.

Для SaaS-платформы, обрабатывающей логи клиентов-физических лиц, картина может измениться: если число субъектов превышает 100 000 или в логах присутствуют косвенные данные о состоянии здоровья (запросы к медицинским ресурсам), уровень повышается до УЗ-2. Это влечёт дополнительные требования: усиленная идентификация администратора, межсетевое экранирование по ФСТЭК, криптозащита по ГОСТ.

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

Приказ ФСТЭК № 21 от 18.02.2013 определяет 15 функциональных групп мер защиты. Для систем хранения и обработки прокси-логов принципиально значимы несколько групп.

РСБ — регистрация событий безопасности. Ирония в том, что сами прокси-логи — это реализация группы РСБ. Требование по УЗ-3: регистрация входа/выхода, попыток несанкционированного доступа, изменений конфигурации. Для хранилища логов это означает логирование доступа к самим логам — «метажурнал» с минимальным сроком хранения, установленным в политике безопасности.

ЗНИ — защита носителей информации. Логи, выгруженные на внешние носители или в резервное хранилище, должны быть защищены от несанкционированного доступа. При передаче в облако — шифрование в соответствии с требованиями уровня.

УПД — управление правами доступа. Доступ к прокси-логам — только по принципу минимальных привилегий. Типичная ошибка: read-доступ к лог-хранилищу для всей группы DevOps. Это отдельный риск при проверке: избыточные права на ПДн квалифицируются как нарушение условий обработки по ч. 1 ст. 13.11 КоАП.

АНЗ — анализ защищённости. Для систем с высоким объёмом логов — минимум ежегодный анализ уязвимостей. Это особенно актуально для ELK/OpenSearch-стеков, используемых как централизованные хранилища: они регулярно попадают в публичные базы уязвимостей CVE.

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

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

Для прокси-логов, передаваемых в ML-пайплайн, наиболее применимы два метода. Введение идентификаторов: реальный IP заменяется псевдонимом (хэш + соль, хранимая отдельно). Этот метод обратим при наличии ключа — что важно для расследования инцидентов, но создаёт регуляторный риск: РКН может расценить обратимую замену как неполное обезличивание. Обобщение: IP усекается до /24-подсети, URL — до домена второго уровня без параметров запроса. Метод необратим, но снижает аналитическую ценность данных.

Практическая архитектура: «горячие» логи с полными данными хранятся 30–90 дней в защищённом хранилище с доступом по УПД; «холодные» логи для ML — только обезличенные агрегаты в отдельном хранилище без доступа к таблице маппинга. Важно: передача обезличенных логов во внешний ML-сервис, размещённый за рубежом, формально является трансграничной передачей только при сохранении возможности реидентификации. Если обезличивание необратимо — норма ст. 12 ФЗ-152 о трансграничной передаче не применяется.

Как применяется КИИ 187-ФЗ к инфраструктуре прокси-логов?

Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры» не отменяет требований ФЗ-152, но добавляет слой обязательств для субъектов КИИ. Прокси-сервер, обеспечивающий доступ к значимому объекту КИИ, сам может быть категорирован как элемент информационной инфраструктуры. В этом случае к логам применяются требования приказов ФСТЭК № 235 и № 239, которые устанавливают более жёсткие стандарты регистрации событий, чем Приказ № 21.

Коллизия возникает в следующей точке: требования 187-ФЗ предписывают хранить логи событий на объектах КИИ не менее трёх лет. Требования 152-ФЗ обязывают хранить ПДн не дольше, чем необходимо для достижения цели. Если цель — обеспечение безопасности КИИ — трёхлетнее хранение обосновано. Это обоснование должно быть явно зафиксировано в политике обработки ПДн и модели угроз: «срок хранения определён требованиями законодательства о КИИ».

Типичные ситуации: CISO и прокси-логи как ПДн

Ситуация 1. SaaS-платформа хранит прокси-логи клиентских сессий в облаке иностранного провайдера. Логи содержат user_id, IP и URL запросов к API. Оператор — SaaS-вендор, субъекты — пользователи тенантов. Хранение в иностранном облаке нарушает требование локализации по ч. 5 ст. 18 ФЗ-152, если логи позволяют идентифицировать граждан РФ. Санкция — ч. 8 ст. 13.11 КоАП: от 1 до 6 млн ₽. Стратегия: перенос хранилища «горячих» логов в облако российского провайдера; необратимо обезличенные агрегаты — в зарубежное облако допустимо.

Ситуация 2. Корпоративный прокси пишет логи в централизованную SIEM-систему, доступную подрядчику по аутсорсингу ИБ. Передача прокси-логов подрядчику — это поручение обработки ПДн по п. 3 ст. 6 ФЗ-152. Без письменного договора-поручения с обязательными реквизитами каждая такая передача — нарушение ч. 1 ст. 13.11. По принципу, сложившемуся в судебной практике, оператор несёт ответственность за утечку через подрядчика наравне с ним. Стратегия: заключить договор-поручение с перечнем разрешённых действий, ограничением срока и обязанностью по уничтожению.

Ситуация 3. Инцидент: обнаружена выгрузка прокси-логов за 18 месяцев на внешний сервер через скомпрометированный сервисный аккаунт. IT-компания Северо-Западного федерального округа (осень 2025 года) выявила инцидент в течение четырёх часов после срабатывания DLP-политики. CISO направил первичное уведомление в РКН за 20 часов. Через 72 часа представлен отчёт с описанием скомпрометированных данных, числа субъектов и принятых мер. Выгрузка затронула около 15 000 пользователей. РКН квалифицировал инцидент по ч. 13 ст. 13.11 (10 000–100 000 субъектов, штраф 5–10 млн ₽). Оперативное уведомление позволило снизить штраф до нижней границы диапазона. Стратегия: критична скорость обнаружения и документирования момента выявления — не момента совершения утечки.

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

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

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

1. Какой УЗ выбрать для SaaS с логами пользовательских сессий?

Отправная точка — категория ПДн в логах и тип угроз из актуальной модели. Если логи содержат только «иные» ПДн (IP, user_id, URL) без специальных категорий, а тип угроз — третий (НДВ в прикладном ПО не актуальны), то при числе субъектов менее 100 000 минимально применимый уровень — УЗ-3 по ПП РФ № 1119. При превышении порога 100 000 субъектов или наличии косвенных данных о состоянии здоровья в URL — уровень повышается до УЗ-2. Выбор должен быть задокументирован в модели угроз и обоснован письменно: это первый документ, который запрашивает РКН на проверке.

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

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

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

Обезличивание по ст. 13.1 ФЗ-152 — это процесс, результатом которого является невозможность соотнести запись с конкретным лицом без дополнительной информации. Ключевое слово — «без дополнительной информации»: при наличии ключа или таблицы маппинга обезличивание считается обратимым, что снижает, но не устраняет регуляторные риски. Анонимизация в западном понимании (GDPR) — полное и необратимое удаление идентифицирующих признаков; в российском праве этот термин не используется. Для ML-задач оптимален метод обобщения: IP усекается до подсети, URL — до домена без параметров. Результат — необратимое обезличивание, пригодное для обучения моделей.

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

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

5. Какие средства защиты информации (СЗИ) обязательны для ИСПДн с логами на УЗ-3?

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

Итог

Прокси-логи — это персональные данные в большинстве корпоративных и SaaS-конфигураций, где возможна косвенная идентификация пользователя через IP и сессионные идентификаторы. Выбор уровня защищённости, набор мер ФСТЭК по Приказу № 21 и порядок обезличивания для ML должны быть задокументированы и обоснованы в модели угроз до начала передачи логов в аналитические системы. Требование локализации по ч. 5 ст. 18 ФЗ-152 и санкции ч. 8 ст. 13.11 КоАП делают иностранные облачные хранилища рискованным выбором для «горячих» логов.

Аналитики DATUM сопровождают IT-компании и SaaS-вендоров в выборе УЗ, разработке модели угроз и организации соответствующего документооборота — от политики обработки до договора-поручения с подрядчиком по аутсорсингу ИБ.