Утечка данных 8,8 млн датчан: урок про доступ подрядчиков

В октябре 2026 года в Дании произошла крупная утечка: через доступ небольшой компании-партнёра злоумышленники получили данные около 8,8 млн человек из центрального реестра населения CPR — имена, адреса и персональные номера. Это примерно четыре из пяти жителей страны. Важно, что реестр не взламывали: доступ был легальным, у компании было право запрашивать данные. Эта история — про риск, который часто недооценивают: доступ подрядчиков.

Что произошло

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

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

Почему легальный доступ опаснее взлома

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

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

Что проверить у себя

1. Кому вы дали доступ к данным. Подрядчики, интеграции, партнёры, бывшие сотрудники. У каждого доступа должна быть причина.
2. Какой объём доступа у каждого. Партнёру, которому нужны отдельные записи, не нужен доступ ко всей базе.
3. Видите ли вы, что делают через этот доступ. Запросы партнёров и интеграций должны логироваться.
4. Сработает ли сигнал при массовой выгрузке. Главная ошибка в этой истории — поздно заметили. Аномальный объём запросов должен вызывать оповещение.
5. Как быстро вы отзовёте доступ. При подозрении доступ партнёра нужно уметь отключить сразу.

Наше мнение

Мы часто видим, что доступы к данным раздают щедро и забывают про них: интеграция, настроенная три года назад; подрядчик, который давно не работает; сервис, который «на всякий случай» имеет доступ ко всей базе. Каждый такой доступ — это риск, которым никто не управляет.

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

Как это связано с 152-ФЗ

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

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

С чего начать ревизию доступов

Если список доступов никогда не вёлся, начать стоит с инвентаризации. Выпишите все системы, где хранятся данные клиентов, и для каждой — кто и что имеет к ней доступ: сотрудники, подрядчики, интеграции, внешние сервисы. Уже на этом этапе обычно находятся сюрпризы: интеграция, настроенная давно уволившимся сотрудником; сервис, которому дали доступ ко всей базе «на время»; партнёр, с которым давно не работают. Каждую такую находку нужно оценить: нужен ли доступ, и если да, можно ли его сузить. Эта разовая работа закрывает значительную часть риска и дальше поддерживается регулярной ревизией.