Posts on this page:
В предыдущих частях мы разговаривали о применении смарт-карт для хранения и использования ключей шифрования EFS в Windows Server 2008. Мы так же рассмотрели вопросы реализации агентов восстановления и самого процесса восстановления. Предыдущие 3 части:
И у нас остался только одна категория вопросов: что будет, если сертификат просрочен или будет отозван. В принципе, разницы в поведении между просроченными и отозванными сертификатами не будет, а именно:
В общем смысле понятно, что расшифровывать файлы/ключи можно с просроченными/отозванными сертификатами, но проводить новое шифрование уже невозможно.
Вот теперь, я так полагаю, мы в достаточной мере рассмотрели вопрос использования смарт-карт для EFS. В качестве эпилога скажу, что рекомендуется использовать комбинированные шаблоны для агентов восстановления. Например, если агент восстановления будет хранить свои закрытые ключи от EFS и Key Archival на смарт-карте, то выгодней будет использовать шаблон Smart Card Logon и в его EKU добавить уже необходимые области применения (например, Key Archival), что упрощает процедуру эксплуатации таких сертификатов в будущем. Не нужно будет теперь заботиться, что отдельные сертификаты будут истекать в разное время и при компрометации смарт-карты придётся отзывать несколько сертификатов - достаточно будет отозвать один сертификат. То же самое касается и пользователей, которые используют смарт-карты. Достаточно в Smart Card Logon EKU добавить Basic EFS и всё будет хорошо. Почти хорошо, если у вас есть Enterprise или Datacenter редакция Windows Server :)
Вопросы обновления сертификатов и прочие lifecycle эксплуатации (например, введение Certificate Autoenrollment и прочее) смарт-карт и EFS уже выходят за рамки моей статьи, поэтому вам придётся этот материал изучать самостоятельно. И на последок я подобрал несколько полезных ссылок, которые помогут с освоением данного материала:
В предыдущих частях мы рассмотрели принципы работы EFS, изучили основные вопросы безопасности и доступности ключей, а так же показали как создавать агентов восстановления файлов EFS и агентов восстановления ключей:
Когда у нас все агенты восстановления подготовлены и подготовлены шаблоны EFS + Smart Card Logon, то необходимо заранее подготовить смарт-карты и выпустить для них сертификаты. Для этого можно воспользоваться консолью MMC - certmgr.msc и выполнить запрос сертификата:
пользователь выполнил запрос сертификата и драйвер предложил сразу положить сертификат на токен. Данную процедуру необходимо проделать для всех пользователей, которые будут шифровать файлы сертификатами и хранить их на смарт-картах. После этого можно приступать к настройке групповой политики:
В Public Key Policies нужно выбрать свойства Encrypting File System и получим такое окно. Здесь у нас появилось много новых настроек, которых раньше не было. Вот скрин этого же окна в Windows Server 2003:
тут мы можем только или разрешить или запретить использование EFS. Пробежимся по настройкам новой консоли:
Чуть ниже мы можем позволить пользователям генерировать самоподписанные сертификаты EFS при недоступности существующего сертификата или недоступности централизованного Enterprise CA. В нашем случае использование самоподписанных сертификатов будет запрещено.
Примечание: часто замечаю, что администраторы сетей сильно пренебрегают вопросами планирования инфтраструктуры PKI и в Enterprise среде не разворачивают Certification Authority (хотя технических препятствий зачастую просто нету), а используют самоподписанные сертификаты. Я постоянно утверждаю, что самоподписанные сертификаты - вселенское зло, поскольку они неуправляемы. Во-первых, им никто (кроме самого издателя) не доверяет, отсутствует механизм управления настройками сертификатов и отсутствуют механизмы отзыва сертификата при компрометации ключа. Особенно часто такие сертификаты используют для веб-серверов или для OWA (Outlook Web Access).
И в самом низу указывается шаблон сертификатов, который будет использоваться для шифрования файлов. В моём случае это SM EFS. Если используются раздельные сертификаты для смарт-карт и EFS (версии 1), то следует оставить значение по умолчанию - Basic EFS.
Когда групповые политики будут настроены, то можно приступать к самому процессу шифрования. Когда пользователь захочет зашифровать файл, то он должен на файле или папке выбрать Properties -> Advanced -> Encrypt contents to secure data. И появится окно с предложением использовать сертификат смарт-каты для шифрования:
После чего потребуется выбрать сертификат из списка доступных сертификатов на смарт-карте и которые пригодны для шифрования:
Выбрав указанный сертификат потребуется ввести PIN от смарт-карты или токена. После этого файл или папка будут зашифрованы. Во время текущего сеанса, когда смарт-карта или токен установлены шифрованные файлы будут открываться без необходимости дополнительного ввода PIN. Но при изъятии смарт-карты и при установке обратно, либо при первой попытке открытия шифрованного файла после перелогона в трее появится значок, говорящий, что требуется авторизоваться на смарт-карте:
и потребует ввода PIN в смарт-карту.
Если ключ пользователя был утерян или временно недоступен, то назначенный групповой политикой агент восстановления EFS (как минимум должен иметь право Change extanded attributes на файл) проделывает точно такую же процедуру с вводом PIN от своего токена, где хранится ключ от EFS Recovery Agent и получает возможность расшифровать файл, как бы это сделал пользователь в штатном режиме. Но если токен был потерян, испорчен (т.е. угрозы похищения ключа нету), то не расшифровывать же все файлы пользователя? Можно расшифровывать, а можно и просто восстановить ключ пользователя из базы CA.
Для восстановления ключа шифрования из базы CA потребуется выполнить следующие шаги:
certutil -getkey 6148fa9e000000000022 %path%\outblob
C:\Users\Administrator>certutil -getkey 6148fa9e000000000022 .\desktop\outblob Querying dc1.contoso.com\contoso-DC1-CA..................... "dc1.contoso.com\contoso-DC1-CA" Serial Number: 6148fa9e000000000022 Subject: CN=Administrator, CN=Users, DC=contoso, DC=com UPN:administrator@contoso.com NotBefore: 12/18/2008 10:26 AM NotAfter: 12/18/2009 10:26 AM Template: SMEFS, SM EFS Version: 3 Cert Hash(sha1): 3c 43 ff 2d 0e 99 35 c4 a1 59 43 47 bc b6 50 91 1c b7 f5 8a Recipient Info[0]: CMSG_KEY_TRANS_RECIPIENT(1) CERT_ID_ISSUER_SERIAL_NUMBER(1) Serial Number: 61312c8f000000000020 Issuer: CN=contoso-DC1-CA, DC=contoso, DC=com Subject: CN=Recovery Agent, CN=Users, DC=contoso, DC=com CertUtil: -GetKey command completed successfully.
certutil -recoverkey %path%\outblob user.pfx
C:\Users\Recovery Agent>certutil -recoverkey outblob administrator.pfx dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000) dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000) ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000) HCCE_LOCAL_MACHINE CERT_CHAIN_POLICY_BASE -------- CERT_CHAIN_CONTEXT -------- ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) CertContext[0][0]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=contoso-DC1-CA, DC=contoso, DC=com NotBefore: 12/15/2008 1:26 AM NotAfter: 12/15/2013 1:36 AM Subject: CN=contoso-DC1-CA, DC=contoso, DC=com Serial: 6fc7646fe91510bc4631b9dcc08805e3 c3 44 cb 46 1d d8 d8 cf dc 35 fb 7c 27 cb 7d a1 d4 64 47 2c Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) Exclude leaf cert: da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09 Full chain: c3 44 cb 46 1d d8 d8 cf dc 35 fb 7c 27 cb 7d a1 d4 64 47 2c ------------------------------------ Verified Issuance Policies: All Verified Application Policies: All Computed Hash: b3 57 bf 4b fe 18 16 bf 38 a4 17 00 17 27 4e b9 43 64 d4 14 Decrypted PKCS7 Message Content User Certificate: Serial Number: 6148fa9e000000000022 Issuer: CN=contoso-DC1-CA, DC=contoso, DC=com Subject: CN=Administrator, CN=Users, DC=contoso, DC=com Cert Hash(sha1): 3c 43 ff 2d 0e 99 35 c4 a1 59 43 47 bc b6 50 91 1c b7 f5 8a Enter new password: Confirm new password: CertUtil: -RecoverKey command completed successfully.
Если же ключ был скомпрометирован (была утеряна смарт-карта и есть основания, что PIN известен 2-м и более лицам), то сертификат следует отозвать.
Вот мы и рассмотрели полностью (не скажу, что очень детально, но достаточно сносно для первой хау-ту :) ) вопрос имплементации новой возможности Windows Vista/Windows Server 2008 - хранение и использование ключей EFS на смарт-картах. Осталось рассмотреть только один вопрос - что будет, когда различные сертификаты истекут или будут отозваны, который я постараюсь (если всё получится) осветить в заключительной 4-й части.
В предыдущей части мы поговорили об основах работы шифрующей файловой системы EFS и основными трудностями, которые появляются при использовании EFS. И одной из важных задач становится защита ключей шифрования надёжным способом от взлома, но и обеспечить возможность восстановления данных при потере ключей шифрования и их доступность. Я уже отметил, что варианта у нас всего 2 - архивирование ключей на внешний контейнер (например, смарт-карта или USB диск) либо Key Archival, когда закрытые ключи дополнительно хранятся в базе Certification Authority. Причём, оба этих метода можно спокойно совместить. Но здесь Microsoft нас снова "радует" (что вполне ожидаемо) - Key Archival работает только при условии, что:
Механизм Key Archival работает следующим образом:
Исходя из этой процедуры нетрудно представить процесс восстановления:
Для начала нам потребуются агенты восстановления, которые будут уполномочены восстанавливать ключи из базы CA. Для этого в CA существует шаблон Key Recovery Agent. Из изменений, которые потребуются - на вкладке General поставить галочку для публикации сертификата в AD и в Security добавить нужных пользователей (но лучше будет поместить нужных агентов восстановления в отдельную группу и ей назначить право Read и Enroll). Затем следует в консоли CA добавить этот шаблон в список издаваемых сертификатов. Когда эта процедура будет завершена агенты восстановления должны подать заявку на выдачу сертификатов восстановления.
Примечание: здесь стоит отметить, что автоматическая выдача сертификатов работать не будет. Администратор CA должен вручную одобрить каждый запрос в секции Pending Requests. После того как запрос будет одобрен, изданный сертификат появится в секции Crtificate Enrollment Requests. Если агент восстановления для запроса использует Windows 2000/XP/2003, то запрос необходимо произвести запрос сертификата используя Certificates Web Enrollment pages из интернет-браузера.
Когда сертификат получен, то можно в CA разрешать Key Archival. Но если у вас есть смарт-карты, то лучше экспортировать пару ключей Key Recovery Agent на смарт-карту. В моём случае (используя Aladdin eToken Pro) потребовалось выполнить стандартную процедуру экспорта сертификата в PKCS #12 файл (.pfx) и используя ПО токена импортировать сертификат на токен. При экспорте ключей в файл не забудьте поставить галочку для удаления ключей из Certificate Store в случае успешного экспорта. После этой операции агент восстановления перестаёт быть зависимым к своему профилю и будет неуязвим к атакам на профиль.
Теперь администратор CA должен выбрать свойства CA и перейти на вкладку Recovery Agents:
В этом окне нужно переставить переключатель в Archive the key и кнопкой Add добавить сертификаты тех агентов восстановления, которые будут уполномочены для восстановления ключей. Именно этими сертификатами CA будет шифровать ключи пользователей.
Следующим этапом будет изменение шаблонов для поддержки Key Archival. Шаблоны версии 1 не поддерживают данную функцию, а только V2 и V3, а эти шаблоны поддерживаются только в Windows Server Enterprise и Datacenter редакциях. Конкретно для EFS придётся создать новый шаблон версии 2 или 3:
Я его назвал SM EFS (Smart Card EFS). Изображение может отличаться от вашего случая. Я предполагаю, что у меня все CA будут работать под управлением Windows Server 2008. Для 2003 картинка может отличаться, но суть останется та же. Далее, нас заинтересует вкладка Request Handling:
Здесь нужно поставить галочку напротив Archive subject's encryption private key. Галочка ниже (Use advanced Symmetric algorithm to send key to the CA) используется только для клиентов Windows Vista и выше. Если этим шаблоном будут пользоваться более ранние клиенты, то её выставлить нельзя! И последнее, что явно потребуется:
драйвер токена Alddin eToken Pro для хранения сертификатов EFS на токене требует, чтобы на токене так же был и логонный сертификат, иначе он впадает в дикий ступор :) При использовании Windows Server Standard редакции потребуется 2 сертификата - отдельно на основе шаблона Smart Card Logon и EFS Basic. Т.е. не обязательно, чтобы один сертификат содержал все функции. Т.к. у меня CA работает под управлением Enterprise то я создал один шаблон и в Extensions добавил необходимые политики действия, а именно - добавил Smart Card Logon. Тогда я могу с использованием одного сертификата и аутентифицироваться в домене и шифровать файлы. Официальная документация требует, чтобы в списке CSP провайдеров был указан провайдер смарт-карты (токена), но в моём случае это не обязательно, поскольку при издании сертификата драйвер сам предлагает экспортировать сертификат на токен. Шаблон можно сохранять и назначить его для издания сертификатов:
Certificate Templates -> New -> Certificate Template to issue -> в списке выбрать SM EFS
И последняя часть, которая нам потребуется - указание агента восстановления для EFS.
Примечание: мы выше уже создавали агента восстановления, но у нас будет 2 различных агента восстановления - отдельно для EFS, который будет задан в GPO и агент восстановления ключей из базы CA. Это 2 совершенно разные роли и следует чётко различать назначение каждого агента.
На практике по умолчанию агентом восстановления становится первый администратор первого контроллера домена в лесу Active Directory. В целях безопасности не следует его оставлять как есть. Для этого я создал новую учётную запись с именем Recovery Agent и добавил его в группу EFS Recovery. Более ни в каких группах пользователь не состоит. Чтобы сделать его агентом восстановления нужно сначала разрешить групе EFS Recovery запрашивать сертификат на основе шаблона EFS Recovery Agent:
Я просто добавил право Read и Enroll для группы EFS Recovery. Затем пользователь, член EFS Recovery должен залогониться, запустить оснастку certmgr.msc и выполнить запрос сертификата:
И ему будет предложен шаблон EFS Recovery Agent. Когда сертификат будет выдан, то у меня драйвер токена перехватил запрос и предложил положить сертификат на токен:
и после нажатия на Ok потребуется ввести PIN токена:
Теперь этот сертификат хранится только на токене. В установках по умолчанию для eToken Pro при извлечении токена из USB очищается весь контейнер Personal в Certificate Store. Поэтому когда агент восстановления извлекает токен, то его профиль больше не представляет никакой ценности в плане закрытых ключей, которыми можно восстанавливать EFS файлы. Как известно, при установке смарт-карты или токена в ридер или USB, то происходит копирование ключей с токена в хранилище Certificate Store. Т.к. по умолчанию сертификат шаблона EFS Recovery Agent не публикуется в AD, поэтому агент восстановления должен экспортировать .cer (сертификат с открытым ключом) в папку вручную из программного хранилища. Именно эти сертификаты будут использоваться для шифрования ключей EFS и последующего сохранения в поле DRF.
Далее администратор должен открыть объект групповой политики нужного контейнера и перейти в секцию Encrypting File System, как это показано на рисунке:
Я уже удалил сертификат администратора по умолчанию и добавил сертификат нового агента восстановления EFS, который был сохранён самим агентом в .cer файл.
Примечание: только после этого шага и применения этой политики на все компьютеры контейнера, к которому прилинкована политика данный агент сможет расшифровывать EFS файлы, которые были зашифрованы после этого шага. Все файлы, которые были зашифрованы до этого момента будут недоступны для нового агента восстановления. Этот факт следует учитывать.
Итак, во второй части мы рассмотрели технические вопросы механизмов восстановления, которые включают в себя использование агентов восстановления:
Так же посмотрели почти пошаговый процесс реализации обоих механизмов и показали как агенты восстановления могут защищать свои ключи восстановления сохранив их на внешние криптоконтейнеры - смарт-карты или токены. Мы подготовили базу для восстановления файлов в случае "а если ...". План мероприятий по восстановлению данных должен быть применён и реализован до эксплуатации EFS и цифровых сертификтов в целом. В следующей части я покажу настройки групповых политик для хранения EFS сертификатов пользователей на смарт-картах на примере использования токена eToken Pro, а так же (если объём следующей части позволит) покажу действие агентов восстановления в случае "а если ...".
Читая различные обзоры нововведений в Windows Vista/Windows Server 2008 ловлю себя на мысли, что по сути, кроме маркетинговых сообщений ничего нету. Повальная виртуализация, мифический NAP и многое другое (опять же, сильно отдаёт маркетингом). Хочется спросить человека "а покажите, как вы это реализовали на практике, с какими столкнулись трудностями и прочее". А вот с этим у нас всё несколько труднее, т.к. одних Get The Fucacts будет маловато для технических специалистов (на что в последнее время очень часто сетует Павел Нагаев и я с ним в этом плане согласен). Поэтому как часть программы по техническому образованию специалистов хочу постараться разобрать одно интересное нововведение в Windows Server 2008 - хранение EFS сертификатов на смарт-картах с использованием новой опции групповых политик. Тема (на сколько я посмотрел) не освещена совсем, кроме как небольших статей на TechNet'e. Разбираемый вопрос для многих, к сожалению, останется неактуальным по причине дороговизны решения - смарт-карты - не самое дешёвое удовольствие, но я заметил, что интерес к данному вопросу всё же есть.
Итак, для начала я хотел бы рассказать про общий механизм работы шифрующей файловой системы EFS.
Когда пользователь выставляет галочку на чек-боксе Encrypt contents to secure data и нажимает Ok, то происходит несколько вещей:
Процес шифрования:
Таким образом гарантируется, что доступ к файлу имеет только владелец закрытого ключа пользователя и агент восстановления. В Windows Server 2003 появилась возможность предоставлять шифрованные файлы в общий доступ с другими пользователями. При этом с самим файлом ничего не происходит, а только ключ FEK шифруется открытыми ключами сертификатов тех пользователей, которым разрешён доступ к шифрованному файлу. Именно по этой причине невозможно предоставлять доступ к шифрованному файлу группам - группы не могут иметь сертификатов, а только Security Principals (конкретные участники безопасности, как пользователи и компьютеры). А так же эти пользователи уже должны иметь в базе Active Directory EFS-пригодные сертификаты. Когда я только начал изучать EFS, то не совсем понимал этих требований, пока не начал изучать вопрос более детально и понимать т.н. физику процесса.
Более интересный вариант - шифрование файла в сетевой папке.
В качестве альтернативного варианта был предложен WebDAV, который позволял использовать защищённый SSL канал при передаче файла. Хотя SSL не обязателен, поскольку любые операции шифрования/расшифрования происходили на клиенте локально. При доступе к шифрованному файлу, он в таком же виде пересылался по сети клиенту, где последний локально расшифровывал файл. После работы файл заново локально шифровался и уже в шифрованном виде передавался по сети.
При использовании клиента Windows Vista и сервера Windows Server 2008, то используется механизм, который реализован в WebDAV, а именно - файл шифруется и расшифровывается локально на клиенте и файл по сети передаётся в шифрованном виде как есть. Но, тем не менее, этот механизм не решает вопрос доступа с различных машин к шифрованному файлу. Дело в том, что при логоне пользователя на рабочую станцию ему не подгружаются сертификаты, которые были использованы на других машинах, они никогда не покидают профиль пользователя. Если в домене применён Certificate Autoenrollment, то автоматически запрашивается новый сертификат с новой парой открытый/закрытый ключ и который непригоден для расшифрования ранее зашифрованных файлов. Для этой задачи существует 2 решения:
Процесс дешифрования (расшифровки) файла:
При обращении пользователя к файлу LSA проверяет локальное хранилище Certificate Store на предмет наличия закрытого ключа сертификата EFS. По логике ассиметричного шифрования открытый и закрытый ключ взаимно дешифруют друг друга, что означает следующее:
Используя закрытый ключ EFS сертификата LSA расшифровывает DDF для извлечения FEK, который ранее был зашифрован открытым ключом. После извлечения FEK происходит прямая дешифрация файла. Если же в хранилище Cetificate Store не было обнаруженного ни единого закрытого ключа, который подходил бы любому шифру DDF, то пользовтелю будет отказано в доступе - Access Denied.
При этом стоит отметить, что имя пользователя на сертификате дешифрования совсем не обязан соответствовать залогиненному пользователю. Поэтому нету ограничений на переименование пользователей в процессе.
Примечание: Однако, есть ограничение на смену пароля, а точнее его сброс. Только ленивый не слышал об утилитах, которые сбрасывают пароли локальных и доменных учётных записей, а так же администратор домена или локальной машины может сбрасывать пароли пользователей, тем самым позволяя с новым известным паролем получить доступ к профилю пользователя. Чтобы не допустить потенциальной кражи ключей в EFS заложен механизм зависимости от пароля. Т.е. сам закрытый ключ зашифрован паролем пользователя. Если пароль пользователя будет сброшен, то все данные, которые были зашифрованы пользователем будут утеряны (на самом деле в некоторых случаях это не совсем верно, но в общем смысле - да), поскольку нечем будет расшифровать закрытый ключ. Это справедливо только для сброса пароля. Когда пользователь меняет пароль планово (по сроку изменения пароля заданного в групповых политиках) или внепланово и с указанием предыдущего пароля, то ключи шифрования обновляются (расшифровываются старым паролем и шифруются новым) и после смены пароля доступ к этим файлам не прекращается. Данный механизм описан здесь: http://support.microsoft.com/kb/290260
Какие ещё могут наступить проблемы? А любые проблемы, которые связаны с профилем. Например, был повреждён профиль пользователя и заменён на новый - вы потеряете ключи. Пользователю назначен новый перемещаемый профиль - вы потеряете ключи. А пользователь может сам зайти в свой Certification Store и удалить ключи - вы потеряете ключи. Универсальной панацеи от этого нету - есть только более или менее эффективные средства защиты и сохранности данных и ключей шифрования.
Если пользователь потерял доступ к своим закрытым ключам EFS, то агент восстановления - Recovery Agent может своим ключом расшифровать нужные файлы и пользователь получит к ним доступ в открытом виде. После этого пользователь может заново сгенерированным ключом снова зашифровать данные. Но сами ключи шифрования можно восстановить только одним единственным способом - Key Recovery.
Организация плана защиты, восстановления ключей и восстановления доступа будет рассмотрена во второй части. В принципе, весь этот материал доступно изложен на TechNet'e (http://technet.microsoft.com/en-us/library/cc700811.aspx), но тем не менее, я хочу подвести плавно тему к целевой задаче использования смарт-карт и задач, которые мы сможем решать с их помощью. Ну и для себя немного прояснить материал.