Содержание:

1) Краткий анализ потенциальных рисков в случае принятия приказа Минцифры 

2) Образец замечаний и предложений разработчикам 

30 апреля Минцифры России разместило проект приказа "Об утверждении Требований к функционированию технических и программных средств (в том числе средств связи), используемым в целях выявления в информационно-телекоммуникационной сети «Интернет» сетевых адресов, соответствующих доменным именам" на сайте https://regulation.gov.ru/projects/167678/ для общественного обсуждения. Мы предлагаем всем принять участи в обсуждении и направить свои замечания до 29 мая. 

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

Главный риск в том, что такой контроль может использоваться не только для технической стабильности, но и для ограничения доступа к информации. Сайт могут не блокировать напрямую — он просто перестанет открываться или будет открываться нестабильно. Для обычного пользователя это будет выглядеть как «интернет сломался», хотя на самом деле причина может быть в фильтрации или ограничении доступа на уровне DNS.

Отдельная проблема — сбор данных о действиях пользователей. Если провайдеры будут обязаны фиксировать, к каким доменам обращались люди, когда и откуда, это может превратиться в систему наблюдения. Даже без чтения переписки можно многое понять о человеке: какие СМИ он читает, какими сервисами пользуется, интересуется ли VPN, медицинскими, юридическими, финансовыми или политическими ресурсами.

Серьёзные последствия возможны и для VPN. Хотя приказ напрямую не говорит «запретить VPN», через DNS можно затруднить работу сайтов VPN-сервисов, приложений, обновлений, авторизации и серверов подключения. Это ударит не только по людям, которые используют VPN для доступа к информации, но и по бизнесу: многие компании используют VPN для удалённой работы, защиты данных, связи филиалов и доступа сотрудников к внутренним системам.

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

---

1) Анализ потенциальных рисков проекта с учётом влияния на интернет, доступ к информации, цензуру, права граждан и бизнеса, государственный контроль и VPN-сервисы

1. Общий вывод

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

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

Проект потенциально создаёт или усиливает инфраструктуру, которая может быть использована для:

• централизованного управления DNS-разрешением;
• ограничения доступа к интернет-ресурсам;
• фильтрации доменных имён;
• выявления и блокировки сайтов, сервисов и инфраструктуры;
• фиксации действий пользователей;
• накопления данных о сетевой активности;
• контроля за провайдерами связи, хостинг-провайдерами и владельцами сетевой инфраструктуры;
• ограничения или деградации работы VPN-сервисов;
• выявления пользователей, обращающихся к VPN-инфраструктуре;
• давления на бизнес, размещающий или использующий защищённые сетевые сервисы.

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

2. Почему DNS-регулирование критически важно

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

Контроль над DNS позволяет влиять на то, какие ресурсы будут доступны пользователю.

Через DNS можно:

• не возвращать IP-адрес для определённого домена;
• возвращать неправильный IP-адрес;
• перенаправлять пользователя на другую страницу;
• фильтровать определённые домены;
• ограничивать доступ к сайтам без физической блокировки сервера;
• фиксировать факт обращения пользователя к тому или иному домену;
• собирать статистику интересов и сетевой активности пользователей.

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

3. Прямые риски ограничения работы интернета

3.1. Централизация DNS-разрешения

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

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

Возможные последствия

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

Уровень риска

Высокий.

3.2. DNS-блокировки и DNS-фильтрация

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

Возможные механизмы:

• отказ в разрешении домена;
• подмена DNS-ответа;
• перенаправление на страницу-заглушку;
• блокировка поддоменов;
• применение централизованных списков доменов;
• фильтрация запросов к определённым категориям сервисов.

Особая опасность DNS-блокировок

DNS-блокировка часто менее прозрачна для пользователя. Сайт или сервис «просто не открывается», а пользователь не всегда понимает, связано ли это с технической ошибкой, блокировкой, проблемой у провайдера или намеренным ограничением.

Уровень риска

Высокий.

3.3. Риск деградации качества доступа к интернету

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

На практике при введении дополнительных обязательных компонентов — взаимодействия с национальной DNS-системой, логирования, проверок, хранения сведений — могут возникнуть:

• дополнительные задержки;
• сбои разрешения доменных имён;
• перегрузка DNS-инфраструктуры;
• зависимость от централизованных компонентов;
• массовые отказы при ошибках конфигурации;
• проблемы совместимости с существующими сетевыми архитектурами.

Возможные последствия

• замедление доступа к сайтам;
• периодическая недоступность ресурсов;
• сбои в работе приложений;
• ухудшение пользовательского опыта;
• нарушение работы бизнес-сервисов.

Уровень риска

Средний/высокий.

3.4. Риск фрагментации интернета

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

Это означает, что пользователь в России и пользователь за пределами России могут фактически видеть разные версии интернета.

Формы фрагментации

• часть доменов не разрешается;
• часть доменов разрешается на другие IP-адреса;
• международные сервисы работают нестабильно;
• доступ к глобальным платформам зависит от национальной инфраструктуры;
• российский бизнес вынужден адаптировать свои сервисы под особые DNS-условия.

Уровень риска

Высокий.

4. Риски для доступа к информации и цензуры

4.1. Возможность скрытого ограничения доступа

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

Ресурс может продолжать существовать, но пользователи определённого оператора или страны не смогут получить его IP-адрес.

Почему это опасно

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

Уровень риска

Высокий.

4.2. Риск внесудебного или непрозрачного ограничения информации

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

Не определено:

• кто принимает решение об ограничении домена;
• на каком основании;
• как уведомляется владелец ресурса;
• как пользователь узнаёт причину недоступности;
• как обжаловать ограничение;
• кто отвечает за ошибочную блокировку;
• как исключить избыточное ограничение доступа.

Сам проект технический, но именно это создаёт риск: технический механизм формируется, а гарантии от злоупотреблений прямо не закреплены.

Уровень риска

Высокий.

4.3. Риск избыточной блокировки — overblocking

DNS-блокировка может затрагивать не только конкретный спорный ресурс, но и добросовестные сервисы.

Особенно это актуально для:

• облачных платформ;
• CDN-сетей;
• хостингов;
• SaaS-сервисов;
• доменов с большим количеством поддоменов;
• инфраструктурных доменов, обслуживающих множество клиентов.

Последствия для граждан

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

Последствия для бизнеса

• потеря клиентов;
• сбои в работе сайтов и приложений;
• нарушение договорных обязательств;
• репутационный ущерб;
• дополнительные расходы на резервирование.

Уровень риска

Высокий.

5. Риски для VPN-сервисов и защищённых каналов связи

5.1. Общая оценка влияния на VPN

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

VPN-сервисы зависят от DNS на нескольких уровнях:

• доступ к сайту VPN-провайдера;
• скачивание приложения;
• авторизация пользователя;
• проверка подписки;
• получение списка серверов;
• получение конфигураций;
• обновление клиента;
• обращение к API;
• подключение к серверу по доменному имени;
• работа служебных доменов и CDN.

Если DNS-разрешение этих доменов ограничивается или деградирует, VPN может перестать работать полностью или частично.

5.2. DNS-блокировка доменов VPN-сервисов

Через национальную DNS-инфраструктуру или связанные с ней технические средства потенциально можно ограничивать разрешение доменов VPN-сервисов.

Это может затронуть:

• официальные сайты VPN-провайдеров;
• домены загрузки приложений;
• домены авторизации;
• домены обновлений;
• API-домены;
• серверы выдачи конфигураций;
• домены технической поддержки;
• CDN-домены.

Последствия

• пользователь не может открыть сайт VPN-сервиса;
• невозможно скачать приложение;
• приложение не может проверить подписку;
• клиент не получает список серверов;
• обновления не загружаются;
• сервис работает нестабильно;
• новые пользователи не могут подключиться к VPN.

Уровень риска

Высокий.

5.3. Деградация VPN без формальной блокировки

VPN может быть ограничен не только прямой блокировкой, но и ухудшением DNS-разрешения.

Возможные формы:

• задержки при разрешении доменов VPN;
• периодическая недоступность служебных доменов;
• ошибки DNS;
• нестабильные ответы;
• возврат неактуальных адресов;
• невозможность получить конфигурацию.

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

Уровень риска

Средний/высокий.

5.4. Риск выявления пользователей VPN по DNS-логам

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

Даже если само VPN-соединение зашифровано, предварительные обращения к DNS могут показать:

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

Последствия

• фиксация интереса пользователя к VPN;
• возможность построения статистики использования VPN;
• связывание конкретного пользователя с конкретным VPN-сервисом;
• риск последующего давления на пользователей;
• охлаждающий эффект — отказ от законного использования VPN из-за опасения наблюдения.

Уровень риска

Высокий.

5.5. Риск для корпоративных VPN

Особенно важно отделить публичные VPN-сервисы от корпоративных VPN.

Корпоративные VPN используются для:

• удалённой работы;
• доступа к внутренним системам;
• администрирования серверов;
• связи филиалов;
• работы банковских, промышленных и IT-систем;
• защиты коммерческой тайны;
• обеспечения информационной безопасности.

Если DNS-регулирование будет применяться широко или ошибочно, оно может затронуть не только массовые VPN-сервисы, но и корпоративные защищённые каналы.

Последствия для бизнеса

• невозможность удалённой работы;
• простой сотрудников;
• нарушение доступа к внутренним системам;
• сбои в DevOps-процессах;
• проблемы у банков, IT-компаний, промышленных предприятий;
• нарушение SLA;
• рост расходов на резервные каналы;
• снижение кибербезопасности.

Уровень риска

Высокий.

5.6. Риск нарушения обновлений VPN-клиентов

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

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

Последствия

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

Уровень риска

Высокий.

5.7. Давление на хостинг-провайдеров, размещающих VPN-инфраструктуру

Поскольку проект распространяет требования на провайдеров хостинга, возникает риск административного давления на компании, которые размещают VPN-инфраструктуру или privacy-сервисы.

Хостинг-провайдеры могут начать избегать клиентов, связанных с:

• VPN;
• прокси-сервисами;
• privacy-инструментами;
• защищёнными коммуникациями;
• нестандартными сетевыми решениями.

Косвенные последствия

• отказ в обслуживании законных проектов;
• самоцензура хостинг-провайдеров;
• уход VPN-инфраструктуры из российской юрисдикции;
• ухудшение качества связи;
• рост стоимости защищённых сервисов.

Уровень риска

Высокий.

5.8. Риск ухудшения кибербезопасности из-за ограничения VPN

VPN используется не только для обхода блокировок. Это базовый инструмент кибербезопасности.

Ограничение или деградация VPN может ухудшить защиту:

• персональных данных;
• коммерческой тайны;
• удалённого доступа;
• корпоративной инфраструктуры;
• журналистских и юридических коммуникаций;
• административного доступа к серверам.

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

6. Риски для прав и свобод граждан

6.1. Ограничение права на поиск, получение и распространение информации

Доступ к интернету является важным условием реализации права на поиск, получение и распространение информации.

Если DNS-инфраструктура используется для ограничения доменов, это может затронуть:

• доступ к СМИ;
• образовательным ресурсам;
• научным базам;
• правозащитным материалам;
• зарубежным сервисам;
• коммуникационным платформам;
• сервисам защиты приватности, включая VPN.

Даже если ограничение вводится технически, его последствия носят правовой и социальный характер.

Уровень риска

Высокий.

6.2. Нарушение приватности и тайны коммуникаций

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

В контексте DNS это может включать:

• домены, к которым обращался пользователь;
• время обращения;
• IP-адрес пользователя;
• идентификатор абонента;
• результат DNS-запроса;
• признаки ошибки, блокировки или перенаправления;
• обращения к VPN-доменам;
• обращения к сервисам связи, почты, облакам, мессенджерам.

DNS-запросы могут раскрывать весьма чувствительную информацию:

• политические интересы;
• религиозные взгляды;
• состояние здоровья;
• финансовое поведение;
• профессиональные связи;
• используемые сервисы;
• попытки защитить соединение через VPN.

Уровень риска

Высокий.

6.3. Массовое профилирование пользователей

Даже без доступа к содержимому трафика DNS-логи позволяют формировать поведенческий профиль пользователя.

Можно определить:

• какие сайты он посещает;
• какие приложения использует;
• когда активен;
• какими банками, маркетплейсами, СМИ пользуется;
• какие облачные сервисы использует;
• обращается ли к VPN, Tor, прокси или иным privacy-инструментам.

Это создаёт риск массового цифрового наблюдения.

Уровень риска

Высокий.

6.4. Охлаждающий эффект

Если граждане понимают, что обращения к определённым доменам могут фиксироваться, они могут отказаться от законного поведения:

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

Такой эффект ограничивает свободу выражения мнения даже без прямого запрета.

7. Риски для бизнеса

7.1. Рост затрат на инфраструктуру

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

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

Последствия

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

Уровень риска

Высокий.

7.2. Административная зависимость бизнеса от государства

Если работа провайдера или хостинг-компании зависит от выполнения технических требований, связанных с национальной DNS-системой, бизнес становится более зависимым от:

• регулятора;
• проверок;
• предписаний;
• требований по логированию;
• правил эксплуатации национальной DNS-инфраструктуры;
• запросов государственных органов.

Техническое регулирование может стать инструментом административного контроля.

Уровень риска

Высокий.

7.3. Риски для компаний, использующих VPN

Для бизнеса VPN — это не инструмент обхода ограничений, а штатный элемент защищённой инфраструктуры.

VPN используется для:

• удалённой работы сотрудников;
• связи филиалов;
• доступа к корпоративным системам;
• администрирования серверов;
• защиты данных;
• работы с облачными платформами;
• подключения к внутренним CRM, ERP, DevOps и финансовым системам.

Ограничение или нестабильность VPN может привести к:

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

Уровень риска

Высокий.

7.4. Риск санкций за технические сбои

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

Например:

• сбои внешних DNS-источников;
• DDoS-атаки;
• аварии магистральных операторов;
• ошибки национальной DNS-системы;
• сбои оборудования;
• ошибки обновления ПО;
• проблемы совместимости.

Уровень риска

Средний/высокий.

7.5. Риск утечек данных

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

Для бизнеса это создаёт риски:

• утечек;
• претензий регуляторов;
• исков пользователей;
• репутационного ущерба;
• расходов на защиту хранилищ;
• атак на базы логов.

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

Уровень риска

Высокий.

8. Риски усиления государственного контроля

8.1. Создание инфраструктуры централизованного контроля DNS

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

Через такую инфраструктуру возможно:

• распространение правил разрешения доменов;
• централизованное обновление списков ограничений;
• мониторинг DNS-запросов;
• проверка исполнения блокировок;
• выявление операторов, которые не применяют ограничения;
• контроль доступа к VPN-доменам и privacy-сервисам.

Уровень риска

Высокий.

8.2. Расширение функций без изменения технической базы

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

• фильтрации;
• блокировки;
• мониторинга;
• контроля VPN;
• выявления обхода ограничений;
• анализа поведения пользователей;
• расследований;
• статистического контроля.

Такое расширение возможно без существенной перестройки системы.

Уровень риска

Высокий.

8.3. Непрозрачный доступ государства к логам

Проект не раскрывает порядок доступа государственных органов к зафиксированной информации.

Неясно:

• кто может запрашивать данные;
• требуется ли судебное решение;
• достаточно ли административного запроса;
• какие данные могут быть переданы;
• как фиксируется факт доступа;
• кто контролирует обоснованность запроса;
• может ли пользователь узнать о доступе к его данным.

При отсутствии гарантий DNS-логи могут стать инструментом наблюдения, в том числе за пользователями VPN.

Уровень риска

Высокий.

9. Риски неопределённости формулировок

9.1. Неясность выражения «иные сведения, позволяющие выявить действия пользователей»

Это одна из наиболее проблемных формулировок.

Она может быть истолкована как обязанность фиксировать:

• DNS-запросы;
• IP-адреса пользователей;
• домены, к которым они обращались;
• обращения к VPN-сервисам;
• попытки подключения к заблокированным ресурсам;
• действия администраторов;
• технические события;
• ошибки и сбои;
• попытки обхода ограничений.

Такая неопределённость создаёт риск чрезмерного сбора данных.

Уровень риска

Высокий.

9.2. Неясность понятия «внешний источник адресной информации»

Проект использует формулировку о внешнем источнике адресной информации, но не определяет её достаточно ясно.

Неясно:

• является ли таким источником глобальная DNS-система;
• является ли им национальная DNS-система;
• может ли оператор выбирать источник;
• какой ответ имеет приоритет;
• что делать при расхождении данных;
• кто отвечает за ошибочные DNS-ответы.

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

9.3. Неясность круга субъектов

Требования могут затронуть:

• операторов связи;
• владельцев технологических сетей;
• организаторов распространения информации;
• провайдеров хостинга;
• дата-центры;
• CDN-провайдеров;
• облачные платформы;
• корпоративные сети;
• SaaS-сервисы;
• владельцев автономных систем.

Неопределённость повышает риск расширительного и произвольного применения.

10. Косвенные риски

10.1. Самоцензура бизнеса

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

Это может привести к отказу в обслуживании:

• независимых СМИ;
• правозащитных проектов;
• privacy-сервисов;
• VPN-проектов;
• исследовательских платформ;
• политически чувствительных ресурсов;
• клиентов с нестандартной сетевой инфраструктурой.

Уровень риска

Высокий.

10.2. Уход пользователей к менее безопасным инструментам

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

Это повышает риски:

• кражи данных;
• установки вредоносного ПО;
• перехвата трафика;
• продажи пользовательских данных;
• фишинга;
• компрометации устройств.

Уровень риска

Средний/высокий.

10.3. Снижение доверия к российской интернет-инфраструктуре

Если DNS-инфраструктура воспринимается как инструмент контроля, это снижает доверие:

• пользователей;
• бизнеса;
• иностранных партнёров;
• разработчиков;
• облачных клиентов;
• инвесторов.

Последствия

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

10.4. Снижение устойчивости сети

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

Чем больше обязательных элементов:

• тем выше риск ошибки;
• тем больше точек отказа;
• тем сложнее диагностика;
• тем выше стоимость эксплуатации;
• тем сложнее малым операторам соответствовать требованиям.

11. Соотношение с правами и свободами

Потенциально затрагиваются следующие правовые ценности:

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

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

12. Наиболее проблемные положения проекта

Положение / аспект	Потенциальный риск
Взаимодействие с национальной системой доменных имён	Централизация DNS, возможность управления доступом
Фиксация «иных сведений, позволяющих выявить действия пользователей»	Массовое логирование, профилирование, наблюдение
Хранение данных 1 год	Риск утечек и долгосрочного контроля
Отсутствие точного перечня фиксируемых данных	Расширительное толкование
Отсутствие порядка доступа к данным	Непрозрачный государственный контроль
Отсутствие гарантий от цензуры	Возможность скрытой фильтрации
Распространение на хостинг-провайдеров	Давление на инфраструктурный бизнес
DNS-уровень регулирования	Возможность блокировать сайты и сервисы без удаления контента
Отсутствие специальных гарантий для VPN	Риск ограничения законных VPN и корпоративных защищённых каналов
Возможность фиксации обращений к VPN-доменам	Выявление пользователей VPN
Влияние на обновления VPN-клиентов	Ухудшение кибербезопасности
Overblocking	Затрагивание легальных сервисов и корпоративных систем

---

13. Сценарии негативного применения

Сценарий 1. Мягкий технический

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

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

Сценарий 2. Административно-контрольный

Национальная DNS-система становится фактически обязательным источником DNS-ответов. Операторы должны сверять данные или получать адресную информацию через неё.

Риски:

• централизованный контроль;
• зависимость операторов;
• возможность фильтрации;
• контроль доступа к отдельным сервисам;
• давление на бизнес.

Сценарий 3. Фильтрационно-цензурный

Через DNS-инфраструктуру внедряются списки доменов, которые не должны разрешаться или должны перенаправляться.

Риски:

• цензура;
• overblocking;
• скрытые ограничения;
• невозможность доступа к законной информации;
• блокировка инфраструктурных доменов.

Сценарий 4. Наблюдательный

DNS-логи используются для анализа поведения пользователей.

Риски:

• массовое профилирование;
• выявление интересов;
• контроль обращений к СМИ, мессенджерам, VPN и облачным сервисам;
• вмешательство в частную жизнь.

Сценарий 5. Ограничение VPN и privacy-инструментов

DNS-инфраструктура используется для ограничения работы VPN не через прямую блокировку трафика, а через нарушение работы доменов, необходимых VPN-сервисам.

Возможные последствия:

• сайты VPN не открываются;
• приложения не обновляются;
• авторизация не работает;
• список серверов не загружается;
• корпоративные VPN попадают под сбои;
• пользователи отказываются от VPN из-за нестабильности;
• бизнес теряет защищённый удалённый доступ.

Риски очень высокие.

14. Меры по снижению рисков

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

14.1. Уточнить состав фиксируемых данных

Необходимо прямо указать, какие именно сведения могут фиксироваться.

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

Особенно важно ограничить хранение:

• полного перечня DNS-запросов пользователей;
• идентификаторов пользователей;
• истории обращений к доменам;
• сведений об обращениях к VPN-сервисам;
• данных, не необходимых для диагностики и безопасности.

14.2. Ввести принцип минимизации данных

Фиксироваться должны только данные, необходимые для:

• диагностики работоспособности;
• информационной безопасности;
• расследования технических инцидентов;
• подтверждения исправности средств.

Не должно быть обязанности создавать поведенческие профили пользователей.

14.3. Сократить срок хранения

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

Можно предложить дифференцированный подход:

• технические события — короткий срок;
• события информационной безопасности — отдельный срок;
• агрегированная статистика — возможно дольше;
• персонализированные сведения — только минимально необходимое время.

14.4. Установить запрет на использование системы для цензуры вне законной процедуры

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

14.5. Обеспечить прозрачность ограничений

Если доступ к домену ограничен по правовым основаниям, пользователь должен получать понятное уведомление:

• что доступ ограничен;
• на каком основании;
• каким органом принято решение;
• где опубликована информация;
• как обжаловать ограничение.

14.6. Установить порядок доступа к логам

Нужно определить:

• кто может запрашивать данные;
• на каком основании;
• требуется ли судебный акт;
• какие данные могут быть переданы;
• как фиксируется доступ;
• как проводится аудит запросов;
• как предотвращается массовая выгрузка данных.

14.7. Обезличивание и агрегация

Если цель — контроль работоспособности, в большинстве случаев достаточно агрегированных и обезличенных данных.

Персонализированные данные должны использоваться только при наличии строгого законного основания.

14.8. Специальные гарантии для VPN и защищённых каналов

Следует прямо закрепить, что применение требований не должно препятствовать законному использованию VPN, включая:

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

14.9. Разграничить публичные VPN и корпоративные VPN

Необходимо исключить ситуацию, при которой меры против отдельных публичных сервисов затрагивают:

• банковские VPN;
• промышленные VPN;
• VPN медицинских организаций;
• VPN образовательных учреждений;
• защищённые каналы IT-компаний;
• VPN государственных подрядчиков;
• удалённый доступ сотрудников.

14.10. Независимый аудит

Нужен регулярный аудит:

• корректности DNS-разрешения;
• отсутствия несанкционированной фильтрации;
• защищённости логов;
• соблюдения требований к персональным данным;
• влияния на VPN и защищённые каналы;
• устойчивости инфраструктуры.

15. Обновлённая итоговая оценка рисков

Категория риска	Уровень
Ограничение доступа к информации	Высокий
DNS-цензура	Высокий
Скрытая фильтрация доменов	Высокий
Массовое логирование действий пользователей	Высокий
Профилирование пользователей	Высокий
Выявление пользователей VPN	Высокий
Ограничение работы VPN-сервисов	Высокий
Нарушение работы корпоративных VPN	Высокий
Деградация обновлений VPN-клиентов	Высокий
Централизация государственного контроля	Высокий
Рост затрат бизнеса	Высокий
Утечки данных	Высокий
Самоцензура бизнеса и хостинг-провайдеров	Высокий
Overblocking легальных сервисов	Высокий
Снижение устойчивости интернета	Средний/высокий
Фрагментация интернета	Высокий
Ухудшение кибербезопасности	Средний/высокий

16. Финальный вывод

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

Основные риски связаны с тем, что проект может создать инфраструктуру для:

• централизованного контроля доступа к доменам;
• скрытой фильтрации и блокировки ресурсов;
• накопления данных о действиях пользователей;
• профилирования граждан;
• административного давления на операторов и хостинг-провайдеров;
• ограничения доступа к информации;
• деградации или блокировки VPN-сервисов;
• нарушения работы корпоративных защищённых каналов.

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

Наиболее уязвимые места проекта:

1. обязательное взаимодействие с национальной системой доменных имён;
2. широкая формулировка о фиксации действий пользователей;
3. отсутствие точного перечня собираемых данных;
4. хранение сведений в течение одного года;
5. отсутствие порядка доступа государства к этим данным;
6. отсутствие прямых гарантий от цензуры;
7. отсутствие специальных исключений и гарантий для VPN и корпоративных защищённых каналов;
8. риск давления на хостинг-провайдеров;
9. риск overblocking;
10. риск ухудшения кибербезопасности.

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

---

2. Образец замечаний и предложений разработчикам 

ПИШЕМ ЗАМЕЧАНИЯ двумя способами:

1) На сайте https://regulation.gov.ru/projects/167678/ авторизовавших по логину и паролю (не у всех срабатывает) или через ГУ. Прямо на этой странице в разделе "ВАШИ ПРЕДЛОЖЕНИЯ". Скопируйте туда наш текст, что мы разместили ниже.

2) Послав на электронную почту автору t.trubakova@digital.gov.ru и копию n.nezemskaya@digital.gov.ru

Замечания и предложения к проекту приказа Минцифры России

1. Общая позиция

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

1. скрытого ограничения доступа к законным интернет-ресурсам;
2. массового сбора сведений о действиях пользователей в сети Интернет;
3. дискриминации отдельных технологий доступа, включая VPN, корпоративные защищённые сети, DoH/DoT/DoQ и иные средства защиты соединения;
4. создания инфраструктуры внесудебного контроля за доступом граждан к информации;
5. ухудшения устойчивости, скорости и предсказуемости работы российского сегмента сети Интернет;
6. возникновения правовой неопределённости для операторов связи, владельцев автономных систем, организаций, использующих корпоративные сети, и обычных пользователей.

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

2. Ключевая проблема проекта: смешение технической устойчивости и контроля доступа

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

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

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

В связи с этим регулирование DNS должно строиться на принципах:

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

3. Конкретные замечания и предложения

Замечание 1. В проекте отсутствует чёткое ограничение целей применения мер

Если в приказе используются формулировки вроде:

• «обеспечение контроля»;
• «управление доступом»;
• «мониторинг обращений»;
• «анализ DNS-запросов»;
• «иные сведения»;
• «иные мероприятия»;
• «по требованию уполномоченного органа» без конкретизации оснований,

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

Необходимо прямо указать, что приказ применяется только для технических целей: устойчивость, отказоустойчивость, безопасность, противодействие DDoS-атакам, защита от DNS-spoofing, DNS-cache poisoning, вредоносных доменов и иных сетевых инцидентов.

Предлагаемая правка

Дополнить проект пунктом следующего содержания:

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

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

Замечание 2. Необходимо запретить скрытую подмену DNS-ответов

Особую опасность представляет возможность технического вмешательства в DNS-ответы, когда пользователь вместо корректного IP-адреса получает:

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

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

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

Предлагаемая правка

Дополнить проект пунктом:

«Не допускается подмена, искажение, необоснованное блокирование, задержка или модификация DNS-ответов, за исключением случаев, прямо предусмотренных федеральным законом, судебным актом либо решением уполномоченного органа, принятым в установленном законом порядке.

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

Замечание 3. Необходимо запретить массовый сбор и хранение DNS-запросов граждан

Если проект допускает сбор, передачу или хранение DNS-запросов пользователей, это должно быть существенно ограничено.

DNS-запросы позволяют установить:

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

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

Массовое хранение DNS-запросов с привязкой к IP-адресу, абоненту, устройству, договору связи или геолокации создаёт инфраструктуру постоянного наблюдения.

Предлагаемая правка

Дополнить проект пунктом:

«Сбор, хранение и передача сведений о DNS-запросах пользователей допускаются только в минимально необходимом объёме, исключительно для целей обеспечения безопасности и устойчивости DNS-инфраструктуры.

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

Хранение сведений, позволяющих связать DNS-запрос с конкретным пользователем, абонентом, IP-адресом, устройством или договором связи, допускается только при наличии конкретного законного основания и на срок, не превышающий минимально необходимого для расследования сетевого инцидента».

Замечание 4. Нужно прямо указать сроки хранения технических журналов

Если проект обязывает операторов вести журналы DNS-событий, необходимо определить:

• какие именно данные хранятся;
• зачем они хранятся;
• кто имеет доступ;
• срок хранения;
• порядок удаления;
• меры защиты;
• ответственность за утечку.

Недопустима формулировка, при которой оператор обязан хранить «все сведения» или «иные сведения» без ограничения объёма и срока.

Предлагаемая правка

Внести пункт:

«Технические журналы DNS-инфраструктуры должны содержать только сведения, необходимые для диагностики и устранения сетевых инцидентов.

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

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

Рекомендуемый вариант для обсуждения:

«не более 7 суток для диагностических журналов и не более 30 суток для журналов, связанных с подтверждённым инцидентом информационной безопасности».

Замечание 5. Нужно запретить передачу «сырых» DNS-данных в централизованные системы

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

Иначе это создаёт централизованную базу сетевого поведения граждан.

Предлагаемая правка

Дополнить проект пунктом:

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

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

Замечание 6. Необходимо исключить дискриминацию VPN и защищённых соединений

Использование VPN, корпоративных туннелей, шифрования DNS, DoH, DoT, DoQ, IPsec, WireGuard, OpenVPN и иных защищённых технологий само по себе не является противоправным.

Такие технологии используются:

• компаниями для удалённой работы;
• банками и финансовыми организациями;
• IT-компаниями;
• образовательными учреждениями;
• медицинскими организациями;
• адвокатами и журналистами;
• гражданами для защиты соединения в публичных сетях;
• администраторами для безопасного доступа к инфраструктуре.

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

Предлагаемая правка

Дополнить проект пунктом:

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

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

Замечание 7. Необходимо защитить корпоративные сети и критически важные сервисы от побочных блокировок

Многие интернет-сервисы используют сложную инфраструктуру:

• CDN;
• облачные платформы;
• балансировщики;
• распределённые DNS;
• домены обновлений;
• домены авторизации;
• API-домены;
• домены телеметрии безопасности;
• домены доставки сертификатов и OCSP/CRL.

Ошибочная DNS-фильтрация может привести к отказу:

• банковских приложений;
• систем удалённой работы;
• облачных сервисов;
• обновлений операционных систем;
• антивирусов;
• корпоративных VPN;
• образовательных платформ;
• медицинских информационных систем.

Предлагаемая правка

Дополнить проект пунктом:

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

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

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

Если ресурс не открывается, пользователь должен понимать:

• это технический сбой;
• ошибка провайдера;
• проблема DNS;
• блокировка по закону;
• ошибочное ограничение.

Без механизма проверки возникает правовая неопределённость и недоверие.

Предлагаемая правка

Дополнить проект пунктом:

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

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

Замечание 9. Необходим механизм срочного обжалования ошибочных ограничений

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

Поэтому нужна процедура быстрого реагирования.

Предлагаемая правка

Дополнить проект пунктом:

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

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

В случае подтверждения ошибочного ограничения доступ должен быть восстановлен незамедлительно».

Замечание 10. Необходимо исключить неопределённые формулировки

Прошу исключить из проекта либо конкретизировать формулировки следующего типа:

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

Такие формулировки создают возможность расширительного толкования и произвольного применения.

Предлагаемая правка

Включить норму:

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

Замечание 11. Нужно закрепить принцип соразмерности

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

Например, для защиты от DDoS не требуется постоянное хранение истории DNS-запросов всех граждан. Для диагностики сбоя не требуется централизованная база доменов, которые посещал каждый пользователь.

Предлагаемая правка

Дополнить проект пунктом:

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

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

Замечание 12. Нужно предусмотреть независимый аудит

Если создаётся инфраструктура, способная влиять на доступ к интернет-ресурсам, необходим аудит.

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

Предлагаемая правка

Дополнить проект пунктом:

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

5. На основании изложенного прошу:

Не принимать проект приказа в текущей редакции.

1. Исключить из проекта положения, допускающие скрытую фильтрацию DNS-запросов, подмену DNS-ответов и неопределённое вмешательство в доступ к интернет-ресурсам.
2. Установить запрет на массовый сбор и централизованное хранение DNS-запросов граждан.
3. Закрепить принцип технологической нейтральности, включая защиту законного использования VPN, корпоративных сетей, шифрованных DNS-протоколов и иных средств защиты соединения.
4. Ввести обязательные механизмы прозрачности, уведомления и обжалования ограничений.
5. Установить конкретные сроки хранения технических журналов и запретить обработку избыточных данных.
6. Предусмотреть независимый аудит применения мер, предусмотренных приказом.
7. Провести повторное общественное обсуждение доработанной редакции проекта.

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

Подписывайтесь на наши ресурсы: