СЗПДн. Анализ. Сколько раз нужно посчитать сотрудников?

СЗПДн. Анализ. Сколько раз нужно посчитать сотрудников?

Продолжаем цикл не новых, но ещё актуальных проблем – сколько раз и как нужно учесть сотрудников, участвующих в обработке ПДн?  

Давайте посмотрим как это нужно делать в государственных и муниципальных учреждениях, в соответствии с ПП 221:

“б) утверждают актом руководителя государственного или муниципального органа следующие документы:

перечень должностей служащих государственного или муниципального органа, замещение которых предусматривает осуществление обработки персональных данных либо осуществление доступа к персональным данным;”

Акт – это скорее всего приказ.  Определяем сотрудников, работающих с ПДн, формируем перечень их должностей – скорее всего делать нужно будет 1 раз, далее он будет меняться редко, скорее при изменении орг. структуры.

Непонятно почему осуществление доступа отделили от обработки ПДн? В соответствии с 152-ФЗ доступ – это один из видов обработки ПДн, а точнее один из видов передачи ПДн.

Давайте посмотрим, что по этому поводу в ПП 1119:

“13. Для обеспечения 4-го уровня защищенности персональных данных при их обработке в информационных системах необходимо выполнение следующих требований:

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

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

И опять же вопрос, почему учитываем только имеющих доступ, а не осуществляющих обработку?

Давайте теперь заглянем в ПП 687:

“13. Обработка персональных данных, осуществляемая без использования средств автоматизации, должна осуществляться таким образом, чтобы в отношении каждой категории персональных данных можно было определить места хранения персональных данных (материальных носителей) и установить перечень лиц, осуществляющих обработкуперсональных данных либо имеющих к ним доступ.”

Опять перечень конкретных сотрудников, причем с указанием категорий ПДн.

Посмотрим, есть ли какие-то уточнения в приказе ФСБ России №378:

“5. В соответствии с пунктом 13 Требований к защите персональных данных при их обработке в информационных системах персональных данных, утвержденных постановлением Правительства Российской Федерации от 1 ноября 2012 г. N1119 (далее - Требования к защите персональных данных), для обеспечения 4 уровня защищенности персональных данных при их обработке в информационных системах необходимо выполнение следующих требований:

в) утверждение руководителем оператора документа, определяющего перечень лиц, доступ которых к персональным данным, обрабатываемым в информационной системе, необходим для выполнения ими служебных (трудовых) обязанностей; …

8. Для выполнения требования, указанного в подпункте "в" пункта 5 настоящего документа, необходимо:

а) разработать и утвердить документ, определяющий перечень лиц, доступ которых к персональным данным, обрабатываемым в информационной системе, необходимдля выполнения ими служебных (трудовых) обязанностей;

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

Опять перечень сотрудников. На всякий случай уточняется что его нужно поддерживать в актуальном состоянии.

Теперь предположим, что у нас в качестве мер защиты используются СКЗИ, обеспечения удаленный доступ к ИСПДн с ноутбуков и мобильных устройств или если персональные межсетевые экраны с функциями VPN клиентов используются для организации выделенной защищенной подсети. Исходя из своего опыта могу сказать, что количество пользователей СКЗИ составляет 20% - 100% от количества пользователей ИСПДн. Придется ли считать их ещё раз?

Приказ ФСБ России №378:

“5. В соответствии с пунктом 13 Требований к защите персональных данных при их обработке в информационных системах персональных данных, утвержденных постановлением Правительства Российской Федерации от 1 ноября 2012 г. N1119 (далее - Требования к защите персональных данных), для обеспечения 4 уровня защищенности персональных данных при их обработке в информационных системах необходимо выполнение следующих требований:

а) организация режима обеспечения безопасности помещений, в которых размещена информационная система, препятствующего возможности неконтролируемого проникновения или пребывания в этих помещениях лиц, не имеющих права доступа в эти помещения; …

6. Для выполнения требования, указанного в подпункте "а" пункта 5 настоящего документа, необходимо обеспечение режима, препятствующего возможности неконтролируемого проникновения или пребывания в помещениях, где размещены используемые СКЗИ, хранятся СКЗИ и (или) носители ключевой, аутентифицирующей и парольной информации СКЗИ (далее - Помещения), лиц, не имеющих права доступа в Помещения, которое достигается путем:

…в) утверждения перечня лиц, имеющих право доступа в Помещения.”

Приказ ФАПСИ (ФСБ России) №152:

19.        Физические лица допускаются к работе с СКЗИсогласно перечню пользователей СКЗИ, утверждаемому соответствующим обладателем конфиденциальной информации. До такого утверждения техническая возможность использования СКЗИ лицами, включенными в данный перечень, должна быть согласована с лицензиатом ФАПСИ.

Лицензиаты ФАПСИ в рамках, согласованных с обладателями конфиденциальной информации полномочий по доступу к конфиденциальной информации имеют право утверждать такой перечень в отношении подчиненных им должностных лиц.”

То есть нужно утверждать перечень пользователей СКЗИ, а также перечни доступа в Помещения.

Подведем итог: при обработке ПДн нам нужно подготовить и утвердить руководителем организации 5 перечней разного содержания, связанного с лицами, обрабатывающими ПДн. А эти перечни будут регулярно меняться в связи с увольнением и приемом на работу новых сотрудников или кадровыми перемещениями внутри организации.

Можно ли и нужно ли совмещать это все в одном перечне, включающем в себя перечень лиц, должности, ИСПДн, категории ПДн, СКЗИ, помещения или все-таки вести отдельные перечни? Неплохим вариантом мне представляется учет всех этих данных в каком-то одном месте (системе, БД) из которой автоматически может генерироваться несколько подходящих нам перечней и передаваться на утверждение.

А как вы ведете учет лиц?

Android-ботнет Kimwolf заразил миллионы устройств через прокси

Исследователи зафиксировали масштабную активность Android-ботнета Kimwolf, который, по оценкам компании Synthient, уже заразил более 2 миллионов устройств. Причём делает он это не напрямую, а довольно изобретательно — через сети резидентских прокси, маскируя атаки под обычный пользовательский трафик.

По данным аналитиков, операторы Kimwolf активно монетизируют ботнет сразу по нескольким направлениям: продают установки приложений, сдают в аренду резидентский прокси-трафик и предлагают услуги DDoS-атак. И, судя по масштабам, спрос на всё это есть.

Впервые Kimwolf публично описали специалисты QiAnXin XLab всего месяц назад, обратив внимание на его связь с другим ботнетом — AISURU. Сейчас исследователи считают Kimwolf Android-вариантом этой сети. Более того, есть основания полагать, что именно он стоял за серией рекордных DDoS-атак, зафиксированных в конце прошлого года.

Заражённые устройства превращаются в «транзитные узлы» для вредоносного трафика и используются для DDoS в промышленных масштабах. Основные очаги заражений — Вьетнам, Бразилия, Индия и Саудовская Аравия. Synthient отмечает, что ботнет оперирует примерно 12 миллионами уникальных IP-адресов в неделю.

 

Главная точка входа — Android Debug Bridge (ADB), оставленный открытым и незащищённым. Более 67% устройств в ботнете имеют включённый ADB без аутентификации. Атакующие сканируют Сеть с помощью инфраструктуры на базе резидентских прокси и устанавливают зловред напрямую. В зоне риска — неофициальные ТВ-приставки и смарт-телевизоры, которые нередко поставляются уже с сомнительными SDK.

Отдельный интерес вызывает связь кампании с коммерческими прокси-сервисами. В декабре 2025 года заражения Kimwolf активно использовали IP-адреса, сдаваемые в аренду китайской компанией IPIDEA — крупным поставщиком прокси с миллионами обновляемых IP. После инцидента IPIDEA закрыла доступ к локальным сетям и чувствительным портам, но, по мнению исследователей, ущерб к тому моменту уже был нанесён.

Схема проста: через прокси-сеть атакующие проникают во внутренние сети устройств, на которые установлен прокси-софт, и загружают основной пейлоад. Он слушает порт 40860 и связывается с управляющим сервером для получения команд.

На этом монетизация не заканчивается. Заражённые устройства также получают SDK сервиса Plainproxies Byteconnect, который превращает их в источник платного интернет-трафика. По данным Synthient, инфраструктура использует 119 ретрансляционных серверов и задействуется для атак вида credential stuffing на IMAP-серверы и популярные веб-сервисы.

«Масштаб проблемы оказался беспрецедентным — миллионы устройств были фактически открыты для атак», — отмечают аналитики. — «Особенно тревожный сигнал — обнаружение предустановленных заражённых ТВ-боксов и всё более тесная связка между киберпреступниками и коммерческими прокси-провайдерами».

В качестве мер защиты эксперты советуют прокси-сервисам блокировать обращения к приватным IP-диапазонам (RFC 1918), а организациям и пользователям — жёстко закрывать доступ к ADB и не использовать устройства с подозрительным или неофициальным Android-софтом. В противном случае телевизор или приставка легко могут превратиться в часть чужого ботнета.

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