Книги, научные публикации
Pages: | 1 | ... | 13 | 14 | 15 | 16 | 17 | ... | 18 | Distributed Systems Guide Microsoft Windows 2000 Server Microsoft Press Распределенные системы Книга 1 Microsof Windows 2000 ...
-- [ Страница 15 ] --При открытии шифрованного файла вызывается API-функция CreatcFile(). NTFS проверяет состояние шифрования файла па диске и затем вызывает службу EFS для проверки данных пользователя. Служба EFS находит сертификат и закрытый Безопасность в распределенных системах 658 ЧАСТЬ ключ пользователя и получает от CryptoAPI закрытый ключ для расшифровки РЕК. После этого она возвращает ключ FEK посредством библиотеки FSRTL в драйвер EFS. Если пользовательский пароль или информация агента восстановле ния изменились, служба EFS запрашивает в CryptoAPI новое значение ноля DDF или поля DRF соответственно и возвращает это значение вместе с РЕК для изме нения устаревших метаданных. Когда служба EFS возвращает метаданные, драй вер EPS устанавливает контекст EFS файлового объекта и создает поток SEFS, со держащий метаданные. РЕК используется для расшифровки файла, после чего со держимое файла отображается на экране в незашифрованном виде.
При записи в файл NTFS вызывает библиотеку EFS FSRTL для шифрования данных.
Другим пользователям, пытающимся открыть файл, в доступе будет отказано. Не возможно расшифровать файл без закрытого ключа пользователя, зашифровавше го файл, или закрытого ключа агента восстановления. Это ограничение останется в силе, даже если администратор изменит разрешения или атрибуты файла или пре доставит файл в общее владение.
Порядок расшифровки файла При расшифровке файла вызывается API-функция DecryptFileQ, и драйвер EFS пытается обнаружить контекст EPS. Рели контекста не существует, то файл уже расшифрован и никаких действий предпринимать не требуется. В противном слу чае драйвер EPS открывает файл, создает незашифрованную резервную копию, за тем снимает атрибут шифрования, удаляет метаданные и записывает данные из ре зервной копии обратно в файл.
Подробнее о расшифровке локальной папки или папки на другом компьютере - в справочной системе Microsoft Windows 2000 Professional или Microsoft Windows Server.
Порядок восстановления файла Если закрытый ключ владельца недоступен (например, вследствие повреждения), администратор Ч агент восстановления открывает файл при помощи своего закры того ключа восстановления. Последний применяется к содержимому поля DRP для расшифровки ключа РЕК. Механизм восстановления файла работает, по существу, так же как и механизм расшифровки разница в том, что используется закрытый ключ не пользователя, а агента восстановления.
Закрытый ключ восстановления не годится для расшифровки поля DDF. Если учет ных записей агентов восстановления несколько, каждый закрытый ключ восстанов ления используется для расшифровки только своего (и никакого другого) поля DRF. Поэтому нет опасности, что агент восстановления получит информацию (то есть ключ), предоставляющую доступ к другим файлам.
Как мы уже говорили ранее, по умолчанию EFS назначает агентом восстановления локальную учетную запись Administrator (Администратор) или учетную запись Administrator (Администратор) домена. В такой конфигурации EPS можно исполь зовать без каких-либо ограничений, ничего не меняя. Однако с точки зрения безо пасности корректнее сменить учетную запись агента восстановления. Поскольку при смене агента восстановления доступ к файлу закрывается, необходимо хранить сертификаты и закрытые ключи восстановления до тех пор, пока не обновится ин формация заголовков всех файлов, которые были зашифрованы с их помощью.
ГЛАВА 15 Шифрованная файловая система Примечание Не рекомендуется шифровать файлы при работе в системе под локаль ной учетной записью Administrator (Администратор), если заданный по умолчанию агент восстановления не переопределен. В этом случае восстановление файла в слу чае утери ключа станет невозможным, так как создавший файл пользователь явля ется одновременно и агентом восстановления.
Подробнее о предоставлении пользователями зашифрованных файлов для восста новления и о восстановлении файлов агентами восстановления в справочной си стеме Microsoft Windows 2000 Professional или Microsoft Windows 2000 Server.
Изменять политику восстановления EFS разрешается только членам группы Domain Admin (Администраторы домена). Подробнее об изменении политики вос становления EFS для изолированного компьютера или в домене Ч в справочной системе Microsoft Windows 2000 Server, а также в разделе Конфигурирование по литики агента восстановления далее в этой главе.
Хранение сертификатов В Windows 2000 сертификаты пользователей, содержащие открытые ключи, хранят ся в папке Personal (Личные) учетной записи пользователя Ч владельца сертифи ката. Сертификат привязывает открытый ключ к определенному субъекту (на пример, к конкретному пользователю), владеющему закрытым ключом. Так как в сертификатах информация открыта, то они хранятся в незашифрованном виде, а защиту от подделки обеспечивает цифровая подпись центра сертификации их вы пустившего. С другой стороны, закрытые ключи необходимо хранить конфиденци ально, и доступ к ним должен иметь только уполномоченный владелец.
Для каждого пользователя создается хранилище сертификатов Personal (Личные), куда помещаются выданные пользователю сертификаты. Сертификаты пользовате лей хранятся в папке %RootDirectory%\Dacumcnts and 5еЫти\<имя_полъзоватв ля>\ApplicationData\Microsoft\SystemCertificates\My Certificates профиля пользо вателя. Сертификаты из профиля пользователя записываются в хранилище Personal в реестре при каждом входе пользователя в систему. Сертификаты перемещаемых профилей хранятся на контроллере домена и временно добавляются в системный реестр того компьютера домена, в систему которого вошел пользователь с таким профилем.
Сертификаты выпускаются центрами сертификации (Certification Authority, CA), или ЦС, которые перед выпуском сертификатов проверяют аутентичность объек тов. Если ни один ЦС не доступен, EFS создает свои собственные сертификаты.
Развертывание служб сертификации для выпуска сертификатов EFS позволяет по лучить следующие преимущества:
Х централизованное управление сертификатами и публикация списков отозванных сертификатов (certificate revocation list,CRL) Х возможность выпускать для учетных записей пользователей дополнительные сертификаты агентов восстановления.
Просматривают хранилища сертификатов Personal (Личные) пользователя сред ствами оснастки Certificates (Сертификаты) (рис. 15-10). У сертификата EFS в столбце Intended Purposes (Назначения) указано Encrypting File System (Шиф рованная файловая система). Так как у пользователей может быть более одного сер Безопасность в распределенных системах 660 ЧАСТЬ тификата для файловых операций в EFS, в этом хранилище иногда находится не сколько сертификатов с аналогичной записью в столбце назначения сертификата.
_J Co rise le Root (Э Certificate? - Current User f-n-^vj Personal L Trusted Root Certf cation Authorities I К CJ Enterprise Trust >J Qj Intermediate Certification ftuthorities Ш G3 Active Directory User Object ?! D REQUEST Рис. 15-10. Сертификаты пользователя и хранилище Personal Сертификаты агентов восстановления также размещаются в хранилище сертифи катов Personal соответствующих учетных записей. На рис. 15-11 показан пример хранилища сертификатов Personal агента восстановления.
ifc^'Х'л-" ХХ илр si, tunsofei -Ilarrente R " ^ш.; ?сд~^ [f i i 'S3 -: ,'A:Son View Eavorites li'J Tree | Favorites | Х3 ' I=sued"iy 1 EsjwaBonDaSe - IWended Pirposes _J Console Root IS^Ominis-,^.' |-'P'. iХ rr,f-; ,....-:i.ril-.HTi].e-:ft e,'5/rju Microsoft Trust Li; t Signing " 8 (Э Certificates - Current U^er В Cj Parsonel SAdrrtmstratorSPreskic.ajm Enter p ri; e -Su botd irate- С Д 6,'5/Ql Certificate Rt-quest ft aent Хj Сю tfraies j Э- j Truited Root Certification Authorities Г-Ч Cj Enterprise Tru^t B- Is) Intermediate Certification ftuthorities Ы1 ' l j Active Directory User Obiect ii Ш CJ REQUEST л1 i И P sens* tee contains 3 cwtffcates. Рис. 15-11. Сертификаты агента восстановления в хранилище Personal Подробнее о хранилищах сертификатов и оснастке Certificates (Сертификаты) - в гла ве 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000*. Для сертификата восстановления в столбце Intended Purposes (Назначение) ука зано File Recovery (Восстановление файлов). Сертификаты восстановления также отображаются и в области сведений консоли Group Policy (Групповая политика) в контейнере Encrypted Data Recovery Agents (Агенты восстановления шифрованных данных). Здесь также может существовать несколько сертификатов данного типа (рис. 15-12). Подробнее о контейнере Encrypted Data Recovery Agents и групповой политике в главе 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000. Шифрованная файловая система ГЛАВА JjJ^attor..t*JJJ leRoot ХPaul1: Domain Policy [5ftVERl.res№,torn] Policy | Computer Configuration Х - Software Settings '"'i Windows Setting; з Scrip Is (Startup/Shutdown) Security Setting? - Н в AiTcciurt Policies Х "^ +j A) Local Policies 1*3 Jjj vent Lt '*' -*3 Restricted G'OLp; i CJ System Service; Л G) Registry Хf C3 File System H _J Pu3licKev Policies jjj Encrypted Data Йесо^егу Agents ^J Automate Certificate Request Settings | j Trusted Root CertiFicaticn Authorities S rj Ег*ефг15е Trust Encrypted tiste Рис. 15-12. Сертификаты агентов восстановления в папке Encrypted Data Recovery Agents Хранение закрытых ключей Закрытые ключи поставщики службы криптографии Microsoft (как Base CSPf так и Enhanced CSP) хранят в профиле пользователя - - в папке %RootDirectory% \Docuincnts and 8с^т^\<имя_поль.зователя>\АррИса1ю1\. Data\Microsoft\Crypto\RSA. Закрытые ключи перемещаемых профилей хранятся в папке RSA на контроллере до мена и загружаются на компьютер пользователя только на время сеанса в системе, то есть до выхода пользователя из системы или до перезагрузки компьютера. В отличие от открытых ключей, их парные закрытые ключи следует защищать. Поэтому, все файлы в папке RSA автоматически шифруются случайным симмет ричным ключом, который называется основным ключом пользователя (user's master key) и генерируется но алгоритму RC4 поставщиком Base CSP или Enhanced CSP. Enhanced CSP (поставщик, подлежащий ограничениям на экспорт криптографичес ких технологий) создает 128-битный ключ, a Base CSP (доступен для всех компью теров под управлением Windows 2000) 56-битный ключ. Основной ключ созда ется и регулярно обновляется поставщиком CSP автоматически. Он автоматичес ки используется для шифрования всех файлов, создаваемых в нанке RSA. Папку RSA нельзя переименовать или переместить, так как это единственное мес то, куда CSP обращается за закрытыми ключами. Поэтому рекомендуется обеспе чить ей дополнительную защиту. Например, усилить защиту файловой системы на компьютерах пользователей или использовать перемещаемые профили, Следует защищать закрытые ключи восстановления, применяемые при архивиро вании Windows 2000. Для этого сертификат и закрытый ключ копируют на дискету или другой носитель, размещают носитель в надежном хранилище и затем удаляют закрытый ключ с компьютера. Такие меры предосторожности позволяют сохранить файл при сбое системы и делают его недоступным для взлома. Для расшифровки файла с данными агенту восстановления достаточно импортировать сертификат и ЧАСТЬ 2 Безопасность в распределенных системах закрытый ключ с носителя в свою учетную запись. Подробнее об обеспечении безо пасности ключей восстановления Ч в справочной системе Microsoft Windows Server. Папка Protect Основной ключ пользователя тоже автоматически шифруется службой Protected Storage (Защищенное хранилище) и размещается в профиле пользователя в панке %RQotDirectory%\Documents and ЗеШ^\<ыжя_пользователя>\Application Data\ Microsoft\Protect. Основной ключ пользователя с перемещаемым профилем хра нится на контроллере- домена и копируется в профиль пользователя на локальном компьютере временно, только до перезагрузки. Основной ключ пользователя шифруется дважды, и полученные в результате два зашифрованных значения помещаются к две части файла в папке Protect Ч по од ному значению на часть. Первая часть файла в папке Protect Ч это ключ шифрова ния пароля (password encryption key). Она создается с помощью алгоритма НМАС (Hash-Based Message Authentication) и хэш-функции SHA1. Эта часть является хэ шем, полученным из следующих входных данных: Х основного ключа пользователя, зашифрованного симметричным 160-битным ключом по стандарту RC4; Х идентификатора безопасности (S1D) пользователя; Х пароля входа в систему пользователя. Вторая часть содержит информацию необходимую для резервного копирования и восстановления основного ключа. Она необходима, если пароль пользователя на одном компьютере изменяется, а ключи находятся в профиле пользователя на дру гом компьютере, или если администратор сбрасывает пароль пользователя. В этих случаях служба Protected Storage не в состоянии обнаружить новый пароль для об новления первой части Protect, поэтому она обращается ко второй части файла и использует се для восстановления первой части и основного ключа. Для создания резервной части файла зашифрованный основной ключ пользовате ля пересылается на контроллер домена в службу Protected Storage, которая с помо щью НМАС и SHA1 снова создает хэш-код из полученных данных и из основного ключа архивирования и восстановления (backup/restore master key) контролера до мена. Затем хэш-код пересылается обратно на компьютер пользователя и сохраня ется в файле папки Protect. Основной ключ пользователя никогда не передается по сети открытым текстом, при передаче он заверяется (подписывается и шифру ется) механизмом удаленного вызова процедур. Основной ключ архивирования и восстановления контроллера домена хранится в разделе HKEY_LOCAL_MACH1NE/SAM реестра как глобальный секрет админис тратора локальной безопасности (Local Security Authority, LSA) и распространяет ся по механизму репликации Active Directory. (Глобальные секреты LSA Ч это объекты, предоставляемые LSA для безопасного хранения конфиденциальных дан ных системными службами.) У папок System Certificates, RSA и Protect установлен системный атрибут. Это предотвращает шифрование средствами EFS расположенных в них файлов, что сде лало бы их недоступными. Шифрованная файловая система ГЛАВА Защита ключей шифрования При сохранении зашифрованного файла Windows 2000 автоматически обеспечива ет пять уровней шифрования. 1. Данные в файле шифруются ключом шифрования файла (РЕК), предоставлен ным EFS. 2. Ключ FEK шифрованная файловая система шифрует открытыми ключами из сертификатов пользователя и агента(ов) восстановления. По умолчанию откры тые ключи и сертификаты хранятся в хранилищах сертификатов компьютера. Используемые для расшифровки FEK парные закрытые ключи хранятся в за шифрованном виде в папках RSA профилей пользователя или агента(ов) вос становления. 3. Служба Protected Storage (Защищенное хранилище) генерирует основной ключ пользователя, который в дальнейшем применяется для шифрования закрытого ключа пользователя. 4. Служба Protected Storage генерирует получаемый из хеша данных учетной за писи создателя файла симметричный ключ шифрования пароля, которым шиф руется основной ключ пользователя. Эта служба также генерирует второй по хожий ключ ключ архивирования и восстановления, который содержит до полнительный хэш, полученный из основного ключа архивирования и восста новления контроллера домена. 5. Для дополнительной защиты всех основных ключей (master keys) и других хра нящихся на компьютере секретных данных можно использовать системный ключ System Key При запуске системы Windows 2000 получает системный ключ и использует его для расшифровки всех закрытых ключей на компьютере, в том числе используемые в EFS. Планирование внедрения EFS Планируя установку шифрованной файловой системы, следует предварительно проанализировать опасности, грозящие Вашей системе, и продумать, как EFS бу дет справляться с ними. Кроме того, необходимо определить, нужно ли разверты вать центр сертификации и если да, то какой. Анализ существующей системы безопасности В этом разделе мы ответим на некоторые вопросы, часто возникающие у админист раторов, рассматривающих вопрос применения EFS для защиты файлов. Возможность открыть чужой зашифрованный файл EFS упрощает выполнение обычных файловых операций. Когда пользователь об ращается к файлу, зашифрованному другим пользователем, EFS пытается найти закрытый ключ расшифровки ключа FEK, которым в свою очередь зашифрован файл. Если у текущего пользователя такого ключа нет, FEK расшифровать не уда стся, и пользователь получит сообщение об ошибке доступа. Возможность лобойти политику восстановления Этою невозможно при условии, что компьютер является членом домена и эта по литика определена на уровне домена. Политика агента восстановления EFS раснро 664 ЧАСТЬ 2 Безопасность в распределенных системах страняется на весь домен в составе групповой политики и реализуется шифрован ной файловой системы па каждом из компьютеров. Локальный администратор не в состоянии переопределить локальную политику EFS, так как приоритет доменной политики выше. Локальный администратор сможет только удалить компьютер из домена, но в этом случае пользователи потеряют возможность входить в систему под доменными учет ными записями и получать доступ к файлам, зашифрованным в соответствии с до менной политикой восстановления. Пользователи вправе войти в систему под дру гими учетными записями и зашифровать другие файлы, но после возвращения ком пьютера в домен эти файлы станут недоступными для доменных учетных записей. Вероятность нейтрализовать политику восстановления Локальный администратор может найти хранилище политики EFS и удалить или заменить его. Удаление бессмысленно, так как после этого EFS попросту переста нет работать. Замена же политики восстановления не даст результата, потому что доменная политика обладает более высоким приоритетом, и при следующем откры тии файла она переопределит любую другую политику. Вероятность физического доступа к носителям информации Злоумышленник, имеющий физический доступ к компьютеру, может попытаться взломать сам файл, расположенный па жестком диске файл. Такая атака лишена смысла, так как файл не содержит никакой информации в открытом виде и в нем нет ключей, способных преобразовать информацию в открытый текст. Файл невоз можно прочитать без закрытого ключа пользователя. Другое направление возможной атаки Ч это разрушение или удаление поля DRF. Но такая атака также лишена смысла, поскольку EFS обновит информацию вос становления при следующем обращении к файлу, Опасность не восстановить данные после сбоя при операциях шифрования или расшифровки EFS содержит систему восстановления и предотвращения потери данных в случае таких невосстановимых сбоев, как отказ системы, переполнение диска или наруше ние работы аппаратуры. Ее работа основана на создании незашифрованной резерв ной копии файла, с которым в данный момент выполняются операции шифрования или расшифровки. После успешного завершения таких операций резервная копия удаляется. Шифрование и расшифровка Ч безопасные операции, потому что при сбое на лю бом этапе система возвращает файл в состояние, предшествующее сбою. Если в ре зультате непоправимого сбоя компьютер перестает реагировать или не перегружа ется, резервная копия файла используется для выполнения отката при следующей загрузке операционной системы. Программа Windows 2000 Backup (Средства архивации и восстановления Windows 2000) автоматически определяет, что файл зашифрован и при архиви ровании сохраняет его состояние. Примечание При шифровании файла данные незашифрованной его копии остают ся на диске до тех пор, пока в занятые сю ранее блоки не будут записаны другие данные. Чтобы этого не происходило, всегда следует сначала создавать пустую за шифрованную папку и уже потом создавать в ней файлы. Такие файлы автомати чески шифруются при создании, поэтому не требуется сохранять их где-либо на диске и открытом виде. ГЛАВА 15 Шифрованная файловая система Вероятность изменения политики восстановления Администратору домена но разным причинам иногда требуется изменить полити ку восстановления, например по истечении срока действия сертификатов или при изменении учетных записей агентов восстановления. EFS проверяет, изменилась ли информация восстановления файла, только при его открытии, и если она устарела, шифрованная файловая система автоматически ее обновляет. Причина использования такого пофайлового подхода в том, что информация вос становления файла недоступна без ключа расшифровки файла (РЕК), а он извле кается только при открытии файла, Из сказанного выше следует, что зашифрованные файлы, которые давно не откры вались, помнят только старую политику восстановления. Поэтому сертификаты восстановления и закрытые ключи необходимо хранить в течение нескольких лет после изменения политики восстановления. Обновление сертификатов или ключей пользователя Так же как при изменении политики восстановления, обновления сертификатов или ключей пользователя для файла вступают в силу только при его открытии. Откры вая файл, EFS проверяет, не устарел ли закрытый ключ и сертификат пользователя и при необходимости обновляет поле DDK Но перед этим EFS должна найти старый закрытый ключ и сертификат. Просроченные сертификаты и закрытые ключи дос тупны, так как они автоматически сохраняются системой в архиве. Однако пользо ватель имеет право удалить этот архив сертификатов и закрытых ключей. Пользова тели обязаны хранить свои старые закрытые ключи до тех пор, пока пе обновлены поля DDE всех файлов, зашифрованных парным открытым ключом. При утере сер тификатов и закрытых ключей пользователя зашифрованные файлы восстанавлива ются с помощью сертификата и закрытого ключа агента восстановления. Таким об разом, архивные копии сертификатов и закрытых ключей агента восстановления не обходимо хранить в безопасном месте даже по истечении срока их действия. Вероятность того, что система не загрузится EFS активизируется только после полной загрузки операционной системы. Бот почему нельзя шифровать системные данные, в том числе реестр, системные DLL библиотеки и другие необходимые при загрузке системы файлы. Операционная система неработоспособна, если какой-либо из этих файлов зашифрован. Для пре дотвращения таких ситуаций в EES запрещено шифрование файлов и папок с установленным системным атрибутом, Особенности развертывания EFS Шифрование файлов лежит в основе их безопасности. Поэтому важно исключить возможность непреднамеренной расшифровки зашифрованных данных. Для этого пользователи должны следовать перечисленным далее правилам. Х Шифровать папку My Documents (Мои Документы) (%RootDirectory%\ Х Шифровать папку Temp (%RootDirectory%\Temp~). Это обеспечивает автомаги ческое шифрование всех создаваемых различными приложениями временных файлов и предотвращает утечку информации. Безопасность в распределенных системах 666 ЧАСТЬ Шифровать целые папки, а не отдельные файлы. Приложения по-разному рабо тают с файлами и могут создавать в процессе редактирования временные копии в той же папке, в которой расположен открытый файл. Эти копии совсем не обя зательно шифруются, и, кроме того, некоторые приложения при сохранении ре зультата заменяют ими оригинал. Очевидно, что в этом случае шифрование на уровне папки позволяет не создавать на диске незашифрованных копий файлов. Экспортировать закрытые ключи восстановления, сохранять их в безопасном месте на защиюленных носителях и удалять ключи с компьютеров. В этом слу чае не удастся использовать данные агента восстановления для чтения чужих зашифрованных файлов. Это особенно важно для изолированных компьютеров, на которых агентом восстановления назначена локальная учетная запись Administrator (Администратор) или другой локальный пользователь. Допустим, злоумышленник похитил содержащий зашифрованные файлы переносной ком пьютер. Однако ему не удастся использовать учетную запись агента восстанов ления для расшифровки файлов, так как закрытого ключа восстановления на компьютере нет. Секретность закрытых ключей, связанных с сертификатами восстановления очень важна. Нельзя оставлять их без защиты. Рекомендуется экспортировать все такие ключи на гибкий диск в защищенные сложным паролем файлы с рас ширением.pfx. Подробнее о засните ключей восстановления Ч в справочной си стеме Microsoft Windows 2000 Professional или Microsoft Windows 2000 Server. He использовать учетную запись агента восстановления для других целей, кро ме как для восстановления зашифрованных файлов. Не уничтожать сертификаты восстановления и закрытые ключи при изменении политики агента восстановления. Полезно хранить их в архиве, до тех пор пока не обновлена информация заголовков всех защищенных ими файлов. Так как EFS ищет закрытые ключи только в папке RSA, ее нельзя переимено вывать или перемещать. Желательно как можно быстрее изменять заданную по умолчанию учетную за пись агента восстановления в домене {учетная запись Administrator первого ус тановленного контроллера домена) и защитить паролями все учетные записи агентов восстановления. Это обеспечит дополнительную защиту на случай взлома учетной записи Administrator и позволит легко отслеживать исполь зование учетной записи агента восстановления. В зависимости от размера подразделения (группа компьютеров или даже отдель ный компьютер в пределах домена) рекомендуется назначать в нем не меньше двух агентов восстановления. Каждой учетной записи агента восстановления назначается отдельный компьютер и соответствующему администратору дается разрешение на ее использование. Рекомендуется выполнять мероприятия по архивированию данных агентов вос становления, чтобы гарантировать восстановление файлов, зашифрованных ус таревшими ключами. Следует соблюдать практику безопасного и контролируе мого хранения сертификатов восстановления и закрытых ключей. Рекоменду ется хранить архив в хранилище с ограниченным доступом, а также создать ос новной и резервный архив. Главный архив располагается локально, а резервный архив Ч в безопасном месте вне защищаемого объекта. ГЛАВА 15 Шифрованная файловая система Х При печати следует избегать создания буферного файла. Если же он все-таки необходим, следует размещать его в зашифрованной панке. Х Рекомендуется создавать системный ключ на изолированных компьютерах, не относящихся к каким-либо доменам для обеспечения защиты закрытого ключа пользователя EFS системным ключом. Подробнее --- в разделе Использование системного ключа далее в этой главе. Политика восстановления В политике восстановления EFS определены применяемые в области ее действия учетные записи агентов восстановления данных. Для нормальной работы EFS тре буется определить политику агента восстановления шифрованных данных. Если этого не сделать, система использует агент восстановления по умолчанию учет ную запись Administrator (Администратор). В домене только члены группы Domain Admins (Администраторы домена) обладают правом назначать агентов восстанов ления. В средах, где домены отсутствуют, например в небольшой компании или на домашнем компьютере, агентом восстановления по умолчанию назначается учетная запись Administrator (Администратор) изолированного компьютера. Эта же учетная запись обладает правом изменять локальную политику восстановления компьютера. Учетная запись агента восстановления применяется для восстановления шифрован ных данных па всех компьютерах в области действия соответствующей политики. В случае утери закрытого ключа пользователь создает программой Windows Backup (Средства архивации и восстановления Windows 2000) резервную копию защищенного этим ключом файла и пересылает ее по защищенной электронной почте агенту восстановления. Агент восстановления получает резервную копию, считывает файл, создает его незашифрованную копию и возвращает незашифрован ный файл пользователю по защищенной электронной почте. Существует другой способ восстановления данных. Администратор может импор тировать свой сертификат и закрытый ключ восстановления на компьютер, где хранятся шифрованные файлы, и выполнить процедуры восстановления на нем. Но такой способ не рекомендуется, так как он небезопасен. Ключ восстановления это секретные данные, и администратор не должен оставлять его на другом компьютере. Внедрение политики Политика агента восстановления шифрованных данных это часть групповой по литики, она настраивается в контейнере Encrypted Data Recovery Agents (Агенты восстановления шифрованных данных) оснастки Group Policy (Групповая полити ка). Подробнее о настройке политики восстановления EFS в главе 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000. Так же как и другие компоненты групповой политики, область действия политики восстановления распространяется на самые различные по размеру области: Х сайт; Х домен; Х подразделение Ч группу компьютеров или даже на единственный компьютер в пределах домена; Х подразделение Ч часть другого, большего подразделения; Х изолированный компьютер. Безопасность в распределенных системах 668 ЧАСТЬ По умолчанию областью действия групповой политики является домен. Каждый компьютер под управлением Windows 2000 в пределах области действия групповой политики управляется набором правил для этой области. Действие политики раз решается корректировать, редактируя списки ACL. Подробнее о групповой поли тике и о механизме ее работы в главе 22 книги Распределенные системы. Кни га 2. Ресурсы Microsoft Windows 2000 (<Х Русская Редакция, 2001). Примечание Политика применяется па уровне компьютеров, а не учетных записей пользователей, так как шифрованные данные хранятся на компьютерах независи мо от того, кто их зашифровал. Подсистема защиты Windows 2000 сама заботится о распространении, репликации, кэшировании и изменении политики ноестановления. Поэтому пользователи могут применять шифрование файлов на временно изолированной (отключенной от сети) системе, например на переносном компьютере. В этом случае механизм работы на поминает вход пользователя в систему под доменной учетной записью с использо ванием данных входа их кеша. Для шифрования FEK при создании поля DRF необходимы только открытые час ти ключевых пар восстановления. Поэтому для нормальной работы файловой сис темы EFS открытые ключи восстановления должны быть всегда доступны. В поли тике агента восстановления шифрованных данных они представлены в виде серти фикатов агента восстановления. Защита ключа восстановления очень важна. Между сеансами восстановления не обходимо удалять закрытые ключи учетных записей агента восстановления с соот ветствующих компьютеров и сохранять их на защищенных гибких дисках или дру гих безопасных устройствах хранения информации. (Подробнее о безопасном уда лении закрытых ключей с компьютера -- в справочной системе Microsoft Windows 2000 Professional или Microsoft Windows 2000 Server.) Реализация политики Система EFS применяет политику восстановления при каждом открытии шифро ванного файла. При этом проверяется соответствие информации восстановления файла и текущей политики. Если такого соответствия нет, заголовочные данные файла обновляются. Таким образом, обеспечивается обновление информации вос становления для всех используемых файлов. При необходимости восстановить файл пользователь обращается к политике восстановления EFS, чтобы выяснить, какому администратору с правами агента восстановления следует отправить файл для восстановления. Если файл давно пе открывался, информация агента восста новления устаревает. Служебная программа efsinfo позволяет получить содержащу юся в зашифрованных файлах информацию об агенте восстановления. Подробнее об efsinfo Ч в разделе Просмотр информации агента восстановления далее в этой главе. Разрешается создавать одну или более учетных записей агентов восстановления для целой группы компьютеров в пределах домена. Для этого средствами оснастки Group Policy (Групповая политика) эти компьютеры объединяются в подразделе ние. Тогда любой из этих агентов восстановления можно использовать для восста новления любых файлов в этом подразделении. ГЛАВА 15 Шифрованная файловая система Политика без сертификатов восстановления, так называемая пустая политика (empty policy), отключает систему EFS на всех компьютерах в области ее примене ния. Следует различать пустую политику и полное отсутствие политики, когда сер тификаты агентов восстановления удаляются из объектов политики восстановле ния EFS. Отсутствие политики подразумевает безразличие* к централизованной политике, и каждый компьютер применяет свою локальную политику. По правилам EFS, если в политике восстановления применен хотя бы один недей ствительный сертификат, то нся политика теряет силу. При этом EFS прекращает всякое шифрование новых файлов. Тем не менее сохраняется поддержка расшиф ровки уже зашифрованных файлов. По умолчанию групповая политика наследуется и обладает кумулятивностью, то есть она последовательно применяется, начиная с самой широкой области действия и заканчивая самой узкой. При входе пользователя в систему сначала применяется политика сайта, потом Ч политика домена и в последнюю очередь Ч политика под разделения. Если на компьютере определена локальная политика, она применяется только в изолированном режиме и при присоединении компьютера к домену заве щается политикой подразделения. Приоритеты политик расположены в порядке, обратном их применению. При возникновении противоречий между политиками сайта, домена или подразделения более высоким приоритетом обладает политика с более близкой к пользователю областью действия. Допустим, в сайте существует учетная запись агента восстановления RECOV1, а в домене и подразделении, к которым присоединяется компьютер, политики не оп ределены. Х Б этом случае при входе в сеть и присоединении к домену применяется полиги ка RECOV1, а затем Ч лотсутствующие, нулевые политики домена и подразде ления. В этом случае никаких конфликтных ситуаций не возникает, и RECOV автоматически становится текущей учетной записью агента восстановления па компьютере. Х Теперь предположим, что в домене агентом восстановления назначена учетная запись RECOV2. Она обладает более высоким приоритетом, чем RECOV1, и именно она станет учетной записью агента восстановления. Х Допустим, что в подразделении не нулевая, а пустая политика. Ее приоритет самый высокий, и поэтому использование EFS станет невозможным из-за за прета, налагаемого пустой политикой. Х Предположим, что учетная запись агента восстановления для изолированного компьютера Ч LOCRECOV. Она игнорируется, так как при подключении к доме ну в силу вступит политика подразделения. Если прекратить членство компьюте ра в домене, удалив его учетную запись с контроллера домена, LOCRECOV снова станет агентом восстановления, При настройке групповой политики доступны следующие возможности: Х блокирование наследования политики. В этом случае полразделения, расположен ные ниже по иерархии, не наследуют политику от родительского сайта, домена или подразделения; Х принудительное наследование политики. В атом случае подразделения, располо женные ниже по иерархии, не переопределяют политику вышестоящего сайта, домена и подразделений. ЧАСТЬ 2 Безопасность в распределенных системах Подробнее о групповой политике Ч в справочной системе групповой политики и в гла ве 22 книги Распределенные системы. Книга 2. Ресурсы Microsoft Windows 2000 (Русская Редакция, 2001). Вы вправе сопоставлять отдельным сайтам, доменам и подразделением несколько объектов групповой политики и определять приоритеты применения этих полити ки к соответствующим объектам службы каталогов Active Directory. Обратное так же верно: несколько сайтов, доменов и подразделений могут совместно использо вать один объект 1рупповой политики. Любой сайт, домен или подразделение раз решается сопоставлять любому объекту групповой политики, даже если они отно сятся к разным доменам одного леса. Администратор имеет возможность заблокировать наследование групповой поли тики для отдельных компьютеров Ч членов домена. При этом с точки зрения груп повой политики такие компьютеры будут работать как изолированные. Служба каталогов Active Directory поддерживает самые разнообразные сценарии применения групповых политик. Компьютер может относиться к нескольким вло женным подразделениям и подчиняться требованиям нескольких объектов группо вой политики. Поскольку данные каталогов хранятся на всех контроллерах домена, в крупных организациях групповая политика применяется к тысячам пользователей. Хранение В EFS информация агента восстановления в политике восстановления хранится в службе каталогов Active Directory как контейнер объекта групповой политики. Эта политика распространяется на все компьютеры в. ее области действия. На изолиро ванных компьютерах информация политики восстановления EFS хранится в кон тейнере Local Computer policy (Политика Локальный компьютер). Это означает, что управлять ключами восстановления в домене имеют право только администра торы домена, а на изолированных компьютерах Ч только локальные администра торы. Служба EFS инициализируется во время запуска системы как часть подсистемы LSA (Local Security Authority Ч Администратор локальной безопасности). LSA от вечает за размещение информации политики EFS в памяти как при работе в доме не, так и в изолированном режиме. Для изолированных компьютеров данные политики восстановления EFS хранятся в локальном реестре. Соответствующий раздел создастся службой EFS и разреше ние Full Control (Полный доступ) на него предоставлено только системе. Это час тично гарантирует, что никто, кроме локальных администраторов, не получит до ступа к этой информации. Кроме того, во избежание случайного повреждения дан ных даже администраторам прямой доступ не предоставляется. В этом же разделе реестра кэшируются данные доменной политики восстановления EFS, использую щиеся при неполадках сети. Примечание При создании политики восстановления EFS, как впрочем и любого другого объекта групповой политики, рекомендуется создавать записи о дате созда ния и назначении объектов, так как групповая политика автоматически не архиви руется. Шифрованная файловая система ГЛАВА 15 Сертификаты Для работы EFS необходимо наличие у пользователя действительного сертифика та пользователя EFS. а в текущей политике восстановления Ч по крайней мере од ного действительного сертификата агента восстановления. Если это возможно, EFS запрашивает сертификаты в центре сертификации предприятия Windows 2000, но шифрованная файловая система может обойтись и без ЦС. Если ЦС предприятия недоступен, EFS самостоятельно создает сертификаты для пользователей и аген тов восстановления по умолчанию. Примечание Создаваемые сертификаты заверяет сама EFS, а не центр сертифика ции. В Windows 2000 сертификаты, подписанные EFS, считаются не заслуживаю щими доверия, потому что сертификат соответствующего ЦС не расположен в хра нилище Trusted Root Certification Authorities (Доверенные корневые центры сер тификации). Тем не менее они вполне пригодны для использования в EFS. Под робнее о пути сертификации Ч в главе 16 Службы сертификации и инфраструк тура открытого ключа в Windows 2000. Подробнее о сертификатах Ч в главе М Криптография в сетевых информационных системах. Подробнее о службах сертификации Microsoft Windows 2000 и ЦС Ч в гла се 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000. Сертификаты пользователей Сертификаты с идентификатором объекта 1.3.6.1.4.1.311.10.3.4 в поле Enhanced Key Usage (Улучшенный ключ) сертификата пригодны для операций пользователя EFS. При наличии доступного ЦС предприятия EFS автоматически запрашивает серти фикат EFS для пользователей при первой операции шифровании файла или пап 'ки. При одобрении запроса выпущенный сертификат размещается в хранилище сер тификатов Personal (Личные) пользователя. Когда же доступных ЦС нет, EFS са мостоятельно создает сертификат и размещает его в указанном хранилище. Для нормальной работы EFS необходимо наличие у пользователя действительного сер тификата EFS в хранилище Personal. В случае окончания срока действия сертифи ката EFS при первом обращении к файлу файловая система EFS создает новую пару ключей и выпускает новый сертификат. Для выпуска и управления сертификатами пользователей EFS можно развернуть центр сертификации. ЦС предприятия выпускает сертификаты на базе шаблонов, которые хранятся в службе каталогов Active Directory. В этих шаблонах определе ны атрибуты типов сертификатов, выпускаемых ЦС для пользователей и компью теров. Среди всех шаблонов сертификатов только следующие три поддерживают работу пользователя с EFS: Х User (Пользователь); Х Administrator (Администратор); Х Basic EFS (Базовое шифрование EFS). При налимий у пользователя действительного сертификата одного из указанных типов EFS использует его для файловых операций. Кроме EFS, сертификаты Administrator и User поддерживают также ряд других назначений, а сертификат Basic EFS применяется исключительно для операций EFS. Безопасность в распределенных системах 672 ЧАСТЬ Принимая решение о судьбе запроса па сертификат, ЦС предприятия учитывает ин формацию списков ACL для шаблона затребованного сертификата. По умолчанию члены групп Domain Admins (Администраторы домена) и Domain Users (Пользова тели домена)-обладают разрешением Enroll (Заявка) для сертификатов базового шифрования EFS и сертификатов пользователей. По умолчанию члены групп Domain Admins (Администраторы домена) и Enterprise Admins (Администраторы предприя тия) обладают разрешением Enroll (Заявка) для сертификатов Administrator. Подробнее о шаблонах сертификатов в главе 16 Службы сертификации и инф раструктура открытого ключа в Windows 2000. Сертификаты агентов восстановления Сертификаты с идентификатором объекта 1.3.6.1.4.1.311.10.3.4.1 в ноле сертифика та Enhanced Key Usage (Улучшенный ключ) пригодны для операций агента вос становления EPS. EFS автоматически создает сертификаты для агентов восстанов ления по умолчанию Ч учетной записи Administrator (Администратор) первого ус тановленного в домене контроллера или локальной учетной записи Administrator на изолированном компьютере. Сертификаты агента восстановления размещаются в хранилище сертификатов Personal учетной записи администратора. Для восста новления данных необходимо наличие действительного сертификата агента восста новления и закрытого ключа на компьютере, где выполняется восстановление. По литика восстановления EFS работает только при условии, что все сертификаты вос становления действительны. Дополнительно назначенные агенты восстановления (кроме заданных по умолча нию) должны обладать действ! [тельными сертификатами агентов восстановления EFS. Для выпуска и управления сертификатами агентов восстановления EFS обыч но развертывают центр сертификации. В Windows 2000 Т 1C предприятия содержит шаблоны сертификатов агентов восста новления EFS. Сертификаты агента восстановления EFS пригодны только для опе раций агента восстановления. По умолчанию члены групп Domain Admins (Адми нистраторы домена) и Enterprise Admins (Администраторы предприятия) облада ют разрешением F,nroll (Заявка) для сертификатов агента восстановления EFS. При необходимости перечень учетных записей, допущенных к получению таких серти фикатов, изменяют, откорректировав список управления доступом по умолчанию для шаблона сертификата. Подробнее об изменении списков ACL шаблонов серти фикатов Ч в главе 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000*. Изолированные ЦС не поддерживают шаблоны сертификатов, но, тем не менее, также способны выпускать сертификаты EFS. Для запроса сертификатов в изоли рованном ЦС следует использовать Web-страницу Advanced Certificate Request (Расширенные запросы на сертификаты) из набора страниц; подачи заявок на сер тификаты через Интернет. Подробнее о запросе сертификатов EFS в изолирован ном ЦС Ч в главе 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000. Шифрованная файловая система ГЛАВА 15 Административные процедуры Обычно выполняются следующие административные процедуры для развертыва ния и обеспечения безопасности EPS в организации: Х обеспечение безопасности ключа восстановления но умолчанию; Х назначение дополнительных учетных записей агентов восстановления; Х конфигурирование политики агентов восстановления; Х просмотр информации агента восстановления; Х восстановление шифрованных файлов или папок; Х запрещение использования EFS на отдельных компьютерах; Х запрещение использования EFS на определенных папках. Защита ключа восстановления Как мы уже говорили, рекомендуется удалять закрытые ключи агентов восстанов ления с компьютеров, экспортируя их на съемные носители и помещая последние в надежное хранилище. Эту операцию следует выполнять по отношению к ключам восстановления по умолчанию до каких-либо изменений в политике восстановления. Такие операции выполняются средствами Certificate Export wizard (Мастер экспорта сертификата), который доступен в оснастке Certificates (Сертификаты). Подробнее об использовании оснастки Certificates и мастера экспорта сертификатов в главе Службы сертификации и инфраструктура открытого ключа в Windows 2000*. Чтобы защитить ключ восстановления на изолированном компьютере, следует вой ти в систему под учетной записью Administrator (Администратор). Сертификат агента восстановления EFS расположен в хранилище сертификатов Personal (Лич ные) этой учетной записи. Чтобы защитить ключ восстановления для домена, войдите в систему под учетной записью Administrator первого созданного в домене контроллера. Сертификат аген та восстановления KFS расположен в хранилище сертификатов Personal (Личные) этой учетной записи. Средствами мастера экспорта сертификатов выполните экспорт сертификата и за крытого ключа на съемный носитель информации. Подробнее об экспорте серти фикатов и соответствующего закрытого ключа - в справочной системе оснастки Certificates (Сертификаты) и в главе 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000. Чтобы удалить закрытый ключ с компьютера, следует установить флажок Delete the private key if the export is successful (Удалить закрытый ключ после успешно го экспорта) на странице Export File Format (Формат экспортируемого файла) ма стера Certificate Export. В этом случае мастер удалит закрытый ключ с компьютера и разместит его вместе с сертификатом агента восстановления в файле с расшире нием.pfx в указанной папке или па диске. Теперь следует обеспечить безопасность PFX-файла, поместив его в падежное хранилище. ^ Обеспечение безопасности PFX-файла 1. Если PFX-файл создан на дискете, он уже находится там, где нужно, Ч на носи теле, который можно физически удалить из компьютера и поместить ti падеж ЧАСТЬ 2 Безопасность в распределенных системах ное место. В противном случае скопируйте файл на дискету и удалите его с же сткого диска компьютера. 2. Извлеките дискету и создайте резервную копию PFX-файла на другой дискете. Поместите дискеты в сейф или в другое безопасное место. Одну из них следует хранить в безопасном месте за пределами организации. Если необходимо восстановить файлы, воспользуйтесь оснасткой Certificates для импорта PFX-файла на требующий мероприятий по восстановлению компьютер и восстановите нужные файлы. По завершении этой операции закрытый ключ следу ет снова переместить в безопасное место. Альтернативный способ обеспечения защиты закрытого ключа - использование только физически защищенных изолированных компьютеров, специально предназ наченных для операций восстановления. В этом случае закрытый ключ хранится на компьютере. На таком компьютере вход в систему выполняется под учетной за писью агента восстановления, и компьютер следует использовать только для опе раций восстановления, Тем не менее важно создать архивную копию сертификата и закрытого ключа, чтобы в случае необходимости восстановить их на этом компь ютере. Для создания архивной копии сертификата и закрытого ключа агента вос становления можно воспользоваться мастером экспорта сертификатов, при этом обязательно проследите, чтобы флажок Delete the private key if the export is successful (Удалить закрытый ключ после успешного экспорта) был сброшен. Ком пьютер без закрытого ключа непригоден для выполнения операций восстановления. Сертификат и закрытый ключ агента восстановления также разрешается хранить на смарт-карте. Для этого необходимо сопоставить сертификат смарт-карты учет ной записи агента восстановления средствами оснастки Active Directory Users and Computers (Active Directory - пользователи и компьютеры). В этом случае появ ляется возможность выполнять операции восстановления на любом компьютере домена под управлением Windows 2000, оборудованном устройством для чтения смарт-карт. Рекомендуется создать защищенную резервную копию сертификата и закрытого ключа агента восстановления на случай повреждения или неправильной работы смарт-карты. При наличии такой архивной копии допускается восстанав ливать файлы, как обычно: импортировать сертификат и ключ на компьютер и ис пользовать их для операций восстановления. Подробнее о хранении сертификатов на смарт-картах в главе 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000s> и в главе 13 Обеспечение безопасности средствами техно логии открытого ключа. Подробнее о сопоставлении сертификатов Ч в главе Службы сертификации и инфраструктура открытого ключа в Windows 2000. Назначение агентов восстановления Не следует управлять восстановлением EFS на уровне целого домена - рекомен дуется назначить специально выделенные компьютеры для управления восстанов лением в отдельных подмножествах компьютеров домена или даже на отдельных компьютерах. Администраторы домена выполняют эту операцию средствами осна стки Active Directory Users and Computers (Active Directory Х пользователи и ком пьютеры), сгруппировав компьютеры в подразделения, а затем создавая отдельные политики восстановления EFS для каждого подразделения. Допускается назначать несколько администраторов применять одну учетную запись агента восстановления для расшифровки файлов пользователей в этом подразделении. ГЛАВА 15 Шифрованная файловая система Хотя политику восстановления можно настроить в подразделениях, ее необходимо определить на уровне домена. Администраторы подразделений обладают правом просматривать политику агентов восстановления, но им не разрешено переопреде лять ее. Для выполнения этой задачи средствами оснастки Group Policy (Групповая поли тика) следует установить ее, открыть нужный объект (домен, подразделение или изолированный компьютер), а затем следовать описанным далее инструкциям, ^ Использование групповой политики для делегирования восстановления Последовательно раскройте узлы Group Policy (Групповая политика), Computer 1. Configuration (Конфигурация компьютера), Windows Settings (Конфигурация Windows), Security Settings (Параметры безопасности), Public Key Policies (По литики открытого ключа). В области сведений щелкните правой кнопкой мыши Encrypted Data Recovery 2. Agents (Агенты восстановления шифрованных данных) и в контекстном меню выберите команду Add (Добавить). Откроется окно мастера Add Recovery Agent Wizard (Мастер добавления агента восстановления). На рис. 15-13 показана первая страница мастера Add Recovery Agent Wizard. Welcome to the Add Recovery Agent Wizard This wizard helps you designate selected user? as recover> agents for Fifes that have been encrypted by other users Recovery agents can decrypt Files using their certificates keys n Group Policy Editor. UOLI can specify the scope (domain or organizational unit] of a ^eccveiy agent. To continue, click Net*. Рис. 15-13. Первая страница мастера Add Recovery Agent Wizard 3. Щелкните кнопку Next (Далее). 4. На второй странице добавьте сертификаты агентов восстановления. Если сер тификаты восстановления выпущены службой каталогов Active Directory, щел кните кнопку Browse Directory (Обзор каталога). В противном случае Ч кноп ку Browse Folders (Обзор папок). :5. При необходимости повторите пункт 4, чтобы добавить дополнительные серти фикаты агентов восстановления. На рис. 15-14 показан примерный вид второй страницы после выбора сертифи ката агента восстановления. Безопасность в распределенных системах 676 ЧАСТЬ Select Recovery Agents Only users who have recoyerji agenl certificates can be designated as recoveiy agents -у Рис. 15-14. Вторая страница мастера Add Recovery Agent Wizard Разрешается добавлять сертификаты агентов восстановления, опубликованные в Active Directory. Информация о сопоставленном выпущенными сертифика тами пользователе с учетной записью агента восстановления отобразится в стол бце Users (Пользователи). Также разрешается добавлять сертификаты агентов восстановления из файла. В этом случае в столбце Users (Пользователи) отображается запись USER_UNKNOWN, так как при добавлении сертификата из файла отсутствует информация о SID-идентификаторе владельца закрытого ключа. Примечание Мастер Add Recovery Agent wizard (Мастер добавления агента вос становления) воспринимает в качестве файлов сертификатов только файлы с расширением.сег. Импорт сертификатов на изолированный компьютер выпол няется средствами мастера Certificate Request wizard (Мастер запроса сертифи ката). Подробнее Ч в справочной системе оснастки Certificates. 6. Добавив все запланированные сертификаты агентов восстановления, щелкните кнопку Next, а затем Ч кнопку Finish (Готово). Конфигурирование политики агента восстановления Рекомендуется выпустить сертификаты восстановления EFS для агентов восстанов ления, отличных от заданной по умолчанию учетной записи Administrator (Адми нистратор). Это необходимо для более гибкого управления восстановлением EFS. Кроме того, в официальной или корпоративной политике можно явно потребовать, чтобы агентом восстановления не была стандартная учетная запись Administrator (Администратора). Также Вы вправе настроить политику восстановления EFS на переносных компьютерах па использование одних и тех же сертификатов агента восстановления, независимо от того подключены ли компьютеры к домену или ис пользуются как изолированные системы. ГЛАВА 15 Шифрованная файловая система Подробнее о конфигурировании локальной политики агентов восстановления на изолированном компьютере или на локальном уровне компьютера и домене -- в справочной системе Windows 2000 Professional или Windows 2000 Server. Подроб нее о конфигурировании политики агентов восстановления на уровне контроллера ломена в справочной системе Windows 2000 Server. Сертификаты агента восстановления EFS разрешается запрашивать как в ЦС пр''л приятия, так и в изолированном ЦС. На ЦС предприятия для этого необходимо войти в систему под учетной записью члена группы Domain Admins (Администра торы домена). Существует два способа запроса сертификата в ЦС предприятия; средствами мастера Certificate Request wizard (Мастер запроса сертификата) или через Web-страницы для подачи заявок на сертификаты через Интернет. Последний вариант также применим для запроса сертификатов в изолированном ЦС. Запросы на сертификаты, направленные в изолированные ЦС, остаются в очереди отложен ных сертификатов до принятия решения о выпуске или отказе администратором этого ЦС. Подробнее о запросе сертификатов - в главе 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000. После размещения сертификата агента восстановления в хранилище сертификатов Personal (Личное) соответствующей учетной записи разрешается экспортировать сертификат и связанный закрытый ключ (как описано ранее в этой главе), а затем их импортировать в учетные записи назначенных агентов восстановления. Вы также вправе добавлять сертификаты в соответствующие политики восстановления EFS. Просмотр информации агента восстановления В Windows 2000 Resource Kit есть программа efsinfo.exe, позволяющая просматри вать информацию о файлах EPS, в том числе сведения об учетной записи пользо вателя EFS и учетных записях агентов восстановления, Чтобы просмотреть информацию пользователя зашифровавшего файл, введите в командной строке команду: efsinfo /и <имя файла> Программа предоставит сведения об имени и адресе электронной почты зашифро вавшего файл пользователя. Чтобы просмотреть информацию агента восстановления для шифрованного файла, введите в командной строке: efsinfo / г <имя файла> Программа предоставит сведения об именах и адресах электронной почты агентов восстановления данного файла. Отображаемая efsinfo.exe информация извлекается из сертификатов пользователя EFS и агента восстановления. При выпуске сертификатов ЦС предприятия полу чает сведения о пользователе из его учетной записи в службе каталогов Active Directory. При использовании изолированного ЦС идентификационная информа ция пользователя в Active Directory недоступна (даже если она там есть), поэтому при выполнении процедуры запроса сертификата имя пользователя и адрес элект ронной почты необходимо ввести на Web-странице Advanced Certificate Request (Расширенные запросы на сертификаты), Безопасность в распределенных системах 678 ЧАСТЬ Служебная программа efsinfo.exe также используется для получения сведений о том, кто шифровал файл или какая учетная запись агента восстановления уполно мочена для восстановления этого файла. Это особенно важно для забытых фай лов, которые не открывались очень давно, и из-за этого их информация пользова теля и агента восстановления устарела. Подробнее об использовании efsinfo.exe Ч в справочной системе Windows Resource Kit. Восстановление шифрованных файлов или лапок Восстановления шифрованного файла или папки при утере пользователем своего закрытого ключа выполняется в определенной последовательности. 1. Средствами протокола для безопасного обмена почтой через Интернет, напри мер Secure/Multipurpose Internet Mail Extensions (S/M1ME), пользователь пе ресылает файл или папку администратору восстановления. Существует другой способ: создать резервную копию средствами программы Windows 2000 Backup (Средства архивации и восстановления Windows 2000) и переслать ее как обыч ное почтовое вложение. 2. Агент восстановления расшифровывает файл или нанку средствами служебной программы командной строки cipher. (В этом случае сертификат и закрытый ключ агента восстановления должны находиться на компьютере восстановления, и администратор должен войти в систему под учетной записью агента восста новления.) 3. Администратор создает незашифрованную копию файла и пересылает ее обрат но пользователю по протоколу безопасного обмена почтой через Интернет, па пример S/MIME. Если ранее выполнены процедуры, описанные в разделе Защита ключа восста новления, сертификат агента восстановления и открытый ключ в сети отсутству ют и надежно сохранены в PFX-файле. Чтобы воспользоваться сертификатом на компьютере восстановления, следует импортировать его в хранилище сертифика тов Personal (Личное) учетной записи агента восстановления. Подробнее об им портировании сертификатов Ч в справочной системе оснастки Certificates (Сер тификаты). По окончании процедур восстановления следует удалить сертификат восстановле ния файла с жесткого диска. Снова выполнять экспорт не надо, так как копия сер тификата есть па сменном носителе. Отметим, что пока выполняются мероприятия по восстановлению информации, закрытый ключ располагается на компьютере для восстановления. Конечно, агент восстановления мог бы перенести свой накрытый ключ на компьютер пользовате ля, но это неправильно с точки зрения безопасности. Никогда не следует копиро вать закрытый ключ на другой компьютер. Запрещение использования EFS на отдельных компьютерах Для нормальной работы EFS на компьютере должен быть по крайней мере один действительный сертификат агента восстановления. В EFS не разрешается шифро вание данных, если в политике нет ни одного сертификата агента восстановления. Поэтому существует два способа запретить использование EFS: полностью удалить Шифрованная файловая система ГЛАВА 15 (обнулить) политику восстановления либо задать пустую политик}' восстановле ния (политика существует, но сертификаты агентов восстановления отсутствуют). При этом система следует следующим правилам: Х и отсутствие политики, и пустая политика запрещают использование EFS на изолированном компьютере; Х ни отсутствие политики, ни пустая политика не в состоянии отменить исполь зование EFS на локальном компьютере Ч члене домена, если политика опреде лена па более высоком уровне, например на уровне домена или подразделения; Х отсутствие политики на более высоком уровне отключает поддержку EFS толь ко на этом уровне - - на компьютерах более низкого уровня используются соб ственные локальные политики; Х определение пустой политики на более высоком уровне отменяет поддержку EFS как на этом уровне, так и на всех подчиненных уровнях. >Х Удаление (обнуление) политики восстановления 1. На изолированном компьютере запустите ММС и добавьте оснастку Group Policy (Групповая политика) для локального компьютера. 2. В оснастке Group Policy (Групповая политика) щелкните правой кнопкой мыши папку Encrypted Data Recovery Agents (Агенты восстановления шиф рованных данных) и в контекстном меню выберите команду Delete Policy (Удалить политику). 3. Подтвердите удаление политики, щелкнув в открывшемся диалоговом окне с предупреждением кнопку Yes (Да). Наилучший способ отключить EFS на всех компьютерах в домене или подразделе нии - определить пустую политику восстановления. Запрет будет работать, пото му что действующая политика представляет собой совокупность политик, опреде ленных на различных уровнях в дереве каталогов объектов групповой политики. При отсутствии политики восстановления на уровне домена или подразделения используется политика более низкого уровня. Но пустая политика восстановления, определенная на более высоких уровнях, запретит использование EFS, не предос тавляя действительных сертификатов восстановления и блокируя использование политики низшего уровня на компьютерах этого уровня и ниже. ^ Определение пустой политики на уровне подразделения или домена 1. Войдите в систему под учетной записью Administrator (Администратор) перво го созданного в домене контроллера, выделите палку Encrypted Data Recovery Agents (Агенты восстановления шифрованных данных) и отобразите список сертификатов в области сведений окна. 2. Щелкните правой кнопкой мыши сертификат Administrator (Администратор) и в контекстном мелю выберите команду Delete (Удалить). Выполните эти дей ствия для всех сертификатов, перечисленных в области сведений окна. 3. Ответьте Yes (Да) на вопрос Permanently delete the selected certificate? (Окон чательно удалить выбранный сертификат?). Безопасность в распределенных системах 680 ЧАСТЬ ^ Возобновление действия EFS на локальном компьютере 1, Для возобновления действия политики восстановления щелкните правой кноп кой мыши папку Encrypted Data Recovery Agents (Агенты восстановления шифрованных данных) и в контекстном меню выберите команду Initialize Empty Policy (Инициализировать пустую политику). 2. После создания пустой политики следует вновь разрешить использование EFS, щелкнув правой кнопкой мыши панку Encrypted Data Recovery Agents (Аген ты восстановления шифрованных данных) и в контекстном меню выбрав коман ду Add (Добавить). Откроется окно мастера Add Recovery Agent wizard (Мас тер добавления агента восстановления). Этот мастер воспринимает в качестве файлов сертификатов только файлы с расширением.сег. ^ Возобновление разрешения использования EFS в домене или подразделении Х Добавьте один или несколько действительных сертификатов агентов восстанов ления в политику восстановления. EFS, следуя процедуре описанной в разделе Назначение агентов восстановления ранее в этой главе. Запрещение использования EFS для определенных папок Существует возможность запретить использовать EFS для отдельной папки. Для этого установите атрибут System (Системный) средствами Windows Explorer (Про водник Windows). Так как в EFS запрещено шифрование таких папок для предотв ращения шифрования необходимых для загрузки системы файлов, система не раз решит зашифровать папку. Однако ее гь папки, не поддерживающие установку сис темного атрибута. Например, содержащая файлы Ntuser.dat папка Profiles. ^ Запрещение использования EFS для папок, не поддерживающих системный атрибут Х Используйте API-функцию Winadvapi, которая имеет следующий прототип: WINADVAPI BOOLEncryption()isable{ IN LPCWSTR DirPath, IN BOOL Disable ) /*++ Эта функция запрещает или разрешает использование EFS в каталоге DirPath. Аргументы: DirPath - Путь к каталогу. Disable - TRUE для запрещения (FALSE для разрешения) Возвращаемое значение: TRUE - при успешной завершении -*/ Прототип этой функции имеется в заголовочном файле Winefs.h. Она запрещает или разрешает использование EFS в указанной папке. При этом создается файл Desktop.ini с такими строками: Encryption] Disable=1; (или Disable=0) Если Desktop.ini уже существует, то функция добавляет эти строки в конец файла. Этого же результата (отключения KFS) Вы добьетесь, если добавите в файл эти строки вручную. ГЛАВА 15 Шифрованная файловая система Использование системного ключа Для обеспечения дополнительной защиты основных ключей и другой секретной информации используется System Key (системный ключ). Системный ключ защи щает следующую конфиденциальную информацию: Х основные ключи, применяемые для защиты закрытых ключей; Х ключи защиты паролей пользовательских учетных записей, хранящихся в служ бе каталогов Active Directory; Х ключи защиты паролей, размещенных в реестре в разделе диспетчера учетных записей безопасности SAM (Security Accounts Manager); Х ключи защиты секретных данных LSA; Х ключ защиты пароля учетной записи администратора, который используется при запуске системы в безопасном режиме. На всех компьютерах домена использование секретного ключа разрешено по умол чанию, и все основные ключи и ключи защиты, хранящиеся на компьютерах, за шифрованы уникальным случайным симметричным 128-битным системным клю чом. Системный ключ должен размещаться в оперативной памяти и оставаться до ступным операционной системе в процессе запуска, так как он используется для расшифровки ключа защиты пароля. Существует три способа поддержки систем ного ключа. Х Б качестве системного выбирается создаваемый компьютером случайный ключ. Он хранится в локальной системе и защищается сложным алгоритмом сокры тия, который распределяет системный ключ по всему системному реестру. В этом случае при перс-загрузке компьютера вводить системный ключ не требует ся. Это стандартный вариант (по умолчанию) конфигурации системы. Х Случайный ключ создается компьютером, но хранится на дискете. В этом слу чае на локальном компьютере нет системного ключа, и для успешного запуска системы необходима дискета. Обращение к ней осуществляется после появле ния на экране предложения вставить дискету в дисковод в начале загрузки Win dows 2000, но до приглашения на вход в систему. Х Системный ключ создается на основе выбранного администратором пароля. Сам пароль на компьютере не хранится. Windows 2000 запрашивает у администра тора пароль на стадии начального запуска, до приглашения на вход в систему, Параметры конфигурации системного ключа устанавливаются в диалоговых окнах служебной программы SysKey. В домене для запуска SysKey необходимы права чле на группы Domain Admins (Администраторы домена), а па изолированных компь ютерах Ч права локальной учетной записи Administrator (Администратор). Разре шается индивидуально конфигурировать поддержку системного ключа для разных компьютеров домена, По умолчанию защита системным ключом применяется во всех доменах, но иногда возникает необходимость изменить стандартную конфигурацию применения сис темного ключа для некоторых компьютеров домена. Также иногда требуется разре шить защиту системным ключом на изолированных компьютерах. Безопасность в распределенных системах 682 ЧАСТЬ ^ Настройка обеспечения безопасности посредством системного ключа 1. В командной строке введите: syskey Откроется диалоговое окно Securing the Windows NT Account Database (Защита БД учетных записей Windows NT) (Рис. 15-15). Рис. 15-15. Диалоговое окно Securing the Windows NT Account Database Заданную системным ключом защиту отменить невозможно. 2. Установите переключатель в положение Encryption Enabled (Шифрование вклю чено) (если это уже не сделано) и затем щелкните ОК. После напоминания о необходимости создания аварийною диска восстановления откроется окно Account Database Key (Ключ базы данных учетных записей), используемое для изменения параметров конфигурации ключа (рис. 15-16). По умолчанию систе ма самостоятельно создает системный ключ и храпит его локально, Рис. 15-16. Диалоговое окно Account Database Key 3. Выберите необходимые параметры системного ключа и щелкните кнопку ОК. 4. Перезагрузите компьютер. В зависимости от сделанного выбора при перезагрузке системы иногда требуется ввести системный ключ. Windows 2000 автоматически обнаруживает первое исполь зование системного ключа и генерирует новый случайный ключ шифрования па Шифрованная файловая система ГЛАВА 15 родя. Ключ шифрования пароля защищается системным ключом. В итоге вся ин формация о паролях учетных записей надежно шифруется. При последующих запусках системы выполняются операции: 1. в зависимости от варианта получения ключа Windows 2000 либо извлекает сис темный ключ с локального жесткого диска, либо вычисляет его на основе паро ля, либо считывает с дискеты; 2. системный ключ применятся для расшифровки основного ключа системы безо пасности; 3. Windows 2000 использует основной ключ системы безопасности для получения ключей шифрования паролей учетных записей пользователей, который в свою очередь используется для расшифровки информации пароля, хранимой в Active Directory или в разделе SAM реестра локального компьютера. Служебная программа syskey применяется также для изменения выбранного места хранения системного ключа или смены пароля. ^ Выбор нового места хранения системного ключа и смена пароля 1. Введите в командной строке команду syskey. Откроется начальное диалоговое окно настройки системного ключа (Рис. 15-15). 2. Щелкните кнопку Update (Обновить). 3. В диалоговом окне Account Database Key (Ключ базы данных учетных запи сей) (Рис. 15-16) установите переключатель в нужное положение и при необхо димости измените пароль. Щелкните кнопку ОК. 4. Перезагрузите компьютер. Чтобы изменить системный ключ, необходимо знать текущий системный ключ. При использовании пароля для получения системного ключа программа SysKey не на лагает ограничений на минимальную длину пароля, тем не менее не рекомендуется задавать пароли короче 12 символов. Максимальная длина пароля - 128 символов. Внимание! При утере пароля системного ключа или дискеты с системным ключом запуск системы станет невозможным. Системный ключ следует хранить в безопас ном месте. Если он расположен на дискете, сделайте резервные копии и храпите их в разных местах. Единственный способ восстановить систему при утере системно го ключа Ч использовать диск аварийного восстановления для возвращения реест ра в состояние, предшествующее разрешению защиты с помощью системного клю ча. Это приведет к утере всей накопленной с тех пор информации и изменений. Допускается индивидуальная настройка компьютеров домена для защиты систем ным ключом. При конфигурировании параметров системного ключа каждый ком пьютер получает уникальный ключ шифрования пароля и системный ключ. Напри мер, основной контроллер домена можно сконфигурировать на использование ав томатически создаваемого системного ключа, копия которого хранится на дискете, а дополнительные контроллеры домена на использование создаваемых компью тером и хранимых локально системных ключей. Создаваемый компьютером систем ный ключ, который хранится локально на основном контроллере домена, не репли цируется. Безопасность в распределенных системах 684 ЧАСТЬ Прежде чем приступить к конфигурированию защиты системным ключом на един ственном контроллере в домене, рекомендуется обеспечить наличие второго, стра ховочного контроллера домена, который в случае сбоя применяется для восста новления первого контроллера. Следует обеспечить наличие полной и обновлен ной базы данных каталога на таком резервном контроллере. Кроме того, перед из менением параметров системного ключа рекомендуется создать новый диск аварий ного восстановления для этого компьютера. Подробнее о создании диска аварий ного восстановления - в справочной системе Microsoft Windows 2000 Server или Microsoft Windows 2000 Professional, Печать файлов в EPS Вывод данных на принтер и другие устройства вывода в EFS выполняется так же, как их отображение на мониторе. Если зашифрованный файл отображается откры тым текстом на экране, в таком же виде он будет напечатан. И наоборот, если его нельзя прочитать на экране, то и печать его недоступна. Таким образом для соблюдения конфиденциальности информации требуется обес печить такую же физическую безопасность принтера, как и самого компьютера. Как сам принтер, так и физическое соединение с ним следует защитить, чтобы атакую щий не смог перехватить передаваемую информацию. Если используется сервер печати, его тоже обязательно следует защитить. При печати Windows 2000 размещает задание в буферном файле (с расширением.spl), расположенном в локальной службе печати. При локальной печати эта служ ба выполняется на локальном компьютере. При печати в архитектуре -^клиент сервер буферный файл располагается на сервере печати. По умолчанию SPL-файлы хранятся в папке %$ystemRoot% \System32\Spool\ Printers. Если эта папка незашифрованна (как это обычно бывает), печатаемый файл хранится в ней открытым текстом. Можно зашифровать папку, но это сильно замедлит работу, так как потребуются дополнительные вычислительные ресурсы на операции шифрования всех буферных файлов. Более корректный способ Ч создать специальный логический принтер и выделить его для шифрованных файлов, кото рый использует тот же физический принтер, но с другими параметрами печати. Та кой принтер должен быть локальным, с закрытым доступом из сети и должен обхо дить заданную по умолчанию папку. Для этого применяют один из двух методов. На вкладке Advanced (Дополнительно) диалогового окна Properties (Свойства) Х принтера установите переключатель в положение Print directly to the printer [Печатать прямо на принтер (ускорение вывода на печать)]. В этом случае зада ние на печать не будет размещаться и очереди, и не создается буферный файл. Примечание Не размещаемые в очереди на печать задания нельзя планировать или распределять по приоритетам. Х Создайте зашифрованную папку и сконфигурируйте ее для хранения буферных файлов. Подробнее о хранении буферных файлов Ч в книге Сопровождение сервера. Ресурсы Microsoft Windows 2000 Server (Русская Редакция, 2001). По умолчанию после выполнения задания на печать буферный файл удаляется. Поведение по умолчанию изменится, если установить флажок Keep printed Шифрованная файловая система ГЛАВА 15 documents (Сохранять документы после печати) на вкладке Advanced (Дополни тельно). В этом случае можно повторно посылать документ на принтер из очереди на печать, а не из приложения. Такой способ не рекомендуется, так как получен ные при этом выгоды не перевешивают риск утечки информации. Даже если бу ферные файлы зашифрованы, из соображений безопасности неправильно хранить копии конфиденциальных данных в нескольких папках. Устранение неполадок при использовании EFS В этом разделе мы рассмотрим типичные неполадки, возникающие при использо вании EFS, и предложим некоторые способы их устранения. Безуспешная попытка зашифровать файлы Убедитесь, что соблюдены следующие условия: Х определена политика агента восстановления; Х файлы размещены на томе с файловой системой KTFS; Х файл не сжат; Х у Вас есть разрешение Write (Запись) для этого файла. Иногда пользователи думают, что файл не зашифрован, так как они без проблем открывают и читают его. Напомните им: чтобы проверить, зашифрован файл или нет, следует изучить его атрибуты. Иногда пользователи пытаются зашифровать сжатую или расположенную на сжа том диске папку. Перед шифрованием необходимо отменить сжатие, сняв соответ ствующий атрибут. Безуспешная попытка открыть зашифрованный ранее файл Убедитесь, что Ваш сертификат KFS и закрытый ключ для этого файла действи тельны. Если этот файл давно не открывался, его сведения вероятно устарели. Про сроченные сертификаты и закрытые ключи следует извлечь из архивных копий. Не исключено, что пользователь удалил архив с сертификатами и закрытыми ключа ми или повредил их. В этом случае следует выполнить процедуру восстановления файла, как описано ранее в этой главе. Указанная неполадка может возникнуть, если компьютер сначала работал в изоли рованном режиме, а затем был присоединен к домену. Если файл зашифрован ло кальным сертификатом, подписанным шифрованной файловой системой компью тера, в домене он недоступен, так как там используются сертификаты полномочно го ЦС, определенного на уровне домена. Безуспешная попытка открыть зашифрованный средствами EFS файл после обновления Windows 2000 с предыдущей сборки Пользователь получает сообщение об ошибке доступа к этому файлу, но возмож ность шифровать и открывать новые файлы в EFS сохранилась. Вероятно, предыдущая сборка поддерживала стойкое, запрещенное к экспорту шифрование, а новая компоновка Ч международная, с облегченным шифрованно!. Технология шифрования с более коротким ключом не в состоянии обрабатывать файлы, зашифрованные ключом большей длины. 686 ЧАСТЬ 2 Безопасность в распределенных системах Если у Вас есть право развертывать системы с запрещенной к экспорту технологи ей шифрования, получите от Microsoft компакт-диск Encryption Pack и используе те его для внедрения поддержки запрещенных к экспорту криптографических тех нологий. Этот компакт-диск запрещен к экспорту из США. На нем также разме щен поставщик службы криптографии Microsoft Enhanced CSP для Windows 2000. Инструкции по использованию компакт-диска содержатся в расположенных на нем файлах. Подробнее о получении компакт-диска Encryption Pack и о текущей политике экс порта криптографических технологий для продуктов Microsoft Ч на Web-странице Microsoft Security Advisor no адресу Антивирусная программа не может проверить некоторые файлы на жестком диске, сообщая об ошибке доступа Антивирусная программа в состоянии открывать и проверять только файлы, за шифрованные текущим пользователем системы. Файлы, зашифрованные другими пользователями, ей недоступны. Эти пользователи должны самостоятельно войти в систему и проверить наличие вирусов в своих файлах, запустив антивирусную программу. Получает ли пользователь предупреждение о том, что при копировании или перемещении файл передается открытым текстом? Нет. Необходимо всегда проверять свойства полученного в результате- файла, что бы удостовериться в том, что он все еще зашифрован. ГЛАВА Службы сертификации и инфраструктура открытого ключа в Windows Microsoft Windows 2000 содержит службы сертификации, легко управляемые сред ствами оснастки Certification Authority (Центр сертификации), и полную инфра структуру открытого ключа. Понимание механизма работы службы сертификации и инфраструктуры открытого ключа в Windows 2000 необходимо для успешного проектирования, развертывания и поддержки инфраструктуры открытого ключа, отвечающей потребностям в безопасности Вашей организации, В этой главе Преимущества инфраструктуры открытого ключа Основные компоненты инфраструктуры открытого ключа Особенности инфраструктуры открытого ключа Развертывание служб сертификации Текущие задачи служб сертификации Восстановление после сбоя См. также Х Подробнее об основных принципах инфраструктуры открытого ключа и техно логий открытого ключа Ч в глане 14 Криптография п сетевых информацион ных системах*. Х Подробнее о решениях безопасности на базе технологий открытою ключа R главе 13 Обеспечение безопасности средствами технологии открытого клюн; |. Х Подробнее о планировании и развертывании инфраструктуры открытого ключа в книге Microsoft Windows 2000 Server Deployment Planning Guide* (Microsoft Press, 2000). Безопасность в распределенных системах 688 ЧАСТЬ Преимущества инфраструктуры открытого ключа Инфраструктура открытого ключа (Public Key Infrastructure, PKI) R Windows предоставляет каркас, состоящий из служб, технологий, протоколов и стандартов, позволяющий развертывать и управлять системой стойкой информационной безо пасности на базе технологий открытого ключа. PKI позволит удовлетворить боль шинство потребностей Вашей организации в сетевой и информационной безопас ности. Инфраструктура открытого ключа в Windows 2000 содержит службы сертифика ции, ответственные за выпуск и управление цифровыми сертификатами, и интер фейс Microsoft Crypto API версии 2. поддерживающий криптографические опера ции и управление закрытыми ключами. PKI полностью интегрирована со службой каталогов Active Directory в Windows 2000 и со службами распределенной безопас ности. В этой главе мы рассмотрим отдельные компоненты и особенности инфраструктуры открытого ключа в Windows 2000. Подробнее об инфраструктуре и технологиях от крытого ключа - в главе 14 Криптография в сетевых информационных системах. Надежная безопасность на базе технологий открытого ключа Инфраструктура открытого ключа Windows 2000 позволяет создать надежные реше ния безопасности на базе цифровых сертификатов и технологии открытого ключа: Х защищенную почту на основе сертификатов и расширений S/MTME (Secure/ Multipurpose Internet Mail Extensions) протокола MIME, гарантирующих цело стность, подтверждение авторства и конфиденциальность сообщений электрон ной почты; Х защищенные Web-узлы, использующие сертификаты и ссылки на сертификаты для сопоставления сертификатов сетевым учетным записям пользователей и уп равления правами и разрешениями пользователей при доступе к Web-ресурсам; Х безопасную связь через Интернет на основе сертификатов и протоколов SSL (Secure Sockets Layer) и TLS (Transport Layer Security), поддерживающих про верку подлинности серверов и клиентов и обеспечивающих конфиденциальную связь между серверами и клиентами; Х подписание программного кода па основе сертификатов и технологий цифровой подписи (например, Microsoft Autbcnticode) для обеспечения целостности и под тверждения авторства программного обеспечения, распространяемого в интра сетях или через Internet; Х вход в систему но смарт-картам на базе хранимых на них сертификатов и за крытых ключей для проверки подлинности локальных и удаленных пользова телей в сети; Х проверку подлинности клиента средствами протокола Internet Protocol Security (IPSec), позволяющего применить сертификаты для такой проверки; Х шифрованную файловую систему (Encrypting File System, EFS), использующую сертификаты для операций пользователей и агенты восстановления EFS; Х специальные решения безопасности на базе сертификатов, обеспечивающие кон фиденциальность, целостность, подтверждение подлинности или невозможность отрицания авторства. Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 Подробнее о решениях безопасности на базе технологий открытого ключа Ч в ла ве 13 Обеспечение безопасности средствами технологии открытого ключа. Интеграция с Active Directory и службами распределенной безопасности Службы сертификации Windows 2000 составляют ядро инфраструктуры открыто го ключа Windows 2000. Схема интеграции служб сертификации предприятия и распределенной безопасности с Active Directory показана па рис. 16-1. Применение политики безопасности Администратор домена Распространение групповой политики, публикаций сертификатов, сопоставление Active Directory сертификатов учетным записям пользователей и т.п. Центр распространения ключей (КОС) на контроллере домена Службы Процесс сертификации входа в домен Запрос, выпуск, Вход в систему обновление со смарт-картой и отзыв сертификатов Рис. 16-1, Службы сертификации в Windows Службы сертификации в Windows 2000 устанавливаются для создания центров сер тификации (certification authorities, CA), или ЦС, отвечающих за выпуск и управ ление цифровыми сертификатами. В Active Directory хранятся данные, необходи мые ЦС предприятия, Ч имена учетных записей пользователей, группы безопасно сти и шаблоны сертификатов. Active Directory также содержит информацию обо всех ЦС предприятия, установленных в домене. Заявки на сертификаты обычно по даются в ЦС предприятия, которые обрабатывают эти заявки и либо отказывают, либо предоставляют сертификат. Выпущенные сертификаты размещаются в Active Directory и на компьютерах получивших сертификаты. ЦС также публикует в Active Directory списки отозванных сертификатов (certificate revocation list. CRL), Кроме того, Active Directory хранит групповую политику открытого ключа (Public Key Croup Policy), распространяемую на все компьютеры в области действия этой политики. Средствами оснастки Group Policy (Групповая политика) в папке Public Key Group Policy (Политика открытого ключа) определяются доверенные ЦС, на значаются альтернативные агенты восстановления EFS и конфигурируется автома тический выпуск и обновление сертификатов на компьютерах под управлением Windows 2000 Ч все с единого центра управления. Active Directory также поддерживает сопоставление (mapping) сетевых учетных за писей пользователей и сертификатов, используемых для проверки подлинности клиентов и управления доступом к сетевым ресурсам. Применение смарт-карт для входа пользователя в систему является особым случаем такого сопоставления сер Безопасность в распределенных системах 690 ЧАСТЬ тификатов, представляющих собой расширение протокола Kerberos v5. Это расши рение позволяет выполнять проверку подлинности пользователей с применением сертификатов и закрытых ключей, хранимых на смарт-картах. Вход пользователя в систему по смарт-карте повышает безопасность процедуры проверки его подлин ности и позволяет применять единый набор реквизитов пользователя как для ло кального, так и удаленного входа по сети. Основные компоненты инфраструктуры открытого ключа Далее перечислены основные компоненты инфраструктуры открытого ключа в Windows 2000: Х службы сертификации Windows 2000 отвечают за выпуск и управление цифро выми сертификатами; Х интерфейс Microsoft Crypto API и поставщика службы криптографии (cryp tographic service providers, CSP) поддерживают криптографические операции и управление закрытыми ключами; Х хранилища сертификатов для хранения и управления сертификатами на пред приятии. Службы сертификации в Windows На рис. 1G-2 показана функциональная блок-схема служб сертификации в Win dows 2000. CryptortPI Защищенное хранилище Закрытые ключи Поддерживает аудит и Поставщики CSP Обеспечивают списки отозванных сертификата криптографические службы и управление База данных закрытыми ключами сертификатов Модуль выхода Службы сертификации Отправляет Создают сертификаты стандарта выпущенные Х.509 на основе шаблонов и в сертификаты и соответствии с политикой. Создают списки отозванных списки отозванных сертификатов сертификатов в точки распространения Модуль политики Шаблоны Обрабатывает запросы сертификатов на сертификаты Рис. 16-2. Функциональная блок-схема служб сертификации в Windows Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 Компоненты служб сертификации Windows 2000 работают совместно с Microsoft CryptoAPI и поставщиками службы криптографии, что позволяет решать многие задачи безопасности, в том числе: Х обработку запросов на сертификаты (входной модуль); Х проверку правомочности обращающихся за сертификатами (модуль политики); Х создание и выпуск сертификатов для запросивших сертификат и прошедших проверку на правомочность (ядро служб сертификации); Х генерацию закрытою ключа и размещение его в безопасном хранилище получа теля сертификата (поставщики CSP и Microsoft CryptoAPI); Х управление закрытым ключом во всех криптографических операциях (постав щики CSP и Microsoft CryptoAPI); Х распределение выпущенных сертификатов среди уполномоченных получателей и, по особому запросу, публикация сертификатов на Web-страницах, в общих папках или в Active Directory (выходной модуль); Х периодическую публикацию списков отозванных сертификатов в Active Direc tory и, по особому запросу, па Web-страницах или в общих папках (выходной модуль); Х сохранение всех транзакций с сертификатами в следе аудита (база данных сер тификатов). Примечание В Windows 2000 все криптографические функции и управление закры тым ключом выполняются интерфейсом Microsoft CryptoAPI совместно с постав щиками службы криптографии. Любая системная служба или приложение вправе запрашивать криптографические службы посредством Microsoft CrypLoAPI, Модуль входа Стандартный модуль входа (entry module) обрабатывает запросы сертификатов стандарта PKCS #10 (Public Key Cryptography Standards), передаваемые по меха низму удаленного вызова процедур (remote procedure call, RPC) или по протоколу HTTP. Входной модуль Ч это недоступная для изменений динамически подключа емая библиотека (DLL). Для подачи заявок на сертификаты в предприятии служ бы Windows 2000 обычно используют RPC, а для подачи заявок через Интернет применяются Web-страницы подачи заявок через Интернет (Web Enrollment Support) и протокол HTTP Запросы на сертификаты в службу сертификации размещаются в очередь отложен ных сертификатов до одобрения или отклонения модулем политики, Примечание Вы вправе создавать специальные приложения для приема запросов на сертификаты. Эти приложения передают запросы в службы сертификации средствами RPC или HTTP Подробнее о разработке специализированных приложений для взаи модействия со службами сертификации Windows 2000 и о формате запросов на серти фикаты Ч на Web-странице Web Resources по адресу wmdows2000/reskit/webresources, ссылка Microsoft Platform SDK. Безопасность в распределенных системах 692 ЧАСТЬ Модули политики Модуль политики (policy module) решает судьбу запроса на сертификат - будет ли он удовлетворен, отклонен или поставлен в очередь отложенных сертификатов до принятия решения администратором. Службы сертификации Windows 2000 содер жат стандартный модуль политики, содержащий политику ЦС как для предприя тия, так и для изолированного центра сертификации. Вы также вправе создавать специализированные модули политики для решения своих задач. Модуль политики предприятия управляет интерактивной обработкой запросов на сертификаты: немедленно выпускает сертификаты или отказывает в запросе. Сис тема обращается в Active Directory за информацией для проверки подлинности об ращающихся за сертификатами и затем автоматически решает, предоставить или отказать в выдаче сертификата запрошенного типа. Модуль изолированной политики - по умолчанию отправляет запросы на серти фикаты в очередь отложенных сертификатов для принятия решения по ним адми нистратором. Вы вправе настроить политику изолированного ЦС на автоматичес кое удовлетворение всех запросов на сертификаты. Однако, так как изолированный ЦС не использует Active Directory для проверки подлинности тех, кто запросил сер тификат, невозможно автоматически аутентифицировать и установить правомоч ность запрашивающего на получение сертификата. Таким образом, настройка на автоматическое удовлетворение всех запросов представляет существенную угрозу для безопасности системы. Настраиваемые модули политики это полностью настраиваемые DLL. Подроб нее о создании специализированных (или настраиваемых) модулей политики на Web-странице Web Resources по адресу reskit/webresources, ссылка Microsoft Platform SDK. Средства консоли Certification Authority (Центр сертификации) позволяют заменить предопределенный модуль политики. Вы также можете разработать собственные модули политики или при обрести их у сторонних поставщиков. Примечание Специализированные модули политики рекомендуется применять только па изолированных ЦС. Для надлежащей интеграции с Active Directory центр сертификации предприятия нуждается в стандартном модуле политики предприя тия. Применение нестандартного модуля политики на ЦС предприятия в некито рых случаях приводит к непредсказуемым результатам. В процессе принятия решения о выдаче сертификата модуль политики обращается за информацией к самым разнообразным источникам, например к службе катало гов, унаследованной внешней базе данных и внешним центрам сертификации. Кро ме того, его разрешается настроить на автоматическое информирование админист ратора при ручной обработке запросов на сертификаты. Модуль политики способен размещать в сертификате дополнительные атрибуты или расширения, необходимые для нормальной работы клиентских приложений. Например, информацию о должности, и. ограничении па сумму заказа, выполняе мого с применением данного сертификата. Такие данные в дальнейшем применя ют, например, в интерактивной форме для определения, имеет ли пользователь пра во па указанную им сумму заказа. Добавляя обязательные атрибуты в выпускаемый сертификат, модуль политики может извлекать их значения из дополнительной информации, указанной в запро Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 се на сертификат. Например, запросы на получение сертификата в изолированном ЦС должны содержать все данные о затребованном сертификате; модуль политики помещает эту информацию в выпускаемый сертификат. С другой стороны, для оп ределения атрибутов сертификатов ЦС предприятия использует шаблоны сертифи катов, поэтому запросы в ЦС предприятия содержат меньше данных. Шаблоны сертификатов В ЦС предприятия атрибуты различных типов сертификатов содержатся в шабло нах сертификатов. ПС предприятия конфигурируется на выпуск определенных ти пов сертификатов авторизованным пользователям и компьютерам. Создавая серти фикат, ЦС использует атрибуты из шаблона сертификата, в том числе сведения о назначениях сертификата, криптографических алгоритмах, длине закрытого ключа и сроке действия. Шаблоны сертификатов хранятся в Active Directory и содержат стандартные данные для сертификатов, типы которых перечислены в таблице 16-1. Таблица 16-1. Типы сертификатов, выпускаемых ЦС предприятия Тип сертификата Назначение Administrator (Администратор) Проверка подлинности клиентов, шифрованная файло вая система (EFS), защищенная почта, подписание спис ков доверия (certificate trust list, CTL) и подписание кода Проверка подлинности клиентов Authenticated Session (Проверенный сеанс) Basic EPS Шифрованная файловая система (EFS). (Базовое шифрование EPS) СЕР Encryption Получение сертификатов в ЦС Windows 2000 маршру тизаторами производства Cisco Systems, Inc. Сертифи (СЕР шифрование ) каты применяются для проверки подлинности по прото (автономный запрос) колу IPSec Code Signing Подписание кода (Подписывание кода) Computer (Компьютер) Проверка подлинности клиентов и серверов Проверка подлинности контроллеров домена. При нали Domain Controller чии ЦС предприятия этот тип сертификата автомати (Контроллер домена) чески выдается контроллерам домена для поддержки операций открытого ключа, необходимых для служб сертификации на контроллерах домена Восстановление шифрованных данных в EFS EFS Recover}' Agent (Агент восстановления EFS) Проверка подлинности администраторов, запрашиваю Enrollment Agent щих сертификаты от имени пользователей, обладающих (Агент подачи заявок) смарт-картами Проверка подлинности служб, запрашивающих серти Enrollment Agent (computer) фикаты от имени других компьютеров [Агент подачи заявок (компьютер)] Проверка подлинности администраторов Microsoft Exchange Enrollment Agent Exchange Server, запрашивающих сертификаты от имени (Обмен агентами подачи пользователей защищенной почты заявок) (автономный запрос) Используется сервером Exchange Server для проверки Exchange Signature Only подлинности клиентов и для защищенной почты (толь (Обмен только подписями) ко для подписания) (автономный запрос) (см. след, стр.) Безопасность в распределенных системах 694 ЧАСТЬ Таблица 16-1. (продолжение) Назначение Тип сертификата Exchange User (Обмен Применяется сервером Exchange Server для проверки пользователями) подлинности клиентов и для защищенной почты (как (автономный запрос) для подписания, так и шифрования почты) Проверка подлинности средствами IPSec IP Sec IPSec (автономный запрос) Проверка подлинности средствами IPSec Root Certification Authority Применяется для установки корневого центра сертифи (Корневой пентр сертификации) кации. (Сертификаты на основе атого шаблона не вы пускаются ДС и используются только при установке корневого ЦС.) Проверка подлинности маршрутизаторов Router (Маршрутизатор) (автономный запрос) Smart Card Logon Проверка подлинности клиентов и вход с использовани (Вход со смарт-картой) ем смарт-карты Smart Card User (Пользователь Проверка подлинности клиентов, защищенная элект со смарт-картой) ронная почта и вход со смарт-картой Subordinate Certification Используется для ныпуска сертификатов подчиненного Authority (Подчиненные центры центра сертификации сертификации) (автономный запрос) Trust List Signing Подписание списка доверия (certificate trust list, CTL) (Подписывание списка доверия) User (Пользователь) Проверка подлинности клиента, шифрованная файловая система и защищенная электронная почта (для подписа ния и шифрования почты) User Signature Only Проверка подлинности клиента и защищенная элект (Только подпись пользователя) ронная почта (только для подписания) Web Server (Веб-сервер) Проверка подлинности Web-сервера (автономный запрос) Многие шаблоны сертификатов существуют для удовлетворения интерактивных (online) запросов на сертификаты, направленных в ЦС предприятия. Такие шабло ны используются для выпуска сертификатов клиентам, обладающим учетными за писями Windows 2000 и поддерживающим получение сертификатов непосредствен но в ЦС предприятия. Шаблоны сертификатов для автономных запросов служат для выпуска сертификатов клиентам, не обладающим учетными записями Win dows 2000 или не поддерживающим немедленное получение сертификатов в цент ре сертификации предприятия. При выпуске сертификата для интерактивных за просов идентификационная информация о клиенте извлекается из его пользова тельской учетной записи в Windows 2000 и размещается в сертификате. Автоном ные запросы должны содержать идентификационные данные клиента. Запрашивая сертификат в ЦС предприятия автономно, посредством специализированных Web страниц для подачи заявок через Интернет (Web Enrollment Support), необходимо указать в форме все идентификационные сведения (имя, адрес электронной почты, подразделение и другие). Например, Web-страницы для подачи заявок через Интернет можно использовать для запроса сертификата Web-сервера для стороннего Web-сервера, а затем устано вить сертификат на этот сторонний сервер. Аналогично можно получить сертифи кат IPSec в автономном режиме, а затем вручную установить его на клиенте IPSec Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 иод управлением операционной системы, отличной от Windows 2000. Шаблон сер тификата подчиненного центра сертификации является автономным сертификатом, так как идентификационная информация подчиненного ЦС вводится в процессе установки. Типы сертификатов центра сертификации предприятия указаны в его политике выпуска сертификатов. По умолчанию в Windows 2000 сразу после установки ЦС предприятия способен выпускать сертификаты нескольких типов. Стандартная конфигурация ЦС изменяется средствами консоли Certification Authority (Центр сертификации), в которой разрешается задать типы сертификатов, выпускаемые каждым из центров сертификации. На изолированных ЦС шаблоны сертификатов не используются, поэтому запросы на сертификаты должны содержать всю информацию, необходимую для определе ния типа запрашиваемого сертификата. Запрашивая сертификаты у изолированных ЦС, службы Windows 2000 предоставляют такую информацию. Для запросов сер тификатов определенных типов в изолированном ЦС разрешается также применять Web-страницы для подачи заявок через Интернет (Web Enrollment Support). База данных сертификатов В базе данных сертификатов регистрируются все операции с сертификатами. В ней хранится информация обо всех запросах на сертификаты и сведения об удовлетво рении или отклонении запросов, а также атрибуты выпущенных сертификатов, в том числе серийный номер и срок действия. Механизм базы данных обеспечивает полный след аудита всех сертификатов Ч от запроса на сертификат до окончания срока его действия, а также отмечает и отслеживает сертификаты, отозванные ад министраторами ЦС. Управление аудитом выполняется средствами консоли Certification Authority (Центр сертификации). Поскольку база данных сертификатов Ч транзактная, она содержит журналы сер тификатов, в которых регистрируются все транзакции с сертификатами..По умол чанию база данных сертификатов и журналы сертификатов размешены в папке: <диск>:\WINNT\System32\CertLog где <диск> Ч буква диска, на котором установлен ЦС. В процессе установки ЦС разрешается- выбрать другое место для хранения базы данных и журналов, а также разместить их на разных дисках. Модули выхода Модуль выхода надлежащим образом упаковывает выпущенный сертификат в со ответствии с выбранным механизмом передачи или протоколом и отправляет его по адресу, указанному в запросе. В запросе на сертификат также можно указать место его публикации Ч в службе LDAP-каталога, в файловой системе или по оп ределенному URL-адресу. Модуль выхода, кроме того, доставляет списки отозван ных сертификатов (CRL) в точки распространения списков CRL. Стандартный модуль выхода предприятия публикует сертификаты и списки CRL в Active Directory, а стандартный изолированный модуль выхода публикует серти фикаты и CRL в локальной файловой системе. Тем не менее службы сертифика ции в Windows 2000 поддерживают многие модули выхода, которые устанавлива ются па данном ЦС средствами консоли Certification Authority (Центр сертифика ции). Например, Вы вправе установить модули выхода, отправляющие сертифика Безопасность в распределенных системах 696 ЧАСТЬ ты и списки CRL в унаследованную базу данных, поддерживающую протокол ODBC (open database connectivity), или и службу LDAP-каталога стороннего про изводителя, Так же как и модуль политики, модуль выхода представляет собой DLL, его можно настраивать и заменять специализированными библиотеками. Подробнее о на стройке модулей выхода - на Web-странице Web Resources по адресу windows.microsoft.com/wmdows2000/rcskit/webresources, ссылка Microsoft Platform SDK. Замена установленного модуля выхода выполняется средствами консоли Certification Authority (Центр сертификации). Вы также вправе разрабатывать свои собственные модули выхода или приобретать модули выхода сторонних произво дителей. Консоль Certification Authority Консоль Certification Authority (Цент]) сертификации) это оснастка ММС, по зволяющая управлять несколькими ЦС и выполнять административные задачи, например: Х запуск и остановку ЦС; Х архивирование и восстановление ЦС; Х замену модулей выхода и политики; Х просмотр сертификата ЦС; Х установку или переустановку сертификатов ЦС на данном ЦС; Х настройку разрешений безопасности и делегирование административного управ ления центром сертификации; Х отзыв сертификатов; Х просмотр или изменение точек распространения списков отозванных сертифи катов (CRL); Х планирование и публикацию списков CRL; Х конфигурирование типов сертификатов, выпускаемых ЦС; Х просмотр информации о выпущенных сертификатах; Х просмотр информации об отозванных сертификатах; Х просмотр отложенных запросов на сертификаты; Х отказ или одобрение отложенных запросов на сертификаты; Х просмотр отвергнутых запросов на сертификаты; Х обновление сертификата ЦС. Подробнее об использовании консоли Certification Authority для управления цент рами сертификации и выполнении конкретных административных задачи Ч в спра вочной системе Certificate Services (Службы сертификации). ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows ^ Добавление консоли Certification Authority (Центр сертификации) в окно ммс 1. Откройте ММС. В мелю Console (Консоль) выберите команду Add/Remove Snap-in (Добавить/ 2. удалить оснастку) или нажмите CTRL+M, Откроется диалоговое окно Add/Remove Snap-in (Добавить/Удалить оснастку). Щелкните Add (Добавить), 3. Откроется диалоговое окно Add Standalone Snap-in (Добавить изолированную оснастку). 4. В списке оснасток выберите Certificates (Сертификаты) и щелкните Add (До бавить). Откроется диалоговое окно Certification authority (Центр сертификации). Выберите одну из двух возможностей: 5. Х чтобы управлять ЦС на локальном компьютере, установите переключатель в положение Local computer (локальным компьютером) и затем щелкните Finish (Готово); Х чтобы управлять ЦС на другом компьютере, установите переключатель в положение Another computer (другим компьютером), а затем введите домен ное имя компьютера с ЦС или щелкните Browse (Обзор) и выберите компь ютер из списка. Щелкните кнопку Finish (Готово). В диалоговом окне Add Standalone Snap-in Вы можете, еще раз нажав Add, до бавить еще одну оснастку. В диалоговом окне Add/Remove Snap-in отображаются выбранные Вами оснас тки для установки в ММС. 6. Закончи и добавлять оснастки в диалоговом окне Add Standalone Snap-in, щел кните Close (Закрыть). 7. В диалоговом окне Add/Remove Snap-in щелкните ОК. На рис. 16-3 показана консоль Certification Authority, добавленная в окно ММС. Она управляет ЦС па локальном компьютере. Узел Certification Authority (Local) (Цент сертификации (локальный)] консоли раз вернут Ч Вы видите вес контейнеры центра сертификации Enterprise-Root-CA предприятия. Эти контейнеры перечислены далее. Revoked Certificates (Отозванные сертификаты) - выделите этот контейнер, что бы просмотреть все отозванные сертификаты данного ЦС. Дабы опубликовать вруч ную список CRL, щелкните правой кнопкой мыши папку Revored Certificates и в контекстном меню выберите All Tasks (Все задачи), а затем Publish (Публика ция): Чтобы изменить расписание публикации списка CRL, щелкните правой кноп кой мыши папку Revored Certificates и в контекстном меню выберите Properties (Свойства). Для просмотра сертификата достаточно дважды щелкнуть его па; ша ние мышью. В открывшихся диалоговых окнах Вы сможете публиковать списки CRL, изменять расписание публикации списков CRL и просматривать параметры сертификата. Безопасность в распределенных системах 698 ЧАСТЬ Issued Certificates (Выданные сертификаты) - выделите этот контейнер, чтобы просмотреть информацию о всех сертификатах, выпущенных данным ЦС. Дабы отозвать сертификат, щелкните сертификат правой кнопкой мыши и в контекстном меню выберите подменю All Tasks (Все задачи), а затем - Revoke Certificate (От ; 5ыв сертификата). Для просмотра сертификата достаточно дважды щелкнуть его, Pending Requests (Запросы в ожидании) выделите этот контейнер, чтобы про смотреть информацию о всех отложенных запросах на сертификаты в данном ЦС. Дабы удовлетворить отложенный запрос на сертификат, щелкните правой кнопкой запрос и в контекстном меню выберите All Tasks (Все задачи), а затем - Issue (Вы дать). Чтобы отказать в отложенном запросе на сертификат, щелкните праной кноп кой мыши запрос и в контекстном меню выберите All Tasks, а затем Deny (Зап ретить). В открывшемся диалоговом окне выполните действия для завершения опе рации отказа в запросе, j Revoked Certificates ^J Issued Certificate; "^J Fend ing Pequests L3 Failed Requests :_J Policy Settings Рис. 16-3. Консоль Certification Authority Failed Requests (Неудачные запросы) в этом контейнере содержится информа ция обо всех запрошенных сертификатах, в выдаче которых отказано. В столбце Request Disposition Message (Запрос сообщения распоряжения) поясняется при чина отказа, Policy Settings (Параметры политики) (только ЦС предприятия) Ч в этом контей нере хранится информация о типах сертификатов, выпускаемым ЦС предприятия. Чтобы удалить определенный тип сертификатов, достаточно выбрать его и нажать клавишу Delete. Для добавления нового типа сертификата щелкните контейнер пра вой кнопкой мьптш, в контекстном меню выберите New (Создать) и в открывшем ся окне щелкните Certificate (Выдаваемый сертификат). В следующем диалоговом окне выберите и добавьте требуемые типы сертификатов. По умолчанию при отображении контейнера, например Failed Requests, многие из столбцов в области сведений (правой панели окна) скрыты. ^ Выбор столбцов, отображаемых в области сведений 1. Щелкните правой кнопкой мыши требуемый контейнер, в контекстном меню выберите подменю View (Вид) и щелкните команду Choose Columns (Выбрать столбцы). Откроется диалоговое окно Modify Columns (Изменить столбцы). Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 2. Средствами диалогового окна Modify Columns добавьте, удалите или измените порядок отображения столбцов и щелкните ОК. Подробнее об использовании диалогового окна Modify Columns Ч в справоч ной системе служб сертификации. Microsoft CryptoAPI и поставщики службы криптографии Microsoft CryptoAPI обеспечивает безопасный интерфейс для выполнения крипто графических операций, предоставляемых устанавливаемыми модулями поставщи ка службы криптографии (cryptographic service provider, CSP). Эти модули выпол няют все криптографические операции и управляют закрытыми ключами. CSP ре ализуются в виде программ или специализированных аппаратных устройств. Служ бы сертификации в Windows 2000 используют CryptoAPI и CSP для выполнения всех криптографических операций и управления закрытыми ключами. Функции CryptoAPI и CSP доступны всем службам и приложениям, нуждающимся в крип тографических службах. Подробнее о CryptoAPI и CSPs Ч на Web-странице Web Resources по адресу ссылки Microsoft Security Advisor и Microsoft Platform SDK. Аппаратные и программные поставщики службы криптографии Поставщики службы криптографии реализуются программно, аппаратно или как комплекс аппаратно-программных средств. Аппаратные решения криптографичес кий операций и управления ключами более безопасны, чем программные, так как в них криптографические операции и закрытые ключи изолированы от операцион ной системы. С другой стороны, аппаратные решения CSP, например на смарт-кар те, обычно ограничены количеством закрытых ключей, а на создание новых клю чей требуется много времени. Программные поставщики службы криптографии более гибки, чем аппаратные, но за гибкость приходится платить некоторым снижением степени безопасности. Тем не менее программные CSP обеспечивают вполне достаточную защиту, удов летворяя большинство потребностей в безопасности. Аппаратные CSP применяют только в специализированных приложениях безопасности, например для входа со смарт-картой или для обеспечения защищенной связи через Интернет с примене нием криптографических карт FORTEZZA. Производители предлагают аппаратные и программные поставщики службы безо пасности, которые поддерживают самые разнообразные криптографические опера ции и технологии. Однако их нормальная работа в Windows 2000 гарантирована, только если они сертифицированы и подписаны Microsoft. Неподписанные компа нией Microsoft поставщики службы безопасности в Windows 2000 не работают. Поставщики службы криптографии производства Microsoft Далее перечислены поставщики службы криптографии производства Microsoft, со держащиеся в Windows 2000, Microsoft Base Cryptographic Provider поддерживает широкий набор основных криптографических функций. На него не налагаются ограничения на экспорт крип тографических технологий США, и он разрешен к экспорту в другие страны и ре гионы (однако на пего распространяются общие ограничения на экспорт из США и импортные ограничения других стран). Base CSP построен на основе технологии RSA, лицензия на которую принадлежит компании RSA Data Security. 700 ЧАСТЬ 2 Безопасность в распределенных системах Microsoft Enhanced Cryptographic Provider обеспечивает те же функции, что и Base CSP, но защищает лучите, поддерживая ключи большей длины и дополнитель ные криптографические алгоритмы. Этот CSP подлежит ограничениям на экспорт криптографических технологий правительства США и недоступен в отдельных странах или регионах. Этот поставщик службы криптографии также построен на основе технологии RSA. Microsoft DSS Cryptographic Provider обеспечивает подписание данных и провер ку подписи по алгоритмам SHA (Secure Hash Algorithm) и DSA (Digital Signature Algorithm). Он также не подпадает под ограничения на экспорт криптографичес ких технологий Соединенных Штатов и разрешен к экспорту в другие страны и регионы (однако подлежит общим ограничениям на экспорт из США и импортным ограничениям других стран). Microsoft Base DSS and Diffie-Hellman Cryptographic Provider является дополне нием DSS Cryptographic Provider и поддерживает обмен ключами по схеме Диффи Ч Хелмана, хэширование (создание выборки из сообщения), подписание данных и проверку подписи средствами алгоритмов DSA и SHA. Этот CSP подлежит огра ничениям па экспорт криптографических технологий Соединенных Штатов и не доступен в отдельных странах или регионах. Schannel Cryptographic Providers поставщики Microsoft RSA/Schannel Cryp tographic Provider, Microsoft DSS Cryptographic Provider и Diffie-Hellman/Schannel Cryptographic Provider предоставляют различные криптографические функции не обходимые для обеспечения целостности данных, обмена ключом сеанса и провер ки подлинности в процессе обмена данными через Интернет по протоколам TLS и SSL. Эти CSP не подлежат ограничениям на экспорт криптографических техноло гий Соединенных Штатов и разрешены к экспорту в другие страны и регионы (од нако подлежат общим ограничениям на экспорт из Соединенных Штатов и импор тным ограничениям других стран). Сертификация по стандарту FIPS140-1 Level Все CSP в Microsoft Windows 2000 обладают сертификатом FIPS 140-1 Level (Federal Information Processing Standard), выданным Национальным институтом стандартов и технологий (National Institute of Standards and Technology, NIST). Требования стандарта FIPS 140-1 Level 1 определены в документах NIST, посвящен ных FIPS 140-1. Чтобы узнать, как получить документы о F1PS140-1, обращайтесь непосредственно в NIST Подробнее о FTPS 140-1 - в главе 13 Обеспечение безо пасности средствами технологии открытого ключа. Сравнительный анализ Base CSP и Enhanced CSP Microsoft Base Cryptographic Provider (Base CSP) разрешен к практически свобод ному экспорту из США, a Microsoft Enhanced Cryptographic Provider (Enhanced CSP) подлежит ограничениям на экспорт криптографических технологий и досту пен только в некоторых странах, в которые разрешен экспорт устойчивых криптог рафических технологий. Подробнее об ограничениях на экспорт криптографичес ких технологий Ч в главе 14 Криптография в сетевых информационных системах и на Web-странице Web Resources по адресу windows2000/reskit/wcbresources, ссылка Microsoft Security Advisor. В таблице! 6-2 представлены различия Base CSP и Enhanced CSP для ключей стан дартной длины. Службы сертификации и инфраструктура открытого ключа в Windows ГЛАВА 16 Таблица 16-2. Сравнение Base CSP и Enhanced CSP Алгоритм Base CSP Enhanced CSP RSA-алгоритм открытого Длина ключа: 512 бит Длина ключа: 1 024 бит ключа для подписания RSA-алгоритм открытого Длина ключа: 512 бит Длина ключа: 1 024 бит ключа для обмена ключами Алгоритм сплошного Длина ключа: 40 бит Длина ключа: 128 бит Длина изменяемой открытой части шифрования RC ключа (salt): настраивается Алгоритм потокового Длина ключа: 40 бит Длина ключа: 128 бит Длина изменяемой открытой части шифрования RC ключа (salt): настраивается Не поддержи нается Длина ключа: 56 бит DES Triple DES (2 ключа) Не поддержи нается Длина ключа: 1 12 бит Triple DES (3 ключа) Не поддерживается Длина ключа: 168 бит В обоих CSP максимальная длина открытых ключей цифровых подписей достига ет 16 384 бит. Однако длина открытых ключей, которые используются для шифро вания ключей и обмена ключами (то есть для защиты закрытых ключей), ограни чены 1 024 битами в Base CSP и 16 384 Ч в Enhanced CSP. Кроме того, длины сим метричных ключей в алгоритмах шифрования поставщика Base CSP меньше и обес печивают менее стойкую криптографическую защиту. В целом, длины ключей и алгоритмы шифрования в Enhanced CSP позволяют обеспечить гораздо более на дежную криптографическую защиту. В обоих CSP длина открытых ключей, используемых для цифровых подписей и обмена ключами, составляет не менее 384 бита. Однако применять ключи длиной 384 бита не стоит. Рекомендуемая длина - не менее 512 бит, а по возможности 1 024 бита. Ключи длиной свыше 1 024 бита обеспечивают устойчивые цифровые подписи. С другой стороны, длинные ключи создают существенную вычислитель ную нагрузку, и процесс подписания занимает довольно много времени, это отри цательно сказывается па общей производительности компьютера и может вынудить Вас отказаться от их применения. По умолчанию длина открытого ключа в Base CSP Ч 512 бит, а в Enhanced CSP Ч 1 024 бит. Службы сертификации в Win dows 2000 обычно используют заданные по умолчанию длины открытых ключей CSP. хотя Вы вправе установить другую длину ключа, поддерживаемую CSP. Enhanced CSP совместим с Base CSP за исключением того, что для алгоритмов RC или RC4 эти поставщики службы безопасности способны генерировать ключи только стандартной (по умолчанию) длины: в Base CSP это 40 бит, а в Enhanced CSP 5ит. Поэтому ключи Enhanced CSP несовместимы с Base CSP. Однако Enhanced CSP импортирует ключи RC2 и RC4 /ушной менее 128 бит, то есть он поддерживает 40-битные ключи, созданные в Base CSP. Поставщики службы криптографии, поддерживающие смарт-карты Windows 2000 содержит поставщики CSP, поддерживающие смарт-карты, двух про изводителей: Gemplus SCA и Schlumberger Limited. Gemplus GemSAEli Card CSP и Schluniberger CSP поддерживают криптографические операции с PC/SC-совмести мыми смарт-картами Gemplus и Schlumberger. Co временем разрабатываются и сер тифицируются для Windows 2000 дополнительные CSP, поддерживающие смарт Безопасность в распределенных системах 702 ЧАСТЬ карты. Подробнее о поставщиках службы криптографии, поддерживающих смарт карты па Web-странице Web Resources по адресу windows2000/reskit/webresources, ссылка Microsoft Security Advisor. Ограничения на экспорт криптографических технологий На модули CSP налагаются ограничения на экспорт криптографических техноло гий, в частности правительством США и другими странами. Доступность модулей CSP определяется экспортным и импортным ограничениям конкретных стран. Максимальная длина ключей, поддерживаемых программным обеспечением в со ставе Windows 2000, составляет 40 или 56 бит для симметричного шифрования и разрешена к экспорту в большинство стран мира. Обладая правом использовать не подлежащие экспорту криптографические технологии, Вы можете получить у Microsoft компакт-диск Encryption Pack и с его помощью преобразовать экспорт ную версию Windows 2000 в версию, поддерживающую устойчивую криптографию. Па этом компакт-диске есть неразрешенная к экспорту версия Microsoft Enhanced Cryptographic Provider for Windows 2000. Подробнее о доступности компакт-диска Encryption Pack и текущей политике экс порта криптографических технологий в продуктах Microsoft Ч на Web-странице Web Resources по адресу webresources, ссылка Microsoft Security Advisor. Хранилища сертификатов В Windows 2000 объекты открытых ключей, в том числе сертификаты, списки CRL и списки CTL (certificate trust list) находятся в хранилище сертификатов. При не обходимости пользователи, службы и компьютеры обращаются за ключами в хра нилище. В Windows 2000 существуют физические и логические хранилища. Физическое хранилище сертификатов (physical certificate store) Ч это место, где фи зически размещены объекты открытых ключей Ч локально (в реестре) или удаленно (в Active Directory). Многие из объектом открытых ключей в физических хранили щах совместно применяются пользователями, службами и компьютерами. Эта функ ция поддерживается средствами механизма логических хранилищ сертификатов. В логическом хранилище (logical certificate store) сертификаты сгруппированы в ло гические и функциональные категории для удобства обращения к ним пользовате лей, компьютеров и служб. Логические хранилища сертификатов содержат' указате ли на физические хранилища и управляются средствами оснастки Certificates (Сер тификаты). Изменения в логических хранилищах сертификатов отражается па содер жании соответствующих физических хранилищ, размещенных в реестре или в Active Directory. Поскольку пользователи, службы и компьютеры обращаются только к ло гическим хранилищам, Вам не придется отслеживать, где физически размещены сер тификаты, и редактировать реестр, управляя хранилищем сертификатов. Механизм логических хранилищ; устраняет необходимость создавать несколько ко пий таких объектов, как доверенные корневые сертификаты, списки CTL и CRL. Пользователи и службы применяют множество стандартных объектов открытых ключей совместно с локальным компьютером. Объекты общих закрытых ключей хранятся в разделах системного реестра локального компьютера. Однако некото рые из них предназначены только для отдельных служб, пользователей или конк ретных локальных компьютеров. Поэтому у каждого из них есть индивидуальные хранилища, где размещены не используемые совместно сертификаты, списки CTL ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 и CRL. Например, пользователь вправе запросить и получить сертификат или С RL, который будет размещен в его персональном логическом хранилище', а физически в персональном физическом хранилище пользователя и реестре. Такие частные сертификаты пользователей и списки CRL Tie используются совместно с локаль ным компьютером или его службами. Кроме того, некоторые объекты открытых ключей, такие, как доверенные корневые сертификаты и списки CTL, распространяются и соответствии с групповой полити кой открытом ключа (Public Key Group Policy). Объекты открытых ключей, рас пространяемые средствами групповой политики, хранятся в специальных областях реестра и отображаются в логических хранилищах, где доступны для пользовате лей, компьютеров и служб. В оснастке Group Policy (Групповая политика) можно создать раздельные списки CTL для пользователей и компьютеров. CTL пользова телей недоступны службам или компьютерам, однако списки CTI. компьютеров доступны пользователям и службам. В логических хранилищах сертификаты сгруппированы по нескольким категориям. Personal (Личные) Ч в этой категории хранятся личные сертификаты пользовате ля, службы или компьютера. Например, когда Вы получаете в ЦС сертификат I'ser (Пользователь), он попадает в хранилище Personal, сопоставленное Вашей учетной записи, Trusted Root Certification Authorities (Доверенные корневые центры сертифика ции) содержит сертификаты корневых ЦС. Компьютер доверяет сертификатам с путями сертификации, ведущими к перечисленным в этой папке корневым ЦС, и санкционирует их использование для всех назначений, разрешенных этими серти фикатами. Enterprise Trust (Доверительные отношения в предприятии) содержит списки CTL, Компьютер доверяет сертификатам с путями сертификации, ведущими к сертифи катам, перечисленным в списке CTL, поддерживать все назначения, разрешенные этим CTL. Intermediate Certification Authorities (Промежуточные центры сертификации) со держит сертификаты ЦС, которые не являются доверенными корневыми сертифи катами (например, сертификаты подчиненного ЦС), но требуются для проверки правильности пути сертификации. В этом хранилище также размещаются списки CRL, к которым обращаются пользователи, службы и компьютеры. Active Directory User Object (Объект пользователя Active Directory) содержит сер тификаты, опубликованные в Active Directory для пользователя. Это хранили ще доступно в консоли Certificates (Сертификаты) только для пользователей, но не для компьютеров или служб, Request (Запрос) содержит отложенные или отклоненные запросы на сертификат. Это хранилище доступно в консоли Ccrtiiicates (Сертификаты) только после полу чения запроса на сертификат для пользователя, компьютера или службы, SPC содержит сертификаты для распространителей программного обеспечения, которым доверяет данный компьютер. Программное обеспечение, подписанное рас пространителями, сертификаты которых расположены в этом хранилище, загружа ется автоматически (пользователь не информируется). По умолчанию это храни лище пусто. При первой загрузке подписанного программного обеспечения Mic rosoft Internet Explorer спрашивает у пользователя, доверяет ли он всему программ ному обеспечению, подписанному данным распространителем. В случае утверди ЧАСТЬ 2 Безопасность в распределенных системах тельного ответа браузер размещает сертификат распространителя программного обеспечения (software publisher certificate, SPC) в хранилище SPC. Последнее дос тупно в консоли Certificates только локальному компьютеру, но не пользователям или службам, Особенности инфраструктуры открытого ключа Далее перечислены основные элементы инфраструктуры открытого ключа и служб сертификации в Windows 2000: Х консоль Certificates (Сертификаты) (оснастка ММС); Х модель доверия центров сертификации; Х центры сертификации предприятия (и изолированные) Windows 2000; Х жизненный цикл сертификатов; Х механизмы выпуска и обновления сертификатов; Х групповая политика открытого ключа (Public Key Group Policy); Х списки отозванных сертификатов; Х предустановленные сертификаты доверенных корневых ЦС; Х поддержка смарт-карт; Х сопоставление сертификатов; Х поддержка перемещаемых профилей. Консоль Certificates Консоль Certificates (Сертификаты) - это оснастка ММС, средствами которой уп равляются хранилища сертификатов пользователей, компьютеров и служб. Она поддерживает выполнение следующих задач: Х просмотр информации сертификатов, в том числе содержания сертификата и пути сертификации; Х импорт сертификатов в хранилище; Х перемещение сертификатов между хранилищами; Х экспорт сертификатов и по особому требованию Ч закрытых ключей (если эта операция разрешена); Х удаление сертификатов из хранилища: Х запрос сертификатов в ЦС предприятия для размещения в хранилище- Personal. Подробнее об использовании консоли Certificates Ч R справочной системе оснаст ки Certificates (Сертификаты). ^ Добавление консоли Certificates в окно ММС 1. Откройте ММС. 2. В меню Console (Консоль) выберите команду Add/Remove Snap-in (Добавить/ удалить оснастку) или нажмите Ctrl+M. Откроется диалоговое окно Add/Remove Snap-in (Добавить/Удалить оснастку). ГЛАВА 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 Щелкните Add (Добавить). 3. Откроется диалоговое окно Add Standalone Snap-in (Добавить изолированную оснастку). В списке оснасток выберите Certificates (Сертификаты) и щелкните Add (До 4. бавить). Откроется диалоговое окно Certificates Snap-in (Оснастка диспетчера сертифи катов). 5. Выберите одну из перечисленных учетных записей: Х My user account (моей учетной записи пользователя); Х Service account (учетной записи службы); Х Computer account (учетной записи компьютера), Консоль Certificates будет управлять хранилищем сертификатов для выбранной учетной записи. Книги, научные публикации