Оборотные штрафы за утечки начнутся с 10 тысяч пострадавших

Оборотные штрафы за утечки начнутся с 10 тысяч пострадавших

Оборотные штрафы за утечки начнутся с 10 тысяч пострадавших

Компании получат оборотные штрафы, если допустят утечку информации более чем 10 тыс. субъектов персональных данных. Такой вариант обсуждается в Минцифры. Законопроект обещают показать в середине сентября.

О подвижках в работе над законопроектом о штрафах за утечки пишет сегодня РБК. Обсуждение началось еще в мае, после громких скандалов с Яндекс.Едой, Delivery Club и Гемотестом.

Обсуждалось, что штраф составит от 1% до 3% оборота. Однако крупные ИТ-компании просили смягчить формулировки документа. Как альтернативу они предлагали трехступенчатую систему наказания: предупреждение за первую утечку; крупный штраф — за вторую; при третьей утечке выплачивается оборотный штраф.

В середине июля Минцифры сообщало, что обсуждаемые предложения включают следующие:

  • штрафы будут применяться в два этапа: за первую утечку — фиксированный (размер зависит от объема данных), при повторной утечке станет применяться оборотный штраф. Будут установлены границы, “от” и “до” какого процента от выручки можно будет взыскать оборотный штраф;
  • будут учитываться смягчающие и отягчающие обстоятельства при определении размера штрафа. Вкладывалась ли компания в защиту информации или пыталась скрыть утечку;
  • будет определено, как устанавливать вину конкретной компании за утечку данных: как отличить, произошла ли новая утечка или мошенники выдают за нее данные из разных баз, слитых ранее;
  • рассматривалась возможность создания специального фонда, в который будут перечислять собранные штрафы и из которого станут выплачивать компенсации гражданам, пострадавшим от утечек.

Сейчас обсуждается, что оборотный штраф может грозить компаниям в том числе и за первую утечку, если она коснулась более 10 тыс. субъектов персональных данных.

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

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

Еще один источник РБК на ИТ-рынке говорит, что обсуждение формулировок законопроекта продолжается и они еще могут поменяться. Например, ранее в ходе обсуждений звучали предложения ввести личную уголовную ответственность за утечки персональных данных, но “пока от этой идеи вроде отказались”.

Предварительные сроки предоставления документа — середина сентября.

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

Вышла утилита RKN Block Checker для диагностики блокировок

Разработчик Дмитрий Виноградов представил утилиту RKN Block Checker с открытым исходным кодом. Она помогает понять, почему конкретный сайт не открывается: это обычная сетевая проблема или блокировка на стороне провайдера / регуляторной инфраструктуры.

Проект написан на Python и опубликован под лицензией MIT. Утилита работает из командной строки и проверяет соединение по цепочке DNS → TCP → TLS → HTTP.

Идея простая: не просто выдать вердикт, что сайт недоступен, а показать, на каком именно уровне всё сломалось. Например, если системный DNS не даёт нормальный ответ, а Cloudflare DoH возвращает корректный адрес, это может указывать на DNS-подмену. Если TCP-соединение на 443-й порт сбрасывается, речь может идти о блокировке на уровне IP.

Если TCP проходит, но соединение рвётся на TLS-рукопожатии с SNI, это уже похоже на работу DPI / ТСПУ. А если сайт открывается, но вместо страницы приходит заглушка провайдера или код 451, утилита фиксирует и такой сценарий.

 

Автор отдельно подчёркивает, что смысл RKN Block Checker не в том, чтобы заменить браузер. Браузер и так сообщает, что сайт не открылся. Здесь задача другая — разложить проблему по слоям и дать пользователю более понятную картину, где именно произошёл сбой и на что это похоже.

Утилита сравнивает ответы системного DNS и DNS over HTTPS через Cloudflare, проверяет обычное TCP-подключение, запускает TLS-handshake с SNI целевого домена и затем делает HTTP-запрос. Вердикт выставляется по первому уровню, на котором возникла ошибка.

 

У проекта есть и ограничения. Пока поддерживается только IPv4. Списки целей жёстко заданы в коде и включают около 20 сайтов на категорию, поэтому инструмент не поймает все частные случаи. Кроме того, это разовая проверка без повторов и долгосрочного мониторинга, хотя JSON-вывод можно использовать в cron для регулярных запусков.

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