1.2.Обзор

Данный документ описывает основные процедуры и меры принятые для внедрения DNSSEC в ДВУ .ДЕТИ (XN--D1ACJ3B).

1.3.Название документа и его назначение

Политика DNSSEC ДВУ .ДЕТИ. Данный документ описывает процедуры и меры принятые для внедрения DNSSEC в  ДВУ .ДЕТИ (XN--D1ACJ3B).

1.4.Сообщество и применимость

1.4.1.  Регистратура

Регистратура ДВУ обладает полномочиями по выработке Правил регистрации доменных имен в ДВУ, в том числе выработку политики DNSSEC, управляет KSK, а также отвечает за аккредитацию Регистраторов.

Регистратура использует Оператора услуг реестра как внешнего субподрядчика для технической эксплуатации Реестра. Оператор услуг реестра отвечает за: функционирование Реестра и Систему регистрации в ДВУ; проверку и обработку данных DNSSEC, полученных от Регистратора; формирование и подписание ресурсных записей в файле ДВУ; управление  ZSK и распространение ДВУ по надлежащим серверам DNS.

В качестве Оператора услуг реестра в ДВУ .ДЕТИ выступает ЗАО «Технический Центр Интернет» (ТЦИ) (http://www.tcinet.ru).

1.4.2.  Регистратор

Регистратор – юридическое лицо, заключившее соглашение с Регистратурой ДВУ. Осуществляет регистрационные действия в Реестре от имени Регистранта.

Регистратор несёт ответственность за проверку принадлежности ключа KSK Регистранту.

1.4.3.  Регистрант

Регистрант – лицо, заключившее договор о регистрации доменного имени с Регистратором и осуществляющее администрирование данного домена.

Регистранты доменных имен, размещенных в ДВУ, вносят необходимые изменения с помощью Регистраторов и несут ответственность за правильность подписи своей доменной зоны, а также за актуальность размещенных в Реестре открытых ключей в виде DS-записей в соответствии со своими потребностями.

1.4.4.  Заинтересованные стороны

Заинтересованные стороны – участники сети Интернет, которые полагаются на работу DNSSEC, например, валидирующие DNS-серверы.

Заинтересованные стороны несут ответственность за настройку и обновление надлежащих доверенных открытых ключей на своем оборудовании.

1.4.5.  Применимость

Данная политика DNSSEC применяется к ДВУ XN--D1ACJ3B (ДЕТИ). Применение DNSSEC в субординатных доменах выходит за рамки данного документа и описывается Регистрантами этих доменов.

1.5.Управление документом

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

1.5.1.  Организация, осуществляющая контроль над документом

Фонд поддержки сетевых инициатив «Разумный Интернет».

1.5.2.  Контактная информация

Фонд поддержки сетевых инициатив «Разумный Интернет»

Адрес: 123242, Москва, Ул. Зоологическая д.8;

Телефон:  +7 (499) 766-74-20.

Сайт: http://www.dotdeti.ru/

E-mail: info@dotdeti.ru

1.5.3.  Процедуры изменения документа

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

2.   Публикация открытых ключей и репозитарии

2.1.Репозитарии

Регистратура публикует информацию, относящуюся к функционированию DNSSEC в ДВУ, на своем официальном сайте в соответствующем разделе, доступном по адресу: [http://dotdeti.ru/docs/dnssec/]

Электронная версия Политики DNSSEC ДВУ XN--D1ACJ3B (ДЕТИ) , находящаяся по приведенной выше ссылке, является официальной версией этого документа.

2.2.Публикация ключа для подписи ключей

Оператор услуг реестра составляет цепочку доверия DNSSEC, публикуя открытый KSK в форме DS-записи непосредственно в корневой зоне DNS.

 

3.   Эксплуатационные требования

3.1.Значение термина «доменные имена»

Доменное имя представляет собой уникальный идентификатор (последовательность символов), которым обозначается область (ветвь) иерархического пространства доменных имен в сети Интернет.

Домены второго уровня в ДВУ .ДЕТИ регистрируются в соответствии с Правилами регистрации доменных имен в ДВУ .ДЕТИ [http://dotdeti.ru/docs/rules/].

3.2.Активация DNSSEC для субординатного домена

Для активации DNSSEC в субординатном домене необходимо разместить хотя бы одну DNSKEY запись и соответствующую ей DS запись в реестре ДВУ. Оператор услуг реестра проверяет данные на корректность, выполняя следующие тесты: проверка поддержки Реестром алгоритма, по которому сформирована DS-запись; проверка подписи; проверка тега ключа.

Если субординатный  домен делегирован и проверка DS-записи прошла успешно, то DS-запись для данного домена будет опубликована в DNS. Опубликованная DS-запись устанавливает цепочку доверия к субординатному домену.

3.3.Идентификация и аутентификация Регистранта

Надежная идентификация и аутентификация Регистранта субординатного домена входит в обязанности Регистратора, с помощью подходящих для этого способов.

3.4.Регистрация DS-записей

Оператор услуг реестра принимает DNSKEY-записи и соответствующие им DS-записи от Регистраторов, используя EPP-интерфейс. DS и DNSKEY записи должны быть корректными и должны отправляться в формате, описанном в стандарте RFC 4310. Реестр поддерживает размещение DS-записей, сформированных в соответствии с  RFC 4034 и RFC 5933.

3.5.Способ определения владельца закрытого ключа

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

3.6.Удаление DS-записей

3.6.1.  Кто может запросить удаление

Только Регистрант субординатного домена или сторона, официально уполномоченная представлять интересы Регистранта субординатного домена, могут при помощи Регистратора отправить запрос на удаление DS-записи для этого домена.

3.6.2.  Процедура запроса на удаление

Оператор услуг реестра удаляет из Реестра DNSKEY-запись и соответствующую ей DS-запись при получении от Регистратора соответствующего запроса через EPP-интерфейс. Удаление всех DNSKEY-записей и соответствующих им DS-записей для субординатного домена деактивирует DNSSEC для этого домена.

3.6.3.  Процедура запроса на удаление при аварийных ситуациях

Не указано

4.   Средства управления и эксплуатационный контроль

4.1.Физические средства управления

4.1.1.  Площадка проведения процедур и её конфигурация

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

4.1.2.  Физический доступ

К объектам Оператор услуг реестра организован ограниченный доступ, который предоставляется только уполномоченному персоналу.

4.1.3.  Электропитание и кондиционирование воздуха

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

4.1.4.  Подверженность затоплению

Оператор услуг реестра предприняты меры предосторожности для минимизации влияния водного воздействия на оборудование.

4.1.5.  Пожарная безопасность

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

4.1.6.  Хранение информации

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

4.1.7.  Уничтожение информации

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

4.1.8.  Резервная копия

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

4.2.Процедурные средства управления

4.2.1.  Доверенные роли

Для работы с закрытым KSK созданы две доверенные роли: «крипто-офицер» и «крипто-оператор»

Для работы с ZSK создана доверенная роль «Администратор Доменной Зоны»

Для контроля над ходом выполнения ключевых процедур создана роль «Наблюдатель»

4.2.2.  Необходимое число допущенных лиц для выполнения задачи

Доверенные роли: «крипто-офицер» и «крипто-оператор», каждая из которых состоит минимум из двух допущенных лиц. Для работы с закрытым KSK необходимо наличие минимум двух крипто-офицеров и одного крипто-оператора.

Доверенная роль «администратор доменной зоны» состоит минимум из двух допущенных лиц. Для контроля и управления ключами ZSK в полуавтоматическом режиме необходимо хотя бы одно допущенное лицо.

Доверенная роль «Наблюдатель» состоит минимум из двух допущенных лиц. Наблюдатели обеспечивают прозрачность процесса и тщательное соблюдение процедур при выполнении критически важных операций с закрытым KSK.

4.2.3.  Идентификация и аутентификация для каждой роли

Доверенные роли: «крипто-офицер» и «крипто-оператор»: каждое из допущенных лиц имеет персональный идентификатор и пароль к нему для работы с закрытым KSK.

Доверенная роль «администратор доменной зоны»: каждое из допущенных лиц имеет персональный логин и пароль к интерфейсу управления DNSSEC

4.2.4.  Задачи, требующие разделения обязанностей

Сотрудник, привлеченный к работе с закрытым KSK, не может одновременно совмещать роли крипто-офицера и крипто-оператора.

4.3.Средства управления персоналом

4.3.1.  Квалификация и опыт

Выше описанный персонал является сотрудниками Оператор услуг реестра, либо лицами, специально утвержденными Регистратурой на роль «крипто-офицера». Персонал, участвующий в процедурах, должен иметь опыт в области применения DNSSEC.

4.3.2.  Процедура проверки данных

Все сотрудники, вовлеченные в работы по поддержке ДВУ .ДЕТИ, должны быть ознакомлены с требованиями по безопасности. Требования по безопасности также должны быть включены в должностные инструкции сотрудников. Сотрудники должны подписывать соглашение о конфиденциальности (неразглашении).

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

1.     положительные рекомендации, в особенности в отношении деловых и личных качеств кандидата;

2.     проверка резюме кандидата на предмет полноты и точности, с подтверждением основного образования и профессиональных навыков;

3.     независимая проверка подлинности удостоверяющих личность документов (паспорта или его эквивалента).

4.3.3.  Требования к подготовке

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

Оператор услуг реестра периодически инструктирует и проверяет готовность персонала к проведению процедур и осуществляет переподготовку по мере необходимости.

4.3.4.  Частота и порядок ротации сотрудников

Не указано

4.3.5.  Ответственность за неправомочные действия

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

4.3.6.  Требования к кандидатам при заключении трудового договора.

Не указано

4.3.7.  Документация

Документация, описывающая порядок выполнения процедур, доступна для всех вовлеченных сотрудников.

4.4.Аудит процедур журналирования

4.4.1.  Типы событий, подлежащих документированию

Автоматически должны журналироваться события следующих типов:

·      Удачные и неудачные попытки доступа по пользовательскому логину, выполнение привилегированных операций.

·      События, имеющие отношение к доступу к HSM (Hardware Secure Module – Аппаратный модуль защиты, см. ниже), вводу в эксплуатацию, целостности системы, генерированию ключей, активации ключей, подписанию и экспортированию ключей.

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

·      Доступ персонала в выделенные охраняемые зоны.

4.4.2.  Частота проверки журнала

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

4.4.3.  Срок хранения данных, подлежащих аудиту

Журналы должны храниться в информационной системе и в системе документооборота Оператора услуг реестра в течение по крайней мере одного месяца. После этого информация журналов архивируется на срок до трех лет.

4.4.4.  Защита журналов аудита

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

4.4.5.  Процедуры резервного копирования журналов, подлежащих аудиту

Копии журналов в электронном и бумажном виде необходимо по крайней мере один раз в месяц посылать в хранилище, находящееся на отдаленном резервном объекте.

4.4.6.  Система сбора данных, подлежащих аудиту

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

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

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

4.4.7.  Оценка уязвимости

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

4.5.Компрометация и восстановление после сбоя

4.5.1.  Оперативные процедуры при происшествиях и компрометации

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

4.5.2.    Выход из строя вычислительных мощностей, программного обеспечения и/или хранилищ данных

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

Копия закрытой части KSK храниться  в зашифрованном виде в безопасном месте на отдаленном резервном сервере.

4.5.3.  Процедуры реагирования на компрометацию закрытой части ключа

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

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

4.5.4.  Непрерывность деятельности Оператора услуг реестра и возможности для восстановления после сбоя в функционировании ИТ

 Оператора услуг реестра использует процедуры резервного копирования и восстановления данных в соответствии с планом по восстановлению после сбоя (DRP, Disaster Recovery Plan) и планом по обеспечению непрерывности деятельности (BCP, Business Continuity Plan). DRP предусматривает географически распределенное расположение систем резервного хранения. BCP предусматривает наличие возможности возобновления предоставления услуг на отдаленном резервном объекте.

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

4.6.Прекращение деятельности

Если работа Оператора услуг реестра прекращается в какой-либо момент, то он должен поставить в известность заинтересованные стороны и передать свои обязательства и записи организации-преемнику безопасным и прозрачным образом, в соответствии с Планом Миграции Реестра ДВУ .ДЕТИ.

 

 

5.   Технические средства безопасности

5.1.Генерация ключей и их внедрение

5.1.1.  Генерация ключей

Создаваемые ключи KSK генерируются и хранятся в специализированном устройстве, называемом HSM (Hardware Secure Module – Аппаратный модуль защиты), у которого отсутствует подключение к сетевой инфраструктуре. Все операции с использованием криптографических преобразований, требующие участия закрытого KSK, выполняются на этом устройстве или на идентичном ему, которое используется в качестве резервного. Для обеспечения безопасности закрытый KSK может покидать устройство только в зашифрованном виде.

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

5.1.2.  Распространение открытого ключа

Открытый KSK распространяется среди заинтересованных сторон  средствами протокола DNS.

5.1.3.  Параметры генерации открытого ключа и проверка качества

Задание параметров и проверка качества ключевой информации осуществляется Оператора услуг реестра.

5.1.4.  Применение ключа

Оператора услуг реестра использует ключевую информацию исключительно для подписи зоны ДВУ.

5.2.Средства защиты закрытого ключа

5.2.1.  Стандарты и элементы управления криптографическими модулями

Аппаратный модуль защиты представляет собой неспециализированное компьютерное устройство, в котором используется сертифицированная ФСТЭК операционная система, аппаратный генератор случайных чисел в качестве источника энтропии и электронный замок, сертифицированный ФСТЭК, который способен производить мониторинг целостности окружения ПО.

5.2.2.  Контроль использования закрытого ключа несколькими сотрудниками

Операции, требующие закрытой части KSK, выполняются крипто-офицерами и крипто-операторами в порядке, определённом в разделе 4.2. «Процедурные средства управления». Персональный идентификатор крипто-офицера содержит часть парольной фразы, необходимой для получения доступа к защищённому диску на HSM. Для восстановления пароля достаточно участия крипто-офицеров в количестве m<n, где n – общее количество частей парольной фразы (крипто-офицеров).

5.2.3.  Депонирование закрытой части ключа

Оператор услуг реестра не производит депонирования закрытых частей ключей.

5.2.4.  Резервное копирование закрытого ключа

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

Резервная копия закрытого ZSK хранится на резервном сервере подписания с горячим подключением, расположенном на резервной площадке, и включается в каждую резервную копию базы данных Реестра.

5.2.5.  Хранение закрытой части ключа в криптографическом модуле

Закрытые части ключей KSK хранятся в зашифрованном виде в криптографическом модуле, описанном выше.

5.2.6.   Архивация закрытого ключа

Выведенные из использования закрытые ключи хранятся исключительно в виде резервных копий.

5.2.7.  Перемещение закрытого ключа

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

5.2.8.  Способ активации закрытого ключа

Доступ к закрытому KSK открывается после открытия доступа к HSM и после дешифрования защищённого диска. Крипто-оператор обеспечивает доступ крипто-офицеров к консоли HSM. Крипто-офицеры используют персональные идентификаторы для дешифрования защищённого диска.

Доступ к закрытому ZSK обеспечивается Администратором Доменной Зоны из интерфейса управления DNSSEC.

5.2.9.   Способ деактивации закрытого ключа

Доступ к закрытому KSK прекращается автоматически немедленно после проведения операции подписания.

Закрытый ключ ZSK хранится в онлайновой части системы DNSSEC и находится  активном состоянии пока у этого ключа статус "Active". Изменение статуса ZSK может быть выполнено из интерфейса управления DNSSEC Администратором Доменной Зоны.

5.2.10.   Способ уничтожения закрытого ключа

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

5.3.Примечания к управлению ключами

5.3.1.  Резервное копирование открытых ключей

Открытые ключи подвергаются резервному копированию при проведении плановых процедур резервного копирования на устройствах.

5.3.2.  Сроки использования ключей

Срок действия KSK устанавливается на 13 (тринадцать) месяцев, ZSK – 3 (три) месяца. Оператор услуг реестра при необходимости может изменить данные сроки. Устаревшие ключи не используются повторно.

5.4.Данные для активации

5.4.1.  Генерация данных для активации и их внедрение

Данные для доступа к KSK представляют собой набор паролей к персональным идентификаторам крипто-офицеров и паролей к персональным идентификаторам крипто-операторов (PIN-коды).

5.4.2.  Защита данных для активации

Крипто-офицеры и крипто-операторы обеспечивают сохранность данных для доступа в соответствии с рекомендациями по безопасности.

5.4.3.  Примечания по работе с данными для активации

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

5.5.Средства управления компьютерной безопасностью

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

5.6.Средства управления сетевой безопасностью

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

Содержащая KSK часть системы подписания не имеет сетевого подключения. Передача запроса на подписание ключевого набора (KSR) осуществляется через съёмный носитель.

5.7.Метки времени

Онлайновая часть системы подписания осуществляет синхронизацию времени с доверенным источником во внутренней сети. Установка времени в офлайновой части системы DNSSEC осуществляется вручную при каждом включении HSM.

5.8.Средства управления жизненным циклом

5.8.1.  Системные средства управления разработкой

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

5.8.2.  Средства управления безопасностью

Оператора услуг реестра проводит периодический аудит безопасности.

5.8.3.  Средства управления безопасностью жизненного цикла

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