«Federated Learning стал модным ответом на вопросы о приватности данных, но его зачастую реализуют исходя из наивного представления об угрозах. На практике распределенная архитектура не решает, а лишь трансформирует классические проблемы информационной безопасности, добавляя к ним новые, специфические уязвимости, которые могут оставаться незаметными, пока не станет слишком поздно.»
Что на самом деле скрывается за термином Federated Learning
Если отбросить маркетинговые обёртки, federated learning, это архитектурная парадигма для машинного обучения, при которой модель обучается децентрализованно. Вместо того чтобы загружать все данные в центральный дата-центр, процесс обучения отправляется на устройства или в локальные узлы, где находятся эти данные. Каждый узел (это может быть смартфон, сервер филиала банка или промышленный контроллер) обучает модель на своих локальных данных, а затем отправляет на центральный сервер только обновления параметров модели — так называемые градиенты или веса. Сервер агрегирует эти обновления, улучшая глобальную модель, которую затем снова рассылает узлам для следующего раунда обучения.
Ключевое обещание FL — сохранение конфиденциальности данных, так как сами сырые данные никогда не покидают исходный узел. Это особенно привлекательно для отраслей, работающих с чувствительной информацией: финансы, телекоммуникации, здравоохранение, государственные услуги. Однако эта декларативная приватность порождает ложное чувство безопасности, маскируя реальные угрозы, которые смещаются с уровня данных на уровень модели и её обновлений.
Существует несколько видов FL, и угрозы для них различаются. Горизонтальный FL — самый распространённый, когда разные узлы обладают разными наборами данных, но с одинаковым набором признаков (например, клавиатуры на разных смартфонах учатся предсказывать следующее слово). Вертикальный FL используется, когда узлы обладают разными признаками об одних и тех же сущностях (например, банк и магазин объединяют признаки о клиенте). FL также делится на одноранговый (peer-to-peer) и архитектуру с центральным координатором, который является основной точкой атаки.
Угрозы конфиденциальности: модель как зеркало данных
Основная иллюзия — что раз данные не передаются, то и украсть их нельзя. На практике модель, а точнее её обновления, становятся мощным каналом утечки информации.
Атаки на основе градиентов
Градиенты, это производные функции потерь по параметрам модели. Они точно отражают, как модель «хотела бы» измениться под влиянием каждого обучающего примера. Используя методы обратного вывода, злоумышленник, имеющий доступ к обновлениям от конкретного узла, может частично или полностью восстановить исходные данные обучения.
Представьте, что модель на мобильном устройстве учится распознавать рукописный текст. Отправляя градиенты, устройство по сути говорит: «После просмотра моих данных модель должна сдвинуть вот эти нейроны в этом направлении». Анализируя эти сдвиги, атакующий на сервере может реконструировать контуры нарисованных букв. Для простых моделей и данных это делается почти тривиально; для сложных требуются вычислительные ресурсы, но сама возможность остаётся критической уязвимостью.
Особенно опасны атаки с членством, когда атакующий пытается определить, входил ли конкретный образец данных (например, медицинская запись определённого пациента) в обучающий набор. Если модель обучалась на этих данных, её поведение на них будет отличаться, что может быть выявлено через анализ обновлений или самой модели.
Угрозы целостности и доступности: саботаж изнутри
Распределённый характер делает FL уязвимым к сбоям и злонамеренным действиям участников. Центральный сервер вынужден доверять всем узлам, участвующим в обучении.
Отравление данных
В классическом ML злоумышленник должен отравить централизованный набор данных. Во FL для этого достаточно скомпрометировать один узел или создать несколько поддельных. Узел может намеренно искажать свои обучающие данные так, чтобы его локальная модель вырабатывала вредоносные обновления. При агрегации на сервере эти обновления встраивают в глобальную модель «бэкдоры» или ухудшают её производительность.
Например, можно незаметно внедрить триггер: модель будет корректно работать на большинстве данных, но давать определённый, нужный атакующему, результат при появлении в входных данных специфического, незаметного для человека паттерна. Так модель для распознавания лиц можно научить не видеть конкретного человека при наличии на изображении едва заметного знака. С учетом того, что узлы зачастую слабо верифицируются, такая атака становится реальной.
Атаки на доступность и ресурсы
FL-системы уязвимы к атакам типа «византийские отказы». Злонамеренные узлы могут отправлять случайные, нулевые или максимально возможные обновления, чтобы сорвать процесс конвергенции модели, сделать обучение невозможным или потребовать огромных вычислительных ресурсов на сервере для обработки мусора. Это прямая угроза доступности сервиса машинного обучения.
Защитные механизмы: не только шифрование
Защита FL-систем, это многослойная задача, где криптография играет важную, но не единственную роль.
Дифференциально-приватный Federated Learning
Это один из самых эффективных методов защиты конфиденциальности. Перед отправкой на сервер обновления с узла «зашумливаются» — к ним добавляется небольшой, специально рассчитанный случайный шум. Этот шум маскирует вклад каждого отдельного образца данных, делая практически невозможным их восстановление из градиентов. Однако здесь возникает фундаментальный компромисс: чем сильнее шум (и выше приватность), тем ниже итоговая точность модели. Необходимо тщательно подбирать параметры шума (эпсилон) под конкретные требования регуляторных норм и бизнес-задач.
Безопасная агрегация (Secure Aggregation)
Это криптографический протокол, который позволяет серверу агрегировать обновления от множества узлов, но не позволяет ему увидеть обновление от любого отдельного узла. Как если бы каждый узел помещал своё обновление в сейф, а сервер мог сложить все сейфы вместе, получить общую сумму, но не мог открыть ни один по отдельности. Это предотвращает прямые атаки на конфиденциальность градиентов от конкретного устройства. Однако протокол сложен, требует дополнительных вычислительных и коммуникационных затрат и не защищает от отравляющих атак, которые могут «испортить» общую сумму.
Селекция и репутация узлов
Для борьбы с отравлением и византийскими атаками сервер не должен слепо доверять всем узлам. Реализуются механизмы контроля:
- Анализ обновлений: выбросы по размеру, направлению или статистическим параметрам могут сигнализировать о злонамеренном поведении. Такие обновления могут отбрасываться или ослабляться при агрегации.
- Репутационные модели: узлам начисляются баллы за качество и полезность их вкладов в прошлых раундах. Обновления от узлов с низкой репутацией либо игнорируются, либо требуют дополнительной проверки.
- Аудиторские задачи: сервер может периодически отправлять узлам заранее известные задачи (с известными ожидаемыми обновлениями) для проверки их честности. Отклонения от ожидаемого результата понижают доверие к узлу.
Регуляторный контекст и ФСТЭК
В российской практике использование Federated Learning для обработки персональных данных или информации, составляющей государственную тайну, сталкивается с неоднозначным регулированием. С одной стороны, принцип отсутствия передачи исходных данных за границы защищаемого периметра хорошо ложится на требования 152-ФЗ о локализации и минимизации. С другой — возникают новые объекты защиты, не описанные явно в классических руководящих документах (РД) ФСТЭК: глобальная модель, обновления параметров, процесс агрегации.
Ключевые вопросы для аттестации:
- Класс защищённости: Как классифицировать распределённую систему FL? Весь контур в сборе или каждый узел отдельно? Центральный сервер агрегации, очевидно, становится критическим компонентом.
- Защита каналов связи: Обмен обновлениями модели, даже зашифрованными, требует защиты от анализа трафика, внедрения и перехвата. Здесь применимы стандартные требования к VPN или ГОСТ-шифрованию.
- Контроль целостности ПО: Необходимо гарантировать, что на узлах работает верифицированное, неизменённое клиентское ПО для обучения. Иначе защищённый протокол можно обойти, просто модифицировав код на узле.
- Учёт новых угроз: В паспорте системы защиты информации (СЗИ) должны быть явно учтены угрозы, специфичные для FL: восстановление данных из градиентов, отравление модели через обновления, атаки на доступность процесса обучения.
FL не отменяет необходимость построения системы защиты в соответствии с приказом ФСТЭК № 17 и другими РД. Он лишь добавляет новый архитектурный слой, к которому эти требования должны быть адаптированы. Без этого адаптирования развёртывание FL в регулируемых отраслях создаст иллюзию соответствия при наличии существенных неизмеренных рисков.