Дружим Check Point и ГОСТовое шифрование / Хабр

Содержание

Выбор межсетевого экрана. обзор основных причин приобретения
Введение
: соиб. проектирование. сертифицированный защищенный удаленный доступ (remote vpn) часть 2
1. Настройка VPN с использованием сертификатов
2. Настройка VPN с использованием пароля
Архитерктура tls-криптошлюза
Аутентификация пользователей
Возможности tls-клиента
Общие сведения
Отказоустойчивость и масштабирование
Работа с криптоключами
Сертифицированные vpn
Требования фстэк к межсетевым экранам
Управление доступом удалённых пользователей

Выбор межсетевого экрана. обзор основных причин приобретения

Вначале нужно определиться с классом защиты. Это важно, поскольку иные интеграторы практикуют установку своим клиентам более дорогих решений, в том числе сертифицированных ФСБ, объясняя чрезмерную стоимость высоким уровнем защиты. На практике подавляющему большинству государственных организаций достаточно межсетевого экрана 4-го и 5-го классов защиты с сертификатом ФСТЭК (если, конечно, это не Администрация Президента, органы ФСБ или МВД).

Далее, следует определиться с типом. Наиболее подходящий для большинства государственных заведений — типы «А» и «Б», то есть межсетевые экраны, применяемые на физической и, соответственно, логической границе локальной сети. Межсетевые экраны типа «Б» могут иметь как программную, так и программно-аппаратную реализацию, в отличие от них тип тип «А» может быть только программно-аппаратным.

ПРОФИЛЬ ЗАЩИТЫ МЕЖСЕТЕВЫХ ЭКРАНОВ ТИПА «Б» ПЯТОГО КЛАССА ЗАЩИТЫ. ИТ.МЭ.Б5.ПЗ МЕТОДИЧЕСКИЙ ДОКУМЕНТ
ПРОФИЛЬ ЗАЩИТЫ МЕЖСЕТЕВЫХ ЭКРАНОВ ТИПА «А» ЧЕТВЕРТОГО КЛАССА ЗАЩИТЫ. ИТ.МЭ.А4.ПЗ МЕТОДИЧЕСКИЙ ДОКУМЕНТ

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

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

Как выбрать UTM-решение для защиты локальной компьютерной сети >>

Введение

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

Кроме того, ряд нормативных актов РФ в области информационной безопасности обязывает обеспечивать защищённый обмен сведениями определённого рода. В частности, если речь идёт о персональных данных, то основанный на одноимённом Федеральном законе №152-ФЗ приказ ФСТЭК России №21 обязывает охранять их от раскрытия, модификации и навязывания — ввода ложной информации — при передаче (или подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны, в том числе — беспроводным.

Схожие требования прописаны и в приказе ФСТЭК России №17, который касается обеспечения безопасности данных, содержащихся в государственных информационных системах. Также о защите каналов связи и об организации защищённого удалённого доступа говорится в нормативных актах, регламентирующих оборону критической информационной инфраструктуры, в частности — в приказах ФСТЭК России №239 и №31.

Чаще всего для организации защищённого канала связи создают виртуальную частную сеть (VPN) с использованием криптоалгоритмов ГОСТ. Для этого применяются криптошлюзы и клиентское программное обеспечение. Законодателями мод в этой нише стали такие разработчики, как «ИнфоТеКС», «Код Безопасности» и «С-Терра».

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

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

: соиб. проектирование. сертифицированный защищенный удаленный доступ (remote vpn) часть 2

По материалам блога http://sborisov.blogspot.ru/

В этот раз рассмотрим самый простой вариант Remote VPN КС1 и сравниваем – на сколько он сложнее чем вообще не сертифицированный Remote VPN

1. Операционные системы (смотреть таблицы в Приложении 1). Если мы посмотрим на статистику использования ОС и мобильных ОС можно сделать следующие вывод – примерно 13% наших пользователей с ноутбуками (с операционными системами Windows 8, OS X, Linux) останутся без Remote VPN. С мобильными устройствами совсем беда – есть решение только у одного вендора и только для iOS. То есть за бортом остается ощутимая часть сотрудников.

В не сертифицированном варианте покрытие ОС и технических средств почти 100%

Статистика по ОС тут и тут

2. В зависимости от решения по разному могут быть предъявлены требования к защите от влияния аппаратных компонентов технических средств на функционирование СКЗИ при защите ПДн.

Например, в варианте С-терра VPN Client (Приложение 2 – 9) для этого требуется проводить тематические исследования BIOS. Стоимость таких работ на порядок больше чем стоимость самого решения.

В варианте Stonegate VPN Client (Приложение 2 – 12) рекомендуется проводить исследования BIOS ещё и на технических средствах субъектов ПДн, данные которых обрабатываются у нас!! :O (кто мог такое придумать, это ж работа для исследователей BIOS на годы вперед обеспечена)

3. При подключении технического средства с СКЗИ к сетям связи общего доступа (а Remote VPN и предназначен для работы через такие подключения) требуется использовать сертифицированные средства межсетевого экранирования (Приложение 2 – 13 и Приложение 2 – 15). То есть либо использовать Remote VPN со встроенным МЭ либо применять дополнительный.

4. Для защиты среды в которой работает сертифицированное СКЗИ должны использоваться сертифицированные ФСТЭК и ФСБ средства антивирусной защиты из перечня (Касперский, Nod32, Dr. Web) (Приложение 2 – 16). Есть вероятность что придется менять наш любимый антивирус. Ещё и перечень ОС, под которыми работают сертифицированные антивирусы ограничен (см. соответствующие формуляры на антивирусы) и не позволяет нам использовать их на экзотических ОС (определенные Linux, Mac OS, iOS,)

5. При использовании для аутентификации пользователей Remote VPN сертификатов PKI (а именно такой вариант более надежен, по сравнению с паролями) необходимо использование Удостоверяющего центра, сертифицированного по классу криптографической защиты, не меньшему чем решение Remote VPN (Приложение 2 – 1) при этом для некоторых решений явно разрешено использование предопределенных ключей pre–shared key (Приложение 2 – 11)

6. Разворачивание в организации сертифицированного удостоверяющего центра, помимо приобретения лицензий, серверов, АРМ оператора, средств защиты от НСД, влечет за собой в том числе установку МЭ, сертифицированного ФСБ (Приложение 2 – 8).

Итого:

Использование внешнего сертифицированного УЦ увеличит стоимость решения примерно на 2000 руб. на пользователя ежегодно.

Использование собственного сертифицированного УЦ увеличит стоимость решения примерно на 2000 руб. на пользователя.

Использование имеющихся в организации несертифицированных УЦ (таких как Microsoft Active Directory Certificate Cervices) нелегитимно.

7. При использовании сертифицированного Remote VPN мы ограничены при определении срока действия сертификата пользователя. Мы обязаны менять его раз в год, а максимальный срок жизни не может превышать 1 год и 3 месяца. (Приложение 2 – 3 и Приложение 2 – 10). В случае с несертифицированным мы можем выбирать срок в соответствии с корпоративной политикой – например 3 года и соответственно уменьшить трудозатраты на эксплуатацию решения.

8. При хранении закрытых ключей или сертификатов пользователя на локальном диске или реестре (случай когда не применяются eToken) мы обязаны для технических средств (ноутбуков) принимать меры, аналогичные ключевым носителям (Приложение 2 – 3). А меры по защите ключевых носителей требуются немаленькие (смотреть содержание нормативных актов из Части 0), в том числе регистрировать их как носители, регистрировать помещения в которых на них работаем, обеспечивать отсутствие к ним доступа посторонних лиц, убирать во внерабочее время в сейф и т.п.

9. При использовании сертифицированных Remote VPN заброшено использование беспроводных каналов связи (Приложение 2-4 и Приложение 2-7). Скажите “нет” WiFi, 3G, 4G, bluetooth, NFC. Что остается мобильному пользователю с ноутбуком?

Так-же придется отключать беспроводные мышки и клавиатуры.

10. При использовании сертифицированного Remote VPN потребуется внедрить обязательные организационные меры, разработать и поддерживать порядка 17 документов (Приложение 3)

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

Организациям, внедряющим полностью легитимный сертифицированный Remote VPN надо учитывать, что его стоимость будет в разы превосходить стоимость несертифицированного аналога и использовать это при выборе контрмер и определении необходимости сертифицированного ФСБ Р решения.

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

PS: Наверное вам интересно, почему в названии статьи Remote VPN а не просто VPN? Ведь большинство пунктов справедливо для любого сертифицированного VPN решения.

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

Приложение 1.

ОС, поддерживаемые СКЗИ

СЗИ от НСД, которые необходимо использовать для классов больших чем КС1 ( для КС2-КС3)

Итоговая сводная таблица по клиентам Remote VPN (не шлюзам)

Приложение2.

Наиболее интересные ограничения и условия (прошу внимательно прочитать и проверить что у вас они соблюдаются):

1. Криптопро CSP 3.6.1 Формуляр ЖТЯИ.00050-03 30 01.

“1.2 Эксплуатация СКЗИ ЖТЯИ.00050-03 должна проводиться в соответствии с эксплуатационной документацией, предусмотренной настоящим Формуляром

1.4 При эксплуатации СКЗИ ЖТЯИ.00050-03 должны использоваться сертификаты открытых ключей, выпущенные Удостоверяющим центром, сертифицированным по классу защиты не ниже класса защиты используемого СКЗИ.”

2. Криптопро CSP 3.6.1 Формуляр ЖТЯИ.00050-03 30 01.

“1.5 При встраивании СКЗИ ЖТЯИ.00050-03 в прикладные системы необходимо проводить оценку влияния аппаратных, программно-аппаратных и программных средств сети (системы) конфиденциальной связи, совместно с которыми предполагается штатное функционирование СКЗИ, на выполнение предъявленных к СКЗИ требований:

– для исполнения 3 (класс защиты КС3) – во всех случаях;

– для исполнений 1 (класс защиты КС1) и 2 (класс защиты КС2) – в следующих случаях:

1) если информация, обрабатываемая СКЗИ, подлежит защите в соответствии с законодательством Российской Федерации;

2) при организации защиты информации, обрабатываемой СКЗИ, в федеральных органах исполнительной власти, органах исполнительной власти субъектов Российской Федерации;”

Про сертификаты: Генератор шума гш 2500м что это

3. Криптопро CSP 3.6.1 Формуляр ЖТЯИ.00050-03 30 01.

“7.8 При эксплуатации СКЗИ ЖТЯИ.00050-03 должны соблюдаться следующие сроки использования пользовательских закрытых ключей и сертификатов: максимальный срок действия закрытого ключа ЭП (ключа ЭП) – 1 год 3 месяца;

Допускается хранение закрытых ключей на HDD ПЭВМ (в реестре ОС Windows, в разделе HDD при работе под управлением других ОС) при условии распространения на HDD или на ПЭВМ с HDD требований по обращению с ключевыми носителями.”

4. Криптопро CSP 3.6.1 Руководство администратора. Часть 16. ЖТЯИ.00050-03 90 02

“16. Должна быть запрещена работа СКЗИ при включенных в ПЭВМ штатных средствах выхода в радиоканал

20. ЗАПРЕЩАЕТСЯ использование беспроводных клавиатур и компьютерных мышей”

5. Криптопро CSP 3.6.1 Руководство администратора. Часть 16. ЖТЯИ.00050-03 90 02

“17. При функционировании исполнения 2 СКЗИ в программно-аппаратных средах Windows XP/2003 , ОС Solaris 9/10 (sparc, ia32, x64) инициализация ПДСЧ должна производиться с использованием внешней гаммы.”

6. Криптопро CSP 3.6.1 Руководство администратора безопасности. Использование СКЗИ под управлением ОС iOS. ЖТЯИ.00050-03 90 02-07

“2. Для операционной системы iOS КриптоПро CSP не поставляется в виде конечного приложения. КриптоПро CSP для iOS представляет собой фреймворк для разработки, который содержит в себе объектный файл, реализующий функции CSP, ресурсы и заголовочные файлы. Фреймворк не имеет механизма самостоятельной установки в операционную систему. Установка осуществляется в составе прикладной программы, разработанной на основе фреймворка теми средствами, которые предлагает разработчик прикладной программы.

7. Криптопро CSP 3.6.1 Руководство администратора безопасности. Использование СКЗИ под управлением ОС iOS. ЖТЯИ.00050-03 90 02-07

10. Ежесуточная перезагрузка ПЭВМ.

15. Должна быть запрещена работа СКЗИ при включенных в ПЭВМ штатных средствах выхода в радиоканал.”

8. КриптоПро УЦ. Формуляр. ЖТЯИ.00067-02 30 01.

“3. Межсетевой экран должен быть сертифицирован ФСБ России на соответствие требованиям к устройствам типа межсетевой экран по 4 классу защищенности. Не входит в комплект поставки, поставляется по согласованию с заказчиком.”

9. С-терра CSP VPN Client 3.11 Правила пользования РЛКЕ.00005-02 90 02.

“4.5…. Для всех исполнений СКЗИ для исключения возможности влияния аппаратных компонентов СФК на функционирование СКЗИ должны быть выполнены следующие требования:

в случае обработки информации, подлежащей обязательной защите в соответствии с законодательством Российской Федерации, необходимо проводить исследования ПО BIOS СВТ, на котором установлен ПК “CSP VPN Gate”, на соответствие требованиям “Временных методических рекомендаций к проведению исследований программного обеспечения BIOS по документированным возможностям”

10. С-терра CSP VPN Client 3.11 Правила пользования РЛКЕ.00005-02 90 02.

“4.7 Требования к обращению с ключевыми документами

Требования к ключам регламентируются документом «Руководство администратора безопасности» КриптоПро CSP, согласно которому срок действия открытых и закрытых ключей шифрования – 1 год 3 месяца.”

11. StoneGate Firewall/ VPN Client 5. Программный комплекс криптографической защиты «StoneGate Firewall/VPN» версия 5 ПРАВИЛА ПОЛЬЗОВАНИЯ 89625543.4012-001 90 02

“6. …. Аутентификация пользователей при обращении к шлюзу StoneGate Firewall/VPN возможна с использованием метода аутентификации на основе сертификатов. Возможна комбинация методов аутентификации по сертификатам c другими методами для предоставления пользователю доступа к функциям системы.

Аутентификация абонентов при взаимодействии шлюза StoneGate Firewall/VPN с другими шлюзами возможна с использованием методов аутентификации на основе сертификатов и на основе предварительно распределяемых ключей. При использовании метода аутентификации на основе предварительно распределяемых ключей каждая пара шлюзов должна иметь уникальный ключ длиной 256 бит (при использовании для генерирования и распределения ключей для шлюзов StoneGate Firewall/VPN функций системы управления SMC это требование выполняется автоматически)

При использовании для аутентификации абонентов сертификатов, требования к аутентификации аналогичны предъявляемым при функционировании соответствующих используемых в комплексе StoneGate Firewall/VPN исполнений СКЗИ «КриптоПро CSP 3.6.1». При использовании иных методов аутентификации требования к аутентификации определяются настоящими Правилами.

12. StoneGate Firewall/ VPN Client 5. Программный комплекс криптографической защиты «StoneGate Firewall/VPN» версия 5 ПРАВИЛА ПОЛЬЗОВАНИЯ 89625543.4012-001 90 02

“6. Если с помощью StoneGate Firewall/VPN обрабатывается информация, подлежащая обязательной защите в соответствии с законодательством Российской Федерации, должно быть обеспечено соответствие ПО BIOS СВТ оператора такой информации (включая оператора персональных данных), на котором установлены компоненты комплекса, «Временным методическим рекомендациям к проведению исследований программного обеспечения BIOS по документированным возможностям». Проверка соответствия ПО BIOS СВТ субъекта данных (например, субъекта персональных данных) не требуется, но рекомендуется”

13. StoneGate Firewall/ VPN Client 5. Программный комплекс криптографической защиты «StoneGate Firewall/VPN» версия 5 ПРАВИЛА ПОЛЬЗОВАНИЯ 89625543.4012-001 90 02

“6.1 …

– при использовании СКЗИ на ПЭВМ, подключенных к общедоступным сетям связи, с целью исключения возможности несанкционированного доступа к системным ресурсам используемых операционных систем, к программному обеспечению, в окружении которого функционируют СКЗИ, и к компонентам СКЗИ со стороны указанных сетей должны использоваться дополнительные методы и средства защиты (межсетевые экраны). При этом возможно задействовать функции разграничения сетевого доступа шлюза StoneGate Firewall/VPN (данный функционал имеет сертификат ФСТЭК);”

14. Криптопро CSP 3.6.1 Руководство администратора. Часть 16. ЖТЯИ.00050-03 90 02

“15…. при использовании СКЗИ на ПЭВМ, подключенных к общедоступным сетям связи, с целью исключения возможности несанкционированного доступа к системным ресурсам используемых операционных систем, к программному обеспечению, в окружении которого функционируют СКЗИ, и к компонентам СКЗИ со стороны указанных сетей, должны использоваться дополнительные методы и средства защиты (например: установка межсетевых экранов, организация VPN сетей и т.п.). При этом предпочтение должно отдаваться средствам защиты, имеющим сертификат уполномоченного органа по сертификации.”

15. МАРШ!

В настоящее время производитель устанавливает на МАРШ! только Linux. Идет тестирование Windows Embeded. Если МАРШ! будет поставляться в составе с Windows, то условия формуляра позволяют использовать такой вариант для класса КС2

16. Криптопро CSP 3.6.1 Формуляр ЖТЯИ.00050-03 30 01.

“2. При эксплуатации СКЗИ ЖТЯИ.00050-03 должны выполняться следующие требования:

…4. СКЗИ должно использоваться со средствами антивирусной защиты. Класс антивирусных средств защиты определяется условиями эксплуатации СКЗИ в автоматизированных системах”

Криптопро CSP 3.6.1 Руководство администратора. Часть 16. ЖТЯИ.00050-03 90 02

“13….Программное обеспечение СКЗИ ЖТЯИ.00050-03 должно использоваться со средствами антивирусной защиты, сертифицированными ФСТЭК и ФСБ России:

Антивирус Касперского

Антивирус Dr.Web

Антивирус NOD32.”

Приложение 3.

Типовой комплект документов при использовании сертифицированных СКЗИ для защиты ПДн (ссылки на пункты типовых требований149/6/6-622 ФСБ России по защите ПДн, которые в свою очередь скопированы из приказа 152 ФАПСИ):

· заключение о возможности эксплуатации криптосредств (п. 2.3);

· журнал учета используемых криптосредств (п. 3.4);

· журнал учета технической документации к криптосредствам (п. 3.4);

· приказ о назначении лиц (пользователей криптосредств), допущенных к работе с криптосредствами (п. 2.3);

· документ, устанавливающего порядок обеспечения безопасности ПДн при помощи криптосредств (п. 1.3);

· документ, устанавливающего порядок организации контроля за соблюдением условий использования криптосредств (п. 2.3);

· приказ о назначении ответственного пользователя криптосредств (п. 2.6);

· описание функциональных обязанностей ответственного пользователя криптосредств (п. 2.7);

· лицевые счета на пользователей криптосредств (п. 3.5);

· технический (аппаратный) журнал регистрации разовых ключевых носителей (п. 3.6);

· приказ о назначении комиссии по уничтожению ключевых документов (п. 3.22);

· документ, устанавливающий требования к режимным помещениям, в которых эксплуатируются криптосредства (п. 4.1);

· журнал учета хранилищ (п. 4.5);

· журнал проверок исправности сигнализации (п. 4.7);

· журнал учета ключей от хранилищ ключевых документов и технической документации (п. 4.8);

· журнал службы охраны (п. 4.9).

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

1. Настройка VPN с использованием сертификатов

Для настройки ГОСТового шифрования с аутентификацией партнеров по сертификатам необходимо выполнить следующую последовательность действий:

1) Установить специальную версию Check Point SmartConsole (файл с именем: SmartConsole_GOST_R75.40VS_EA);

2) Зайти на сервер управления с помощью данной утилиты;

3) Создать новое VPN Community:

4) Поместить в создаваемое VPN Community шлюзы, между которыми будет строиться VPN соединение:

5) Настроить VPN Community на использование ГОСТового шифрования:

Предлагается 3 варианта:

Set 1 и Set 2- отличающихся используемыми режимами шифрования, можно использовать любой (поддерживаются всеми версиями, для которых есть ГОСТ, кроме R65.50);

Legacy – режим совместимости с ГОСТ на Check Point R65.50, если есть необходимость построения VPN туннелей со шлюзами, функционирующими на данной версии Check Point.

6) Нажать кнопку «ОК», тем самым создав новое VPN Community;

Список VPN Community будет выглядеть примерно вот так:

7) После создания VPN Community и добавления в него шлюзов, необходимо внести в конфигурацию сервера управления сведения о ГОСТовом центре сертификации, который будет выпускать сертификаты для наших шлюзов. Добавьте в конфигурацию новый доверенный центр сертификации:

8) В случае если CRL Distribution Point (в примере это сервер центра сертификации) находится за одним из шлюзов и другие шлюзы будут соединяться с ним через VPN-соединение, эти шлюзы не смогут загрузить CRL, потому что не смогут построить VPN из-за невозможности проверки сертификата первого шлюза.

Или можно вынести CRL Distribution Point за пределы VPN домена защищающего его шлюза, что бы другие шлюзы обращались к нему не через VPN соединение.

9) Выгрузите корневой сертификат центра сертификации в формате DER и добавьте его в конфигурацию Check Point:

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

В случае кластера шлюзов сертификаты выпускаются на КАЖДЫЙ член кластера. Для выпуска сертификата выполните следующую последовательность действий:

• Откройте окно свойств объекта кластера шлюзов;

• Перейдите во вкладку «Cluster Members»;

• Щелкните два раза по объекту члена кластера;

• В открывшемся окне «Cluster Member Properties» перейдите во вкладку «VPN» и в поле «Certificates List with keys stored on Security Gateway» нажмите кнопку «Add»:

• Введите имя сертификата;

• В поле «CA to enroll from» выберете добавленный ГОСТовый центр сертификации и нажмите кнопку Generate;

• Заполните Distinguished Name для запроса, например:

• Будет сгенерирован запрос на сертификат, нажмите «Copy to Clipboard»:

• Вставьте запрос на сертификат в поле «Сохраненный запрос» на портале центра сертификации и нажмите выдать:

• Сохраните файл сертификата в формате DER:

• В поле «Certificates List with keys stored on Security Gateway» нажмите кнопку «Complete», в открывшемся окне выберете сохраненный файл сертификата:

• Примите сертификат:

• Повторите данную последовательность действий для каждого члена кластера.

В случае выпуска сертификата для некластерированного шлюза запрос на сертификат создается в окне свойств шлюза, раздел «IPSec VPN», графа «Repository of Certificates Available to the Gateway». Также нажмите клавишу «Add», только в случае некластерированного шлюза будет выбор, где будут храниться ключи шифрования.

После добавления сертификатов некластерированный шлюз уже готов к построению ГОСТового VPN после установки политики, но в случае кластера это еще не все. КриптоПро шифрует трафик, передаваемый между членами кластера и между библиотеками на шлюзе, используя для этого Site Key или Site Certificate.

Про сертификаты: Оптический кабель компании Алтай Кабель. Купить со склада в Москве и Спб, низкая цена

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

11) Для генерации Site Key необходимо выполнить следующую последовательность действий:

• Открыть окно свойств объекта шлюза, в разделе «IPSec VPN» в графе «Repository of Certificates Available to the Gateway» выбрать сертификат, выданный шлюзу внутренним центром сертификации (Check Point internal_ca), и нажать кнопку «View»;

• В открывшемся окне свойств сертификата необходимо найти первую строчку с SHA-1 хешем сертификата, она понадобится для генерации Site Key;

• На любом шлюзе с установленным КриптоПро из экспертного режима необходимо выполнить команду:

bash /opt/cprocsp/bin/ia32/cp-genpsk.sh <machine_name> <net_id> <expiry> <Site_ID>

, где:

o	<machine_name> - имя шлюза;

o	<net_id> - неописанный, но обязательный параметр, должно стоять Net, причем, если вставить параметр Net с прописной буквы, вывод команды будет корректным, но сгенерированный Site Key работать НЕ БУДЕТ;

o	<expiry> - срок действия ключа в месяцах, максимальное значение 6;

o	<Site_ID> - первая срока с SHA-1 хешем сертификата.

Пример выполнения и вывода команды:

[Expert@FW1-Node-1:0]# bash /opt/cprocsp/bin/ia32/cp-genpsk.sh FW1-Cluster Net 6 32:56:3E:12:A8:D6:6C:EF:47:23:30:7C:17:53:ED:47:1E:BD:7F:7DgenpskUTC Wed Jun 26 12:15:53 2021

FW1-Cluster. Net. Number of stations 1.Stations: 32563E12A8D66CEF4723307C1753ED471EBD7F7DPart 0. Valid for (months) 6.

FW1-Cluster UTC Wed Jun 26 12:15:53 202132563E12A8D66CEF4723307C1753ED471EBD7F7D part 0 valid for (months) 6W6426WLHP3C8TMW6426WLHP3C8TMW6426WLHP3C8TM

genpskUTC Wed Jun 26 12:15:53 2021

FW1-Cluster. Net. Number of stations 1.Stations: 32563E12A8D66CEF4723307C1753ED471EBD7F7DPart 1. Valid for (months) 6.

FW1-Cluster UTC Wed Jun 26 12:15:53 202132563E12A8D66CEF4723307C1753ED471EBD7F7D part 1 valid for (months) 641NKET2QC6B3NW41NKET2QC6B3NW41NKET2QC6B3NW

• Вывод команды содержит две части сгенерированного Site Key, которые нужно совместить и внести в конфигурацию кластера. Первая часть помечена зеленым, вторая часть помечена красным. Совмещать их нужно так:

W6426WLHP3C8TM41NKET2QC6B3NW

Site Key должен быть повторно сгенирирован в следующих случаях:

• Истек срок действия Site Key;• VPN был включен и выключен;• Сертификат выданный внутренним центром сертификации (internal_ca) был обновлен.

• После того как у вас появился Site Key, его необходимо внести в конфигурацию кластера. Откройте окно свойств объекта кластера, раздел «IPSec VPN», графа «VPN Advanced» и нажмите кнопку «Pre-Shared Secret» в разделе «GOST Standard»:

• В открывшемся окне введите Site Key и нажмите ОК:

12) Теперь можно установить политики на шлюзы и проверить логи на предмет того, что VPN успешно собрался. В логах должны присутствовать сообщения об успешной установке Site Key или Site Certificate и инициализации криптобиблиотек и сообщения типов Encrypt/Decrypt для трафика, передаваемого через VPN соединение. Примеры сообщений:

13) Если политика установилась без ошибок и данные сообщения в логах присутствуют, то поздравляю вас, вам успешно удалось настроить VPN с использованием ГОСТового шифрования.

2. Настройка VPN с использованием пароля

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

1) Установить специальную версию Check Point SmartConsole (файл с именем: SmartConsole_GOST_R75.40VS_EA);

2) Зайти на сервер управления с помощью данной утилиты;

3) Создать новое VPN Community:

4) Поместить в создаваемое VPN Community шлюзы, между которыми будет строиться VPN соединение:

5) Настроить VPN Community на использование ГОСТового шифрования:

Предлагается 3 варианта:

6) Установить в настройках VPN Community использование пароля для аутентификации. Делается это в свойствах VPN Community в разделе «Advanced Settings», пункт «Shared Secret»:

7) Нажать кнопку «ОК», тем самым создав новое VPN Community;

Список VPN Community будет выглядеть примерно вот так:

8) Сгенерировать Site Key для КАЖДОГО шлюза, как это прописано в разделе 5.1 пункт 11. В случае кластера шлюзов генерируется один Site Key на кластер. Если у вас на некластеризованном шлюзе есть установленный ГОСТовый сертификат, то Site Key для этого шлюза можно не генерировать.

9) После генерации и установки Site Key, необходимо сгенерировать пароль для пары шлюзов. В отличие от «традиционной» настройки VPN на Check Point при настройке ГОСТового VPN нельзя использовать произвольный пароль, его нужно сгенерировать по аналогии с Site Key. Чтобы сгенерировать пароль для пары шлюзов, выполните следующую последовательность действий:

• На любом шлюзе с установленным КриптоПро из экспертного режима необходимо выполнить команду:

bash /opt/cprocsp/bin/ia32/cp-genpsk.sh <pair_name> <net_id> <expiry> <GW_1_Site_ID> <GW_2_Site_ID>

, где:

o	<pair_name> - имя пары шлюзов;

o	<net_id> - неописанный но обязательный параметр, должно стоять Net, причем если вставить параметр Net с прописной буквы вывод команды будет корректным, но сгенерированный пароль работать НЕ БУДЕТ;

o	<expiry> - срок действия ключа в месяцах, максимальное значение 6;

o	<GW_1_Site_ID> - первая срока с SHA-1 хешем сертификата первого шлюза пары;

o	<GW_2_Site_ID> - первая срока с SHA-1 хешем сертификата второго шлюза пары.

Какой-либо принципиальной разницы в том, какой шлюз первый, а какой второй –нет, поле <pair_name> можно заполнить произвольно.

Пример выполнения и вывода команды:

Expert@FW1-Node-1:0]# bash /opt/cprocsp/bin/ia32/cp-genpsk.sh FW1-FW2 Net 6 32:56:3E:12:A8:D6:6C:EF:47:23:30:7C:17:53:ED:47:1E:BD:7F:7D A6:F0:24:9A:16:AA:7F:42:9A:3A:A2:83:66:FA:67:E9:75:08:46:1BgenpskUTC Sat Jun 29 11:17:26 2021

FW1-FW2. Net. Number of stations 2.Stations: 32563E12A8D66CEF4723307C1753ED471EBD7F7D A6F0249A16AA7F429A3AA28366FA67E97508461BPart 0. Valid for (months) 6.

FW1-FW2 UTC Sat Jun 29 11:17:26 202132563E12A8D66CEF4723307C1753ED471EBD7F7D part 0 valid for (months) 6BC1HGFATY4N6QMBC1HGFATY4N6QMBC1HGFATY4N6QM

FW1-FW2 UTC Sat Jun 29 11:17:26 2021A6F0249A16AA7F429A3AA28366FA67E97508461B part 0 valid for (months) 6ZPYLCHU36QNZNMZPYLCHU36QNZNMZPYLCHU36QNZNM

genpskUTC Sat Jun 29 11:17:26 2021

FW1-FW2. Net. Number of stations 2.Stations: 32563E12A8D66CEF4723307C1753ED471EBD7F7D A6F0249A16AA7F429A3AA28366FA67E97508461BPart 1. Valid for (months) 6.

FW1-FW2 UTC Sat Jun 29 11:17:26 202132563E12A8D66CEF4723307C1753ED471EBD7F7D part 1 valid for (months) 6WKDHN8MRYD599UWKDHN8MRYD599UWKDHN8MRYD599U

FW1-FW2 UTC Sat Jun 29 11:17:26 2021A6F0249A16AA7F429A3AA28366FA67E97508461B part 1 valid for (months) 6FN4T4X8Z5YRT0UFN4T4X8Z5YRT0UFN4T4X8Z5YRT0U

• Вывод команды содержит четыре части сгенерированного пароля, которые нужно совместить и внести в конфигурацию. Первая часть помечена зеленым, вторая часть помечена красным, третья честь помечена синим, четвертая – оранжевым, но совмещаются они, в отличие от Site Key, не по порядку, а так: часть 1 часть 3 часть 2 часть 4, пример совмещения частей:

BC1HGFATY4N6QMWKDHN8MRYD599UZPYLCHU36QNZNMFN4T4X8Z5YRT0U

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

• Истек срок действия пароля;• VPN был включен и выключен;• Сертификат выданный внутренним центром сертификации (internal_ca) был обновлен.

10) После того как у вас появился пароль, его необходимо внести в конфигурацию. Откройте окно свойств шлюза, раздел «IPSec VPN», нажмите кнопку «Traditional mode configuration», установите флажок «Pre- Shared Secret»:

11) Нажмите кнопку «Edit Secrets», введите сгенерированный ключ для другого члена пары шлюзов и нажмите «ОК»:

12) Если у вас есть шлюзы, находящиеся под управлением других серверов управления, как в примере, повторите операцию добавления ключа на них;

13) Теперь можно установить политики на шлюзы и проверить логи на предмет того, что VPN успешно собрался. В логах должны присутствовать сообщения об успешной установке Site Key или Site Certificate и инициализации криптобиблиотек и сообщения типов Encrypt/Decrypt для трафика, передаваемого через VPN соединение.

14) Если политика установилась без ошибок и данные сообщения в логах присутствуют, то поздравляю вас, вам успешно удалось настроить VPN с использованием ГОСТового шифрования.

Архитерктура tls-криптошлюза

Критерий сравнения	КриптоПро NGate	ViPNet TLS Gateway	Континент TLS	С-Терра TLS
Вид поставки	Программно-аппаратный комплекс, виртуальная машина	Программно-аппаратный комплекс, виртуальная машина	Программно-аппаратный комплекс	Программно-аппаратный комплекс, виртуальная машина
Архитектура системы	Серверная и клиентская части, центр управления сетью	Серверная и клиентская части	Серверная и клиентская части	Серверная и клиентская части
Совместимость со средами виртуализации	Microsoft Hyper-V 8 / 8.1 / 10 / 2008 / 2008R2 / 2021 / 2021R2 / 2021, VMware Workstation 11—15, VMware vSphere ESXi 5.5—6.7, Virtual Box 3.2—5.2, Xen 7.1—7.6	Oracle VM VirtualBox 5.0 / 5.1 / 5.2, VMware vSphere ESXi 6.0 / 6.5 / 6.7, VMware Workstation 14 / 15, KVM	Совместим только тестовый дистрибутив	VMware ESXi, Workstation, Citrix XenServer, Microsoft Hyper-V, KVM
Сетевые интерфейсы младшей модели	Модель NGate 300: 4×10/100/1000BASE-T RJ45	Модель TLS 500: 4×10/100/1000BASE-T RJ45	Модель IPC-50: 4х10/100/1000 BASE-T RJ45, 1x1GB SFP	Модель «С-Терра TLS 100»: 3х10/100/1000BASE-T RJ45
Сетевые интерфейсы старшей модели	Модель NGate 3000: 4х10/100/1000BASE-T RJ45, 4x10GB SFP	Модель TLS 5000: 4×10/100/1000BASE-T RJ45, 4x10G SFP	Модель IPC-3000: 1х10/100/1000BASE-T RJ45, 4x10GB SFP	Модель «С-Терра TLS 7000»: 4×10/100/1000BASE-T RJ45, 4x10G SFP

Аутентификация пользователей

Критерий сравнения	КриптоПро NGate 1.0	ViPNet TLS Gateway 1.5	Континент TLS 2.1	С-Терра TLS
Аутентификация удалённых пользователей и администратора на основе технологии открытых ключей (X.509 v.3)	Да	Да	Да	Да
Разграничение доступа к защищаемым ресурсам на основе полей сертификата, вплоть до OU (Organization Unit)	Да	Да	Да	Да
Аутентификация пользователей в Active Directory с помощью протокола LDAP с использованием сертификатов, записанных в LDAP (MS AD)	Да	Да	Да	Нет
Аутентификация пользователей в Active Directory с помощью протокола LDAP с использованием логина и пароля	Да	Да	Да	Нет
Аутентификация пользователей по локальной базе данных	Да	Нет, в разработке	Да	Да
Возможность разрешения, запрещения, ограничения использования веб-приложений клиентом на основе политик	Да	Да	Да	Нет
Проверка сертификатов ключей по спискам отозванных сертификатов (CRL)	Да	Да	Да	Да
Поддержка аутентификации по UPN-сертификату	Да	Нет, в разработке	Да	Нет
Перечень поддерживаемых идентификаторов	«Рутокен», eToken, JaCarta, ESMART	ESMART Token, Infotecs Software Token, aKey, ViPNet HSM, JaCarta, «Рутокен», «Рутокен S», R301 Foros, SafeNet eToken (eToken Aladdin)	USB флеш-накопители / USB-ключи: «Рутокен Lite», «Рутокен S», «Рутокен ЭЦП 2.0 Flash», JaCarta PKI, JaCarta ГОСТ, JaCarta 2 ГОСТ, JaCarta PKI / ГОСТ, eToken PRO (Java), Esmart USB Token, Esmart USB Token ГОСТ; смарт-карты: «Рутокен ЭЦП», «Рутокен Lite», JaCarta PKI, JaCarta ГОСТ, eToken PRO (Java), eToken PRO, Esmart, Esmart ГОСТ; идентификаторы: DS1995, DS1996	eToken Java 72К, JaCarta PKI, JaCarta PKI / ГОСТ, «Рутокен Lite», «Рутокен ЭЦП», «Рутокен ЭЦП 2.0»
Режим работы без аутентификации пользователя	Да, в режиме TLS Offload	Да, в режиме одностороннего TLS	Да	Да, в режиме одностороннего TLS

Возможности tls-клиента

Критерий сравнения		КриптоПро NGate	ViPNet TLS Gateway	Континент TLS	С-Терра TLS
Перечень поддерживаемых ОС для собственных TLS-клиентов	Microsoft Windows	7 / 8 / 8.1 / 10 / Server 2003 / Server 2008 / Server 2008 R2 / Server 2021 / Server 2021R2 / Server 2021	7 / 8.1 / 10 / Server 2008R2 / Server 2021 / Server 2021R2 / Server 2021 / Server 2021	7 / 8.1 / 10; серверные версии, начиная с Server 2021, будут доступны в ближайшем обновлении (версия 2.2)	10
	Linux	CentOS 7, Red OS, Fedora, Oracle Linux 7, SUSE Linux Enterprise Server 12, ОpenSUSE 13.2, RHEL 7, Ubuntu 14 / 16 / 17 / 18, Linux Mint 13 / 14 / 15 / 16 / 17 / 18, Debian 7 / 8 / 9, Astra Linux Special Edition, Common Edition, ALT Linux 7, «Альт 8 СП», ROSA 2021, РОСА «ХРОМ» / «КОБАЛЬТ» / «НИКЕЛЬ», ThinLinux	«Альт 8 СП “Рабочая станция”», «Альт Линукс СПТ 7.0», «РЕД ОС 7.1 “МУРОМ”», Astra Linux Common Edition 2.12, Astra Linux Special Edition 1.5 / 1.6, Debian 7.11 / 8.11 / 9.8, Ubuntu 14.04 LTS / 16.04 LTS, Ubuntu Server 16.04 LTS	Нет, будет доступно в ближайшем обновлении (версия 2.2)	Debian 9 / 10, Astra Linux Special Edition 1.6
	Apple macOS	Mac OS X 10.9 / 10.10 / 10.11 / 10.12 / 10.13 / 10.14	Mac OS X 10.10 и выше	Нет	Нет
	Мобильные ОС	Android, iOS	«Аврора» (встроенными средствами самой ОС); в разработке: Android, iOS	Нет, в разработке (Android, iOS, «Аврора»)	Android, iOS
Поддерживаемые браузеры		Любые соблюдающие спецификацию TLS	Любые соблюдающие спецификацию TLS	Любые соблюдающие спецификацию TLS	«Спутник», Chromium c поддержкой ГОСТ
Собственный TLS-клиент		Да	Да	Да	Да
Наличие бесплатного TLS-клиента		Да	Да	Да	Да
Возможность использования защищённых ключевых носителей в клиентском ПО		Да	Да	Да	Да
Поддержка мобильных устройств		Да	Да	Да	Да
Возможность подключения без TLS-клиента		Да	Да, через браузер	Нет	Да, через браузер

Про сертификаты: Зачем нужны сертифицированные средства защиты информации? / Хабр

Общие сведения

Критерий сравнения	КриптоПро NGate	ViPNet TLS Gateway	Континент TLS	С-Терра TLS
Компания-вендор	ООО «КРИПТО-ПРО»	ОАО «ИнфоТеКС»	ООО «Код Безопасности»	ООО «С-Терра СиЭсПи»
Целевой сегмент	Крупный и средний бизнес, государственный сектор	Крупный и средний бизнес, государственный сектор	Крупный и средний бизнес, государственный сектор	Крупный и средний бизнес, государственный сектор
Штаб-квартира	Россия (Москва)	Россия (Москва)	Россия (Москва)	Россия (Москва)
Официальный сайт вендора	cryptopro.ru	infotecs.ru	securitycode.ru	s-terra.ru
Наличие в реестре отечественного ПО	Да	Да	Да	Нет, планируется
Сертификаты соответствия	Сертификаты ФСБ России №СФ/124-3631 до 01.01.2022, класс КС3; №СФ/124-3630 до 01.01.2022, класс КС2; №СФ/124-3630 до 01.01.2022, класс КС1. Сертифицированы как серверная, так и клиентская части (в т. ч. для iOS и Android)	Сертификаты ФСБ России №СФ/124-3676 до 12.04.2022, классы КС1 и КС3, для шлюза; №СФ/124-3411 до 20.06.2021, классы КС1, КС2, КС3, для ViPNet PKI Client (Windows); №СФ/124-3576 до 25.12.2021, класс КС3, для ViPNet PKI Client (Linux)	Сертификаты ФСБ России №СФ/124-3549 до 10.06.2020, классы КС1 и КС2, для «Континент TLS Клиент»; №СФ/124-3548 до 10.06.2020, класс КС2, для «Континент TLS Сервер»; сертификат ФСТЭК России №3286 по 4 уровню контроля НДВ для «Континент TLS Сервер»	Планируются сертификаты ФСБ России, классы КС1 и КС2, для шлюза и клиента (конец 2020 года)
Модельный ряд	NGate ЦУС 100, NGate 300, NGate 600, NGate 1000, NGate 1500, NGate 2000, NGate 3000	TLS VA, TLS 500, TLS 1000, TLS 5000	IPC-50, IPC-500, IPC-1000, IPC-3000	TLS-100, TLS-2000, TLS-3000, TLS-7000, TLS-V
Сравниваемые версии	1.0	1.5	2.1	4.3
Языки интерфейса	Русский и английский, возможно добавление любого языка	Русский	Русский	Русский
Принцип лицензирования	ПАК или виртуальное исполнение. Лицензия на количество одновременных подключений. Лицензия на ЦУС	ПАК или виртуальное исполнение. Лицензия на количество одновременных подключений	ПАК. Лицензия на количество одновременных подключений	ПАК или виртуальное исполнение. Лицензия на количество одновременных подключений
Техническая поддержка производителя	5 видов технической поддержки (ПО — базовая, расширенная, круглосуточная; АО — базовое и расширенное обслуживание)	5 видов технической поддержки	4 вида технической поддержки	2 вида технической поддержки (первый год стандартного уровня — бесплатно)
Гарантия производителя	Техническая поддержка гарантирует замену оборудования в любой год эксплуатации вплоть до 5 лет	1 год	1 год, расширенная — 2 года и 7 дней	3 года на аппаратную платформу

Отказоустойчивость и масштабирование

Критерий сравнения	КриптоПро NGate	ViPNet TLS Gateway	Континент TLS	С-Терра TLS
Возможность «холодного» резервирования аппаратной платформы TLS-криптошлюза	Да	Да	Да	Да
Возможность полноценной кластеризации в режиме Active-Active с синхронизацией сессий	Да	Нет, в разработке	Нет	Нет
Возможность масштабирования TLS-криптошлюза посредством подключения в кластер новых нод шлюзов с синхронизацией сессий	Да, до 32 нод	Нет, в разработке	Да, неограниченное линейное масштабирование	Нет
Возможность автоматического перераспределения нагрузки между элементами высокопроизводительного кластера TLS-криптошлюзов с использованием внешнего балансировщика трафика	Да	Да	Да	Да
Возможность бесшовного переключения сессии пользователя без разрыва соединения в случае выхода из строя одного или нескольких узлов кластера	Да	Нет, в разработке	Нет	Нет
Количество узлов в кластере (при использовании синхронизации сессий)	32	Нет, в разработке	Нет ограничений	Нет
Резервное копирование и восстановление настроек	Да	Да	Да	Да
Отсутствие ограничения на количество узлов в кластере (без синхронизации сессий)	Да	Да	Да	Да
Поддержка LACP	Да	Да	Да	Да
Наличие второго блока питания	Да (на старших моделях: NGate 1500, NGate 2000, NGate 3000)	Нет, в разработке	Да (на старших моделях: IPC-1000 и IPC-3000)	Да (на старших моделях)

Работа с криптоключами

Критерий сравнения	КриптоПро NGate	ViPNet TLS Gateway	Континент TLS	С-Терра TLS
Поддержка отечественных криптографических алгоритмов (ГОСТ)	ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2021, ГОСТ 34.11-2021, ГОСТ 34.11-94, ГОСТ 28147-89, ГОСТ 34.12-2021 (ГОСТ Р 34.12-2021), ГОСТ 34.13-2021 (ГОСТ Р 34.13-2021);	ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2021, ГОСТ 34.11-2021, ГОСТ 34.11-94, ГОСТ 28147-89, ГОСТ 34.12-2021 (ГОСТ Р 34.12-2021), ГОСТ 34.13-2021 (ГОСТ Р 34.13-2021)	ГОСТ 28147–89, ГОСТ 34.11–2021 (ГОСТ Р 34.11-94), ГОСТ Р 34.10–2021 (ГОСТ Р 34.10-2001)	ГОСТ Р 34.10-2021, ГОСТ 34.11-2021, ГОСТ Р 34.12-2021, ГОСТ Р 34.13-2021
Поддержка зарубежных криптографических алгоритмов	RSA, ECDSA, AES, AES-GCM	RSA, ECDSA, AES	Нет	RSA, AES, IDEA, Camellia, SEED
Поддерживаемые версии TLS	1.0, 1.1, 1.2 (согласно МР ТК-26), в разработке — 1.3	1.0, 1.1, 1.2 (согласно МР ТК-26), в разработке — 1.3	1.0, 1.2 (согласно МР ТК-26), в разработке — 1.3	1.2 (согласно МР ТК-26)
Форматы поддерживаемых сертификатов и контейнеров	PEM, DER, PKCS7, PFX	PKCS7, PEM, DER, PFX	DER, PEM, PKCS7	PEM, DER, PKCS7
Генерация на TLS-криптошлюзе закрытого ключа и формирование на его основе открытого ключа с созданием запроса на получение сертификата стороннего удостоверяющего центра (с использованием отечественных криптоалгоритмов)	Да	Да	Да	Да
Генерация на TLS-криптошлюзе закрытого ключа и формирование на его основе открытого ключа с созданием запроса на получение сертификата стороннего удостоверяющего центра (с использованием зарубежных криптоалгоритмов)	Да	Да	Нет	Да
Генерация закрытого ключа и формирование на его основе открытого ключа с созданием запроса на получение сертификата стороннего удостоверяющего центра на TLS-клиенте (с использованием отечественных криптоалгоритмов)	Да	Да	Да	Нет
Генерация закрытого ключа и формирование на его основе открытого ключа с созданием запроса на получение сертификата стороннего удостоверяющего центра на TLS-клиенте (с использованием зарубежных криптоалгоритмов)	Да	Да	Нет	Нет
Поддержка списка аккредитованных удостоверяющих центров (TSL)	Нет	Да	Да	Нет

Сертифицированные vpn

VPN подходят для реализации меры ЗИС.3 из 21-го приказа ФСТЭК (защита данных при передачи за пределами контролируемой зоны). Однако, поскольку VPN является криптосредством, то при их использовании мы попадаем под действие 378 приказа ФСБ.

Используемые VPN должны быть сертифицированы по линии ФСБ в качестве средств криптографической защиты информации (СКЗИ). Существуют следующие классы сертифицированных криптосредств, обозначаемых через КС1, КС2, КС3, КВ1, КВ2, КА1 (по последним данным КВ1 и КВ2 объединены в один класс КВ).

Как выбрать сертифицированное решение VPN нужного класса для защиты персональных данных?

1) Для начала, определимся с минимальным классом используемого решения:

Это базовая таблица, которая ограничивает класс применяемых СКЗИ “снизу”. То есть, если у нас УЗ3 и актуальны угрозы 2 типа, то необходимо применять СКЗИ класса КВ и выше. Если у нас УЗ4 и актуальны угрозы 3 типа, то требуемый класс – КС1 и выше.

Обратим внимание на словосочетание “… и выше”.

2) Разработаем совокупность предположений о возможностях нарушителя.

3) Подберем решение, соответствующее выбранному классу СКЗИ и нашим техническим требованиям.

*после поглощения McAfee заказать сертифицированный StoneGate скорее всего невозможно

Это те решения, с которыми приходилось чаще всего сталкиваться на рынке. Если есть что добавить – пишите в комментарии.

P.S.

При выборе решения есть множество нюансов, на которые стоило бы обратить внимание.

Во-первых, один и тот же продукт может быть сертифицирован по разным классам, в зависимости от вариантов исполнения. Например, VPN-клиент без модуля доверенной загрузки (АПМДЗ) сертифицирован по классу КС1, а в комплекте с АПМДЗ – уже КС2/КС3. Нам придется внимательно выбрать необходимый вариант исполнения приобретаемого решения.

Во-вторых, изучим формуляр и правила пользования, в соответствии с которыми должны эксплуатироваться СКЗИ. Убедимся, что мы действительно сможем выполнить указанные там условия.

Требования фстэк к межсетевым экранам

Межсетевой экран (сокращенно МЭ, другое название — файрвол, от английского firewall) согласно ФСТЭК — это «программное или программно-техническое средство, реализующее функции контроля и фильтрации в соответствии с заданными правилами проходящих через него информационных потоков».

Согласно определению, МЭ должен противодействовать следующим угрозам:

несанкционированному доступу к цифровой информации организации;
отказу в обслуживании информационной системы по причине неконтролируемых сетевых подключений (в том числе DDoS-атакам), уязвимостей, недостатков настроек;
несанкционированной передаче информации из внутренней системы организации во внешнюю среду, в том числе вследствие работы вредоносного программного обеспечения;
воздействию на МЭ с целью нарушения его функционирования.

Руководящий документ. Средства вычислительной техники. Межсетевые экраны.

Ссылка на документ на сайте ФСТЭК

Согласно документу на сайте ФСТЭК, межсетевой экран должен уметь:

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

Типы межсетевых экранов согласно классификации ФСТЭК:

тип «А»: межсетевой экран, применяемый на физической границе или между физическими границами сегментов локальной инфраструктуры организации;
тип «Б»: межсетевой экран, применяемый на логической границе или между логическими границами сегментов локальной инфраструктуры организации;
тип «В»: межсетевой экран, применяемый на узле (хосте) информационной системы;
тип «Г»: межсетевой экран, применяемый на сервере или на физической границе сегмента серверов;
тип «Д»: межсетевой экран, применяемый в автоматизированной системе управления технологическими или производственными процессами.

ФСТЭК, Приказ № 17 «ОБ УТВЕРЖДЕНИИ ТРЕБОВАНИЙ О ЗАЩИТЕ ИНФОРМАЦИИ, НЕ СОСТАВЛЯЮЩЕЙ ГОСУДАРСТВЕННУЮ ТАЙНУ, СОДЕРЖАЩЕЙСЯ В ГОСУДАРСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ»

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

Критерий сравнения	КриптоПро NGate	ViPNet TLS Gateway	Континент TLS	С-Терра TLS
Управление доступом пользователей на основе даты и времени	Да	Нет, в разработке	Нет	Нет
Управление доступом пользователей с двухфакторной аутентификацией через Radius	Да	Нет, в разработке	Нет	Нет
Автоматическое разграничение доступа пользователей на основе используемых алгоритмов шифрования	Да	Да	Нет	Нет
Разграничение доступа пользователей к защищаемым подсетям на основе членства в группах доменов	Да	Да	Да, в режиме портала приложений	Нет
Контроль состояния установленных защищённых соединений с удалёнными пользователями с возможностью принудительного завершения сессии пользователя по команде администратора	Да	Да, без возможности принудительного завершения	Да, без возможности принудительного завершения	Нет
Автоматический разрыв активной сессии пользователя по невалидному сертификату на основе полученного CRL	Да	Нет, в разработке	Да, в том числе при отзыве аккредитации издателя сертификата пользователя	Нет