Утечки персональных данных из приложений: реальные кейсы и уроки конфиденциальности

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

За 2025 год Роскомнадзор зафиксировал 118 случаев компрометации баз персональных данных: в открытый доступ попали более 52 млн записей. Годом ранее ведомство сообщало о 135 утечках и более чем 710 млн записей. Сравнивать эти цифры как прямой показатель улучшения защиты не стоит: число инцидентов и объём попавших в сеть данных — разные вещи. Но масштаб показывает главное: мобильная безопасность заканчивается не на экране смартфона. За приложением стоят серверы, подрядчики, рекламные модули и люди с доступом к данным.

Приложение — только витрина. Где на самом деле теряются данные

Когда говорят о безопасности приложения, обычно вспоминают разрешения: доступ к контактам, геолокации, микрофону. Это понятная часть контроля, но только верхний слой. Пользователь нажимает кнопку в интерфейсе, а запрос уходит на сервер. Там он проходит через API, может попасть в базу, аналитическую систему и сторонние сервисы. Ошибка в любом звене способна раскрыть сведения, которые сам телефон хранил вполне аккуратно.

Причины утечки данных пользователей обычно складываются в несколько групп:

• Ошибки серверной архитектуры. Неправильные настройки доступа, слабая проверка запросов или уязвимость API могут открыть данные не тому аккаунту или вообще сделать их доступными извне. Клиентское приложение в таком случае бывает написано безупречно. Проблема живёт за его пределами.
• Небезопасное хранение на устройстве. Если приложение оставляет чувствительные сведения в локальных файлах без должной защиты, риск возникает при потере телефона, заражении вредоносной программой или получении доступа к устройству посторонним.
• Сторонние SDK. Это подключаемые библиотеки для рекламы, аналитики, уведомлений и других функций. Они могут собирать технические параметры устройства и пользовательские сведения, а затем передавать их дальше по цепочке интеграций.
• Человеческий фактор. У сотрудника может быть избыточный доступ к базе, учётная запись может оказаться скомпрометирована, а внутренние правила — существовать только в презентации для руководства.
• Внешняя атака. Киберпреступники могут получить доступ к инфраструктуре сервиса или воспользоваться уже известной уязвимостью. Это лишь один сценарий, а не универсальное объяснение каждой утечки.

Для обычного пользователя эти механизмы выглядят одинаково: после инцидента в сети появляются телефон, адрес или история заказов. Но для оценки риска разница существенна. Если скомпрометирован пароль, его нужно менять; если утекли адрес и телефон, сменить их нельзя. И если приложение сообщает о проблеме, полезно понять, какие именно категории данных затронуты, а не успокаиваться общим словом «инцидент».

Телефон может быть защищён паролем и обновлён до последней версии. Это не закрывает дыру в базе сервиса, который хранит ваши заказы и адрес.

Доставка: удобный сервис, подробный цифровой след

У сервисов доставки есть неприятная особенность: чтобы привезти заказ, им нужны сведения, по которым человека можно найти в реальном мире. Телефон, адрес, время доставки, состав заказа. Это не абстрактная статистика о кликах. Такой набор способен раскрыть привычки и распорядок пользователя, даже если пароли и платёжные данные не затронуты.

В марте 2022 года Яндекс Еда подтвердила утечку, связанную с недобросовестными действиями сотрудника. В открытый доступ попали номера телефонов клиентов и данные об их заказах: состав, адрес и время доставки. Сервис сообщал, что платёжные данные и пароли скомпрометированы не были. Это разграничение важно: не стоит превращать подтверждённый инцидент в более тяжёлую историю, которой факты не подтверждают. Но и без банковских реквизитов утёкшие сведения могут быть полезны для адресного спама и фишинга.

СДЭК в 2022 году столкнулась с серией кибератак и масштабной утечкой. В сеть попали базы объёмом в сотни миллионов строк с именами, телефонами и адресами доставки. Здесь виден другой риск: даже если одна строка кажется безобидной, массив данных позволяет связывать сведения и массово использовать их для мошеннических рассылок.

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

Поэтому после сообщения об утечке я бы разделял действия по типу данных:

1. Если затронуты пароль или учётная запись, сменить пароль и завершить неизвестные активные сеансы. Повторно используемый пароль стоит заменить и на других сервисах: иначе одна утечка превращается в ключ к нескольким аккаунтам.

2. Если утекли телефон и адрес, настороженно относиться к звонкам и сообщениям, где собеседник торопит, просит назвать код или перейти по ссылке. Код подтверждения не становится безопасным оттого, что собеседник знает, что вы заказывали.

3. Если указаны платёжные данные, следовать рекомендациям банка и проверять операции по карте. При этом не надо автоматически считать, что любая утечка клиентской базы затронула данные карт: это выясняют отдельно.

4. Если сервис описывает инцидент расплывчато, смотреть на конкретику: какие категории сведений затронуты, когда обнаружена проблема и какие меры предприняты. Формулировка «данные пользователей могли быть доступны» сама по себе не отвечает на вопрос, что именно оказалось под угрозой.

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

Скрытый сбор: что привозят сторонние библиотеки

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

Библиотека может собирать системные параметры и другие сведения, а затем передавать их в собственные сервисы или дальше по каскаду интеграций. Чем длиннее цепочка, тем труднее обычному человеку понять, где заканчивается приложение и начинается чужая инфраструктура. Разработчик может видеть только ближайший SDK, тогда как тот сам зависит от других компонентов. Такая архитектура напоминает цифровую матрёшку, только внутри лежит не игрушка, а пользовательская телеметрия.

Это не означает, что любой SDK шпионит за владельцем смартфона. Аналитика сама по себе нужна разработчику: без неё трудно понять, где приложение падает, какая функция работает плохо и почему пользователи бросают экран регистрации. Вопрос в объёме собираемых сведений, цели сбора, сроках хранения и контроле над тем, кому они уходят.

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

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

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

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

Утечка и закон: уведомить быстро, расследовать отдельно

В российском законодательстве обязанности оператора персональных данных не заканчиваются на публикации короткого сообщения для пользователей. По части 3.1 статьи 21 152-ФЗ о факте утечки нужно уведомить Роскомнадзор в течение 24 часов с момента обнаружения. Результаты внутреннего расследования направляются в течение 72 часов. Это разные этапы: первый срок относится к первичному уведомлению, второй — к итогам выяснения причин и обстоятельств.

За нарушение сроков уведомления предусмотрена отдельная ответственность. Для юридических лиц штраф за неуведомление об инциденте составляет от 1 до 3 млн рублей. Поправки, связанные с ФЗ № 420-ФЗ, усилили ответственность за сами утечки. По приведённым в законе категориям штрафы могут составлять 3–5 млн рублей за компрометацию данных от 1 тыс. до 10 тыс. субъектов и 10–15 млн рублей за утечку сведений более чем о 100 тыс. человек. За повторные крупные инциденты предусмотрены оборотные штрафы от 1% до 3% годовой выручки, с установленными пределами от 20 до 500 млн рублей.

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

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

Я бы не оценивал безопасность сервиса по одному факту, что он публикует политику конфиденциальности или заявляет о соответствии требованиям. Документ может быть аккуратным, а доступы к базе — раздутыми. Намного полезнее наблюдать, как компания ведёт себя после инцидента: сообщает ли, какие сведения затронуты, отделяет ли подтверждённые факты от предположений и объясняет ли, что делать пользователю. Это не отменяет саму утечку, но помогает понять, пытается ли сервис разобраться или просто переждать новостной цикл.

Что может сделать пользователь, пока сервисы собирают данные

Полностью исключить утечку со стороны компании пользователь не может. Зато можно уменьшить последствия и не помогать злоумышленникам собирать недостающие фрагменты.

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

Для повседневной цифровой гигиены пригодятся и другие меры:

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

Отдельная ловушка — желание поставить на телефон очередной «защитный» сервис после новости об утечке. Приложение с обещанием тотальной приватности само может просить широкие разрешения и отправлять телеметрию. Дополнительная программа не обязательно добавляет защиту; иногда она добавляет ещё одного посредника. Тут работает скучное правило: устанавливать стоит то, чью функцию вы понимаете и без чего действительно не обойтись.

Мой вывод простой: безопасность личной информации в смартфоне зависит не только от самого смартфона. Телефон контролирует разрешения и хранит часть данных, но сведения о заказах, адресах и аккаунтах живут ещё и у сервисов, подрядчиков и внутри аналитических систем. Поэтому полезно разбирать каждый инцидент по фактам: что утекло, откуда это взялось и какие действия действительно уменьшают риск. Установить защиту от всего одной кнопкой не получится. Зато можно не отдавать приложению лишнее, не повторять пароли и не превращать утёкшую деталь из заказа в пропуск к своему аккаунту.