Кратко

  • APNIC сообщила, что во втором квартале 2026 года завершила многолетний перенос с утративших поддержку хостов CentOS на контейнерные платформы или RHEL9.
  • Публичные материалы также описывают DAST, SAST, сообщения об уязвимостях, классификацию и хранение данных, DLP и эмуляцию действий противника, однако смешивают итоги, текущую работу, цели и постоянные правила.
  • Четыре безопасные связки остаются вне публичной проверки: реестр активов — вывод платформы, находка — исправление, классификация — удаление, сценарий — подтверждённое обнаружение в промышленной среде.
  • Ежеквартальная квитанция о закрытии контроля может показывать знаменатели, исключения, возрастные интервалы, исходы и повторные тесты без раскрытия систем, уязвимостей, персональных данных и живых правил обнаружения.

Редкий случай, когда слово «завершено» имеет границы

30 июня 2026 года APNIC опубликовала материал об укреплении основ безопасности. В нём сказано, что во втором квартале завершилась многолетняя программа обновления ключевой инфраструктуры. Хосты Linux CentOS, чей жизненный цикл закончился, были переведены на контейнерные платформы или Red Hat Enterprise Linux 9. Поддерживаемые системы, поясняет APNIC, легче исправлять, контролировать и защищать при появлении новых уязвимостей.

Годовой отчёт за 2025 год фиксирует два соседних результата. Перенос существующих проектов с виртуальных машин на Kubernetes завершён. Альтернативная платформа виртуализации выбрана и внедрена, миграция закончена.

В документах нет числа охваченных сервисов, списка исключений или метода итоговой проверки. Из них также нельзя заключить, что у APNIC остался CentOS. Зато утверждение содержит исходное состояние, семейство замены и квартал завершения. Его можно сверить с агрегированным знаменателем.

Именно поэтому этот фрагмент полезен как контрольный образец. Вопрос не в раскрытии хостов. Вопрос в том, можно ли провести публичное утверждение от охвата через действие к исходу и повторной проверке.

Итог, процесс, цель и правило — разные классы

Годовой отчёт в основном описывает фактические итоги. DAST внедрён. Шесть критических уязвимостей выявлены и исправлены. Сертификация ISO 27001:2022 достигнута.

Июньская публикация сочетает результат и процесс. DAST распространён на портфель критически важных приложений и дополняет SAST, HackerOne и программу сообщений об уязвимостях. Microsoft Purview развёрнут и применяется для присвоения уровней чувствительности и определения сроков хранения. Усиленные механизмы DLP на конечных устройствах и в облачных службах ещё внедряются; первоначальное повышение зрелости намечено на третий квартал. Контролируемая эмуляция противника выполняется для улучшения обнаружения в производственной среде.

План деятельности на 2026 год перечисляет цели. Первичное сканирование публичных сайтов WordPress и более близкая к производству локальная тестовая среда намечены на третий квартал. Активно-активные пограничные межсетевые экраны и проверка путей обнаружения атак в критической инфраструктуре — на второй. Разбор и исправление критических уязвимостей в течение тридцати дней указаны как постоянный целевой результат.

Протокол Исполнительного совета за декабрь 2025 года фиксирует приоритеты: внедрить политику хранения и удаления с пилотным проектом в Fellowship Application System, усилить DLP, создать внутреннюю красную команду и проводить внешнее сканирование всех публичных веб-сервисов.

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

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

Связка первая: от реестра к выводу платформы

Публичной сверке не нужны имена серверов. Нужен знаменатель.

APNIC могла бы выбрать единицу — хост, рабочую нагрузку или сервис — и зафиксировать число элементов в охвате CentOS на исходную дату. Затем сумма распределяется между перенесёнными, перестроенными, выведенными и формально исключёнными. Исключения достаточно группировать по широким причинам и кварталу следующего пересмотра. Метод проверки можно назвать без деталей: конфигурационный реестр, подтверждение развёртывания или независимая выборка.

Так слово «завершено» получает устойчивое значение. Административное закрытие проекта, остановка последнего производственного хоста и удаление последней старой зависимости — близкие, но разные состояния. Источники не показывают, что APNIC смешала их. Квитанция нужна для того, чтобы внешнему читателю не пришлось гадать.

Связка вторая: от находки к повторной проверке

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

Безопасная таблица могла бы для каждого канала и уровня тяжести показывать начальный остаток, новые находки, закрытия, возрастные интервалы, просроченные случаи, ложные срабатывания, принятые риски и повторные открытия. Ключевое поле — повторный тест. Оно отделяет доставленное изменение от подтверждения, что исходное условие отказа больше не воспроизводится.

Институциональные границы тоже важны. Уязвимость продукта APNIC, инцидент в собственных системах и жалоба на злоупотребление с участием члена APNIC идут по разным маршрутам. Страница безопасности APNIC уже разделяет эти обращения. Единый процент закрытия скрыл бы различия в сроках, полномочиях и ответственности.

Название уязвимости, система и способ исправления для такой сверки не нужны. Достаточно диапазонов, исходов и даты ретеста.

Связка третья: от класса к судьбе данных

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

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

Содержание анкет, точные сроки и причины отдельных решений останутся закрытыми. Публичным будет лишь факт, что правило дошло до объекта и закончилось решением.

Годовой отчёт также говорит о завершении проекта хранилища данных, каталогизации всей информации в нём и запуске средств запросов. Это ограниченный и полезный результат. Он не доказывает классификацию или удаление во всём массиве APNIC. Каталог, класс, расписание и исход — четыре стадии.

Связка четвёртая: от сценария к сигналу в промышленной среде

Эмуляция противника проверяет не намерение, а принимающую сторону. APNIC сообщает о контролируемой программе, которая должна улучшать средства обнаружения в производственной среде, проверять мониторинг и реагирование и находить направления улучшения.

Техники, пути атаки и действующие правила публиковать нельзя. Агрегированные результаты возможны: класс сценария, цель обнаружения, статус — успешно, частично или неуспешно —, состояние исправления и квартал повторного теста. Можно также показать долю целей, которые дали своевременный сигнал и дошли до нужной роли реагирования.

«Учение проведено» доказывает активность. «Цель обнаружена и повторно проверена после настройки» доказывает контроль. Публичная отчётность должна сохранять обе фразы и не подменять вторую первой.

Сертификат задаёт рамку, но не закрывает строку

Политика APNIC указывает, что сертификат ISO/IEC 27001:2022 выдан 10 сентября 2025 года. Протокол совета отмечает успешный повторный аудит в августе, а годовой отчёт — дополнительные меры контроля в редакции 2022 года.

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

Ежеквартальная квитанция закрытия

Форма поместится на одной странице: население в охвате, контроль или действие, класс доказательства — цель, внедрено, проверено, закрыто, повторно проверено —, агрегированный исход, исключения, дата проверки, ответственная роль и следующий пересмотр. Исправления сохраняются версиями.

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

В случае CentOS APNIC уже показала чёткую границу завершения. Четыре дополнительные связки не сделают рассказ громче. Они превратят набор реальных действий в проверяемую историю контроля.

Источники