В предыдущей части мы поговорили об основах работы шифрующей файловой системы EFS и основными трудностями, которые появляются при использовании EFS. И одной из важных задач становится защита ключей шифрования надёжным способом от взлома, но и обеспечить возможность восстановления данных при потере ключей шифрования и их доступность. Я уже отметил, что варианта у нас всего 2 - архивирование ключей на внешний контейнер (например, смарт-карта или USB диск) либо Key Archival, когда закрытые ключи дополнительно хранятся в базе Certification Authority. Причём, оба этих метода можно спокойно совместить. Но здесь Microsoft нас снова "радует" (что вполне ожидаемо) - Key Archival работает только при условии, что:

• Certification Authority (CA) работает под управлением Windows Server 2003/2008 Enterprise/Datecenter Edition.
• CA является Enterprise CA, а не StandAlone CA.
• криптопровайдер (CSP) поддерживает хранение закрытых ключей.

Механизм Key Archival работает следующим образом:

1. Клиент ищет доступный CA в базе AD и устанавливает с ним соединение. При соединении у CA запрашивается сертификат основанный на шаблоне CA Exchange (который используется только для этих целей).
2. Клиент удостоверяется, что сертификат валидный (имя в сертификате соответствует имени CA, срок годности сертификата ещё не истёк и т.д.) и проверяет списки CRL на предмет отзыва этого сертификата. А так же клиент проверяет, что сертификат подписан именно тем CA, с которым он сейчас работает и на имя этого CA. Это гарантирует, что CA сможет расшифровать полученный на последующих этапах шифрованный закрытый ключ.
3. Если с сертификатом всё в порядке, то клиент шифрует сгенерированный закрытый ключ открытым ключом сертификата CA Exchange. Если это клиент Windows Vista/Windows Server 2008, то клиент может шифровать свой ключ новыми алгоритмами CNG (Cryptography Next Generation) и использовать алгоритм AES для шифрования. По сути, Windows XP тоже поддерживает AES, но эта поддержка была внедрена только начиная с SP1 и здесь для Windows XP нету возможности использовать AES.
4. Далее клиент подготавливает полный запрос PKI для CA и этот запрос направляет в CA.
5. CA в свою очередь дешифрует полученный запрос и сверяет соответствие закрытого и открытого ключа в запросе.
6. Если соответствие подтверждено, то CA шифрует полученный закрытый ключ рандомным симметричным ключом с использованием 3DES или AES )(только для ОС Windows Vista и выше).
7. Затем этот симметричный ключ шифруется одним или несколькими открытыми ключами агентов восстановления, которые определены в свойствах CA и которые допущены к архивированию ключей и сохраняет всё это в специальном BLOB (Binary Large Object) формате в своей базе.

Исходя из этой процедуры нетрудно представить процесс восстановления:

1. администратор CA извлекает необходимый BLOB файл из базы CA.
2. Т.к. этот файл зашифрован открытым ключом агента (или агентов) восстановления, то файл передаётся любому допустимому агенту восстановления для дешифрации.
3. агент восстановления использует свой закрытый ключ для дешифрации файла и создаёт .pfx файл, попутно защищая его паролем.
4. .pfx файл затем передаётся конечному пользователю, который у себя на машине импортирует пару из открытого и закрытого ключа в контейнер Certificate Store.

Для начала нам потребуются агенты восстановления, которые будут уполномочены восстанавливать ключи из базы 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 файлы, которые были зашифрованы после этого шага. Все файлы, которые были зашифрованы до этого момента будут недоступны для нового агента восстановления. Этот факт следует учитывать.

Итак, во второй части мы рассмотрели технические вопросы механизмов восстановления, которые включают в себя использование агентов восстановления:

• Key Archival - архивирование всех закрытых ключей пользователей в базе CA, что обеспечивает возможность восстановления ключей шифрования с минимальными затратами по восстановлению нормальной работы шифрованных файлов.
• EFS Recovery Agent - в контексте обсуждаемого вопроса применили агента восстановления EFS файлов без необходимости восстановления ключей из базы CA. Тем более Key Archival в ряде случаев будет невозможен для применения.

Так же посмотрели почти пошаговый процесс реализации обоих механизмов и показали как агенты восстановления могут защищать свои ключи восстановления сохранив их на внешние криптоконтейнеры - смарт-карты или токены. Мы подготовили базу для восстановления файлов в случае "а если ...". План мероприятий по восстановлению данных должен быть применён и реализован до эксплуатации EFS и цифровых сертификтов в целом. В следующей части я покажу настройки групповых политик для хранения EFS сертификатов пользователей на смарт-картах на примере использования токена eToken Pro, а так же (если объём следующей части позволит) покажу действие агентов восстановления в случае "а если ...".