Роскомнадзор предложил ранжировать операторов ПДн по степени полномочий

Роскомнадзор предложил ранжировать операторов ПДн по степени полномочий

Роскомнадзор предложил ранжировать операторов ПДн по степени полномочий

Роскомнадзор прорабатывает систему ранжирования операторов персональных данных, чтобы сократить объемы хранимых ПДн. Регулятор убежден, что разделение таких обработчиков по уровням доступа поможет эффективно бороться с утечками.

В настоящее время в реестре федеральной службы надзора числится более 950 тыс.  операторов ПДн. Среди них с большими объемами данных (свыше 1 млн записей) имеют дело менее 100.

«Стоит дифференцировать операторов данных: ввести несколько рангов, которые будут зависеть от объема накапливаемых данных, способности автономно решать сложные задачи и в целом от стратегического назначения оператора, — пояснил замглавы РКН Милош Вагнер, выступая в Питере на международном юридическом форуме (ПМЮФ). — Например, операторы первого ранга могли бы помогать операторам поменьше, взяв на себя функции по защите информации и контролю доступа к ней, по проведению аудитов и прочего. Операторам низшего ранга также стоит предоставить возможность работать с минимальным количеством данных, не накапливать их, не передавать третьим лицам».

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

Стремясь получить нужный доступ, многие принимают условия, не вдаваясь в подробности,  и в итоге их данные могут разойтись по 20-30 организациям, с которыми потом придется контактировать.

Действующий с 2006 года Закон об обработке персональных данных (№152 –ФЗ), по мнению Вагнера, давно требует модернизации. Назрели, к примеру, поправки, предусматривающие простой механизм отказа от обработки персданных — за один клик.

Необходимо также составить детальные инструкции по хранению такой информации для операторов ПДн и узаконить их право на использование доверенных систем идентификации. В случае утечки базу обезличенных идентификаторов и транзакционных данных будет сложно расшифровать и использовать со злым умыслом.

В начале текущего года эксперты отметили, что объем утечек в России существенно возрос. По данным РКН, с января в Сеть было слито свыше 510 млн записей ПДн; регулятор при этом зафиксировал лишь 19 фактов утечки. По итогам 2023 года эти показатели составили 300 млн и 168 соответственно.

Ввиду роста угрозы Национальный координационный центр по компьютерным инцидентам (НКЦКИ) запустил онлайн-сервис проверки утечек, аналогичный Have I Been Pwned. С его помощью пользователи смогут самостоятельно контролировать сохранность своих данных.

Популярную ИИ-библиотеку LiteLLM заразили бэкдором через PyPI

В экосистеме ИИ-разработки всплыла неприятная история: исследователи из Endor Labs обнаружили, что популярная Python-библиотека LiteLLM, у которой больше 95 млн загрузок в месяц, была скомпрометирована в репозитории PyPI. Через заражённые версии злоумышленники распространяли многоступенчатый бэкдор.

Речь идёт о версиях 1.82.7 и 1.82.8. Причём в официальном GitHub-репозитории проекта такого вредоносного кода не было.

Проблема возникла именно в пакетах, опубликованных в PyPI: туда попал файл с закладкой, который декодировал и запускал скрытую нагрузку сразу после импорта библиотеки.

Во второй заражённой версии, 1.82.8, схема стала ещё жёстче. Пакет устанавливал .pth-файл в директорию site-packages, из-за чего вредоносный код мог запускаться вообще при любом старте Python, даже если сам LiteLLM никто не импортировал.

После запуска зловред начинал искать самое ценное: SSH-ключи, токены AWS, GCP и Azure, секреты Kubernetes, криптокошельки и другие конфиденциальные данные. Если заражение происходило в контейнерной или кластерной среде, вредонос пытался двигаться дальше по инфраструктуре, в том числе через развёртывание привилегированных подов на узлах Kubernetes.

Для закрепления на хосте атакующие, как сообщается, ставили systemd-бэкдор sysmon.service, который регулярно связывался с командным сервером и мог получать новые команды или дополнительные вредоносные модули.

Специалисты считают, что за атакой стоит группировка TeamPCP, которая в последнее время явно разошлась: до этого её уже замечали в инцидентах, затронувших GitHub Actions, Docker Hub, npm и OpenVSX.

Украденные данные, по информации исследователей, шифровались и отправлялись на сервер атакующих. Для маскировки использовались домены, внешне похожие на легитимные, например models.litellm[.]cloud и checkmarx[.]zone.

Сейчас разработчикам и DevOps-командам советуют как можно быстрее проверить окружение. Последней известной чистой версией LiteLLM считается 1.82.6. Если в системе использовались 1.82.7 или 1.82.8, нужно проверить наличие файла litellm_init.pth, артефактов вроде ~/.config/sysmon/sysmon.py и сервиса sysmon.service.

RSS: Новости на портале Anti-Malware.ru