Аутентификация на основе одноразовых паролей в Active Directory. Теоретические основы. / Двухфакторная аутентификация / PKI Guru

Что требуется администратору безопасности?

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

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

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

1. При вводе ключей в эксплуатацию необходимо для каждого токена задать пароль администратора, PIN-код пользователя и загрузить в его память все требуемые данные (ключи, сертификаты и т.п.). Кроме того, нужно внести изменения в базу данных пользователей, поставив в соответствие каждому определенное устройство или устройства.
2. В процессе использования токена сотрудниками администратору безопасности придется многократно менять уровни доступа, разрешая или запрещая им те или иные действия.
3. В ситуации кражи или утери токена необходимо иметь возможность его немедленной блокировки с тем, чтобы не позволить злоумышленнику им воспользоваться.
4. В случае рассинхронизации OTP, необходимо иметь возможность исправить ситуацию.
5. Если пользователь забыл свои ПИН код, требуется обеспечить возможность, на основе технологий запрос-ответ, его смены.
6. Если пользователю требуется срочный доступ, а аппаратный токен выдать невозможно, то потребуется сформировать токен программный.

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

На первый взгляд, может показаться, что все эти задачи могут быть решены в рамках AD и специальный инструментарий не потребуется. Тем не менее, это не так. Если мы говорим о компании среднего размера или крупной, то возникает существенный рост нагрузки на ИБ или ИТ службу, поскольку, ответственному лицу придется «вручную» корректировать записи в Active Directory, системе VPN, правилах доступа к внутреннему порталу, в базе данных каталога каждого отдельного приложения (если таковые имеются), отзывать все выданные сотруднику сертификаты, убирать полномочия по расшифровыванию данных и подписи документов и т. д.

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

Что важно для компании?

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

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

Введение

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

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

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

Целью этой статьи является сделать обзор необходимых для корпоративного заказчика набора технологий, базируясь на которых можно выбрать конкретное решение для реализации в рамках службы каталога Active Directory. Рассмотрим аутентификацию на основе смарт карт и USB ключей.

«запрос-ответ» (challenge-response)

Рассмотрим принципы работы метода «запрос-ответ» (см. рис. 1):

1. Пользователь вводит свое имя на рабочей станции. Имя пользователя передается серверу по сети в открытом виде.
2. Сервер генерирует случайный запрос.
3. Этот запрос передается по сети в открытом виде.
4. Пользователь вводит полученные данные в свой OTP-токен.
5. OTP-токен шифрует запрос с помощью секретного ключа пользователя, и формируется ответное значение, которое отображается на экране токена.
6. Пользователь вводит это значение на своей рабочей станции.
7. Затем ответ передается по сети в открытом виде.
8. Сервер осуществляет поиск записи пользователя в аутентификационной БД, используя секретный ключ пользователя, шифрует тот же запрос.
9. Далее сравниваются два значения: полученное от пользователя и вычисленное сервером. При их совпадении аутентификация считается успешной.
10. Нетрудно заметить, что такой метод предполагает большое количество шагов и несколько большую вовлеченность пользователя в процесс аутентификации, добавляется необходимость еще одного дополнительного ввода данных, что создает неудобства.

Альтернативным вариантов является метод «только ответ».

«только ответ» (response only)

В методе «только ответ» OTP-устройство и сервер аутентификации генерируют скрытый запрос, используя значение предыдущего запроса. На первоначальной стадии используется уникальное случайное начальное значение, формируемое при инициализации токена.

Рассмотрим принципы работы (см. рис. 2).

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

Pam_radius

Установите модуль PAM_RADIUS

$ sudo yum -y install epel-release$ sudo yum -y install pam_radius

Откройте для редактирования файл /etc/pam_radius.conf и укажите адрес компонента Multifactor Radius Adapter и shared key.

192.168.0.1:1812   shared_secret   40

Прочие сервера, если они есть по умолчанию в файле, необходимо удалить или закомментировать (поставить в начале #).

Двухфакторная аутентификация: active directory, ldap, databases — protectimus

Журналы

Журналы работы компонента находятся в папке Logs. Если их нет, удостоверьтесь, что папка доступна для записи пользователю Network Service.

Запуск компонента

Компонент может работать в консольном режиме или в качестве службы Windows. Для запуска в консольном режиме достаточно запустить приложение.

Для установки, как Windows Service, выполните с ключом /i от имени Администратора

MultiFactor.Radius.Adapter.exe /i

и запустите службу

net start mfradiusadapter

Литература

[1] Леонид Шапиро «Аутентификация и одноразовые пароли. Теоретические основы. Часть 1» (Системный Администратор № 9 2022 г.).

[2] Леонид Шапиро «Аутентификация и одноразовые пароли. Часть 2. Внедрение OTP для аутентификации в AD» (Системный Администратор № 9 2022 г.).

[3] Аутентификация, теория и практика обеспечения безопасного доступа к информационным ресурсам. – М., 2009, ISBN 978-5-9912-0110-0.

Настройка openvpn

В первую очередь вам необходим Linux сервер с установленным OpenVPN.
Сервер может быть CentOS, Ubuntu, Debian и тд. В нашем примере рассматривается CentOS, но для прочих систем отличия будут минимальными.

Сам процесс установки и первичной настройки OpenVPN мы не рассматриваем, так как на эту тему есть множество статей.

Настройка openvpn сервера

Откройте файл /etc/openvpn/server.conf и добавьте плагин для аутентификации с помощью PAM модуля

plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

Далее создайте файл проверки подлинности для openvpn

$ sudo vi /etc/pam.d/openvpn

и впишите в него

auth    sufficient  pam_radius_auth.so
account sufficient  pam_permit.so
session sufficient  pam_permit.so

Перезапустите OpenVPN сервер

$ sudo systemctl restart openvpn@server

Настройка мультифактора

Зайдите в систему управления Мультифактором, создайте новый ресурс “OpenVPN”. После создания вам будут доступны два параметра: NAS Identifier и Shared Secret они понадобятся для дальнейшей настройки.

Параметры компонента

Параметры работы компонента хранятся в файле MultiFactor.Radius.Adapter.exe.config в формате XML.

Принципы работы

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

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

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

Синхронизация по времени (time synchronous)

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

1. Пользователь активизирует свой токен, который генерирует OTP, зашифровывая показания часов с помощью своего секретного ключа.
2. Пользователь вводит свое имя и этот OTP на своей рабочей станции. Имя пользователя и OTP передаются по сети в открытом виде.
3. Сервер находит запись пользователя и шифрует показания своих часов с помощью хранимого им секретного ключа, получая в результате OTP.
4. Далее сравниваются вычисленный и полученные OTP. При совпадении значений аутентификация считается успешной.

Необходимо учитывать, что такие системы чувствительны к синхронизации времени.

Синхронизация по событию

В режиме «синхронизация по событию» (см. рис. 4) токен и сервер ведут количественный отсчет прохождения аутентификаций пользователем и на основе этого числа генерируют OTP.

1. Пользователь активирует токен, который генерирует OTP, зашифровывая количество прохождений аутентификаций данного пользователя с помощью своего секретного ключа.
2. Пользователь вводит свое имя и OTP на рабочей станции.
3. Эти данные передаются по сети в открытом виде.
4. Аутентификационный сервер находит запись пользователя и шифрует значения количества прохождений аутентификаций данного пользователя с помощью хранимого секретного ключа, получая в результате OTP.
5. Далее сравниваются полученные значения, и при совпадении аутентификация считается успешной.

В этом варианте проблему представляет ситуация, когда устройство аутентификации «обгонит» сервер, например, при многократном повторном нажатии кнопки генерации OTP на устройстве.

Современный подход к работе…

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

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

И неважно, что это будет: персональный компьютер на базе ОС Windows или MAC OS, планшет или смартфон. Все это представляет существенные сложности для ИТ служб. Как обеспечить безопасный доступ со всех этих устройств? Разумеется, самым простым способом будет использование обычных паролей, однако это приводит к слишком серьезным рискам с точки зрения информационной безопасности.

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

Выбирая поставщика оборудования стоит быть особенно внимательным к некоторым важным деталям.

Очевидно, что наиболее «правильным» с точки зрения ИБ будет применение асимметричной криптографии, что собственно говоря, реализовано у любого поставщика. Связка смарт карт, технологии Kerberos PKINIT, доступной нам еще с Windows Server 2000 и инфраструктуры открытых ключей, например Microsoft PKI предоставляет нам, на первый взгляд весь необходимый для реализации безопасной аутентификации функционал.

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

Следовательно, для такой ситуации имеет смысл рассмотреть технологию одноразовых паролей, которая была рассмотрена в статьях см. [1] [2]. При этом весьма желательно обладать возможностью использования не только аппаратного устройства (OTP токена), но и временного использования программного OTP, например, в ситуации утери или кражи.

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

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

В заключении

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