Сертифицированные vs несертифицированные средства защиты информации: требования регулятора или реальная необходимость? / Хабр

1с-битрикс – ssl-сертификаты: что это такое и как правильно выбрать

Настройка FreeRADIUS.

Начнем с установки и настройки FreeRADIUS сервера.

В операционной системе Gentoo это делается довольно просто, достаточно ввести команду
=====================================================
root@s2 ~ # emerge -av freeradius

These are the packages that I would merge, in order:

Calculating dependencies …done!

[ebuild N ] net-dialup/freeradius-1.0.5-r1 -edirectory
-frascend -frnothreads -frxp -kerberos -ldap -mysql pam
-postgres -snmp ssl -udpfromto 2,240 kB

Total size of downloads: 2,240 kB

Do you want me to merge these packages? [Yes/No]
=====================================================

Если планируется хранить базу пользователей во внешних базах (например, ldap, mysql или postgre), то перед сборкой RADIUS сервера надо активировать соответствующие флаги, позволяющие собрать FreeRADIUS с поддержкой mysql/postgre и/или ldap:
=====================================================
# USE=”mysql ldap” emerge -av freeradius
=====================================================

После проверки включенности нужных флагов, достаточно нажать клавишу Y и пакет будет собран и установлен в систему:
=====================================================

<….>

— !targe sym /usr/lib/rlm_digest-1.0.5.la
— !targe sym /usr/lib/rlm_detail.so
— !targe sym /usr/lib/rlm_detail-1.0.5.la
— !targe sym /usr/lib/rlm_counter.so
— !targe sym /usr/lib/rlm_counter-1.0.5.la
— !targe sym /usr/lib/rlm_checkval.so
— !targe sym /usr/lib/rlm_checkval-1.0.5.la
— !targe sym /usr/lib/rlm_chap.so
— !targe sym /usr/lib/rlm_chap-1.0.5.la
— !targe sym /usr/lib/rlm_attr_rewrite.so
— !targe sym /usr/lib/rlm_attr_rewrite-1.0.5.la
— !targe sym /usr/lib/rlm_attr_filter.so
— !targe sym /usr/lib/rlm_attr_filter-1.0.5.la
— !targe sym /usr/lib/rlm_always.so
— !targe sym /usr/lib/rlm_always-1.0.5.la
— !targe sym /usr/lib/rlm_acct_unique.so
— !targe sym /usr/lib/rlm_acct_unique-1.0.5.la
— !targe sym /usr/lib/libradius.so
— !targe sym /usr/lib/libradius-1.0.5.la
— !targe sym /usr/lib/libeap.so
— !targe sym /usr/lib/libeap-1.0.5.la
>>> original instance of package unmerged safely.
>>>

Вышеприведенный лог сборки (его конец) показывает, что FreeRADIUS 1.0.5 успешно установлен в систему (о чем сообщает строка ” net-dialup/freeradius-1.0.5-r1 merged”). Можно приступать к его настройке.

Создание сертификата компьютера.

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

Наш компьютер называется testcomp1. Создаем сертификат для него:
#—————————————————-
# ./sign_cert.sh client_cert testcomp1
#—————————————————-

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

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

1 Установка корневого сертификата CA напрямую.

Для начала, необходимо установить корневой сертификат CA (сертификационного центра). Просто открываем в Windows Explorer-е директорию, где у нас лежат файлы сертификатов, и два раза щелкаем на созданном ранее файле tmp_org-ca.crt

В ответ получаем окошко, где нам предлагается установить сертификат в систему. Можно сразу щелкнуть по кнопке “Установить сертификат”, а можно предварительно побегать по закладкам:

Закладка “Состав” показывает все параметры сертификата. Особенно интересны пункты “Действителен с” и “Действителен по” — сертификат будет действителен только в этом промежутке времени. Если им воспользоваться раньше или позже указанного времени, он будет отвергнутым (это касается сертификатов любых типов — как серверных, так и клиентских).

“Путь сертификации” показывает, что сертификат является корневым (самоподписанным).

После нажатия кнопки “Установить сертификат” в закладке “Общие”, мы попадем в мастер импорта сертификатов.

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

… осталось нажать кнопку “готово”.

Выскакивает последнее предупреждение об установке нового центра сертификации “tmp_org root CA”.

После нажатия на кнопку “да” в предыдущем меню, система сообщит нам, что импорт выполнен. Тем не менее, даже после нажатия на “ОК”, основное окошко с сертификатом продолжает сообщать, что сертификат неизвестен. Это всего лишь “фича” операционной системы. Достаточно закрыть то окно и открыть его заново (два раза щелкнуть на файл с сертификатом):

В этом случае нам уже сообщают, что сертификат известен и ему доверяют.

4 файл /etc/raddb/eap.conf

Переходим к настройке протокола EAP. Его настройки располагаются в отдельном файле, который, в свою очередь, подключается к основному /etc/raddb/radiusd.conf вот такой конструкцией:
#—————————————————-
$INCLUDE ${confdir}/eap.conf
#—————————————————-

Открываем /etc/raddb/eap.conf

В секции eap{ }
#—————————————————-
default_eap_type = peap # по-умолчанию, используем EAP-PEAP
#—————————————————-

Раскомментируем секцию, относящуюся к peap:
#—————————————————-
peap {
default_eap_type = mschapv2
}
#—————————————————-

Но этого недостаточно для функционирования PEAP, нам также необходимо активировать (раскомментировать) секцию, отвечающую за EAP-TLS:
#—————————————————-
tls {
private_key_password = whatever
private_key_file = ${raddbdir}/certs/cert-srv.pem

certificate_file = ${raddbdir}/certs/cert-srv.

В данном случае использованы цифровые сертификаты, сгенерированные автоматически, при установке пакета freeradius. Можно, конечно, создать собственные сертификаты, подписанные своим (или сторонним) сертификационным центром, но для простоты объяснения, этот этап опущен (он будет подробно расписан в следующей части статьи). Для работы RADIUS-сервера для обеспечения работы EAP-PEAP протокола, вышеприведенных настроек будет достаточно.

Настройка точки доступа.

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

Надо сделать следующее:

• включить WPA;
• выбрать тип шифрования (AES или TKIP)
• прописать адрес RADIUS-сервера
• прописать пароль доступа (shared secret) к RADIUS-серверу

Вводим SSID беспроводной сети (WPA-PEAP), активируем “Security” и жмем кнопку “Configure Security”.

В появившемся окне выбрать WPA RADIUS в пункте “Security Mode”. Далее алгоритм шифрования — установить AES (или TKIP, если клиентское оборудование AES не поддерживает). Далее вводим адрес машины, где установлен RADIUS сервер и порт, по которому оный принимает запросы (порт 1812 — является стандартным).

Осталось задать “Shared Secret” (пароль на подключение) и все — настройка точки доступа на этом завершена.

Настройка беспроводного клиента.

WiFi карта подключена к компьютеру под управлением Windows XP PRO SP2. Настройка производится в родной Windows Zero Config утилите.

Жмем на “изменить порядок предпочтения сетей”.

В закладке “беспроводные сети” щелкаем на кнопку “Добавить”.

Попадаем в окно свойств беспроводной сети.

Закладка “связи”. Указываем нужное имя сети (в нашем случае WPA-PEAP) и выбираем тип шифрования данных (AES или TKIP). Разумеется, он должен совпадать с тем, что был указан в точке доступа.

Переходим на закладку “Проверка подлинности”. В типе EAP ставим “Protected EAP (PEAP)”. После чего жмем на кнопку “Свойства”.

В следующем окошке снимаем галку с “проверять сертификат сервера”. Так как сертификаты у нас самосгенеренные при установке FreeRadius, Windows не сможет проверить их валидность (это будет показано чуть ниже).

Далее, выбираем “Метод проверки подлинности”, ставим там “Secured password (EAP-MSCHAP v2). Если тут же нажать кнопку “настроить”, то

Установка сертификатов через MMC

Пара способов установки клиентских сертификатов уже была описана в четвертой части:

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

Для установки сертификата компьютера, который будет храниться в системном профиле (куда ОС будет иметь доступ даже без наличия сети), необходимо воспользоваться Microsoft Managment Console (MMC).

Для этого идем в “Пуск” -> “Выполнить”.

В окне запуска программы пишем “mmc” и жмем клавишу “OK”.

В открывшемся окне консоли необходимо добавить оснастку сертификатов.

Для этого идем в меню “Консоль”. И выбираем пункт “Добавить или удалить оснастку”.

На закладке “Изолированная оснастка” жмем кнопку “добавить”.

В появившемся списке выбираем оснастку “Сертификаты” и жмем кнопку “Добавить”.

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

Пункт “моей учетной записи пользователя” позволит добавить оснастку управления пользовательскими сертификатами. Именно ими мы и управляли в предыдущей статье с помощью интерфейса IE.

Добавляем пользовательскую оснастку.

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

Сертификаты компьютера невозможно добавить напрямую или через IE. Они добавляются только через MMC-консоль.

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

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

Теперь подробнее рассмотрим, что эти оснастки из себя представляют.

Раскрываем дерево сертификатов текущего пользователя. Идем вниз по дереву: “Личные” -> “Сертификаты”.

Настройка беспроводной сети на клиенте.

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

Заходим в Zero Config Utility, жмем на “Изменить порядок предпочтения сетей”.

В закладке “Беспроводные сети” жмем кнопку “Добавить”.

В закладке “Связи” вводим имя сети (WPA-TLS), в качестве проверки подлинности опять выбираем WPA, а шифрование данных — AES.

Пока все то же самое, не так ли? А с закладки “Проверка подлинности” появляются отличия.

В качестве “Типа EAP” выставляем “Смарт карта или другой сертификат”.

Галка “Проверять подлинность как у компьютера при доступности сведений о компьютере” пока не нужна, ее необходимость будет рассмотрена позже.

Теперь жмем на кнопку “Свойства”.

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

После чего активировать “проверку сертификата сервера” и в появившемся внизу списке сертификатов корневых серверов выбрать наш личный центр — tmp_org root CA.

Конечно, можно не активировать проверку сертификата сервера, но ведь мы настраиваем безопасную сеть, не так ли? И должны убедиться, что точка доступа наша, так как обращается к нашему RADIUS-серверу. При подключении к точке доступа, она (а точнее RADIUS) предъявляет свой, серверный сертификат, также подписанный корневым tmp_org root CA.

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

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

появится окно, сообщающее, что корневым сертификатом для предъявленного сервером радиуса, является “tmp_org root CA”. Если нажать ОК, то соединение продолжится.

Если же убрать галку с “проверка сертификата сервера”, то никаких проверок валидности серверного сертификата на клиенте производиться не будет. Но это небезопасно — кто угодно может поставить собственную точку доступа, настроенную аналогично нашей (то же имя сети (SSID), те же параметры шифрования и собственный центр сертификации), в результате мы подключимся к чужой сети, возможно, с самыми печальными последствиями.

Последняя закладка — “Подключение” — в свойствах беспроводной сети позволяет активировать автоматическое подключение к сети, как только она будет обнаружена клиентом.

Процесс подключения со стороны RADIUS-сервера

Для детального наблюдения за процессом, запускаем Radius в режиме отладки:
#—————————————————-
# radiusd -X
#—————————————————-

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

После того, как рабочая станция включится и операционная система полностью загрузится (до момента, когда появится ctrl alt del экран) нужно подождать еще секунд 20..40. Это время необходимо ОС для обнаружения беспроводной сети — только после этого произойдет попытка подключения к ней.

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

Несколько слов о сертификации сзи

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

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

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

Несколько слов про timestamp.

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

Пример:Сертификат действителен с: 01.01. 2008Сертификат действителен до: 31.12.2021Подпись сделана: 04.07.2009Подпись проверена: 30.04.2021

C временной меткой (timestamp) подпись пройдет проверку, поскольку на момент подписи сертификат был действителен. Без такой метки сертификат не пройдет проверку, поскольку на момент проверки у сертификата уже закончился срок.То есть такая метка позволяет использовать подписанный код, даже после срок окончания сертификата.

Несколько советов.

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

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

UPD: добавил важную информацию про timestamp (временную метку), спасибо TolTol и crea7or

Типовые организации и применимые к ним нпа

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

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

Также предположим, что Банк не осуществляет обработку сведений, составляющих государственную тайну – при наличии такого рода информации вопрос о необходимости использования сертифицированных СЗИ, как мы понимаем, не стоит. Далее по тексту будут раскрыты еще несколько особенностей выбранной нами организации, обосновывающие применение тех или иных НПА. Для простоты далее будем именовать наш пример как просто «Банк».

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

1. ГОСТ Р 57580, который приобретает статус обязательного документа для организаций, на которые распространяются требования Положений БР 672-П, 683-П.

2. Ряд положений Банка России: Положения 382-П, 672-П, 683-П, устанавливающих обязательные для финансовых организаций требования к обеспечению защиты информации, выполнять которые в той или иной степени необходимо каждому банку.

3. Приказ Минкомсвязи № 321 и методический документ БР № 4-МР, регламентирующие порядок защиты биометрических персональных данных, так как выбранный нами Банк взаимодействует с Единой биометрической системой.

4. ФЗ «О персональных данных» и подзаконные акты, определяющие требования к обеспечению защиты персональных данных, так как Банк является оператором персональных данных, осуществляя обработку информации о своих работниках, клиентах и иных лицах.

5. ФЗ «О безопасности критической информационной инфраструктуры» и подзаконные акты, так как нашему Банку принадлежат информационные системы, функционирующие в банковской сфере, в соответствии с чем он является субъектом КИИ

6. И, возможно, даже СТО БР ИББС, если Банк продолжает использовать комплекс в качестве вектора ИБ-развития.

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

Но не стоит думать, что для иных организаций он будет значительно меньше. Так, например, для страховой организации в общем случае этот перечень уменьшится лишь на несколько положений БР, СТО БР, БР № 4-МР, а для субъекта КИИ, не являющегося финансовой организацией, применимы останутся как минимум пункты 4 и 5 представленного выше списка.

Заключение

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

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

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

Таким образом, к решению вопроса о необходимости применения сертифицированных решений стоит подходить как минимум с двух разных сторон: как со стороны требований НПА, так и со стороны специфики конкретной организации, ее систем и процессов.

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

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

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

Спасибо за внимание!

Владислав Павлов

Специалист отдела аудита и консалтинга, Акрибия

Заключение.

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

В последней части речь пойдет о проблеме “первичности курицы и яйца”- использовании беспроводных клиентов в доменах Windows.

Разберем вкратце эту ситуацию. Клиентский сертификат хранится в профиле пользователя. Профиль может лежать как на сервере (перемещаемые профили), так и на самой рабочей станции (локальные профили).

Для процесса аутентификации (подключения к беспроводной сети), нам необходим клиентский сертификат, лежащий в профиле. Для доступа к профилю, нам как минимум надо аутентифицироваться и на домен-контроллере. То есть, с одной стороны, для подключения к беспроводной сети нам нужно аутентифицироваться на домен-контроллере. А с другой — для аутентификации на домен-контроллере мы уже должны быть подключены к беспроводной сети. Замкнутый круг? 🙂

Второй момент. Выдали сотруднику клиентский сертификат на его ноутбук. Работает он в беспроводной сети, горя не знает. Потом сотрудник уволился. Как запретить ему доступ в сеть компании?

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