Для кого: для тех, кто администрирует системы в компании или организации, которая обрабатывает персональные данные в Японии, и для руководства, которому они подотчетны. В октябре 2026 года японские государственные органы и национальные организации в сфере кибербезопасности выпустили серию предупреждений о несанкционированном доступе. Это руководство превращает их в проверки, которые можно провести на собственных системах на этой неделе. Оно основано на публичных документах Секретариата кабинета министров (Национальное бюро кибербезопасности), IPA (Information-technology Promotion Agency), JPCERT/CC, Комиссии по защите персональных данных (PPC), Агентства по финансовым услугам (FSA) и Национального полицейского агентства (NPA); все эти документы на японском языке. Техники атак в руководстве не рассматриваются.
Почему эти предупреждения появились именно сейчас
Примерно с сентября 2026 года организации в Японии одна за другой сообщают об утечках данных в результате несанкционированного доступа. IPA говорит, что сообщения поступают от широкого круга компаний, включая финансовые организации и телекоммуникационных провайдеров, и что системы, стоящие за онлайн-сервисами и сервисами учетных записей, которые обрабатывают большие объемы персональных данных, подвергались взлому, а данные, включая персональную информацию, похищались.
Следующие документы были выпущены 7–9 октября.
| Дата | Кто выпустил | Документ | Основное содержание |
|---|---|---|---|
| 7 октября (видеообъяснение добавлено 9 октября) | Комиссия по защите персональных данных | Реагирование на масштабные утечки данных (предупреждение) и пересмотренное «ПРЕДУПРЕЖДЕНИЕ: предотвращение утечек персональных данных, вызванных несанкционированным доступом» | Предварительный взгляд на пересмотренные примеры технических мер защиты (окончательная редакция запланирована на апрель 2027 года); удаление персональных данных, которые больше не нужны; девять типов случаев, включая злоупотребление API |
| 8 октября (обновлено 9 и 23 октября) | JPCERT/CC | Оповещение о недавней серии случаев несанкционированного доступа в японских организациях (JPCERT-AT-2026-0030) | Пять наблюдаемых схем атак, меры противодействия, индикаторы для расследования (IOC) |
| 9 октября | Секретариат кабинета министров, Национальное бюро кибербезопасности | Реагирование на утечки данных, вызванные несанкционированным доступом | Три направления: веб-системы, цепочка поставок, управление данными |
| 9 октября | IPA | Меры, которые нужно оперативно принять в связи с утечками данных, вызванными несанкционированным доступом | Проверки, которые нужно провести сейчас, и меры, которые нужно принять (обновляется по мере необходимости) |
| 9 октября | Агентство по финансовым услугам | Укрепление кибербезопасности и обработка заявок на открытие счетов в текущей ситуации | Требования к финансовым организациям пересмотреть меры контроля и ужесточить проверку личности |
JPCERT/CC говорит, что, хотя затронуто несколько продуктов и сервисов, обмен техническими данными недостаточен, а известное ограничено. Ни в одном из документов не называются отдельные инциденты. Японские случаи несанкционированного доступа, которые этот сайт освещал в сентябре и октябре, включают Times Car, Yamato Transport и Sagawa Express, приложение Seicomart, приложение Yakiniku King, подрядчика Daiwa Securities и Lawson ID. Что именно сообщила каждая компания, описано в связанных статьях.
Проверки на этой неделе: три направления IPA
IPA выделяет три направления в разделе «проверки, которые нужно провести оперативно». Ниже они разбиты на конкретные задачи. Выполняйте их только для систем, которыми вы управляете.
Составьте список приложений, доступных из интернета, и проверьте их логи: сначала за последний месяц, затем за три месяца
Перечислите все приложения и сервисы, которые вы создали или эксплуатируете и к которым можно обратиться из интернета: сайты для участников, API, которые вызывают ваши мобильные приложения, контактные формы и административные экраны. JPCERT/CC говорит, что страдают и системы, не предназначенные для широкой публики, например BI-инструменты и административные системы для сотрудников, поэтому включайте и внутренние системы, доступные из сети.
Для каждого приложения проверьте логи на аномалии. Примеры IPA: большой объем ошибок и шаблоны, отличающиеся от обычных. На практике ищите всплески запросов к административным экранам или API в журнале доступа веб-сервера, одну и ту же ошибку, повторяющуюся в журнале приложения, и большие выборки данных ночью или в выходные. Начните с последнего месяца, затем расширьте проверку до трех месяцев.
IPA также просит заранее знать, кто и как может провести расследование, поскольку может понадобиться расследовать более одного раза. Наконец, проверьте компоненты каждого приложения и сервиса (например, ОС, промежуточное ПО, библиотеки и CMS) на наличие неустановленных исправлений безопасности и установите их как можно скорее.
Для API пересмотренный 7 октября документ ПРЕДУПРЕЖДЕНИЕ от PPC добавляет случай 9, «злоупотребление API» (первая редакция от 11 декабря 2024 года содержала случаи с 1 по 8). В нем перечислены причины: некоторые API отсутствовали в списке управляемых; изменение параметра, например идентификатора участника, позволяло вошедшему пользователю получить данные других пользователей; ответы содержали ненужную информацию, а идентификаторы участников были последовательными; и не было ограничения на объем запросов (rate limiting). Примеры мер противодействия:
- Регулярно проводите инвентаризацию своих API
- Проверяйте авторизацию (имеет ли этот пользователь право доступа к этим данным) при каждом запросе, а не только аутентификацию (кто этот пользователь)
- Исключайте из ответов ненужную информацию и используйте случайные значения, такие как UUID, для идентификаторов участников и номеров записей
- Внедрите ограничение частоты запросов, которое выявляет и блокирует большие объемы запросов за короткое время
В облачных, VPN и других внешних сервисах проверьте неудачные входы, адреса источников и неизвестные учетные записи
Составьте список облачных сервисов, VPN и SaaS, которыми вы пользуетесь. IPA просит включать сервисы, на которые подписались отдельные подразделения. Спросите у финансового отдела и отдела продаж, есть ли у них договоры, о которых не знает IT-команда.
В логах каждого сервиса ищите многочисленные неудачные входы, незнакомые IP-адреса источников и входы в необычное время. IPA отмечает, что сроки хранения различаются между сервисами и что поставщик и заказчик могут видеть разные логи. Если административная консоль показывает только короткий период, спросите у поставщика.
Для учетных записей проверьте, не создавались ли какие-либо, которых вы не узнаёте, и не были ли повторно включены те, которые вы отключили или удалили. IPA говорит, что помогает проверка журнала аудита операций с учетными записями. Это организационная версия проверки того, обращался ли кто-то к вашей учетной записи.
Случай 8 в том же ПРЕДУПРЕЖДЕНИИ — утечка из облачного сервиса, который использовал бизнес. Бизнес-система облачного провайдера подверглась несанкционированному доступу, и персональные данные многих клиентских компаний были зашифрованы. Одна из причин, которую называет PPC: клиенты полагали, что использование облачного сервиса, который не являлся аутсорсингом, не считается передачей персональных данных на обработку, поэтому не контролировали, как с ними обращаются. В качестве меры противодействия PPC рекомендует перед выбором облачного сервиса проверять по условиям обслуживания и документам об оценке безопасности сервиса, есть ли у него надлежащие меры безопасности.
Проведите инвентаризацию персональных данных, которые вы храните, и удалите то, что не нужно
IPA отмечает, что похищенные данные используются для вымогательства и перепродажи, и просит организации хранить только нужные данные и точно знать, что именно они хранят. Для каждой базы данных и хранилища файлов запишите, какие данные там находятся, сколько записей, зачем они нужны и до какого срока. Всё, что вы не можете объяснить, является кандидатом на удаление.
Предупреждение PPC за ту же неделю напоминает предприятиям, что статья 22 японского закона о персональной информации обязывает их прилагать усилия к тому, чтобы незамедлительно удалять персональные данные, когда они больше не нужны, и говорит, что видело случаи, когда ситуация ухудшилась именно из-за того, что это не было сделано. Если закон устанавливает срок хранения, запишите и это основание, и срок.
IPA также сообщает, что государственные органы и поставщики средств безопасности могут публиковать информацию, полезную для расследования, например подозрительные IP-адреса, и просит организации на данный момент усилить сбор информации.
Даже если проверки ничего не показали, продолжайте
IPA просит организации рассмотреть дополнительные меры, даже если аномалий не найдено. Для приложений, доступных из интернета, и внешних сервисов: пересмотрите, что открыто для доступа, усильте аутентификацию, например многофакторную аутентификацию и пароли, пересмотрите привилегии учетных записей, пересмотрите управление интеграциями API и то, что и как долго логируется. Для данных: пересмотрите, нужно ли их хранить, пересмотрите место их хранения, проверьте записи о доступе и сроки их хранения, и зашифруйте их.
Три направления Национального бюро кибербезопасности в виде конкретных проверок
Уведомление Национального бюро кибербезопасности в качестве фона называет эксплуатацию уязвимостей веб-систем, компрометацию через цепочку поставок и слабое управление данными и излагает ключевые меры по каждому из них. Правая колонка переписывает пункты уведомления в виде вопросов, которые можно проверить в собственной организации.
| Направление | Основные пункты уведомления | Что проверить |
|---|---|---|
| 1. Надлежащее управление веб-системами | Оперативно устанавливать патчи безопасности (включая внутренние серверы, не открытые в интернет), прекратить использование продуктов, которые больше не поддерживаются, отключить неиспользуемые системы и функции, регулярно проводить оценку уязвимостей, закрыть ненужные порты и сервисы | Можете ли вы составить список каждого публичного и внутреннего сервера с датой окончания поддержки и датой последнего обновления? |
| 1. (учетные записи и аутентификация) | Многофакторная аутентификация, запрет легко угадываемых паролей, минимизация административных учетных записей, оперативное отключение учетных записей уволенных, переведенных и неиспользуемых сотрудников | Можете ли вы назвать владельца каждой административной учетной записи? Остались ли активными учетные записи уволенных сотрудников? |
| 1. (устойчивость) | Сбор и хранение логов, мониторинг подозрительного трафика и массовых обращений, выявление аномальных попыток аутентификации извне, подготовка к реагированию на инциденты | Когда происходят массовые выборки или повторяющиеся неудачные входы, кто получает уведомление? |
| 2. Цепочка поставок, включая подрядчиков | Проверка политик, структуры и распределения ответственности подрядчиков, знание состояния и субподрядчиков, включение в договоры контроля доступа, ведения журналов и обязанностей по сообщению об утечках, предоставление подрядчикам только необходимых данных, обеспечение удаления данных после окончания работ | Можете ли вы на одной странице указать для каждого подрядчика персональные данные, которыми вы с ним делитесь, учетные записи, которые ему предоставлены, и контакт для инцидентов? |
| 3. Надлежащее управление данными | Знание того, где находится информация и кто за нее отвечает, определение цели и срока хранения, регулярная инвентаризация, разделение прав на чтение и запись, шифрование хранимых данных и трафика, никогда не хранить учетные данные в открытом виде, проверка облачной открытости и настроек доступа, фиксация доступа к персональным данным и отслеживание массовых выборок | Можете ли вы впоследствии установить, кто и когда обращался к персональным данным? |
Что касается цепочки поставок, уведомление просит организации действовать, исходя из понимания, что они «управляют совместно с подрядчиками», поскольку злоумышленники иногда используют менее защищенного подрядчика как точку опоры, а затем расширяют доступ к целевой компании. Учетные записи подрядчиков и обслуживающего персонала также рассматриваются в базовых требованиях безопасности для организаций.
Национальное бюро кибербезопасности: что защищать
Веб-системы / цепочка поставок, включая подрядчиков / управление данными
IPA: что проверить на этой неделе
Логи приложений, доступных из интернета / учетные записи внешних сервисов / ваши данные
JPCERT/CC: что происходит
Пять схем атак / меры противодействия / ориентиры для расследования (IOC, обновляются)
Предварительный взгляд PPC на пересмотренные технические меры защиты
В приложении к своему предупреждению от 7 октября PPC изложила пересмотренное содержание пункта «10-6 Технические меры защиты» в приложении к своим общим руководствам по японскому закону о персональной информации. Оно говорит, что пересмотр запланирован к окончательной редакции в апреле следующего года (апрель 2027 года), но что планируемое содержание публикуется заранее, поскольку с учетом недавних событий оно, вероятно, окажется полезнее в качестве справочного материала.
В нем перечислены «примеры методов». PPC говорит, что это именно примеры и что не обязательно внедрять каждый из них, чтобы избежать нарушения. Оно также указывает, что конкретные методы должны соответствовать риску, включая вред для людей в случае утечки данных, а также характеру и объему обрабатываемых персональных данных. Предприятиям, которые хранят большие объемы персональных данных, следует сверить свои меры контроля с этим документом построчно. В приложении также приведены отдельные примеры для малых и средних предприятий.
| Область | Примеры из приложения (в сокращении) | Что проверить |
|---|---|---|
| (1) Контроль доступа | Минимизировать доступ к системам, которые обрабатывают персональные данные (например, только с заранее одобренных конкретных IP-адресов). Свести к минимуму число сотрудников с привилегированными учетными записями, используемыми ими устройствами и временем их использования. Пересматривать права доступа, например, через регулярные аудиты. Оценивать каждый запрос на доступ по контексту, такому как место источника, время и состояние безопасности устройства, и принимать решение на основе риска | Можно ли получить доступ к административным экранам или базам данных откуда угодно? Можете ли вы перечислить привилегированные учетные записи и устройства, с которых они используются? |
| (2) Идентификация и аутентификация | Использовать многофакторную аутентификацию (включая устойчивые к фишингу методы) для доступа извне сети организации, для доступа с административными правами и для доступа к важным персональным данным. Также надлежащим образом идентифицировать и аутентифицировать пользователей, не являющихся сотрудниками, например, с помощью многофакторной аутентификации (аналогично) | Требует ли каждое удаленное подключение и административный вход многофакторной аутентификации без исключений? Предлагается ли она участникам и другим пользователям? |
| (3) Предотвращение несанкционированного доступа извне | Межсетевые экраны, средства защиты, установка исправлений, предотвращение неутвержденного ПО. Разрешать доступ к персональным данным только с устройств, одобренных организацией и соответствующих ее стандартам безопасности | Работают ли с персональными данными только устройства, которые одобрила компания? |
| (4) Предотвращение утечек при использовании систем | Сводить к минимуму персональные данные, используемые как тестовые данные для проверки функций (например, запрещать их или заменять часть другими данными). При удалении персональных данных в облаке использовать метод, затрудняющий восстановление, например собственный метод поставщика или криптографическое стирание | Есть ли копии реальных персональных данных в тестовых средах? Определено ли, как удаляются данные при отмене или переносе облачного сервиса? |
| (5) Выявление несанкционированного доступа | Хранить логи аутентификации, доступа, операций и сети в течение установленного периода, защищать их от утечек, подмены и несанкционированного удаления, регулярно их анализировать. Вести непрерывный мониторинг с помощью IDS/IPS, EDR и подобных средств. Ограничивать распространение ущерба, останавливая или изолируя системы, которые были или могли быть скомпрометированы, и отключая учетные записи | Храните ли вы логи там, где злоумышленник не сможет их удалить? Кто может принять решение об изоляции системы и отключении учетных записей? |
Хранение логов в строке (5) также является тем, от чего зависит проверка IPA «последний месяц, затем три месяца». Если проверка на этой неделе показывает, что логов недостаточно, строка (5) дает основания для исправления этого.
Пять схем, которые наблюдала JPCERT/CC
Оповещение JPCERT/CC описывает схемы атак, отличные от программ-вымогателей, которые приводят к крупным утечкам данных и, по всей видимости, особенно растут. Здесь они изложены лишь настолько, чтобы показать, где искать.
| Схема | Краткое описание по JPCERT/CC | Где проверять |
|---|---|---|
| Случай A | Поиск известных уязвимостей и попытки их эксплуатировать, в том числе попытки получить файлы конфигурации или резервные копии через плохо управляемое оборудование | Уровень установки исправлений на публичных серверах; не лежат ли конфигурационные файлы или резервные копии в публичных папках |
| Случай B | Несанкционированные запросы к административному API приложения, приводящие к изменению данных. В сообщениях фигурируют выявление API путем анализа публичных приложений, атаки на внутренние API и злоупотребление API-ключами, украденными из других систем | Требуют ли административные и внутренние API аутентификации и контроля доступа; права и срок действия API-ключей |
| Случай C | Эксплуатация уязвимости SQL-инъекции в Metabase (CVE-2026-72898) через несанкционированные API-запросы | Используете ли вы Metabase, установлено ли на нем исправление, доступен ли он из интернета |
| Случай D (добавлен 9 октября) | Файл WAR (упакованное Java-приложение), размещенный на сервере приложений, доступном с публичного веб-сервера, внутри которого находится файл, работающий как простая веб-оболочка (вредоносная программа, позволяющая посторонним выполнять команды) | Доступны ли функции управления сервера приложений из публичной части сети; развернуто ли каждое приложение вами |
| Случай E (добавлен 23 октября) | Попытки атак, злоупотребляющие платформами автоматизированного тестирования на проникновение на основе ИИ; названия платформ перечислены в оповещении JPCERT/CC. Они в основном нацелены на веб-приложения, открытые в интернет, выявляя и пытаясь эксплуатировать различные уязвимости, а также наблюдались атаки, использующие плохо управляемое оборудование (например, получение конфигурационных или резервных файлов). Включены попытки атак на серверы WSUS (серверы, которые распространяют обновления Windows внутри организации), открытые в интернет | Уровень установки исправлений на публичных веб-приложениях и то, что лежит в публичных папках; доступен ли сервер WSUS из интернета |
Случай C рассмотрен в статье об утечках из-за уязвимости Metabase и в разборе CVE-2026-72898. О конфигурационных файлах и резервных копиях, оказавшихся не на месте, см. оставили ли вы секретный файл в публичном каталоге?
15 октября JPCERT/CC опубликовал результаты изучения серверов, которые, возможно, использовались при атаках. Оно говорит, что злоумышленники применяли ИИ для сканирования известных уязвимостей и атак через API, а также что есть следы анализа файлов распространения Android-приложений для выявления API и поиска в них таких недостатков, как SSRF. Это совпадает с «выявлением API путем анализа публичных приложений» из случая B. JPCERT/CC отмечает, что секреты и логику аутентификации API, встроенные в приложение, можно извлечь даже из скомпилированного кода (например, из приложений на Flutter), и рекомендует следующее.
- Не встраивайте в приложение закрытые ключи или долгоживущие учетные данные, используемые для аутентификации API
- Не полагайтесь только на подпись или обфускацию внутри приложения; аутентифицируйте пользователей на сервере и авторизуйте каждую операцию по её цели и содержанию
- Применяйте ограничения частоты запросов и отслеживайте аномальные запросы, исходя из того, что доступ может приходить от клиентов, отличных от официального приложения
- Для API, которые получают внешние URL, ограничивайте адреса назначения, а также проверяйте, куда ведут перенаправления
Для доступа через API JPCERT/CC рекомендует ограничения частоты запросов для каждой функции на вход, сброс пароля, отправку SMS и поиск (лимиты запросов); контроль доступа, в том числе к непубличным API; минимальные права и разумный срок действия для пользователей API и токенов; а также возможность быстро отозвать ненужные или, возможно, утекшие токены. Его общие меры включают ограничение регионов-источников для сервисов, которые используются только в определенных областях, обновление версий, затронутых известными уязвимостями, пересмотр способов ограничения бокового перемещения при компрометации веб-сервера, проверку обнаружения и первичного реагирования, отключение ненужных административных функций от интернета, удаление данных, срок хранения или цель которых истекли, и подготовку заранее предупреждений клиентов о последующем вреде в случае утечки.
Что выяснили японские компании по безопасности (с 7 по 19 октября)
Японские компании по безопасности также опубликовали выводы по делам, которыми занимались, и по изучению серверов атакующих. Одна компания рассмотрела 81 утечку из веб-систем, о которых организации в Японии сообщили начиная с июля 2026 года (по состоянию на 6 октября), и обнаружила, что 65 из них (80,2%) не удалось классифицировать по причине, поскольку в уведомлениях было недостаточно объяснений. Методы, которые она наблюдала в своих делах, включают API, возвращающие больше данных, чем нужно, отсутствие проверок авторизации на сервере, функции только для участников, доступные анонимным пользователям, и API-ключи, извлеченные из смартфонных приложений.
Другая компания описывает, как злоумышленники переключались на другой IP-адрес непосредственно перед достижением порога блокировки WAF, используя в общей сложности несколько сотен IP-адресов. Она также сообщает, что версии, не указанные в CVE, и версии после окончания поддержки могут быть затронуты той же уязвимостью. 19 октября она сообщила, что подтвердила использование системы автономного тестирования на проникновение на основе ИИ на сервере злоумышленника. 23 октября JPCERT/CC также добавило в свое оповещение как случай E попытки атак, злоупотребляющие платформами тестирования на проникновение на основе ИИ.
Добавьте эти три проверки к перечисленным выше.
- Убедитесь, что административные экраны и другие функции управления действительно входили в область вашей оценки уязвимостей (функции, не открытые публично, часто упускаются)
- Не полагайтесь только на ограничения запросов по IP-адресам или на WAF и не откладывайте установку исправлений из-за того, что WAF уже стоит
- Сократите персональные данные, которые вам больше не нужны, включая неожиданную информацию в свободных полях заметок, и отзовите API-ключи сервисов, которые прекратили работу
По индикаторам (IP-адреса, User-Agent) используйте текущую страницу JPCERT/CC
Оповещение JPCERT/CC перечисляет подозрительные IP-адреса источников и примеры User-Agent, наблюдавшиеся в атаках. Список расширялся 9 и 23 октября и может снова измениться, поэтому этот сайт его не копирует. Проверяйте актуальный список в оповещении JPCERT/CC (JPCERT-AT-2026-0030, на японском языке).
JPCERT/CC просит организации проверить, обращались ли к ним перечисленные IP-адреса, чтобы выяснить, не было ли уже атаки. Используйте список как ориентир для поиска по прошлым логам, а не как блоклист. Что было добавлено к случаю B 23 октября:
- Один новый IP-адрес источника с датой, когда была зафиксирована атака или когда, по оценкам, активна инфраструктура атаки (JST). JPCERT/CC отмечает, что попытки атак могли происходить и вне этих дат. У случая E есть собственный отдельный список IP-адресов
- В качестве примера User-Agent — тот же User-Agent, что и у публичного приложения. Это значит, что по одному User-Agent нельзя отличить атакующий трафик от настоящего приложения
- Примеры TLS-отпечатков. JPCERT/CC пишет, что указанное значение JA4 совпадает с распространенными Python HTTP-клиентами, поэтому оно само по себе не идентифицирует атакующего и должно сочетаться с другими ориентирами
- Помимо перечисленных адресов, наблюдался доступ через выходные узлы Tor и резидентные прокси (сервисы ретрансляции, которые направляют трафик через домашние интернет-соединения)
JPCERT/CC говорит, что эти адреса могли использоваться законно на момент расследования, поэтому совпадение само по себе не доказывает проникновения. Смотрите, что именно делал этот источник, в ваших логах.
Если вы что-то нашли: действуйте в таком порядке
IPA просит организации оперативно объявлять инцидент безопасности, если они находят аномальные логи или учетные записи. Ожидание, пока что-то прояснится, может привести к тому, что логи истекут раньше, чем кто-либо на них посмотрит.
Объявите инцидент безопасности
Передайте аномалию ответственному лицу в тот же день и решите рассматривать её как инцидент. Объявление можно отозвать позже; запоздавшее начало уже не сделать более ранним.
Сохраните логи и доказательства
Логи исчезают по окончании срока хранения. Прежде чем что-либо удалять или перезаписывать, скопируйте серверные логи, логи, которые можно выгрузить из консолей внешних сервисов, и журналы аудита учетных записей в отдельное место. Спросите у специалистов, нужно ли сохранить образы дисков перед переустановкой сервера. Порядок действий описан в разделе «Что делать в первую очередь, если вы что-то нашли» в статье как проверить, взломан ли ваш сайт или сервер.
Привлеките специализированную фирму
Учитывая возможность утечки данных, IPA настоятельно рекомендует привлечь специализированную фирму по безопасности для подробного расследования. JPCERT/CC принимает запросы на реагирование на инциденты. Не решайте самостоятельно, насколько далеко продвинулся злоумышленник и что было похищено.
16 октября 2026 года IPA открыло специальную консультационную службу по несанкционированному доступу для компаний и организаций, которые пострадали или могли пострадать. Она консультирует о том, могли ли вы понести ущерб, и о мерах первой помощи, направляет к списку фирм, занимающихся реагированием на инциденты, и указывает другие места для консультаций или сообщений (телефон 03-6759-5760, по будням с 9:30 до 17:30, кроме перерыва с 12:00 до 13:00, на японском языке; принимается и электронная почта). Если вы не знаете, какой фирме звонить, можно начать с этой службы.
Сообщите в PPC и поделитесь информацией
Если персональные данные были или, возможно, были утечены, может потребоваться сообщение в PPC и уведомление затронутых людей. Сроки и место подачи сообщения кратко описаны в статье как проверить, взломан ли ваш сайт или сервер. Национальное бюро кибербезопасности просит пострадавшие организации оперативно передавать техническую информацию ему, соответствующему министерству и профильным органам, чтобы предотвратить дальнейший ущерб. Также доступны окно отчетности IPA и полицейские подразделения по киберпреступности.
Что сообщить руководству
В уведомлении Национального бюро кибербезопасности говорится, что ущерб от кибератак больше не является только проблемой IT-отдела, поскольку утечка может привести к остановке бизнеса, проблемам с обслуживанием клиентов и другим управленческим рискам. Оно просит руководство рассматривать кибербезопасность как управленческий вопрос и укреплять её, в том числе за счет необходимых инвестиций и кадров. IPA также просит срочно пересмотреть меры как вопрос управленческой ответственности.
Докладывая наверх, ограничьтесь четырьмя пунктами, чтобы руководство могло принять решение.
- Результаты этой недели: по каждому из трех направлений — были ли найдены аномалии, не найдено ничего или проверить не удалось
- Что не удалось проверить: периоды без логов, внешние сервисы или подрядчики, которых вы не смогли учесть
- Требуемые решения: стоимость более длительного хранения логов, постоянное соглашение со специализированной фирмой, требования к подрядчикам
- Готовность к работе с клиентами: текст уведомления и контактный пункт на случай утечки (JPCERT/CC рекомендует заранее подготовить предупреждения о последующем вреде)
Некоторые отрасли также получили требования от своих регуляторов. FSA попросило финансовые организации пересмотреть свои меры контроля, включая управление рисками третьих сторон и реагирование на инциденты, и оперативно устранить выявленные пробелы. Оно также попросило проверять изображения удостоверений личности и лиц на предмет всего неестественного при онлайн-проверке личности и заранее перейти к считыванию чипов IC, до 1 апреля 2027 года, когда подача изображений удостоверений личности перестанет быть допустимым методом.
Позиция этого сайта: «логов не было» — это результат, а не провал проверки
Проверки IPA предполагают, что вы можете посмотреть назад на месяц, затем на три месяца. На практике команды часто обнаруживают, что логи были настроены на истечение через 30 дней или что консоль внешнего сервиса показывает только две недели.
В таком случае не сообщайте «аномалий нет». Точный отчет звучит так: «аномалий за последний месяц нет; более ранние периоды проверить не удалось». Фиксация того, какие периоды и системы вы не смогли проверить, сразу подсказывает следующие исправления: более длительное хранение, отправку логов в другое место, обращение к поставщику. Проверка на этой неделе — это не только поиск аномалий, но и выяснение того, насколько далеко назад вы вообще можете видеть.
Сообщения для сотрудников и клиентов
NPA, ссылаясь на продолжающиеся утечки, просит компании поддерживать сетевое оборудование в актуальном состоянии и использовать надежные пароли, а частных лиц — не нажимать необдуманно на ссылки в письмах (это могут быть поддельные письма, выдающие себя за компанию, допустившую утечку), не повторять пароли и использовать многофакторную аутентификацию. После инцидента могут участиться поддельные сообщения от имени вашей организации. Сообщите сотрудникам и клиентам, что любой контакт нужно проверять через ваш официальный сайт. О том, как их распознать, см. что такое фишинг?
Источники (официальные, на японском языке)
- Секретариат кабинета министров, Национальное бюро кибербезопасности: Реагирование на утечки данных, вызванные несанкционированным доступом (9 октября 2026) — cyber.go.jp
- IPA: Меры, которые нужно оперативно принять в связи с утечками данных, вызванными несанкционированным доступом (9 октября 2026, обновляется по мере необходимости) — ipa.go.jp
- IPA: Открытие специальной консультационной службы по несанкционированному доступу (16 октября 2026, на японском языке) — ipa.go.jp
- IPA: Специальный сайт по противодействию несанкционированному доступу (16 октября 2026, на японском языке) — ipa.go.jp
- JPCERT/CC: Оповещение о недавней серии случаев несанкционированного доступа в японских организациях (JPCERT-AT-2026-0030, опубликовано 8 октября 2026, обновлено 23 октября) — jpcert.or.jp
- JPCERT/CC: Исследование техник атак, использованных в серии случаев несанкционированного доступа (JPCERT/CC Eyes, 15 октября 2026, на японском языке) — blogs.jpcert.or.jp
- Комиссия по защите персональных данных: Реагирование на масштабные утечки данных (предупреждение) (7 октября 2026; видеообъяснение добавлено 9 октября) — страница уведомления / предупреждение и приложение (PDF) / пресс-релиз (PDF)
- Комиссия по защите персональных данных: ПРЕДУПРЕЖДЕНИЕ: предотвращение утечек персональных данных, вызванных несанкционированным доступом (11 декабря 2024, пересмотрено 7 октября 2026) — ppc.go.jp
- Агентство по финансовым услугам: Укрепление кибербезопасности и обработка заявок на открытие счетов в текущей ситуации (9 октября 2026) — fsa.go.jp
- Национальное полицейское агентство: Cyber Police Agency Letter 2026 Vol.19 (октябрь 2026) — npa.go.jp
- JPCERT/CC: запрос на реагирование на инцидент — jpcert.or.jp
- IPA: сообщение о компьютерных вирусах и несанкционированном доступе — ipa.go.jp
Аналитика японских компаний по безопасности (не официальные документы, на японском языке):
- Macnica Security Research Center: О серии утечек данных из веб-систем (7 октября 2026, дополнение 8 октября) — security.macnica.co.jp
- GMO Cybersecurity by IERAE: Три пункта для подготовки к серии случаев несанкционированного доступа (15 октября 2026) — gmo-cybersecurity.com
- GMO Cybersecurity by IERAE: Подтверждено, что ИИ стоит за многими источниками недавнего несанкционированного доступа (19 октября 2026, обновлено 21 октября) — gmo-cybersecurity.com
История обновлений
2026-10-24: Учтено оповещение JPCERT/CC в редакции от 23 октября. Схемы атак выросли с четырех до пяти (случай E: попытки атак, злоупотребляющие платформами тестирования на проникновение на основе ИИ, включая попытки против серверов WSUS, открытых в интернет). Добавлены новые ориентиры в случае B (тот же User-Agent, что и у публичного приложения; JA4 сам по себе не идентифицирует атакующего; доступ через Tor и резидентные прокси; использование IP-адресов для поиска прошлого доступа). Добавлена ссылка на обзор атак с использованием ИИ и порядок защиты.
2026-10-23: Добавлен анализ двух японских компаний по безопасности (от 7, 15 и 19 октября): 80% утечек, раскрытых с июля, нельзя классифицировать по причине по уведомлениям; атаки, которые остаются ниже порогов WAF; использование системы автономного тестирования на проникновение на основе ИИ; три проверки (область оценки, отказ от опоры только на WAF, сокращение ненужных данных и API-ключей).
2026-10-22: Добавлено изучение JPCERT/CC серверов атакующих (опубликовано 15 октября): API, выявленные путем анализа приложений, и четыре меры противодействия. Flutter назван примером скомпилированных приложений, как это делает JPCERT/CC.
2026-10-19: Добавлены специальная консультационная служба IPA по несанкционированному доступу (открыта 16 октября) и её специальный сайт. Подтверждено, что оповещение IPA от 9 октября по состоянию на 19 октября не обновлялось.
2026-10-14: Проверен текст предупреждения PPC и кратко изложено в таблице его приложение о пересмотренных примерах для «10-6 Технические меры защиты» (окончательная редакция в апреле 2027). Меры из случая 9 (злоупотребление API) пересмотренного ПРЕДУПРЕЖДЕНИЯ добавлены в проверку приложений, доступных из интернета, а случай 8 (утечка из облачного сервиса, которым вы пользуетесь) — в проверку внешних сервисов. Обновлены список документов и источники.
2026-10-12: Первая публикация. Документы Национального бюро кибербезопасности, IPA, JPCERT/CC, PPC, FSA и NPA проверены 12 октября 2026. Страница IPA обновляется по мере необходимости, оповещение JPCERT/CC может получать дополнения; статья будет обновлена, если они изменятся.
Читайте далее
- Полная картина атак с использованием ИИ и порядок защиты: Защита от кибератак с использованием ИИ (автономное проникновение, prompt injection, цепочка поставок ИИ)
- Более широкая картина для организаций: Базовые требования безопасности для организаций (шесть приоритетов по инцидентам Японии 2026 года)
- Проверка собственного сайта: Как проверить, взломан ли ваш сайт или сервер
- Точки входа: VPN-устройства — самый большой путь проникновения / Расстановка приоритетов с помощью CVSS, EPSS и KEV
- Инвентаризация: Чек-лист инвентаризации безопасности / Публичная открытость облачных хранилищ
- Термины: Что такое IOC?
- Все инциденты 2026 года: Утечки данных и кибератаки 2026 года