Аутентификация в windows по смарт карте

Кто-то из вас наверняка слышал про инцидент , который был обнародован совсем недавно. Американский производитель полупроводников Allegro MicroSystem LLC подал в суд на своего бывшего IT-специалиста за саботаж. Нимеш Пател, проработавший в компании 14 лет, уничтожил важные финансовые данные в первую неделю нового фискального года.

Как это произошло?

Через две недели после своего увольнения Пател зашел на территорию штаб-квартиры компании в Вустере (штат Массачусетс, США) с целью поймать корпоративную сеть Wi-Fi. Используя учетные данные бывшего коллеги и рабочий ноутбук, Пател авторизовался в корпоративной сети. Затем он внедрил в модуль Oracle код и запрограммировал его выполнение на 1 апреля 2016 года — первую неделю нового финансового года. Код предназначался для копирования определенных заголовков или указателей в отдельную таблицу базы данных и следующего удаления их из модуля. Ровно 1 апреля данные были удалены из системы. И поскольку злоумышленник авторизовался в сети Allegro легально, его действия были замечены не сразу.

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

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

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

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

В следующих статьях мы расскажем вам, как настроить Bitlocker, защитить электронную почту и простейший документооборот. Также мы вместе с вами настроим безопасный доступ к корпоративным ресурсам и безопасный удаленный доступ по VPN.

Двухфакторная аутентификация

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

Давайте вспомним, что такое аутентификация. В нашем случае это процесс подтверждения подлинности субъекта или объекта. Аутентификация пользователя — это процесс подтверждения подлинности пользователя.

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

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

Токен и смарт-карта

Наверно, самым надежным и простым в реализации способом двухфакторной аутентификации является использование криптографического токена или смарт-карты. Токен — это USB-устройство, которое является и считывателем, и смарт-картой одновременно. Первым фактором в таком случае является факт владения устройством, а вторым — знание его PIN-кода.

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

На фотографии изображена типичная смарт-карта и считыватель.

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

А начнем мы с домена Windows, ведь в большинстве компаний в России корпоративная сеть построена именно вокруг него.

Как известно, политики Windows-домена, настройки пользователей, настройки групп в Active Directory предоставляют и разграничивают доступ к огромному количеству приложений и сетевых сервисов.

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

Почему двухфакторная аутентификация в домене по токену с PIN-кодом безопаснее обычной парольной схемы?

PIN-код привязан к определенному устройству, в нашем случае к токену. Знание PIN-кода само по себе ничего не дает.

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

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

Токен является уникальным некопируемым физическим объектом. Им обладает легитимный пользователь. Двухфакторную аутентификацию по токену можно обойти только тогда, когда администратор намеренно или по недосмотру оставил для этого «лазейки» в системе.

Преимущества входа в домен по токену

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

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

При использовании токена для пользователя вход в систему выглядит следующим образом: после загрузки компьютера, он просто подключает токен к USB-порту компьютера, вводит 4-6 цифр и нажимает кнопку Enter. Скорость ввода цифр у обычных людей выше, чем скорость ввода букв. Поэтому PIN-код вводится быстрее.

Токены позволяют решить проблему «брошенного рабочего места» — когда пользователь уходит со своего рабочего места и забывает выйти из своей учетной записи.

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

Недостатки, куда же без них

Токены или смарт-карты не бесплатные (решается бюджетом).

Их нужно учитывать, администрировать и обслуживать (решается системами управления токенами и смарт-картами).

Некоторые информационные системы могут «из коробки» не поддерживать аутентификацию по токенам (решается системами типа Single Sign-On — предназначенными для организации возможности использования единой учетной записи для доступа к любым ресурсам области).

Настройка двухфакторной аутентификации в домене Windows

Теоретическая часть:

Служба каталога Active Directory поддерживает возможность аутентификации с помощью смарт-карты и токена, начиная с Windows 2000. Она заложена в расширении PKINIT (public key initialization — инициализация открытого ключа) для протокола Kerberos RFC 4556 .

Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей. Он может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sing-On. Протокол основан на ключевой сущности Ticket (билет).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей).

Когда пользователь выполняет первичную аутентификацию после успешного подтверждения его подлинности, KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT).

В дальнейшем при обращении к отдельным ресурсам сети, пользователь, предъявляет TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Ticket Granting Service (TGS).

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

Расширение PKINIT позволяет использовать двухфакторную аутентификацию по токенам или смарт-картам на этапе предаутентификации Kerberos.

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

Все контроллеры доменов должны иметь установленный сертификат Domain Controller Authentication, или Kerberos Authentication, т. к. реализуется процесс взаимной аутентификации клиента и сервера.

Практика:

Приступим к настройке.

Сделаем так, чтобы в домен под вашей учетной записью можно было зайти только по предъявлению токена и зная PIN-код.

Для демонстрации мы будем использовать Рутокен ЭЦП PKI производства компании «Актив».

1 Этап — Настройка домена Первым делом установим службы сертификации.

Дисклеймер.

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

Все контроллеры доменов и все клиентские компьютеры в рамках леса, где осуществляется внедрение такого решения, обязательно должны доверять корневому Удостоверяющему Центру (Центру Сертификации).

Задача центра сертификации — подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи.

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

Удостоверяющий центр, выдающий сертификаты для использования смарт-карт или токенов, должен быть помещен в хранилище NT Authority.

Зайдите в Диспетчер сервера и выберите «Добавить роли и компоненты».

При добавлении ролей сервера выберите «Службы сертификации Active Directory» (Microsoft категорически рекомендует не делать это на контроллере домена, дабы не огрести проблем с производительностью). В открывшемся окне выберите «Добавить компоненты» и выберите пункт «Центр сертификации».

На странице для подтверждения установки компонентов нажмите «Установить».

2 Этап — Настройка входа в домен с помощью токена

Для входа в систему нам понадобится сертификат, который содержит идентификаторы Smart Card Logon и Client Authentication.

Сертификат для смарт-карт или токенов также должен содержать UPN пользователя (суффикс имени участника-пользователя). По умолчанию суффиксом имени участника-пользователя для учетной записи является DNS-имя домена, которое содержит учетную запись пользователя.

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

В сертификате должен быть указан путь к точке распространения списка отзыва сертификатов (CRL distribution point). Такой файл содержит список сертификатов с указанием серийного номера сертификата, даты отзыва и причины отзыва. Он используется для передачи сведений об отозванных сертификатах пользователям, компьютерам и приложениям, пытающимся проверить подлинность сертификата.

Настроим установленные службы сертификации. В правом верхнем углу нажмите на желтый треугольник с восклицательным знаком и щелкните «Настроить службы сертификации…».

В окне «Учетные данные» выберите необходимые учетные данные пользователя для настройки роли. Выберите «Центр сертификации».

Выберите «ЦС предприятия».

ЦС предприятия интегрированы с AD. Они публикуют сертификаты и списки отзыва сертификатов в AD.

Укажите тип «Корневой ЦС».

На следующем этапе выберите «Создать новый закрытый ключ».

Выберите период действия сертификата.

3 этап — Добавление шаблонов сертификатов

Для добавления шаблонов сертификатов откройте Панель управления, выберите пункт «Администрирование» и откройте Центр сертификации.

Щелкните по названию папки «Шаблоны сертификатов», выберите пункт «Управление».

Щелкните по названию шаблона «Пользователь со смарт-картой» и выберите пункт «Скопировать шаблон». На следующих скриншотах показано, какие параметры в окне «Свойства нового шаблона» необходимо изменить.

Если в списке поставщиков нет «Aktiv ruToken CSP v1.0», то необходимо установить комплект «Драйверы Рутокен для Windows».

Начиная с Windows Server 2008 R2 вместо специального провайдера от производителя можно использовать «Microsoft Base Smart Card Crypto Provider».

Для устройств Рутокен библиотека «минидрайвера», поддерживающая «Microsoft Base Smart Card Crypto Provider», распространяется через Windows Update.

Проверить установился ли «минидрайвер» на вашем сервере можно подключив Рутокен к нему и посмотрев в диспетчер устройств.

Если «минидрайвера» по каким-то причинам нет, его можно установить принудительно, инсталлировав комплект «Драйверы Рутокен для Windows», а после этого воспользоваться «Microsoft Base Smart Card Crypto Provider».

Комплект «Драйверы Рутокен для Windows» распространяется бесплатно с сайта Рутокен .

Добавьте два новых шаблона «Агент сертификации» и «Пользователь с Рутокен».

Для этого выйдите из окна «Управления шаблонами». Нажмите правой кнопкой мыши на «Шаблоны сертификатов» и выберите пункт меню «Создать» и подпункт «Выдаваемый шаблон сертификата».

Далее выберите «Агент регистрации» и «Пользователь с Rutoken» и нажмите «ОК».

В результате названия этих шаблонов отобразятся в центре сертификации.

Далее нам необходимо выписать сертификат администратору домена. Откройте службу «Выполнить» и укажите команду mmc. Добавьте оснастку «Сертификаты».

В окне «Оснастки диспетчера сертификатов» выберите «моей учетной записи пользователя». В окне «Добавление и удаление оснастки» подтвердите добавление сертификатов.

Выберите папку «Сертификаты».

Запросите новый сертификат. Откроется страница для регистрации сертификата. На этапе запроса сертификата выберите политику регистрации «Администратор» и нажмите «Заявка».

Таким же образом запросите сертификат для Агента регистрации.

Чтобы запросить сертификат для определенного пользователя щелкните «Сертификаты», выберите пункт «Зарегистрироваться от имени…».

В окне для запроса сертификата установите флажок «Пользователь с Рутокен».

Теперь необходимо выбрать пользователя.

В поле «Введите имена выбранных объектов» укажите имя пользователя в домене и нажмите «Проверить имя».

В окне для выбора пользователя нажмите «Заявка».

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

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

4 этап — Настройка учетных записей пользователей

Для настройки учетных записей откройте список пользователей и компьютеров AD.

Выберите папку Users и пункт «Свойства».

Перейдите на вкладку «Учетные записи», установите флажок «Для интерактивного входа в сеть нужна смарт-карта».

Настройте политики безопасности. Для этого откройте Панель управления и выберите пункт «Администрирование». Откройте меню для управления групповой политикой.

В левой части окна «Управление групповой политикой» щелкните «Default Domain Policy» и выберите пункт «Изменить».

В левой части окна «Редактор управления групповыми политиками» выберите пункт «Параметры безопасности».

Откройте политику «Интерактивный вход в систему: требовать смарт-карту».

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

Откройте политику «Интерактивный вход в систему: поведение при извлечении смарт-карты».

На вкладке «Параметры политики безопасности» установите флажок «Определить следующий параметр политики», из раскрывающегося списка выберите «Блокировка рабочей станции».

Перезагрузите компьютер. И при следующей попытке аутентификации в домене уже можно будет использовать токен и его PIN-код.

BINGO!

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

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

---

Рубрика: Администрирование /  #10 лет назад

Facebook Twitter Мой мир Вконтакте Одноклассники Google+

 СТАНИСЛАВ ШПАК, более десяти лет занимается сопровождением Active Directory и Windows-серверов

Внедряем смарт-карты в домене

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

Ранее в «Системном администраторе» я рассматривал процесс развертывания системы PKI в домене [1-3]. Опираясь на эту структуру, сейчас рассмотрим процесс внедрения смарт-карт в домене.

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

Рисунок 1. Диалог входа в Windows при использовании смарт-карты

Существуют две категории смарт-карт: карты памяти и микропроцессорные карты. Первая категория содержит только энергонезависимую память, вторая – еще и микропроцессор. Любой крупный производитель смарт-карт выпускает карты обоих типов, поэтому обращайте внимание на спецификацию. Микропроцессорные карты, кроме хранения информации, могут еще производить различные вычислительные операции. Нас интересует подмножество микропроцессорных карт – криптографические карты (микропроцессорные карты, производящие криптографические операции). Они существенно повышают безопасность системы, так какв этом случае закрытый ключ (private key) не покидает пределы смарт-карты.

Обычная смарт-карта по форм-фактору представляет собой аналог банковской пластиковой карточки. Считывание данных с такой смарт-карты производится специальным устройством – «смарт-карт-ридером», в который помещается смарт-карта. В настоящее время все шире используется другой вариант исполнения смарт-карты – USB-токен. Внешне он очень похож на обычный USB-флеш-накопитель: совмещает в себе смарт-карту плюс карт-ридер и вставляется непосредственно в USB-разъем компьютера без каких-то дополнительных устройств. USB-токен кажется удобнее, однако на обычную смарт-карту можно нанести информацию осотруднике и использовать еще и как удостоверение личности. Какой вариант лучше – решать вам, каждый имеет свои плюсы и минусы, причем в зависимости от условий применения. Например, в случае использования USB-токенов нет необходимости оборудовать рабочие места смарт-карт-ридерами, и это может быть как плюсом, так и минусом. Все, о чем будет говориться далее в статье, одинаково применимо как к обычным «пластиковым» смарт-картам, так и к USB-токенам.

Приложения в Windows работают со смарт-картами по следующей цепочке [4]: «Приложение → Поставщик служб для смарт-карты (Smart Card Service Provider) → Менеджер ресурсов смарт-карты (Smart Card Resource Manager (Win32API)) → Драйвер карт-ридера → Карт-ридер → Смарт-карта».

В этой цепочке между приложением и менеджером ресурсов (который представляет собой Windows-компонент) располагаются поставщик служб смарт-карты и, в частности, его подмножество: «поставщик служб криптографии» (CSP – Cryptography Service Provider). Это программный компонент, который должен быть написан производителем смарт-карты с помощью программного интерфейса Microsoft CryptoAPI. В стандартную комплектацию Windows XP и 2003 входит поддержка CSP только для шести моделей смарт-карт от трех производителей (Gemplus, Infineon и Schlumberger). Таким образом, мы приходим к тому, что в среде Windows поддерживаются только смарт-карты, CSP которых был разработан с использованием MS CryptoAPI и установлен в системе.

Поскольку вряд ли вам удастся приобрести смарт-карты вышеназванных моделей, то важный вывод, который мы сделаем здесь и к которому еще вернемся позже: кроме смарт-карты, потребуется еще и CPS для нее, иначе Windows не сможет с ней работать. В этом случае вы получите ошибку: «The card supplied requires drivers that are not present on this system. Please try another card». (Имеющаяся плата требует наличия драйверов, отсутствующих в системе. Попробуйте использовать другую плату.)

Опустим особенности перевода слова «card» как «плата», из-за которого смысл ошибки на русском языке несколько искажается. Кроме того, смарт-карту перед использованием надо инициализировать – штатных средств для этого в Windows также не предусмотрено, поэтому вопрос сопутствующего программного обеспечения надо оговаривать с поставщиком смарт-карт заранее.

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

• Active Directory;
• микропроцессорная смарт-карта (плюс смарт-карт ридер) или USB-токен;
• драйверы карт-ридера и программное обеспечение смарт-карты;
• развернутая в домене инфраструктура открытого ключа (подразумевает наличие хотя бы одного центра сертификации уровня предприятия (enterprise CA);
• наличие сертификатов типа enrollment agent (агент подачи заявок), позволяющих выпускать сертификаты от имени других пользователей.

Теперь рассмотрим подробно все вышеперечисленные пункты, кроме, разве что, Active Directory.

Минимум настроек, который может понадобиться, мы рассмотрим в конце статьи.

Выбор смарт-карты и подготовка компьютера

Для начала нам надо определиться, какой тип смарт-карты мы хотим использовать. Будут ли это обычные пластиковые смарт-карты, либо USB-токен, и какой объем памяти должен быть на смарт-карте.

Имейте в виду, что около 16 Кб будет занимать операционная система смарт-карты, а место, занимаемое пользовательским сертификатом, будет зависеть от длины ключа. Конечно, даже на смарт-карте с 32 Кб памяти хватит места для размещения сертификата пользователя, однако не надо забывать, что на ней можно хранить и дополнительные данные.

Для пробы я решил воспользоваться обоими видами смарт-карт и приобрел 64 Кб смарт-карту Siemens и USB-карт-ридер для нее, а также 64 Кб USB-токен Charismatic. В комплектацию поставки пластиковой смарт-карты входила только сама карта, а к токену еще прилагался комплект ПО. Карт-ридер также поставлялся без драйверов, однако на сайте продавца были все необходимые ссылки на сайт производителя, где без труда удалось раздобыть драйвер для Windows XP.

Здесь будет весьма уместно вспомнить о том, что для смарт-карты потребуется еще и CSP. Поскольку к смарт-карте никакого ПО не прилагалось, то Windows отказалась записывать на смарт-карту данные, поскольку карта была не инициализирована и CSP для нее не был установлен в системе.

Исследование Интернета на предмет нужного ПО показало, что таковое имеется, но является платным – например, комплект нужного ПО для Siemens CardOS стоил чуть меньше 20$ с лицензией на 1 ПК.

Не будучи уверенным, что все понял правильно, я связался с поставщиком смарт-карт, где меня заверили, что так оно и есть, но они предоставляют ПО от Charismatic, которое работает не только с одноименными токенами, но и с некоторыми смарт-картами. Действительно, так и оказалось, однако скачать это ПО с сайта производителя было нельзя и пришлось получать его от поставщика смарт-карт. Имейте это в виду.

Итак, действия, которые нужно выполнить на этом шаге: подключить и установить драйверы карт-ридера либо USB-токена (для него тоже могут понадобиться драйверы), установить прилагаемое ПО, которое как минимум должно включать в себя СSP (обычно один или несколько dll-файлов) и пользовательский интерфейс для инициализации и работы со смарт-картой/токеном. Инициализировать смарт-карту или токен – требуемые действия тут могут отличаться в зависимости от используемого ПО. На рис. 2 представлен пример инициализации токена с помощью программы Charismatic Smart Security Interface Manager.

Рисунок 2. Инициализация смарт-карты

Настройка доменного окружения

Теперь перейдем к настройке доменного окружения. В качестве PKI в домене будем опираться на структуру, которая рассматривалась в [1-3]. Напомню, что речь шла о цепочке из трех серверов сертификации, первые два из которых были изолированные корневой и подчиненный центры сертификации (Certificate Authority – СА), а третий – подчиненный СА уровня предприятия с именем EntCA. Все настройки, связанные с внедрением смарт-карт, будут выполняться именно на этом СА.

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

Сертификаты, позволяющие запрашивать пользовательские сертификаты для смарт-карты, – это Enrollment Agent (агент подачи заявок) и Enrollment Agent (Computer) (агент подачи заявок (компьютер)). Первый устанавливается в локальное хранилище сертификатов пользователя, второй – в локальное хранилище сертификатов компьютера, с которого будет производиться запрос сертификатов для смарт-карты. Чтобы выпустить сертификаты типа Enrollment Agent, надо подготовить их шаблоны. Процедура аналогична описанной в [3]. Скажу лишь, что ввиду высокой важности рекомендуется права на выпуск этого типа сертификатов дать лишь одному пользователю и одному компьютеру – тому, который и будет заниматься выпуском смарт-карт.

Кроме того, надо подготовить шаблоны сертификатов пользователя для смарт-карты. Существует два таких шаблона: Smartcard Logon (вход со смарт-картой) и Smartcard User (пользователь со смарт-картой). Первый используется только для входа в систему по смарт-карте, второй – для входа в систему и шифрования. Проверьте, что для выбранного вами шаблона имеются права Enroll (выпуск) для доменной группы EnrollmentAgent.

Выпуск смарт-карты

Для выпуска смарт-карты на рабочую станцию, у которой есть право Enroll для шаблона Enrollment Agent (Computer), в систему должен войти пользователь, имеющий право Enroll для шаблона Enrollment Agent. Далее через веб-интерфейс нужно обратиться к центру сертификации (в нашем случае это адрес http://EntCA/certsrv, где EntCA – имя сервера). Имеет смысл предварительно добавить этот адрес в список доверенных узлов в настройке безопасности браузера, иначе потом можно столкнуться с блокированием ActiveX-компонента.

На открывшейся странице из списка предложенных вариантов надо выбрать Request a certificate (запрос сертификата), тем самым перейдя на страницу с тремя пунктами, последний из которых Request a certificate for a smart card on behalf of another user by using the smart card certificate enrollment station (запросить сертификат для смарт-карты от имени другого пользователя, используя станцию подачи заявок смарт-карт). Остановимся в этом месте подробнее (см. рис. 3).

Рисунок 3. Страница выбора вариантов для запроса сертификата

Я очень много времени провел в поисках причины того, почему на этой странице в моем случае были только первые два пункта и отсутствовал третий. Причем в тестовом домене он был, а в рабочем – нет. Не найдя ничего связного в Интернете, пришлось обратиться к файлам, формирующим веб-страницу СА. Оказалось, что проблема кроется в файле certrqad.asp, который находится в %SYSTEMROOT%system32certsrv. При сравнении этого файла между тестовым и корпоративным СА оказалось, что в рабочем отсутствует следующий раздел:

<% If bNewThanNT4 And "Enterprise"=sServerType Then %>
<TR>
	<TD><Img Src="certspc.gif" Alt="" Height=10 Width=1></TD>
</TR>
<TR>
	<TD><A Href="certsces.asp"><LocID ID=locLblSmartcard>
	Request a certificate for a smart card on behalf of another user
	by using the smart card certificate enrollment station.</LocID></A>
	<LocID ID=locAdminWarn><Font Size=-1><BR>
	Note: You must have an enrollment agent certificate to submit a
	request on behalf of another user.</Font></LocID>
	</TD>
</TR>
<%End If%>

В статье [3] я писал о том, что СА под управлением Windows Server 2003 не совместим с Windows Vista, и говорил о необходимости установки обновления KB922706 для Windows 2003. Однако, как оказалось, именно после установки этого обновления с веб-страницы СА пропадает пункт запроса сертификата для смарт-карты.

Решение проблемы заключается в том, чтобы вручную добавить эту часть в файл certrqad.asp или же восстановить его из соответствующей папки резервной копии, которая создается автоматически в %Systemroot% при установке каждого обновления. После этого, возможно, потребуются перезапуск служб IIS на сервере и очистка кэша браузера на клиенте.

Итак, с этой проблемой мы разобрались, выбираем третий пункт и попадаем на страницу Smart Card Certificate Enrollment Station (станция подачи заявок смарт-карт) (см. рис. 4). Здесь надо выбрать, какой шаблон использовать (Smartсard User или Smartсard Logon), указать выпускающий СА и выбрать поставщика служб криптографии. В выпадающем списке CSP надо выбрать именно тот CSP, который устанавливался для вашего типа смарт-карты, иначе процесс записи сертификата на смарт-карту окончится неудачей. Если на компьютере установлен более чем один сертификат типа Certificate Request Agent, то в поле Administrator Signing Certificate (сертификат подписи администратора) можно выбрать сертификат нужного администратора.

Рисунок 4. Запрос сертификата для смарт-карты

Ну и самое главное – в разделе User to enroll (заявляемый пользователь) надо выбрать пользователя, чей сертификат будет помещен на смарт-карту. Когда это будет сделано, справа внизу страницы появится кнопка Enroll (подать заявку), после нажатия на которую система попросит вас вставить смарт-карту, ввести PIN-код (устанавливаемый при инициализации) и произведет на нее запись всех нужных данных.

Замечание: в среде Windows не существует штатных средств по смене PIN-кода смарт-карты, эти средства обычно поставляются в составе ПО смарт-карты.

Использование смарт-карты

Теперь мы имеем рабочую смарт-карту с сертификатом пользователя. Для того чтобы начать ее использовать, не требуется никаких особых настроек на компьютере пользователя, кроме установки драйверов для смарт-карт-ридера и ПО смарт-карты. После этого достаточно вставить смарт-карту в карт-ридер (или токен в USB-разъем), как стандартное окно запроса пароля при входе в систему сменится на запрос PIN-кода (см. рис. 5).

Рисунок 5. Вход в систему с использованием смарт-карты

Сменить PIN-код пользователь может с помощью ПО смарт-карты. В случае если PIN-код забыт, администратор с помощью административного пароля может установить новый PIN-код, а если утерян и административный PIN-код, можно повторно инициализировать смарт-карту с помощью системного PIN-кода. В этом случае все данные, содержащиеся на смарт-карте, будут уничтожены. Если утерян и системный PIN-код, смарт-карту можно смело выбрасывать.

На одну смарт-карту можно поместить несколько сертификатов, однако для входа в систему Windows XP/2003 будет использоваться только один – так называемый «контейнер по умолчанию». Его можно определить с помощью ПО смарт-карты. Для Windows Vista этого ограничения уже нет – в этой ОС можно указать, какой сертификат из имеющихся на карте нужно использовать для входа – по крайней мере это заявлено в документации.

Смарт-картой можно пользоваться и при входе на удаленные компьютеры по RDP-протоколу. Для этого в свойствах RDP-подключения надо на вкладке Local Resources (локальные ресурсы) нажать кнопку More (еще) и установить опцию Smart Card (смарт-карта) – однако и тут надо помнить о том, что на удаленном компьютере должно стоять все необходимое для работы смарт-карты ПО, иначе вы получите ошибку, о которой говорилось ранее в разделе «Общие сведения».

Что касается пользовательских настроек Active Directory, то для работы со смарт-картами предусмотрены две опции. Обе доступны в ветке: Local Computer Policy → Computer Configuration → Windows Settings → Security Settings → Local policies → Security Options («Локальная политика компьютера → Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Локальные политики → Параметры безопасности»).

Первая опция Interactive logon: Require smart card (вход в систему: требуется смарт-карта) может принимать состояние Enable (включено) или Disable (выключено) и при включении означает безусловную необходимость в смарт-карте при входе в систему. В этом случае без смарт-карты пользователь не сможет осуществить вход. Это надо иметь в виду, так как может возникнуть ситуация, когда пользователь забыл или потерял смарт-карту, или же требуется войти в домен через компьютер, на котором не установлены драйвер карт-ридера или ПО смарт-карты.

Вторая опция: Interactive logon: Smart card removal behavior (вход в систему: поведение при извлечении смарт-карты) означает поведение рабочей станции при изъятии смарт-карты из карт-ридера. Допустимыми состояниями являются No action (бездействие), Lock workstation (блокировка рабочей станции) и Force Logoff (выход из системы). Эта опция работает только при включенной первой опции.

Как я уже говорил, применение смарт-карты не ограничивается только входом в систему. В настоящее время многие приложения умеют хранить сертификаты на смарт-карте, например Mozilla Firefox, OpenVPN, TrueCrypt и др. Как использовать смарт-карту – это уже решать вам, но надеюсь, что эта статья поможет вам в самом начале процесса внедрения смарт-карт в домене.

1. Шпак С. Установка цепочки серверов сертификации как часть внедрения PKI в домене. Часть 1. //«Системный администратор», № 8, 2008 г. – С. 54-58. URL: http://samag.ru/archive/article/1764.
2. Шпак С. Установка цепочки серверов сертификации как часть внедрения PKI в домене. Часть 2. //«Системный администратор», № 10, 2008 г. – С. 60-64. URL: http://samag.ru/archive/article/1852.
3. Шпак С. Установка цепочки серверов сертификации как часть внедрения PKI в домене. Часть 3. //«Системный администратор», № 11, 2008 г. – С. 66-69. URL: http://samag.ru/archive/article/1874.
4. Smart Cards – http://technet.microsoft.com/en-us/library/dd277362.aspx.
5. Deploying Smart Cards – http://technet.microsoft.com/ru-ru/library/dd277383(en-us).aspx.
6. Blog about Smart Card infrastructure in Windows – http://blogs.msdn.com/shivaram.

Ключевые слова: smart cards, PKI, смарт-карта, домен.

Permalink

Cannot retrieve contributors at this time

title	description	ms.prod	author	ms.author	ms.reviewer	manager	ms.topic	ms.localizationpriority	ms.date	appliesto	ms.technology
How Smart Card Sign-in Works in Windows	This topic for IT professional provides links to resources about the implementation of smart card technologies in the Windows operating system.	windows-client	paolomatarazzo	paoloma	ardenw	aaroncz	article	medium	09/24/2021	✅ <b>Windows 10</b> ✅ <b>Windows 11</b> ✅ <b>Windows Server 2016</b> ✅ <b>Windows Server 2019</b> ✅ <b>Windows Server 2022</b>	itpro-security

This topic for IT professional provides links to resources about the implementation of smart card technologies in the Windows operating system. It includes the following resources about the architecture, certificate management, and services that are related to smart card use:

• Smart Card Architecture: Learn about enabling communications with smart cards and smart card readers, which can be different according to the vendor that supplies them.

• Certificate Requirements and Enumeration: Learn about requirements for smart card certificates based on the operating system, and about the operations that are performed by the operating system when a smart card is inserted into the computer.

• Smart Card and Remote Desktop Services: Learn about using smart cards for remote desktop connections.

• Smart Cards for Windows Service: Learn about how the Smart Cards for Windows service is implemented.

• Certificate Propagation Service: Learn about how the certificate propagation service works when a smart card is inserted into a computer.

• Smart Card Removal Policy Service: Learn about using Group Policy to control what happens when a user removes a smart card.

Permalink

Cannot retrieve contributors at this time

title	description	ms.prod	author	ms.author	ms.reviewer	manager	ms.topic	ms.localizationpriority	ms.date	appliesto	ms.technology
How Smart Card Sign-in Works in Windows	This topic for IT professional provides links to resources about the implementation of smart card technologies in the Windows operating system.	windows-client	paolomatarazzo	paoloma	ardenw	aaroncz	article	medium	09/24/2021	✅ <b>Windows 10</b> ✅ <b>Windows 11</b> ✅ <b>Windows Server 2016</b> ✅ <b>Windows Server 2019</b> ✅ <b>Windows Server 2022</b>	itpro-security

This topic for IT professional provides links to resources about the implementation of smart card technologies in the Windows operating system. It includes the following resources about the architecture, certificate management, and services that are related to smart card use:

• Smart Card Architecture: Learn about enabling communications with smart cards and smart card readers, which can be different according to the vendor that supplies them.

• Certificate Requirements and Enumeration: Learn about requirements for smart card certificates based on the operating system, and about the operations that are performed by the operating system when a smart card is inserted into the computer.

• Smart Card and Remote Desktop Services: Learn about using smart cards for remote desktop connections.

• Smart Cards for Windows Service: Learn about how the Smart Cards for Windows service is implemented.

• Certificate Propagation Service: Learn about how the certificate propagation service works when a smart card is inserted into a computer.

• Smart Card Removal Policy Service: Learn about using Group Policy to control what happens when a user removes a smart card.

Проблема аутентификации доступа к информационным ресурсам является на сегодня весьма актуальной. Защиты с помощью пароля нередко оказывается недостаточно, ее требуется усиливать. Операционная система Microsoft Win-dows 2000 позволяет усовершенствовать процесс аутентификации пользователей с помощью смарт-карт, но при этом требуется наличие устройства чтения — ридера. Есть и другие варианты, и один из них предполагает использование электронных USB-ключей eToken компании «Аладдин», которые являются полнофункциональным аналогом одновременнно смарт-карт и устройств чтения/записи для работы со смарт-картами.

Смарт-карта или eToken

Термин «смарт-карта» используется для обозначения устройств размером с кредитную карточку, обладающих различными возможностями: карты для хранения данных, бесконтактные карты и карты на основе интегральных микросхем (integrated circuit cards, ICC). Все они отличаются друг от друга, а также от традиционных карт с магнитной полосой, обычно используемых для обслуживания банковского счета.

На персональном компьютере и в среде Windows 2000 используются карты на основе интегральных микросхем, так как они могут выполнять сложные криптографические операции. Смарт-карта — это, по существу, миниатюрный компьютер с ограниченной памятью и возможностью обработки данных, заключенный в форму пластиковой кредитной карточки. Обмен данными между смарт-картой и приложением, работающим на компьютере, осуществляется через полудуплексный последовательный интерфейс, управляемый приемным устройством с помощью соответствующего драйвера. Устройства для чтения смарт-карт достаточно разнообразны и могут подсоединяться к компьютеру с помощью интерфейса RS-232, PCMCIA или USB.

eToken — это первый полнофункциональный аналог смарт-карты, выполненный в виде брелка. Он напрямую подключается к компьютеру через порт Universal Serial Bus (USB) и не требует наличия дорогостоящих устройств считывания или других дополнительных устройств. Более подробная информация о моделях eToken приведена во врезках «Познакомимся поближе» и «Преимущества eToken перед смарт-картами».

Смарт-карты являются важнейшим компонентом инфраструктуры открытых ключей (PKI), интегрированной Microsoft в Windows 2000. Смарт-карты расширяют возможности программной аутентификации. Аналогичными функциями обладает и eToken, который обеспечивает:

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

eToken может использоваться для аутентификации пользователя в домене Windows 2000 в трех случаях:

• интерактивный вход в систему (interactive logon), при котором задействуются каталог Active Directory, протокол Kerberos версии 5 и сертификат открытого ключа;
• удаленный вход в систему (remote logon), использующий сертификат открытого ключа, протокол Extensible Authentication Protocol — Transport Layer Security (EAP-TLS) для идентификации удаленного пользователя, учетная запись которого хранится в каталоге Active Directory;
• аутентификация клиента (client authentication) — процесс взаимной идентификации пользователя и домена с помощью сертификата открытого ключа, сопоставленного с хранящейся в каталоге Active Directory учетной записью.

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

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

Интерактивный вход в систему

При подключении eToken к USB-порту Windows 2000 «понимает», что теперь, вместо имени пользователя, имени домена и пароля, необходимо запросить персональный идентификационный номер (Personal Identification Number, PIN), см. Экран 1. Это событие эквивалентно нажатию сочетания клавиш Ctrl-Alt-Del, инициирующему процедуру входа в систему с использованием пароля. Однако PIN, который указывается в диалоговом окне при входе в систему, обеспечивает аутентификацию только по отношению к eToken, но не к домену.

Экран 1. Окно ввода PIN-кода к eToken.

Сертификат открытого ключа, хранящийся в защищенной памяти eToken, используется для аутентификации в домене с применением протокола Kerberos версии 5 и его расширения PKINIT.

Запрос на вход в систему

После того как пользователь вводит в окне регистрации PIN, операционная система определяет, может ли пользователь быть идентифицирован и аутентифицирован на основе предъявленной им удостоверяющей информации (PIN и eToken). При запросе на вход в систему сначала происходит обращение к локальной системе безопасности (LSA), которая передает запрос пакету аутентификации Kerbe-ros, запущенному на клиентском компьютере. Пакет Kerberos посылает запрос службе аутентификации Key Distribution Center (KDC), функционирующей на контроллере домена, для аутентификации и получения билета TGT (билет начального уровня — Ticket Granting Ticket). В состав запроса к службе аутентификации (Authentication Service, AS), в те его поля, которые предшествуют идентификационным, помещается сертификат пользователя, обнаруженный в памяти eToken. Удостоверение, включенное в эти поля, заверяется цифровой подписью с использованием личного ключа пользователя так, чтобы KDC могла проверить запрос, отправленный владельцем сертификата.

Проверка сертификата

Перед тем как удовлетворить запрос, служба AS, прежде всего, должна проверить происхождение сертификата и убедиться в том, что он заслуживает доверия. KDC использует CryptoAPI, чтобы проследить путь от пользовательского сертификата к сертификату корневого центра сертификации (CA). Если KDC по тем или иным причинам (например, корневой сертификат недействителен, невозможно найти родительские сертификаты или определить, не аннулирован ли сертификат) окажется не в состоянии построить допустимую цепочку сертификатов, то она вернет сообщение об ошибке и откажет в удовлетворении запроса.

KDC также должна проверить, уполномочен ли центр сертификации, выдавший сертификат, выдавать сертификаты для аутентификации в домене. В Windows 2000 для аутентификации с помощью eToken источником сертификатов должен быть корпоративный центр сертификации, который опубликован в Active Directory. Это требуется для предотвращения выдачи сертификатов в пространстве имен другого домена ложными центрами сертификации, действительными только в одной из иерархий. Хотя предпринять подобного рода атаку исключительно сложно, так как это зависит от получения ложным центром сертификации прав на издание от законного родительского центра сертификации, решение запрашивать корпоративный CA, опубликованный в Active Directory, было принято во избежание самой возможности вторжения.

Проверка цифровой подписи

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

Поиск учетной записи и билет TGT

Убедившись, что пользователь является тем, за кого себя выдает, и что сертификат может быть использован для аутентификации в домене, служба KDC запрашивает в каталоге домена учетную запись. KDC ищет учетную запись пользователя в Active Directory по основному имени пользователя (User Principal Name, UPN), которое указано в поле альтернативного имени (Subject Alternative Name) в пользовательском сертификате открытого ключа. Учетная запись, которую KDC получает от службы каталога, используется для формирования билета TGT. Билет TGT будет включать идентификатор безопасности пользователя (Security ID, SID), SID всех групп, членом которых пользователь является. Список SID внесен в поля данных авторизации TGT.

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

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

Автономная регистрация в системе (Offline Logon)

Когда пользователь отсоединен от сети или контроллер домена недоступен, пользователь должен сохранить возможность зарегистрироваться на своем компьютере автономно. Такая возможность обеспечивается с помощью паролей путем сравнения хешированного пароля, сохраняемого локальной системой безопасности, с хешем удостоверения, которое пользователь предъявляет Graphical Identification and Authentication (GINA) в процессе автономной регистрации в системе. Если сравниваемые данные совпадают, пользователь получает доступ к локальной машине.

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

Аутентификация клиента

Поскольку поддержка eToken интегрирована в CryptoAPI, протоколам Secure Sockets Layer (SSL) и Transport Layer Security (TLS) не нужно «знать» что-либо об eToken для того, чтобы работать с ним. Роль eToken в процессе аутентификации клиента состоит в том, чтобы подписать часть данных протокола на начальной стадии сеанса обмена данными по протоколу SSL. Поскольку закрытый ключ, соответствующий сертификату открытого ключа, хранится в памяти eToken, подобный метод аутентификации является более строгим, так как применение закрытого ключа требует от владельца eToken подтверждения прав доступа и к eToken, и к домену. Кроме того, операции с закрытым ключом, выполняемые на начальной стадии сеанса обмена данными, реализуются eToken таким образом, что закрытый ключ никогда не передается компьютеру или в локальную сеть.

Взаимная аутентификация

Оба протокола, SSL 3.0 и TLS 1.0, поддерживают взаимную аутентификацию, что для клиента означает возможность проверить подлинность сервера, а для сервера — подлинность клиента.

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

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

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

Авторизация

При аутентификации клиента в Win-dows 2000 с применением открытых ключей используются данные из сертификата клиента для получения информации о его правах доступа в домене.

Когда установлен сеанс SSL или TLS, провайдер безопасного канала (secure channel provider) прежде всего пытается, исходя из UPN сертификата, найти учетную запись пользователя в каталоге домена. UPN включено в сертификат в поле альтернативного имени субъекта (Alternative Subject Name), оно определяет точное имя учетной записи пользователя (префикс) и имя домена, в котором расположена учетная запись (суффикс). Так же как при входе в систему с помощью eToken на основе Kerberos, источник сертификатов должен иметь полномочия на выпуск сертификатов для домена, чтобы им можно было доверять при идентификации и проверке полномочий.

Если нет соответствия UPN или СА не уполномочен издавать сертификаты для аутентификации в домене, провайдер пытается запросить в каталоге поиск учетной записи, у которой атрибут Alternate Security Iden-tities содержит явное указание на соответствие сертификату клиента. Явное указание сертификата в учетной записи пользователя требует дополнительных действий со стороны ад министратора. Соответствие сертификату клиента может быть основано либо на имени источника, либо на источнике и субъекте в сертификате. Учетная запись может иметь один или более связанных с ней сертификатов, что упрощает применение одной учетной записи несколькими пользователями. Сертификат не может соответствовать нескольким учетным записям, хранящимся в каталоге домена. Аутентификация не будет выполнена, если сертификат соответствует более чем одной учетной записи.

Удаленный доступ

Поддержка расширяемой аутентификации для удаленных пользователей в Windows 2000 обеспечивается службой удаленного доступа RAS. Сервер удаленного доступа поддерживает протокол аутентификации EAP и обеспечивает модулям различных производителей возможность поддержки разнообразных методов аутентификации (см. Экран 2).

Экран 2. Выбор метода аутентификации.

Windows 2000 содержит встроенный модуль для поддержки eToken, что позволяет обеспечить строгую аутентификацию удаленных пользователей. Замечу, что удаленный доступ к системе фактически означает две аутентификации: на сервере RAS и в сети.

Первая аутентификация завершается подтверждением аутентификации сер-вера RAS клиентом и установлением соединения между клиентом и сервером. В результате клиенту сопоставляются некоторые политики RAS и атрибуты учетной записи. Атрибуты учетной записи применяются индивидуально и включают такие свойства, как права доступа, режимы обратного вызова (callback options), статические маршруты (static routes) и т. д. Политики RAS определяют основные принципы взаимодействия сервера с клиентом. Это позволяет управлять пользователями, обеспечивая соответствие свойств подключения, группового членства, профиля и т. д.

Вторая аутентификация относится к домену и использует TLS в качестве протокола аутентификации вместо Kerberos. Аутентификация в домене с использованием EAP-TLS очень похожа на аутентификацию по протоколу SSL, за исключением того, что сертификат открытого ключа должен содержать UPN, соответствующее учетной записи, хранящейся в доменном каталоге Active Directory.

Политики безопасности

В домене Windows 2000 имеется несколько типов политик, определяющих процедуры работы с eToken.

Обязательное использование eToken. Windows 2000 поддерживает на уровне отдельного пользователя политику учетных записей, требующую обязательного использования eToken для интерактивной регистрации в системе (см. Экран 3).

Экран 3. Установка обязательного использования eToken.

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

Режим обязательного использования eToken, обусловленный политикой учетной записи при интерактивной регистрации, должен быть установлен для пользователей, являющихся членами группы Users и применяющих eToken для регистрации в домене Windows 2000.

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

Политика извлечения смарт-карты (или eToken) — это локальная политика, действие которой распространяется на компьютер, а не на учетную запись пользователя.

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

Экран 4. Выбор режима блокировки при отсоединении eToken.

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

А что делать, если пользователь забыл свой eToken дома? Возможность войти в здание по временному пропуску существенно отличается от того, что нужно для регистрации на компьютере для исполнения служебных обязанностей. Здесь может быть несколько вариантов.

Можно выдать временный eToken с сертификатом короткого срока действия, например на один день.

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

Персональные идентификационные номера

В то время как пароли обладают очевидными недостатками, в частности создаются пользователями на основе легко запоминаемых ассоциаций, PIN-коды eToken не подчиняются тем же правилам, что и «надежные пароли» (strong passwords), поскольку eToken не подвержены классическим атакам путем подбора слов.

Проблемы запоминания PIN-кода не существует, поскольку eToken блокирует многократные попытки ввести ошибочный PIN-код, аппаратно реализуя задержку (примерно 1 с) между вводами PIN-кода.

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

Благодаря способности eToken противостоять вышеописанным типам атак, часто менять PIN-код не требуется.

Станция регистрации eToken

Станция регистрации смарт-карт (то же относится и к eToken) работает как часть корпоративной службы центра сертификации в Windows 2000 Server и Windows 2000 Advanced Server. Она поддерживает централизованную выдачу eToken. Станция регистрации смарт-карт использует шаблоны сертификатов для определения того, какую информацию включать в тот или иной сертификат.

Для eToken существует два шаблона:

• eToken для регистрации (не может использоваться для защиты электронной почты);
• eToken пользователя.

Чтобы выдавать сертификаты для eToken, на предприятии должна существовать станция регистрации смарт-карт (eToken). Это требование обязательно, поскольку по умолчанию пользователи домена не могут регистрировать сертификаты eToken, выданные корпоративным ЦС Windows 2000.

Экран 5. Работа со станцией регистрации.

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

Для использования станции регистрации eToken Windows 2000, кто-то из сотрудников должен выполнять функции регистратора. Для того чтобы поддержать эти функции, корпоративный центр сертификации может выдать такому сотруднику сертификат регистратора. Данный сертификат обеспечивает более широкие полномочия по сравнению с другими, поскольку служащий с сертификатом регистратора имеет возможность зарегистрировать сертификат eToken любого пользователя домена, включая администратора. Поэтому рекомендуется, чтобы по умолчанию права доступа к шаблону сертификата регистратора предоставляли возможность регистрации только избранным сотрудникам.

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

Внедрение eToken

Использование в организации eToken позволяет существенно повысить безопасность сети за счет совершенствования методов аутентификации. К тому же пользователям больше не придется запоминать множество учетных записей (login) и паролей к различным ресурсам сети и приложениям. Нужно запомнить одно-единственное число — PIN-код к своему ключу eToken.

Максим Подлесный — руководитель отдела разработок компании Aladdin Software Security R.D. C ним можно связаться по адресу: it@aladdin.ru.

---

Познакомимся поближе

eToken имеет до 64 Кбайт защищенной энергонезависимой памяти (EEPROM) и может использоваться как портативный контейнер для хранения секретных данных (ключей шифрования, кодов доступа, сертификатов). eToken имеет уникальный серийный номер (ID) и может использоваться как электронный идентификатор (ключ) для аутентификации пользователя. eToken поддерживает работу и интегрируется со всеми основными системами и приложениями, использующими технологию Public Key Infrastructure (PKI).

eToken R2

eToken R2 имеет аппаратно реализованный алгоритм шифрования DESX со 120-разрядным ключом.

eToken Pro

eToken Pro, в отличие от R2, имеет дополнительный чип смарт-карты, аппаратно реализующий алгоритм шифрования RSA/1024, 3DES (TripleDES), SHA-1 и генератор личных (Private) ключей, никогда не покидающих микросхему.

В eToken Pro используется микросхема SLE66C Infineon, обеспечивающая исключительно высокий уровень безопасности, сертифицированный по ITSEC LE4.

В eToken Pro используется файловая система Siemens CardOS/M4, поддерживающая неограниченную иерархию объектов и файлов.

eToken RIC

В eToken RIC аппаратно реализованы криптографические алгоритмы шифрования ГОСТ 28147-89 (имеет сертификат соответствия ФАПСИ), включая диверсификацию и формирование сессионного ключа, а также DES и Triple DES.

назад

---

Преимущества eToken перед смарт-картами

Помимо функций смарт-карт eToken обладает дополнительными возможностями:

• не требует дорогостоящего устройства считывания и лишних проводов. Большинство устройств чтения смарт-карт подключается к компьютеру через последовательный порт RS-232, разъем PCMCIA Type II или шину USB. eToken напрямую подключается к компьютеру через USB-порт и не требует наличия дорогостоящих устройств считывания или других дополнительных устройств;
• имеет больше памяти (до 32 Кбайт) и может хранить несколько сертификатов (семь и более). Криптографические смарт-карты имеют ограниченный объем памяти, обычно от 2 до 16 Кбайт. Поскольку память пользуется большим спросом и довольно дорого стоит, производители карт ограничивают объем памяти, доступный одному приложению;
• различные приложения могут использовать один и тот же eToken. eToken поддерживает стандарт PC/SC и эмулирует смарт-карту и устройство считывания, что позволяет легко встраивать его как в существующие приложения, так и в новые. При работе с разными приложениями может использоваться уже имеющийся eToken. Необходимости в покупке дополнительных ключей нет. Потребуется лишь доплатить за лицензию на использование нужной программы;
• возможна одновременная работа с несколькими брелками eToken.

назад