Читая различные обзоры нововведений в 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), но тем не менее, я хочу подвести плавно тему к целевой задаче использования смарт-карт и задач, которые мы сможем решать с их помощью. Ну и для себя немного прояснить материал.
Все так. Маленькое дополнение: вместо смарт-карт могут использоваться другие носители. Например eToken. Несколько дешевле и поимо самого "свистка" и USB разъема никакого железа не нужно. Правда, и для контроля физического доступа уже не поиспользуешь. =)
Кстати говоря, я и использую Aladdin eToken. В любом случае это криптоконтейнеры, которые отличаются лишь размерами и разъёмами. Таки, я считаю их более удобными (вряд ли менее безопасными), чем стандартные смарт-карты в виде карточки.
И я же об этом: дело в конкретной ситуации и удобстве. У карт есть неоспоримое преимущество, как я уже говорил, в виде возможностей интеграции: с СКД, пропусками на стоянку, кредитной картой и удостоверением кормящего пенсионера =))) Преимущество eToken - отсутствие дополнительных требований по железу. В общем, за все нужно платить по-любому =) Мы в свое время остановились на смешанном решении: карты для СКД, токены для аутентификации и прочего. В итоге нет необходимости каждому выдавать карт ридер, но все таскаются и со смрт картой и с токеном. В MS, насколько я знаю, все на смарт картах. А некоторые довольствуются пустым паролем... =)
Выбор смарт-карты или токена - это уже отдельный вопрос. Это скорее организационный вопрос, нежели технический. Технически что смарт-карта, что токен - одно и то же.
Согласен. Опять драться не будем. ;)
Кстати говоря, есть eTokens с RFID метками, так что интеграция с СКД уже не проблема :)
"Для решения этой задачи Windows CA (будь то Standalone или Enterprise CA и CA может работать под управлением любой версии Windows Server)" Вадим, а разве токенами можно пользоваться со standart редакцией сервера? Там ведь нельзя модифицировать шаблоны, следовательно нельзя и crypto service provider поменять на aladdinовский например.
а где вы это нашли? Я в этом посте не упомниал про редакции Windows Server.
Дико извиняюсь, хотел прокомментировать соседний пост http://www.sysadmins.lv/PermaLink,guid,7c130407-4d6a-40a1-8090-8dae07e26353.aspx
Тогда давайте, вы напишите туда комментарий, а я отвечу. Поскольку ваш вопрос не относится к данному посту, здесь я ничего отвечать не буду.
Comments: