Почему безопасность ML-систем становится все более важным вопросом и как ее обеспечить: MLOps-подходы, практики и технологии защиты данных, моделей машинного обучения, а также вычислительных и инфраструктурных конвейеров.
Защита данных для машинного обучения
В связи с активным внедрением система машинного обучения в производственное использование, вопрос безопасности становится все более актуальным. ML-системы часто содержат конфиденциальную информацию или позволяют компании иметь конкурентное преимущество за счет специфических алгоритмов обработки данных и предиктивных моделей. Модели машинного обучения в производстве обычно являются частью более крупной системы, в которой выходные данные используются с использованием внутренних или сторонних приложений. Поэтому важно гарантировать, что результаты моделей ML будут использоваться только авторизованными пользователями. Конвейеры создания моделей MLOps уязвимы и легко подвергаются атакам тремя разными способами: злонамеренными инсайдерами, посредством манипулирования цепочкой поставок программного обеспечения и через взломанные системы.
Таким образом, потребность в обеспечении защиты ML-систем возникает с самого начала разработки и на всех этапах производства, а также во время эксплуатации. В течение всего своего жизненного цикла система Machine Learning должна быть активно защищена. Реализовать это можно с помощью практик и инструментов MLOps – концепции, направленной на устранение организационных и технологических разрывов между всеми участниками процессов разработки, развертывания и эксплуатации систем машинного обучения.
Поскольку ML-модели очень зависят от данных, безопасность системы машинного обучения напрямую связана с защитой данных. Поэтому данные надо организовать так, чтобы обеспечить их целостность, согласованность и аутентифицированный доступ. Для этого есть несколько практик:
- политика нулевого доверия, которая требует аутентификации и авторизации всех пользователей, запрашивающих доступ к приложениям или данным ML-системы. Политика проверяет пользователей, чтобы гарантировать, что их устройства имеют надлежащие привилегии, и постоянно отслеживает их активность. Здесь пригодится аутентификация на основе рисков (Risk Based Autentification)– практика обеспечения безопасности с разными уровнями строгости к процессу аутентификации. Эта стратегия также известна как адаптивная аутентификация, поскольку она рассчитывает оценку риска для попытки доступа в режиме реального времени. Это дает пользователю возможность аутентификации в зависимости от его оценки. В процессе аутентификации применяются более строгие и ограничительные меры по мере увеличения уровня риска.
- принцип наименьших привилегий (PoLP, Principle Of Least Privilege), когда пользователю предоставляется только тот доступ к данным и приложениям, который ему необходим для выполнения своих задач — не больше и не меньше. Если злоумышленник получает доступ к одной части системы хранения данных, используемой для машинного обучения, этот принцип ограничивает его доступ ко всей системе и уменьшает поверхность атаки.
- паттерн CQRS (Command and Query Responsibility Segregation) – разделение запросов на чтение данных от команд на их изменение, создание и удаление, т.е. любые мутации. Для этого придется реализовать несколько экземпляров хранилища данных со значениями фичей для машинного обучения: одно будет допускать мутации данных, а потому будет иметь более строгие политики безопасности. Другие будут реплицировать данные с него данные, но будут доступны лишь для чтения. Подробнее про важность отметок времени события для кибербезопасности корпоративных озер и хранилищ данных мы писали здесь.
- криптографические меры защиты конфиденциальных данных. Шифрование и хэширование данных в хранилище, используемом для ML, также позволит снизить вероятность несанкционированного доступа к чувствительным данным. Кроме того, эти же самые меры можно применить к протоколам передачи данных, например, использование безопасных криптографических протоколов, требующих доверенного общения между всеми участниками процессов обмена данными.
- мониторинг и протоколирование доступа к хранилищу данных, с логированием всех событий. Файлы логов содержат журнал аудита, который можно использовать для мониторинга действий в хранилище данных. Журналы аудита действуют как следующая линия защиты, если злоумышленник обходит другие меры безопасности. Они помогли провести судебно-медицинское расследование после нарушения безопасности.
- регулярный аудит файлов логов поможет выявить любые следы несанкционированных действий, нарушений политик и инцидентов безопасности. Если произошло нарушение безопасности, журналы аудита помогут восстановить события, приведшие к нарушению, позволяя узнать, как произошло нарушение и как можно устранить уязвимости.
- физические меры защиты хранилища данных, включая датчики температуры и дыма для мониторинга внутренней среды, биометрии или устройств чтения смарт-карт для предотвращения несанкционированного доступа, а также видеонаблюдение с сохранением видео.
Защита ML-моделей
Одним из ключевых отличий ML-систем от других ИС является зависимость не только от данных, но и от алгоритмов машинного обучения. Поэтому важно защитить не только данные, но и сами модели, которые постоянно эволюционируют. А, поскольку модели обучаются на данных, рассматривать защиту ML-моделей в отрыве от защиты данных, невозможно. Поэтому для защиты ML-моделей важно понять, какие данные используются для обучения модели, откуда они берутся и что содержат.
Отравление данных представляет собой серьезную угрозу для моделей Machine Learning. Иногда даже небольшое отклонение в данных может сделать модель машинного обучения неэффективной. Часто злоумышленники стремятся манипулировать обучающими данными, чтобы сделать ML-модель уязвимой к атакам. Например, злоумышленник может подать свои входные данные в качестве обучающих, чтобы алгоритм классификации вывел неверный прогноз. Модель, обученная на поддельных данных, не может давать точных прогнозов. Таким образом, злоумышленник может перепроектировать ML-модель и использовать ее в личных целях. Если это произойдет, MLOps-инженеру необходимо выявить некачественные выборки данных, удалить их и повторно обучить исходную ML-модель.
Однако, переобучение может не исправить ситуацию. Поэтому следует предотвратить атаки, обнаруживая вредоносные входные данные с помощью проверки их достоверности, регрессионного тестирования и пр. Полезной практикой при этом может стать ограничение пропускной способности входящих запросов, т.е. запрет повтора однотипных действий от одного пользователя в течение определенного времен. Например, временное блокирование процедуры аутентификации после нескольких неудачных попыток входа в учетную запись.
Проверка достоверности помогает проверить качество и точность исходных данных перед обучением модели машинного обучения. Регрессионное тестирование поможет предотвратить ошибки Machine Learning, отслеживая производительность модели ML. Также можно промоделировать атаки на ML-алгоритмы, чтобы обеспечить эффективную защиту от атак с отравлением данных: обнаружить возможные точки данных, привлекающие злоумышленников, и создать механизмы их защиты.
Помимо этого, к защите ML-моделей относится соблюдение корпоративных или государственных политик соответствия. MLOps-инженеру следует знать законы, касающиеся обработки и хранения данных. Например, 152-ФЗ РФ защищает персональные данные граждан РФ. А компании, обрабатывающие информацию о пациентах в Европейском Союзе, должны соблюдать Общий регламент по защите данных (GDPR). В США действует Закон о переносимости и подотчетности медицинского страхования (HIPAA), который регулирует использование конфиденциальных данных пациентов. Поэтому при сборе таких данных для обучения ML-моделей необходимо согласие их обладателя. Кроме того, при запросе пользователя на удаление этих данных, ML-система должна предоставлять MLOps-инженеру такую возможность.
Таким образом, чтобы защитить модели машинного обучения, MLOps-инженеру необходимо иметь точные ответы как минимум на следующие вопросы:
- откуда берутся данные обучения?
- какие данные используются для обучения моделей?
- кто разработчик ML-модели?
- кто, помимо разработчика, имеет доступ к модели?
- у кого есть доступ к MLOps-конвейеру?
Безопасность MLOps-конвейера и инфраструктуры
Поскольку данные для обучения ML-модели и прогнозирования выводов генерируются и потребляются с помощью взаимодействующих приложений, защита конвейера обработки данных также является важным элементом обеспечения безопасности. В частности, одной из проблем обеспечения безопасности MLOps является длина и глубина типичных конвейеров машинного обучения. Они включают в себя множество этапов: сбор и подготовка данных, а также создание, оценку, оптимизацию, развертывание и использование ML-модели. На любом этапе этого конвейера может возникнуть уязвимость.
Поэтому очень важно вести непрерывный мониторинг всей ML-системы, чтобы обеспечить ее. Наблюдение за задачами ML предотвращает сбои, предоставляя оповещения до возникновения инцидента и рекомендуя решения для этих сбоев. Ошибка, обнаруженная в обучающих данных, может повлиять на функциональность модели. Чтобы эффективно устранить проблему, MLOps-инженер должен отследить ее с того места, где она возникла. Поэтому просмотр данные о производительности и значения метрик задач машинного обучения позволяет получить о проблемах безопасности. Сюда же относится анализ логов в журналах доступа и прогнозирования.
Таким образом, для защиты MLOps-конвейера необходимо обеспечить его наблюдаемость, которая позволит понимать поведение системы в работоспособном и неработоспособном состояниях. Для этого следует настроить оповещения, которые прогнозируют атаку еще до того, как произойдет фактический инцидент. Отслеживание данных о производительности и регистрация показателей задач ML дают возможность получить представление обо всех проблемах безопасности, которые могут повлиять на систему машинного обучения.
Наконец, в рамках защиты конвейера обработки данных следует обеспечить их безопасную оркестрацию, поскольку сбой оркестратора, управляющего заданиями машинного обучения, приведет к остановке всей ML-системы. Для этого следует использовать защищенные протоколы, аутентификацию и политики управления трафиком с несколькими проверками входящих запросов и устройств.
Эксплуатация ML-системы предполагает развертывание модели машинного обучения в производственной среде, чтобы результаты моделирования были доступны пользователям и внешним системам. Обычно для развертывания моделей Machine Learning используются веб-серверы в качестве точки входа к серверному веб-приложению извне. Однако, при взаимодействии клиента и сервера по типу запрос-ответ (request-response) данные пользователя должны отправляться на сервер при каждом запросе, что увеличивает использование сети и задержку. Избежать этого позволят альтернативные способы интеграции клиента с серверным приложением, например, с помощью потокового API в gRPC, о чем мы писали здесь.
После разработки ML-модели и ее успешного внедрения в производство необходимо непрерывно следить за ней, чтобы вовремя увидеть падение производительности или точности. Для этого MLOps-инженеры используют инфраструктурные решения, которые логируют и визуализируют системные метрики и логи. Например, Grafana, Prometheus, Influx DB и т.д.
Таким образом, помимо разработки и развертывания ML-систем необходимо решать вопросы обеспечения безопасности, связанные с данными, программным кодом, конвейерами обработки данных и инфраструктурой. Комплексное решение этих вопросов с трассировкой подходов и инструментов предлагает концепция MLOps.
Узнайте больше про применение MLOps-инструментов в системах аналитики больших данных и машинного обучения на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
