Всё о новых штрафах за утечки данных. Сколько светит и как защитить своё приложение

от автора

В 2023 году Роскомнадзор выявил 168 утечек персональных данных, затронувших 300 млн записей о клиентах Сбера, Спортмастера, Здравсити, МТС Банка и других крупных компаний. Суды рассмотрели 87 дел и назначили штрафы на общую сумму почти в 5 млн рублей. Таких «щадящих» наказаний за нарушения в работе с данными больше не будет, ведь на этой неделе Госдума ужесточила ответственность за подобные инциденты. Суть изменений в том, что для компаний штрафы вырастут до 3% от выручки или до 500 миллионов рублей. 

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

Откуда вообще взялись штрафы за утечку данных в 3% от выручки

Госдума ужесточила наказания по двум причинам:

Причина первая — слишком много данных пользователей утекает. Число взломов растёт, по мнению правительства страдают все: и сами граждане, данные которых попали в сеть; и компании, которые несут за это ответственность. Если в прошлом году утекло 300 млн записей, то с начала 2024 года — уже 1 миллиард, из которых 500 миллионов в результате одной утечки. Данные 80% россиян — имена, возраст, почты, телефоны, адреса и данные банковских карт — просто лежат в интернете.

Причина вторая — маленькие штрафы не сработали. До изменений компании платили 100–300 тысяч рублей за потерю данных. Например, Яндекс.Еда выплатила всего 60 тысяч рублей, когда ее сотрудник слил имена, телефоны, адреса и суммы заказов пользователей за полгода. Настолько крупные компании и сервисы не замечают столь малые суммы и не слишком мотивированы вкладываться в безопасность.

В итоге правительство нашло выход в привязке штрафов к оборотам и выручкам компаний. Если компании теряет пользовательские данные впервые, то платит до 15 млн рублей, если второй раз — до 3% выручки или до 500 млн рублей. Видимо, логика тут в том, чтобы заставить бизнес почувствовать ощутимые последствия и на контрасте сделать инвестиции в безопасность выгоднее.

Для должностных лиц в таких компаниях всё сложнее: они отдельно платят до 2 млн рублей при повторной утечке. И условный руководитель или технический директор продукта может получить штраф в 400–600 тысяч рублей за то, что кто-то потерял 100 тысяч строк из базы данных.

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

Почему данные утекают из приложений

Число утечек растёт по четырём причинам:

  1. Стало больше уязвимостей в ПО из-за санкций. Эксперты RosCo считают, что санкции усложняют обновление приложений, а в устаревших продуктах появляется больше дыр в безопасности.

  2. Новые формы атак от хакеров и мошенников. Бизнесу и продуктам приходится противостоять разнообразным мошенническим схемам: программам-вымогателям, вирусам-шифровальщикам, фишингу, атакам на системы защищенной передачи данных и промышленному шпионажу.

  3. Несерьёзное отношение компаний. Судя по статистике даже после утечки треть организаций не принимали мер по устранению дыр. Ощутимых штрафов не было, поэтому безопасность отходила на второй план. 

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

Как проверить приложение с пользовательскими данными на безопасность: пошаговая инструкция

Переходим к самому главному — разберём пошагово, что владелец приложения магазина или ресторана, аудитор и технический директор могут сделать, чтобы из приложения не украли персональные данные клиентов.

Шаг 1. Проверить партнёрские сервисы перед интеграцией

В чём смысл проверки

Недавно был случай, который наглядно показал необходимость такой проверки. СМИ написали об «утечке» данных пользователей из приложения Бургер Кинга, которое мы, кстати, делаем. Среди утёкших данных были записи о популярных блюдах, которые не собирает клиентское приложение.

Оказалось, что хакеры взломали маркетинговую платформу Mindbox и украли личные данные 6 млн клиентов. Да, инцидент произошёл по вине стороннего интегрированного сервиса. Зато бизнесу стало понятно, что даже выверенное по безопасности приложение может оказаться под ударом.

Когда стоит проводить

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

Допустим, магазин косметики хочет собрать базу посетителей и рассылать им купоны на почту. Для этого надо подключить сервис для сбора и хранения контактов вроде GetResponse и платформу для рассылки — Unisender или что-то подобное. Каждый из этих сервисов нужно проверить.

Как проводить проверку

  1. Проверяем сертификаты и стандарты. Это делают бизнес-аналитики (BA). На сайте поставщика они должны найти подтверждение, что его программы соответствуют ГОСТ Р 57580, ГОСТ Р 51188-98, ГОСТ Р ИСО/МЭК 15408, ISO/IEC 27001 и PCI DSS (для финтеха).

  2. Изучаем документы по политике безопасности. Аналитики изучают документы, в которых описаны меры при обнаружении уязвимостей, узнают, кто несёт ответственность за возможные утечки и как устраняет их последствия.

  3. Проверяем нежелательные взаимодействия. Если партнёрский сервис будет иметь доступ к данным пользователей, BA узнают, реализована ли изоляция данных. Убедиться в этом на 100% сложно, так как партнёры редко соглашаются на аудиты безопасности, но стоит хотя бы посмотреть их отзывы и заявления.

  4. Тестируем внешние API и SDK для интеграции. Разработчики внедряют безопасные методы аутентификации, например, OAuth 2.0, OpenID Connect или Единую систему идентификации и аутентификации (ЕСИА). Проверяют, что используется криптографический протокол SSL, то есть данные защищены в процессе передачи.

Шаг 2. Проверить текущие интеграции

В чём смысл проверки

Если интеграции с какими-то сервисами уже есть, нужно проверить их на безопасность. Тут было бы хорошо узнать, обновлено ли ПО поставщика услуг и соответствует ли новая версия требованиям безопасности. И проверять всё это стоит не разово, а регулярно.

Когда нужно проводить

Если ИТ-продукт уже интегрирован со сторонними системами аналитики или сервисами рекомендаций и платежей. Например, приложение аптеки умеет отправлять push-уведомления, чтобы сообщить покупателю, что заказ доставлен, через Firebase Cloud Messaging или OneSignal. После подключения такого сервиса сразу должна проводиться проверка безопасности.

❗️ Если у вашего приложения есть интеграции с иностранными сервисами, всё сложнее. Они могут не идти на контакт и не соглашаться на проверки. В таком случае это риск. Здесь можно проверить условия соглашения, которое вы подписали при подключении, и обратиться в поддержку. Обычно, иностранные сервисы берут на себя обязательства защитить данные.

Как проводить проверку

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

  2. Опционально: регулярно смотрим исходный код. Разработчики периодически проводят аудит кода сервиса и находят изменения, которые могли бы повлиять на защищённость приложения. Не все компании дадут доступ к исходному коду, но попытка не пытка. А в случае успеха вы точно убедитесь, что сервис безопасный.

  3. Проверяем ограничения доступа. Разработчики организуют доступ так, чтобы он был только у авторизованных сервисов и пользователей. Если нужна дополнительная защита, можно внедрить системы вроде Zero Trust.

  4. Проводим тестирование на проникновение. Разработчики могут регулярно проводить penetration-тесты, чтобы выявить новые уязвимости после обновлений продукта.

Шаг 3. Провести аудит продукта и найти опасные места

В чём смысл проверки

Обычно приложение разрабатывают так:

  • На этапе проектирования функциональностей BA и QA-специалисты обращают внимание на риски, связанные с использованием сторонних решений, и подсвечивают это.

  • Во время написания кода команда разработчиков обеспечивает защиту приложения и проверяет интеграции. Затем команда на стороне клиента проводит тестирование, и если есть уязвимости, уведомляет об этом разработчиков. Они устраняют ошибки до релиза.

В реальности на эти проверки не хватает времени, и просто считается, что безопасность — ответственность разработчиков.

Когда нужно проводить

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

Это также пригодится, чтобы проверить, защищён ли корпоративный портал с данными о сотрудниках, кадровой документацией и расписаниями. Или проверить e-commerce-приложение, которое хранит данные о зарегистрировавшихся пользователях.

Как проводить проверку

Что такое аудит продукта. Во время аудита штатный эксперт или компания-подрядчик комплексно оценивает кодовую базу, архитектуру и структуру приложения, изучает процессы разработки и проводит аудит безопасности данных. Обычно полный аудит кода занимает от 2 до 4 недель.

  1. Проводим оценку защиты данных. Аудитор смотрит, как организовано перемещение данных и насколько защищена пользовательская информация. Применяет статический анализ кода (Static Application Security Testing, SAST) и динамический анализ кода (Dynamic Application Security Testing, DAST).

  2. Оцениваем безопасность хранилища данных. Специалист изучает текущие способы хранения баз данных, например, облачное и серверное хранение. Смотрит на наличие резервных копий.

  3. Проверяем соответствие ПО стандартам безопасности и шифрования. Аудитор убеждается, что ПО создано по международным и локальным стандартам в области информационной безопасности.

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

Что ещё может сделать владелец приложения, чтобы повысить безопасность данных

Во-первых, не стоит перекладывать всю ответственность на разработчиков или бизнес-аналитиков. Владелец продукта должен думать о безопасности продукта и шагах по её повышению.

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

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

Также можно:

  • Подумать о внедрении автоматизированных систем контроля DLP (Data Loss Prevention), например, Ростелеком-Солар, InfoWatch, SearchInform или Zecurion. Они помогают предотвратить утечки, предупреждая сотрудников о возможных ошибках.

  • Организовать обучение для команды по вопросам кибербезопасности, рассказать им про методы предотвращения фишинга и порядок работы с конфиденциальной информацией. 

  • Составить график и разработать регламент проведения аудитов безопасности кода и внешних систем. 

  • Определить для своей компании требования к безопасности сервисов партнёров, как сделали в Microsoft.

  • Разработать план действий на случай утечки. Указать в нём риски, процесс идентификации утечки, критерии оценки последствий и правила информирования стейкхолдеров.

Регулярно проверяя продукт и анализируя партнёрские сервисы можно надежно защитить данные от утечек и избежать штрафов. А ещё — сэкономить ресурсы на восстановлении после утечек.

Больше о том, как создавать прибыльные мобильные приложения, мы рассказываем в Telegram-канале «Точка приложения». Заходите в гости.


ссылка на оригинал статьи https://habr.com/ru/articles/862048/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *