В поисках безопасности. Развертывание файловой системы EFS: Часть 1.
На сегодняшний день уже каждый слышал сообщения о том, как личные или конфиденциальные данные были утрачены из-за кражи или потери портативного компьютера. Портативные компьютеры пропадают постоянно. С ростом числа хищений личных данных и при более чем когда-либо высокой важности соблюдения нормативных требований тщательная защита данных на мобильных компьютерных системах крайне важна.
Одним из решений является использование файловой системы EFS (Encrypting File System — шифрованная файловая система), включенной в систему Windows® начиная с версии Windows 2000 и обеспечивающей встроенное высокоэффективное шифрование диска. Система EFS тесно интегрирована с проводником Windows, так что конечные пользователи часто даже не знают, что используемый ими файл зашифрован. Кроме того, система EFS работает одинаково хорошо с собственными технологиями проверки подлинности и контроля доступа системы Windows, так что пользователям не нужно запоминать для доступа к своим данным отдельные пароли. И, наконец, система EFS обеспечивает удобные варианты восстановления данных в случае потери пользователем доступа к своим ключам шифрования (например в случае удаления или повреждения профиля пользователя либо в случае потери смарт-карты).
Для генерирования, хранения и развертывания ключей криптостойкого шифрования для защиты данных в системе EFS используется встроенная в систему Windows технология шифрования. В операционной системе Windows XP с пакетом обновления 1 (SP1) и в более поздних версиях операционной системы для шифрования данных на диске в файловой системе EFS используется алгоритм стандарта AES (Advanced Encryption Standard — улучшенный стандарт шифрования) с 256-разрядным ключом. Эти симметричные ключи затем защищаются ассиметричной (RSA) парой ключей. В системе EFS каждый файл шифруется своим собственным ключом AES, затем этот ключ шифруется пользовательским ключом RSA и результат сохраняется в файл. Дополнительную информацию о шифровании файловой системы EFS см. в статьях, приведенных на боковой панели «EFS Resources» (Источники информации о файловой системе EFS). А пока уделим основное внимание не техническим основам системы EFS, а тому, как развернуть эту систему и сделать ее применимой в пользовательской среде. По этой причине отметим, что данная статьи предполагает наличие предварительных знаний концепций шифрования файловой системы EFS.
Примечание о безопасности системы EFS
Утверждается, что некоторые приложения способны взломать или раскрыть шифрование системы EFS. Ни одно из приложений фактически не может расшифровать зашифрованные с помощью алгоритма стандарта AES (или стандарта шифрования данных DES либо расширенного стандарта шифрования данных DESX) данные, а скорее может только получить доступ к закрытому ключу EFS пользователя путем грубого взлома пароля пользователя. В отношении шифрования системы EFS важно помнить, что используемые для генерирования и защиты зашифрованных данных закрытые ключи используют интерфейс DPAPI (Data Protection API — прикладной программный интерфейс защиты данных). Интерфейс DPAPI использует для защиты данных производные от учетных данных пользователя, поэтому конечный результат защиты данных с помощью системы EFS будет настолько надежным, насколько надежен пароль пользователя. С появлением ОС Windows Vista™ стало возможным хранение сертификатов шифрования системы EFS на смарт-картах, что изменяет эту парадигму и значительно повышает относительную безопасность данных, защищенных файловой системой EFS.
Насколько длинным должен быть пароль, чтобы обладать устойчивостью к таким атакам? С учетом возможностей современных аппаратных средств и существующих сейчас алгоритмов атак на пароли рекомендуется использовать пароль (или точнее фразу-пароль), состоящий из 11 или более символов. Фраза-пароль из 11 или более символов является очень стойкой к самым передовым на сегодняшний день методам, включая атаки с использованием предварительно вычисленной хэш-функции (например атака Rainbow Table; дополнительную информацию см. в публикации «Why you shouldn't be using passwords of any kind on your Windows networks» (почему не нужно использовать пароли в некоторых сетях Windows) (на английском языке), ссылка на которую приведена на боковой панели «Resources» (Источники информации)).
Нужна или не нужна инфраструктура открытых ключей (PKI)?
Одним из наиболее распространенных неправильных представлений о системе EFS является мнение, что для ее работы требуется наличие инфраструктуры PKI (public key infrastructure — инфраструктура открытых ключей). Хотя система EFS легко интегрируется с существующей в организации инфраструктурой PKI и использует ее преимущества, наличие инфраструктуры PKI отнюдь не является обязательным требованием. С другой стороны, решение о том, использовать инфраструктуру PKI в своем варианте развертывания системы EFS или нет, влияет на многие будущие решения, касающиеся развертывания, поэтому этот вопрос следует исследовать первым.
Главное преимущество использования с системой EFS инфраструктуры PKI заключается в возможности выполнять архивирование и восстановление ключей. Несмотря на то, что используемая отдельно система EFS позволяет администратору выполнять восстановление данных, автоматическое восстановление ключей возможно только при наличии инфраструктуры PKI, при этом в качестве центра сертификации (CA) должна использоваться операционная система Windows Server® 2003 Enterprise Edition. Восстановление данных — это процесс, в ходе выполнения которого потерявший доступ к своему ключу шифрования пользователь может предоставить свои зашифрованные данные назначенному администратору, называемому агентом DRA (Data Recovery Agent — агент восстановления данных), который может либо расшифровать эти данные и вернуть пользователю, либо повторно зашифровать их для использования с новым закрытым ключом. Агент DRA дублирует процесс шифрования пользователя, в результате чего все, что пользователь шифрует с использованием своего ключа, также шифруется с использованием копии ключа агента DRA. Таким образом, если ключ пользователя потерян, может вмешаться агент DRA, взять зашифрованные данные, применить к ним для расшифровки (или повторного шифрования) ключ агента DRA и затем вернуть данные пользователю. Подход с использованием агента DRA работает хорошо, но может быть сложен в управлении, если пользователь зашифровал большие объемы данных или если отсутствуют местные ИТ-специалисты, которые могут выступать в качестве агентов DRA.
Восстановление ключа, с другой стороны, требует создания центром сертификации копии шифровального ключа пользователя в процессе создания этого ключа, а затем безопасного хранения копии ключа в базе данных центра сертификации. Если пользователь вдруг потеряет доступ к зашифрованным файлам, администратору центра сертификации необходимо только войти в эту базу данных и извлечь ключ пользователя. В этот момент пользователь немедленно вновь получит доступ к своим данным, и необходимости в восстановлении данных агентом DRA не будет. При использовании такого способа восстановление ключа может быть более быстрым и эффективным. Однако обратите внимание на то, что в качестве резервного варианта на случай потери ключей всегда рекомендуется иметь агентов DRA, даже если используется восстановление ключей. Это также позволяет крупным организациям иметь распределенную систему восстановления, при которой ИТ-администраторы могут восстанавливать данные пользователей и при этом вообще не обращаться к группе администраторов инфраструктуры PKI.
Еще одним потенциальным преимуществом использования инфраструктуры PKI с системой EFS является упрощение совместного использования зашифрованных файлов. Вспомните, что использование системы EFS не ограничивается только портативными компьютерами; эта файловая система может быть столь же ценной в любой ситуации, когда физическая безопасность компьютера не может быть гарантирована. В таких ситуациях может возникнуть необходимость в доступе нескольких пользователей к одним и тем же зашифрованным данным. Хотя поддержка системой Windows совместного использования зашифрованных файлов несколько ограничена, потому что позволяет совместно использовать только отдельные файлы, а не каталоги, данная поддержка может быть полезным средством. Для облегчения совместного использования файлов системы EFS пользователь, который организует совместное использование файла, должен иметь доступ к открытым ключам других пользователей, получающих доступ к этому общему файлу (что проще всего реализовать, если эти пользователи имеют действительные сертификаты системы EFS, опубликованные в их учетных записях в службе каталогов Active Directory®). Хотя это опубликование и можно выполнять вручную, использование центра сертификации системы Windows, установленного в корпоративном режиме (интегрированного в службу Active Directory), делает данный процесс полностью автоматическим.
Управление ключами системы EFS
При наличии готовой к использованию инфраструктуры открытых ключей на основе ОС Windows Server 2003 процесс генерирования пользовательских сертификатов системы EFS является несложным. Центр сертификации системы Windows Server 2003 поставляется с предоставляемым по умолчанию набором шаблонов сертификатов, включая шаблон Basic EFSBasic EFS (Базовое шифрование EFS). Однако этот шаблон является шаблоном версии 1 и не поддерживает архивирование ключей. Поэтому прежде чем делать его доступным в своем центре сертификации, нужно создать копию этого шаблона для создания нового шаблона версии 2 (его, например, можно назвать EFS with Key ArchiveEFS with Key Archive (EFS с архивом ключей), как показано на рис. 1). В этом новом шаблоне перейдите на вкладку Request HandlingRequest Handling (Обработка запросов) и установите флажок архивирования ключей шифрования пользователей. Обратите внимание на то, что прежде чем включать этот параметр, необходимо правильно настроить архивирование ключей в центре сертификации. В раздел источников информации включено отличное подробное описание этого процесса. Вам также следует заместить этим шаблоном шаблонBasic EFS Basic EFS (Базовое шифрование EFS), чтобы гарантировать использование клиентами этой новой версии (см. рис. 2).
Затем необходимо установить для шаблона соответствующие права, чтобы предоставить доступ для подачи заявок нужной совокупности пользователей. Так как компонент EFS в системе Windows автоматически запрашивает сертификат при первом использовании системы EFS, обычно нет необходимости разрешать пользователям автоматическую подачу заявок для шаблона EFS. Фактически, я бы не рекомендовал включать автоматическую подачу этих заявок, если нет уверенности в том, что все автоматически подающие заявки пользователи будут использовать систему EFS. На рис. 3 показаны настройки подачи заявок на сертификаты EFS. Выдавая сертификаты пользователям, которые, возможно, никогда не будут пользоваться системой EFS, вы бесполезно увеличиваете размер базы данных центра сертификации. Хотя размер самой базы данных центра сертификации не ограничен, но по мере увеличения количества выдаваемых сертификатов управление этой базой данных может усложняться (в частности, через консоль управления MMC).
Рис. 3. Настройка прав пользователей системы EFS
И, наконец, если необходима поддержка совместного использования зашифрованных файлов, следует обеспечить автоматическую публикацию сертификатов пользователей в службу каталогов Active Directory центром сертификации.
При правильной настройке шаблона центра сертификации когда пользователь впервые попытается зашифровать файл с помощью системы EFS, ему центром сертификации будет выдан сертификат, а его закрытый ключ будет автоматически помещен в архив.
Управление ключами агентов DRA
Следующий вопрос, который необходимо продумать при наличии инфраструктуры PKI, заключается в том, использовать или нет генерируемые центром сертификации сертификаты агентов DRA. В каких случаях не стоит использовать сертификаты агентов DRA из инфраструктуры PKI? Представьте ситуацию, когда имеется центр сертификации с собственным краткосрочным сертификатом (на два года или меньше). Этот центр не сможет выдавать сертификаты со сроком действия, превышающим его собственный, а это значит, что сертификаты агентов DRA будут иметь срок действия два года (или меньше). Это может привести к значительно более сложной схеме восстановления данных. Этот гипотетический пример иллюстрируется следующей ситуацией.
• Пользователь шифрует файл в январе 2006 г. Сертификаты агентов DRA, опубликованные на машину пользователя через групповую политику, имеют срок действия два года (истекают в январе 2008 г.). • Пользователь продолжает работать с системой EFS, шифруя новые файлы. • В январе 2008 г. срок действия сертификатов агентов DRA истекает, и администратор через групповую политику публикует на машину пользователя новые сертификаты. • При выполнении любых операций по шифрованию с этого момента будут использоваться новые сертификаты агентов DRA (включая любые файлы, открываемые пользователем, которые были зашифрованы с использованием старых сертификатов агентов DRA; при их сохранении используются новые сертификаты DRA), но все файлы, которые пользователь не трогает, будут оставаться защищенными старыми сертификатами DRA. • Пользователь случайно повреждает свой профиль и нуждается в восстановлении данных. • В этой ситуации ИТ-администратор должен иметь два комплекта сертификатов DRA: новые для файлов, с которыми пользователь работал после этапа 3, и старые для файлов, с которыми пользователь после этого не работал.
Хотя ИТ-администратор может запустить после этапа 3 сценарий, обновляющий все файлы новым агентом DRA (с помощью команды cipher.exe /u), этот процесс может потребовать много времени. Кроме того, для ясности, пара ключей агента DRA не становится бесполезной после истечения срока действия, хотя компонент EFS и не позволит выполнять новые операции по шифрованию, если в его политику восстановления включен сертификат агента DRA, срок действия которого истек. Старые файлы, зашифрованные с использованием пары ключей DRA, срок действия которых истек, конечно же, могут быть восстановлены с использованием этих ключей. Следовательно, пары ключей агентов DRA никогда нельзя удалять, даже если их срок действия истек. Невозможно предсказать, когда они понадобятся.
По этой причине я рекомендую задействовать в средах с центрами сертификации, имеющими короткий срок действия собственного сертификата, самозаверяющиеся сертификаты DRA с более длительным сроком действия. Служебная программа шифрования включает параметр (cipher.exe /r), который автоматически создает пары ключей агентов восстановления данных системы EFS, имеющие срок действия 100 лет (см. рис. 4). Сертификат из этой пары ключей может быть прикреплен к объектам GPO (Group Policy Object — объект групповой политики) и использован в качестве агента DRA в рамках всей организации. Так как компонент EFS не проверяет цепочку доверия сертификатов DRA, эти самозаверяющиеся сертификаты будут работать без внесения каких-либо изменений в список доверенных корневых центров сертификации соответствующих систем. Независимо от срока действия центра сертификации организации, я всегда рекомендую создавать хотя бы один сертификат агента DRA длительного действия и присоединять его к объекту GPO, примененному ко всему домену. Это резервный вариант восстановления данных, которым можно будет воспользоваться, если все другие варианты не сработают. Это особенно актуально в случае использования генерируемых центром сертификации ключей агентов DRA при отсутствии архива ключей центра сертификации. Если сертификат DRA в какой-либо момент подвергнется риску, можно будет обновить GPO, присоединив новый сертификат, и воспользоваться для обновления файлов командой cipher.exe /u, как это обсуждалось выше.
Рис. 4. Выполнение команды Ciquer /R
Источники информации о системе EFS Большое количество дополнительной информации о системе EFS и практических рекомендаций можно найти на следующих веб-узлах: (на английском языке)
Развертывание агентов KRA и DRA
Архивирование ключей обеспечивает администраторам центров сертификации возможность восстанавливать депонированные ключи шифрования для пользователей. Конечно же, это очень мощная возможность, затрагивающая конфиденциальность, потому что она позволяет администратору центра сертификации расшифровывать любые данные организации, которая использует ключи, подписанные этим центром сертификации. Таким образом, с архивированием и восстановлением ключей следует обращаться очень осторожно, и только очень небольшому кругу заслуживающих доверия сотрудников службы безопасности должно предоставляться соответствующее право. Так как операция восстановления ключей затрагивает конфиденциальность, то при желании использовать этот метод в качестве основного механизма восстановления доступа к зашифрованным с помощью системы EFS данным важно направить группе администрирования центра сертификации четко определенный процесс передачи запросов о восстановлении по инстанциям. Процесс восстановления должен инициироваться только после тщательной проверки таких запросов. Затем после фактического восстановления ключа он должен предоставляться пользователю безопасным методом (не по электронной почте), так как восстановленный ключ обеспечивает доступ ко всем защищенным с помощью системы EFS данным пользователя.
Ключи агента KRA (Key Recovery Agent — агент восстановления ключей) генерируются и хранятся администраторами центра сертификации, эти ключи не распространяются через групповую политику. Фактически, даже сама система EFS не может определить, был ли используемый ею ключ скопирован в архив, а просто выполняет операции шифрования, как и полагается этой системе. Кроме того, созданные в центре сертификации ключи KRA никоим образом не являются предназначенными специально для системы EFS. К центру сертификации, в котором используется архивирование ключей, будет присоединено на уровне центра сертификации n ключей KRA, которые будут использоваться для защиты любых архивируемых центром сертификации ключей. К числу таких ключей относятся ключи, используемые для системы EFS, защиты электронной почты или для любого другого сертификата, включающего шифрование. Ключи KRA должны храниться с соблюдением мер безопасности лицами, являющимися агентами восстановления ключей, а для обеспечения наличия резерва на случай утраты одного из ключей таких ключей должно быть не меньше двух.
При первом входе администратора в систему контроллера вновь созданного домена на уровне домена по умолчанию создается политика восстановления с использованием самозаверяющегося сертификата и пары ключей, хранящихся в профиле администратора на контроллере домена. Этот сертификат DRA будет иметь срок действия три года. Рекомендуется удалить этот сертификат по умолчанию и заменить его самозаверяющимся сертификатом с большим сроком действия или сертификатом, выданным инфраструктурой PKI. Если не удалить этот создаваемый по умолчанию самозаверяющийся сертификат, то через три года после его создания система EFS перестанет шифровать новые файлы по всему домену. Это связано с тем, что срок действия сертификата истечет, и система EFS будет препятствовать шифрованию данных, если в ее политику восстановления будет включен сертификат DRA с истекшим сроком действия. Хотя системой Windows XP и более поздними операционными системами можно пользоваться без политики агента восстановления, это настоятельно не рекомендуется. Такое пользование означает, что в случае утраты по какой-либо причине пользователем доступа к своему ключу шифрования и при отсутствии возможности восстановить этот ключ, все данные этого пользователя будут безвозвратно утрачены.
Как уже отмечалось, ключи DRA могут быть либо самозаверяющимися, либо выданными центром сертификации. В большинстве случаев лучше всего применять смешанный подход, когда в качестве запасного варианта в рамках всего предприятия используется не менее двух самозаверяющихся сертификатов DRA с длительным сроком действия. Так как сертификаты DRA разворачиваются через объекты групповой политики (GPO), они, как и другие объекты GPO, обладают возможностями наследования. Иными словами, стандартный алгоритм накопления и применения локальных объектов групповой политики, объектов групповой политики узлов, доменов и подразделений, управляющий применением других настроек объектов групповой политики, также применяется и к агентам DRA. Таким образом, организация может легко реализовать разделенный на уровни подход к агентам DRA, при котором центральная ИТ-группа имеет доступ к агентам DRA для всего предприятия, а локальные ИТ-группы обладают возможностями в отношении своих конкретных зон ответственности. Это особенно ценно для больших, территориально разбросанных организаций, так как снижает потребность в передаче больших объемов зашифрованных данных по каналам глобальной сети для облегчения восстановления данных. На рис. 5 показано типовое развертывание агентов DRA при наличии нескольких уровней.
Рис. 5. Многоуровневое развертывание агентов DRA
В этом случае пользователь из подразделения Baton Rouge в итоге имеет для каждого зашифрованного файла шесть агентов DRA: два от своих локальных администраторов, два от североамериканской ИТ-группы и два от уровня домена. Следовательно, если пользователь потеряет доступ к своим зашифрованным данным, ему их может восстановить локальный агент DRA в Baton Rouge или член североамериканской ИТ-группы. В крайнем случае, если эти четыре агента DRA будут недоступны или утрачены, заняться этим вопросом и восстановить данные могут агенты DRA уровня домена. Независимо от того, какой агент DRA выполнит восстановление, этот процесс будет практически одинаковым. Пользователь сначала сделает данные доступными агенту DRA. Важным моментом является обеспечение агентом DRA необходимых мер, направленных на проверку законности данного запроса и того, что этот запрос поступил от истинного владельца данных. После этого агент DRA загружает сертификат DRA, расшифровывает (и, желательно, повторно зашифровывает) данные, а затем отправляет эти данные обратно конечному пользователю. Некоторые организации также предпочитают выполнять локальное восстановление, когда агент DRA физически посещает пользователя, у которого возникли проблемы, загружает свою пару ключей агента DRA в профиль и расшифровывает данные, после чего удаляет свою пару ключей. Пользователь получает доступ к незашифрованным данным и может повторно зашифровать свои данные с помощью нового ключа. Необходимо отметить, что этот подход является намного менее надежным, потому что пара ключей агента DRA копируется (хотя и временно) на локальную машину, но это может сэкономить некоторое количество времени, особенно в том случае, когда необходимо восстановить большой объем данных.
Обратите внимание на то, что если восстановление обеспечивается пользователю посредством архивирования и восстановления ключа, то запрос о восстановлении должен обрабатываться совершенно независимо от этого процесса. Вместо использования агента DRA запрос пользователя о восстановлении ключа должен поступать администраторам центра сертификации, которые должны выполнить по этому запросу проверку, затем обратиться к архиву и восстановить закрытый ключ пользователя. Затем они должны безопасным методом предоставить этот закрытый ключ пользователю, например поместив его на безопасный веб-узел для загрузки пользователем. (Если пользователь для хранения ключа системы EFS пользуется смарт-картой, что возможно в ОС Windows Vista, то этот ключ также должен быть выдан повторно.) Пользователь загрузит данный ключ в свой профиль и сразу получит доступ ко всем своим зашифрованным данным.
Так как пары ключей агентов DRA и KRA могут использоваться для расшифровки конфиденциальных данных, важно обеспечить их надлежащую защиту. Пары ключей агентов DRA и KRA не должны храниться в нормальных профилях администраторов на настольных системах (в профилях, которые они используют для выполнения своих повседневных задач). Напротив, эти пары ключей должны безопасно сохраняться на автономный накопитель, например на дискету, оптический или флэш носитель, и храниться в физически защищенном месте. Затем, если необходимо выполнить восстановление, агент восстановления может загрузить соответствующую пару ключей с этого накопителя на восстанавливающую данные рабочую станцию, выполнить операцию восстановления и удалить эту пару ключей. В некоторых наиболее чувствительных к обеспечению безопасности организациях для восстановления отведены специальные выделенные рабочие станции, что позволяет дополнительно повысить защищенность этих пар ключей, но это требование не является обязательным для всех организаций.
В следующем выпуске
Теперь, после рассмотрения процессов управления ключами, восстановления данных и планирования системы EFS со стороны службы Active Directory, во второй части этой темы, которая выйдет в следующем месяце, основное внимание будет уделено вопросам развертывания системы со стороны клиента. В ней будут рассмотрены такие темы, как управление использованием системы EFS через групповую политику, отбор данных для шифрования, автоматическое шифрование данных посредством сценариев входа, а также улучшения проводника Windows со стороны клиента, предназначенные для дальнейшего упрощения работы с защищенными системой EFS данными.
---------------------------------------------------------------------------------------- Джон Морелло (John Morello) с отличием окончил университет штата Луизиана и в течение шести лет работает на различных должностях в корпорации Майкрософт. Работая в должности старшего консультанта, он разрабатывал решения в сфере безопасности для предприятий, входящих в рейтинг Fortune 100, а также для клиентов из гражданских и оборонных федеральных ведомств. В настоящее время является руководителем программы в группе по разработке операционной системы (ОС) Windows Server, занимающейся вопросами обеспечения безопасности и технологиями удаленного доступа.
