Registrų centras: 600 000 записей утекло — и как это предотвратить на вашем сервере

С января по апрель 2026 года из Государственного реестра недвижимости Литвы утекло более 600 000 записей: личные коды (asmens kodai), адреса, данные о владении имуществом. Registrų centras — центральный государственный реестр Литвы, который хранит данные о недвижимости, юридических лицах и населении. Утечку обнаружил не мониторинг, не CERT, не служба безопасности — её заметил мэр Неринги Дариус Ясайтис. Registrų centras предоставляет каждому гражданину возможность проверить, кто и когда запрашивал его данные в реестре. 18 февраля Ясайтис воспользовался этой функцией — и среди привычных записей (нотариусы, журналисты) увидел подключения от Vidaus reikalų ministerija (Министерства внутренних дел) в нерабочее время. Это показалось странным: зачем МВД его данные о недвижимости, да ещё ночью? Мэр обратился в институции с вопросом. Никакого ответа не последовало. Данные продолжали утекать ещё два месяца.

Масштаб и последствия оказались серьёзными. Директор Registrų centras Адриюс Юсас покинул должность через три дня после публичного раскрытия. Генеральная прокуратура возбудила уголовное дело. NKSC классифицировал инцидент как крупный и объявил аудит. Советник президента по национальной безопасности назвал принятые меры защиты «полностью неэффективными». Атаку предположительно организовали из иностранного государства — официальной атрибуции нет, расследование продолжается.

ЦЕПОЧКА АТАКИ

Атака была простой и эффективной именно потому, что не требовала никакой технической изощрённости. Атакующие получили логины и пароли двух сотрудников Migracijos departamento (Департамента миграции) — предположительно через компрометацию их личной электронной почты. Директор Migracijos departamento Индрэ Гасперэ на пресс-конференции подтвердила: к Registrų centras подключались, используя реальные email-адреса и пароли реальных сотрудников департамента. Были ли пароли потеряны самими сотрудниками или похищены иным способом — следствие ещё устанавливает.

Дальше всё было механически просто. Registrų centras предоставляет API-доступ к своим реестрам более чем 20 000 пользователей из государственных учреждений, нотариусов, журналистов. Аутентификация — только логин и пароль, смена которого требуется раз в три месяца. MFA не было. Имея на руках credentials двух сотрудников Migracijos departamento, атакующие заходили в систему как легитимные пользователи и методично скачивали записи из реестра недвижимости — ночами, в выходные, возвращаясь к одним и тем же объектам по несколько раз. Февральские данные по одному объекту, апрельские — по другому. Четыре месяца.

Системы Migracijos departamento при этом, по заявлению самого департамента, взломаны не были — атакующие просто использовали украденные credentials для прямого подключения к API Registrų centras, минуя системы источника. Это важная деталь: злоумышленники не взламывали ничего в классическом смысле. Они вошли через парадную дверь с чужим ключом.

ВРЕМЕННАЯ ШКАЛА

Январь 2026 года — первые несанкционированные подключения к API Registrų centras с использованием credentials сотрудников Migracijos departamento. Февраль 2026 года — мэр Неринги Дариус Ясайтис проверяет историю запросов своих данных в реестре и обнаруживает подключения от Vidaus reikalų ministerija (Министерства внутренних дел) в нерабочее время. Обращается в институции. Ответа нет.

Апрель 2026 года — Registrų centras наконец фиксирует утечку, блокирует скомпрометированные учётные записи и передаёт информацию в правоохранительные органы и Национальный центр кибербезопасности (NKSC). Принято решение не сообщать гражданам до выяснения обстоятельств. Май 2026 года — портал 15min задаёт вопросы Registrų centras, после чего компания подтверждает инцидент. Генеральная прокуратура немедленно объявляет об уголовном расследовании. Гражданам открывают возможность проверить, были ли затронуты их данные.

Итог: утечка длилась около четырёх месяцев. Граждан не уведомляли около двух месяцев после того, как факт утечки стал известен Registrų centras. Директор покидает должность через три дня после публичного раскрытия.

ПОЧЕМУ ЭТО ВАЖНО

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

Масштаб доступа делает проблему системной. 20 000 пользователей с прямым API-доступом к государственным реестрам, аутентифицированных только по паролю, — это не одна уязвимость, это 20 000 потенциальных точек входа. Не нужно взламывать Registrų centras напрямую — достаточно скомпрометировать любое из подключённых учреждений. Именно это и произошло: атакующие не тронули центральную систему, они зашли через боковую дверь, которую никто не охранял.

И наконец — реакция. Первый сигнал появился в феврале, от гражданина, а не от системы мониторинга. Никакой реакции не последовало. Данные утекали ещё два месяца. Когда Registrų centras всё же зафиксировал инцидент в апреле — граждан не уведомляли ещё два месяца, ссылаясь на необходимость проверки. GDPR требует уведомить надзорный орган в течение 72 часов после обнаружения утечки. Прошло около двух месяцев.

КАК ПРЕДОТВРАТИТЬ

Этот инцидент разбирается не потому что атака была изощрённой — она была элементарной. Разбирается потому что каждый из провалов, который её сделал возможной, встречается в половине корпоративных и государственных систем прямо сейчас.

Начать нужно с MFA. Пароль, который меняется раз в три месяца, защищает ровно до момента кражи. Дальше у атакующего есть до трёх месяцев легитимного доступа — именно это и произошло. MFA закрывает этот сценарий полностью: украденный пароль без второго фактора бесполезен. Для API с доступом к персональным данным граждан MFA должен быть не опцией, а обязательным условием подключения. Без исключений для «внутренних» учреждений — потому что именно они и стали вектором. Важная оговорка: для небольшого личного сервера SSH только по ключам — уже хороший уровень защиты. MFA становится обязательным там где пользователей много, они из разных организаций, и никто не контролирует как каждый из них хранит свои credentials. Именно такой была архитектура Registrų centras — 20 000 пользователей из десятков учреждений, и ни одного второго фактора.

Дальше — поведенческий мониторинг. Государственное учреждение делает тысячи запросов к реестру недвижимости в субботу ночью — это не норма. Такой паттерн должен автоматически триггерить алерт и блокировку сессии до выяснения. Логи в Registrų centras велись — граждане могли проверить историю запросов по своим данным, значит данные писались. Но никто не смотрел на них в реальном времени. Audit log без мониторинга — это архив для посмертного расследования, а не инструмент защиты. Разница между этими двумя вещами — четыре месяца утечки.

Отдельная история — rate limiting. 600 000 записей за четыре месяца это тысячи запросов. Нотариус запрашивает конкретный объект по делу клиента. Журналист — несколько объектов для материала. Никто из легитимных пользователей не качает реестр оптом. Лимит на количество записей за сессию или за день — элементарный контроль, который физически ограничивает ущерб даже при полностью скомпрометированном аккаунте. Его не было.

И наконец — принцип минимальных привилегий. 20 000 пользователей с доступом к реестру недвижимости — это не архитектурное решение, это его отсутствие. Сотруднику Migracijos departamento нужен доступ к данным конкретных мигрантов, а не ко всему реестру недвижимости страны. Нотариусу — к конкретному объекту по запросу, а не ко всей базе. Granular permissions по ролям и учреждениям сократили бы объём потенциальной утечки на порядки — даже если бы все остальные контролы провалились.

ЧТО ДЕЛАТЬ

Если вы администрируете системы с API-доступом к персональным данным — проверьте следующее прямо сейчас. Включён ли MFA для всех внешних пользователей? Есть ли алерты на подключения в нерабочее время? Есть ли rate limiting на количество записей за сессию? Когда последний раз проводился аудит активных учётных записей и их привилегий?

Первым делом проверьте SSH — настроен ли MFA или хотя бы запрещены ли пароли:

# Проверить что пароли отключены и включена только аутентификация по ключу
grep "PasswordAuthentication\|PubkeyAuthentication\|AuthenticationMethods" /etc/ssh/sshd_config

# Ожидаемый результат:
# PasswordAuthentication no
# PubkeyAuthentication yes

Если пароли не отключены — это первое что нужно исправить. Если хотите добавить второй фактор поверх ключей — установите libpam-google-authenticator и настройте AuthenticationMethods publickey,keyboard-interactive в sshd_config. Украденный ключ без TOTP-кода бесполезен — именно этого не хватало сотрудникам Migracijos departamento.

Для литовских граждан первый шаг — проверить, попали ли ваши данные в утечку. Registrų centras открыл возможность проверить историю запросов по своим данным через клиентскую самообслуживания систему на registrucentras.lt — для этого нужна электронная идентификация. Если в истории видны подключения от незнакомых учреждений в нерабочее время — ваши данные, скорее всего, были в числе затронутых. Именно так обнаружил утечку мэр Неринги.

Что именно утекло — важно понимать конкретно. По официальному заявлению Registrų centras, раскрыты данные из выписок реестра недвижимости: имя, фамилия, asmens kodas, дата рождения, адрес, данные об объектах недвижимости. Телефоны, email, банковские счета, платёжные данные, судебные решения и кадастровые документы — не затронуты. Эксперт ESET Рамунас Либертас в комментарии LRT уточнил: имея только имя, фамилию и asmens kodas, мошенник не сможет взять кредит. Но asmens kodas в сочетании с адресом и данными о недвижимости — уже достаточно для убедительной социальной инженерии.

Главная угроза для обычного человека — социальная инженерия. Механика простая: мошенник звонит или пишет, называет ваше имя, asmens kodas, точный адрес и объект недвижимости — и этим создаёт ощущение что он «свой», что он из официальной структуры, что ему можно доверять. Раньше такие детали знали только вы сами и государственные учреждения. Теперь — все у кого есть эта база.

Вот как это работает на практике. Звонок: «Добрый день, это Swedbank, мы фиксируем подозрительную активность по вашему счёту. Для верификации назовите пароль интернет-банка» — и параллельно называют ваш точный адрес, чтобы вы поверили что это действительно банк. Или письмо от «нотариуса» с вашим asmens kodas и адресом объекта: «Требуется ваше участие в оформлении сделки по недвижимости по адресу X» — с просьбой перейти по ссылке и подтвердить личность. Или сообщение от «Valstybinė mokesčių inspekcija» с данными о вашем имуществе: «Выявлена задолженность, оплатите в течение 24 часов во избежание штрафа».

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

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

На системном уровне этот инцидент должен стать поводом для пересмотра архитектуры доступа ко всем государственным реестрам — не только в Литве. Federated identity с MFA, поведенческий мониторинг, rate limiting, granular permissions по ролям — это не передовые технологии, это базовая гигиена для 2026 года. То что 20 000 пользователей имели доступ к чувствительным данным только по паролю — это не технический долг, это архитектурное решение, которое нужно пересмотреть.

Если вы администрируете сервис с API-доступом к данным — вот конкретные примеры того что должно быть настроено прямо сейчас.

Rate limiting в nginx: ограничение количества запросов к API-эндпоинту по IP и по аутентифицированному пользователю. Без этого контроля атакующий с валидными credentials может выгружать данные со скоростью сети:

# Зона rate limiting — 100 запросов в минуту на пользователя
limit_req_zone $http_authorization zone=api_user:10m rate=100r/m;

server {
    location /api/ {
        limit_req zone=api_user burst=20 nodelay;
        limit_req_status 429;

        # Логировать превышение лимита отдельно для алертов
        access_log /var/log/nginx/api_ratelimit.log combined;
    }
}

Мониторинг аномальных паттернов в логах nginx — поиск аккаунтов с подозрительно высоким числом запросов за короткий период:

# Топ-10 IP по количеству запросов за последние 1000 строк
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | \
  sort | uniq -c | sort -rn | head -10

# Запросы в нерабочее время (22:00 - 06:00)
grep -E ' (2[2-9]|0[0-6]):[0-9]{2}:[0-9]{2} ' /var/log/nginx/access.log | \
  awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -20

Блокировка в nftables после превышения лимита запросов — автоматическая реакция на аномальную активность. Связка nginx + fail2ban + nftables закрывает сценарий когда rate limit сработал, но запросы продолжаются с того же IP:

# /etc/fail2ban/filter.d/nginx-api-ratelimit.conf
[Definition]
failregex = ^<HOST> - - \[.*\] "GET /api/.*" 429

# /etc/fail2ban/jail.d/nginx-api.conf
[nginx-api-ratelimit]
enabled  = true
port     = http,https
filter   = nginx-api-ratelimit
logpath  = /var/log/nginx/api_ratelimit.log
maxretry = 10
findtime = 60
bantime  = 3600
action   = nftables-multiport[name=nginx-api, port="http,https"]

Audit log для отслеживания доступа к чувствительным файлам и директориям через auditd. В случае с Registrų centras логи велись, но никто не анализировал их в реальном времени — auditd с правильными правилами триггерит алерт сразу:

# Мониторинг доступа к директории с данными пользователей
auditctl -w /var/lib/app/userdata/ -p rwxa -k userdata_access

# Мониторинг массового чтения файлов одним процессом
auditctl -a always,exit -F arch=b64 -S open,openat -F dir=/var/lib/app/userdata/   -F success=1 -k bulk_read

# Просмотр алертов в реальном времени
ausearch -k userdata_access --start today | aureport -f -i

# Топ процессов по доступу к данным за сегодня
ausearch -k bulk_read --start today | awk -F'comm=' '/comm=/{print $2}' | \
  awk '{print $1}' | sort | uniq -c | sort -rn

Быстрая проверка активных сессий и нетипичных подключений к вашему сервису прямо сейчас:

# Активные соединения по количеству на IP — аномально высокое число подозрительно
ss -tn state established | awk '{print $5}' | cut -d: -f1 |   sort | uniq -c | sort -rn | head -20

# Соединения к API-порту с иностранных IP (пример для порта 8443)
ss -tnp | grep ':8443' | awk '{print $5}' | cut -d: -f1 |   sort -u

# Последние 50 уникальных IP подключавшихся к API за час
awk '{print $1}' /var/log/nginx/access.log |   sort -u | tail -50

ЧТО ПРОИСХОДИТ ДАЛЬШЕ

Инцидент не закрыт — он только разворачивается. NKSC объявил о проведении аудита кибербезопасности Registrų centras и намерен выяснить точный механизм утечки и что нужно изменить. Министерство экономики и инноваций, которое является владельцем Registrų centras, объявило конкурс на нового директора — с явным указанием что кибербезопасность теперь главный приоритет. Инспекция по защите данных Литвы (VDAI) уже заявила что штраф компании может достигнуть 60 000 евро по GDPR — за несвоевременное уведомление пострадавших граждан. Генеральная прокуратура продолжает расследование, детали под следственной тайной.

Отдельный вопрос который многих беспокоит: можно ли сменить asmens kodas? Официальный ответ — нет. Представитель Registrų centras Миндаугас Самкус прямо сказал в комментарии LRT: asmens kodas регулируется законодательством, и гражданин не может его поменять как пароль. Это делает утечку принципиально иной по характеру: скомпрометированный пароль меняется за минуту, скомпрометированный идентификатор остаётся с человеком навсегда. Именно поэтому осведомлённость о социальной инженерии важнее любого технического решения на стороне пострадавших граждан.

Литва в этом инциденте не исключение — она часть системной европейской проблемы. Государственные реестры с широким API-доступом, слабой аутентификацией и недостаточным мониторингом атаковали и в других странах. Принципиальная разница в том, что в этом случае вектором стала не уязвимость в коде и не прямой взлом — а компрометация credentials смежного учреждения. Это означает что любая государственная система с десятками тысяч внешних пользователей несёт в себе тот же риск, если не применяет MFA и поведенческий мониторинг. Инцидент с Registrų centras — это предупреждение для каждого государственного реестра в Европе.

КАК НЕ ДОПУСТИТЬ ПОВТОРЕНИЯ НА ВАШЕМ СЕРВЕРЕ

Registrų centras — государственный реестр, но уязвимости которые привели к утечке встречаются на любом сервере с API-доступом к данным. Вот три уровня на которых нужно выстроить защиту.

Процессный уровень — организация, а не только технология. Технические контролы без процессов не работают. Конкретно: определите кто получает алерты от fail2ban и auditd — и убедитесь что этот человек реально их читает, а не просто имеет доступ к почте. Установите регулярный ревью активных учётных записей — раз в квартал проверяйте кто имеет доступ к API, нет ли давно уволившихся сотрудников с активными токенами, не изменились ли роли пользователей. Задокументируйте план реагирования на инцидент: что делать в первые 30 минут после обнаружения аномалии, кого уведомлять, когда блокировать доступ. В Registrų centras первый сигнал пришёл в феврале — и исчез в никуда именно потому что не было процесса обработки таких сигналов.

Архитектурный уровень — Zero Trust для межсистемного доступа. Принцип «внутренняя сеть — доверенная зона» устарел. Когда 20 000 пользователей из десятков учреждений имеют прямой API-доступ по паролю — это не внутренняя сеть, это публичный интерфейс с иллюзией изоляции. Правильная архитектура: federated identity через единый identity provider (например, Keycloak или аналог), где каждое учреждение аутентифицируется через свой IdP, а не через прямые credentials. Доступ выдаётся на уровне scopes — конкретные операции для конкретных ролей, не общий доступ к реестру. Между системами — short-lived токены с автоматической ротацией, не долгоживущие пароли. Это Zero Trust на практике: не доверяй никому по умолчанию, проверяй каждый запрос.

Чеклист перед запуском API с доступом к персональным данным. Если вы разворачиваете или аудитируете такой сервис — пройдитесь по этому списку:

• MFA включён для всех пользователей — не только администраторов
• Пароли отключены там где используются ключи или токены
• Rate limiting настроен — лимит запросов на пользователя и на IP
• Audit log включён и алерты настроены на аномальные паттерны
• Принцип минимальных привилегий применён — каждая роль имеет доступ только к нужным ресурсам
• Мониторинг нерабочего времени — запросы в 2 ночи должны триггерить алерт
• Процедура ревью доступов задокументирована и выполняется по расписанию
• План реагирования на инцидент существует и известен команде
• Тест уведомления об инциденте проведён — убедитесь что алерты реально доходят до нужных людей

Ни один из этих пунктов не требует дорогостоящих решений. Все они были пропущены в Registrų centras — и именно поэтому утечка длилась четыре месяца.

ВЫВОДЫ

Взлом Registrų centras — это не история про изощрённую APT-атаку с эксплойтами нулевого дня. Это история про украденный пароль, отсутствие MFA и мониторинг который не работал. Атакующие не взломали ничего — они вошли через парадную дверь с чужим ключом и четыре месяца методично выносили данные. Система не заметила. Первым заметил гражданин.

Самый неудобный вывод из этого инцидента: аsmens kodas 600 000 литовцев теперь в чужих руках навсегда. Его нельзя заменить как пароль. Данные о недвижимости не изменятся. Это долгосрочный ресурс для тех, кто его получил — неважно, мошенники это или разведка.

Для всех кто администрирует системы с доступом к персональным данным — этот случай стоит распечатать и повесить над монитором. Не как страшилку, а как чеклист того, что должно быть включено по умолчанию: MFA, anomaly detection, rate limiting, минимальные привилегии, audit log с алертами. Каждый из этих контролей мог остановить атаку в одиночку.

ОБНОВЛЕНИЕ

2 июня 2026. Registrų centras официально заявил что компания самостоятельно не анализировала утечку — не изучала какие именно данные были похищены и есть ли в них закономерности. Вся информация передана Генеральной прокуратуре. Представитель Миндаугас Самкус: «Registrų centras не анализировал никаких данных, раскрытых в результате этого инцидента. Всю имеющуюся информацию мы передали правоохранительным органам».

2 июня 2026. Министр экономики и инноваций Эдвинас Грикшас заявил в Сейме что инцидент — не разовый сбой, а результат финансовых, технологических и управленческих проблем накопленных за многие годы: «Сигналы о растущих рисках в сфере безопасности государственных информационных ресурсов были видны и представлены давно». По его словам, IT-проблемы в государственном секторе решались только тогда когда ситуация становилась кризисной.

5 июня 2026. Registrų centras опубликовал официальную хронологию инцидента. Факт нарушения защиты персональных данных был установлен 7 мая — до этого компания собирала ответы от госучреждений для выяснения обстоятельств. В тот же день ГИЗД была уведомлена официально. Генеральная прокуратура начала предварительное расследование 15 апреля, публично объявить о нём разрешила только 22 мая — до этого момента участники процесса были обязаны соблюдать ограничения на коммуникацию с общественностью. По оценке ГИЗД, утекло чуть более 600 000 выписок, однако пострадавших граждан около 500 000 — часть фигурирует в нескольких выписках. Предварительный ущерб оценивается минимум в 111 000 евро.

5 июня 2026. По данным TV3 и LRT, атаку первой обнаружила не система мониторинга и не мэр Неринги — а частная финансовая группа. Её представители обратились в правоохранительные органы, заметив что ночами и в выходные кто-то из структур МВД проверял данные их руководителей и членов семей, интересовался их недвижимостью. Именно это обращение запустило официальное расследование в апреле. Мэр Неринги Дариус Ясайтис сообщил об аномалии ещё в феврале — но тогда его никто не услышал. Также подтверждено: использовалась учётная запись одного сотрудника Migracijos departamento, а не нескольких как сообщалось ранее.

16 июня 2026. Появилась деталь которая объясняет почему атаку не остановили раньше. МВД знало о подозрительной активности ещё в начале 2026 года, однако когда запросило информацию у Registrų centras — те потребовали оплатить выписку. Стоимость: 2,64 евро. Министр внутренних дел Владислав Кондратовичюс на заседании Сейма: «У меня не было 2,64 евро в тот момент, поэтому я не мог узнать кто использует информационную систему». Когда министерство всё же оплатило запрос — Registrų centras указал какая именно учётная запись была скомпрометирована. С этого момента началась остановка утечки. Впоследствии Registrų centras выставил МВД счёт на 100 000 евро за дополнительные услуги в рамках расследования. Касчюнас в Сейме: «Мы спрашивали есть ли структура для управления кризисом. Очевидно что никакой структуры даже не планировалось создавать».

19 июня 2026. Президент Гитанас Науседа в ежегодном обращении к Сейму: «Менее месяца назад — значительно позже чем следовало — все узнали о краже данных из Registrų centras. Вредоносная деятельность не только не была своевременно выявлена и остановлена, но и создала ещё большую опасность для жителей Литвы из-за слишком медленной реакции государственных институций». Сейм 19 июня проголосовал за создание парламентской комиссии по расследованию — 61 «за», 21 «против». Комиссия проверит безопасность государственных реестров за период 2020–2026 годов.

PS

Этот инцидент наглядно показывает: экономия на IT-безопасности — это не экономия, это отложенный счёт который всегда приходит с процентами. Мы живём в мире где уязвимости обнаруживаются каждый день. Патчи, аудиты, мониторинг, MFA — это не расходы, это инфраструктура. Государство которое экономит на защите данных своих граждан перекладывает риск на самих граждан. И когда счёт приходит — его оплачивают не чиновники, а 600 000 человек чьи данные теперь в чужих руках навсегда. Символично: остановить утечку не смогли в том числе потому что одно ведомство не могло заплатить другому 2,64 евро за информацию о скомпрометированной учётной записи.