Книги, научные публикации
Pages: | 1 | ... | 14 | 15 | 16 | 17 | 18 | Distributed Systems Guide Microsoft Windows 2000 Server Microsoft Press Распределенные системы Книга 1 Microsof Windows 2000 ...
-- [ Страница 16 ] --6. Щелкните Next (Далее).
Если Бы выбрали My user account, то вернетесь в диалоговое окно Add Standalone Snap-in. Вы можете еще раз щелкнуть Add, чтобы добавить еще одну оснастку.
Если Вы выбрали Service account или Computer account, то откроется диало говое окно Select Computer (Выбор компьютера). Для управления локальным компьютером достаточно щелкнуть Next (Далее). Чтобы управлять другим ком пьютером, либо введите доменное имя компьютера в поле Another computer (другим компьютером), либо щелкните кнопку Browse (Обзор) и выберите ком пьютер из списка. Щелкните кнопку Next.
Если Вы выбрали Computer account, то вернетесь в диалоговое окно Add Stan dalone Snap-in. Вы можете еще раз щелкнуть кнопку Add, чтобы добавить еще одну оснастку.
Если Вы выбрали Service account, то откроется диалоговое окно Certificates Snap-in. Выберите службу из списка Services account (Учетная запись службы) и щелкните Finish (Готово). Возвратившись в диалоговое окно Add Standalone Snap-in, Вы можете еще раз щелкнуть Add и добавить еще одну оснастку.
Закончив добавлять оснастки в диалоговом окне Add Standalone Snap-in, щел 7.
кните Close (Закрыть).
Вы вернетесь в диалоговое окно Add/Remove Snap-in с установленными Вами в ММС оснастками.
8. В диалоговом окне Add/Remove Snap-in щелкните ОК.
На рис. 16-4 показаны три узла консоли Certificates, добавленные в окно ММС.
Первый узел управляет сертификатами вошедшего в систему пользователя, второй - сертификатами для службы World Wide Web Publishing (Служба веб-публика сертификатами для самого локального ции) на локальном компьютере, а третий компьютера.
Безопасность в распределенных системах 706 ЧАСТЬ !-,.1.1. Х [, Х LJ Personal Console Root ^Trusted Root Certification Authorities CUEnterprise Trust :+ LJ Personal : ] CJ Trusted Root Certification Authorities | [iiijIntermediate Certification Authorities : C"l Enterprise Trust LJ Active Directory User Object ф- Gj Intermediate Certifical ion Authorities DREQUEST Ш- Q Active Directory User Object. Я D REQUEST H '{У Certificates - Service (World Wide Web Publishing Service) on Local Computer В vj wasvciPersonal El CJ W3SVC\Trusted Root Certification Authorities О WSSVClEnterpnse Trust S+i -LJ WSSVCyntermediate Certification Authorities t-1 QJ Certfcate? (Local Computer) IS-О Personal Ё LU Trusted Root Certifica:ion Authorities Qj Enterprise Trust It" Cl Intermediate Certification Authorities Щ 3 REQUEST Рис. 16-4. Консоль Certificates (Сертификаты) Узлы консоли Certificates на рис. 16--1 раскрыты Ч Вы можете изучить логические хранилища сертификатов. Этот режим отображения называется Logical display mode (Логическое хранилище). Сертификаты также можно просматривать по физичес ким хранилищам или по назначению.
Чтобы изменить режим отображения, выберите одну из консолей Certificates. В меню View (Вид) щелкните команду Options (Параметры). В открывшемся диало говом окне View Options (Параметры просмотра) задайте требуемые параметры отображения хранилищ сертификатов. Эти параметры описаны в таблице 16-3.
Таблица 16-3. Параметры диалогового окна View Options (Параметры просмотра) Параметр Описание Certificate purpose Отображает сертификаты в режиме по назначению*, напри (по назначению) мер шифрованная файловая система, восстановление файлов или подписание кода Logical certificate stores Отображает сертификаты в режиме по логическим хранили (по логическим щам, в котором они сгруппированы по логическим х р а н и л и хранилищам) щам, к которым относятся. Этот режим просмотра установлен по умолчанию Physical certificate stores В дополнение к логическим отображаются и физические хра (физические хранилища) нилища. Этот параметр доступен только в режиме отображе ния по логически\т хранилищам Archived certificates При установке этого параметра отображаются а р х и в н ы е серти (архив сертификатов) фикаты. Windows 2000 поддерживает архив сертификатов и их закрытых ключей, срок жизни которых истек или обновлен ных. Рекомендуется хранить архивные сертификаты, так как иногда требуется воспользоваться ими или их ключами. На пример, может понадобиться проверить цифровую подпись на старом документе, подписанном ключом обновленного серти фиката или сертификата с истекшим сроком действия Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 Модель доверия центров сертификации Инфраструктура открытого ключа Windows 2000 поддерживает иерархическую мо дель центров сертификации и списков CTL. Чтобы управлять доверенными серти фикатами па предприятии, Вы можете развернуть службы сертификации W i n dows 2000 и создать иерархию доверенных ЦС. Кроме тою, для этих целей создают списки CTL.
Иерархии центров сертификации Инфраструктура открытого ключа в Windows 2000 поддерживает иерархическую модель центров сертификации, или иерархию сертификации (certification hierarchy), для обеспечения масштабируемости, удобства управления и совмести мости со многими новыми коммерческими службами ЦС сторонних производителей и программным обеспечением, поддерживающим технологию открытого ключа. Про стейшая форма иерархии сертификации это один центр сертификации. Однако обычно иерархия содержит множество ЦС с четко определенными отношениями типа родитель Ч потомок*. На рис. 16-5 показаны несколько выриантов иерархии ЦС.
Уровень Root CA 1 (корневой ЦС) Root CA 2 (корневой ЦС) Уровень Intermediate CA Ч С (промежуточный ЦС) Issuing CA Ч A Issuing CA Ч В (выпускающий ЦС).(выпускающий ЦС) Уровень Сертификаты Сертификаты Issuing CA Ч D (выпускающий ЦС| Уровень Сертификаты Рис. 16-5. Иерархии сертификации Б соответствии со своими потребностями Вы вправе развернуть несколько иерар хии ЦС. Центр сертификации на вершине иерархии называется корневым ЦС (root CA). Корневой ЦС сертифицирует себя сам, выпуская и подписывая свой серти фикат ЦС. Это наиболее доверенный ЦС в организации. Рекомендуется обеспечить максимальную безопасность такого центра сертификации. Все центры сертифика ции предприятия не обязаны подчиняться единственному родительскому ЦС верх ЧАСТЬ 2 Безопасность в распределенных системах пего уровня или корневому ЦС. Хотя доверительные отношения ЦС и зависят от доменной политики доверительных отношений центров сертификации, тем не ме нее ЦС одной иерархии могут размещаться в разных доменах.
Дочерние ЦС называются подчиненными ЦС (subordinate CA). Подчиненный ЦС сертифицируется родительским ЦС тот выпускает и подписывает сертификат подчиненному ЦС. Подчиненные ЦС подразделяются на промежуточные и выпус кающие ЦС. Промежуточный ЦС (intermediate CA) выдает сертификаты только подчиненным ему ЦС. Выпускающие ЦС (issuing CA) выдают сертификаты пользо вателям, компьютерам и службам.
Не существует ограничений на глубину иерархии сертификации. Тем не менее для удовлетворения потребностей большинства организаций вполне достаточно треху ровневой иерархии сертификации - корневой ЦС, промежуточный ЦС и выпуска ющий ЦС.
Путь сертификации Иерархия сертификации создает цепь доверия Ч путь сертификации (certification path) - от определенного сертификата к корневому ЦС. На рис. 16-6 показан че тырехуровневый путь сертификации в трехуровневой иерархии ЦС, изображенной на рис. 16-5.
I Root CA 3 Intermediate С A - ' П Issuing С A - D LJ;
Рис. 16-6, Пути сертификации В этом примере у сертификата EPS Recovery Agent (Агент восстановления EPS), выпущенного ЦС Issuing CA - D, есть путь сертификации до высшего ЦС Root CA 2. Сертификат агента восстановления EFS является доверенным, потому что сертификат ЦС Root CA 2 содержится в хранилище Trusted Root Certification Authorities (Доверенные корневые центры сертификации).
Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 Путь сертификации проходит через все сертификаты вплоть до корневого ЦС. Сер тификатам с действительным путем сертификации до корневого сертификата, раз мещенного хранилище в Trusted Root Certification Authorities, доверены псе назна чения, перечисленные в корневом сертификате. Если сертификат корневого ЦС для данного пути сертификации не размещен в этом хранилище, путь сертификации не будет доверен до тех пор, пока сертификат корневого ЦС не будет добавлен в хра нилище Trusted Root Certification Authorities.
Microsoft CryptoAPI исследует действительность пути сертификации от данного сертификата до сертификата корневого ЦС, проверяя все сертификаты на этом пути. В каждом сертификате содержатся сведения о родительском ЦС, выпустив шем его. CryptoAPI последовательно извлекает эти сведения из сертификатов ро дительских ЦС, указанных в пути сертификации, либо из одного из хранилищ Intermediate Certification Authorities или Trusted Root Certification Authorities (если сертификаты хранятся в одном из них), либо из внешнего, доступного интерактив но (online) хранилища (например, доступного по HTTP- или LDAP-адресу), ука занного в сертификате. Обнаружив недействительность или отсутствие хотя бы одного сертификата па пути сертификации, CryptoAPI не разрешит доверять дан ному пути сертификации.
Обнаружив в процессе проверки пути сертификации сертификат подчиненного ЦС, CryptoAPI размещает его в хранилище Intermediate Certification Authorities (если его там ранее не было) для будущих ссылок. Тем не менее для автономных компь ютеров, например переносных, придется импортировать сертификаты подчиненных ЦС в хранилище Intermediate Certification Authorities, чтобы обеспечить проверку путей сертификации с использованием сертификатов некорневых ЦС.
На рис. 16-7 показан недоверенный путь сертификации - здесь корневого серти фиката нет в хранилище Trusted Root Certification Authorities.
Intermediate CA - С О Issuing CA - С О EPS Recovery Agenl Cerift;
ats status:
Рис. 16-7. Недоверенный путь сертификации ЧАСТЬ 2 Безопасность в распределенных системах По умолчанию сертификаты, выпущенные доверенным ЦС, пригодны для всех опе раций, указанных в сертификате доверенного ЦС. Средствами диалогового окна Certificate (Сертификат) на вкладке Details (Состав) можно ограничить цели, для которых применяются локальные сертификаты. Вы также вправе использовать списки CTL для определения доверенных сертификатов и ограничения перечня доверенных им операций.
Списки доверия сертификатов Для создания списков доверия сертификатов (certificate trust list, CTL) использу ется мастер Certificate Trust List (мастер списков доверия сертификатов). Он до ступен из контекстного меню раздела Public Key Policy (Политики открытого клю ча) консоли Group Policy (Групповая политика). В CTL перечислены доверенные корневые ЦС, то есть сертификаты с путями сертификации, ведущими к перечис ленным в списке CTL корневым ЦС, доверенным для указанных в этом списке це лей. Списки CTL создаются для компьютеров и пользователей. Списки CTL для компьютеров действительны для всех компьютеров, пользователей и служб в обла сти действия данной групповой политики, а списки CTL для пользователей Ч толь ко для пользователей в области действия групповой политики. На рис. 16-8 пока зан пример пути сертификации с CTL.
f: Certificate и path i Root issuing CA Q CTL Signing [3 Certificate Trust List Intermediate CA - С El IssuhgCA-D :
OB i.erlihcate status:
Г-5Г- Рис. 16-8. Путь доверия сертификации со списком CTL В этом примере путь сертификации от EPS Recovery Agent к ЦС Root CA 2 иден тичен пути сертификации, показанном на рис. 16-6, но сертификата ЦС Root CA 2 нет в хранилище Trusted Root Certification Authorities. В пути сертификации так же содержатся список CTL, доверенный сертификат, подписывающий список (в нашем примере Ч CTL Signing), и сертификат корневого ЦС, выпустившего под писывающий сертификат (лRoot Issuing CA). Сертификат EPS Recovery Agent Службы сертификации и инфраструктура открытого ключа в Windows 2000 ГЛАВА является доверенным, потому что сертификат ЦС Root Issuing CA (то есть цент ра сертификации, выпустившего сертификат CTL Signing) размещен R хранилище Trusted Root Certification Authorities.
CTL подписывает администратор, обладающий действительным сертификатом для подписания списков доверия, например сертификатом Administrator (Админис гра тор) или Trust List Signing (Подписывание списка доверия), выпущенными ЦС предприятия. По умолчанию списки CTL действительны до истечения срока дей ствия сертификата, использованного для его подписания. Однако Вы вправе огра ничить срок доверия сертификату, установив более короткий срок действия списка CTL.
По умолчанию члены групп Domain Admins (Администраторы домена) и Enterprise Admins (Администраторы предприятия) обладают разрешениями на получение сер тификатов Administrator и Trust List Signing. Чтобы изменить стандартные пара метры получения сертификатов, следует скорректировать списки управления до ступом (ACL) в шаблонах сертификатов Administrator и Trust List Signing.
Списки CTL действительны только в том случае, когда пути сертификации подпи сывающих их сертификатов ведут к корневому ЦС. информация о котором имеет ся в хранилище Trusted Root Certification Authorities. На рис. 16-9 показан CTL, недействительный по причине недействительности сертификата, которым он под писан. Это одна из причин непригодности списка CTL. Всего их две: либо путь сер тификации сертификата, подписывающего список CTL, не ведет к доверенному корневому сертификату, либо сфок действия подписывающего сертификата истек.
Q Certificate Trust list Information This certificate trust ! №'fлftvafei' The certificate that signed tbe ist 15 rot vM.
fwd :...;
..
Encrypting C!le5ystem ZZ List identifier 4300 5400 4COO 2000 3200 0000..= Monday, July 26, 1999 4:27:53 PM | ' :
EH Effective date shal l;
f{| Щ Siject algorithm ^ Thumbprint algorithm ;
shal BFE1 8C77 K71 7B39 JBDl 9975 ? | i SThumbprht *x]cTL n^me (friendly name ЧЧ ViM:
Рис. 16-9. Недействительный список CTL Списки CTL хранятся в хранилище Enterprise Trust и доступны для просмотра в консоли Certificates.
243ак. 402/ Безопасность в распределенных системах 712 ЧАСТЬ В CTL дополнительно можно ограничить перечень разрешенных назначений сер тификатов. Например, даже если в назначениях сертификата указана его пригод ность для подписания программного кода, для защищенной почты и проверки под линности клиентов, то список CTL способен ограничить его область действия толь ко проверкой подлинности клиентов. CTL часто применяются для ограничения доверия сертификатам, выпущенным и управляемым другими организациями. На пример, Вы вправе сконфигурировать CTL на доверие центру сертификации дело вого партнера только для подписания кода и проверки подлинности клиентов в управляемом Вами экстранете.
Сервер Internet Information Services (IIS) также поддерживает CTL для защищен ных Web-узлов. Подробнее о списках CTL в TIS Ч в главе 13 Обеспечение безо пасности средствами технологии открытого ключа.
Процесс проверки действительности сертификата Windows 2000 доверяет только сертификатам, прошедшим проверку действитель ности, то есть действительности самого сертификата и его пути сертификации. На рис. 16-10 показана блок-схема этого процесса.
Существует множество причин недействительности сертификатов и отсутствия до верия к ним:
Х дата начала действия и срок действии несовместимы или срок действия истек;
Х некорректный формат сертификата (не соответствует стандарту Х.509 v3);
Х ошибочная или неполная информация в полях сертификата;
Х ощибка проверки целостности: хэш сертификата не соответствует подписи, ука зывая на его фальсификацию или разрушение;
Х сертификат указан в опубликованном списке отозванных сертификатов;
Х выпустившего сертификат центра сертификации нет ни в доверенной иерархии сертификации, ни в списке CTL;
Х корневого ЦС пути сертификации нет в хранилище Trusted Root Certification Authorities;
Х назначения, для которых выполняется попытка использовать сертификат, за прещены в CTL.
Сертификат ЦС с истекшим сроком действия в пути сертификации не лишает этот путь действительности. В инфраструктуре открытого ключа Windows 2000 путь сер тификации остается в силе, если сертификат ЦС был действителен в момент вы пуска сертификата. Допустим, что ЦС сторонней компании выпустил сертификат со сроком действия более поздним, чем у сертификата самого ЦС. После истече ния срока действия сертификата ЦС путь сертификации для выпущенного им сер тификата останется в силе, и сертификат останется действительным и доверенным.
ГЛАВА 1Б Службы сертификации и инфраструктура открытого ключа в Windows 2000 Начало Проверка наличия списков Проверка типа сертификата доверия сертификатов Есть ли списки доверия?
Проверка дат начала Проверка списков и окончания срока доверия сертификатов действия Нет ХХ Действительны Есть ли ЦС в списке пи даты? доверия?
Проверка Проверка наличия целостности разрешенных сертификата назначений Недейст- Недействи Нет вительный тельный Успешна ли Разрешено ли сертификат сертификат проверка запрошенное назначение?
целостности?
Проверка наличия цепочки доверия к доверенному ЦС Есть ли в цепочке доверенный ЦС?
Действительный сертификат Рис. 16-10. Основные этапы проверки действительности сертификата Преимущества многоуровневых иерархий сертификации При создании системы сертификационных центров стоит рассмотреть возможность развертывания многоуровневой иерархии сертификации, состоящей из корневого, 714 ЧАСТЬ 2 Безопасность в распределенных системах промежуточного и выпускающего центров сертификации. Многоуровневые иерар хии доверия обладают многими преимуществами.
Общие преимущества Х Число доверенных корневых ЦС ограничено и невелико, что позволяет центра лизовано управлять и обслуживать систему, обеспечивая высокую степень безо пасности и целостности для корневых ЦС.
Х Меньше убытков и негативных последствий в случае компрометации иди сбоя ЦС.
Х Система Ч гибкая: отдельные подразделения могут развертывать и управлять промежуточными ЦС для обеспечения своих потребностей по безопасности на базе технологий открытого ключа.
Х Система - гибкая: подразделения и состоянии развертывать и управлять выпус кающими ЦС для разделения нагрузки сертификации и дублирования служб сертификации.
Административные преимущества Х Гибкое конфигурирование окружения безопасности ЦС (надежность ключей, физическая защита, защита от сетевых атак и др.). Существует возможность подгонять среду центров сертификации для обеспечения требуемого равно весия между безопасностью PI удобством работы. Например, на корневом ЦС Вы можете установить специализированные криптографические устройства, разме стить его в физически закрытом хранилище и обеспечить доступ к нему только в изолированном (offline) режиме. Для выпускающих ЦС аппаратные криптог рафические решения, закрытые хранилища и работа в изолированном режиме могут оказаться дорогостоящими, кроме того, они способны затруднить взаимо действие с ЦС и снизить их быстродействие и эффективность.
Х Можно относительно часто обновлять ключи и сертификаты для промежуточ ных и выпускающих ЦС, риск компрометации которых высок, не меняя суще ствующие доверительные отношения с корневым ЦС.
Х Можно лотключить часть иерархии ЦС, не нарушая существующие довери тельные отношения с корнем или остальной частью иерархии. Например, отклю чение выпускающего ЦС отдельного сайта не нарушит работу других служб сер тификации данного или других сайтов.
Преимущества использования множественных выпускающих центров сертификации Х Можно индивидуально настраивать политики сертификации для различных групп пользователей или компьютеров. Например, разворачивать выпускающие ЦС для администрирования политик сертификации отдельных групп пользова телей и компьютеров.
Х Бы вправе раздельно настраивать политики сертификации целых организаци онных единиц одного типа, например роли пользователей или компьютеров на предприятии. Для этого также создается выпускающий ЦС.
Х Разрешается строить дифференцированную политику сертификации по геогра фическому признаку, например определить политику для сайта, в котором рас положены пользователи и компьютеры.
Службы сертификации и инфраструктура открытого ключа в Windows 2000 ГЛАВЛ Х Можно распределять нагрузку сертификации и создавать запасные службы, раз вертывая несколько выпускающих ЦС. Порядок распределения нагрузки серти фикации настраивается в соответствии с особенностями сайтов, сети, подклю чений серверов и требованиями по нагрузке. Например, для медленных или раз дельных сетевых соединений между сайтами требуется выпускающий ЦС в каж дом из них для обеспечения приемлемой производительности службы сертифи кации и удобства в работе. Кроме того, разрешается создание нескольких дуб лирующих выпускающих ЦС - при сбое ЦС его функции подхватывает ре зервный ЦС, таким образом, обеспечивается непрерывность работы службы.
Центры сертификации в Windows Windows 2000 Server и службы сертификации поддерживают два типа корневых и подчиненных центров сертификации: ЦС предприятия и изолированный ЦС.
Центры сертификации предприятия ЦС предприятия (Enterprise СА) интегрирован с Active Directory и публикует пы пускаемые сертификаты и списки CRL в этой службе каталогов. Решение о выпус ке или отказе в выдаче сертификата принимается на основании хранимой в Active Directory информации шаблонов сертификатов, учетных записей пользователей и групп безопасности. Для получения сертификата запрашивающий должен обладать разрешением Enroll (Заявка), предоставленным в списке управления доступом (access control list, ACL) шаблона сертификата запрашиваемого типа. При выпуске сертификата ЦС предприятия использует информацию в шаблоне сертификата и создает сертификат со всеми необходимыми атрибутами данного типа.
Рекомендуется устанавливать большинство выпускающих ЦС в качестве ЦС пред приятия, что гарантирует максимум преимуществ от интеграции с Aciive Directory, в том числе автоматическую обработку запросов на сертификаты и получение сер тификатов компьютерами. Кроме того, только ЦС предприятия способен выпускать сертификаты для входа в систему со смарт-картой, так как эта процедура требует автоматического сопоставления (mapping) сертификатов смарт-карт учетным запи сям пользователей в Active Directory, а также нуждается в шаблонах сертификатов.
Изолированные центры сертификации Изолированный ЦС (stand-alone CA) не обращается к Active Directory и не исполь зует шаблоны сертификатов. В таком ЦС вся информация о требуемом сертифика те содержится в запросе. Страницы приема запросов на сертификаты через Интер нет (Web Enrollment Support), устанавливаемые для изолированного ЦС. поддер живают запросы на сертификаты многих типов, По умолчанию все запросы сертификатов, направленные в изолированный ЦС, раз мещаются в очереди отложенных сертификатов до одобрения их администратором ЦС. Теоретически разрешается сконфигурировать изолированный ЦС на автома тический выпуск сертификатов, однако на практике это не рекомендуется, так как создает существенную угрозу безопасности.
Если требуется автоматизировать выпуск сертификатов в ответ на запросы, разра ботайте специализированные модули политики, обеспечивающие безопасное одоб рение или отказ в выпуске сертификатов. Например, специализированный модуль политики, который автоматически предоставляет сертификат запрашивающему, если тот прошел проверку на основании информации, содержащейся в унаследо ЧАСТЬ 2 Безопасность в распределенных системах 71Б ванной базе данных или в службе каталогов сторонней организации. Изолирован ные ЦС не в состоянии выпускать сертификаты для входа в систему со смарт-кар той, но поддерживают другие типы сертификатов для смарт-карт. Например, изо лированный ЦС с установленными Web-страницами приема запросов на сертифи каты через Интернет способен выпускать сертификаты для защищенной почты и защищенного браузера, размещаемые на смарт-карте того, кто запрашивает серти фикат.
По умолчанию изолированный ЦС публикует списки отозванных сертификатов (CRL) в папке:
<диск>: \WINNT\Systeiti32\Certsrv\CertenroU где <диск> - буква диска, на котором установлен ЦС.
Использование изолированного ЦС, если требуется выпускать большое качество сертификатов, обычно не оправдано, так как возрастают издержки на администри рование. Это вызвано тем, что администраторам приходится вручную изучать и принимать решение по каждому запросу на сертификат. Поэтому изолированные выпускающие ЦС обычно используются с приложениями, поддерживающими тех нологии открытого ключа, в экстранете и Интернете, где у пользователей нет учет ных записей Windows 2000, а число выпускаемых и управляемых сертификатов от носительно невелико.
Однако при использовании службы каталогов сторонних производителей или в условиях недоступности Active Directory допускается применение только изолиро ванных ЦС. Кроме того, изолированный ЦС способен обеспечить дополнительную гибкость при планировании и управлении жизненным циклом сертификатов в сис теме корневых и промежуточных ЦС.
Жизненный цикл сертификатов Под жизненным циклом сертификатов (certificate life cycle) мы понимаем следую щие события служб сертификации:
Х установку ЦС и выпуск сертификата для него;
Х выпуск сертификатов центром сертификации;
Х отзыв сертификатов (по мере необходимости);
Х обновление сертификатов или истечение срока их действия;
Х обновление сертификатов ЦС до истечения срока их действия;
Х отзыв или отключение ЦС.
Выпущенные сертификаты становятся недействительными по истечении срока их действия. При необходимости их обновляют. Это делают и до окончания его срока действия Ч для обеспечения непрерывности работы служб сертификации на пред приятии.
Центры сертификации в Windows 2000 поддерживают только вложенные сроки дей ствия для жизненных циклов сертификатов, то есть запрещено выпускать серти фикаты со сроком действия более поздним, чем у сертификата самого ЦС. Если срок действия, определяемый типом сертификата, превышает срок действия серти фиката ЦС, центр сертификации сокращает это значение до срока действия серти фиката ЦС. Таким образом вложенные сроки действия сертификатов Ч важное об стоятельство, которое следует учитывать, планируя цикл жизни сертификатов в ЦС ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 служб сертификации в Windows 2000. В центрах сертификации сторонних произ водителей такие ограничения могут отсутствовать.
Определение времени жизни сертификатов, выпускаемых ДС предприятия, отли чается от порядка, установленного для изолированных ЦС. ЦС предприятия вы пускает сертификаты со сроками действия, определенными в шаблонах сертифи катов. Время жизни сертификатов, выпускаемых изолированными ЦС, определя ется параметрами конфигурации ЦС в реестре, а также некоторыми другими фак торами. Кроме того, следует не превышать время безопасного использования за крытых ключей.
Вложенные сроки действия В Windows 2000 ЦС предприятия и изолированные ЦС должны соблюдать вложе ние сроков действия для всех сертификатов ЦС и выпускаемых ими сертификатов.
Например, если сертификат корневого ЦС действителен до 2 января 2010 года, ни один из его дочерних центров сертификации в цепочке ниже корня не способен выпустить сертификат с более поздней датой действия. Если промежуточный ЦС в Windows 2000 имеет сертификат, действительный до 2 января 2006 года, то ника кой из его дочерних ЦС не выпустит сертификат со сроком действия более по здним, чем 2 января 2006. Если у выпускающего ЦС сертификат действителен до 2 января 2002 года, ему не удастся выпустить сертификат со сроком действия по зднее этой даты.
Если, обладая сертификатом ЦС действительным до 2 января 2002 года, центр сер тификации получит запрос на годовой сертификат 1 августа 2000 года, он удовлет ворит запрос, выпустив сертификат, действительный один год, Ч до 31 июля года. Однако, получив такой запрос 1 августа 2001 года, ЦС выпустит сертификат со сроком действия до 2 января 2002 года.
ЦС в Windows 2000 с пятилетним сертификатом, срок которого истекает 2 января 2005 года, способен выпускать годовые сертификаты вплоть до 2 января 2004 года или двухлетние сертификаты до 2 января 2003 года. После 2 января 2003года ЦС больше не выпускает двухлетних сертификатов, сокращая срок действия до 2 янва ря 2005 года. Аналогично после 2 января 2004 года ЦС сокращает срок действия одно- и двухлетних сертификатов до 2 января 2005 года.
Обычно сертификаты ЦС в Windows 2000 обновляются прежде, чем начнут дей ствовать ограничения по вложенности сроков действия. Иногда для предупрежде ния влияния требований по вложенности сроков действия в разветвленных иерар хиях сертификации в службах сертификации Windows 2000 требуется частое обнов ление сертификатов выпускающих ЦС.
Сертификаты, выпускаемые изолированными центрами сертификации Срок действия сертификатов, выпускаемых изолированным ЦС, определен в сле дующих параметрах реестра:
HKEY_LOCAL_HACHINE\SYSTEH\CurrentControlSet\Services\CertSvc \Conf iguration\
По умолчанию изолированный ЦС выпускает сертификаты со сроком действия 1 год (ValidityPeriod = Years, ValidityPeriodUnits = 1). Чтобы определить другой срок действия следует отредактировать в реестре параметры ValidityPeriod и Validi tyPeriodUnits данного изолированного ЦС.
Сроки действия всех сертификатов, выпускаемых изолированным ЦС, одинаковы и определены в параметрах ValidityPeriod и ValidityPeriodUnits реестра. Поэтому при необходимости выпускать сертификаты с различными сроками действия, Вам следует установить либо ЦС предприятия, либо несколько изолированных ЦС, либо ЦС стороннего производителя, Сертификаты, выпускаемые центрами сертификации предприятия На ЦС предприятия максимальный срок действия выпускаемых им сертификатов определяется значениями параметров ValidityPeriod и ValidityPeriodUnits в реест ре. По умолчанию их значения равны: ValidityPeriod = Years и ValidityPeriod Units = 2. Поэтому стандартный максимальный срок действия сертификатов, вы пускаемых ЦС предприятия два года.
Однако срок действия сертификата зависит от его типа и определяется в соответ ствующем шаблоне. Срок действия сертификатов большинства типов Ч 1 год. Да лее перечислены шаблоны сертификатов со сроком действия 2 года:
Х СЕР Encryption (offline request) [СЕР шифрование (автономный запрос)];
Х Enrollment Agent (Агент подачи заявок);
Х Enrollment Agent (computer)[Агент подачи заявок (компьютер));
Х Enrollment Agent (offline request)! Агент подачи заявок (автономный запрос)!;
Х IP Sec;
Х IPSec (автономный запрос);
Х Router (offline request) [Маршрутизатор (автономный запрос)];
Х Web Server (Веб-сервер).
Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 Для следующих шаблонов сертификатов определен пятилетний срок действия:
Х Domain Controller (Контроллер домена);
Х Subordinate Certification Authority (Подчиненные центры сертификации).
Эти сертификаты обычно выдаются на 2 года (максимальный стандартный срок действия сертификатов, выпускаемых ЦС предприятия). Чтобы ЦС предприятия выпускал пятилетние сертификаты, следует изменить значения параметров Validi tyPeriod и ValidityPeriodUnits.
Вы также вправе сократить максимальный срок действия сертификатов, изменив значения параметров ValidityPeriod и ValidityPeriodUnits. Например, чтобы сокра тить максимальный срок действия сертификатов, выпускаемых ЦС до 6 месяцев, присвойте ValidityPeriod значение Month, a ValidityPeriodUnits Ч 6. В случаях, тре бующих особого управления сроком действия сертификатов, Вы вправе использо вать собственные модули служб сертификации.
Сертификаты центров сертификации По умолчанию корневой ЦС предприятия и изолированный корневой ЦС предпри ятия устанавливаются с двухлетним сертификатом ЦС. В процессе установки ЦС Вы можете установить другой срок действия сертификата ЦС, указав его в днях, неделях, месяцах или годах. Например, надежно защищенному корневому центру сертификации, обладающему надежным длинным закрытым ключом, Вы можете определить срок действия сертификата ЦС в 20 лет. С другой стороны, разрешает ся при развертывании служб сертификации установить более короткие сроки дей ствия - несколько дней или недель.
При установке подчиненного ЦС Вам предоставляется выбор: интерактивно за просить сертификат подчиненного ЦС у родительского НС или создать файл зап роса сертификата и отослать его родительскому ЦС и автономном режиме. В слу чае одобрения интерактивного запроса у доступного ЦС сертификат подчиненного ЦС выпускается родительским ЦС предприятия автоматически. Выполняя авто номный запрос, Вы должны использовать Web-страницы приема запросов на сер тификаты через Интернет для отправки файла запроса сертификата родительско му ЦС. После выпуска сертификата подчиненного ЦС следует средствами оснаст ки Certification Authority (Центр сертификации) установить файл пути сертиф i кации и запустить ЦС.
Срок действия сертификата подчиненного ЦС определяется родительским НС, об ладающим нравом одобрить запрос на сертификат и выпустить его. Срок действия сертификата подчиненного ЦС Ч 2 года, если родительский центр сертификации является ЦС предприятия и срок действия по умолчанию, определенный в его па раметрах реестра ValidityPeriod и ValidityPeriodUnits, не был изменен. Допускает ся корректировать параметры реестра, продлевая или сокращая срок действия сер тификатов, выпускаемых родительским ЦС, однако срок действия сертификата подчиненного ЦС на может превышать 5 лет, поскольку это максимальный срок, определенный в шаблоне сертификата Subordinate Certification Authority. На изо лированных родительских ЦС срок действия сертификата подчиненного ЦС пол ностью определяется значениями параметрами реестра ValidityPeriod и Validi tyPeriodUnits родительского центра сертификации.
Управляя жизненным циклом сертификатов, попробуйте использовать изолирован ные ЦС в качестве корневых и промежуточных центров сертификации Ч таким Безопасность в распределенных системах 720 ЧАСТЬ образом Вы обеспечите наибольшую гибкость при решении этих задач. Обнаружив, что при установке определен слишком длинный срок действия ЦС и центр серти фикации находится в большей опасности, чем ожидалось, Вы можете просто обно вить сертификат ЦС в иерархии сертификации, сократив срок его действия, Использование изолированного корневого ЦС и промежуточного ЦС дает и дру гие преимущества. Если изолированный ЦС работает в автономном режиме (не подключен к сети) и размещен в физически защищенном помещении, риск атак значительно сокращается. Кроме того, существует возможность управлять процес сом установки для четкого контроля донеренных ЦС, устанавливаемых на предпри ятии.
Одновременное управление автономными запросами изолированного корневого и промежуточного ЦС обычно сокращает издержки, так как ЦС используется нечас то и обрабатывает относительно немного запросов на сертификаты. Вы можете под ключаться сети только при необходимости опубликовать список отозванных сер тификатов или для обработки нечастых интерактивных запросов сертификатов под чиненных ЦС.
Пример жизненных циклов сертификатов В таблице 16-4 описан пример жизненных циклов сертификатов в случае исполь зования центра сертификации Windows 2000 и стандартных поставщиков службы криптографии Microsoft.
Таблица 16-4. Жизненные циклы сертификатов в Windows Назначение сертификата Срок действия Срок действия закрытого ключа Изолированный корневой ЦС 20 лет Обновляется по крайней мере каждые (4 096-битный ключ) лет для обеспечения выпуска 10-летних сертификатов промежуточных ЦС. Об новляется с новым ключом по крайней мере каждые 20 лет Изолированный промежуточный Обновляется по крайней мере каждые ЦС: все типы сертификатов лет для обеспечения выпуска 5-летних кроме сертификатов смарт-карт лочерних выпускающих ЦС. Обновляется (3 072-битный ключ) 10 лет с новым ключом по крайней мере каждые 10 лет Первый выпускающий ЦС 5 лет Обновляется по крайней мере каждые предприятия: все типы сертифи- года для обеспечения выпуска 2-летних катов кроме сертификатов смарт- сертификатов Web-сервера. Обновляется карт (2 048-битный ключ) с новым ключом но крайней мере каждые 5 лет Второй выпускающий ЦС 5 лет Обновляется по крайней мере каждые предприятия: сертификаты года для обеспечения выпуска сертифика смарт-карт (2 048-битный ключ) тов со сроком действия один год. Обнов ляется с новым ключом по крайней мере каждые 5 лет Третий выпускающий ЦС 5 лет Обновляется по крайней мере каждые предприятия: сертификаты всех года для обеспечения выпуска сертифика остальных типов кроме смарт- тов со сроком действия один год. Обнов карт, защищенной почты и серти- ляется с новым ключом по крайней мере фикатов защищенного браузера каждые 5 лет (2 048-битный ключ) Защищенная почта и сертифи- 1 год Обновляется с новым ключом по крайней каты защищенного браузера мере каждые 2 года ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 Таблица 16-4. (продолжение) Назначение сертификата Срок действия Срок действия закрытого ключа Сертификаты смарт-карт 1 год Обновляется с новым ключом по крайней (1 024-битный ключ) мере каждые 2 года Сертификаты Администратора 1 год Обновляется с новым ключом по крайней (1 024-битный ключ) мере каждые 2 года Сертификаты защищенного 2 года Обновляется с новым ключом по крайней Web-сервера (1 024-битный ключ) мере каждые 2 года Сертификаты пользователей 6 месяцы Обновляется с новым ключом по крайней деловых партнеров для экстра- море раз в год сетей (512-битный ключ) Примечание Жизненные циклы сертификатов, описанные в таблице 16-4, показа ны для примера и не являются рекомендацией. Жизненные циклы (в том числе срок действия сертификатов, длина и срок действия ключей) реальных сертифика тов могут отличаться от них.
Все приведенные в таблице 16-4 сертификаты выпущены ЦС Windows 2000 за ис ключением сертификатов пользователей деловых партнеров (для экстрасетей), ко торые выпущены ЦС делового партнера. Доверие к сертификатам делового парт нера в домене экстрасети обеспечивается посредством списков CTL. Для обеспече ния гибкости управления сроками действия центров сертификации используется изолированный ЦС. Возобновление сертификатов с новыми ключами ограничива ет время использования ключей и снижает риск их компрометации.
Из-за требования вложенности сроков действия ЦС может выпускать (при наличии соответствующего разрешения) сертификаты с сокращенными сроками действия.
Они требуют более частого обновления по мере приближения к сроку действия сер тификата ЦС. Поэтому сертификаты центров сертификации обычно обновляются до того, как начинается выпуск сертификатов с лурезанными сроками действия. Сер тификаты обновляются с новыми ключами до истечения допустимого безопасного срока действия старых ключей. Чтобы снизить риск компрометации закрытых клю чей, их следует обновлять по мере возможности вместе с сертификатами.
Чем больше уровней в иерархии сертификации, тем короче сроки действия сертифи катов. Поэтому жизненные циклы сертификатов следует планировать так, чтобы из бежать слишком коротких сроков действия сертификатов и циклов их обновления.
Определение сроков действия ключей Нет простых правил для определения максимальных сроков действия закрытых ключей. Срок действия определяется многими факторами риска, в том числе:
Х длиной закрытых ключей сертификатов. В общем случае более длинные ключи служат дольше;
Х безопасностью закрытых ключей, обеспечиваемой поставщиками службы крип тографии (CSP). Б общем случае аппаратные CSP обеспечивает большую безо пасность и поддерживают более длинные сроки действия закрытых ключей, чем программные CSP;
Х безопасностью ЦС и их закрытых ключей. В общем случае чем лучше защита ПС и его закрытого ключа, тем дольше безопасный срок действия ЦС. Напри Безопасность в распределенных системах 722 ЧАСТЬ мер, для повышения безопасности ЦС можно использовать его только в авто номном режиме (не подключен к сети), разместив в физически защищенном хранилище или центре хранения данных;
Х надежностью технологии, используемой в криптографических операциях. Неко торые криптографические технологии обеспечивают более сильную защиту и поддерживают более надежные криптографические алгоритмы. Например, Вы можете применять смарт-карты для входа пользователей в систему, а криптог рафические карты FORTEZZA Ч для защищенной почты и защищенных брау зеров. В общем случае более устойчивая криптографическая технология поддер живает более длинные сроки действия ключей;
Х риском атаки на цепочку сертификации ЦС, которые зависят прежде всего от того, насколько защищено Ваше предприятие, насколько ценны сетевые ресур сы, защищенные приложениями, поддерживающими технологию открытого ключа, и сколько будет стоить атака потенциальным взломщикам. В общем слу чае чем выше риск атаки, тем важнее устанавливать более длинные закрытые ключи ЦС и меньшие сроки действия ключей.
Для снижения риска компрометации закрытого ключа наборы закрытых и откры тых ключей следует обновлять вместе с сертификатами до истечения срока дей ствия ключей. Однако для некоторых аппаратных поставщиков службы криптог рафии обновление сертификатов с новыми наборами ключей невозможно по при чине небольшого объема хранилища ключей или потому что на генерацию ключа требуется слишком много времени.
В процессе установки центра сертификации Windows 2000 на первой странице ма стера Windows Components wizard (Мастер компонентов Windows) пометьте фла жок Advanced options (Дополнительные возможности), что позволит Вам задать длину ключа, используемого в сертификате ЦС, из диапазона 384Ч16384 бит. В общем случае чем длиннее ключ, тем больше безопасный срок его действия. Для ЦС следует использовать ключи длиной не менее 1 024 бита.
Рекомендуется использовать настолько длинные ключи, насколько это позволяют обстоятельства, то есть обеспечить максимальную защиту без снижения произво дительности ЦС. Очень длинные ключи существенно загружают процессор, и опе рации подписания могут занимать слишком много времени. Поэкспериментируйте с различными длинами ключа ЦС в лабораторных условиях и на тестовых програм мах, прежде чем развертывать ЦС в сети предприятия.
Подробнее о рисках, связанных с закрытыми ключами Ч в главе 14 Криптогра фия в сетевых информационных системах.
При обновлении сертификатов средствами поставщиков Microsoft CSP можно так же обновлять набор закрытых и открытых ключей сертификата. В общем случае чем дольше используются ключи, тем выше риск их компрометации. Установите максимальные допустимые сроки действия ключей и обновляйте сертификаты с новыми ключами до истечения этих сроков.
Запрос и обновление сертификатов Службы сертификации Windows 2000 поддерживают следующие способы запроса, выпуска и обновления сертификатов:
Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 Х запрос сертификатов вручную с помощью мастера Certificate Request wizard (Мастер запроса сертификата) (только для пользователей и компьютеров под управлением Windows 2000);
Х автоматические запросы сертификатов с помощью мастера Automatic Certificate Request Setup wizard (Мастер установки автоматического запроса сертификатов) (только для сертификатов для компьютеров под управлением Windows 2000);
Х запрос сертификатов вручную с помощью Web-стратшц для подачи заявок че рез Интернет (для пользователей браузера);
Х запрос сертификатов для смарт-карт средствами Smart Card Enrollment Station (Станция подачи заявок смарт-карт) на страницах поддержки подачи заянок через Интернет;
Х специальные (нестандартные) приложения для запроса и обновления сертифи катов.
Способы подачи заявок и типы сертификатов, поддерживаемые службами серти фикации сторонних поставщиков, определяются особенностями реализации этих служб. За дополнительной информацией следует обращаться непосредственно к поставщикам таких служб.
Запрос сертификатов вручную клиентами под управлением Windows Для запроса и обновления сертификатов для пользователей и компьютеров под упраклением Windows 2000 используется мастер Certificate Request wizard (Маспер запроса сертификата), запускаемый из консоли Certificates (Сертификаты). Мас тер запроса сертификата недоступен, если центр сертификации предприятия недо ступен в интерактивном режиме. В списках управления доступом (ACL) шаблонов сертификатов определено, какие учетные записи пользователей или компьютеров обладают правом получать сертификаты того или иного типа.
Мастер Certificate Renewal wizard (Мастер обновления сертификатов) применяет ся для обновления сертификатов до или после истечения срока их действия. Этот мастер недоступен, если центр сертификации предприятия недоступен в интерак тивном режиме. Мастер обновления сертификатов позволяет обновить сертификат с прежними закрытыми и открытыми ключами. Не следует обновлять сертификат с прежними ключами, если при этом превышается максимальный безопасный срок действия ключей.
Автоматический запрос и обновление сертификатов Мастер Automatic Certificate Request Setup wizard (Мастер установки автоматичес кого запроса сертификатов), запускаемый из контекстного меню папки Public Key Policy (Политики открытого ключа) в оснастке Group Policy (Групповая полити ка), используется для конфигурации ароматической подачи заявок на сертифика ты компьютеров. Этот мастер не поддерживает автоматическую подачу заявок на сертификаты пользователей и недоступен, если центр сертификации предприятия недоступен в интерактивном режиме. Автоматически допускается запрашивать сер тификаты типов Computer (Компьютер), Domain Controller (Контроллер домена) и IPSec.
После настройки автоматической подачи заявок сертификаты указанных типов выпускаются автоматически для всех компьютеров, обладающих разрешением Безопасность в распределенных системах 724 ЧАСТЬ Enroll (Заявка) на запрашиваемый тип сертификата, в пределах действия данной групповой политики открытого ключа. Такие сертификаты выпускаются автомати чески при следующем сетевом входе компьютера в систему.
Например, если Вы сконфигурируете автоматическую подачу заявок на сертифи каты Computer, сертификаты будут выпускаться для всех компьютеров в группе безопасности Domain Computers (Компьютеры домепа) в области действия груп повой политики открытого ключа. По умолчанию все компьютеры под управлени ем Windows 2000, за исключением контроллеров домена, серверов служб Routing and Remote Access (Маршрутизация и удаленный доступ) и Internet Authentication Services (Службы проверки подлинности в Интернете) Ч члены группы Domain Computers. Компьютеры, обладающие правом получать сертификаты Computer, определяют, изменяя ACL шаблонов соответствующего сертификата, например пре доставляя разрешение Enroll (Заявка) отдельной группе выбранных Вами компью теров. Компьютеры в области действия групповой политики открытого ключа члены такой группы, получат сертификаты компьютеров при следующем сетевом входе в систему.
Кроме того, Вы также вправе применять подразделения (organizational unit) и соот ветствующую им групповую политику открытого ключа для ограничения автома тической подачи заявок и получения сертификатов отдельным группам компьюте ров. Например, создав подразделение 1 PSec Authentication, содержащее клиенты под управлением Windows 2000, обязанные проходить проверку подлинности с при менением сертификатов TPSec, Вы можете ограничить автоматический выпуск сер тификатов IPSec, настроив групповую политику открытого ключа и порядок авто матического запроса и выпуска в этом подразделении.
После настройки автоматического запроса сертификатов выпущенные в автомати ческом режиме сертификаты компьютеров обновляются выпускающим ЦС пред приятия также автоматически. Сертификаты компьютеров также обновляются вручную средствами мастера Certificate Renewal или с помощью страниц запроса сертификатов через Интернет.
Страницы запроса сертификатов через Интернет Страницы Web Enrollment Support (Страницы подачи заявок на сертификаты че рез Интернет) служб сертификации в Windows 2000 состоят из страниц Active Server Pages и элементов управления ActiveX, предоставляющих пользователю Web-интерфейс центра сертификации. По умолчанию эти страницы устанавлива ются автоматически одновременно с ЦС. Можно также установить эти страницы на другом компьютере под управлением Windows 2000 Server.
Страницы подачи заявок на сертификаты через Интернет поддерживают выполне ние следующих задач:
Х запрос и получение основного сертификата пользователя;
Х запрос и получение сертификатов других типов средствами расширенного за проса;
Х запрос сертификатов с помощью файла запроса сертификата;
Х обновление сертификатов с помощью файла обновления сертификата;
Х сохранение запроса сертификата в файле;
Х сохранение выпущенного сертификата в файле;
ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 Х проверку ожидающих выполнения запросов на сертификаты;
Х просмотр сертификата ЦС:
Х просмотр последнего списка отозванных сертификатов;
Х запрос на сертификаты смарт-карт от имени других пользователей (доступно для доверенных администраторов).
Страницы подачи заявок на сертификаты через Интернет, устанавливаемые на изо лированном ЦС, аналогичны страницам ЦС предприятия. Единственное отличие в том, что изолированный ЦС не поддерживает шаблоны сертификатов. В запросе в изолированный ЦС ноеобходимо указать всю информацию о сертификате, в том числе сведения о том, кто запрашивает. Страницы подачи заявок через Интернет на изолированном ЦС поддерживают ряд типов сертификатов, практически таких же, как типы сертификатов на основе шаблонов. Развернув изолированный ЦС и страницы подачи заявок на сертификаты через Интернет, Вы сможете выпускать сертификаты большинства типов, поддерживаемых ЦС предприятия. Тем не менее ЦС предприятия незаменим при выпуске сертификатов для входа в систему со смарт-картой и для автоматического выпуска сертификатов.
Страницы подачи заявок па сертификаты через Интернет поддерживаются Micro soft Internet Explorer версий 4 и 5. При использовании поставщика Microsoft Enhanced Cryptographic Provider необходим браузер Internet Explorer с поддерж кой не подлежащих экспорту криптографических технологий. Браузеры Internet Explorer с поддержкой разрешенных к экспорту криптографических технологий со вместимы только с поставщиком Microsoft Base Cryptographic Provider.
Netscape Navigator версии 4.x и Netscape Communicator версии 4.x поддерживают большинство страниц подачи заявок через Интернет. Браузеры Netscape не юд лерживают страницы Advanced Certificate Request (Расширенные запросы на сер тификаты) и Smart Card Enrollment Station (Станция подачи заявок смарт-карт), так как на них размещены элементы управления ActiveX. Кроме того, браузеры Netscape используют собственные криптографические модули, а не поставщики CSP и по этому не поддерживают все функции поставщиков Microsoft CSP.
Специальные пользовательские приложения для запроса и обновления сертификатов Стандартные методы запроса, выпуска и обновления в Windows 2000 удовлетворя ют широкий диапазон потребностей. Однако если их возможностей Вам не хватает, Вы впране разработать собственные специальные приложения для запроса и обнов ления сертификатов. Модуль входа служб сертификации Windows 2000 поддержи вает стандартные формы запросы сертификатов посредством запросов удаленного вызова процедур (RPC) или по протоколу HTTP. Вы также можете разработать специальные приложения, запрашивающие сертификаты в службе сертификации ЦС Windows 2000. Подробнее о разработке специализированных приложений, взаимо действующих со службами сертификации Windows 2000 Ч на Web-странице Web Resources по адресу ссылка Microsoft Platform SDK.
Групповая политика открытого ключа Политика открытого ключа Ч это подмножество групповой политики. В оснастке P u b l i c Key Group Policy (Групповая политика открытого ключа) настраивается ав ЧАСТЬ 2 Безопасность в распределенных системах тематический запрос сертификатов компьютеров, доверенных корневых сертифи катов, списков CTL для компьютеров и пользователей, а также агентов восстанов ления EFS. Она также применяется для распространения групповой политики на сайты, домены и подразделения.
Консоль Group Policy (Групповая политика) - это оснастка ММС, которая позво ляет управлять групповой политикой открытого ключа сайтов, доменов и подраз делений, конфигурировать ее для отдельных пользователей и компьютеров, а так же выполнять следующие действия по администрированию групповой политики открытого ключа для компьютером:
Х определять сертификаты, размещаемые в хранилище Trusted Root Certification Authorities (Доверенные корневые центры сертификации);
Х создавать списки CTL для доверия центрам сертификации и ограничивать ис пользование сертификатов, выпущенных отдельными ЦС;
Х определять автоматическую подачу заявок, выпуск и обновление для сертифи катов компьютеров;
Х определять альтернативные агенты восстановления данных для EFS.
Параметры групповой политики открытого ключа действительны в области дей ствия данной групповой политики. Например, параметры политики открытого клю ча, примененные к подразделению, определяют эту политику только для данного подразделения.
Кроме того, консоль Group Policy (Групповая политика) используется для конфи гурирования списков CTL, действительных только в пределах области действия данной групповой политики. Например, списки, определенные для отдельного подразделения, применяются только к пользователям в данном подразделении.
Подробнее о групповой политике в главе 22 книги Распределенные системы.
Книга 2. Ресурсы Microsoft Windows 2000 (Русская Редакция, 2001).
Списки отозванных сертификатов Windows 2000 поддерживает стандартные списки отозванных сертификатов (certificate revocation list, CRT.) формата Х.509 v2. Каждый ЦС поддерживает спис ки CRL выпускаемых им сертификатов и публикует их в точках распространения CRL (CRL distribution points, CDP), в качестве которых выступают Web-страницы, общие папки в сети или служба каталогов Active Directory. В сертификате формата Х.509 v3 обычно содержится указание на точку CDP, выпустившего его центра сер тификации.
По умолчанию - С предприятия еженедельно публикует списки CRL в Active Directory, а изолированный ЦС на сервере ЦС в папке:
<днск>:\WINNT\System32\Certs rv\Certen roll где <()иск> Ч буква диска, на котором установлен ЦС.
Точки распространения CRL определяются средствами консоли Certification Authority (Центр сертификации). В этой же консоли можно публиковать новые списки CRL или изменить расписание публикации.
Проверка отозванных сертификатов службами подключения Internet Explorer 5, Internet Information Services и в Active Directory. При включенной функции про верки отозванных сертификатов у Вас есть возможность кэшировать списки CRL ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 до развертывания решений па основе смарт-карт. Программное обеспечение этих производителей также применяется для определения PIN-кода, настройки числа попыток ввести PIN-код до блокировки смарт-карты и отмены блокировки.
Подробнее о смарт-картах Ч в главе 13 Обеспечение безопасности средствами тех нологии открытого ключа.
Сопоставление сертификатов Сопоставление сертификатов (certificate mapping) используется для управления доступом к сетевым ресурсам учетных записей пользователей домена, а также к ресурсам Web-узла на сервере Internet Information Services.
Доменные учетные записи пользователей Средства оснастки Active Directory Users and Computers (Active Directory пользо ватели и компьютеры) позволяют сопоставлять сертификаты отдельным сетевым учетным записям пользователей. Сопоставленные сертификаты применяются для проверки подлинности пользователей в процессе аутентификации Kerberos. Тем, кто прошел проверку предоставляются права и разрешения соответствующих учет ных записей. Сертификаты на пход в систему по смарт-карте Ч особые. В процессе входа система автоматически сопоставляет сертификат смарт-карты соответствую щей учетной записи пользователя Windows 2000.
Для сопоставления сертификатов следует в оснастке Active Directory Users and Computers (Active Directory пользователи и компьютеры) отметить (если этого еще не сделано) команду Advanced Features (Дополнительные функции) в меню View (Вид). Чтобы отобразить сертификат, щелкните правой кнопкой мыши учет ную запись пользователя и в контекстном меню выберите Name Mappings (Ото бражение имен). В открывшемся диалоговом окне Security Identity Mapping (Со поставление идентичности зашиты) щелкните Add (Добавить), чтобы импортиро вать сертификаты, которые требуется сопоставить учетной записи пользователя.
Одной учетной записи можно сопоставить несколько сертификатов. Например, вы пустить сертификат агента восстановления EFS для смарт-карты назначенным агентам восстановления, а затем сопоставить эти сертификаты учетным записям пользователей, уполномоченных для восстановления EFS. Проверка подлинности агентов восстановления EFS будет выполняться средствами смарт-карты, что обес печит дополнительную защиту.
Сопоставлять сертификаты разрешается только отдельным учетным записям пользо вателей, но не группам безопасности. При сопоставлении других сертификатов, то есть не хранящихся на смарт-картах, пользователи смогут войти под сопоставленной учетной записью пользователя только в систему компьютера, где расположен закры тый ключ (если, конечно, для входа дополнительно не применяются смарт-карты или перемещаемые профили).
Internet Information Services Сервер Internet Information Services поддерживает сопоставление сертификатов учетным записям пользователей, которые управляют доступом к ресурсам, публи куемым в Интернете. Сопоставленные сертификаты нужны либо для запрещения доступа к ресурсам, либо для предоставления прав и разрешений соответствующей учетной записи. Разрешается отображать как один (однозначное сопоставление), так и несколько (множественное сопоставление) сертификатов на одну учетную Безопасность в распределенных системах 730 ЧАСТЬ запись пользователя. При множественном отображении устанавливаются правила отбора сертификатов для сопоставления. Только сертификаты, удовлетворяющие таким правилам, сопоставляются соответствующей учетной записи. Например, пра вило может определять, что сертификаты, выпущенные одним определенным цен тром сертификации, сопоставляются другим учетным записям пользователей. Все клиенты с сертификатами, выпущенными указанным 1ДС, сопоставляются соответ ствующей учетной записи пользователя, и им предоставляются все определяемые сертификатом права и разрешения.
Подробнее о сопоставлении сертификатов в Internet Information Services Ч в главе Обеспечение безопасности средствами технологии открытого ключа.
Поддержка перемещаемых профилей Windows 2000 поддерживает перемещаемые профили пользователей, в результате сертификаты (и закрытые ключи) могут следовать за пользователями и не зави сят от того, с какого компьютера те входят в систему. При наличии поддержки пе ремещаемых профилей все данные пользователей, в том числе выпущенные сер тификаты и закрытые ключи, хранятся на контроллере домена. Перемещаемые про фили загружаются на компьютер в процессе входа пользователя в систему. Смарт карты также поддерживают перемещение, так как на них размещены все реквизиты, необходимые для входа пользователя в систему. Подробнее о перемещаемых профи лях в главе 21 книги Распределенные системы. Книга 2. Ресурсы Microsoft Windows 2000 (Русская Редакция*, 2001).
Развертывание служб сертификации Развертывание служб сертификации Windows 2000 обычно выполняется в следую щей последовательности:
Х установка центров сертификации;
Х конфигурация центров сертификации;
Х изменение установленных по умолчанию разрешений для шаблонов сертифика тов (при необходимости);
Х установка и настройка вспомогательных систем или приложений;
Х настройка групповой политики открытого ключа;
Х установка страниц Web Enrollment Support (Служба подачи заявок на сертифи кат через Интернет) (при необходимости);
Х настройка параметров безопасности страниц Web Enrollment Support (при не обходимости).
Подробнее об установке служб сертификации Windows 2000 Ч в справочной сис теме служб сертификации. Подробнее о планировании и развертывании инфра структуры открытого ключа Ч в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000).
Установка центров сертификации Для нормальной работы служб сертификации в организации иерархия ЦС должна соответствовать потребностям Вашей организации. В Windows 2000 устанавлива ют центры сертификации предприятия и изолированные ЦС. Сначала рекоменду ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 ется установить корневой ЦС, а затем подчиненные. Например, трехуровневая иерархия сертификации устанавливается, как правило, в следующем порядке:
1. корневой ЦС;
2. промежуточный ЦС;
3. выпускающий ЦС.
Хотя такой порядок необязателен. Сертификат корневого ЦС заверяется его соб ственной подписью, поэтому такие центры сертификации не нуждаются при уста новке в других ЦС. Однако для завершения установки дочернего ЦС требуется, чтобы родительский ЦС обработал запрос на сертификат и выпустил для него сер тификат подчиненного ЦС. Такой ЦС можно установить в любой момент, сохра нив запрос на сертификат в файле, который следует позже отправить родительско му ЦС. После установки и запуска родительского ЦС файл запроса на сертификат отправляется посредством Web-страницы Advanced Certificate Request (Расширен ные запросы на сертификаты) родительского ЦС. После выпуска сертификат для дочернего ЦС устанавливается средствами оснастки Certification Authority (Центр сертификации). Подчиненный центр сертификации не работает без действительно го сертификата ЦС.
Вы вправе установить ЦС на контроллерах домена, хотя это не рекомендуется. Для распределения сетевой нагрузки и предупреждения перегрузки для этого рекомен дуется выбирать компьютеры под управлением Windows 2000 Server, специал.по выделенные для выполнения функций центра сертификации. Кроме того, Web-стра ницы подачи заявок через Интернет стоит также размещать на отдельном компью тере под управлением Windows 2000 Server.
За дополнительными сведениями об установке ЦС сторонних поставщиков и их иза имодействии с ЦС в Windows обращайтесь к документации соответствующих ЦС.
Обновление Certificate Server 1. При обновлении сервера под управлением Windows NT 4.0 со службой Certificate Server 1.0 до Windows 2000 Server эта служба автоматически обновляется до ио:юй версии Certificate Services (Службы сертификации). Если обновляемый ЦС исполь зует модуль политики, отличный от стандартного модуля политики Certificate Server 1.0, то службы сертификации продолжают использовать старый модуль, ко торый в дальнейшем называется Legacy policy module (Модуль поддержки старой политики). Если ЦС использует стандартный модуль политики, на обновленном ЦС применяется изолированная политика служб сертификации.
Если ЦС на базе Certificate Server 1.0 не обновляется, а устанавливается новый центр сертификации Windows 2000, предназначенный для его замены, может воз никнуть необходимость использовать старый модуль политики, а не стандартный, предоставляемый службами сертификации. Для замены стандартного модуля поли тики на специальный модуль или на модуль, разработанный для Certificate Server 1. и Windows NT 4.0, следует сначала командой Regsrv32 зарегистрировать DLL-биб лиотеку модуля политики, а затем подключить к ЦС средствами оснастки Certification Authority (Центр сертификации). Подробнее об использовании Regsv и выборе модулей политики - в справочной системе Microsoft Windows 2000 Server и справочной системе служб сертификации.
Безопасность в распределенных системах 732 ЧАСТЬ Создание заявления поставщика ЦС (при необходимости) При установке ЦС Вы вправе добавить заявление поставщика о правилах приме нения ЦС. Оно отобразится, когда Вы щелкнете кнопку Issuer Statement (Заявле ние поставщика) на вкладке General (Общие) диалогового окна Certificate (Сер тификат). Политика применения ЦС - это заявление о политике, содержащий све дения об авторских правах и другие сопутствующие сведения о ЦС, а также о по литике выпуска сертификатов, ограничениях ответственности и др.
Файл с политикой применения следует установить на сервере до установки служб сертификации Windows 2000. Он пазы кается Capolicy.ini и размещается в каталоге %Systemroot%. (По умолчанию %Systemroot% это C:\Winnt.) Этот файл содержит текст, отображаемый в качестве заявления о политике применения ЦС, или URL адрес, по которому расположено само заявление, например Web-страница. Подроб нее о создании файла Capoficy.inf -- в справочной системе служб сертификации.
Установка служб сертификации Windows Для установки центра сертификации следует войти под учетной записью члена локальной группы Administrator (Администратор) на изолированных компьютерах или члена группы Domain Administrator (Администратор домена) на компьютерах Ч членах домена, ^ Установка служб сертификации Windows 1. В Control Panel (Панель управления) щелкните значок Add/Remove Programs (Установка и удаление программ).
Откроется диалоговое окно Add/Remove Programs (Установка и удаление про грамм).
2. Щелкните кнопку Add/Remove Windows Components (Добавление и удаление компонентов Windows).
3. В открывшемся окне мастера Windows Component установите флажок Certificate services (Службы сертификации).
4. Щелкните Next (Далее) и следуйте инструкциям мастера Windows Components для завершения установки ЦС, В таблицах 16-5 Ч 16-9 описаны параметры конфигурации ЦС на каждой из стра ниц мастера Windows Component.
Примечание После установки ЦС компьютер нельзя переименовать, присоединить к домену или исключить из его состава. При установке ЦС предприятия обязатель но наличие Active Directory, поэтому компьютер с ЦС должен быть членом домена Windows 2000.
Таблица 16-5. Страница Certification Authority Type Selection (Тип центра сертификации) Параметр Описание Enterprise root CA Установка корневого центра сертификации предприятия (корневой ЦС предприятия) Enterprise subordinate CA Устанопка подчиненного центра сертификации (подчиненный ЦС предприятия) предприятия Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 Таблица 16-5. (продолжение) Параметр Описание Stand-alone root CA Установка изолированного корневого центра (изолированный корневой ЦС) сертификации Stand-alone subordinate С А Установка изолированного подчиненного центра (изолированный сертификации подчиненный ЦС) Advanced options Установка этого флажка позволяет настраивать допол (Дополнительные возможности) нительные параметры на странице Public and Private Key Selection (Пара открытого и закрытого ключей) Таблица 16-6. Страница Public and Private Key Selection (Пара открытого и закрытого ключей) Параметр Описание В этом списке выбирается поставщик службы криптографии, Cryptographic service provider предназначенный для генерации пары отрытого и закрытого ключей для сертификата ЦС. Этот же CSP управляет и хр.шит (Поставщик CSP) закрытый ключ. CSP по умолчанию Ч Microsoft Base Crypto graphic Provider или Microsoft Enhanced Cryptographic Provider, в зависимости от того, какие технологии криптографии под держивает данная версия Windows 2000 Ч разрешенные или запрещенные к экспорту Если для управления и хранения зак рытых ключей Вы предпочитаете другой поставщик CSP, на пример аппаратный, следует выбрать его в этом списке Hash algorithms В этом списке укажите алгоритм хэширования, необходимый для цифрового подписания сертификатов ЦС. По умолчанию (Алгоритм хеширования) выбран алгоритм SIIA-1, обеспечивающий самую надежную криптографическую защиту Key length Выберите длину ключа из списка или введите длину закрытого (Длина ключа) и открытого ключей. По умолчанию устанавливается 512-бит ный ключ для Microsoft Base Cryptographic Provider и 1 024 битный Ч для Microsoft Enhanced Cryptographic Provider. Дли на ключа выбирается из диапазона 384 - 16 381 бит. Для I [С используйте ключ длиной по крайней мере 1 024 бит. В общем случае чем больше длина, тем длинней безопасный срок дгй ствия закрытого ключа. Следует использовать ключи макси мальной длины, соответствующие ограничениям CSP по хране нию ключей, при которых производительность ЦС не опуска ется ниже допустимого уровня Установив этот флажок, Вы получите возможность выбрать Use existing keys закрытый ключ из списка существующих ключей. Этот флажок (Использовать обычно применяют при восстановлении центра сертификации существующие ключи) Use the associated Этот флажок позволяет выбрать сертификат, связанный с су certificate ществующим закрытым ключом, используемым ЦС. Список недоступен, если не установлен флажок Use existing keys.
(Использовать обычно используемый при восстановлении центра связанный сертификат) сертификации Импорт закрытого ключа, которого нет в списке Use existing Import keys. Например, закрытый ключ для восстанавливаемого ЦС (Импорт) зачастую импортируется из архива Позволяет просмотреть сертификат, связанный с выбранным View Certificate закрытым ключом в списке Use existing keys (Просмотр сертификата) Безопасность в распределенных системах 734 ЧАСТЬ Таблица 16-7. Страница СА Identifying Information ЦС (Сведения о центре с ертификации ) Параметр Описание СА name (Имя ЦС) Информация, которая однозначно идентифицирует создаваемый ЦС.
Эти данные размещаются в сертификате ЦС в поле Subject (Субъект) Organization Значение параметра СА name используется системой Windows (Организация) для идентификации ЦС, поэтому оно должно быть уникальным среди Organizational unit всех ЦС организации. Значения всех остальных полей могут совпа (Подразделение) дать для всех ЦС. Другие программы для идентификации поиска и Locality (Город) обращения к ЦС обычно используют поле Subject (Субъект) State or province (Область) Country/region (Страна/регион) E-mail (Электронная почта) СА description Описание данного центра сертификации (не обязательно) (Описание ЦС) Validity duration Срок действия сертификата корневого ЦС. Поле со списком содер (Срок действия) жит три значения: Years (лет), Months (месяцев) и Weeks (недель).
Срок действия по умолчанию сертификата корневого ЦС Ч 2 года.
Установите срок действия в соответствии с выбранным жизненным циклом сертификата. Этот параметр недоступен при установке под чиненного ЦС, так как срок действия определяет родительский ЦС Дата завершения срока действия сертификата корневого ЦС в соот Expires on ветствии со сроком, указанным в поле Validity duration (Истекает) Таблица 16-8. Страница Data Storage Location (Размещение хранилища данных) Параметр Описание По умолчанию база данных сертификатов и журнал размещаются в Certificate database папке
Х установить сертификат ЦС;
Х конфигурировать параметры модуля выхода;
Х конфигурировать параметры модуля политики;
Х определить расписание публикации списков отозванных сертификатов;
Х изменить разрешения и делегировать управление центром сертификации;
Х по особому требованию обеспечить поддержку проверки отозванных сертифи катов средствами браузеров Netscape через Интернет.
Подробнее об использовании консоли Certification Authority Ч в справочной сис теме служб сертификации.
Установка сертификата ЦС Если в процессе установки сертификат для подчиненного ЦС запрашивался в изо лированном ЦС, Вы обязаны получить и установить его. Он необходим для серти фикации ЦС, который не может работать, пока на нем не установлен сертификат ЦС. Выполнять эти операции на корневом или подчиненном ЦС, получивших сер тификат в ЦС предприятия при установке, не требуется.
Для получения сертификата. ЦС воспользуйтесь Web-страницей Submit a Saved Request (Выдача сохраненного запроса) Ч одной из страниц подачи заявок на сер тификаты через Интернет, чтобы отправить файл запроса на сертификат, создан ный во время установки. На следующей странице Issued Certificate (Сертификат выдан) щелкните кнопку Install this certification path (Загрузить путь сертифика ции ЦС), чтобы загрузить файл с путем сертификации. Далее средствами оснастки ЧАСТЬ 2 Безопасность в распределенных системах Certification Authority (Центр сертификации) загрузите путь сертификации из фай ла и сертифицируйте ЦС.
Для установки сертификата ЦС средствами консоли Certification Authority щелкни те правой кнопкой мыши узел ЦС, выберите- в контекстном меню подменю All Tasks (Все задачи) и щелкните команду Install (Установить сертификат ЦС). Система ус тановит сертификат ЦС, выпущенный родительским ЦС, и запустит службу ЦС.
Настройка параметров модуля политики Дополнительная настройка параметров модуля политики не требуется, если опи санные в этом разделе параметры по умолчанию Вас устраивают. В противном слу чае воспользуйтесь средствами консоли Certification Authority: щелкните правой кнопкой мыши узел ЦС и контекстном меню выберите Properties (Свойства). В открывшемся окне свойств ЦС перейдите на вкладку Policy Module (Модуль по литики) и щелкните кнопку Configure (Настроить). В диалоговом окне Properties (Свойства) измените значения параметров. В следующих разделах описаны пара метры на странице свойств модуля политики.
Вкладка Default Action (Действие по умолчанию) (на изолированных центрах сертификации) Но умолчанию установлен переключатель Set the certificate request to pending (Присвоить сертификату состояние ожидания) запрос размещается в очереди отложенных сертификатов до одобрения его администратором. Установите пере ключатель Automatically approve the certificate requests (Всегда выдавать серти фикат), чтобы изолированный ЦС автоматически удовлетворял правомерные за просы и выпускал сертификаты. Однако имейте в виду, что такая конфигурация со здает серьезный риск для безопасности и поэтому не рекомендуется. В ЦС пред приятия переключатель Set the certificate request to pending недоступен.
Вкладка Х.509 Extensions (расширения Х 509) Нажимая кнопки Add (Добавить) и Remove (Удалить), Вы можете изменять точки распространения CRL, указанные в списке Distribution Points CRL [Точки распро странения списков отзыва (CRL)]. Например, чтобы предоставить пользователям удобный доступ к спискам CRL, добавьте в качестве точки распространения CRL общие папки или URL-адрес страницы на внутреннем Web-узле. ЦС записывает информацию об этих точках во все выпускаемые сертификаты. Это позволяет при ложениям, например Internet Explorer, проверять отозванные сертификаты, На стройте модуль выхода ЦС на публикацию всех CRL во все добавленные в список точки распространения CRL. Чтобы отключить точку распространения CRL в списке Distribution Points CRL, достаточно сбросить флажок, расположенный рядом с ней.
Кнопками Add (Добавить) и Remove (Удалить) можно изменить состав точек рас пространения сертификатов, указанных в списке Authority Information Access (До ступ к информации о центрах сертификации). Например, чтобы предоставить пользователям удобный доступ к сертификатам, добавьте в качестве точки распро странения общие папки или URL-адрес страницы на внутреннем Web-узле. Серти фикаты, выпускаемые данным ЦС, публикуются в указанных точках распростра нения сертификатов. Кроме того, ЦС размещает сведения об этих точках в каждый сертификат. Чтобы отключить точку распространения сертификатов в списке Authority Information Access, достаточно сбросить флажок рядом с ее именем. При просмотре пути сертификата, выпущенного данным ЦС, в диалоговом окне Cer tificate (Сертификат) на вкладке Certification Path (Путь сертификации) |то есть ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 при выборе сертификата в пути сертификации и нажатии кнопки View (Просмотр сертификата)] система, пытаясь обнаружить соответствующий сертификат, про сматривает точки распространения в порядке, указанном в списке Authority In formation Access, Настройка параметров модуля выхода Дополнительно настраивать параметры модуля выхода не надо, если описанные в этом разделе параметры по умолчанию Вас удовлетворяют. В противном случае, чтобы настроить модули выхода средствами консоли Certification Authority, щелк ните правой кнопкой мыши узел ЦС и контекстном меню выберите Properties (Свойства). В открывшемся диалоговом окне свойств ЦС перейдите на вкладку Exit Modules (Модуль выхода), затем кнопками Add (Добавить) и Remove (Удалить) настройте список активных модулей выхода Active exit modules (Активные моду ли выхода). Если Вы применяете модуль ныхода собственной разработки или сто ронних постанщиков, установите его как активный.
Дополнительные модули выхода устанавливаются, когда сертификаты и списки CRL публикуются в местах, не указанных в стандартном модуле выхода предпрЕ1я тия или изолированного ЦС. Например, на Web-странице или в.службе каталогов стороннего поставщика.
Независимо от установленных модулей выхода, сертификаты не публикуются, если место публикации в запросе не указано. Модули выхода позволяют публиковать сертификаты в местах, указанных в запросе.
Чтобы настроить параметры модуля выхода средствами консоли Certification Authority, щелкните правой кнопкой мыши узел ЦС и контекстном меню выберите Properties (Свойства). В открывшемся диалоговом окне свойств ЦС перейдите на вкладку Exit Modules (Модуль выхода). Укажите модуль и щелкните к н о п к у Configure (Настроить). В диалоговом окне Properties (Свойства) измените значе ния параметров.
Таблица 16-10. Параметры модуля выхода Параметр Описание Allow certificate publication По умолчанию в стандартном модуле выхода предприятия to Active Directory этот флажок установлен. Сбросьте его, если публикация (Разрешить публикацию сертификатов или списков CRL в Active Directory не тре сертификатов в Active буется. Этот флажок недоступен в стандартном изолиро DirecLory) ванном модуле выхода Allow certificate publication to По умолчанию н стандартном изолированном модуле ныхо the file system да этот флажок установлен. Сбросьте его, если публикация (Разрешить сертификатов или списков CRL в файловой системе не публикацию сертификатов в требуется. По у м о л ч а н и ю в стандартном модуле выхода предприятия он сброшен. Установите этот флажок, если файловой системе) требуется публиковать сертификаты или списки CRL в файловой системе Если на ЦС предприятия работает (активен) стандартный модуль выхода с пара метрами по умолчанию, сертификаты публикуются в Active Directory. На изолиро ванном ЦС активный стандартный модуль выхода с параметрами по умолчанию публикует сертификаты в локальной файловой системе.
Безопасность.в распределенных системах 738 ЧАСТЬ Планирование публикации списков отозванных сертификатов Дополнительно настраивать параметры публикации списков CRL не надо, если опи санные в этом разделе параметры по умолчанию (еженедельная публикация) Вас устраивают. При настройке публикации CRL придерживайтесь следующих правил:
Х планируйте ежедневную, а не еженедельную публикацию CRL, если число от зываемых сертификатов велико или если требуется усилить безопасность цен ной информации, защищенной системой безопасности открытого ключа;
Х планируйте публикацию CRL раз в две недели или раз в месяц, если число от зываемых сертификатов невелико;
Х отключите автоматическую публикацию CRL на ЦС автономного режима, на пример на изолированном корневом ЦС или изолированном промежуточном ЦС, и публикуйте списки CRL вручную.
Чтобы изменить расписание публикации CRL средствами Certification Authority, щелкните правой кнопкой мыши узел Revoked Certificates (Отозванные сертифи каты) и в контекстном меню щелкните Properties (Свойства). В диалоговом окне Properties: Revoked Certificate (Свойства: Отозванные сертификаты) настройте параметры публикации CRL. Они описаны в таблице 16-11.
Таблица 16-11. Параметры публикации CRL Параметр Описание Publish Interval Определяет период публикации. Единица измерения выбирается из множества: Hours (часов), Days (дней), Weeks (недель). Months (меся (Интервал публикации) цев) или Years (лет). Например, для публикации CRL каждые две не дели введите 2 и к поле со списком выберите Weeks (недель) Next Publish Отображает дату и время следующей запланированной публикации (Следующее списка CRL обновление) Disable Scheduled Этот флажок включает или отключает автоматическую публикацию Publishing CRL на данном - С (Отключить публикацию по. :
расписанию) Х.' View Current CRL Просмотр самого последнего списка CRL данного ЦС (Просмотр текущего CRL) Конфигурация выпускаемых сертификатов При установке ЦС предприятия стандартная политика поддерживает выпуск сер тификатов следующих типов: Administrator (Администратор), Domain Controller (Контроллер домена), Computer (Компьютер), Basic EFS (Валовое шифрование EPS), EFS Recovery Agent (Агент восстановления EFS), User (Пользователь), Subordinate Certification Authority (Подчиненный центр сертификации) и Web Server (Веб-сервер). Политика выпуска настраивается индивидуально для каждого ЦС в соответствии с потребностями организации.
Для выпуска сертификатов других типов, кроме стандартных, следует добавить эти типы в политику выпуска средствами консоли Certification Authority. Эта же кон соль используется для отмены в политике выпуска отдельных видов сертификатов.
Например, можно сконфигурировать политику выпуска па корневом или промежу Службы сертификации и инфраструктура открытого ключа в Windows 2000 ГЛАВА точном ЦС для выпуска только сертификатов подчиненного ЦС или создать вы пускающий ЦС, добавив в политику выпуска сертификат Trust List Signing (Под писывание списка доверия) и удалив Subordinate Certification Authority. Вы также вправе заставить ЦС выпускать только сертификаты Enrollment Agent (Агент по дачи заявок), или Smart Card Logon (Вход со смарт-картой), или Smart Card User (Пользователь со смарт-картой) - два последних поддерживают развертывание смарт-карт.
Чтобы добавить тип сертификата в политику выпуска с помощью оснастки Cer tification Authority, щелкните правой кнопкой мьттпи узел Policy Settings (Парамет ры политики). В контекстном меню выберите подменю New (Создать) и щелкните команду Certificate to Issue (Выдаваемый сертификат). В диалоговом окне Select Certificate Template (Выбор шаблона сертификатов) укажите один или несколько шаблонов сертификатов и щелкните ОК Ч они будут добавлены в политику пуб ликации.
Когда Вы выбираете узел параметров политики ЦС, типы сертификатов, поддер живаемые центром сертификации, показаны в области сведений. Чтобы удалить шаблон сертификата из политики публикации, выберите шаблон и нажмите клави шу Delete;
или щелкните правой кнопкой мыши шаблон сертификата и в контекст ном меню выберите Delete (Удалить).
Разрешения на получение сертификатов управляются индивидуально списками ACL каждого из шаблонов (подробнее Ч в разделе Изменение стандартных разре шений шаблонов сертификатов (по требованию) далее в этой главе) средствами консоли Certification Authority. Это позволяет запретить отдельным пользователям или группам получать в данном ЦС сертификаты определенных типов.
Изменение конфигурации безопасности центра сертификации По умолчанию члены локальных групп Administrators (Администраторы) и Authenticated Users (Прошедшие проверку), а также Domain Admins (Администра торы домена) и Enterprise Admins (Администраторы предприятия) обладают раз решением Enroll (Заявка) и поэтому уполномочены запрашивать сертификаты в ЦС.
То есть по умолчанию все пользователи домена вправе запрашивать в СА сертифи каты разрешенных им типов. Кроме того, члены локальной группы Administrators и глобальных групп Domain Admins и Enterprise Admins обладают на ЦС разрешени ем Manage (Управление). Дополнительно настраивать разрешения не надо, если кон фигурация безопасности ЦС по умолчанию удовлетворяет Вашим потребностям.
Чтобы настроить параметры безопасности средствами консоли Certification Au thority, щелкните правой кнопкой мыши узел ЦС и контекстном меню выберите Properties (Свойства). В открывшемся диалоговом окне свойств ЦС перейдите на вкладку Security (Безопасность) и измените значения параметров. Используйте кнопки Add (Добавить) и Remove (Удалить) для изменения пользователей и групп в списке Permissions (Разрешения).
Чтобы изменить основные разрешения, выберите группу или учетную запись пользо вателя из списка и установите или снимите соответствующие флажки Allow (Раз решить) или Deny (Запретить) рядом с записями основных разрешений в списке Permissions.
Чтобы изменить дополнительные разрешения, щелкните кнопку Advanced (Допол нительно). В диалоговом окне Permissions (Разрешения) посредством кнопок Add и Remove откоректируйте список групп безопасности и учетные записи полыюва Безопасность в распределенных системах 740 ЧАСТЬ телей. Для изменения дополнительных разрешений группы или учетной записи пользователя выберите ее в списке и щелкните кнопку View/Edit (Показать/Из менить).
В таблице 16-12 описаны разрешения для ЦС, которые настраиваются в дополни тельном диалоговом окне Permissions (Разрешения).
Таблица 16-12. Разрешения для шаблонов сертификатов Разрешение Описание Manage (Управление) Определяет, каким учетным записям пользователей и группам (основное разрешение) разрешено управлять ЦС средствами консоли Certification Authority или служебных программ командной строки. По умолча нию предоставлено членам локальной группы Administrators (Ад министраторы) и членам глобальных групп Domain Admins (Адми нистраторы домена) и Enterprise Admins (Администраторы предприятия) Определяет, каким учетным записям пользователей и группам Enroll (Заявка) (основное разрешение) разрешено запрашивать сертификаты в ЦС. По умолчанию предос тавлено членам локальных групп Administrators (Администрато ры) и Authenticated Users (Прошедшие проверку) и членам гло бальных групп Domain Admins (Администраторы домена) и Enterprise Admins (Администраторы предприятия) Read (Чтение) (допол- Определяет, каким учетным записям пользователей и группам нительное разрешение) разрешено читать информацию конфигурации ЦС. По умолчанию предоставлено членам локальных групп Administrators (Админист раторы) и Authenticated Users (Прошедшие проверку) и членам глобальных групп Domain Admins (Администраторы домена) и Enterprise A d m i n s (Администраторы предприятия) Определяет, каким учетным записям пользователей и группам Write Configuration разрешено изменять данные конфигурации ЦС. По умолчанию (Запись конфирура ции)(дополнительное предоставляется всем учетным записям пользователей и группам, разрешение) обладающим разрешением Manage Read Control (Чтение Определяет, каким учетным записям пользователей и группам разрешений) (дополни- разрешено просматривать параметры безопасности ЦС. По умол тельное разрешение) чанию предоставляется всем учетным записям пользователей и группам, обладающим разрешением Read Modify Permissions Определяет, каким учетным записям пользователей и группам (Смена разрешений) разрешено изменять разрешения ЦС. По умолчанию предоставля (допол н ительное ется всем учетным записям пользователей и группам, обладающим разрешение) разрешением Manage Modify Owner (Смена Определяет, каким учетным записям пользователей и группам владельца)(дополни- разрешено изменять владельца объекта ЦС. По умолчанию предос тельное разрешение) тавляется всем учетным записям пользователей и группам, облада ющим разрешением Manage Revoke Certificates Определяет, каким учетным записям пользователей и группам (Отзыв сертификата) разрешено отзывать сертификаты. По умолчанию предоставляется (дополнительное всем учетным записям пользователей и группам, обладающим раз разрешение) решением Manage Approve Certificates Определяет, каким учетным записям пользователей и группам (Подтверждение сер- разрешено одобрять запросы на сертификаты. По умолчанию пре тификатов) (дополни- доставляется всем учетным записям пользователей и группам, об ладающим разрешением Manage тельное разрешение) Read Database (Чтение Определяет, каким учетным записям пользователей и группам базы данных) (дополни- разрешен доступ и чтение информации базы данных сертифика тельное разрешение) тов. По умолчанию предоставляется всем учетным записям пользователей и группам, обладающим разрешением Manage ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 Совместимая с Netscape проверка отозванных сертификатов через Интернет Браузеры Netscape поддерживают частный метод интерактивной проверки отозван ных сертификатов в местах, которые указаны в дополнительных полях сертифика та. Для внедрения в сертификат совместимых с Netscape расширений проверки от зыва сертификатов через Интернет выполните в командной строке на сервере ЦС следующую команду:
Certutil -SetReg Policy\RevocationType +AspEnable После перезапуска службы центра сертификации во всех выпускаемых сертифика тах появятся дополнительные поля, необходимые для поддержки Netscape, Изменение стандартных разрешений шаблонов сертификатов (по требованию) На ЦС предприятия разрешения Enroll (Заявка) управляются списками ACL каж дого из шаблонов сертификатов. ЦС предприятия выдает сертификаты только учет ным записям пользователей или компьютеров, обладающим этим разрешением.
Существует стандартная (по умолчанию) конфигурация списков ACL для различ ных шаблонов пользователей и групп.
По умолчанию членам группы Domain Admins (Администраторы домена) в доме не, где установлен ЦС. предоставлено разрешение Enroll (Заявка) на все типы с ер тификатов. Членам группы Domain Users (Пользователи домена) предоставлено разрешение Enroll для следующих типов сертификатов: Basic EFS, Authenticated Session, Exchange User, Exchange Signature Only, User и User Signature Only. Чле нам группы Enterprise Admins предоставлено разрешение Enroll для всех типов сер тификатов за исключением: Basic EFS, Authenticated Session, Exchange User, Ex change Signature Only, User и User Signature Only.
Если необходимо позволить другим группам запрашивать сертификаты, следует отредактировать списки управления доступом соответствующих шаблонов серти фикатов (в домене, где установлен ЦС), добавив в них разрешение Enroll. Если тре буется разрешить запрос сертификатов в ЦС предприятия группам другого доме на, необходимо добавить группу другого домена в ACL шаблонов сертификатов для домена, где установлен центр сертификации.
Для изменения списков ACL для шаблонов сертификатов используется оснастка Active Directory Sites and Services (Active Directory - сайты и службы). Чтобы ото бразить в этой оснастке контейнер Certificate Templates, следует в меню View (Вид) отметить команду Show Services Node (Показать узел служб), если она еще не отмечена. Подробнее об использовании оснастки Active Directory Sites and Services в справочной системе Active Directory.
Чтобы отобразить контейнер Certificate Templates, разверните контейнеры Services и Public Key Services (рис. 16-11).
Для редактирования списков ACL шаблонов сертификатов щелкните Certificate Templates, в области сведений щелкните правой кнопкой мишки требуемый шаб лон и выберите Properties (Свойства). В диалоговом окне свойств ЦС перейдите на вкладку Security (Безопасность) и настройте разрешения. Подробнее о редакти ровании списков ACL для шаблонов сертификатов -- в справочной системе служб сертификации.
Безопасность в распределенных системах 742 ЧАСТЬ Action Viei" Fa^wite Tvpe' Tree j'Favorites j.
_ Console Root | Certificate Template gg Active Directory 5ites and Servic ClientAutt-, Certificate Template E L3 Sites Certificate Template К LJ Service?
!+.: л] MsniqServices JCTLSigning Certficate Template Х+Х CJ NetServices jDomairiControlle' Certificate Template ?] C] Public Key Services Certificate Template lEFSRecoverv "ei-tificate Template E nrolhi en t Services i Enrollment Agent Teftificate Template lEnrollmentAgentOffline Certificate Template Si Windows NT Certificate Template |ExchangeUser5ignature Certificate Template >!
Рис. 16-11. Контейнер Certificate Templates Например, чтобы предоставить доступ к сертификату Enrollment Agent (Агент по дачи заявок) только нескольким доверенным пользователям, следует изменить спи сок управления доступом шаблона сертификата Enrollment Agent, удалив заданные по умолчанию группы безопасности и добавив специальную группу и предоставив ей разрешение Enroll. Аналогично Вы можете поступить с шаблоном сертификата Code Signing (Подписывание кода), предоставив разрешение на него только специ альной группе разработчиков, ответствешплх за подписание кода.
Примечание После изменения епископ ACL шаблонов сертификатов следует по дождать определенное время, пока изменения не распространятся на остальные контроллеры домена.
Установка и конфигурация вспомогательных систем или приложений Обязательно следует установить вес необходимые для поддержки инфраструктуры открытого ключа вспомогательные системы или приложения, в том числе:
Х устройства чтения смарт-карт на локальных компьютерах;
Х системы управления ключами и защищенной почтой;
Х специальные приложения запроса, получения и обновления сертификатов;
Х Web-узлы поддержки и обучения пользователей работе со службами сертифи кации;
Х инфраструктуру открытого ключа и службы сертификации сторонних постав щиков.
Конфигурирование групповой политики открытого ключа Настройка групповой политики открытого ключа для сайтов, доменов, подразделе ний, а также локальной политики компьютера выполняется средствами консоли Group Policy (Групповая политика). Большинство функций инфраструктуры от Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 крытого ключа и служб сертификации не требуют вмешательства. Однако Вам при дется настроить групповую политику открытого ключа при выполнении следую щих операций:
Х при автоматическом выпуске сертификатов для компьютеров;
Х при добавлении доверенных корневых сертификатов для групп компьютеров;
Х при создании списков CTL для компьютеров и пользователей;
Х при назначении учетных записей агентов восстановления EFS.
^ Добавление оснастки Group Policy (Групповая политика) в ММС 1. Откройте ММС.
2. В меню Console (Консоль) выберите команду Add/Remove Snap-in (Добавить/ удалить оснастку) или нажмите CTRL+M.
Откроется диалоговое окно Add/Remove Snap-in (Добавить/Удалить оснастку).
Щелкните Add (Добавить).
3.
Откроется диалоговое окно Add Standalone Snap-in (Добавить изолированную оснастку).
4. В списке оснасток выберите Group Policy (Групповая политика) и щелкните Add (Добавить).
Откроется диалоговое окно Select Group Policy Object (Выбор объекта группо вой политики) с именем локального компьютера в поле Group Policy Object (Объект групповой политики).
5. Выберите одну из двух возможностей:
Х чтобы управлять политикой локального компьютера, щелкните Finish (Готово);
Х чтобы управлять другой групповой политикой, щелкните Browse (Обзор) и выберите существующую или создайте новую политику. Щелкните Finish (Готово).
Возвратившись в диалоговое окно Add Standalone Snap-in, Вы можете еще \rn\i щелкнуть Add и добавить еще одну оснастку.
Закончив добавлять оснастки в диалоговом окне Add Standalone Snap-in, щел 6.
кните Close (Закрыть).
В диалоговом окне Add/Remove Snap-in отображаются выбранные Вами оснас тки для установки в ММС, 7. В диалоговом окне Add/Remove Snap-in щелкните кнопку ОК.
В каждом объекте групповой политики сайтов, доменов и подразделений содержат ся два контейнера Public Key Policy (Политики открытого ключа) Ч для компью теров и для пользователей. На рис. 16-12 показан контейнер Public Key Policy для компьютеров в папке Default Domain Policy. Чтобы отобразить контейнер Public Key Policy, последовательно разверните узлы Computer Configuration (Конфигу рация компьютера) и Security Settings (Параметры безопасности), а затем щелк ните Public Key Policies (Политики открытого ключа).
Безопасность в распределенных системах 744 НАСТЬ I 1 Encrypted Data Recovery Agents -onsole Root UJ Automatic Certificate Request Settings ч? Default Domain Polty [Serverl.rEskit.com] Policy L_jT>usted Root Certification Authorities r jjll Computer Configuration ^IjEnterprise Trust SI 3 Software Settings E Cj Windows Settings Security Settings Account Policies I Local Policies I Event Log i Restricted Groups i System Services Registry i File System '_J Encrvoted Dat^ Recovery Agents L...1 Automatic Certificate Request Settings CD Trusted Root Certification Authorities G3 Enterprise Trust IP Я "S ^ecuritj" Policies on Active Directory '._ UJ Administrative TenipJates User Configuration Рис. 16-12. Контейнер Public Key Policy в разделе Computer Configuration На рис. 16-13 показан контейнер Public Key Policy в панке Default Domain Policy.
Чтобы увидеть контейнер Public Key Policy для пользователей, последовательно разверните узлы User Configuration (Конфигурация пользователя) и Security Settings (Параметры безопасности), а затем щелкните Public Key Policies (Поли тики открытого ключа).
гч,^? d Х Х Ь." ' "i :
.
u & as == j ;
"jj Console Window. 'Йе% ;
Tuf* | Partitas j -?b!?ct Type JEnterprise Trust "Л Console Root El | ? Default Domain Policy [5erverl.feskit.com] Policy J.+. jfl Computer Configuration Н-фГ User Configuration i: j Software Sethng.;
FT I J Windows Settings b? -^fj Internet Expbrer Maintenance :- | Scripts (Logon /Logoff) Щ Is- з> Security Settings ' :i Entetprise Trust sJH- Remote InstciSahon Services [*: ;
"J Folder Redirection j..l...i., :--;
l - ,+! i \ Administrative Templates Рис. 16-13. Контейнер Public Key Policy в разделе User Configuration ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 Контейнеры Public Key Policies используются для выполнения следующих задач:
Х Automatic Certificate Request Settings (Параметры автоматического запроса сертификатов) Ч для настройки автоматического выпуска сертификатов;
Х Trusted Root Certification Authorities (Доверенные корневые центры сертифи кации) Ч для добавления сертификатов доверенных корневых ЦС в хранилище Trusted Root Certification Authorities (Доверенные корневые центры сертифи кации);
Х Enterprise Trust (Доверительные отношения в предприятии) Ч для настройки списков CTL (это единственный контейнер, отображаемый в разделе конфигу рации пользователя);
Х Encrypted Data Recovery Agents (Агенты восстановления шифрованных дан ных) Ч для конфигурирования агентов восстановления EPS Ч это единствен ный контейнер доступный в объекте Local Computer policy (Политика Локаль ный компьютер).
Для пользователей можно настроить только списки CTL. В локальной компьютер ной политике доступна настройка только политики агентов восстановления EFS Ч Encrypted Data Recovery Agents Policy. Подробнее о конфигурировании групповой политики открытого ключа Ч в справочной системе служб сертификации и груп повой политики.
Примечание Изменения групповой политики не вступают в силу немедленно. Груп повая политика пользователей и компьютеров обновляется периодически (по умол чанию, каждые 90 минут), а также при входе пользователей в систему и запуске компьютеров. Для обновления политики вручную следует выполнить в командной строке команду Secedit /refreshPolicy на каждом локальном компьютере.
Автоматический выпуск сертификата Разрешается настроить автоматический выпуск и обновление сертификатов ком пьютеров. При этом сертификаты выделенных для автоматического выпуска типов выпускаются автоматически для всех компьютеров в области действия данной груп повой политики открытого ключа. Такие сертификаты компьютеров обновляются центром сертификации также автоматически. Автоматический выпуск невозможен, если хотя бы один ЦС предприятия не способен обрабатывать запросы на серти фикаты в интерактивном режиме.
Чтобы настроить автоматический выпуск сертификатов, в узле Public Key Policies (Политики открытого ключа) щелкните правой кнопкой мыши узел Automatic Certificate Request Settings (Параметры автоматического запроса сертификатов) и в подменю New (Создать) контекстного меню выберите команду Automatic Certificate Request (Автоматический запрос сертификатов). На страницах мастера Automatic Certificate Request wizard (Мастер установки автоматического запроса сертификатов) установите нужные параметры. Элементы страниц описаны в таб лице 16-13.
746 ЧАСТЬ 2 Безопасность в распределенных системах Таблица 16-13. Элементы окон мастера установки автоматического запроса сертификатов Страница Описание Certificate Template Выберите шаблон сертификата из списка Certificate templates (Шаблон сертификата) (Шаблоны сертификатов) и щелкните кнопку Next (Далее), Все компьютеры, обладающие разрешением Enroll (Заявка), в области действия политики автоматического выпуска будут получать сертификаты автоматически после перезапуска компьютера и входа в домен Certification Authority Пометьте один или несколько ЦС в списке Certification authorities (Центры сертификации). При выборе нескольких (Центр сертификации) ЦС запросы на сертификаты обрабатывает доступный ЦС первый в списке. Выбрав один или несколько центров сертифи кации, щелкните кнопку Next и закончите работу с мастером Доверие по корневым сертификатам При установке корневого ЦС предприятия или изолированного корневого ЦС сер тификат этого центра сертификации автоматически размещается в папке Trusted Root Certification Authorities (Доверенные корневые центры сертификации) кон тейнера групповой политики домена. Вы также вправе добавлять в эту папку сер тификаты других корневых ЦС. Сертификаты корневых ЦС, размещаемые в папке Trusted Root Certification Authorities, становятся доверенными корневыми ЦС для компьютеров, на которые распространяется действие данной групповой политики, Например, чтобы использовать сторонний центр сертификации в качестве корне вого ЦС в иерархии сертификации предприятия, следует добавить сертификат это го ЦС в папку Trusted Root Certification Authorities соответствующей групповой политики.
Чтобы добавить сертификат в папку доверенных корневых ЦС, в узле Public Key Policies (Политики открытого ключа) контейнера групповой политики щелкните правой кнопкой мыши узел Trusted Root Certification Authorities (Доверенные корневые центры сертификации), в контекстном меню перейдите в подменю All Tasks (Все задачи) и выберите команду Import (Импорт). Используйте открывше еся окно мастера Certificate Import wizard (Мастер импорта сертификатов), чтобы импортировать файл с сертификатом корневого ЦС и добавить его в политику груп пы. Сертификат будет скопирован в хранилище Trusted Root Certification Au thorities на всех компьютерах в области действия групповой политики при следу ющем ее обновлении.
Списки доверия сертификатов Списки доверия сертификатов (certificate trust list, CTL) создаются для управле ния доверием сертификатам отдельных ЦС и (при необходимости) для ограниче ния перечня назначений сертификатов. Например, Вы вправе средствами CTL ука зать, что доверенными являются только сертификаты, выпущенные коммерческим ЦС, и разрешить использовать только их. Списки CTL также применяются для управления доверием в экстрасетях Ч для сертификатов, выпущенных центрами сертификации деловых партнеров. Существует возможность индивидуальной на стройки списков CTL для компьютеров и пользователей.
Для создания списков CTL администратор должен обладать действительным сер тификатом подписания списков доверии [например, Administrator (Администратор) Службы сертификации и инфраструктура открытого ключа в Windows 2000 ГЛАВА или Trust List Signing (Подписывание списка доверия)], выпущенным ЦС предпри ятия. Для обеспечения целостности списка Администратор подписывает его с по мощью закрытого ключа подписания списков CTL. Если сертификат администра тора недействителен, все списки CTL, которые созданы и подписаны им, также ут рачивают законную силу.
Чтобы создать CTL для компьютеров или пользователей, в узле Public Key Policies (подчиненном узла Computer Configuration или User Configuration) щелкните тра вой кнопкой мыши узел Enterprise Trust (Доверительные отношения в предприя тии), в контекстном меню перейдите в подменю New (Создать) и щелкните коман ду Certificate Trust List (Список доверия сертификатов). Используйте мастер Certificate Trust wizard (Мастер списков доверия сертификатов) для создания спис ка CTL и задания его параметров. Элементы страниц мастера Certificate Trust спи саны в таблицах 16-14 Ч 16-18.
Таблица 16-14. Страница Certificate Trust List Purpose (Назначения для списка доверия сертификатов) Элемент Описание Type a prefix that identifies Поле ввода префикса для CTL. Этот префикс необходим this CTL (optional) [Введите для уникальной идентификации списка CTL префикс, идентифицирующий этот список (не обязательно)] Valid duration (optional)[Срок Определяет срок действия для CTL. Введите число месяцев в поле Months (месяцев) и число дней в поле Days (дней).
действия (не обязательно)] Если не определить этот параметр, срок действия CTL за кончится в момент истечения срока годности сертификата, использованного для подписания этого списка Designate Purposes В списке Designate Purposes пометьте одно или более на (Назначения) значений для списка доверия. Списки CTL устанавливают доверие только для сертификатов, применимых для выб ранных целей. Сертификат обычно поддерживает все допу стимые назначения, но Вы вправе ограничить цели, для которых его разрешается применять Add Purpose Щелкните эту кнопку, чтобы добавить дополнительные назначения в поле Designate Purposes. В открывшемся (Добавить назначение) диалоговом окне User Denned Purpose (Цели, определен ные пользователем) введите идентификатор объекта нового назначения в поле Object ID (Код объекта) Таблица 16-15. Страница Certificates in the CTL [Сертификаты в списке доверия (CTL)] Элемент Описание Current CTL Certificates В списке отображены сертификаты корневых ЦС, доверие к (Сертификаты из текущего которым поддерживается этим списком CTL. Сертификаты списка доверия) с путями сертификации, ведущими к этому корневому ЦС.
являются доверенными для всех назначений, указанных в CTL Add from Store Добавляет корневой сертификат из хранилища Trusted (Добавить из хранилища) Root Certification Authorities (Доверенные корневые цгь i' ры сертификации). В открывшемся диалоговом окне Select Certificate (Выбор сертификата) выберите все требуемые сертификаты и щелкните ОК (см. след, стр.) Безопасность в распределенных системах 748 ЧАСТЬ Таблица 16-15. (продолжение) Описание Элемент Add from File (Добавить Добавление сертификата корневого ЦС из файла из файла) Удаление выбранного сертификата из ноля Current CTL Remove (Удалить) Certificates View Certificate (Показать) Просмотр сведений о сертификате, выбранном в поле Current CTL Certificates Таблица 16-16. Страница Signature Certificate (Сертификат подписи) Описание Элемент Use this certificate Отображает сертификат подписания списков доверия, свя занный с закрытым ключом, который будет использоваться (Использовать этот для подписания CTL сертификат) Добавление сертификата подписания списков доверия из Select from Store (Выбрать хранилища Personal (Личные) администратора. В открыв из хранилища) шемся диалоговом окне Select Certificate (Выбор сертифи ката) выберите требуемые сертификаты и щелкните ОК Select from File (Выбрать Добавление сертификата подписания списков доверия из файла из файла) View Certificate Просмотр сведений о сертификате, выбранном в поле Use this certificate (Просмотр сертификата) Таблица 16-17. Страница Timestamping (Штамп времени) Элемент Описание Add a timestamp to the data Добавляет в список CTL метку времени. Последняя приме (Добавить к данным штамп няется для задания срока действия CTL. Если метка време времени) ни не задана, для оценки действительности списка доверия используется системное время Timestamp service URL Поле ввода URL-адреса службы, применяемой для созда (URL-адрес службы штампа ния метки времени времени) Таблица 16-18. Страница Name and Description (Имя и описание) Элемент Описание Friendly Name Понятное пользователю имя списка доверия, отображаемое в консоли ММС при просмотре списков CTL (не обяза (Попятное имя) тельно). Для удобства просмотра рекомендуется задавать уникальные имена создаваемым спискам доверия Description (Описание) Необязательное описание данного списка CTL. Служит для информирования других пользователей о цели создания CTL Агенты восстановления EFS По умолчанию локальная учетная запись Administrator (Администратор) па пер вом созданном в домене контроллере является агентом восстановления EFS в этом дометте. Средства консоли Group Policy позволяют Вам назначить дополнительные агенты восстановления HFS, добавив сертификаты EFS Recovery Agent в группо Службы сертификации и инфраструктура открытого ключа в Windows 2000 ГЛАВА вую политику открытого ключа, по перед этим Вы должны выдать эти сертифика ты назначаемым учетным записям пользователей на локальных компьютерах.
В процессе конфигурирования параметров восстановления EFS у Вас есть две воз можности: добавить сертификаты агента восстановления, опубликованные в Active Directory, или добавить сертификаты агента восстановления из файла на диске или из общей папки, доступной с данного компьютера. Перед добавлением сертифика тов из файла их следует экспортировать в папку, из которой они будут устанавли ваться в процессе настройки групповой политики восстановления EFS.
Чтобы добавить агент восстановления EES, в узле Public Key Policies (Политики открытого ключа) щелкните правой кнопкой мыши узел Encrypted Data Recovery Agents (Агенты восстановления шифрованных данных) и в контекстном меню щел кните Add (Добавить). Используйте мастер Add Recovery Agent wizard (Мастер добавления агента восстановления), чтобы добавить сертификаты агентов восстанов ления. Элементы страницы мастера Add Recovery Agent описаны в таблице 16-19.
Таблица 16-19. Мастер Add Recovery Agent Элемент Описание Recovery agents В этом списке отображаются сертификаты назначаемы?
(Агенты восстановления) агентов восстановления Browse Directory Щелкните эту кнопку, чтобы просмотреть Active Directory (Обзор каталога) и добавить сертификат учетной записи пользователя, кото рый будет выполнять функции агента восстановления Browse Folders Щелкните эту кнопку, чтобы добавить сертификат агента (Обзор папок) восстановления из файла При выборе агента восстановления сертификаты агента восстановления EFS, опре деленные в групповой политике, отображаются в области сведений оснастки. Эти сертификаты агентов восстановления используются EFS в области действия дан ной групповой политики. Чтобы удалить сертификат агента восстановления из групповой политики, выберите сертификат нажмите клавишу Delete или щелкните правой кнопкой мыши шаблон сертификата и в контекстном меню щелкните Delete (Удалить).
Установка Web-страниц запроса сертификатов на другом компьютере (при необходимости) По умолчанию Web-страницы для подачи заявок через Интернет (Web Enrollment Support) устанавливаются на том же сервере, что и ЦС. Однако Вы вправе восполь зоваться для этой цели любым другим компьютером под управлением Windows 2000.
Установка ЦС и страниц поддержки подачи заявок через Интернет позволяет сни зить нагрузку на компьютер с ЦС при, например, большом трафике службы серти фикации или при установке служб сертификации па не особо мощных компьютерах, Страницы подачи заявок на сертификаты через Интернет устанавливаются в панку:
<днск>:\WINNT\System32\CertSrv где <диск> Ч буква диска, на котором установлены страницы Web Enrollment Support.
Папка CertSrv содержит Web-файлы (файлы Active Server Page, графические i шт лы и другие) и две панки (CertEnroll и CertControl), в которых размещены к чк> могательныс файлы и.элементы управления ActiveX для Web-страниц.
Безопасность в распределенных системах 750 ЧАСТЬ Предоставление компьютеру прав представителя На ЦС предприятия страницы подачи заявок на сертификаты через Интернет спо собны работать на компьютере отличном от Т 1C только при условии, что этот компьютер доверен для делегирования. На изолированном ЦС соблюдение этого условия не обязательно.
Предоставление компьютеру прав представителя выполняется средствами оснаст ки Active Directory Users and Computers (Active Directory пользователи и ком пьютеры). Для установки страницы подачи заявок на сертификаты через Интернет необходимо войти в систему компьютера под учетной записью члена группы Do main Admins (Администраторы домена).
^ Делегирование компьютеру прав представителя 1. В оснастке Active Directory Users and Computers (Active Directory - пользова тели и компьютеры) разверните узел домена.
2. Выберите контейнер с компьютером, которому следует делегировать права пред ставителя.
Компьютеры выбранного контейнера отобразятся в области сведений.
3. Дважды щелкните объект компьютера, которому следует предоставить права.
Откроется диалоговое окно Properties (Свойства) для выбранного компьютера.
4. В диалоговом окне Properties перейдите на вкладку General (Общие), устано вите флажок Trust computer for delegation (Доверять компьютеру права пред ставителя) и щелкните ОК или Apply (Применить).
5. Перезапустите компьютер, чтобы новые параметры вступили в силу.
До перезапуска компьютера страницы подачи заявок на сертификаты через Ин тернет недоступны.
Подробнее об оснастке Active Directory Users and Computers Ч в справочной сис теме Active Directory.
Установка страниц подачи заявок на сертификаты через Интернет Установка страниц подачи заявок на сертификаты через Интернет на компьютере, отличном от сервера ЦС, выполняется средствами мастера Windows Components wizard (Мастер компонентов Windows). Для установки этих страниц необходимо войти в систему компьютера под учетной записью члена группы Domain Admins (Администраторы домена). Страницы подачи заявок на сертификаты через Интер нет возможно установить только на компьютере под управлением Windows 2000 с установленным сервером Internet Information Services.
^ Установка страниц подачи заявок на сертификаты через Интернет на компьютере, отличном от сервера ЦС 1. В Control Panel (Панель управления) щелкните значок Add/Remove Programs (Установка и удаление программ).
Откроется диалоговое окно Add/Remove Programs (Установка и удаление про грамм).
2. Щелкните Add/Remove Windows Components (Добавление и удаление компо нентов Windows).
ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 3. В открывшемся окне мастера Windows Component установите флажок Certificate services (Службы сертификации).
4. Щелкните кнопку Details (Состав) и сбросьте флажок Certificate Services (ЦС служб сертификации). Флажок Certificate Services Web Enrollment Support (Служба подачи заявок на сертификат через Интернет) должен быть установ лен. Щелкните ОК 5. Щелкните кнопку Next (Далее) Откроется окно Certificate Services Client Configuration (Настройка клиента служб сертификации).
6. Введите доменное имя компьютера с ЦС в поле Computer Name (Компьютер) или щелкните Browse (Обзор) и найдите нужный компьютер.
В поле СА Name (Центр сертификации) отображается ЦС, работающий на выб ранном сервере. Устанавливаемые страницы подачи заявок на сертификаты че рез Интернет (Web Enrollment Support) будут работать с этим ЦС.
7. Щелкните Next (Далее) и завершите работу мастера Windows Components.
После установки проверьте работу и взаимодействие страниц подачи заявок на сер тификаты через Интернет с ЦС. Например, запросите в ЦС сертификат или спи сок CRL с помощью этих страниц. При необходимости измените параметры безо пасности по умолчанию этих страниц.
Настройка параметров безопасности страниц подачи заявок на сертификаты через Интернет (при необходимости) Папки CertSry, CertEnroll и CertControl добавляются как виртуальные катало) и в Default Web Site (Веб-узел по умолчанию) на сервере Internet Information Services.
На ЦС предприятия CertSrv и CertControl сконфигурированы для доступа с базо вой проверкой подлинности и интегрированной проверкой подлинности Windows.
Проверка подлинности пользователей и доступ к Web-ресурсам им предоставляет ся на основе сведений их учетных записей в Windows 2000. Проверка подлинности обязательна, так как ЦС предприятия при обработке запросов на сертификаты ис пользует сведения из учетных записей Windows 2000. На изолированном ЦС CertSrv и CertControl сконфигурированы для анонимного доступа, поэтому доступ к ним предоставлен всем пользователям. По умолчанию на ЦС предприятия ано нимный доступ отключен, в противном случае страницы подачи заявок на серти фикаты через Интернет не удастся применять с ЦС предприятия.
Интегрированный с Windows механизм проверки подлинности предоставляет до ступ к Web-страницам на основе реквизитов для входа в систему пользователей Internet Explorer. Пользователи получают доступ к Web-страницам только при ус ловии, что их реквизиты входа в систему соответствуют действительной учетной записи пользователя Windows 2000. Интегрированный механизм проверки подлин ности в Windows не считается стандартом HTTP и поддерживается только браузе ром Internet Explorer версии 2.0 и более поздними. Этот механизм не поддержива ет работу через прокси-серверы и другие брандмауэры.
Если интегрированная проверка подлинности Windows невозможна из-за наличия брандмауэра или какой-либо неполадки, браузер просит пользователя ввести имя и пароль для выполнения базовой проверки подлинности. Пользователям браузе ЧАСТЬ 2 Безопасность в распределенных системах ров других поставщиков также предлагается ввести реквизиты для базовой провер ки подлинности.
Базовая проверка подлинности (basic authentication) Ч это часть стандарта HTTP 1.0, поэтому большинство браузеров поддерживает такой метод. Доступ к Web-страни цам предоставляется пользователям только после ввода ими своего имени и паро ля Windows 2000. Однако следует иметь в виду, что пароли пользователей переда ются открытым текстом, поэтому их легко перехватить сетевым анализатором при передаче от браузера на Web-узел. На ЦС предприятия базовая проверка подлин ности поддерживается при доступе к страницам подачи заявок на сертификаты че рез Интернет Ч тогда они доступны из любого браузера. Поскольку передача паро лей открытым текстом представляет угрозу безопасности, желательно либо отклю чить базовую проверку подлинности, либо настроить аутентификацию на основе кэша.
Если Вам требуется поддержка только Internet Explorer, Вы можете использовать оснастку Internet Information Services для отключения базовой проверки подлин ности и предотвращения передачи паролей открытым текстом при доступе к пап кам CertSrv и CertControl. Если же необходима поддержка других браузеров, на стройте безопасность для CertSrv и CertControl на обязательное использование за щищенных каналов по протоколу SSL (Secure Sockets Layer) или TLS (Transport Layer Security). При передаче по защищенным каналам пароли шифруются. Одна ко в результате снижается производительность работы страниц подачи заявок на сертификаты через Интернет вследствие дополнительной вычислительной нагруз ки на сервер, вызванной операциями шифрования, которые необходимы для под держки защищенных каналов.
Internet Information Services также поддерживает проверку подлинности с приме нением хэша Ч порядок аутентификации, определенный в стандарте HTTP 1.1. В этом случае пароли защищены и передаются в виде хэша, который в состоянии рас шифровать только центр распространения ключей (Key Distribution Center, KDC) Windows 2000 службы проверки подлинности Kerberos. Если браузеры поддержи вают HTTP 1.1 (последние версии браузеров обычно поддерживают этот стандарт), средствами оснастки Internet Information Services отключите базовую проверку под линности и разрешите проверку подлинности на основе хэша при доступе к папкам CertSrv и CertControl. Если разрешить и основную проверку подлинности, и проверку подлинности на основе хэша, последний метод применяется, если его поддерживает браузер. В противном случае выполняется базовая проверка подлинности.
Если разрешены все виды проверки, приоритетность их применения такова:
1. проверка подлинности, интегрированная с Windows;
2. проверка подлинности на основе хэша;
3. базовая проверка подлинности.
Для проверки подлинности используется метод, обладающий наивысшим приори тетом среди поддерживаемых браузером. При отключенном анонимном доступе доступ с проверкой подлинности используется только при соответствующей на стройке безопасности файлов NTFS для управления доступом к ресурсам Web-узла.
Чтобы убедиться в корректной работе страниц подачи заявок на сертификаты че рез Интернет с новыми параметрами безопасности, проверьте их во всех браузерах, которые планируется поддерживать.
ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 Подробнее о безопасности Web-узлов на сервере internet Information Services в главе 13 Обеспечение безопасности средствами технологии открытого ключа.
Подробнее об использовании оснастки Internet Information Services для настройки безопасности и проверки подлинности при доступе к ресурсам Web-узла - в спра вочной системе Internet Information Services.
Интеграция со службами сертификации сторонних поставщиков (при необходимости) Инфраструктура открытого ключа в Windows 2000 способна взаимодействовать со службами сертификации сторонних поставщиков, которые поддерживают стаплар ты, рекомендуемые рабочей группой Public Key Infrastructure X.509 (PKIX) сооб щества Internet Engineering Task Force (IETF). Тем не менее нельзя безоговорочно гарантировать способность к взаимодействию (interoperability) между доступными на рынке PKIX-совместимыми продуктами, так как эта технология пока находится на ранней стадии своего развития. Подробнее о способности к взаимодействию - в главе 13 Обеспечение безопасности средствами технологии открытого ключа.
В общем случае службы сертификации Windows 2000 предоставляют больше преиму ществ, чем ЦС сторонних поставщиков, так как они полностью интегрированы с ин фраструктурой открытого ключа в Windows 2000 и Active Directory. Хотя, конечно, не возбраняется использовать с Windows 2000 службы сертификации сторонних по ставщиков для развертывания ЦС и выпуска сертификатов в Вашей организации.
Для корректной работы с инфраструктурой открытого ключа в Windows 2000 ЦС сторонних поставщиков должен поддерживать промышленный стандарт сертифи катов Х.50Э v3 и списков отозванных сертификатом X.509 v2. Сертификаты в стан дарте Х.509, выданные ЦС стороннего поставщика, можно использовать в большин стве решений безопасности в Windows 2000 на основе открытого ключа. Ограниче ние Ч только решения, где требуется интеграция ЦС предприятия с Active Direc tory. Например, их нельзя применять для выпуска сертификатов Smart Card Lo^on (Вход со смарт-картой) или Smart Card User (Пользователь со смарт-картой) в до менах Windows 2000 или для автоматического выпуска сертификатов компьютеров.
Вы можете использовать совместимый ЦС стороннего поставщика для поддержки всех или части цепочек доверия сертификации. Следует иметь в виду, что сертифи каты корневых ЦС сторонних поставщиков не размещаются автоматически в храни лище Trusted Root Certification Authorities. Конфигурирование групповой политики открытого ключа и добавление корневых ЦС сторонних поставщиков в это хранили ще, а также создание списков CTL для доверия таким ЦС выполняют вручную.
Прежде чем использовать службы сертификации сторонних поставщиков в инфра структуре открытого ключа Windows 2000, следует убедиться, что они работают кор ректно, и тщательно протестировать их в лаборатории и на пилотных системах. За более подробной информацией о функциях решений, предоставляемых сторон и i- ми поставщиками, обращайтесь непосредственно к соответствующим производителям.
Текущие задачи служб сертификации К задачам, постоянно выполняемым службами сертификации Windows 2000, отно сятся:
Х поддержка страниц подачи заявок на сертификаты через Интернет;
ЧАСТЬ 2 Безопасность в распределенных системах Х запрос сертификатов средствами мастера Certificate Request (Мастер запроса сертификатов);
Pages: | 1 | ... | 14 | 15 | 16 | 17 | 18 | Книги, научные публикации