Что значит обезличить в е услугах
Обезл***вание д***ных — это не просто рандомизация
В банке есть проблема: нужно давать доступ к базе данных разработчикам и тестировщикам. Есть куча клиентских данных, которые по PCI DSS требованиям Центробанка и законам о персональных данных вообще нельзя использовать для раскрытия на отделы разработки и тестирования.
Казалось бы, достаточно просто поменять всё на какие-нибудь несимметричные хеши, и всё будет хорошо.
Дело в том, что база данных банка — это множество связанных между собой таблиц. Где-то они связаны по ФИО и номеру счёта клиента. Где-то по его уникальному идентификатору. Где-то (тут начинается боль) через хранимую процедуру, которая вычисляет сквозной идентификатор на основе этой и соседней таблицы. И так далее.
Обычная ситуация, что разработчик первой версии системы уже десять лет как умер или уехал, а системы ядра, запущенные в старом гипервизоре внутри нового гипервизора (чтобы обеспечить совместимость) ещё в проде.
То есть прежде чем всё это обезличить, сначала надо разобраться в базе данных.
Кто делает обезличивание и зачем?
Обезличиванием или маскированием занимаются потому, что есть законы и стандарты. Да, гораздо лучше тестировать на «снапшоте прода», но за такой залёт регуляторы могут и отозвать лицензию. То есть прикрыть бизнес как таковой.
Любое обезличивание — это достаточно дорогая и неповоротливая прослойка между продуктивными системами и тестированием с разработкой.
Цель проектов по обезличиванию (маскированию) практически всегда — подготовить данные для тестирования, максимально похожие на реальные, хранящиеся в продуктивных базах. То есть если данные содержат ошибки — вместо email забит телефон, вместо кириллицы в фамилии латиница и т. п., то и замаскированные данные должны быть такого же качества, но изменёнными до неузнаваемости. Вторая цель — уменьшение объёма баз данных, которые используются в тестировании и разработке. Полный объём оставляют только под нагрузочное тестирование, а под остальные задачи обычно делается некий срез данных по заранее определённым правилам — усечение БД. Третья цель — получить связанные между собой данные в разных замаскированных и усечённых базах. Имеется в виду, что данные в разных системах, в разное время, должны быть обезличены единообразно.
По вычислительной сложности обезличивание — это примерно как несколько архивирований базы данных на предельной компрессии. Алгоритм примерно похож. Разница в том, что алгоритмы архивирования оттачивались годами и дошли до почти максимального КПД. А алгоритмы обезличивания пишут так, чтобы они хотя бы работали на текущей базе и были достаточно универсальными. И софт после обезличивания вообще заработал. То есть отличный результат — перемолоть 40 ТБ за ночь. Бывает так, что заказчику дешевле загонять в обезличивание базу раз в полгода на неделю на слабеньком сервере — тоже подход.
Как заменяются данные?
Каждый тип данных меняется в соответствии с правилами, которые могут использоваться в коде. Например, если мы заменим ФИО на случайный хеш со спецсимволами и цифрами, то первая же проверка корректности данных сразу выдаст ошибку в реальном тестировании.
Поэтому сначала система обезличивания должна определить, что за тип данных хранится в поле. В зависимости от вендора используются разные подходы от ручной разметки до попыток дискаверинга базы и автоопределения, что же там хранится. У нас есть практика внедрения всех основных решений на рынке. Разберём один из вариантов, когда есть визард, который пытается найти данные и «угадать», что там за тип данных хранится.
Естественно, для работы с этим софтом нужен допуск к реальным данным (обычно это копия недавнего бекапа БД). По банковскому опыту мы сначала два месяца подписываем тонну бумаг, а потом приезжаем в банк, нас раздевают, обыскивают и одевают, потом мы идём в отдельное обшитое клеткой Фарадея помещение, в котором стоят двое безопасников и тепло дышат нам в затылок.
Итак, предположим, после всего этого мы видим таблицу, в которой есть поле «ФИО». Визард уже за нас его разметил как ФИО, и нам остаётся только подтвердить и выбрать тип обезличивания. Визард предлагает случайную замену на славянские имена (есть базы для разных регионов). Мы соглашаемся и получаем замены вроде Иван Иванов Петренко — Иосиф Альбертович Чингачгук. Если это важно, сохраняется пол, если нет — замены идут по всей базе имён.
Следующее поле — дата в юникстайме. Визард это тоже определил, а нам надо выбрать функцию обезличивания. Обычно даты используются для контроля последовательности событий, и ситуации, когда клиент сначала сделал перевод в банке, а потом открыл счёт, никому особо не нужны на тестировании. Поэтому мы задаём небольшую дельту — по умолчанию в пределах 30 дней. Ошибки всё равно будут, но если это критично, можно настроить более сложные правила, дописав свой скрипт в обработку обезличивания.
Адрес должен валидироваться, поэтому используется база российских адресов. Номер карточки должен соответствовать реальным номерам и валидироваться по ним. Иногда бывает задача «сделать все Визы случайными Мастеркардами» — это тоже выполнимо в пару кликов.
Под капотом визарда находится профилирование. Профилирование — это поиск данных в БД по заранее заданным правилам (атрибутам, доменам). Фактически мы читаем каждую ячейку базы данных заказчика, применяем к каждой ячейке набор регулярных выражений, сравниваем значения в этой ячейке со словарями и т. д. В результате чего имеем набор сработавших правил на столбцах таблиц базы данных. Профилирование мы можем настраивать, можем читать не все таблицы в БД, можем брать только определённое количество строк из таблицы или определённый процент строк.
Что происходит внутри?
К каждой записи в базе применяются правила обезличивания, которые мы выбрали. При этом на время работы процесса создаются временные таблицы, куда записываются замены. Каждая последующая запись в БД прогоняется по этим таблицам соответствия замен, и если там есть соответствие — заменяется так же, как раньше. Всё на деле чуть сложнее в зависимости от ваших скриптов и правил сопоставления паттернов (может быть неточная замена, например для родов или замен дат, хранимых в разном формате), но общая идея такова.
Если есть размеченные соответствия «имя кириллицей — имя латиницей», то они должны быть явно обозначены на этапе разработки, и тогда в таблице замен они будут соответствовать друг другу. То есть имя кириллицей будет обезличено, а потом эта обезличенная запись будет сконвертирована в латиницу, например. В этом моменте мы отходим от подхода «не улучшать качество данных в системе», но это один из компромиссов на которые приходится идти ради какой-никакой, но производительности системы. Практика показывает, что если нагрузочное, функциональное тестирование в своей работе не замечает компромисса, то ничего не было. И тут всплывает важный момент, что обезличивание в целом это не шифрование. Если у вас пару ярдов записей в таблице, а в десятке из них ИНН не изменился, то что? То ничего, этот десяток записей не найти.
После окончания процесса таблицы перекодировки остаются в защищённой базе сервера обезличивания. База нарезается (усекается) и передается в тестирование без таблиц перекодировки, таким образом, для тестировщика обезличивание становится необратимым.
Полная обезличенная база передаётся тестировщикам для нагрузочного тестирования.
Это значит, что во время работы с БД таблица перекодировки «пухнет» (точный объём зависит от выбора замен и их типа), но рабочая база остаётся исходного размера.
Как примерно выглядит процесс в интерфейсе оператора?
Общий вид IDE на примере одного из вендоров:
Запуск трансформации из IDE:
Настройка выражения для поиска чувствительных данных в профилировщике:
Страница с набором правил для профилировщика:
Результат работы профилировщика, веб-страница с поиском по данным:
Все ли данные в базе маскируются?
Нет. Обычно список данных под обезличивание регулируется законами и стандартами сферы, плюс у заказчика есть пожелания по конкретным полям, про которые не должен знать никто.
Логика в том, что если мы замаскировали ФИО пациента в больнице, можно маскировать или не маскировать диагноз — всё равно никто не узнает, от кого он. У нас был случай, когда примечания к операции в банке просто маскировали случайными буквами. Там были заметки уровня: «В кредите отказано, так как клиент пришёл пьяным, его вырвало на стойку». С точки зрения отладки это просто строка символов. Ну вот пусть ей и остаётся.
Динамическая seed-таблица это таблица перекодировки в которую складываем уже случившиеся перекодировки. Хеш может быть сильно разный и в случае того же ИНН, чаще генерируется новый случайный ИНН с сохранением первых символов, с контрольными цифрами.
Можно ли менять данные средствами самой СУБД?
Да. При обезличивании данных есть два основных подхода — изменять данные в БД средствами самой БД либо организовать ETL-процесс и менять данные посредством стороннего софта.
Ключевой плюс первого подхода — данные не надо никуда из базы выносить, нет затрат на сеть, используются быстрые и оптимизированные средства БД. Ключевой минус — отдельная разработка под каждую систему, отсутствие общих таблиц перекодировки для разных систем. Таблицы перекодировки нужны для воспроизводимости обезличивания, дальнейшей интеграции данных между системами.
Ключевой плюс второго подхода — неважно, какая у вас БД, система, файл это или какой-то веб-интерфейс, — один раз реализовав какое-то правило, вы можете использовать его везде. Ключевой минус — надо читать данные из базы, обрабатывать их отдельным приложением, записывать в базу обратно.
Практика показывает, что если у заказчика есть набор из нескольких систем, которые требуют дальнейшей интеграции, то реализуемым за конечную стоимость в деньгах, а также за приемлемые сроки разработки может быть только второй подход.
То есть сделать можем всё, что угодно, но в банковском секторе очень хорошо зарекомендовал себя именно ETL-подход.
А почему данные просто не портят вручную?
Один раз так можно сделать. Кто-то просидит три дня, обезличит кучу данных и подготовит базу данных на 500-1000 записей. Сложность в том, что процесс надо повторять регулярно (с каждым изменением структуры БД и появлением новых полей и таблиц) и на больших объёмах (для разных видов тестирования). Обычный запрос — обезличить первые 10-50 ГБ базы так, чтобы этот объём пришёлся на каждую таблицу равномерно.
Что делать, если в базе хранятся сканы документов?
Если документ можно свести к XML и конвертировать обратно (это, например, документы офиса), — можно провести и обезличивание в них. Но иногда бывают бинарники вроде сканов паспортов в PDF/JPG/TIFF/BMP. В этом случае общепринятая практика — нагенерить сторонним скриптом похожих документов и подменять реальные на образцы из базы нагенерённых случайным образом. Сложнее всего с фотографиями, но есть сервисы вроде этого, которые примерно похожим образом решают вопрос.
Кто за что отвечает?
При обновлении после изменения ПО или «вдогонку» процессы попроще.
А что, если на тестах что-то пойдёт не так?
Обычно так и случается. Во-первых, тестировщики после первого прогона обезличивания точнее формулируют требования к базе. Мы можем поменять правила обезличивания или отбраковывать записи вроде «вот тут действия должны идти в хронологическом порядке, а не в хаотичном». Во-вторых, в зависимости от внедрения мы или поддерживаем обезличивание по мере изменения базы, либо оставляем всю документацию, описания структуры БД и типов обработки, передаём весь код обработки (правила в xml/sql) и обучаем специалистов у заказчика.
Расследование: как обезличенные данные становятся персональными и продаются на сторону
Неделю назад мне в очередной раз позвонили и предложили купить какой-то новый автомобиль в салоне, где я точно никогда не бывал. На простой вопрос о том, откуда звонивший взял мой номер телефона и мои имя и отчество, последовал прямой ответ — мы выбрали ваш номер случайным образом из номерной емкости. В это объяснение я не поверил, и решил поинтересоваться тем, как устроен рынок данных и понять, кто может сливать информацию о пользователях и как легко и виртуозно интернет-монополисты обходят стороной закон «О персональных данных» (№152-ФЗ).
Читайте под катом о том, кто монетизирует мои данные и как они попадают в руки компаний, услугами которых я никогда не пользовался — банков, страховых компаний, медицинских центров, застройщиков и прочих организаций с надоедливыми рекламными звонками. И да, это лонгрид, всё как вы любите.
Весну и начало лета 2020 года наша прекрасная страна провела на самоизоляции. Помимо очевидного роста финансовой нагрузки на бизнес, необходимости людям носить повсюду маски и вынужденно работать из дома, этот временной период наглядно показал, насколько легко и просто некоторые участники рынка обращаются с персональными данными россиян.
Предыстория
К написанию этой статьи меня подтолкнуло интервью Тиграна Оганесовича Худаверяна в СМИ (TheBell, Roem) о работе сервиса Яндекса по оценке индекса самоизоляции.
Напомню кратко в чем суть: практически одновременно с объявлением режима «как бы нерабочих дней по всей стране», интернет-гигант Яндекс стал регулярно рапортовать о соблюдении мер по самоизоляции гражданами. Чиновники и СМИ ежедневно обращались к этим данным. И хотя сейчас эта тема плавно уходит на второй план, но вопросы к первоисточнику таких данных никуда не делись.
Поскольку Яндекс и ранее был замешан в скажем так вольготном отношении к пользователям — вспомним хотя бы историю слежки через приложения — то разумно предположить, что данные о текущем местоположении граждан при самоизоляции собирались с помощью мобильных приложений с геолокацией. Да и сам по себе метод слежки через умные гаджеты — очевидный. В столице, например, вообще была вопиющая история — несмотря на обилие нарушений действующего законодательства, ДИТ Москвы заставлял людей подписывать кабальный договор с другим подобным «товарищем майором».
И хотя в своем интервью управляющий директор Яндекса заявляет:
«Мы ни в чем из этого не участвуем. Признаюсь, для нас это больное место, потому что нас постоянно подозревают, что мы в этой слежке участвуем. Но у нас внутри компании есть свой принцип: ни в коем случае, даже в сложной ситуации, не нарушать принципы, которыми «Яндекс» руководствуется со дня основания»
— веры в это нет никакой. Журналисты не задали самый главный вопрос – а на основе каких данных, Яндекс формировал свой «конфиденциальный» рейтинг? Это важно, ведь свободном доступе ответа нет — интернет-гигант просто не раскрывает свою методологию:
Разумно предположить, что под термином «данные об использовании различных приложений и сервисов Яндекса» имеется ввиду именно мониторинг перемещений граждан. Вот только вряд ли кто-то из нас с вами давал прямое согласие на такую слежку.
Как устроен рынок данных
В 90-х продавали базы данных на рыночных развалах с компакт-дисками. В наше время получить список нужных контактов можно еще быстрее — даже ехать никуда не надо.
Очевидные, но нелегальные способы
Чужие данные можно поискать в соцсетях, или в специальных телеграм-каналах, названия пабликов я приводить не буду, уверен, вы и сами их найдете при желании.
Некоторые более продвинутые граждане поступают немного иначе — они размещают на своих сайтах договор-оферту, из которой следует, что данные собираются из публичных источников и даже приводят отсылки на статьи закона, которые как бы разрешают им это делать:
Нюанс только в том, что в документах на сайте «Авито» сказано, что самостоятельно парсить базу контактов интернет-площадки avito.ru прямо запрещено правилами.
Подобным образом продавцы баз в интернете собирают информацию изо всех возможных источников. Все эти методы, будем говорить прямо, незаконны, так как нарушают положения закона «О персональных данных» (№152-ФЗ). Уверен на 100%, что ни один здравомыслящий человек из вот таких баз данных не давал своего согласия на публичное распространение подобными компаниями информации о себе через интернет.
Man-in-the-middle attack
Способ слива информации через сотрудников предприятий, имеющих доступ к базе клиентов тоже очевиден. Не будем уделять слишком много внимания этому аспекту.
Единственный способ борьбы с такими людьми — контроль доступа, грамотное проектирование базы контактов и применение механизмов борьбы со фродом, которые разрабатывают сотрудники информационной безопасности. Последние, к слову, регулярно ловят «продавцов» и передают их правоохранителям.
Завуалированные способы сбора данных
Интернет-компании, скажем прямо, совсем обнаглели и придумали новую методику свободного обращения с данными пользователей. Сегодня все крупнейшие игроки этого рынка собирают про нас, бедных пользователей, такое досье, что им позавидуют Джеймс Бонд, Рихард Зорге, Мата Хари и Остин Пауэрс вместе взятые. Причем, никто из пользователей и не уполномачивал интернет-компании собирать такую фактуру.
У всех на слуху история с американскими выборами, в которых победу республиканцев обеспечил таргетинг рекламы на пользователей Google и Facebook. Причем, эти компании делились данными со сторонней организацией Сambridge Analytics, которая и формировала «целевую аудиторию» рекламных объявлений. Сбором данных промышляют и в Китае — популярная ныне соцсеть тоже недавно прославилась использованием нелегальных методов слежки, которые запрещены даже правилами Google.
Должен сказать, что российский Яндекс внимательно следит за действиями иностранных коллег, и применяет схожие методы — компания прячется за ширмой «обезличенных данных», которая, как показал мой личный опыт непрограммиста, при должной сноровке расшифровывается даже сидя дома на диване.
В декабре прошлого года на РБК появилась интересная статья, в которой рассказывалось про совместный проект Яндекса и Бюро Кредитных Историй (БКИ) по передаче данных о пользовательском поведении в сети. По задумке авторов этого решения, банки смогут получать дополнительную информацию по нужным им персонам от Яндекса, обладая при этом лишь адресом электронной почты и номером мобильного телефона клиента.
Неназванный в статье источник сообщил, что Яндекс получает данные в хэшированном виде, после чего внутренние алгоритмы определяют некую оценку для конкретного человека, и именно эта оценка и возвращается в БКИ. Все это выглядит довольно складно, однако есть нюанс — в статье приводится мнение управляющего партнера УК «Право и бизнес» Александра Пахомова, который также как и я считает, что при выполнении этой процедуры обезличенные данные вновь становятся персональными:
Как обезличенные данные становятся персональными
Попробуем разобраться в том, что происходит «под капотом» у этого сервиса. Сразу скажу, что мне сделать это сложно, так как я часто наслаждаюсь грациозностью великой и прекрасной России, а не провожу рабочие дни на митингах в переговорках современного московского офиса Яндекса. Поэтому, призываю вас поделиться информацией и подправить меня, если я ошибаюсь или в чем-то не прав.
Шаг 1. Хэширование данных
Начнем с изучения того, что именно сам Яндекс вкладывает в понятие «зашифрованные», «хэшированные» или «обезличенные» данные. И поможет нам в этом публичный сервис Яндекс.Аудитория.
Из его описания следует, что сервис позволяет рекламодателям достучаться до своих клиентов. Причем, чтобы добиться этой цели потребуется всего лишь сообщить Яндексу некие идентификаторы клиентов — номера телефонов или адреса электронной почты. Эти данные можно сгрузить в явном виде, например, в виде текстового или табличного файла. А можно — также и в обезличенном виде. Для этого применяется алгоритм хэширования MD5.
Далее сервис работает следующим образом: Яндекс вычисляет конкретного пользователя, зная его персональные данные, и показывает ему таргетированные рекламные сообщения на различных сервисах и порталах Яндекса.
Алгоритм MD5 представляет собой 128-битный алгоритм хеширования. Это значит, что он вычисляет 128-битный хеш для произвольного набора данных, поступающих на его вход.
Детальное описание алгоритма можно найти на Хабре. Нам важно знать, что он был разработан и предназначался для создания и проверки отпечатков сообщений произвольной длины — например, пользовательских паролей или контактов.
Алгоритм MD5 создали в далеком 1991 году, и до 1993 он точно считался криптостойким. Именно тогда исследователи Берт ден Боер и Антон Боссиларис предположили, что в алгоритме возможны псевдоколлизии. Дальше было проведено несколько научных работ на эту тему, которые показали возможность «взлома» MD5. Практическая же реализация была продемонстрирована в 2008 году.
Шаг 2. Расшифровка MD5-хэшей
Технически, взлом MD5 может быть осуществлен одним из четырех способов:
Возьмем, например, любой телефонный номер. Мы точно знаем, что в нем может быть фиксированное число символов, и мы точно знаем, что все эти символы — цифры от нуля до 9. Предположим, что число символов в телефонном номере не превышает 11.
Знание этих критериев позволит быстро получить искомую таблицу с помощью специального программного обеспечения. Типичное содержание такого файла будет выглядеть примерно так:
Далее, вам потребуется взять в качестве референсного значения какой-нибудь условный телефонный номер. Возьмем для примера абстрактный номер 83910123456. Его MD5 хэш будет выглядеть так — fba55dd11f758ab4f03fad3c5f19ba75.
Подставляем этот хэш в софт, указываем расположение таблицы… пара секунд, и вуаля — видим исходный телефонный номер в поле Plaintext!
С адресами электронной почты, как вы уже догадались, дело обстоит ровно так же. Единственная лишь разница в том, что для определения имени почты используется больше данных — в набор символов должны входить буквы, цифры, средства пунктуации и спецсимволы.
В приведённом примере я сознательно не использую «соль» — понятно, что подсоливание хэшей усложняет их взлом. Но об этом немного позже.
Шаг 3. Сопоставление данных
Нет ни малейших сомнений в том, что Яндекс хранит данные в зашифрованном виде. Условно говоря, у поисковика есть профиль каждого зарегистрированного пользователя, где помимо прочего указаны адреса его электронной почты и номер телефона. Такие данные легко хэшируются и, при необходимости (как мы уже убедились выше) — дехешируются.
Далее, получив от рекламодателей в любом виде список контактов, Яндексу не составляет труда сопоставить их со своей внутренней базой, которая содержит эти же идентификаторы. Говоря проще, Яндекс делает кросс-матчинг идентификатора из профиля своего пользователя на соответствие запрашиваемым данным рекламодателя. Это и позволяет таргетированно показывать рекламу конкретному пользователю при заходе на страницу того или иного сервиса Яндекса.
Однозначная идентификация пользователей
Ни о каком обезличенном обмене данными при работе по такой схеме и речи идти не может. Все стороны однозначно идентифицируют конкретного пользователя в процессе оказания услуг. С кредитными бюро, судя по комментариям и описанию, применяется ровно эта же схема. И по всей видимости, на стороне Яндекса используется решение, подозрительно похожее на платформу Крипта.
Однако Яндекс публично никогда не заявлял о возможности сопоставления таких профилей с номерами мобильных телефонов или e-mail своих пользователей. Но, как нам стало известно из материалов СМИ, Яндекс именно это и делает как минимум при работе с Объединенным Кредитным Бюро.
Почему об этом честно не сказать своим клиентам, ведь все и так лежит на поверхности? Вместо этого спикеры Яндекса стыдливо говорят об отсутствии “личной информации» и приводят прочие выдуманные термины, которые отсутствуют в законодательстве РФ и позволяют обойти некоторые вопросы оборота и защиты данных граждан.
Немного практики: Яндекс, я нашел у тебя нарушение 152-ФЗ!
Солит ли Яндекс хэши? Я не могу однозначно ответить на этот вопрос, в конце концов, я не работаю в этой компании и не знаю внутренней кухни. Однако я могу сделать два допущения:
Обратите внимание на вопросительный знак у чекбокса «Хэшированные данные». Давайте перейдем в сам сервис и подведем указатель мыши к этому вопросу.
Видим три хэша: a31259d185ad013e0a663437c60b5d0, 78ee6d68f49d2c90397d9fbffc3814d1 и 702e8494aeb560dff987e623e71bccf8. Причем, в первом явно чего-то не хватает: там всего 31 символ, а должно быть 32! Поэтому, этот хэш отбросим сразу.
Расшифровать вторые два хэша через ранее созданную радужную таблицу я тоже не смог. Но решил попробовать пройтись по ним брутфорсом. Для этого мне потребовалось перенастроить майнинг-ферму из 6 видеокарт класса GeForce GTX1060 с добычи эфира на работу с программой hashcat.
Я указал программе поиск по маске из 11 цифр (см на верхнюю стрелку на скриншоте). В результате, моя вполне обычная ферма произвела дехэширование номера телефона в одном из хэшей всего за 22 секунды. Просто представьте, с какой скоростью можно брутфорсить хэши на мощностях Яндекса!
Теперь давайте определим кому принадлежит этот номер, просто пробьем его через мобильное приложение Numbuster:
Теперь идем в поисковик, и за считанные мгновения получаем всю нужную нам информацию:
Шах и мат, Яндекс, благодаря открытой информации с твоего же сайта, я только что в пару кликов мышью узнал, кто именно делал твой сервис! Надо ли говорить, что такое же действие может легко повторить любой из тех, кто сейчас читает эту статью? За что же вы так с Ярославом-то поступили?
Какие данные могут быть в профиле каждого пользователя
Для использования сервисов Яндекса необходимо указать номер мобильного телефона и электронной почты. Через свои приложения и сервисы Яндекс знает обо мне практически все: от сайтов, которые я посещаю (где стоит Яндекс.Метрика, а таковых в Рунете более 54%), до номера телефона, который я указываю в приложениях. Ему известны мои маршруты из супераппа Яндекс.Go, мои заболевания, предпочтения в музыке. Яндекс знает, в какие театры я хожу, какие фильмы смотрю, какие товары покупаю в магазине и какую еду заказываю.
Эта информация, как утверждают в компании, «используется, в основном, для собственных нужд и размещения таргетированной рекламы за счет знаний о клиентских предпочтениях». Ключевое здесь – «в основном». Раньше считалось, что Яндекс – инновационная компания, которая предоставляет пользователям бесплатные сервисы и зарабатывает на рекламе в Интернете. Но как мы знаем из СМИ, теперь Яндекс как минимум продает данные через Бюро Кредитных Историй — работу самого механизма трансфера данных я покажу чуть ниже. Разумно предположить, что желающих купить у интернет-гиганта информацию о пользователях в привязке к номерам телефонов и адресам электронной почты, будет довольно много.
Другими словами — теперь банки, страховые и юридические компании, медицинские центры, застройщики могут получить номер человека, который заходил на определенный сайт или искал определенный товар, и звонить ему в своих рекламных целях. Или отказать в выдаче страховки или банковского кредита.
Кому Бюро Кредитных Историй продает данные
Не требуется быть особым аналитиком, чтобы понять, что БКИ консолидирует данные о конкретных людях не только для банков. На сайте той структуры, с которой работает Яндекс, можно увидеть, что кроме банковского скоринга клиентам также доступны и другие сервисы:
Сервис «Триггеры Бюро»
В Банки и Страховые компании передается информация о ваших действиях в триггерном режиме:
Обратите внимание на логику работы этого сервиса — вы ставите на мониторинг номера телефонов ваших клиентов, и как только они делают какое-либо действие, которое вас интересует, вы получаете об этом уведомление. При этом данные о конкретных действиях клиента не передаются. Просто факт целевого действия – подача или оформление полиса автострахования, заказ такси и прочее.
Удобно, правда? Особенно с точки зрения объяснения позиции «данные о клиентах не передаются и обрабатываются в Яндексе»? Ведь информацию о действии в виде захода на конкретный web-сайт, можно сообщить, просто передав захэшированный мобильный номер, без каких-либо данных о посещении сайта. А хэш, о чем я говорил выше, можно элементарно сопоставить с хэшами базы пользователей. Можно даже, для упрощения, взять базу всех возможных комбинаций мобильных номеров в России — она доступна на сайте Федерального агентства связи.
Опять получается, что «зашифрованные», «хэшированные», «обезличенные» данные в терминах Яндекса таковыми не очень-то и являются. И уж точно описанная Яндексом схема не мешает продавать эти данные в рамках рассмотренных сервисов кредитных бюро, которые как раз и могут быть тем самым источником спам-звонков на мой телефон.
Страховые компании, получив доступ к данным из картографических сервисов Яндекса и его шедеврального супераппа Яндекс.Go, могут определять:
Законом о GDPR воспользовались журналисты издания Meduza, которые из Литвы запросили данные по одному из своих сотрудников.
В статье Meduza говорится, что журналист получил от сотрудников Яндекса архив, в котором помимо прочего был файл со всей историей перемещений. Информация отслеживалась в тот момент, когда приложение было запущено на смартфоне, в том числе в фоновом режиме. Журналист это называет «историей запуска приложения «Карт» на айфоне с точными координатами, где это происходило» (файл traffic_sessions.csv).
Интересно, что гражданам РФ такая информация компанией Яндекс не предоставляется. Более того, до сего момента Яндекса даже не представил сервис, который позволил бы понять, кто и когда запрашивал накопленные данные о пользователе. Такой сервис есть даже у Facebook — и сам пользователь может запросить и просмотреть всю информацию о себе.
Какую персональную информацию точно собирает Яндекс?
Обратимся к правовым документам на сайте Яндекса. Из пункта 4 мы узнаем, что интернет-гигант может собирать следующие категории персональной информации пользователей во время использования сайтов и сервисов Яндекса:
С какой целью Яндекс собирает все эти данные?
Ответ на этот вопрос можно найти в том же документе, внимательно смотрим пункт №5. Помимо понятных целей, таких как:
предоставление пользователям результатов поиска по поисковым запросам;
соблюдения установленных законодательством обязательств;
чтобы лучше понимать, как пользователи взаимодействуют с сайтами и сервисами,
Яндекс отдельно отмечает, что сбор персональных данных необходим для того, чтобы чтобы предлагать вам другие продукты и сервисы Яндекса или других компаний, которые, по нашему мнению, могут Вас заинтересовать (подпункт пункт «с» пункта 5).
Однако закон «О персональных данных» (№152-ФЗ) категоричен: статья 15 гласит, что «обработка персональных данных в целях продвижения товаров, работ, услуг на рынке путем осуществления прямых контактов с потенциальным потребителем допускается только при условии предварительного согласия субъекта персональных данных». На стороне пользователей контролирующие органы – ФАС, Роспотребнадзор и Роскомнадзор.
При этом интернет-гигант свободно передает другим компаниям базы данных с якобы обезличенными персональными идентификаторами, которые по мнению интернет-гиганта перестали быть персональными данными. И Яндекс обеспечил себе это право «делиться» за счет малозаметной строчки во внушительном тексте собственной политики конфиденциальности.
Вместо заключения
Законно ли всё это? Ведь я не давал права Яндексу разглашать информацию обо мне кому-либо. Знакомые юристы говорят, интернет-данные и интернет идентификаторы – это «серое» поле нашего законодательства и привлечь Яндекс к ответственности за продажу таких данных о вас невозможно.
И насколько справедливо, что Яндекс зарабатывает на моих данных, не объясняя мне как именно это происходит и за счет чего формируется этот заработок, ведь это уже давно не только пресловутая реклама утюгов, которая после поиска «утюга» догоняет тебя еще 2 недели на всех сайтах. Это и прямое влияние на качество моей жизни и доступность социальных сервисов и услуг – таких как кредитование, страховки, медицинская помощь.
Согласитесь, оценка меня как заемщика или страхователя на основе информации о моем поведении в интернете, которая к тому же происходит «в темную» и опирается только на завуалированные термины и оферты, скрытые в подвалах – выглядит абсолютно неэтично и непрозрачно. Это очень напрягает.
Несмотря на GDPR и ужесточение законов по использованию персональных данных граждан в России, интернет-гигант продолжает монетизировать информацию о нас и абсолютно открыто следит за всеми нашими действиями через свои сервисы. Пусть даже и прикрываясь социально важной темой информирования населения и властей о соблюдении режима изоляции, как в случае с коронавирусом. Возникает разумный вопрос – а кто ещё использует наши данные помимо Яндекса и его коммерческих клиентов?