Четыре крупные утечки данных в Японии в 2026 году (KDDI, Aflac, Digital Agency, Sakura): разные пути проникновения, одно общее решение — лучшее обнаружение

Одной из причин, названных Aflac, было то, что «не хватало функций мониторинга и контроля большого объёма запросов данных за короткое время». Задайте для каждого API или экрана, который возвращает данные клиентов, ограничение числа записей на запрос и в час, а также оповещение человеку по мере приближения к лимиту. Даже с действительным входом выгрузка десятков тысяч записей за короткое время не похожа на то, как люди пользуются системой. Как определить, что считать, для кого и до какого значения, описано в статье об ограничении частоты запросов и контроле злоупотреблений.

Измерять можно на трёх уровнях.

В приложении: считайте записи по учётной записи в путях поиска, списков и экспорта; это единственный уровень, который знает, кто и сколько выгрузил.
Перед приложением: limit_req в nginx или правило ограничения частоты на CDN, ограничивающее число запросов в секунду или минуту на каждую конечную точку.
На уровне платформы: центр оповещений Google Workspace и журнал аудита и политики оповещений Microsoft 365 могут сообщать о массовых загрузках и экспорте (набор возможностей зависит от вашего тарифа).

Начните с одной конечной точки — той, что возвращает больше всего записей. Задайте для неё почасовой лимит на учётную запись и оповещение при достижении 80% лимита. Одна конечная точка, которая действительно вызывает человека, лучше полного проекта, который ещё пишется.

Первый пункт в плане устранения последствий у Aflac — более строгая «аутентификация при доступе и авторизация при запросе данных». Может ли человек войти (аутентификация) и может ли он видеть конкретную запись (авторизация) — это разные вопросы, и если второе не проверяется для каждой записи, вошедший пользователь может запрашивать чужие данные. Разница объяснена в статье «Аутентификация и авторизация», а классическая уязвимость описана в статье об IDOR.

В случае с Sakura Internet доступ к системе управления продажами начался примерно за три года до того, как это стало известно. Если журналы за этот период отсутствуют к моменту обнаружения, нельзя сказать ни что произошло, ни чего не произошло. Sakura тоже назвала пересмотр объёма и сроков хранения журналов. Если хранилище позволяет сохранять лишь несколько недель, разумный вариант — хранить хотя бы журналы аутентификации и запросов данных значительно дольше.

Ориентир: стандарт безопасности индустрии платёжных карт (PCI DSS) требует хранения 12 месяцев с немедленным доступом к последним трём месяцам. Даже вне платежей это полезная отправная точка.

Храните как минимум три вида: аутентификацию (успешные и неуспешные попытки), запросы данных и экспорт, административные действия. Одни только журналы доступа веб-сервера не скажут, кто и сколько записей забрал.

Уязвимость, использованная в случае с KDDI, была неизвестна самому производителю на момент обнаружения. На тот момент исправления не существовало. Поскольку некоторые вторжения нельзя предотвратить даже при идеальной установке патчей, остаётся способность замечать подозрительную активность и исходящий трафик на серверах — примером служит EDR, который KDDI развернула на каждом сервере.

Ничего из этого не означает, что предотвращение вторжений стало менее важным. Случай с Цифровым агентством произошёл через уязвимость VPN-устройства. Не оставлять известные уязвимости незакрытыми по-прежнему остаётся самой экономически эффективной защитой. По VPN-устройствам см. «VPN-устройства — главный путь проникновения для программ-вымогателей»; по порядку работ см. «Расстановка приоритетов с помощью CVSS, EPSS и KEV».