В предыдущих частях мы рассмотрели принципы работы EFS, изучили основные вопросы безопасности и доступности ключей, а так же показали как создавать агентов восстановления файлов EFS и агентов восстановления ключей:
Когда у нас все агенты восстановления подготовлены и подготовлены шаблоны EFS + Smart Card Logon, то необходимо заранее подготовить смарт-карты и выпустить для них сертификаты. Для этого можно воспользоваться консолью MMC - certmgr.msc и выполнить запрос сертификата:
пользователь выполнил запрос сертификата и драйвер предложил сразу положить сертификат на токен. Данную процедуру необходимо проделать для всех пользователей, которые будут шифровать файлы сертификатами и хранить их на смарт-картах. После этого можно приступать к настройке групповой политики:
В Public Key Policies нужно выбрать свойства Encrypting File System и получим такое окно. Здесь у нас появилось много новых настроек, которых раньше не было. Вот скрин этого же окна в Windows Server 2003:
тут мы можем только или разрешить или запретить использование EFS. Пробежимся по настройкам новой консоли:
- Encrypt the contents of the users's Documents folder - при использовании этой опции будет зашифрована вся папка Documents пользователя. Особого смысла в ней не вижу. Но кому-то может пригодиться.
- Require a smart card for EFS - опция, которая позволяет принудительно хранить EFS ключи шифрования на смарт-картах. Если эта опция включена, но смарт-карты не реализованы, то шифрование будет недоступно. Т.к. у нас смарт-карты есть, то выставляем здесь флажок.
- Create caching-capable user key from smart card - данная опция позволяет кэшировать ключи шифрования для обеспечения возможности шифрования при изъятом токене или смарт-карте. Параметры кэширования настраиваются дополнительно на вкладке Cache. Если этот флажок сброшен, то будут действовать настройки кеширования драйвера смарт-карты.
- Enable pagefile encryption - разрешает шифровать файл подкачки. При включении шифрования файла подкачки может замедлиться работа системы и увеличиться нагрузка на систему. Во всяком случае первый раз файл подкачки будет шифроваться достаточно долго.
- Display key backup notifications when user key is created or changed - включает или отключает уведомление пользователя, что его ключ шифрования был создан или изменён.
Чуть ниже мы можем позволить пользователям генерировать самоподписанные сертификаты 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 потребуется выполнить следующие шаги:
- войти в систему под учётной записью, которая имеет право управления Certification Authority (обычно администратор), запустить консоль CMD и в ней выполнить следующую команду:
certutil -getkey 6148fa9e000000000022 %path%\outblob
где 6148fa9e000000000022 - серийный номер сертификата. Его можно посмотреть как в самом сертификате, так и в консоли Certifiaction Authority добавив в показ колонки Serial Number
path%\outblob - путь к выходному BLOB файлу. Вывод команды должен выглядеть примерно так: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. - Вот этот BLOB файл нужно передать (например, по электронной почте или через сервис мгновенных сообщений) пользователю, который в CA является агентом восстановления ключей и чей сертификат находится во вкладке Recovery Agents.
- получив этот файл агент восстановления должен установить смарт-карту или токен в ридер или USB, где находится закрытый ключ от KRA сертификата. Далее ему нужно запустить консоль CMD и в командной строке выполнить:
certutil -recoverkey %path%\outblob user.pfx
где %path%\outblob - путь к BLOB файлу, который был получен на шаге 2
User.pfx - имя PKCS #12 файла, который будет содержать пару из открытого и закрытого ключа пользователя.
Вот так примерно выглядит вывод команды: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. - После успешного расшифрования BLOB файла агенту восстановления будет предложено ввести и подтвердить пароль для .pfx файла, который нужно будет потом ввести при импорте файла в Certificate Store.
- Передать полученный файл пользователю любым доступным способом и сообщить пароль к нему. Не следует и файл и пароль передавать одним путём (например, через почту или Messenger).
Если же ключ был скомпрометирован (была утеряна смарт-карта и есть основания, что PIN известен 2-м и более лицам), то сертификат следует отозвать.
Вот мы и рассмотрели полностью (не скажу, что очень детально, но достаточно сносно для первой хау-ту :) ) вопрос имплементации новой возможности Windows Vista/Windows Server 2008 - хранение и использование ключей EFS на смарт-картах. Осталось рассмотреть только один вопрос - что будет, когда различные сертификаты истекут или будут отозваны, который я постараюсь (если всё получится) осветить в заключительной 4-й части.
Comments: