PKI в WINDOWS 2000: ВЫЗОВ ИЛИ ПРИЗЫВ?

Зачем нужна встроенная поддержка PKI в Windows 2000, когда есть Baltimore Technologies, Verisign и Entrust? Однако сочетание общедоступных и частных сертификатов открывает новые возможности.

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

Эта критически важная часть общей проблемы контроля доступа называется авторизацией. Для обеспечения нормальной работы механизмы авторизации и аутентификации необходимо объединить. Таким образом, инфраструктура с открытыми ключами (Public Key Infrastructure, PKI) и серверы приложений должны дополнять друг друга. В Windows 2000 делается попытка достижения такого взаимодействия путем объединения технологий PKI, виртуальных частных сетей (Virtual Private Network, VPN), Web, аутентификации пользователей, электронной почты и смарт-карт.

ВОЗМОЖНОСТИ WINDOWS 2000

Microsoft проделала достойную похвалы работу по интеграции в операционную систему Windows 2000 приложений безопасности. В Windows 2000 включено немало средств обеспечения безопасности, таких, как защищенный Web, VPN, аутентификация пользователей, защищенная электронная почта, а также файловая система с шифрованием (Encrypted File System, EFS). Связующей технологией, которая делает все перечисленные средства еще более мощными, является встроенная в операционную систему поддержка PKI. В решении Windows 2000 присутствуют все типовые компоненты PKI, включая уполномоченного по регистрации (Registration Authority, RA), уполномоченного по сертификации (Certificate Authority, CA) и подчиненного уполномоченного по сертификации (Subordinate Certificate Authority, Sub-CA). Используя средства Windows 2000 Advanced Server, администраторы теперь могут создавать свои собственные закрытые иерархии CA, поддерживающие регистрацию, распространение и аннулирование цифровых сертификатов для большой базы пользователей.

В операционной системе Windows NT 4.0 концепция Microsoft относительно построения иерархий CA ограничивалась одним Sub-CA и одним CA. Функция RA обеспечивалась либо Sub-CA, либо CA по выбору администратора. Очевидно, что эта первая реализация не являлась масштабируемой и поэтому не могла рассматриваться в качестве корпоративной PKI. К счастью, с тех пор многое изменилось: к настоящему времени в Windows 2000 поддерживаются многоуровневые иерархии CA и Sub-CA, а также возможна установка нескольких уполномоченных по регистрации.

Иерархии CA и Sub-CA важны для разделения обязанностей и ответственности между компонентами сервера PKI. В то время, как один Sub-CA обрабатывает запросы на выдачу сертификатов для пользователей сети Intranet, другой мог бы заниматься только запросами на выдачу сертификатов, поступающих от серверов Intranet, а третий — обслуживать множество пользователей Extranet и Internet. Освобождение CA от этих функций и распределение их между несколькими Sub-CA означает, что CA мог бы сосредоточиться только на обработке запросов на сертификаты от Sub-CA (см. Рисунок 1).

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

Поддержка Web в Windows 2000 в основном остается такой же, как и в Windows NT 4.0. Сервер Web может быть сконфигурирован так, что пользователю для аутентификации необходимо будет предъявить подлинный цифровой сертификат. Подлинность цифрового сертификата определяется правомочностью организации, выпустившей сертификат, и свойствами самого сертификата. Правомочность издателя сертификата устанавливается на основании доверительного списка сертификатов (Certificate Trust List, CTL) в Microsoft Internet Information Server (IIS). В списке CTL можно активизировать такие известные сертификационные компании, как Verisign и GTE CyberTrust (недавно приобретенную компанией Baltimore Technologies), либо внести туда только вашего собственного главного уполномоченного по сертификации (старшего в иерархии). Выбор будет зависеть от степени вашей заинтересованности в привлечении сторонних поставщиков общедоступных услуг PKI.

В Windows 2000 поддерживается такая важная функция, как отображение сертификатов на учетные записи пользователей или групп пользователей IIS. Соответствие сертификатов и учетных записей может быть задано одним из двух способов. При первом подходе используется операция задания соответствия по схеме «многие к одному», когда нескольким сертификатам соответствует одна пользовательская учетная запись или группа. В другом варианте реализуется схема «один к одному», при которой один сертификат соответствует одной учетной записи пользователя или группы.

Каждый вариант имеет свои «за» и «против». Задание соответствия сертификатов по схеме «многие к одному» упростило бы процедуру развертывания благодаря возможности использования шаблонов подстановки (wildcards), однако при этом затруднило бы определение того, кем в действительности является прошедший аутентификацию пользователь. По этой причине схема «многие к одному» не очень подходит при необходимости ограничения доступа к достаточно важным данным. В свою очередь, отображение сертификатов по схеме «один к одному» обеспечивает точный учет аутентифицированных пользователей. Однако такой метод займет больше времени на развертывание, так как для каждого пользователя потребуется выполнить как минимум одно индивидуальное отображение.

Перед выполнением запросов на отображение как по схеме «сертификат — учетная запись», так и «сертификат — группа» сначала происходит обращение к правилам фильтрации IIS, на основании которых определяется правомочность такого отображения. Правила фильтрации разрешают или запрещают пользователям доступ на основании данных, содержащихся в их цифровых сертификатах X.509v3 (например, в сертификатах Windows 2000). В IIS правила фильтрации реализованы в виде списков контроля доступа (Access Control Lists, ACL) и предоставляют администратору возможность весьма гибко управлять доступом. Таким образом достигаются две цели: аутентификация пользователей-владельцев сертификатов и предоставление им адекватного уровня полномочий (в результате отображения сертификата на учетную запись пользователя или группы) немедленно после успешной аутентификации. Благодаря этой возможности в Windows 2000 прекрасно объединяются упомянутые выше процедуры аутентификации и авторизации.

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

Технология виртуальных частных сетей в Windows 2000 реализована таким образом, что у администратора имеется возможность выбора. Клиент и шлюз VPN поддерживают не только PKI, но и протоколы туннелирования, такие, как Point-to-Point Tunneling Protocol (PPTP) и Layer-2 Tunneling Protocol (L2TP), причем возможности последнего дополняются протоколом безопасности IPSec. Пара протоколов L2TP/IPSec позволяет передавать пакеты не только IP, но и других протоколов, например IPX и NetBEUI, при этом при передаче по туннелю протокол IPSec используется для проверки целостности, шифрования и аутентификации сообщения.

Процедура аутентификации в туннеле может быть настроена на использование цифровых сертификатов, смарт-карт или просто протоколов аутентификации Microsoft CHAP (Challenge Handshake Authentication Protocol) и Microsoft PAP (Password Authentication Protocol). (Прим. ред.: версии Microsoft PAP не существует как таковой. Кроме того, Windows 2000 поддерживает также стандартный CHAP.)

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

На отформатированных томах в Windows 2000 может устанавливаться файловая система с шифрованием (Encrypted File System, EFS). Если пользователь корректно вошел в систему, то доступ к данным, защищенным EFS, осуществляется в прозрачном режиме. Цифровой сертификат Windows 2000 играет для EFS простую роль: он требуется только для восстановления данных в случае сбоев в системе. Очевидно, что такая процедура может быть проведена только при условии предварительного сохранения копий сертификатов на внешних носителях (дискетах или надежных дисках). По умолчанию копии сертификатов для восстановления создаются для каждого нового пользователя и хранятся в службе каталогов Active Directory.

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

РАЗВЕРТЫВАНИЕ

Перед развертыванием PKI на базе Windows 2000 вам следует задать себе несколько вопросов.

• Какие приложения и процедуры вы хотите защитить с помощью средств PKI: Web, VPN, регистрацию пользователей или электронную почту?
• Кто будет вашими пользователями? Будут ли они работать в Intranet, Extranet, Internet или использовать комбинацию всего перечисленного?
• В какой степени вы можете полагаться на поставщиков общедоступных услуг PKI в вашем решении?
• Хватит ли у вас административных средств для поддержания собственной PKI?
• Какая модель регистрации будет использоваться: централизованная или распределенная?
• Является ли PKI наилучшим способом для достижения ваших целей повышения безопасности?

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

Вам потребуется также определить, в какой мере можно полагаться на внешних поставщиков PKI. К счастью, средства PKI в Windows 2000 поддерживают и поддерживаются поставщиками общедоступных услуг PKI (подробнее об этом — далее). Если же вы решаете построить собственное решение PKI, то вам потребуются администраторы, имеющие знания в этой области.

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

Уполномоченные по регистрации RA бывают двух видов: корпоративные и автономные. Корпоративные RA позволяют пользователю регистрироваться в оперативном режиме путем ввода действующего пароля и немедленной загрузки выделенного ему сертификата. В этом случае после получения уполномоченным CA запроса на сертификат служба каталогов Active Directory проверяет аутентичность пользователя и передает сертификат обратно RA для выдачи. Такая процедура может быть названа распределенным подходом к регистрации сертификатов, так как вмешательства человека не требуется. Подход с распределенными RA наилучшим образом подойдет для пользователей Intranet и просто пользователям с индивидуальными идентификаторами.

С другой стороны, автономный RA перед выдачей каждого сертификата требует подтверждения от администратора. Сначала запрос на сертификат хранится в базе данных, ожидая подтверждения с участием оператора, затем пересылается в Active Directory, где временно находится, пока не достигнет RA, который выдает сертификат. Данный алгоритм можно назвать централизованным подходом к регистрации сертификатов, так как вмешательство оператора в процесс подтверждения сертификата предоставляет администратору больший уровень контроля. Такой подход является более подходящим для пользователей Extranet и Internet, так как чаще всего у них нет индивидуальных идентификаторов, и им доверяют меньше, чем пользователям Intranet.

Построение RA относительно несложно, но требует некоторой осторожности, так как почти не освещается в документации Microsoft. В Microsoft Windows 2000 RA — это тот же CA с некоторыми отключенными возможностями. Чтобы построить RA, у CA необходимо отключить способность подписывать сертификаты, но сохранить его функцию обслуживания запросов на выдачу сертификатов через Web. RA вообще нежелательно разрешать какие-либо функции подписи ключей, так как наиболее вероятно, что обслуживаемые ими пользователи Extranet и Internet располагаются в демилитаризованной зоне (Demilitarized Zone, DMZ) брандмауэра. Кроме того, запросы через Web на внесение в список на вашем RA будут использовать стандартные протоколы HTTP или HTTPS (HTTPS включает протокол Security Sockets Layer и является предпочтительным), поэтому вам, вероятно, не понадобится открывать какие-либо дополнительные порты и протоколы на вашем брандмауэре.

Введение сертификатов при большом количестве пользователей может быть весьма громоздким. Прежде всего, следует понимать, что сертификаты, которые будут распространяться среди множества пользователей, предназначены только для их аутентификации. Очень часто срок действия пользовательских сертификатов устанавливается в один или два года (или менее). Я считаю, что каждый сертификат в идеальном случае должен быть закреплен за пользователем на весь срок его работы на данном предприятии, поэтому в полях сертификата не нужно использовать те характеристики, которые могут измениться в ближайшее время. Чем дальше вы отклоняетесь от основной цели применения сертификатов — проверки аутентичности пользователей, — тем чаще вам придется отвлекаться на аннулирование и перерегистрацию сертификатов. Когда определяете поля шаблона сертификата, не беспокойтесь о другой составляющей безопасности — авторизации, — эту функцию возьмут на себя поддерживающие PKI приложения, такие, как IIS.

ПУТЬ, КОТОРЫЙ ЕЩЕ ПРЕДСТОИТ ПРОЙТИ

Microsoft проделала серьезную работу по реализации в последней версии Windows широкого набора компонентов безопасности, однако основания для беспокойства еще остаются. Наиболее опасной недоработкой является, вероятно, отключение CTL по умолчанию. При отключенном CTL (как уже упоминалось) каждый обладатель CA может выпускать сертификаты, которые ваш сервер Web, например, будет воспринимать как действительные, — даже когда у вас применяется полный набор правил фильтрации сертификатов. Поэтому обязательно включите поддержку CTL и выберите уполномоченных по сертификации верхнего уровня, которым будете доверять, в противном случае вы невольно откроете доступ в сеть каждому желающему.

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

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

Другая проблема, с которой можно столкнуться при развертывании PKI средствами Windows 2000, связана с управлением событиями безопасности. Дело в том, что о каждом запросе на аутентификацию (неважно, был сертификат действительным или недействительным) делается запись в журнале событий Microsoft Event Viewer. Так как в настоящее время существует немало утилит безопасности, отслеживающих эти записи, вы можете отметить появление нежелательных предупреждений при каждой процедуре аутентификации пользователя с помощью сертификата. На момент публикации Microsoft не предоставила информации об устранении данной проблемы.

ПОДДЕРЖКА ПРОИЗВОДИТЕЛЕЙ

До февраля 2000 г. производители дружно поддерживали Microsoft, выпуская свои продукты PKI для Windows 2000, и хвалили ее за следование стандартам. Например, к настоящему времени сертификаты компаний Verisign и Thawte (недавно приобретенной Verisign) могут быть легко интегрированы в Windows 2000 PKI. Это значит, что вы можете либо полностью доверить решение своей проблемы внешним провайдерам услуг PKI, либо использовать комбинацию внешних и внутренних сертификатов. В любом случае вы можете встраивать в приложения элементы строгой аутентификации и авторизации (например, фильтры сертификатов Web в IIS) на основе внешних (общедоступных) сертификатов. Возможность использования сертификатов от нескольких производителей появляется благодаря тому, что все они следуют требованиям стандарта X.509v3, где однозначно определяется набор и порядок полей сертификата, с тем, чтобы такие приложения, как IIS, могли точно их интерпретировать.

Что касается взаимной сертификации между Windows 2000 и третьими сторонами, то поставщики PKI рассматривают этот ход Microsoft скорее как деловой стимул, чем как препятствие. Однако перед принятием решения о передаче сторонней организации любой части системы выдачи и распространения сертификатов вам следует подумать о последствиях данного шага для безопасности. В двух словах, PKI — это цепочка доверия. Если какое-либо звено из нее выпадает, то рвется вся цепочка. При обращении за услугами PKI к внешним организациям вам неминуемо придется доверить поставщику ваши «ключи от королевства», поэтому выбирайте поставщика, который, по вашему мнению, никуда не исчезнет в ближайшее время и чьей собственной практике обеспечения безопасности вы склонны доверять.

ЧТО ДЕНЬ ГРЯДУЩИЙ НАМ ГОТОВИТ?

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

Включив в Windows 2000 поддержку смарт-карт, а также предоставив возможность распространять и использовать сертификаты и биометрические данные на этом носителе, Microsoft делает шаг в будущее. В дополнение к поддержке биометрии введенная Microsoft в проектирование и развертывание PKI здоровая «инъекция» простоты должна стимулировать остальных поставщиков решений PKI разрабатывать интуитивно понятные пользовательские интерфейсы и процедуры использования.

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

Бесспорно, сочетание безопасности и поддержки стандартов является сильной стороной Windows 2000. Поддерживая такие открытые стандарты, как, например, IPSec, L2TP и X.509, Microsoft начинает конкурировать с компаниями, действующими за пределами территории Windows. Кроме того, Microsoft опередила и традиционных конкурентов, представив новую операционную систему с богатым набором возможностей по обеспечению безопасности систем и сетей.

Ресурсы Internet