Объявление о начале приема заявлений от организаций-претендентов, которые желают стать Оператором реестра домена .УКР

Согласно Временной Концепции внедрения и развития домена .УКР, утвержденной 16 августа 2013 года, Администратор должен предоставить Координационному совету УСИЦ предложения об утверждении Оператора реестра домена .УКР из нескольких предложений.
Также, согласно требованиям той же Концепции, техническая инфраструктура домена .УКР должна соответствовать требованиям, устанавливаемым соответствующими техническими документами ICANN на предмет её  устойчивой работы, хранения данных, обрабатываемых элементами этой инфраструктуры, защиты от несанкционированного доступа.
Осознавая, что до начала аккредитации Регистраторов доменных имен в домене .УКР и к началу третьего этапа приоритетной регистрации доменных имен должен быть определен Оператор реестра домена .УКР,  с которым Регистраторы будут заключать договоры, а также согласно своим полномочиям, Администратором 13 сентября 2013 года утвержден документ «Требования к оператору реестра домена .УКР».
В соответствии с Требованиями к оператору реестра домена .УКР,  Администратор объявляет о начале приема заявлений от организаций-претендентов, желающих стать Оператором реестра домена .УКР .
Заявления принимаются до 12 октября 2013 до 18:00 включительно. Заявления должны направляться Администратору (ОП УСИЦ) по адресу: 04053, г.Киев, а / я 45.

 Текст Требований в формате. pdf можно найти  здесь  (на украинском языке).

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

Текст Требований:

УТВЕРЖДЕНО
Директор ОП УСИЦ
Администратор домена .УКР_______________ Ю. Гончарук
«13» сентября 2013

Требования к Оператору реестра домена .УКР

г. Киев
2013

1. Общие положения.
1.1. Цель этого документа – определить организационные, технические (технологические), и квалификационные требования к организации-претендента, желающего стать Оператором реестра домена .УКР (далее – претенденты), обязан обеспечить разработку, внедрение и постоянное и бесперебойное обслуживание системы регистраций доменных имен в домене .УКР, функционирования системы доменных имен, других обязательных подсистем (далее вместе – Система), включая:
1) все публично доступные службы, связанные с процессами обслуживания реестра домена .УКР;
2) подсистемы, отвечает за документарное и электронное сопровождение транзакций, осуществляемых на всех этапах жизненного цикла доменных имен, а также внутренних транзакций при сопровождении реестра домена .УКР.
1.2. В этом документе будут определяться минимальные параметры архитектуры технической базы Оператора реестра и базовые организационные процедуры, которые Оператор реестра обязан будет выполнять при взаимодействии с администрацией домена .УКР (далее – Администратором), Регистраторами, Комиссией по досудебному разрешения доменных споров (далее – Комиссией по спорам) в соответствии с Правилами регистраций и пользования доменными именами в домене .УКР (далее – Правил), которые одобряются Координационным советом. Оператор реестра также будет обязан разработать и соблюдать требования, которые будут определяться в Техническом регламенте, который будет утверждаться администрацией.
1.3. Предложения по усилению значений технических и других параметров системы, которые могут улучшить ее свойства и возможности обслуживания реестра домена .УКР, а также предложения по совершенствованию организационных процедур взаимодействия и партнерства с администрацией, Регистраторами, Комиссией по спорам и т.д. будут считаться дополнительными преимуществами для Претендента.
1.4. Претендент подает к Администратору заявление о своем намерении стать Оператором реестра домена .УКР течение 30 дней со дня размещения на сайте Администратора объявления о приеме соответствующих предложений по осуществлению функций Оператора реестра домена .УКР.
Заявление Претендента и приложения к ней должны содержать:
1) заверенные надлежащим образом копии учредительных документов и соответствующего решения учредителей / участников о намерении осуществлять исключительную основе деятельность как Оператора реестра домена .УКР;
2) сведения о соответствии Претендента установленным требованиям, определяемых в этом документе (требованиях к оператору реестра домена .УКР) и в документах , соблюдение которых является обязательным для выполнения обязанностей Оператора реестра домена .УКР;
3) сведения о существующем опыт Претендента и его возможности, включая общее описание технических систем, владельцем которых является Претендент, организационных возможностей и квалификации персонала по выполнению обязательств оператора реестра домена .УКР;
4) эскизный проект системы с описанием и архитектурой каждой из подсистем, относительно которых устанавливаются требования в этом документе, документах ICANN и в соответствующих стандартах Интернет;
5) соответствующее эскизному проекту техническое задание на разработку и внедрение Системы;
6) техническое задание на разработку и внедрение комплексной системы защиты информации в реестре домена .УКР и соответствующие должностные инструкции;
7) документ «Описание API EPP»;
8) план по восстановлению работоспособности Системы и / или подсистем в случае возникновения внештатных ситуаций (катастроф, аварий и т.п. ) и соответствующие должностные инструкции;
9) план-график действий, предусмотренных подпунктами 6) и 7) пункта 1.5 этого документа, в случае, если такие действия являются необходимыми.
1.5. Претендент, на момент подачи заявления о своем желании стать Оператором реестра, должен отвечать следующим требованиям:
1) быть юридическим лицом, созданная и зарегистрированная согласно законодательству Украины не менее чем за 2 года до подачи заявления в соответствии с пунктом 1.4;
2) не иметь в своем уставном капитале доли или голосов для управления, принадлежащего иностранной компании или лицу, действующему в интересах иностранного лица, в размере более 10%;
3) не быть государственным или коммунальным предприятием или таким, в уставном капитале которого доля, принадлежащая государству, превышает 50%;
4) иметь развернутый и работающий программно-аппаратный комплекс с программным обеспечением для обслуживания реестра домена .УКР, в том числе поддержки серверов доменных имен (DNS) с промышленным способом дистрибуции файла зоны, службу WHOIS со стандартным и веб -интерфейсом, поддержку протокола EPP (Extensible Provisioning Protocol), который предназначен для управления регистрационной информации, иметь встроенный программный интерфейс и иметь веб-интерфейс для Регистраторов;
5) отвечать требованиям ICANN, предъявляемые к операторам реестров доменов верхнего уровня, типа ccTLD / gTLD, что может быть подтверждено информацией от ICANN,
6) или быть ICANN-аккредитованным регистратором в gTLD, производственный комплекс которого может быть организационно, технически и квалификационно отделен от деятельности по регистрации доменных имен в gTLD и приведен в соответствие с требованиями к оператору реестра ccTLD, а также с требованиями к Оператору реестра домена .УКР, изложенные в этом документе, в срок не более 2-х месяцев,
7) или быть фактически действующим оператором реестра другого домена верхнего уровня ccTLD, производственный комплекс которого может быть технически и квалификационно отделен от деятельности по регистрации доменных имен в другом ccTLD и приведен в соответствие с требованиями к Оператору реестра домена .УКР, изложенные в этом документе, в срок не более 2-х месяцев;
8) иметь не менее 5 (пять) технологических площадок (групп логически связанных серверов и сетевого оборудования, которые подключены несколькими каналами в Интернет и обеспечены бесперебойным электропитанием) и которые уже функционируют в рабочем режиме, из которых не менее одного должен находиться за пределами Украины и не менее двух должны находиться в Украине. Все технологические площадки (комплексы) должны базироваться на собственных аппаратных ресурсах Претендента;
9) иметь не менее 3 (трех) блоки IPv4-адресов минимально / 24 в различных сетях класса С;
10) не менее 1 (один) из блоков IP-адресов, указанных в подпункте 9) должен также иметь поддержку (адресацию) IPv6.
1.6. Для проверки соответствия определенным требованиям Претендент вместе с заявлением и приложениями к ней передает Администратору коды доступа к каждому из серверов и другого оборудования, которые должны быть задействованы в обслуживании реестра домена .УКР и всех его подсистем, на бумажном и электронном носителе.
1.7. На момент подачи заявления Претендент должен иметь разработанные и документированные процедуры, в соответствии с которыми он, как возможный Оператор реестра, обязан с соблюдением требований законодательства Украины осуществлять следующее:
1) придерживаться соответствующих применимых стандартов, рекомендаций и положений документов ICANN по имплементации IDN ccTLD, Правил регистрации и использования доменных имен в домене .УКР, Технического регламента, Положение (порядка) решения доменных споров, а также условий договоров с администрацией, Регистраторами, Комиссией по досудебному разрешению споров.
Под соответствующими применимыми стандартами понимаются стандарты RFC «standards – track» или «best current practice», внедрены Группой инженерных проблем Интернета (IETF)
2) поддерживать файл зоны домена .УКР/.xn--j1amh в актуальном состоянии – создание регулярных обновлений данных в файле зоны должно осуществляться согласно соответствующим стандартам, как определено подпунктом 1)
3) обеспечивать работу службы доменных имен домена .УКР/.xn--j1amh – обеспечение стабильной работы всех авторитативным серверов доменных имен домена .УКР, обеспечение возможности получения адресации в домене .УКР всеми пользователями Интернет согласно действующих стандартов;
4) поддерживать точность, актуальность и полноту информации, относится к любым изменениям регистрационных и / или служебных данных по назначенным административных, технических, финансовых контактах Оператора реестра и Регистраторов. Изменения любых контактных и коммуникативных данных Оператора реестра должны доводиться до Администратора течение 1 часа с момента изменения таких данных;
2. Технические требования.
Претендент должен представить решения, которые обеспечивают безотказную и непрерывную работу всех подсистем и элементов реестра домена .УКР и Системы в целом.
Для обеспечения безотказности работы Системы в случаях сбоев в работе основных серверов и другого оборудования, задействованных в постоянном режиме работы подсистем DNS и / или WHOIS, баз данных, все серверы и другое оборудование должны синхронизироваться в реальном времени с серверами и другим оборудованием, работающих в режиме «горячего» резерва.
Возникновение нештатной ситуации в ходе работы любой подсистемы не должно останавливать работу других подсистем.Продление подсистем должно происходить с набором данных, который был актуален перед сбоем. После восстановления работоспособности подсистемы, выходила из строя, и ее соединения с другими подсистемами, данные, задействованных из резерва для восстановления работы подсистемы, актуализируются для всех подсистем.
Восстановление работоспособности любой подсистемы после возникновения внештатной ситуации должно происходить не более, чем за 24 часа.
Претендент должен представить решение по обеспечению требований к безопасности и устойчивой работоспособности следующих элементов Системы:
1) узлов сети (серверов, рабочих станций на базе ПК, ноутбуков, планшетов, смартфонов (софтфонов) и т.д.), операционных систем и приложений, хранилищ баз данных;
2) сетевых устройств и оборудования (маршрутизаторов, коммутаторов, межсетевых экранов, канального оборудования и т.д.);
передачи данных между подсистемами реестра и / или внешней сети.
Решения по безопасности доступа к подсистемам реестра должны быть построены на основе PKI (Public Key Infrastructure).
Администратор осуществлять автоматизированную проверку параметров и элементов системы и оставляет за собой право не разглашать количество и места расположения специальных мониторинговых программ (мониторов), которые на основе определенных алгоритмов осуществлять проверку доступности, работоспособности сетевых сервисов и служб. Претендент и в дальнейшем Оператор реестра обязаны устанавливать и устанавливать такие мониторы, их параметры и настройки по требованию Администратора в тех элементах подсистем, оборудовании, ОС которые будут определены администрацией на основе данных, которые будут подаваться в заявлении.
2.1. Требования к параметрам Системы и к телекоммуникационной сети.
Претендент должен представить:
1) схему реализации Системы с указанием технических параметров серверов, их статуса и функциональных задач, мест расположения;
2) схему работы Системы в случаях внештатных ситуаций с указанием технических параметров серверов, их статуса и функциональных задач, мест расположения, которые являются иными;
3) схему реализации телекоммуникационной сети с указанием функциональных и технических параметров узлов сети, их статуса и мест расположения.
Доступ к каждому сетевого узла должен обеспечиваться через минимум через двух операторов / провайдеров телекоммуникаций (Интернет) при отсутствии предварительного фильтрования сетевых пакетов и сервисов.
Претендент должен представить свое решение и проектные параметры частности для следующих характеристик Системы:
1) транзакционность – обеспечение целостности данных и предотвращения конфликтов несоответствия во время работы нескольких пользователей через программные приложения с одним и тем же набором ( массивом) данных и одновременной обработки этих данных внутри системы;
2) масштабируемость – возможность увеличить производительность системы за счет увеличения количества серверных компонент или увеличение вычислительной мощности отдельных компонент. Процесс такого увеличения производительности не должен приводить к росту простоя системы для ее совершенствования;
3) многократное резервирование узлов и компонентов системы – исключение возможности потери или искажения данных и минимизация времени на восстановление полной работоспособности подсистем в случаях выхода из строя оборудования и возникновения других непредвиденных обстоятельств;
4) наличие инструментов самодиагностики и внешней диагностики ключевых компонентов системы – пригодность системы самостоятельно определять проблемы с каким-либо компонентом путем вызова и обработки специального набора тестовых заданий, выполняемых по каждой из подсистем;
5) соответствие протоколов и схем взаимодействия международным стандартам и стандартам Интернет ;
6) защищенность от внешних несанкционированных вмешательств – реализация системой политик безопасности, предоставляющих максимальную защиту от атак, вмешательств, несанкционированного доступа к данным и т.д..
Безопасность оборудования, которое будет использоваться Претендентом в системе и телекоммуникационной сети должна быть подтверждена соответствующими сертификатами соответствия.
2.2. Подсистема регистраций.
2.2.1. Принципы работы подсистемы регистрации и ее доступность.
Подсистема регистраций доменных имен и осуществления надлежащих операций с доменными именами должна обеспечивать взаимодействие с технологическими автоматизированными комплексами Регистраторов по протоколу EPP (Extensible Provisioning Protocol).
Количество Front-end серверов подсистемы регистраций должно быть не менее 3 (трех ). Эти серверы должны быть расположены как минимум в 2 (двух) независимых датацентрах. Минимум 2 (два) серверы должны находиться в режиме Stand-by.
Претендент должен предложить и обосновать оптимальный, по его мнению, метод который будет использоваться для передачи данных и транспортный сетевой протокол.
Подсистема регистраций должна:
1) основываться на уже проверенных на практике Претендентом процессах управления регистрациями (транзакциями)
2) обеспечивать автоматическую обработку всех транзакций;
3) обеспечивать авторизацию Регистраторов и подлинности операций, осуществляемых в системе.
Претендент должен представить решение относительно автоматической обработки всех транзакций.
Подсистема регистраций должна обеспечивать и поддерживать весь жизненный цикл доменного имени (домена ), которые будут определяться в (проекте) Правилах регистраций и пользования доменными именами в домене .УКР и соответствующем Техническом регламенте.
Доступность службы EPP – способность совокупности EPP-серверов домена .УКР выполнять удачную обработку запросов через корректные EPP-команды от аккредитованных Регистраторов, которые имеют надлежащие учетные записи для доступа к EPP-серверов реестра. Ответ должен включать соответствующие сведения из Системы в соответствии с описанием работы EPP-команд. Действие в отношении ожидания ответа на запрос EPP, при которой значение показателя параметра сервиса в пять раз превышает соответствующее необходимое значение, считается завершившейся неудачно. Если в 51% или более при проверке мониторами такие действия были неудачными, такая служба EPP считается недоступной в течение определенного времени.
Минимальные значения параметров, которые должны быть обеспечены в подсистеме регистраций:
Параметр SLR (ежемесячно)
Доступность службы EPP = <время простоя 864 мин . (Не менее 98%)
RTT команды управления сессией = RTT команды на получение информации = RTT команды на изменение информации =

2.2.2. Безопасность в подсистеме регистраций.
Кроме требований по разработке и последующего внедрения комплексной системы защиты информации в соответствии с требованиями законодательства и упомянутых в пункте 1.4 этих Требований, в частности основные серверы подсистемы регистраций Претендента, которые будут иметь статус Master, должны предоставлять всем подчиненным серверам возможность актуализации, обработки и хранения данных о текущих регистрациях, но при этом не должны быть доступны извне и иметь статус Hidden Back-End.
Подсистема регистраций должна обеспечивать защищенную обработку всех транзакций. Претендент должен представить решение относительно защищенной обработки всех транзакций.
Подсистема регистраций должна обеспечивать безотказную (бесперебойную) работу и способность восстановления актуальных данных в случае возникновения нештатных и непредвиденных ситуаций. Претендент должен представить решение по обеспечению безотказной (бесперебойной) работы и способности восстановления актуальных данных в случае возникновения нештатных и непредвиденных ситуаций.
2.2.3. Набор инструментов по разработке программного обеспечения EPP.
На момент подачи заявления Претендент должен иметь документ «Описание API EPP», которым будут определяться возможности по разработке и инструкции по встраиванию программного обеспечения и его элементов в программные комплексы Регистраторов, для обеспечения автоматизированного процесса взаимодействия программных комплексов Регистраторов с реестром домена .УКР.
2.2.4. Другие требования к EPP.
Реализация протокола EPP, что будет предлагаться Претендентом, должна обеспечить на уровне «клиент-сервер» такую ​​возможность управления данными и объектами, хранящимися в репозитории (реестре), которая будет поддерживать обработку информации с кодировкой как UTF-8 так и PUNYCODE.
2.3. Подсистема DNS.
2.3.1. Принципы работы подсистемы DNS и ее доступность
Доступность службы DNS – способность группы серверов доменных имен, которые определены как полномочные серверы DNS для домена .УКР, отвечать на запросы (в основном это запросы типа nslookup) других серверов и клиентов DNS или запросы от специальных мониторов по адресации и другой служебной информации доменных имен. Для того, чтобы служба DNS считалась доступной в конкретный момент времени, по крайней мере для двух полномочных серверов доменных имен, должны быть получены успешные результаты DNS-проверок. Если в 51% или более случаев DNS-проверок служба недоступна в течение определенного времени, такая служба DNS считается недоступной.
Доступность сервера имен DNS – способность отдельного DNS сервера отвечать на запросы других DNS-серверов и клиентов в форме определенной Интернет-стандартами.
Все зарегистрированные в уполномоченной службе DNS высшего уровня IP-адреса всех серверов доменных имен, контролируемых должны проходить проверку в индивидуальном порядке. Если в 51% или более случаев DNS проверок для определенных серверов в течение заданного времени получаемые ответы типа «undefined / unanswered» (не определено / без ответа), такой сервер имен считается недоступным.
Минимальные значения параметров, которые должны быть обеспечены в подсистеме DNS:
Параметр SLR (ежемесячно)
Доступность службы DNS Время простоя 0 мин. = 100% доступность
Доступность сервера имен DNS = <Время простоя 432 мин. (Не менее 99%)
RTT для DNS / TCP = RTT для DNS / UDP = Время обновления DNS =

2.3.2. Надежность работы групп серверов в подсистеме DNS.
Надежность работы групп серверов в подсистеме DNS должна быть 100%.
Претендент должен предусмотреть в решениях, которым представляются, возможность защиты данных от модификации, искажению и дискредитации их в процессе передачи этих данных от DNS-серверов в клиентов. Также, должны быть представлены средства предотвращения создания ложных DNS-серверов, которые будут предоставлять недостоверные данные (ответы).
2.3.3. Обслуживание файла зоны.
Программное обеспечение в системе, что представляться Претендентом, должно обеспечивать динамическое обновления файла зоны.
Претендент должен представить в надлежащем решении технические параметры, необходимые для текущего обслуживания, архивирования и депонирования файла зоны домена .УКР/xn--j1amh.
Сохранение дампа (архива) файла зоны должно проводиться ежедневно на отдельные земни носители информации, включая такие, которые не перезаписываются.
При возникновении внештатной (непредсказуемой) ситуации по работоспособности Системы, восстановления базы данных и файла зоны должно осуществляться по отдельным земних носителей информации на дисковые массивы серверов , задействованных в обеспечении работы Системы и являются резервными и находятся в состоянии «горячей замены» («горячего резерва»).
2.3.4. Требования к DNS-серверам.
Подсистема DNS-серверов в составе решения Претендента должна состоять не менее 13 серверов, расположенных минимум в 5 (пяти) разных датацентрах. Как минимум 5 (пять) серверов должны находиться в состоянии «горячей замены» («горячего резерва»), из которых минимум 3 (три) должны быть в состоянии Stand-by.
Минимальная конфигурация серверов: Quad Core CPU, 16GB DDR3 ECC, 2 -4 HDD (SAS / SATA / SSD), Raid controller, 64-bit Unix operating system, IPMI, дублированное питание, 100% готовности «горячей замены».
2.4. Служба WHOIS
2.4.1. Принципы работы службы WHOIS и ее доступность.
Подсистема WHOIS должна поддерживать UTF-8 (Unicode) с возможностью получения и предоставления ответов запросов на украинском и русском языках, а также в ASCII.
Доступность службы WHOIS – способность всех служб WHOIS домена .УКР предоставлять по запросы пользователей Интернета соответствующие данные из реестра. Если в 51% или в более случаях проверка WHOIS специальными мониторами показывает, что какая-либо из служб WHOIS недоступна в течение определенного времени, такая служба WHOIS считается недоступной.
Минимальные значения параметров, которые должны быть обеспечены службой WHOIS:
Параметр SLR (ежемесячно)
Доступность WHOIS = <время простоя 864 мин. (Не менее 98%)
RTT WHOIS-запроса = Время обновления WHOIS =

Система WHOIS-серверов Претендента должна состоять минимум из 6 (шести) серверов, расположенных в 3 (трех) различных датацентрах. 3 (три) сервера должны находиться в состоянии «горячей замены» («горячего резерва»).
2.4.2. Формат данными в WHOIS
Набор данных в службе WHOIS должен отображать информацию на оригинальном языке регистрации доменного имени с автоматической транслитерацией в ASCII или с возможностью аутентичного перевода на английский язык в ASCII путем редактирования соответствующих полей.
2.4.3. Набор данных WHOIS
Последовательность данных, которые должны быть предоставлены в ответ на запрос, приведены в ниже приведенной таблице
Поле Значение
Domain Name (PUNYCODE): Имя домена в кодировке Punycode
Domain Name (UTF8): Имя домена в кодировке UTF8
Registry Domain ID: Идентификатор регистрации доменного имени
Registrar WHOIS Server: WHOIS-сервер Регистратора
Updated Date: Дата проведения модификации домена
Creation Date: Дата регистрации доменного имени
Expiration Date: Дата окончания действия регистрации доменного имени
Registry Status: Текущий статус, в котором находится домен
Registrar: Название Регистратора
Registrar URL: Адрес сайта Регистратора
Registrar ID: Идентификатор Регистратора
Registrar Abuse Contact Email: Адрес электронной почты Регистратора, на которую следует отправлять жалобы в отношении использования домена
Registrar Abuse Contact Phone: Телефон Регистратора, на которую следует звонить в случае возникновения жалоб относительно использования домена
Registry Registrant ID: Идентификатор регистранта
Registrant Name: Имя (Название) Регистранта
Registrant Organization: Название организации Регистранта
Registrant Street: Улица, номер дома с адреса Регистранта
Registrant City: Город с адреса Регистранта
Registrant Postal Code: Почтовый код с адреса Регистранта
Registrant Country: Страна с адреса Регистранта
Registrant Phone : Телефонный номер Регистранта
Registrant Phone Ext: Дополнительный номер офисной АТС к телефонному номеру Регистранта
Registrant Fax: Номер факса Регистранта
Registrant Fax Ext: Дополнительный номер офисной АТС к факсу Регистранта
Registrant Email: Адрес электронной почты Регистранта
Registry Admin ID: Идентификатор администратора домена
Admin Name: Имя администратора
Admin Organization: Название организации администратора
Admin Street: Улица, номер дома с адреса администратора
Admin City: Город с адреса администратора
Admin Postal Code: Почтовый код с адреса администратора
Admin Country: Страна с адреса администратора
Admin Phone: Телефонный номер администратора
Admin Phone Ext : Дополнительный номер офисной АТС к телефонной номера администратора
Admin Fax: Номер факса администратора
Admin Fax Ext: Дополнительный номер офисной АТС к факсу администратора
Admin Email: Адрес электронной почты администратора
Registry Tech ID: Идентификатор технического контакта домена
Tech Name: Имя технического контакта
Tech Organization: Название организации технического контакта
Tech Street: Улица, номер дома с адреса технического контакта
Tech City: Город с адреса технического контакта
Tech Postal Code: Почтовый код с адреса технического контакта
Tech Country: Страна с адреса технического контакта
Tech Phone: Телефонный номер технического контакта
Tech Phone Ext: Дополнительный номер офисной АТС к телефонному номеру технического контакта
Tech Fax: Номер факса технического контакта
Tech Fax Ext: Дополнительный номер офисной АТС к факсу технического контакта
Tech Email: Адрес технического контакта
Registry Bill ID: Идентификатор финансового контакта домена
Bill Name: Имя финансового контакта
Bill Organization: Название организации финансового контакта
Bill Street: Улица, номер дома с адреса финансового контакта
Bill City: Город с адреса финансового контакта
Bill Postal Code: Почтовый код с адреса финансового контакта
Bill Country: Страна с адреса финансового контакта
Bill Phone: Телефонный номер финансового контакта
Bill Phone Ext: Дополнительный номер офисной АТС к телефонному номеру финансового контакта
Bill Fax: Номер факса финансового контакта
Bill Fax Ext: Дополнительный номер офисной АТС к факсу финансового контакта
Bill Email: Адрес электронной почты финансового контакта
NS servers (Domain servers in listed order) Перечень серверов имен, которые обслуживают домен

2.5. Требования к сети.
2.5.1. Управление сетью.
Управление сетью должно происходить из одного центра в штатном режиме работы.
Управление сетью должно предусматривать возможность удаленного доступа к узлам подсистемы управления реестром (Системой) в случаях возникновения внештатных ситуаций.
Управление сетью должно происходить в режиме 7х24х365.
2.5.2. Безопасность сети.
Базовыми требованиями по обеспечению безопасности сети для Претендента следующее:
1) идентификация – которая осуществляется с целью предотвращения угроз обезличенного и несанкционированного доступа к ресурсам и данным подсистем реестра (системы). В требованиях определяется, что действия по идентификации обязательно и всегда содержат авторизацию;
2) целостность, которая обеспечивает защиту от подслушивания, сканирования и манипулирования данными, поддерживая конфиденциальность и неизменность передаваемой сетью;
3) активная проверка, означает проверку правильности применения предписаний политик безопасности и помогает выявлять несанкционированное проникновение в сеть и атаки типа DDoS. Активная проверка должна происходить в режиме on-line.
С целью обеспечения поддержки (обеспечения) безопасности сетевое оборудование на каждом узле должно осуществлять аудит сети и анализ сетевых инцидентов в режиме on-line.
Фильтрация IP-адресов определенных сетей допускается исключительно в случаях возникновения атак с этих сетей типа DDoS и т.п. узлы Системы.
Регистраторы проходить процедуру аккредитации. Претендент должен представить свое решение относительно принципов технического требования в процедуре аккредитации Регистраторов с точки зрения взаимодействия автоматизированных систем Регистраторов и безопасности сети.
Соединение автоматизированных систем Регистраторов с подсистемой регистраций в составе реестра (Системы) должно происходить исключительно с использованием протоколов защиты сетевых соединений . Каждому аккредитованном Регистратору должен быть в Системе присвоен ID и пароль (или токен). Доступ с автоматизированных систем Регистраторов к подсистеме регистраций должен быть разрешен от заранее определенных IP-адресов.Претендент должен представить свое решение о применении им защищенного доступа (в том числе сетевого) и идентификации.
2.6. Требования к обеспечению непрерывности бизнес-процессов
2.6.1. План действий по обеспечению непрерывности бизнес-процессов.
Претендент должен представить документы «План по восстановлению работоспособности Системы и / или подсистем в случае возникновения внештатных ситуаций (катастроф, аварий и т.п.) и соответствующие должностные инструкции» и «План действий по обеспечению технической поддержки непрерывности бизнес- процессов », которые должны среди прочего описывать следующее:
1) Отказоустойчивость.
2) Преодоление чрезвычайных ситуаций.
3) Резервное копирование и восстановление.
4) Поддержка критически важных бизнес-процессов.
Планы действий должны включать в себя разработку сценариев Претендента (Оператора реестра) в частности в условиях :
1) перебоев с электропитанием (включая долговременные)
2) сбоев в работе оборудования IT-системы;
3) сбоев в работе программного обеспечения (как ОС, так и прикладного и приложений);
4) сбоев в работе сетевого оборудования;
5) недостаточная квалификация технического персонала и его ошибки;
6) ошибок в программных комплексах, обслуживающих реестр (Система).
2.6.2. Требования к организации службы поддержки Оператора реестра
Управление сетью должно осуществляться непрерывно в течение трех рабочих смен. Штатное расписание одной рабочей смены должно предусматривать не менее 2 (двух) системных администраторов в дневное время, задействованы исключительно в этой работе, и одного в ночное время, также задействованного исключительно в этой работе, и не менее 2 (двух) работников персонала технической поддержки в дневное время и одного в ночное время. Претендент должен представить соответствующие должностные инструкции дежурного персонала изменений по всем позициям.
Управление сетью должно осуществляться персоналом в режиме 7х24х365. Время отклика и реагирования на внешнее обращение не должно превышать 120 секунд.
Квалификация персонала должна быть подтверждена Претендентом.
2.6.3. Охрана территорий.
Пропуск на территории офисных помещений Оператора реестра может быть свободным, но с разрешения персонала. Все рабочие компьютеры, с которых обеспечивается доступ к Системе должны не хранить постоянно пароли доступа в программных приложениях и в ОС, вводиться каждый раз в каждом сеансе доступа. Продолжительность сеансов должно быть кратким, компьютеры не должны оставаться без присмотра персонала, чтобы предотвратить использование этих компьютеров посторонними лицами, зашли к офисным помещениям. Должна быть предусмотрена возможность экстренной или заранее подготовленной передачи управления и доступа в IT-систему реестра сбоку руководящего состава Оператора реестра и Администратора через удаленный узел с возможностью поднятия привилегия управления в Системе с целью отмены всех возможных изменений, которые были сделаны с текущими привилегиями управления в случае , если такой доступ скомпрометировано (получен доступ сторонними лицами). Все лица кроме руководящего состава Оператора реестра и Администратора по действиям с повышенными привилегиями являются посторонними лицами, которым такие действия запрещаются и информация о возможности таких действий (адреса, последовательность и т.д.) должна быть доступна.
Пропуск на территорию производственных помещений Оператора реестра должно происходить исключительно на основании соответствующего допуска.
Допуск к оборудованию IT-систем и телекоммуникационного (сетевого) оборудования должно разрешаться строго ограниченному кругу лиц из персонала Оператора реестра или персонала того датацентра, с которым у Оператора реестра заключен договор. Ответственность за непрерывность и постоянство работы реестра (Системы) возлагается на Оператора реестра.
Претендент должен представить все решения и инструкции по указанным вопросам в этом разделе Требований.
2.6.4. Система оповещения.
Система оповещения должна обеспечивать немедленное сообщение о возникновении внештатной ситуации очередной смене (в соответствии с должностными инструкциями персонала) и руководящему составу Оператора реестра, а также протоколирование таких сообщений и их выслеживание.
Претендент должен представить свое решение по организации системы оповещения.
2.6. 5. Требования к отчетности.
Отчетность должна представляться в электронном и письменном (печатном) виде.
Отчетность в виде Технического отчета изменения должна открываться как журнал в начале каждой смены, вестись в течение всей смены (до передачи другой смене, а не до завершения смены) и заканчиваться соответствующими записями и подписью ответственного лица в конце смены.
Технический отчет изменения должен содержать полные сведения о каждом обстоятельство или ситуацию, являются внештатными (время возникновения, установлены причины возникновения, действия персонала, ответственного за ликвидацию, время завершения (возврат в штатное состояние), последствия) .
В случае, если внештатные ситуации возникают с периодичностью должен быть составлен Технический отчет о нештатной ситуации, в котором описывается с исчерпывающей полнотой характер возникновения внештатной ситуации, характерные признаки, действия, которые применялись, другую информацию, которая может быть полезной. Технический отчет о нештатной ситуации, возникающая периодически состоит предназначенной ответственным лицом или руководством Оператора реестра ..
Хранение отчетности осуществляется на электронных носителях. Ответственность за сохранность, целостность, корректность и своевременность предоставления отчетности о техническом состоянии реестра несет Оператор реестра.
Срок хранения отчетности неограниченный и определяется решением Администратора.
Претендент должен представить свое решение по организации отчетности.
2.6.6. Статистика и информация о состоянии работоспособности.
Система должна иметь интерфейс доступа к статистическим данным (количество регистраций, продлений регистраций, отмен, определенных состояний доменных имен, состояния трудоспособности подсистем, время непрерывной работы, количество сбоев и их продолжительность и т.д.). Система статистики должна иметь возможность автоматизированного экспорта части данных, определяться администрацией, для обработки их внешними системами. Доступ к системе статистики и информации о состоянии работоспособности должно быть ограниченным и определяться администрацией.
Претендент должен представить свое решение по организации системы статистики и информации о состоянии работоспособности.