Как происходят утечки персональных данных и что делать в такой ситуации?

**Как происходят утечки персональных данных и что делать в такой ситуации?**

К концу октября в сетях распространились сообщения о том, что произошла утечка персональных данных граждан Узбекистана, в частности, ПИНФЛ, адресов и паспортных данных. Некоторые пользователи заявили, что нашли свои данные в Telegram-ботах, и опубликовали подтверждающие скриншоты на своих страницах.

После столь тревожных сообщений Центр кибербезопасности при МВД и СГБ сообщил о начале проверки. Однако, хотя идет уже первая неделя ноября, официальные лица до сих пор не объявили о результатах. На какой стадии находятся исследования в настоящее время, также неизвестно.

Как на самом деле и через какие источники происходят утечки данных? Что делать обычному пользователю и компании в подобной ситуации? Что определяет безопасность и надежность приложений? Как узнать, передаются ли данные на другой сервер? Эксперт по кибербезопасности Акмаль Содиков ответил на эти вопросы в беседе с «Газетой». Ниже приводится полный текст интервью.

— Кажется, что в последние годы случаи утечки персональных данных граждан стали наблюдаться чаще. Как вы относитесь к этой ситуации?

— Увеличение утечек персональных данных характерно не только для Узбекистана, но и для всего мира. По мере цифровизации государственных услуг в одном приложении аккумулируется больше данных, а значит, увеличивается и количество целей, стоящих нападения. Без технических доказательств по конкретному приложению трудно сказать «да» или «нет», вероятность есть, но ее необходимо проверять.

Большинство баз, распространяемых с утверждениями «произошла утечка данных из такого-то приложения», на самом деле представляют собой подборки, собранные из старых баз. А иногда данные утекают не из самого приложения, а из другого места, имеющего доступ к государственной системе, к которой подключено приложение. По этой причине каждый случай должен проходить независимую техническую проверку, а ее результаты должны публиковаться открыто. Однако следует также сказать, что нет разницы, являются ли персональные данные старыми или новыми — эта информация все равно остается актуальной. Подобную информацию можно использовать во многих целях.

— Откуда обычно утекают данные? Что становится причиной этого?

— На практике большинство утечек происходит на стороне сервера, а не в самом приложении. Наиболее распространенные причины:

1. Ошибки авторизации в API. Сервер не проверяет, имеет ли право отправляющий запрос пользователь видеть эти данные. В результате, изменив ID в запросе, можно получить данные другого человека. Это самая распространенная уязвимость в мире.

2. Неправильно настроенные хранилища. Оставшиеся открытыми без пароля в интернете базы данных, резервные копии, тестовые серверы также открывают путь к утечке данных.

3. Инсайдеры. Это могут быть сотрудники организаций, имеющих доступ к базе или интегрированных с ней; большая часть сервисов «пробива» в Telegram работает именно таким образом.

4. Сторонние сервисы. Сюда входят аналитические и рекламные SDK (Software Development Kit) внутри приложения, SMS-шлюзы, облачные сервисы.

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

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

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

— Какими способами можно получить данные, вводимые в приложение? Легкий ли это процесс?

— Основными путями являются следующие:

1. Массовый скачивание из незащищенного API (например, последовательный перебор номеров телефонов или автомобильных номеров);

2. Взлом сервера;

3. Злоупотребление внутренними правами доступа;

4. Вредоносные программы и фишинг на телефоне пользователя.

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

— Означает ли однократная утечка данных, что система была взломана?

— Не всегда. «Взлом» и «утечка» — это разные вещи. Данные могут утечь и без всякого взлома, например, из-за оставшейся открытой базы, API без авторизации, продажи информации сотрудником или ошибки в партнерской организации. Но каким бы путем это ни произошло, это показывает, что контроль безопасности не сработал, и ответственность за оператором в любом случае сохраняется.

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

— Основной метод — анализ содержимого утекшего массива. Нужно посмотреть, есть ли в нем поля, внутренние идентификаторы, формат записей и диапазон дат, характерные только для одной системы. После этого данные сопоставляются с активностью в журналах этой системы, то есть проверяется, какой аккаунт или IP-адрес и когда отправлял запросы в нетипичном объеме. Для надежного подтверждения необходимы:

1. Журналы сервера и API (кто, когда, запрашивал какие записи);

2. Аудит доступа к базе данных;

3. Точное сопоставление записей из утекшего образца с записями в системе;

4. По возможности, результаты по специально отмеченным «записям-ловушкам» (canary records).

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

— Как обычный пользователь при использовании приложения может проверить безопасность данных? На что именно следует обратить внимание в политике конфиденциальности?

— В Google Play есть разделы «Data safety» (Безопасность данных), а в App Store — «App Privacy». В них указывается, какие данные собирает приложение и кому их передает. В политике конфиденциальности необходимо смотреть на следующее:

1. Какие именно данные и с какой целью собираются;

2. Кому передаются (третьи стороны, партнеры, рекламные сети);

3. Где хранятся (согласно законодательству Узбекистана, данные граждан должны находиться на серверах на территории страны);

4. Какой срок хранятся и как их можно удалить;

5. Кто является оператором и как с ним связаться.

Если политика конфиденциальности отсутствует, состоит из общих слов или скопирована из другого приложения — это признак риска.

— Насколько нормально, если приложение запрашивает разрешения, не имеющие отношения к его функциям, например, доступ к контактам, микрофону, SMS или местоположению? Может ли такое разрешение стать серьезной угрозой?

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

— Что означает получение согласия пользователя на сбор приложением персональных данных? Дает ли само по себе предоставление согласия разрешение на хранение и передачу данных любым способом?

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

— Можно ли проверить, на какие серверы приложение отправляет данные через интернет?

— Можно. На iPhone раздел «Настройки — Конфиденциальность и безопасность — Отчет о конфиденциальности приложений» показывает, к каким доменам обращалось каждое приложение. На Android такие инструменты, как PSAPdroid или NetGuard, позволяют просматривать трафик без root-прав. Сервис Exodus Privacy определяет отслеживающие SDK (трекеры) внутри приложения. Специалисты же с помощью mitmproxy или Burp Suite анализируют и содержимое запросов. Если приложение отправляет данные на иностранные серверы, особенно на домены с неизвестными названиями, на это следует обратить серьезное внимание.

— Что определяет безопасность приложения? Насколько правильно оценивать ее по его популярности, количеству скачиваний или репутации разработчика?

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

— Какие дополнительные риски влечет за собой установка приложения не из Google Play или App Store, а из Telegram-канала или через APK-файл?

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

В Узбекистане большая часть случаев хищения денег с банковских карт происходит именно через APK-файлы, отправленные под предлогом «проверьте штраф» или «посмотрите фотографии». Кроме того, пользователь, единожды давший разрешение на «установку из неизвестных источников», остается открытым и для последующих атак.

— Если у человека утекли Ф.И.О., номер телефона, номер автомобиля и данные ПИНФЛ, что ему следует сделать в первую очередь? Какую угрозу это создает?

— Основная угроза — социальная инженерия. Мошенник, точно зная ваши данные, может убедительно позвонить под видом сотрудника банка, СБДД или другого государственного органа и запросить SMS-код или данные карты. Кроме того, есть риск попытки оформления онлайн-микрозайма на ваше имя, переоформления SIM-карты и целевого обмана (фишинга). Что нужно делать:

1. Никому не сообщать SMS-коды и данные карт. Настоящий сотрудник банка или государства никогда не затребует их, особенно через Telegram: Telegram не является официальным каналом обмена информацией;

2. Включить дополнительную защиту и двухэтапную аутентификацию в банковских приложениях и на my.gov.uz;

3. Периодически проверять через кредитное бюро кредиты, открытые на ваше имя;

4. Узнать у мобильного оператора о возможности установки ограничения на перевыпуск SIM-карты;

5. При подозрительных ситуациях немедленно обращаться в банк и правоохранительные органы.

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

1. Устранение источника.

Закрытие уязвимого API или открытой базы, блокировка компрометированных аккаунтов, замена ключей, токенов и паролей.

2. Сохранение доказательств.

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

3. Оценка масштаба.

Какие данные, сколько пользователей, за какой период.

4. Уведомление уполномоченных органов.

Центр кибербезопасности и уполномоченный государственный орган в сфере персональных данных.

5. Открытое информирование пользователей.

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

6. Мониторинг.

Отслеживание распространения данных в Telegram-каналах и даркнете.

7. Можно ли полностью удалить утекшие персональные данные из интернета? Что может сделать пользователь, если данные скопированы и распространены повторно?

— К сожалению, на практике это невозможно. Как только данные скопированы, они расходятся по десяткам каналов и архивов. Блокировка отдельных каналов или сайтов и жалобы на платформы уменьшают распространение, но не уничтожают данные полностью. Существуют некоторые платные сервисы, предлагающие услугу «скрытия информации», но это лишь скрывает результат в них, сама же база остается в архивах других систем. А платить за это означает финансировать именно этот рынок.

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

— Какие технические требования, по вашему мнению, необходимы для приложений, работающих с персональными данными в Узбекистане?

1. Обязательный независимый пентест перед запуском. Для приложений, интегрированных с государственными базами, это должно повторяться ежегодно. Необходимо проверять соответствие международным стандартам, таким как OWASP MASVS и ASVS.

2. Минимизация и маскирование данных. Не должны собираться данные, не требуемые для работы приложения, ПИНФЛ и номер телефона должны быть частично скрыты на экране и в ответах API.

3. Защита API. Проверка авторизации при каждом запросе, ограничение количества запросов и выявление попыток массового скачивания.

4. Шифрование. Данные должны быть зашифрованы как при передаче, так и при хранении.

5. Аудит доступа. Фиксация того, кто, когда и какую запись просматривал. Это особенно касается сотрудников и интегрированных партнеров, так как это самое эффективное средство против «пробива».

6. Перечень и контроль сторонних SDK.

7. Открытый канал для сообщений об уязвимостях. Исследователь, найдя уязвимость, должен знать, кому написать.

8. Строгое установление сроков оповещения об инциденте. Как уполномоченного органа, так и пользователей.

9. Контроль фактического выполнения требования о локализации данных.

Самое главное, эти требования не должны оставаться на бумаге, их нужно проверять на практике, а для нарушивших операторов должна быть реальная ответственность.