Введение
Компания КриптоПро работает на рынке производителей отечественных средств криптографической защиты информации (СКЗИ) без малого 20 лет и успела завоевать в отрасли одно из лидирующих положений. Вплоть до последнего времени этот бренд вызывал устойчивые ассоциации с криптопровайдером, средствами электронной подписи (ЭП) и средствами удостоверяющих центров (УЦ). Более того, для многих людей он успел стать едва ли не собирательным образом для обозначения таких СКЗИ.
Относительно недавно в линейке продуктов компании произошло пополнение. Оказалось, что компания в течение нескольких последних лет проводила планомерную работу по созданию продукта иного типа, результатом которой стал NGate — высокопроизводительный TLS-шлюз, позволяющий построить полноценную VPN-сеть для обеспечения защищенного удаленного доступа пользователей к информационным ресурсам.
Важнейшим конкурентным преимуществом продукта стала одновременная поддержка как TLS-ГОСТ, так и зарубежных криптонаборов TLS. Кроме того, обратить на него пристальное внимание заставляет возможность одновременной работы как с VPN-клиентами, так и в условиях веб-доступа, в режиме терминации TLS-соединений. Во многих существующих альтернативных решениях те же возможности зачастую предполагают использование разных продуктов.
Рисунок 1. Одновременная поддержка отечественных и зарубежных алгоритмов в КриптоПро NGate
Появление на рынке СКЗИ продукта с такой функциональностью следует признать крайне своевременным. Конечно, всегда были и будут востребованы средства, позволяющие решать проблему защиты удаленного доступа к сервисам электронной почты, веб-консолям управления различными ИТ-системами, системам обмена знаниями, корпоративным порталам, удаленным рабочим столам, файловым серверам, офисному программному обеспечению, системам электронного документооборота и т.п.
- Подавляющее большинство пользователей российского сегмента интернета, независимо от того, являются ли они частными лицами или сотрудниками организаций, используют операционные системы (ОС) и прикладное программное обеспечение (ПО) зарубежного производства. Наличие необходимых криптографических примитивов для реализации протокола TLS на основе зарубежных криптографических стандартов обеспечивается встраиванием криптографических библиотек и сертификатов зарубежных УЦ в состав ОС и/или браузера. Хотя в РФ есть УЦ, которые выдают собственные SSL-сертификаты, последние не предустановлены в ОС и веб-браузерах, и даже те российские сайты, которые используют проверенные сертификаты, все равно получают их в зарубежных центрах сертификации.
Описанная ситуация складывалась в российском сегменте интернета на протяжении многих лет, но негативные побочные эффекты стали очевидны лишь теперь. В качестве примера уместно вспомнить хотя бы прошлогоднюю историю с отзывом компанией GeoTrust SSL-сертификата Общественной палаты РФ в результате санкционной политики со стороны США. После этого инцидента были развеяны последние сомнения в том, что перечень оснований для отзыва сертификата далеко не ограничивается компрометацией закрытого ключа, а вполне может быть обусловлен политическими и экономическими причинами.
В качестве меры противодействия было принято решение о реализации перехода государственных учреждений на использование российских криптографических алгоритмов и средств шифрования в рамках электронного взаимодействия между собой, с гражданами и организациями (Поручение Президента РФ № Пр-1380 от 16.07.2022). Конечно, все понимают, что в одночасье решить проблему невозможно, переход должен быть постепенным. Поэтому на некотором этапе, по-видимому, нужно обеспечить бесконфликтное сосуществование на российских веб-серверах TLS-сертификатов как отечественного, так и зарубежного происхождения. На первых порах это позволит пользователю получать доступ к ресурсам российских сайтов независимо от того, поддерживает ли его браузер отечественные алгоритмы или еще нет.
- По инициативе Банка России и Минкомсвязи России создана и развивается единая биометрическая система (ЕБС), призванная обеспечить предоставление цифровых коммерческих и государственных услуг для граждан в любое время и в любом месте.
Применение удаленной биометрической идентификации клиентов в финансовой сфере регламентировано Федеральным законом «О внесении изменений в отдельные законодательные акты Российской Федерации» от 31.12.2022 N 482-ФЗ. Согласно 482-ФЗ, концепция получения доступа к услугам «в любое время и в любом месте» подразумевает возможность использования клиентом в этих целях любого устройства, будь то смартфон, планшет или стационарный компьютер.
Какой бы способ клиент ни выбрал, ему должна быть предоставлена возможность использовать для доступа сертифицированное СКЗИ с алгоритмами ГОСТ. И если в сценарии с использованием мобильного устройства право превращается в обязанность (клиенту будет попросту отказано в удаленной идентификации, если на смартфоне не установлено СКЗИ, сертифицированное ФСБ России по классу КС1), то при доступе со стационарного компьютера у клиента появляется выбор — он вполне может использовать для защиты доступа и зарубежные криптоалгоритмы. Для серверной стороны (информационной системы банка), реализующей для защиты канала связи протокол TLS, это означает, что нужно одновременно обеспечить поддержку как TLS-ГОСТ, так и зарубежного TLS. Насколько нам известно, в настоящее время на рынке только у NGate имеется соответствующая функциональность.
Из приведенных примеров видно, что КриптоПро, вооружившись продуктом NGate, имеет все основания претендовать на статус компании, имеющей в своем портфеле наиболее актуальные решения. Предлагаем рассмотреть подробнее, каким образом и за счет каких внутренних механизмов NGate достигаются анонсированные положительные эффекты.
Архитектура криптопро ngate
В состав КриптоПро NGate входят следующие компоненты:
- серверная часть (собственно криптошлюз и система управления);
- клиентская часть (опционально).
При внедрении в небольшие организации, которые не испытывают потребности в обеспечении отказоустойчивости при организации защищенного удаленного доступа, фактически достаточно установки единственного шлюза, контролирующего доступ к приложениям невысокого уровня критичности.
В этом случае криптошлюз целесообразно объединить с системой управления в единой аппаратной или виртуальной платформе. Функции управления при этом могут выполняться с любого автоматизированного рабочего места (АРМ) администратора с помощью веб-браузера с поддержкой алгоритмов ГОСТ.
Рисунок 2. Схема внедрения КриптоПро NGate с установкой шлюза и системы управления на одну аппаратную платформу
Если требуется создать отказоустойчивую систему доступа к критичным информационным ресурсам организации, предпочтительно использовать схему кластерного внедрения.
Рисунок 3. Схема внедрения КриптоПро NGate с раздельной установкой криптошлюзов и системы управления
В этой схеме несколько криптошлюзов объединяются в кластер, который может объединять до 32 нод, а система управления устанавливается на отдельный сетевой узел. При этом кластер может быть распределен по нескольким центрам обработки данных (ЦОД).
Схема кластерного развертывания допускает возможность применения имеющегося в организации балансировщика нагрузки. Выход из строя какого-либо элемента кластера не приводит к разрыву соединений, поскольку данные о сессии синхронизируются балансировщиком между устройствами и соединение перераспределяется на свободные узлы.
Централизованная система управления позволяет производить настройку, мониторинг и управление всеми шлюзами доступа организации. Предусмотрена возможность удаленной автоматизированной загрузки конфигураций на все узлы кластера, а также получение параметров работы кластера из единого центра управления в режиме онлайн.
Инструкция по настройке шлюза удаленных рабочих столов
Для того чтобы повысить уровень безопасности Windows-сервера бывает недостаточно сменить TCP-порт RDP . Рассмотрим настройку шлюза удаленных рабочих столов (Remote Desktop Gateway / Terminal Services Gateway) в домене Active Directory.
Remote Desktop Gateway, что это?
Remote Desktop Gateway — это роль Windows-сервера, обеспечивающая защищенное соединение, с помощью протокола SSL, с сервером по RDP. Главное преимущество этого решения в том, что не требуется развертывание VPN-сервера, для этого и используется шлюз.
Следует отметить, что начиная с Windows Server 2008 R2, были изменены названия всех служб удаленных рабочих столов. Именуемые ранее службы Terminal Services были переименованы в Remote Desktop Services.
Преимущества Remote Desktop Gateway в следующем:
- Используя зашифрованное соединение, шлюз позволяет подключаться к внутренним сетевым ресурсам без необходимости использования VPN-соединения удаленными пользователями;
- Шлюз дает возможность контроля доступа к определенным сетевым ресурсам, тем самым реализуя комплексную защиту;
- Шлюз разрешает подключение к сетевым ресурсам, которые размещены за межсетевыми экранами в частных сетях или NAT;
- С помощью консоли диспетчера шлюза появляется возможность настраивать политики авторизации для тех или иных условий, которые должны быть выполнены при подключении к сетевым ресурсам удаленными пользователями. В качестве примера, можно указать конкретных пользователей, которые могут подключаться к внутренним сетевым ресурсам, а также должен ли клиентский компьютер при этом быть членом группы безопасности AD, допустимо ли перенаправление устройства и диска;
- Консоль диспетчера шлюза содержит инструменты, предназначенные для отслеживания состояния шлюза. Используя их, вы можете назначить отслеживаемые события для аудита, например, неудачные попытки подключения к серверу шлюза служб терминалов.
Важно! Шлюз служб терминалов должен входить в домен Active Directory. Настройка шлюза выполняется только от имени администратора домена, на любом сервере в домене.
Установим роль.
Открываем Диспетчер серверов.
Выбираем “Добавить роли и компоненты”.
На этапе “Тип установки”, выбираем “Установка ролей и компонентов”.
Следующим шагом выбираем текущий сервер.
Роль сервера — Служба удаленных рабочих столов.
Переходим к службе ролей. Выбираем “Шлюз удаленных рабочих столов”.
Переходим к этапу подтверждения, нажимаем кнопку “Установить”.
Настройка политики авторизации подключения и ресурсов.
В открывшемся окне диспетчера шлюза удаленных рабочих столов, в левой части окна, раскрываем ветку с именем сервера → Политики → Политики авторизации подключений.
В правой части того же окна выбираем Создать новую политику → Мастер.
В открывшемся окне “Мастер создания новых политик авторизации” выбираем рекомендуемый параметр “Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов”. Нажимаем кнопку “Далее”.
На следующем шаге вводим удобное имя для политики авторизации подключения. Мы рекомендуем давать имена на английском языке.
В окне выбора групп кликаем по кнопке “Дополнительно”.
Окно изменит размеры. Нажимаем кнопку “Поиск”. В результатах поиска находим “Администраторы домена” и нажимаем кнопку “OK”.
В окне выбора группы проверяем выбранные имена объектов и нажимаем “OK”.

Группа добавлена. Для перехода к следующему шагу нажимаем кнопку “Далее”.
На следующем этапе выбираем пункт “Включить перенаправление устройств для всех клиентских устройств” и нажимаем “Далее”.
Устанавливаем таймауты — время простоя и время работы сессии, значения указаны в часах. Нажимаем “Далее”.
Проверяем выполненные настройки. Все правильно — нажимаем “Далее”.
На следующем этапе настроим политику авторизации ресурсов. Указываем желаемое имя политики. Нажимаем “Далее”.
Следующим шагом установим членство в группах. Обычно, группа уже установлена, но если это не выполнено, следует выполнить действия приведенные выше. Нажимаем “Далее”.
Выбираем доступные сетевые ресурсы. Для этого необходимо выбрать группу, которая содержит серверы на которых требуемые группы пользователей могли бы работать с удаленным рабочим столом. Нажимаем кнопку “Обзор”.
В окне выбора группы, нажимаем кнопку “Дополнительно”.
В измененном окне нажимаем кнопку “Поиск”. В окне результатов находим “Контроллеры домена”. Нажимаем “OK”.
Проверяем выбранные объекты и нажимаем “OK”.
Еще раз проверяем какая сетевая группа добавлена и нажимаем “Далее”.
Если номер RDP-порта неизменялся, устанавливаем значение переключателя в “Разрешить подключение только к порту 3389”. Если порт был изменен, следует указать новое значение.
Кликаем “Готово”
На этапе подтверждения создания политики нажимаем кнопку “Закрыть”.
По окончании настройки окно будет выглядеть подобным образом.
Установим SSL-сертификат.
В том же окне “Диспетчер шлюза удаленных рабочих столов”, в левой окна кликаем по значку сервера, в основной части окна — “Просмотр и изменение свойств сертификата”.
В открывшемся окне “Свойства <имя_сервера>” переходим на вкладку “Сертификат SSL”. Устанавливаем переключатель “Создать самозаверяющий сертификат” и кликаем по кнопке “Создать и импортировать сертификат…”.
Хотя возможны еще 2 варианта:
- импорт ранее загруженного сертификата (самоподписанного ранее или стороннего);
- загрузка стороннего сертификата (например, Comodo) и его импорт;
В окне “Создание самозаверяющего сертификата” проверяем параметры и нажимаем кнопку “OK”.
Система уведомит, что сертификат был создан успешно. также присутствует информация, где можно найти сам файл сертификата. Нажимаем кнопку “OK”.
В окне свойств сервера, нажимаем кнопку “Применить”.
Самозаверенный сертификат установлен на TCP-порт 443 (SSL-порт по умолчанию).
Мы рекомендуем, в целях безопасности, изменить порт SSL, используемый по-умолчанию. Для этого, в основном меню окна, выбираем “Действия” → “Свойства”.
Переходим на вкладку “Параметры транспорта” и устанавливаем желаемое значение поля “HTTPS-порт”. Сохраняем параметры нажимая кнопку “Применить”.
Система запросит подтверждение — отвечаем ”Да”.
Выполним подключение через шлюз.
Открываем RDP-клиент, переходим на вкладку “Дополнительно” и нажимаем кнопку “Параметры”.
В открывшемся окне выбираем “Использовать следующие параметры сервера шлюза удаленных рабочих столов”. Указываем доменное имя сервера и через двоеточие (:) указываем SSL-порт. Метод входа — “Запрашивать пароль”. Нажимаем “OK”
Переходим на вкладку “Общие”. Указываем адрес компьютера и пользователя под которым будет выполняться подключение. Нажимаем кнопку “Подключить”
Программа запросит пароль от учетной записи.
Результаты работы шлюза можно проверить трассировкой — команда tracert.
Настройка доступа
После развертывания инфраструктуры ключей администратор получает доступ к веб-интерфейсу администрирования NGate, с помощью которого производится настройка криптошлюза, параметров мониторинга и управления.
Организация доступа пользователей не вызывает каких-либо затруднений, хотя и требует известной внимательности в ходе выполнения довольно значительного количества элементарных операций. Логика требуемых шагов применительно к небольшой организации и уж тем более, как в нашем случае, в тестовых целях может выглядеть несколько громоздкой и избыточной.
Итак, для настройки доступа пользователей к порталу потребуются следующие шаги:
- создание кластера. Все узлы NGate (криптошлюзы) в рамках системы управления должны быть объединены в кластеры. Кластер может включать в себя до 32 узлов;
- создание и настройка узлов внутри кластера;
- ввод лицензионных ключей. В ознакомительных целях КриптоПро предоставляет возможность бесплатного использования продукта в течение пробного периода длительностью три месяца с ограниченным числом подключений к шлюзу NGate. Для полноценного использования программного обеспечения NGate необходимо произвести активацию и ввести лицензионный ключа кластера и лицензионный ключ «КриптоПро CSP»;
- создание элемента серверного мандата. Серверный мандат состоит из сертификата сервера и закрытого ключа, которые публикуются на портале. Данный сертификат необходим для организации TLS-соединения между шлюзом NGate и клиентским устройством пользователя;
- настройка балансировщиков нагрузки (если предполагается их использование);
- создание конфигураций — логические элементы, описывающие параметры кластера, защищаемые шлюзом NGate ресурсы и права доступа к ним;
- создание порталов для каждой конфигурации — логические элементы, описывающие параметры групп защищаемых ресурсов, ресурсы и права доступа к ним;
- создание сетевых ресурсов: веб-ресурсов, динамических туннельных ресурсов, redirect-ресурсов;
- задание в конфигурации прав доступа к сетевым ресурсам (Access Control List) в зависимости от используемого метода аутентификации: на основе членства пользователей в группах LDAP, на основе информации в полях пользовательского сертификата, на основе ограничений по дате и времени;
- задание в конфигурации привязки прав доступа к защищаемым сетевым ресурсам, которая определяет, при выполнении каких правил доступа пользователь получит доступ к тому или иному ресурсу на портале;
- публикация конфигураций. В ходе этого процесса формируются и отправляются на узлы системы необходимые конфигурационные файлы. Далее производится проверка базовых параметров конфигурации и подготовка конфигурации к использованию. Если этот процесс завершится без сбоев, то система выполнит активацию конфигурации. В противном случае в интерфейсе системы управления будет отображено уведомление об ошибке, и текущая конфигурация останется без изменений.
Настройка роли
Запускаем «Диспетчер серверов», переходим на правой стороне во вкладку «Добавить роль»:
Для примера используем первый пункт:
Далее утилита попросит указать сервер, для которого производится выдача роли. Выбираем из списка, нажимаем «Next». На следующем этапе появится перечень доступных ролей для сервера. Для примера проставляем «Службу удаленных рабочих столов»:
После нажатия кнопки «Next» на экране отобразится информация о выбранной роли. Соглашаемся и переходим к следующему шагу. Теперь в разделе Role Server появилась добавленная функция. Заходим в нее и отмечаем опции, которые необходимы администратору. Для примера, активируем RDG:
Мастер настройки проверяет выбранную роль и совместимость с серверной ОС. Если необходима установка дополнительных компонентов, то автоматически откроется рабочая область с отмеченными компонентами. Чтобы RDG работал, в операционной системы должны быть установлены сервисы web-администрирования с полным набором программных инструментов:
Рекомендуется оставить по умолчанию выбранные сервисы. Нажимаем «Next», подтверждаем установку.
Обслуживание в ходе эксплуатации
Выше мы уже обращали внимание, что объем действий, который может потребоваться от администратора в процессе эксплуатации изделия, сравнительно невелик. Из их числа можно выделить следующие типовые сценарии.
Настройка параметров сетевых интерфейсов и доступа по SSH. Требуется при внесении каких-либо изменений в конфигурацию сети организации и может быть выполнена из веб-интерфейса системы управления NGate. Разрешение сетевого доступа к изделию по протоколу SSH рекомендуется к применению исключительно для диагностики, устранения неполадок и просмотра текущих настроек.
Рисунок 9. Настройка параметров сетевых интерфейсов КриптоПро NGate
Мониторинг расходования ресурсов и проверка состояния криптошлюза NGate. Обратиться к соответствующим функциям администратору, возможно, потребуется при необходимости выявления нештатных ситуаций в работе изделия, связанных с некорректным функционированием или снижением производительности (например, вследствие утечек памяти или сетевых ресурсов).
Для этого потребуется обеспечить локальный доступ к аппаратной платформе с помощью консольного терминала или монитора и клавиатуры, подключенных к коммуникационным портам COM и USB. В ходе мониторинга и проверки состояния администратор в консольном режиме получает возможность выполнять различные команды NGate, позволяющие производить диагностику неисправностей.
В штатном же режиме возможен мониторинг основных параметров устройства по протоколу SNMP.
Кроме того, с помощью различных консольных команд администратор может выполнять и другие рутинные операции (полный список доступных команд приведен в эксплуатационной документации на изделие):
- смена паролей администраторов (команды ngpasswd, ngwebpasswd);
- резервное копирование и восстановление конфигурации кластера (команда ng-backup);
- сбор диагностической информации о системе (команда ng-info);
- изменение имени устройства (файл /etc/hostname);
- обновление ПО NGate (команда ng-updater).
Установка сертификата ssl
Чтобы доступ через RDG был активен, также необходимо создать сертификат. В рабочем окне RDG Manager переходим к разделу «Имя сервера». Через контекстное меню открываем пункт «Просмотреть или изменить свойства сертификата». В открывшемся окне переключаемся на вкладку SSL. Доступно 3 варианта создания. Выбираем пункт, отмеченный красным на скриншоте:
Теперь прописываем имя сертификата и путь, по которому он будет храниться:
Нажимаем «ОК» для генерации. В итоге рабочая область менеджера выглядит следующим образом:
Для повышения уровня безопасности рекомендуется сменить порт по умолчанию для подключения через Remote Desktop Protocol. Открываем в RDG Manager раздел «Действия», пункт «Свойства». Переходим во вкладку «Свойства транспортировки». В поле, отмеченным красным, меняем значение:
Подтверждаем изменения, закрываем окно.
Выводы
Появление КриптоПро NGate на рынке средств криптографической защиты информации может расцениваться как естественная реакция на современные тенденции:
- централизация доступа пользователей к информационным ресурсам, потребность подключения к рабочему пространству из различных точек, включая дом, транспорт, места командировок и отдыха;
- в соответствии с повышением уровня мобильности сотрудников расширяется и номенклатура устройств, с помощью которых сотрудники получают доступ к корпоративным ресурсам: смартфоны, планшеты, ноутбуки;
- постоянное расширение круга лиц, которым необходимо предоставлять доступ к тем или иным категориям корпоративных ресурсов: партнеры, контрагенты, аутсорсинговые организации, внештатные сотрудники.
КриптоПро NGate позиционируется как продукт, полностью удовлетворяющий всем необходимым требованиям, предъявляемым к перспективным средствам защиты информации:
- соответствие действующему законодательству: КриптоПро NGate сертифицирован ФСБ России, включен в состав ряда «собственных» и «типовых» решений (в терминологии методических рекомендаций Банка России 4-МР от 14.02.2022) по линии ЕБС в качестве средства криптографической защиты биометрических персональных данных, передаваемых между подразделениями банка и центральным офисом, а также в качестве средства аутентификации граждан при получении банковских услуг; кроме того, продукт может использоваться в соответствии со своим непосредственным назначением для реализации технических защитных мер, предписанных законодательством в области ПДн, ГИС и КИИ;
- способность удовлетворить потребности государства и бизнеса: КриптоПро NGate служит для предоставления защищенного удаленного доступа пользователей к информационным ресурсам в коммерческих и государственных организациях, а также для предоставления по защищенному каналу электронных услуг (электронные торговые площадки, ДБО, сдача электронной отчетности и др.);
- способность удовлетворить ожидания лиц, непосредственно осуществляющих эксплуатацию продукта — пользователей и администраторов: КриптоПро NGate обеспечивает работу на различных устройствах, не требует сложных управляющих воздействий со стороны пользователя, позволяет работать как с помощью VPN-клиента, так и посредством веб-браузера; обладает высокими уровнями отказоустойчивости и масштабирования, возможностями гибкой настройки политик безопасности.
Преимущества
- Выполнение требований регуляторов, предъявляемых к средствам защиты информации данного типа.
- Единственный на рынке полноценный сертифицированный VPN-TLS шлюз, поддерживающий на клиентской стороне практически все ОС.
- Одновременная поддержка отечественных и зарубежных алгоритмов.
- Исключение необходимости встраивания криптопровайдера в прикладное программное обеспечение и как следствие — отсутствие необходимости проведения оценки влияния прикладной части на выполнение криптографических функций.
- Возможность функционирования в различных режимах в зависимости от решаемой задачи и поддержка множества методов аутентификации.
- Поддержка множества популярных клиентских платформ.
- Высокая производительность и масштабируемость решений, построенных на базе этого продукта.
Недостатки
- Нет поддержки VPN-IPSec, которая позволила бы применять КриптоПро NGate при организации защищенного взаимодействия между территориально распределенными площадками.
- Нет поддержки TLS 1.3.
- Как и в решениях других производителей, не реализован шифр «Кузнечик» из стандарта симметричного блочного шифрования ГОСТ Р 34.12-2022.
По сведениям, предоставленным представителями компании КриптоПро, планы реализации соответствующих доработок имеются, и в недалеком будущем потребители смогут воспользоваться усовершенствованной версией продукта, включающей эти возможности.
