Кратко

  • 15 сентября изменение конфигурации одного компонента MyAPNIC затронуло другие функции сильнее, чем ожидалось. 17 сентября проблема базы данных задержала письма в тикет-систему и сделала некоторые функции MyAPNIC недоступными.
  • Одинаковые 28 минут и близкие даты не доказывают общей причины. Нужен ответ, сравнивал ли APNIC зависимости и нашёл связь, исключил её или оставил вопрос открытым.

В сообщении от 15 сентября APNIC указывает интервал с 13:58 до 14:26 UTC+10. Был затронут портал участников MyAPNIC. Изменение конфигурации одного компонента оказало более широкое, чем предполагалось, влияние на другие функции. APNIC готовит исправление, чтобы аналогичные изменения не повторяли такой эффект.

Сообщение от 17 сентября описывает другой 28-минутный интервал — с 14:50 до 15:18. На этот раз названа проблема базы данных. Письма в тикет-систему задерживались, а часть функций MyAPNIC была недоступна. APNIC намерен улучшить мониторинг базы данных.

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

Между началом событий прошло 48 часов 52 минуты. Одинаковая длительность может отражать общую периодичность обнаружения, эскалации или восстановления. Она может быть совпадением. Это основание для проверки, а не для причинного вывода.

Из публичных данных не видно, сопоставлял ли APNIC аутентификацию, очереди, хранилища данных, конфигурационные системы, пути развёртывания, пробелы мониторинга или операционные передачи. Не опубликовано и заключение: общий фактор найден, исключён или остаётся неизвестным.

Для ответа не требуется раскрывать внутреннюю топологию. Безопасная для приватности запись могла бы назвать оба инцидента, классы затронутых функций, окно доказательств и проверенные области зависимостей. Результат имеет три состояния: связь найдена, исключена или неизвестна. Достаточно также указать владельца действия, статус локализации и дату пересмотра.

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

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

Источники