OpenVPN пользуется заслуженной популярностью у системных администраторов, находя широкое применения в самых разнообразных сценариях. Но очень часто внедрение OpenVPN происходит посредством повторения инструкций, без глубокого понимания смысла выполняемых действий. Особенно это касается "генерации ключей", эта простая с виду операция имеет достаточно глубокий скрытый пласт, формируя собственную инфраструктуру открытых ключей. Отсутствие понимания структуры PKI, как показывает отклик наших читателей, способно приводить к различного рода затруднениям и проблемам при использовании OpenVPN.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Вообще-то PKI - тема достаточно сложная и обширная, требующая глубоких теоретических знаний. Но мы не будем углубляться в дебри, а постараемся простым языком, с максимальным упрощением, дать тот необходимый минимум знаний, который должен быть у любого администратора, работающего с OpenVPN.
Всем известно, что для аутентификации пользователей OpenVPN использует вместо паролей сертификаты. Что это дает? Это дает существенное повышение безопасности. Мы сейчас не будем говорить о том, что пароль можно перехватить. Современные системы не передают пароли в открытом виде, используя вместо них достаточно хорошо защищенные сложными криптографическими алгоритмами хеши. Но пароль всегда можно подобрать и это одно из наиболее уязвимых мест.
Сертификат подобрать невозможно, его можно либо иметь, либо не иметь. Но само по себе наличие сертификата еще ничего не дает, он не является секретным и вы вполне можете его получить, но чтобы установить защищенное соединение с сервером вам потребуется закрытый ключ, который хранится в надежном месте и (в идеале) никогда не покидает пределы клиентского ПК.
Но как сервер определит, что именно этот клиент имеет право доступа? Существует ошибочное мнение, что сертификаты выдает именно сервер и поэтому он знает, кто из клиентов имеет право подключаться, а кто нет. Однако это не так и данное заблуждение часто приводит к разного рода затруднениям при работе с OpenVPN.
Здесь мы вплотную подходим к понятию инфраструктуры открытых ключей. Основная цель PKI - это обеспечение области доверия, в которой каждый участник может однозначно доверять другому участнику, не имея никакой предварительной информации о нем.
Если проводить аналогию, то это можно сравнить с пропускной системой на проходной. Охранник лично вас не знает в лицо, вы тоже, возможно, первый раз его видите, но вы предъявляете ему пропуск установленного образца, и он открывает вам турникет. За счет чего это происходит? За счет доверия. Пропуска выдаются специальным отделом - Бюро пропусков, авторитет и доверие, к которому неоспоримы.
В нашем случае таким "бюро пропусков" служит Центр сертификации (CA, Certification authority), вокруг которого складывается инфраструктура открытых ключей. Авторитет CA неоспорим и доверие к нему не подвергается сомнению. Именно CA осуществляет всё управление сертификатами, как для клиентов, так и для серверов.
Это абсолютно отдельная сущность, хотя физически она может находиться на одном узле с сервером OpenVPN. Чаще всего в роли центра сертификации используется Easy-RSA, хотя можно использовать любое другое ПО, скажем, в роли CA вполне может выступать Mikrotik. Но общий смысл от этого не меняется, создав центр сертификации мы вместе с ним создаем область доверия, которая называется инфраструктурой открытых ключей.
Давайте рассмотрим следующую схему:
При создании центра сертификации мы генерируем ключевую пару из открытого и закрытого ключей. Открытый ключ, вместе с другой информацией о нашем CA содержится в корневом сертификате ca.crt, который должен иметь самое широкое распространение в нашей инфраструктуре, так как именно он составляет основу доверительных отношений. Имея на руках корневой сертификат, мы можем проверить сертификат любого другого субъекта и убедиться, что он выдан нашим CA и следовательно мы можем ему доверять.
Закрытый ключ центра сертификации представляет самую большую ценность и должен храниться в надежном месте, а также никогда не покидать пределы CA. Компрометация закрытого ключа фактически уничтожает область доверия, так как мы не можем быть уверенны, что предъявленный нам сертификат выпущен именно CA, а не завладевшим ключом злоумышленником.
При помощи центра сертификации мы формируем ключи и сертификаты для OpenVPN-серверов и их клиентов. Если быть строго последовательными - то это неправильно, так как закрытый ключ клиента (под клиентами CA подразумеваются как сервера OpenVPN, так и их клиенты) формируется на узле CA, а потом передается на узел клиента, что является нарушением безопасности, так как закрытый ключ не должен покидать пределы собственного узла.
В теории мы должны на каждом клиенте центра сертификации создать открытый и закрытый ключи, сформировать запрос на сертификат и отправить его CA, который в свою очередь выпустит нужный нам сертификат и подпишет его своим открытым ключом. Таким образом никакая критически важная для безопасности информация (закрытые ключи) по каналам связи не передается.
На практике схема, когда и ключи, и сертификаты формирует CA вполне допустима, так как все это контролируется системным администратором, который может принять разумные меры для недопущения несанкционированного доступа к закрытым ключам.
Таким образом на каждом из узлов нашей OpenVPN-сети должен присутствовать закрытый ключ, сертификат узла и корневой сертификат CA. При этом ни клиенты, ни сервера не знают кому именно выпущены сертификаты и в каком количестве.
Это очень важный момент. OpenVPN-сервер не имеет списка клиентов и готов предоставить доступ любому, кто предоставит валидный сертификат. Почему? Потому что все они входят в область доверия, созданную центром сертификации в рамках инфраструктуры открытых ключей.
Чтобы получить доступ клиент предъявляет серверу собственный сертификат, сервер, при помощи корневого сертификата CA убеждается, что данный сертификат действительно выдан нашим центром сертификации и ему можно доверять, затем проверяется срок его действия и при успешной проверке начинается процесс установления защищенного соединения.
Срок действия является одним из наиболее важных параметров сертификата и его можно успешно использовать в свою пользу. Скажем для сотрудника на испытательном сроке можно выпустить сертификат на 30 дней, а затем просто перевыпустить на больший срок. Это гораздо безопаснее, чем потом забыть отозвать сертификат у не прошедшего испытательного срока работника.
Со своей стороны клиент точно также проверяет действительность сертификата сервера, после чего устанавливает с ним связь. При этом любой клиент с сертификатом текущего CA может без проблем подключиться к любому серверу в рамках инфраструктуры PKI.
Что касается CA, что обычно он размещается на одном из серверов OpenVPN, но в более сложных схемах имеет смысл вынести его на отдельный узел, лучше всего на виртуальную машину, которую даже можно большую часть времени держать выключенной, включая только для того, чтобы выпустить или отозвать очередной сертификат.
И если мы говорим о доверии, то самое время вспомнить об его утрате. В каком случае субъект может утратить доверие? Вариантов тут может быть несколько: это и увольнение сотрудника, и возможная компрометация его закрытого ключа (например, устройство было украдено). В этом случае сертификат требуется отозвать. В процессе отзыва сертификата CA формирует список отозванных сертификатов - CRL. Данный список публикуется на заранее известном узле, и любой участник PKI может проверить предъявленный ему сертификат на предмет отзыва.
Но OpenVPN так не умеет, что влечет за собой некоторые дополнительные действия. Рассмотрим еще одну схему:
После того, как CA обновил список отозванных сертификатов (CRL) его нужно распространить на все сервера OpenVPN в нашей инфраструктуре, после чего они будут понимать, что данный сертификат отозван и отказывать в соединении. Если мы не выполним данное условие, то те сервера, которые не получили обновленный CRL будут по-прежнему разрешать доступ клиенту сертификат которого отозван.
Что касается практики, то правильный сценарий предусматривает в пределах одной организации один центр сертификации, создание для нескольких OpenVPN-серверов нескольких CA является достаточно грубой ошибкой. Единственный CA позволяет иметь одну точку управления доверием для всей вашей сети вне зависимости от количества серверов и клиентов в ней.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Последние комментарии