ICANN сделала смену корневого ключа DNSSEC публичной проверкой операционной подотчётности

Резюме

• Смена корневого ключа подписи ключа DNSSEC, проведённая ICANN в октябре 2018 года, изменила публичный якорь доверия, который используют проверяющие резолверы DNSSEC для проверки корня DNS. На странице ICANN о смене ключа указано, что резолвер без актуального корневого якоря доверия не сможет разрешать DNS-запросы после изменения, что превратило готовность в вопрос непрерывности, а не в узкую криптографическую процедуру обслуживания.
• Наиболее значимым фактом подотчётности стала задержка. ICANN отложила первоначально запланированную на октябрь 2017 года смену после того, как новые данные телеметрии RFC 8145 показали, что значительное число резолверов, используемых интернет-провайдерами и сетевыми операторами, может быть не готово. Это решение превратило скрытую проблему готовности операторов в публичную запись управления.
• Позднее ICANN перешла к выполнению 11 октября 2018 года после одобрения Правления, публичных комментариев, дополнительной разъяснительной работы, технического анализа и пересмотренного плана. После события ICANN объявила, что немногие обнаруженные проблемы были быстро устранены и не указывали на системный сбой, требующий отката.
• Практический контроль был распределён. ICANN и Public Technical Identifiers контролировали процесс церемоний корневого KSK, публикацию, документацию, разъяснительную работу и окончательное решение о смене; Verisign выполняла функции оператора корневой зоны; операторы резолверов контролировали конфигурацию якоря доверия и поведение ПО; поставщики контролировали качество реализации RFC 5011; государственные органы и компании контролировали планы резервного восстановления для своих сетей.
• Урок подотчётности в том, что изменения глобальной интернет-инфраструктуры требуют наблюдаемой готовности, опубликованных критериев принятия решений, проверки сообществом, продуманного отката и достаточной скромности, чтобы отложить изменение, когда телеметрия подрывает уверенность. Смена прошла успешно именно потому, что к ней отнеслись как к публичному операционному риску, а не потому, что риск был воображаемым.

Корневой ключ был мал, но зависимость от него была глобальной

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

Посвящённая этомустраница ICANN о смене KSK корневой зоныявляется базовым источником. На ней объясняется, что ICANN выполнила смену 11 октября 2018 года, что смена KSK означает генерацию новой пары открытого и закрытого ключей и распространение открытой части среди операторов проверяющих резолверов и что поддержание актуального KSK необходимо, поскольку отсутствие текущего KSK корневой зоны означает, что проверяющие резолверы DNSSEC не смогут разрешать DNS-запросы. Это и есть вся проблема подотчётности простыми словами. Изменение центрального объекта доверия превращается в простой пользователей, когда распределённые операторы не обновили локальное состояние проверки.

KSK не существовал изолированно. На странице ICANN о смене ключа первоначальное планирование описывается как работа партнёров по управлению корневой зоной: ICANN как оператора функций IANA, Verisign как оператора корневой зоны и NTIA Министерства торговли США как администратора корневой зоны до завершения роли NTIA 1 октября 2016 года.Страница IANA об управлении корневой зонойслужит текущей публичной точкой входа в управление корневой зоной, астраница IANA о корневом KSK DNSSECсодержит информацию о якоре доверия и церемониях KSK.

Таким образом, операционная история находится на пересечении управления ICANN, функций PTI/IANA, операций Verisign с корневой зоной и множества независимых операторов резолверов, которые используют корневой якорь доверия.

Техническая архитектура DNSSEC объясняет, почему это событие имело значение.RFC 4033определяет введение и требования DNSSEC,RFC 4034— записи ресурсов, используемые DNSSEC, аRFC 4035— изменения протокола. Эти стандарты не являются доказательствами конкретного инцидента ICANN. Они объясняют цепочку проверки, которая сделала корневой ключ значимым. Проверяющий резолвер либо имеет приемлемый путь доверия, либо нет. В отличие от сертификата веб-сайта, который один оператор может заменить для одной службы, корневой якорь доверия — это общая инфраструктура.

Поэтому ставка на публичную непрерывность была широкой. Интернет-провайдеры, компании, университеты, государственные органы, провайдеры рекурсивного DNS, реестры, регистраторы, облачные сети, дистрибутивы ПО, поставщики устройств и обычные пользователи не все были прямыми клиентами ICANN. Тем не менее их разрешение DNS могло зависеть от того, был ли подготовлен их рекурсивный резолвер. Именно поэтому в собственном объявлении ICANN о переносе 2017 года оценивалось, что примерно каждый четвёртый пользователь интернета в мире, или около 750 миллионов человек, полагался на проверяющие резолверы DNSSEC и мог пострадать от плохо выполненной смены.

Эта цифра не была предсказанием, что все эти пользователи потерпят неудачу. Это была оценка численности зависимой аудитории.

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

Задержка стала стержнем подотчётности

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

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

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

ICANN выбрала задержку. Это решение легко хвалить задним числом, поскольку последующая смена прошла успешно. Но в тот момент оно имело свою цену. Перенос мог подорвать доверие к плану, продлить период с двумя опубликованными ключами, отсрочить операционные действия, требуемые Практикой DNSSEC ICANN, и дать сигнал неопределённости операторам, которые уже подготовились к дате 2017 года. Однако продолжение рисковало тем, что операторы резолверов и их пользователи обнаружат проблемы готовности только тогда, когда имена перестанут разрешаться.

Объявление о переносе необычно откровенно для управления инфраструктурой. В нём говорилось, что у операторов может быть несколько причин отсутствия нового ключа, включая неверную настройку ПО резолвера и недавно обнаруженную проблему в одной широко используемой программе резолвера, которая, судя по всему, не обновляла ключ автоматически, как ожидалось. Также сообщалось, что ICANN обращается к сообществу, включая SSAC, региональные интернет-реестры, группы сетевых операторов и других.

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

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

Задержка также сохранила подотчётность операторов резолверов. ICANN не могла войти в каждый рекурсивный резолвер и установить якорь доверия. Операторы интернет-провайдеров, компаний, государственных сетей и DNS-сервисов контролировали собственное ПО и конфигурацию резолверов. Отложив смену, ICANN сделала проблему готовности публичной и дала этим операторам дополнительное время. Это не перекладывало на них всю ответственность, но делало модель совместного контроля видимой.

Автоматизация RFC 5011 была полезной, но не волшебной

Смена в значительной степени зависела от автоматического обновления якорей доверия.RFC 5011определяет автоматическое обновление якорей доверия DNSSEC. Привлекательность RFC 5011 очевидна: проверяющий резолвер может наблюдать новый ключ в течение периода удержания при добавлении и автоматически принять его как якорь доверия. Без такого механизма каждому оператору проверяющего резолвера пришлось бы вручную устанавливать ключи в масштабах всего интернета.

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

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

Страница Verisign о смене KSKотразила это различие с точки зрения оператора корневой зоны и корневых серверов. Там говорилось, что каждому валидатору DNSSEC нужен якорь доверия и что RFC 5011 никогда не тестировался в production для смены корневого KSK. Также сообщалось, что Verisign как оператор корневого сервера получала некоторые данные RFC 8145 и анализировала их, чтобы выявить источники с устаревшей конфигурацией якоря доверия. Это важно, поскольку показывает, что телеметрия не была только центральной панелью ICANN. Операторы корневых серверов тоже могли видеть сигналы готовности и реагировать на них.

Автоматизация сделала смену возможной, но публичная подотчётность требовала независимых доказательств того, что автоматизация сработала. Такими доказательствами были сигнализация якорей доверия, тестирование ПО резолверов, разъяснительная работа с операторами, которые выглядели устаревшими, публичные комментарии, обсуждения в списках рассылки и мониторинг после события. Сюда же относилась готовность определить порог отката, если сбой окажется достаточно массовым.

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

Урок не в том, что RFC 5011 ненадёжен. Урок в том, что распределённые механизмы автоматического обновления нуждаются в телеметрии и социальной координации, когда защищают общую инфраструктуру. Стандарт может определить конечный автомат. Он не может заставить каждого оператора понять, работает ли этот конечный автомат правильно в его сети.

Публичные комментарии превратили техническое изменение в запись управления

После переноса ICANN не просто выбрала новую дату в частном порядке. Еёстраница публичных комментариев «План перезапуска процесса смены корневого ключа подписи ключа»открыла пересмотренный план для проверки сообществом. На странице говорилось, что план включает более широкое информирование о готовности, более тщательный анализ данных о готовности и саму смену 11 октября 2018 года. СвязанныйPDF «План продолжения смены корневого KSK»описывал предлагаемый перезапуск после предыдущей задержки.

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

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

Вобъявлении об одобрении Правлениемговорилось, что Правление одобрило планы первой в истории смены криптографического ключа, защищающего корень DNS, и поручило организации выполнить её 11 октября 2018 года. В объявлении признавалось, что невозможно полностью гарантировать, что у каждого сетевого оператора резолверы будут настроены правильно, но ICANN ожидала, что подавляющее большинство будет иметь доступ к корневой зоне. Также говорилось, что наихудшим вариантом исправления для оператора было бы отключить проверку DNSSEC, установить новый ключ и снова включить проверку.

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

Справедливый рассказ не должен делать вид, что публичные комментарии устранили риск. Они изменили бремя доказательства. ICANN должна была объяснить, почему продолжение в октябре 2018 года лучше дальнейшей задержки. Операторы должны были использовать дополнительный год для проверки собственной готовности. Сообщество должно было признать, что общий якорь доверия нельзя сменить только при нулевой неопределённости, потому что нулевая неопределённость не наступает никогда.

Коммуникация была частью контроля, а не связей с общественностью

Материалы ICANN по информированию были операционными средствами контроля. Страница о смене связывала ресурсы дляпроверки текущих якорей доверия в проверяющих резолверах DNSиобновления проверяющих резолверов последним якорем доверия. Эти документы не были маркетингом. Это были практические инструкции для операторов, которые контролировали последний отрезок готовности.

Комплексное руководство о том, чего ожидать во время смены корневого KSK, обеспечило ещё одну форму контроля: управление ожиданиями. Операторам нужно было знать, что изменится, когда это произойдёт, как могут проявляться симптомы и что делать при сбое проверки. Молчаливое центральное изменение оставило бы каждое расследование сбоя начинать с нуля. Публичное руководство дало службам поддержки, сетевым командам и сотрудникам безопасности общую рамку.

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

Коммуникация должна была достичь и сетей государственного сектора. Метка «Непрерывность государственного сектора» уместна, потому что государственные службы, школы, больницы, управления по чрезвычайным ситуациям и госорганы часто зависят от рекурсивного DNS, настроенного центральной ИТ-организацией или поставщиком. Устаревший проверяющий резолвер в такой среде воспринимался бы не как учебное занятие по DNSSEC, а как невозможность доступа к сервисам.

Урок непрерывности государственного сектора в том, что улучшения безопасности могут создавать риск доступности, когда обновления якорей доверия скрыты от владельцев сервисов. Городское агентство может не знать, проверяет ли его вышестоящий резолвер. Команда сети больницы может полагаться на управляемое устройство DNS. Школьный округ может наследовать поведение резолвера интернет-провайдера. Публичные материалы ICANN не могли заставить эти организации провести тестирование, но дали им способ задать правильные вопросы.

Коммуникация также должна была избегать паники. ICANN нужно было предупредить, что неподготовленные проверяющие резолверы могут отказать, не намекая, что весь интернет погаснет. Нужно было объяснить, что большинство непроверяющих резолверов не затронуто напрямую, не отбивая желание внедрять DNSSEC. Нужно было описать отключение проверки как аварийный вариант восстановления, не делая этот вариант стандартным. Такой баланс операционно сложен. Слишком мало тревоги вызывает бездействие. Слишком много тревоги вызывает недоверие к самому механизму безопасности.

Решение о запуске приняло остаточный риск

Одобрение сентября 2018 года не означало, что ICANN доказала безопасность каждого резолвера. Оно означало, что ICANN приняла остаточный риск после дополнительной разъяснительной работы, анализа и консультаций с сообществом. Это различие центрально для подотчётности.

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

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

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

Таким образом, решение о запуске принадлежало руководству ICANN и управлению Правления, но опиралось на распределённые данные. Операторы резолверов, обновившие якоря доверия, создавали готовность. Поставщики ПО, чьи реализации вели себя корректно, создавали готовность. Корневые операторы, анализировавшие сигналы, создавали готовность. Рецензенты из сообщества, оспаривавшие предположения, создавали готовность. ICANN координировала и принимала решение, но не в одиночку делала распределённую систему готовой.

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

Само событие прошло тихо, потому что подготовка не была тихой

11 октября 2018 года ICANN выполнила смену. В постсобытийном объявлении ICANN от 15 октября говорилось, что после оценки доступных данных не выявлено значительного числа конечных пользователей интернета, которые пострадали бы устойчиво и негативно. Сообщалось, что немногие возникшие проблемы были быстро устранены и не указывали на системный сбой, требующий отката. Также говорилось, что ICANN приступит к отзыву старого KSK, KSK-2010, на следующей церемонии ключей в первом квартале 2019 года.

Более позднийОбзор смены KSK DNSSEC 2018 года— самый сильный постсобытийный источник. В нём KSK-2010 определён как якорь доверия, использовавшийся до смены 2018 года, а KSK-2017 — как ключ, впервые подписавший корневую зону 11 октября 2018 года. Там же задокументированы уроки первой производственной смены. Отчёт об обзоре не делает ICANN нейтральным наблюдателем собственной работы, но он ценнее победного объявления, поскольку создаёт долговременную запись для следующей смены.

Тишину события не следует принимать за доказательство того, что риск был преувеличен. Многие изменения инфраструктуры проходят тихо именно потому, что операторы откладывали, тестировали, общались и наблюдали. Испытание моста, выявившее слабость до обрушения, — не ложная тревога. В этом смысл тестирования. Поэтому задержка 2017 года — часть успеха 2018 года, а не отдельное пятно.

Постсобытийная запись также ограничивала масштаб утверждений. Не говорилось, что никто не пострадал. Говорилось, что не было значительного числа устойчивых негативных последствий для конечных пользователей и системного сбоя. Это правильный уровень для глобального изменения инфраструктуры. У отдельных операторов могли быть локальные проблемы. Важным вопросом было, вызвало ли изменение корневого якоря доверия широкий и длительный сбой разрешения DNS.

Шаг отзыва старого ключа тоже важен. Смена не завершена только потому, что используется новый ключ. Старый якорь доверия должен быть выведен из эксплуатации так, чтобы подтвердить, что валидаторы приняли новое состояние. Обзор ICANN и последующие материалы церемоний показывают, что смена была последовательностью, а не одной меткой времени.

Власть делегирования DNS реальна даже без переделегирования домена

Метка «Власть делегирования DNS» обычно вызывает в памяти контроль над записями корневой зоны, делегированиями доменов верхнего уровня, отношениями с регистраторами и владением именами. Смена KSK показывает другую форму власти делегирования: контроль над цепочкой доверия проверки корневой зоны. ICANN не переделегировала TLD и не меняла домен регистранта. Она изменила криптографический ключ, который проверяющие резолверы используют, чтобы решить, можно ли доверять подписанным данным корня.

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

Практика DNSSEC оператора корневого KSKуместна, поскольку задаёт ожидания того, как оператор корневого KSK выполняет управление ключами. Практики — сухие документы, но это инструменты подотчётности. Они определяют церемонии, роли, средства контроля и ожидания, позволяющие сообществу оценить, действует ли оператор в рамках опубликованных процедур. Когда ICANN сменила ключ, она не просто реализовывала усмотрение; она выполняла документированную операционную ответственность.

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

Власть делегирования DNS становится подотчётной, когда существует публичная цепочка от решения к артефакту и действиям оператора. Решение о смене задокументировано. Открытый ключ опубликован. Ожидаемое поведение оператора описано. Телеметрия обсуждена. Одобрение Правления зафиксировано. Постсобытийный обзор опубликован. Эта цепочка не устраняет вред, но делает осуществление полномочий проверяемым.

Контраст с частным сбоем платформы полезен. Частный SaaS-провайдер иногда может общаться только с клиентами и публиковать мало. У ICANN в том же смысле такой возможности не было. Корневой KSK — публичная зависимость интернета. Канал подотчётности должен был быть публичным, потому что аудитория зависимости была публичной.

Операторы резолверов тоже были подотчётны

Центральный анализ, который винит или хвалит только ICANN, упускает половину системы. Операторы резолверов делали смену безопасной или рискованной в своих сетях. Если интернет-провайдер включил проверку DNSSEC для миллионов пользователей, он контролировал, обновлены ли его резолверы, отслеживаются ли они и протестированы ли. Если компания использовала проверяющие резолверы для внутреннего и внешнего разрешения, она контролировала, включена ли в управление изменениями готовность корневого якоря доверия. Если госорган передал DNS поставщику, он контролировал вопросы к поставщику и ожидания непрерывности.

Документы ICANNпо проверке текущих якорей доверияипо обновлению проверяющих резолверовдавали практические шаги, но операторы должны были их использовать. Центральная организация не может вечно компенсировать локальную небрежность. Резолвер с включённой проверкой, но без мониторинга сбоев DNSSEC — скрытый риск непрерывности. Резолвер, чей файл якоря доверия перезаписывается системой управления конфигурацией, — скрытый риск непрерывности. Устройство поставщика, некорректно реализующее RFC 5011, — скрытый риск непрерывности.

Государственный аспект делает это конкретным. Правительственные органы и критически важные публичные службы часто наследуют выбор DNS от общих служб, облачных провайдеров, поставщиков управляемой безопасности, сетевых интеграторов или телеком-контрактов. Эти органы могут не быть экспертами по DNS, но могут требовать от поставщиков доказательств: включена ли проверка DNSSEC, какое ПО резолвера используется, как обновляются корневые якоря доверия, как отслеживаются сбои проверки и как утверждаются экстренные изменения.

Операторы также контролировали путь восстановления. В объявлении об одобрении Правления ICANN описывалось отключение проверки DNSSEC, установка нового ключа и повторное включение проверки как наихудший вариант исправления для неподготовленного оператора. Этот аварийный путь не идеален, потому что отключение проверки убирает контроль безопасности, даже временно. Но это лучше, чем оставить пользователей без разрешения имён. Вопрос подотчётности в том, был ли этот путь задокументирован у операторов до изменения, а не обнаружили ли они его во время кризиса.

Поэтому смена относится к серии о рисках и подотчётности, а не только к истории DNSSEC. Событие проверило, могут ли распределённые операторы согласовать свои локальные практики с центральным изменением безопасности. Глобальный контроль безопасности настолько устойчив, насколько устойчивы наименее подготовленные организации, зависящие от него для непрерывности.

Телеметрия создала обязанность интерпретации, а не определённость

Сигнализация якорей доверия RFC 8145 — один из самых интересных элементов истории, потому что она создала видимость и неопределённость одновременно. Сигнал мог указывать, какие якоря доверия резолвер считал настроенными. Но корневые серверы видят трафик DNS, а не организационные намерения. Один видимый адрес источника мог представлять множество пользователей или лабораторию. Некоторые сигналы могли быть устаревшими. Некоторые резолверы могли не сигнализировать. Некоторые сети могли перенаправлять трафик через уровни, скрывающие фактический проверяющий резолвер.

Задержка 2017 года показывает, что ICANN относилась к телеметрии как к значимой для решения, даже если она несовершенна. Это хорошее управление, но оно также создаёт обязанность объяснять интерпретацию. Если телеметрия указывает на риск, лидеры должны решить, достаточно ли реален риск для задержки. Если последующая телеметрия всё ещё показывает устаревшие сигналы, лидеры должны решить, представляют ли эти сигналы значимое влияние на пользователей или управляемый остаточный шум.

Обзор смены и технические обновления показывают эту аналитическую нагрузку.Страница ресурсов ICANN о сменесобрала технические обновления, обзорные материалы и руководства для операторов в одном месте.Обновление от 18 декабря 2017 года по проекту смены корневого KSKзафиксировало состояние анализа после переноса. Смысл таких документов не в достижении идеальной уверенности, а в предотвращении превращения решения в слухи.

У подотчётности телеметрии две стороны. ICANN и корневым операторам нужно было избегать переоценки сигнала. Операторам резолверов нужно было избегать его игнорирования. Если резолвер сети сигнализировал старый якорь доверия, оператор не мог разумно ожидать, что центральное сообщество выявит и исправит локальную конфигурацию без сотрудничества. Наоборот, ICANN не могла разумно продолжать, не показав, почему наблюдаемые устаревшие сигналы не означают неприемлемого глобального сбоя.

Этот баланс всё более актуален за пределами DNS. Современные изменения инфраструктуры часто связаны с зашумлённой телеметрией от распределённых клиентов, агентов, резолверов, сертификатов, менеджеров пакетов или конечных точек. Урок смены KSK в том, что несовершенные данные не должны ни парализовать, ни отбрасываться. Они должны запускать прозрачную интерпретацию и подотчётные критерии принятия решений.

Что ICANN контролировала, а что нет

ICANN контролировала центральный процесс KSK через функции IANA и роль Public Technical Identifiers, включая церемонии ключей, публикацию, документы планирования, консультации с сообществом, разъяснительную работу, техническое руководство, эскалацию в Правление, рекомендацию запуска/отказа, мониторинг и постсобытийный обзор. ICANN не контролировала каждый проверяющий резолвер, каждый пакет ПО, каждое окно изменений интернет-провайдера, каждую конфигурацию компании или каждый DNS-контракт государственного сектора.

Verisign контролировала функцию оператора корневой зоны и управляла инфраструктурой корневых серверов, важной для наблюдения и координации. Она не контролировала локальное состояние валидаторов внутри каждой сети. Проекты ПО резолверов контролировали качество реализации поведения RFC 5011 и проверки DNSSEC. Поставщики устройств и дистрибутивы операционных систем контролировали упаковку и поведение по умолчанию. Сетевые операторы контролировали развёртывание. Госорганы и компании контролировали закупки, мониторинг и планирование резервного восстановления.

Конечные пользователи не контролировали почти ничего из этого. Гражданин, чей резолвер интернет-провайдера не прошёл проверку, не знал бы, была ли причина в устаревшем якоре доверия, сбое DNSSEC, проблеме маршрутизации, приложении или недоступности сайта. Малый бизнес, использующий управляемый роутер, не знал бы, приняло ли его DNS-устройство KSK-2017. Эта асимметрия — причина, по которой подотчётность должна лежать на операторах инфраструктуры, а не на пользователях.

Поэтому вопрос подотчётности не в том, «Кто владел интернетом?» Никто. Вопрос в том, кто контролировал каждую значимую часть смены. ICANN контролировала центральные полномочия и публичную координацию. Операторы контролировали готовность. Поставщики контролировали код. Публичные институты контролировали ожидания непрерывности. У каждого была своя обязанность.

Эта многоуровневая карта также предотвращает поверхностный рассказ об успехе. ICANN правильно отложила смену и продолжила после получения данных. Но будущие смены не должны каждый раз полагаться на героическую разъяснительную работу. Операторы резолверов должны институционализировать инвентаризацию якорей доверия. Поставщики должны сделать состояние проверки видимым. Госорганы должны требовать от поставщиков доказательств непрерывности DNSSEC. Управление корневой зоной должно продолжать публиковать планы и обзоры. Успех должен стать повторяемой практикой, а не одноразовым воспоминанием.

Следующая смена должна унаследовать доказательства, а не удачу

Текущаястраница ICANN о смене алгоритма корневого KSKпоказывает, что криптографическое обслуживание корневой зоны продолжается. Будущая смена алгоритма отличается от смены ключа 2018 года, поскольку меняет криптографический алгоритм, а не просто заменяет один RSA-ключ другим RSA-ключом. Эта будущая работа делает запись подотчётности 2018 года более ценной, а не менее. Первая смена создала шаблон публичного планирования, разъяснительной работы, телеметрии, одобрения Правления, руководства для операторов и постсобытийного обзора.

Шаблон следует улучшить. Во-первых, телеметрия должна быть проще для связи операторов с их собственной инфраструктурой. Центральный сигнал менее полезен, если оператор не может определить, какое устройство его создало. Во-вторых, ПО резолверов должно показывать состояние якоря доверия способами, которые обычные сетевые команды могут отслеживать. В-третьих, закупки государственного сектора и компаний должны рассматривать рекурсивный DNS как инфраструктуру непрерывности. В-четвёртых, аварийное отключение проверки должно отрабатываться как крайняя мера с последующим восстановлением, а не нормализоваться как долгосрочный обходной путь.

В-пятых, ICANN должна продолжать публиковать критерии принятия решений заранее, чтобы будущие задержки или решения о запуске можно было оценивать по известному стандарту.

Смена 2018 года также показывает ценность ограниченной уверенности. ICANN продолжила, признав, что некоторые операторы не будут готовы. Это честно. Критическая инфраструктура не может ждать идеального соблюдения каждым участником. Но честный остаточный риск должен сопровождаться данными о восстановлении: кто мониторит, как будут обнаружены проблемы, какие пороги запускают откат, как операторы получают помощь и как публикуются постсобытийные уроки.

Тот же стандарт должен применяться к сетям государственного сектора. Органы должны знать, кто предоставляет рекурсивный DNS, включена ли проверка, обновляются ли корневые якоря доверия автоматически, есть ли сигналы о сбоях DNSSEC и как связаться с поставщиком во время криптографического изменения корневой зоны. Если госорган не может ответить на эти вопросы, он делегировал непрерывность, не сохранив подотчётность.

Долговременный урок

Запись ICANN о смене корневого KSK 2016–2018 годов — сильный пример операционной подотчётности, потому что содержит неудобную середину: план, предупреждающий сигнал, задержку, публичные комментарии, пересмотренный план, одобрение Правления, выполнение, мониторинг и обзор. История не в том, что «ICANN сменила ключ, и ничего не произошло». История в том, что ICANN и сообщество DNS отнеслись к смене ключа как к глобальному операционному риску и сделали риск достаточно видимым для управления.

Смена прошла успешно без значительного устойчивого влияния на конечных пользователей, согласно публичному постсобытийному заявлению ICANN. Этот успех следует приписать распределённой подготовке в той же мере, что и центральной координации. ICANN контролировала процесс корневого KSK и решение. Verisign и другие корневые операторы внесли операционные наблюдения. Поставщики и операторы резолверов заставили проверку работать в полевых условиях. Владельцы публичных и частных сетей несли ответственность за собственную непрерывность.

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

Первая смена корневого KSK DNSSEC не доказала, что будущие криптографические изменения корня безрисковы. Она доказала, что изменения общей инфраструктуры можно проводить ответственно, когда полномочия сочетаются с данными, а техническая уверенность остаётся достаточно скромной, чтобы остановить календарь. Это стандарт подотчётности, которому должна соответствовать следующая смена.