В утечку данных Columbia попали не только студенты, абитуриенты и сотрудники, но и люди, которые вообще не имели отношения к университету. Речь как минимум о компрометации 1,8 млн номеров Social Security Number, и для ИТ-аудитории это неприятно знакомый сюжет: данные собирали десятилетиями, удалить собирались давно, а добил все один забытый legacy-слой.
Историю раскопала Ars Technica после того, как журналистка издания получила уведомление о взломе Columbia University, хотя никогда там не училась, не работала и даже не подавала документы. Публичные уведомления университета после инцидента в июне 2025 года были адресованы только «членам сообщества Columbia» и описывали компрометацию данных, связанных с поступлением, обучением, финансовой помощью и частью кадровых записей. Но уже позже выяснилось, что круг пострадавших шире. Более того, для многих из них письмо оказалось первым внятным сигналом, что их SSN вообще хранился в системах университета.
Дальше начинается сюжет, который хорошо поймут все, кто хотя бы раз пытался пройти путь «пострадавший — поддержка — эскалация — тишина». Сначала жертвам предлагали обращаться на горячую линию Kroll, где ответ сводился к формуле «мы эскалируем ваш запрос». Потом подключался ИТ-колл-центр Columbia, который обещал разобраться, почему конкретные данные оказались в массиве утечки, но с ответами тоже не спешил. На каком-то этапе университетская коммуникация дошла до версии, что чужой SSN мог попасть в системы Columbia еще в 2001 году через SAT: тогда номер соцстрахования часто использовался как идентификатор абитуриента, а школьники могли соглашаться на передачу данных в обмен на информацию о вузах и стипендиях. Версия выглядела правдоподобно, но не всегда сходилась с фактами конкретных людей.
Проверка этой гипотезы только добавила неловкости. College Board, который администрирует SAT, сообщил Ars Technica, что через опциональную программу Student Search SSN абитуриентов Columbia не передавался. До 2018 года передача SSN в принципе могла происходить, но только если студент сам отправлял результаты теста в конкретный вуз. ACT, по данным издания, прекратил использовать такую практику примерно десять лет назад. В Columbia в итоге дали более широкое объяснение: до 2012 года университет получал данные потенциальных студентов, включая SSN, из самых разных источников — от рекрутинговых сервисов и стипендиальных программ до тестовых платформ. После этого в вузе отказались от использования SSN как идентификатора, а старые массивы собирались зачистить.
Проблема в том, что зачистили не все. Представитель Columbia признал, что университет пропустил legacy-базу, где и оставались чувствительные записи, включая SSN людей, не связанных с вузом напрямую. Это, пожалуй, самая важная часть всей истории. Не хактивист и не экзотическая схема сбора данных, а банальная невозможность честно ответить на вопрос: что именно у нас хранится, откуда это взялось и почему оно до сих пор здесь. Хуже того, часть полей, которые могли бы помочь установить источник конкретной записи, уже была удалена. То есть организация накопила данные, частично потеряла контекст их происхождения, а потом еще и не смогла быстро объяснить пострадавшим, что произошло.
Для разработчиков, CISO, продуктовых команд и ИТ-директоров здесь нет ни одной экзотической морали, зато есть несколько очень приземленных. Во-первых, retention policy без технической верификации мало чего стоит: можно годами считать, что чувствительные данные «уже вычищены», пока не всплывет забытая реплика, архивная БД или импорт из старой системы. Во-вторых, data lineage перестает быть красивым термином из презентации, когда приходит реальный инцидент и нужно ответить не регулятору вообще, а конкретному человеку: почему ваш SSN оказался у нас. В-третьих, процессы уведомления о взломе часто проектируют под «типового» пострадавшего. В случае утечки данных Columbia это были студенты и сотрудники. Но если в системах лежат записи людей снаружи контура, весь сценарий поддержки ломается: старые адреса, неочевидные каналы связи, неготовые скрипты операторов, месяцы ожидания и репутационный ущерб уже после самого взлома.
Отдельно неприятен сам исторический хвост SSN как универсального идентификатора. Американские организации много лет уходят от этой практики, но она продолжает аукаться через резервные копии, миграции и базы «на всякий случай». Российским компаниям это тоже знакомо, просто под другими сущностями: паспортные данные, СНИЛС, ИНН, старые профили кандидатов, исторические анкеты клиентов, формы лидогенерации из давно закрытых кампаний. Собрать такие данные легко, объяснить, зачем они нужны спустя 10–15 лет, почти невозможно. А после инцидента выясняется, что главная дыра не только в защите, но и в управлении жизненным циклом данных.
У Columbia, по данным Ars Technica, теперь ускоряют поиск другой чувствительной информации в сети университета и обещают отдельно отвечать тем, кто уже обращался в Kroll или университетский ИТ-центр. Но главный вопрос после этой истории шире одного вуза: сколько организаций уверены, что давно удалили лишние персональные данные, хотя на деле просто перестали видеть их в отчетах. Если утечка данных Columbia чему-то и учит, то довольно прозаичной вещи: самый токсичный актив в инфраструктуре — это не тот, который вы сознательно храните, а тот, о существовании которого уже почти забыли.