Как только человек научился выражать свои мысли в письменном виде, у него появилась потребность скрывать записанную информацию от любопытных глаз. Информация со временем менялась, от местоположения полянки на которой растут огромные грибы, до технической документации по новейшему истребителю-бомбардировщику, но требования по её защите оставались. Решались они разными путями, наиболее надёжным из которых считаются толстые двери и надёжные замки, подкреплённые охраной из здоровых и надёжных головорезов, вооружённых до зубов, которые следят друг за другом и окружающими, и понятия не имеющими что именно они охраняют. Для пущей гарантии, всё это можно подкрепить различными техническими устройствами, совершенство которых ограничивается только уровнем развития техники на тот момент, от арбалетов-самострелов и потайных рычагов и кнопок, до автоматических турелей с крупнокалиберными пулемётами и систем контроля основанных на биометрических параметрах.
Однако, подобные меры доступны только богатым организациям, для охраны очень ценной информации. А что делать обычным людям, которые не готовы выкладывать дикие деньги за охрану своей информации, но, тем не менее, имеют что прятать от любопытных глаз. Единственный выход это сделать так, что если злоумышленник и сможет добыть интересующий его материал, исключить возможность для него им воспользоваться. В то же время, законный хозяин должен иметь возможность прочитать свои данные когда ему будет угодно. Один из методов, который может защитить данные без огромных затрат, это шифрование. В современном мире шифрование используется достаточно широко, и в самых различных видах, от примитивной перестановки букв в определённом порядке, чем иногда пользуются школьники передавая друг-другу "тайные" записки, до весьма изощрённых, используемых организациями посерьёзнее. С появлением Windows2000 Microsoft решил предоставить пользователям возможность достаточно серьёзного шифрования. Тот же алгоритм шифрования, практически без изменений, перекочевал и в Windows XP.
Шифрование встроено в операционную систему, шифруется всё просто, работает очень быстро, но достаточно надёжно. В этом и кроются свои подводные камни, и иногда пользователи не понимающие того как это работает вместо того чтобы сохранить, безвозвратно теряют свои данные. Между тем, если немного позаботиться заранее, то можно полностью обезопасить себя от этого, и иметь возможность восстановить свои данные даже после полного краха системы. Функции шифрования доступны в Windows 2000 всех видов, и в Windows XP начиная с Professional. Windows XP Home Edition шифрование не поддерживает. Реализация шифрования одинакова, как в W2k так и в WinXP поэтому описание алгоритма по которому существляется шифрование подходит для обоих ОС. Но в XP изменилась системная политика по отношению к шифрованным файлам, с целью сделать шифрование более безопасным, поэтому процедур восстановления зашифрованных файлов в XP изменилась. Но, всё по порядку. Начнём с того что снаружи, о есть что видно пользователю.
Что видит пользователь.
Встроенные в ОС функции шифрования можно задействовать только на дисковых разделах отформатированных под NTFS. Другие файловые системы, доступные из под W2k/WinXP шифрование не поддерживают. Но если это условие соблюдено, то зашифровать что-нибудь элементарно. Для этого достаточно открыть Properties файла или папки (через правую кнопку мыши), нажимаем на кнопку Advanced, и в открывшемся окне ставим галочку в чекбоксе "Encrypt content to secure data".
Два раза нажимаем на OK, в каждом из открытых окно, и дело сделано. Теперь, если открыть это же окно ещё раз, станет доступной кнопка Detail, нажав на которую можно увидеть ещё одно окно:
С его помощью можно добавить, кто ещё из зарегистрированных на машине пользователей может пользоваться зашифрованным файлом (эта функция доступна только в WinXP, поэтому пользователям W2k искать её не стоит). Если пользователя которого вы хотите добавить нет в списке возможных, это значит что он не имеет соответствующего сертификата и ключа. Зашифруйте этим пользователем хоть один файл или папку, после чего попробуйте ещё раз, нужный пользователь должен появится. Разрешая другим пользователям пользоваться зашифрованными файлами не забывайте, что таким образом вы предоставляете ему тот же уровень контроля над шифрованием файла, который имеете сами. То есть, он получает возможность добавлять или удалять пользователей, которые имеют доступ к файлу, а при желании сможет расшифровать файл (для чего требуется просто снять галочку в чекбоксе Encrypt content to secure data). Если после этого он зашифрует его заново, из под своей учётной записи, то вы потеряете доступ к собственному файлу. Ещё в этом окне показывается имя "Encrypted Data Recovery Agent" который, в случае чего, сможет восстановить файл. Но, я несколько забегаю вперёд.
Для пользователей которым не хватает возможностей по управлению функциями шифрования, предоставляемых Windows Explorer, есть утилитка для командной строки, под названием "cipher". Справку по этой команде можно получить набрав в командной строке cipher /?.
Для пользователя имеющего все права для доступа к зашифрованному файлу работа с ним абсолютно прозрачна, и ничем не отличается от работы с любым другим файлом, расшифровка и шифрование производятся на лету. Но если содержимое зашифрованного файла попытается прочитать пользователь не имеющий на это право, то всё что он увидит это сообщение о том, что в доступе к файлу отказано. Однако, не стоит обманывать себя, пользователь будет иметь такой доступ к файлу, какой ему предоставит файловая система, поэтому если вы не позаботитесь о том, что бы выставить соответствующие разрешения на доступ средствами NTFS, то у пользователя будет возможность манипулировать вашим файлом. То есть, он не сможет прочитать его содержимое, но сможет его переименовать, переместить, или просто стереть.
Хотя не всё так просто. Даже владелец файла, который имеет полные права на пользование файлом, при работе с зашифрованными данными вынужден подчинятся некоторым ограничениям. Ограничений всего два, но в сочетании они дают достаточно много других вариантов. Первое, что стоит помнить при работе с зашифрованными файлами, это что хранится они могут только на NTFS разделах. Второе, это что файл может быть либо зашифрован, либо сжат средствами файловой системы, но не то и другое одновременно. Кроме этих двух ограничений, надо помнить пару правил: любой файл попавший в зашифрованную папку автоматически шифруется, и таким остаётся, даже после того как покинет эту папку. Второе правило гласит, что атрибут шифрования имеет больший приоритет, чем атрибут сжатия. Таким образом получается, что копируя зашифрованный файл с NTFS раздела куда-либо ещё, файл расшифровывается. Если пользователь не может расшифровать файл, то он не сможет и скопировать его на не-NTFS раздел, даже если у него есть полные права доступа к файлу, и он может делать с ним что угодно на NTFS разделе. Кроме этого, из этих правил и ограничений следует, что если скопировать сжатый файл в зашифрованную папку, он автоматически декомпрессируется и зашифруется. В то же время, если скопировать зашифрованный файл в сжатую папку, то он останется неизменным, не сжатым, но зашифрованным. Если поместить незашифрованный файл в зашифрованную папку, то файл автоматически зашифруется, и останется зашифрованным даже в том случае, если его переместить из зашифрованный папки куда-либо ещё.
В общем, помня об этих правилах можно точно предсказать, что случится с сжатым или зашифрованным файлом если произвести с ним то или иное действие. Не смотря на простоту таких правил, достаточно часто можно встретить непонимание этих моментов, когда речь заходит о чуть более сложных примерах. Поэтому рассмотрим ещё один пример.
Если пользователь А зашифрует папку, а пользователь В поместит в неё свой файл, то файл автоматически зашифруется. Но зашифруется с ключом пользователя В, который поместил файл в папку, а не с ключом пользователя А, зашифровавшего папку. Пользователь A сможет переименовать или переместить этот файл, но он не сможет прочитать или расшифровать его. Он не сможет сделать копию с этого файла, так как при этом система попытается зашифровать файл с ключом пользователя А, что не удаться, потому что файл уже зашифрован с ключом пользователя В, и его надо сначала расшифровать. Пользователь В, в свою очередь, не сможет снять атрибут Encrypted со всей папки, потому что зашифрована она с ключом пользователя А, но он сможет снять такой атрибут со своего файла, который лежит в этой папке, и оставить не зашифрованный файл в зашифрованной папке. Если после этого кто-нибудь из пользователей (А, С, не важно) сделает копию с этого файла внутри этой папки, то копия файла автоматически зашифруется с ключом этого пользователя. И, наконец, пользователь А может в любой момент снять атрибут Encrypted с папки зашифрованой с его ключом, но это не окажет никакого влияния на находящиеся в папке файлы, как зашифрованные пользователем А, так и кем-либо другим. Если добавить в этот пример возможность для пользователей XP разрешать любому другому пользователю, по выбору, пользоваться своими шифрованными файлами, то всё становится ещё запутаннее. Впрочем, я надеюсь, что приведённых выше примеров и объяснений хватит для того, что бы читатель мог абсолютно чётко прогнозировать, что случится с его файлами при использовании тех или иных функций шифрования в W2k/WinXP. Остаётся дать несколько советов, которые помогут использовать шифрование более эффективно. Наиболее часто встречающаяся ошибка, которую совершают пользователи желающие защитить свои файлы, это шифрование всего одного файла который, собственно, и защищается. Однако, зачастую этого недостаточно. В процессе работы ваши файлы вполне могут оказаться и в других местах, таких как TEMP или TMP папки. Кроме этого, некоторые программы (например Microsoft Office) при работе делают временные копии файлов с которыми работают в той же директории, где находится и оригинальный файл. Задумано это с благой целью, в случае с Microsoft Office, например, эти копии используются для восстановления файлов случае сбоя. Но эти копии не шифруются автоматически, поэтому ваши документы вполне могут оказаться прочитанными не теми, кем вам хотелось бы. Что бы этого не случилось, я советую вам шифровать не отдельные файлы, а директории где они хранятся. Кроме этого, не забудьте зашифровать и TEMP папку. Этим вы обезопасите себя, и если какие-либо временные файлы или копии ваших данных или документов будут создаваться, они будут автоматически зашифрованы. Это что касается внешней стороны, видимой для пользователя. Но для полного понимания всех потенциальных проблем, которые могут возникнуть при использовании шифрования в W2k/WinXP, что бы знать чего стоит и чего не стоит ожидать от шифрования, не обойтись без того, что бы рассмотреть как работает шифрование "изнутри". Эта информация необходима и для того, что бы знать как решать проблемы возникающие с шифрованием. Наиболее часто встречающейся из которых является потеря информации в результате техногенных "катаклизмов", от которых не гарантирован ни один компьютер, или в результате ошибок пользователя, от которых не гарантирован ни один из читателей.
Как это работает
"Encrypted File System", или EFS, основывается на поддержке шифрования в W2k/WinXP, аналог которой впервые появился ещё в Windows NT 4.0. Первоначально эти функции не использовались для шифрования файлов, а только для установки защищённых сетевых соединений, защиты паролей пользователя, и тому подобных нужд. Только с появлением Windows 2000 и NTFS 5.0, как основной файловой системой для него, появилась возможность шифровать любые файлы средствами ОС. Для шифрования EFS использует личный и публичный ключи пользователя, которые генерируются когда пользователь пользуется функцией шифрования впервые, и остаются неизменными всё время, пока существует аккаунт пользователя. Причём на эти ключи не влияет ничего, пользователь может менять свой пароль для входа в систему, переименовывать свой аккаунт, ключи останутся неизменными так долго, как долго пользователь будет иметь тот же "security identifier" (SID). При удалении аккаунта удаляются и ключи, и если создать заново аккаунт с таким же именем, паролем, и всем остальным, то вновь созданный пользователь не будет иметь никакого ключа, до тех пор пока не зашифрует хотя бы один файл или директорию. Как только он это сделает, сгенерируются новые ключи которые, конечно же, не будут иметь ничего общего ключами которые использовал аккаунт с таким же именем раньше.
При шифровании файла EFS генерирует случайный номер, длиной 128 бит, для каждого файла разный, который называется "File Encryption Key" (FEK). Этот номер используется для шифрования файла с использованием одного из вариантов Data Encryption Standard (DES) алгоритма – DESX . После того как файл зашифрован, FEK сохраняется вместе с файлом, но тоже шифруется, уже по алгоритму RSA, основанном на использовании публичного и известного всем (для шифрования) и личного, не известного никому (для расшифровки) ключей пользователя. Таким образом, для того что бы расшифровать содержимое файла требуется знать FEK, но для того что бы расшифровать FEK, требуется знать личный ключ пользователя зашифровавшего файл. Такие сложности нужны для ускорения работы функций шифрования, при сохранении достаточно высокой надёжности. DESX является симметричным алгоритмом, то есть для шифрования и расшифровки используется один и тот же ключ. Это не очень надёжно, зато работает такой алгоритм очень быстро, и его помощью можно шифровать и расшифровывать большие объёмы данных практически в реальном времени. Для того что бы обеспечить надёжность шифрования, FEK и шифруется по RSA, ассиметричному алгоритму, когда для шифрования и расшифровки используются разные ключи. Это слишком медленно, что бы шифровать таким образом большие объёмы данных, но для шифрования FEK, RSA с использованием открытого и личного ключей подходит наилучшим образом.
Encrypted File System (EFS) работает как драйвер, на уровне ядра, но для того что бы работала вся система шифрования необходимо взаимодействие нескольких компонентов ОС. EFS тесно связана с драйвером NTFS, таким образом когда пользователь или приложение обращаются к зашифрованному файлу, драйвер NTFS вызывает EFS. EFS самостоятельно работает с алгоритмом DESX, но её возможностей не хватает для того что бы разобраться с RSA. Поэтому, каждый раз когда после шифровки файла алгоритмом DESX требуется зашифровать FEK, или наоборот, когда для расшифровки файла требуется расшифровать FEK, она должен обратиться к базовой криптографической службе операционной системы, которая работает не уровне пользователя, а не системы как EFS. Для этого используется Local Security Authority Subsystem (Lsass - \Winnt\System32\Lsass.exe), которая управляет сессиями пользователей, залогиненных на машину и заодно обрабатывает обращения EFS. Непосредственно обработкой запросов EFS занимается Local Security Authority Server (Lsasrv - \Winnt\System32\Lsasrv.dll), компонент Lsass, который и занимается непосредственно шифровкой или расшивкой FEK, используя Microsoft's CryptoAPI (CAPI). Как только FEK зашифрован или расшифрован (в зависимости от того что требовалось), он возвращается обратно к EFS, и она делает всю остальную черновую работу.
Несмотря на столь тесное взаимодействие, для работы NTFS вовсе не требуется загруженного EFS драйвера (Winnt\System32\Drivers\Efs.sys). Драйвер EFS подключается к драйверу NTFS через plug-in интерфейс, и вовсе не является неотъемлемой его частью. Конечно, драйвер NTFS имеет несколько функций, которые предназначены исключительно для поддержки EFS, но если модуль EFS не подключен, он прекрасно будет работать дальше. Свидетельством этому служит WinXP Home Edition, в которой EFS не поддерживается вовсе но NTFS прекрасно работает. Кроме этого, EFS можно включать/выключать на любой ОС из семейства W2k или WinXP. Для этого достаточно в реестре по адресу HKLM\Software\Microsoft\Windows NT\CurrentVersion\EFS key создать или отредактировать уже существующий ключ типа DWORD под названием EfsConfiguration. Присвоив этому ключу значение 1 вы выключите EFS, а 0 включите обратно. Для того что бы изменения вошли в силу, необходимо перезагрузить компьютер. Очевидно, что отключив EFS вы потеряете возможность не только шифровать файлы, но и расшифровывать ранее зашифрованные. Как очевидно и то, что включение/отключение EFS влияет сразу на всех пользователей. Но на ключи пользователей, как открытые так и личные, это действие не окажет абсолютно никакого влияния, поэтому после того как EFS будет включена вновь, никаких проблем с доступом к своим файлам пользователи не испытают.
Как вы уже знаете, в WinXP пользователь может разрешать другим пользователям использовать его защищённые файлы. Для того что бы сделать это возможным, EFS сохраняет вместе с файлом дополнительный блок информации. Как и любой другой файл, зашифрованный файл начинается с заголовка. Первым записывается версия файла, которая имеет абсолютно стандартный вид, и содержит в себе имя файла, дату создания и последнего изменения, информацию о владельце, и тому подобные вещи. Потом идёт контрольная сумма файла, которая позволит убедиться что в процессе хранения файл не был изменён или повреждён каким-либо способом. После этого сообщается о количестве Data Decryption Field (DDF) в файле. Именно это и позволяет использовать файл нескольким пользователям. Каждый из пользователей, который имеет право расшифровывать и читать содержимое файла обязан иметь свой DDF. Эти поля равнозначны, и содержат одинаковую информацию. Это Security ID (SID) пользователя, так называемый container name, которое позволяет найти нужный для расшифровки ключ, имя криптографической службы (обычно Microsoft Base Cryptographic Provider), и EFS certificate hash, где находится открытый ключ пользователя. Кроме этого, DDF содержит 128 битный FEK, зашифрованный с открытым ключом пользователя.
Таким образом, когда пользователь разрешает кому-либо другому пользоваться зашифрованным файлом, то к файлу просто добавляется ещё один DDF. Для того что бы добавить его, от пользователя требуется расшифровать FEK со своим личным ключом, а потом зашифровать его с открытым ключом пользователя, которого он хочет добавить, что позволит тому расшифровать FEK со своим личным ключом, и получить доступ. Естественно, для этого у другого пользователя должен быть открытый и закрытый ключи которые, как уже говорилось, генерируются только тогда, когда пользователь впервые воспользуется шифрованием. Поэтому если вы не можете добавить нужного пользователя, хотя он правильно зарегистрирован в системе, значит этот пользователь никогда не пользовался шифрованием. И пока этого не произойдёт, добавить его в качестве пользователя какого-либо зашифрованного файла будет невозможно. После всех DDF записей, следует раздел о количестве Data Recovery Field (DRF), на чём основана система позволяющая восстанавливать файлы, в случае если ни один из ключей пользователей прописанных в DDF не доступен. Это может случится как в случае когда учётная запись пользователя случайно или намеренно удалена (что может произойти в случае, например, если пользователь уволился), так в случае если ключ физически утерян (конечно, по умолчанию личный ключ хранится на жёстком диске компьютера, который "физически" так просто не утеряется, но в целях повышения общей надёжности и безопасности системы, есть возможность организовать хранение личных ключей пользователя на, например, магнитных карточках, потерять которую уже гораздо проще). DRF имеет тот же самый формат что и DDF, принципиальная разница между ними в том, что DDF автоматически добавляется только один, а DRF столько, сколько Encrypted Data Recovery Agent прописано в системе. К каждому зашифрованному файлу. Очевидно, что Data Recovery Agent может восстанавливать только те файлы, которые были зашифрованы после того, как он зарегистрирован системе, но никак не те, которые зашифрованы раньше. В самом еле, откуда там возьмётся соответствующий ему DRF?
Восстановление зашифрованных файлов.
Ключевой вопрос, когда речь заходит о восстановлении зашифрованных файлов, это кто был агентом по восстановлению на момент когда файл шифровался? Ответ на этот вопрос зависит от того, что за система, где и как она стоит, и позаботился ли кто заранее о том, что бы можно было восстанавливать зашифрованные файлы. По умолчанию, когда никто не добавлял и не убирал агентов по восстановлению, ситуация выглядит следующим образом.
Если компьютер является членом домена, то агентом по восстановлению по умолчанию является администратор домена, как для W2k, так и для WinXP. Если машина не является членом домена, всё по другому. В W2k агентом по восстановлению по умолчанию является локальный администратор. Более того, именно вокруг локального администратора в W2k и строится вся политика шифрования, поэтому если отобрать у локального администратора W2k права агента по восстановлению, шифрование перестанет работать вообще. Повторюсь, это касается машины которая не входит в домен. Такая ситуация далеко не идеальна, потому что у пользователей нет выбора, либо локальный администратор может читать их зашифрованные файлы, либо шифрование не работает, и администратор всё равно может читать файлы. Поэтому единственное усовершенствование функций шифрования, которое произошло в WinXP по сравнению с W2k, это изменение системной политики для шифрования. В WinXP шифрование больше не завязано на локальном администраторе. Поэтому в WinXP по умолчанию вообще нет агентов по восстановлению. То есть, DRF зашифрованных файлов остаётся пустым, и в случае утери личного ключа пользователя зашифровавшего файл восстановить его невозможно. Разве что взломом "в лоб" RSA алгоритма которым зашифрован FEK записанный в файле. Что совсем не просто сделать. А если возможно, то явно не в домашних условиях. Что бы обезопасить себя от такой печальной участи, можно воспользоваться несколькими методами. Во первых, можно экспортировать свой личный ключ и сохранить его в надёжном месте. Это прекрасно подходит в случае когда пользователь сам заботится о сохранности своих данных. Если пользователей много, и задачи по заботе о сохранности данных возложена на одного человека, то сохранять личные ключи всех пользователей сортировать и хранить их может оказаться весьма утомительным. В этом случае гораздо разумнее определить какого-либо пользователя в качестве агента по восстановлению, и сохранить только его ключ.
Если компьютер находится в домене, то агент по восстановлению создаётся простым запросом в центр сертификации (который, конечно же, должен быть запущен), и если пользователь имеет права администратора как на локальном компьютере так и на домене, то соответствующий сертификат будет им получен. Конечно, после этого у пользователя можно отобрать права администратора как на домене так и на локальном компьютере, он всё равно останется агентом по восстановлению. Но уже без администраторских прав. Таким образом можно создать столько агентов по восстановлению, сколько нужно. Если компьютер не является членом домена, то всё несколько сложнее. В случае с отдельно стоящей W2k добавить нового агента по восстановлению, вдобавок к администратору, который является таковым по умолчанию, средствами только одной ОС нельзя. По крайней мере, я такого способа на знаю. Совсем другое дело, когда речь идёт про WinXP. Процесс добавления Encrypted Data Recovery Agent в WinXP состоит из двух этапов. Во первых, необходимо создать сертификат дающий право его владельцу стать агентом по восстановлению (recovery certificate). Во вторых, требуется назначить пользователя, который должен стать агентом по восстановлению зашифрованных данных.
Для выполнения первой задачи, создания сертификата агента восстановления, требуется следующее. Залогинтесь как администратор. Для этого наберите имя пользователя Administrator в окне логона WinXP. Если у вас используется Welcome Screen, то просто нажмите для раза Crtl+Alt+Del, тогда откроется более традиционное окно, где можно вводить имя пользователя. Если пользователь один, и окно с приглашением выбрать кого-либо не появляется вообще, то загрузившись сделайте Log Off текущему пользователю, тогда у вас появится возможность залогиниться администратором. Несмотря на то, что пользователь администратор не показывается в окне Users and Passwords, он существует на любой инсталляции WinXP, и именно под этим именем. До тех пор пока его не переименуют. Пароля у этого пользователя по умолчанию нет, поэтому вводить его не надо. Загрузившись администратором, в любой командной строке наберите cipher /r:имя файла, где имя может быть любым. Вас попросят ввести пароль, которым будет защищён сертификат, повторить его, и будут сохранены два файла, CER и PFX. Это и есть то, что нам нужно. Сохраните их в надёжном месте, потому что с помощью этих файлов любой пользователь вашего компьютера может стать агентом по восстановлению.
Для того что бы делегировать пользователю права агента по восстановлению, необходимо выполнить несколько простых шагов.
Залогинтесь пользователем, которого вы хотите сделать агентом по восстановлению.
Запустите оснастку сертификаты (Certmgr.msc), перейдите в раздел Certificates – Current User -> Personal
Выберете меню Action – All tasks – Import. Откроется окно мастера импорта сертификатов.
Нажмите на кнопку Browse. Укажите путь где сохранёны файлы с сертификатом агента по восстановлению. Поменяйте тип файла на PFX, укажите на файл, нажмите Next.
В следующем окне введите пароль, которым вы защитили файл, отметьте пункт Mark This Key As Exportable, нажмите Next.
В окне пришедшему на смену отметьте пункт Automatically Select The Certificate Store Based On The Type Of Certificate, нажмите на Next. В последнем окне нажмите на Finish. Всё, оснастку сертификаты можно закрывать.
Теперь требуется открыть оснастку Local Security Settings (secpol.msc), и перейти в раздел Security Settings -> Public Key Policies -> Encrypting File System.
Выберете меню Action – Add Data Recovery Agent. Нажмите Next.
В открывшемся окне под названием Select Recovery Agents нажмите на кнопку Browse, укажите путь где сохранены файлы с сертификатом по восстановлению. На этот раз требуется указать на CER файл, поэтому тип файла который выбирается по умолчанию менять не требуется. После этого в окне, в разделе Recovery agents: появится строчка сообщающая о том, что USER_UNKNOWN готов стать агентом по восстановлению. Так и должно быть, потому что в этом сертификате имя пользователя не хранится.
Нажмите на Next, потом на Finish, и всё. Теперь пользователь стал агентом по восстановлению. С этого момента во все файлы, которые будут шифроваться на данной машине будет добавляться Data Recovery Field с атрибутами этого пользователя, и он сможет их расшифровывать. Как уже неоднократно говорилось, это относится только к файлам зашифрованным после того, как пользователь стал агентом по восстановлению, и никоим образом не относится к файлам зашифрованным раньше.
Добавив агента по восстановлению, вы даёте ему возможность расшифровывать любые файлы, любых пользователей, что не всегда является хорошей идеей. Гораздо разумнее сделать так, что бы и агент по восстановлению в системе был, но что бы он не мог просто так, когда ему вздумается расшифровывать чужие файлы. Добиться этого дегко. Всё что требуется, это экспортировать и удалить личный ключ пользователя, который назначен агентом по восстановлению. После этого, во все вновь зашифрованные файлы всё равно будет добавляться DRF запись, потому что для этого (шифрования File Encryption Key) нужен только открытый ключ, который удаляться не будет. А вот для расшифровки понадобится личный ключ, который будет удалён, и будет хранится в надёжном (как хочется верить) месте.
Для того что бы экспортировать и удалить личный ключ агента по восстановлению, требуется сделать следующее:
• Логинимся пользователем который является агентом по восстановлению. • Запускаем оснастку Certificates (certmgr.msc) там идём Certificates-Current User -> Personal -> Certificates. • Кликаем правой кнопкой мыши на File Recovery certificate, который можно узнать по надписи Encrypting File System в столбце Intended Purposes, в контекстном меню выбираем All Tasks -> Export, что запустит мастер экспорта сертификатов (Certificate Export Wizard). В открывшемся окне нажимаем на Next. • В следующем окне выбираем пункт Yes, Export The Private Key, снова нажимаем на Next.
Отмечаем Enable Strong Protection и Delete The Private Key If The Export Is Successful, снова жмём на Next.
В следующем окне вводим и подтверждаем пароль, которым будет защищён получившийся файл.
Указываем путь, где следует сохранить файл, жмём на Next, потом на Finish, и всё готово.
Теперь, для того что бы агент по восстановлению смог получить доступ к зашифрованным файлам, где он прописан в DRF, необходимо вновь импортировать только что экспортированный ключ. Делается это точно так же, как импорт любого другого личного ключа. Про то как это делается, будет написано немного ниже.
Вышеописанная методика может уберечь вас от многих неприятностей, но далеко не от всех. Например, она не поможет вам в случае полного краха системы, в этом случае вы не сможете прочитать ваши файлы. Для того что бы обезопасить себя и от этой проблемы, вам придётся экспортировать и сохранить сертификат агента восстановления. Для этого логинимся пользователем из группы администраторов, и вновь запускаем оснастку Local Security Settings (secpol.msc), и идём в Security Settings -> Public Key Policies -> Encrypting File System.
Кликаем правой кнопкой на сертификате относящемуся к администратору, выбираем All Tasks -> Export, и запускаем мастер экспорта сертификатов. На первой закладке отмечаем DER Encoded Binary X.509 (.CER) в качестве формата в котором будет сохранён экспортированный сертификат, нажимаем на Next.
В следующем окне указываете путь, где следует сохранить полученный сертификат, ещё раз нажимаете на Next, потом на Finish, и получаете требуемый сертификат, который можно использовать в случае если с вашей системой случится что то непредвиденное.
Coxранение ключа
Описанные выше методики и рекомендации подходят, в большей степени, для случаев когда на компьютере имеется несколько пользователей, или для администра, которые отвечают за несколько компьютеров, на которых существует по несколько пользователей, и у него нет времени и сил возиться с каждым из них по отдельности. Но что делать обычному пользователю, который работает на своём компьютере в одиночку, и не имеет желания городить огород с дополнительными пользователями, кучей сертификатов, делегированием прав, и тому подобными вещами. А всё что он хочет, это иметь возможность восстановить свои файлы в случае краха или переустановки системы. Это не сложно сделать. Всё что требуется от такого пользователя, это сохранить свой личный ключ, который используется для расшифровки FEK защищённых файлов зашифрованных с помощью открытого ключа этого пользователя. Для экспорта личного ключа можно запустить Internet Options (что можно сделать либо через Control Panel -> Internet Options, либо запустив Internet Explorer, и выбрав меню Tools, пункт Internet Options...). На закладке Content нажимаем на кнопку Certificates...
И оказываемся в окне сертификатов. На закладке Personal выбираем пользователя для которого требуется экспортировать личный ключ, и нажимаем на кнопку Export.
Если нужного пользователя в этом окне нет, это означает что этот пользователь не имеет личного и публичного ключа. Это означает, что этот пользователь ещё ни разу не использовал функций шифрования. Закройте окно, зашифруйте какой-либо файл или папку, и попробуйте ещё раз. После нажатия на кнопку Export откроется уже знакомое вам окно мастера экспорта сертификатов. Нажимаем на Next, в следующем окне отмечаем пункт Yes, export private key, снова жмём на Next. На следующей закладке оставляем настройки по умолчанию, не вздумайте отмечать пункт Delete the private key if export is successful, потому что в этом случае вы потеряете возможность расшифровывать зашифрованные вами файлы. Нажимаем на Next, вводим и подтверждаем пароль которым хотим защитить экспортированный ключ, снова жмём на Next, указываем где следует сохранить файл, ещё пару кликов мышкой, и мы имеем очередной PFX файл, в котором хранится ваш личный ключ. Этот ключ подходит для всех файлов когда-либо зашифрованных этим пользователем. Сохраните его в надёжном месте, в случае чего-либо непредвиденного этот файлик ваша последняя надежда на восстановление зашифрованных данных. Но не забывайте, что этот же файлик может помочь не только вам, но и любому злоумышленнику, который захочет получить доступ к вашим файлам.
Но, так или иначе, перед нами стоит задача, как получить доступ к зашифрованному файлу, профиль пользователя утерян но, к счастью, остался личный ключ пользователя. Всё что требуется, это импортировать этот ключ в профиль пользователя, который должен иметь доступ к файлам. Кстати, точно так же импортируются любые ключи, не только персональные но и, к примеру, личные ключи агентов по восстановлению. Для того что бы импортировать ключ, требуется вновь запустить окно Internet Options, перейти на закладку Content, нажать на кнопку Certificates, и открыть уже знакомое нам окно. На этот раз требуется нажать на кнопку Import, что запустит мастер импорта сертификатов. Нажимаем на Next, указываем на заранее сохраненный PFX файл с личным ключом, снова нажимаем на Next, в следующем окне вводим пароль, которым защищён файл, снова нажимаем на Next, на следующей закладке отмечаем пункт Place All Certificates In The Following Store, нажимаем на кнопку Browse, указываем папку Personal, кликаем на OK, Next и Finish. Если всё было сделано правильно, и вы ничего не напутали с экспортом и импортом, если все ключи и файлы подходят друг к другу, то в результате всех этих запутанных операций вы получите возможность прочитать казалось бы безвозвратно потерянные файлы.
Для того что бы хоть немного упорядочить полученную информацию, и не запутаться окончательно во всех этих ключах и сертификатах, как мне кажется стоит вкратце повторить всё что я тут понаписал, конечно же без излишних подробностей. Только один тезисы. Итак.
Для того что бы иметь возможность читать зашифрованные другими пользователями файлы, требуется создать Encrypted Data Recovery Agent. Для создания такого агента требуется два файла, сертификат агента по восстановлению, и личный ключ этого агента.
Что бы агент по восстановлению не мог читать любые зашифрованные файлы когда ему вздумается, следует удалить и сохранить личный ключ агента по восстановлению.
Что бы иметь возможность пользоваться услугами агента по восстановлению после краха системы, следует сохранить сертификат агента по восстановлению. Но одного этого сертификата мало, он должен сопровождаться личным ключом агента по восстановлению.
Для того что бы иметь возможность читать файлы зашифрованные конкретным пользователем, необходимо сохранить личный ключ пользователя. Тогда, в случае переустановки системы или утери профиля пользователя для того что бы прочитать зашифрованные файлы, достаточно импортировать личный ключ другому пользователю.
