Для кого: для компаний и организаций с сотрудниками и подрядчиками, которым нужно решить, где проходит их «минимум» безопасности. Независимым разработчикам и небольшим проектам — базовый чек-лист безопасности для независимых разработчиков. Статья заново выводит в виде мер для организации то, что этот сайт анализировал по официальным сообщениям самих организаций об инцидентах в Японии 2026 года. Шагов атак здесь нет.
Шесть дыр, которые показали инциденты
Всё это случаи, которые сайт разбирал по официальным сообщениям организаций (подробные разборы — в японской и английской версиях).
| Что раскрыто | Какую проблему это показало | Минимум для организации |
|---|---|---|
| Цифровое агентство: проникновение через уязвимость VPN-устройства; на пресс-конференции пояснили, что исправления ставились по очереди | Обновление доступных извне устройств «в очереди» | (1) Закрывать входные устройства в срок |
| Цифровое агентство: обнаружен массовый доступ к файлам на сервере через учётную запись сотрудника обслуживания | Права и контроль учётных записей не-сотрудников | (2) Сузить учётные записи обслуживания, подрядчиков и ушедших |
| Aflac: атака выглядела как обычное использование и не была сразу обнаружена; не хватало функций контроля массовых запросов за короткое время | Объём по отдельности «законных» запросов | (3) Следить за объёмом и временем |
| Sakura Internet: несанкционированный доступ к системе управления продажами длился с апреля 2023 по март 2026 года; среди мер — пересмотр охвата и срока хранения журналов | Невозможно оглянуться назад, когда заметили | (4) Хранить журналы достаточно долго |
| Gyazo: утёкшие метаданные были в основном до января 2019 года | Данные хранились после того, как стали не нужны | (5) Не хранить ненужные данные |
| Adobe Commerce: исправление 11 августа, эксплуатация подтверждена (KEV) через 44 дня, а бюллетень по-прежнему говорил «приоритет 2, эксплуатация неизвестна» | Отложили, поверив оценке на момент выпуска | (6) Пересматривать приоритеты по KEV |
Как читать эту таблицу: не чтобы обвинять, а чтобы проверить себя
Каждая организация провела расследование и опубликовала причину и меры. Сайт использует эти отчёты не как чужую историю, а как чек-лист «нет ли у нас такой же проблемы?». Ни одна из этих проблем не принадлежит только особенно беспечным организациям. В случае KDDI входом стала уязвимость, о которой не знал даже сам поставщик, так что предположение, что вход можно закрыть идеально, не выдерживает проверки. Именно поэтому пункты (2)–(5) — сторона «не дать распространиться после проникновения» — входят в минимум.
Шесть минимумов — и первый шаг для каждого
(1) Закрывайте доступные из интернета устройства в срок
VPN-устройства, шлюзы удалённого рабочего стола, панели управления межсетевыми экранами — составьте список всех устройств, доступных напрямую из интернета, с моделью, версией и ответственным за обновление. В статистике Национального полицейского агентства Японии 61 из 92 действительных ответов о путях заражения вымогателями приходится на VPN-устройства.
Первый шаг: для каждого устройства задайте одно число — сколько дней допускается до закрытия уязвимости после подтверждения её эксплуатации (KEV). Установка исправлений «по очереди» — та же схема, что в случае Цифрового агентства.
(2) Сузьте учётные записи обслуживания, подрядчиков и ушедших — и сделайте их видимыми
В каждой организации есть учётные записи людей, которые не являются сотрудниками: обслуживающих компаний, подрядчиков, уже ушедших. Им часто дают широкие права ради удобства, а кто ими владеет — неясно.
Первый шаг: перечислите все учётные записи не-сотрудников и назначьте каждой внутреннего владельца и дату окончания. Затем по порядку: включать только на время работы, ограничить адреса подключения, требовать устойчивую к фишингу двухфакторную аутентификацию. Отключение учётной записи внесите в ту же форму, что и приём на работу.
(3) Следите за объёмом и временем
В случае Aflac атака выглядела так же, как обычное использование. Если каждый запрос по отдельности законен, проверка по одному его не остановит. Остаются признаки: сколько записей ушло за час и активность ночью и в выходные.
Первый шаг: для одной функции, которая отдаёт больше всего данных клиентов, введите почасовой лимит на учётную запись и оповещение конкретному человеку при 80% лимита. На файловых серверах и в облачных хранилищах настройте оповещение о массовых загрузках, в разы превышающих обычные.
(4) Храните журналы так долго, чтобы можно было оглянуться назад
В случае Sakura Internet несанкционированный доступ начался примерно за три года до обнаружения. Без журналов за этот период нельзя сказать ни что произошло, ни что не произошло.
Первый шаг: храните не менее 12 месяцев три вида записей — аутентификацию (успехи и неудачи), запросы и выгрузку данных, административные действия, — ориентируясь на стандарт платёжных карт PCI DSS. Если места мало, защищайте эти три вида раньше, чем журналы веб-доступа.
(5) Не храните данные, которые больше не нужны
В случае Gyazo утёкшие метаданные были в основном сведениями к изображениям, загруженным много лет назад. Масштаб утечки определяется тем, сколько данных вы хранили на тот момент. Данные, которых у вас нет, утечь не могут.
Первый шаг: для каждого вида данных клиентов напишите одну строку: для чего они и как долго их храним. То, для чего строку написать нельзя, — кандидат на удаление или обезличивание. Проверьте также, не остаются ли данные о расторгнувших договор (в случае Sakura Internet данные участника сохранялись после расторжения, пока он отдельно не выходил из членства).
(6) Пересматривайте приоритеты по KEV, а не по оценке на момент выпуска
У Adobe Commerce бюллетень при выпуске исправления говорил «приоритет 2, эксплуатация неизвестна», а через 44 дня CISA подтвердило эксплуатацию. Для ядра WordPress это заняло три дня.
Первый шаг: настройте один способ получать уведомление, когда используемый вами продукт добавлен в KEV, и сделайте правилом при этом пересматривать очередь обновлений. Порядок принятия решений — в статье Какую CVE закрывать первой — CVSS, EPSS и KEV.
Сузить вход
(1) закрывать доступные извне устройства в срок / (6) пересматривать приоритеты по KEV
Ограничить, куда дотянется злоумышленник
(2) учётные записи обслуживания, подрядчиков и ушедших / (5) не хранить ненужные данные
Заметить проникновение и оглянуться назад
(3) следить за объёмом и временем / (4) хранить журналы достаточно долго
Что меняется между одним человеком и организацией
Что накапливает организация (здесь начинаются инциденты)
- Чужие учётные записи (обслуживающие компании, подрядчики, ушедшие)
- Устройства, о которых никто не помнит (VPN от установщика, старый тестовый стенд)
- Данные за многие годы (расторгнувшие участники, старые метаданные)
- Мониторинг «кто-нибудь да смотрит» (инструмент есть, владельца нет)
Что делает минимум организации
- Назначает всему внутреннего владельца и срок
- Управляет доступными извне устройствами через список и сроки исправлений
- Записывает, зачем и как долго хранятся данные, и удаляет то, что не обосновать
- Задаёт оповещениям число и получателя и проверяет, что они доходят
Взгляд этого сайта: минимум — это решить, кто замечает, по какому числу и когда
Если выстроить отчёты об инцидентах в ряд, бросается в глаза, что многие организации уже имели средства защиты. У Aflac были функции обнаружения и блокировки несанкционированного доступа, а перед запуском проводились проверки архитектуры и тесты на проникновение. И всё же атака не была остановлена, потому что имела не ту форму, которую ожидали.
Поэтому сайт советует измерять минимум организации не вопросом «что мы внедрили», а вопросом «решено ли, кто замечает, выше какого числа и когда». Список внедрённых инструментов полезен для аудита; когда случается инцидент, до кого-то реально дойдёт только оповещение с порогом и получателем. Проверить, что оповещения не уходят до сих пор на почту ушедшего сотрудника, — уже первый шаг.
Кто поддерживает работу шести мер
Шесть минимумов — не разовая задача. Люди меняются, устройств становится больше, данные накапливаются. Чтобы всё продолжало работать, нужно как минимум следующее.
- Один ответственный: кто держит список и сроки по каждому из шести пунктов.
- Ежеквартальная инвентаризация: обновление списков устройств, учётных записей не-сотрудников и данных (подход — в чек-листе инвентаризации).
- Обучение, которое начинается с «как проверить контакт»: после любого инцидента сообщений от имени организации становится больше. Приучите и сотрудников, и клиентов проверять через официальный сайт.
- Прописать обращение с учётными записями и журналами в договорах с подрядчиками: доступом обслуживания и подрядчиков никто не управляет, если договор не говорит, кто это делает.
Читать дальше
- Решение: Какую CVE закрывать первой — CVSS, EPSS и KEV
- Учётные записи: какой способ 2FA самый надёжный / чек-лист инвентаризации
- Версия для одного человека: базовый чек-лист безопасности для независимых разработчиков
- Прошлые случаи: утечка данных Benesse (злоупотребление у подрядчика) / вымогатель в KADOKAWA / Niconico (без сегментации — по всей компании)
- Управление ИИ на работе: Что такое теневой ИИ (shadow AI)? (неодобренные ИИ-инструменты на работе и что делать)
- Точка входа: VPN-устройства — главный путь внутрь
- После проникновения: ограничение частоты запросов и защита от злоупотреблений / если взломали вашего хостинг-провайдера