И снова EFS. Казалось бы, над ним уже давно расставлены все точки, ан-нет, кому-то обязательно не будет покоя. А покоя сегодня нет по следующим поводам: EFS sharing и как правильно состряпать сертификат агента восстановленя EFS.
EFS sharing
Поступил по почте мне вопрос с ссылкой на ОСЗоне: http://forum.oszone.net/showthread.php?p=1922709. Краткое содержание серий:
Хочу сдать экзамен 70-642 (проектирование сетевой инфраструктуры Win2k8), читаю, тестирую, наткнулся на непонимание работы EFS по сети. Что написано в учебнике по 70-642:
"для совместного использования файлов с защитой EFS на локальном компьютере нужно добавить к файлу пользовательские сертификаты шифрования. Для совместного использования файлов по сети делать это не нужно, поскольку EFS предназначена для защиты доступа к файлам на локальном компьютере, и система Windows автоматически выполняет расшифровку файлов перед назначением общего доступа"
Честно говоря, я этот учебник не читал даже в оригинале и не могу сказать, правда ли так написано или нет. Возвращаемся к моему недавнему посту по теме. Из него следует, что шаринг файлов и шифрование сетевых файлов может сосуществовать (хотя, некоторые интернеты и отрицают это), т.е. не являются взаимоисключающими параграфами. Стало быть, вторая часть фразы из учебника не совсем верная. Вот как происходит процесс локально:
Цопирайт: картинка невозбранно стырена из религиозно-православной книжки Комара.
- Пользователь создаёт файл и хочет его зашифровать.
- В этот момент система генерирует симметричный ключ FEK (File Encryption Key), которым шифруется само содержимое файла (при помощи какого-нибудь симметричного алгоритма DES/3DES/AES).
- Берётся сертификат EFS пользователя и открытым ключом шифруется этот самый FEK, но уже при использовании асимметричного алгоритма.
- Зашифрованный ключ кладётся в поле DDF (Data Decryption Field).
- Если назначены агенты восстановления файлов EFS, шаги 2 и 3 повторяются для каждого агента восстановления.
- Эти зашифрованные ключи кладутся уже в поле DRF (Data Recovery Field).
Предположим, что на данном компьютере работает ещё один пользователь и ему необходимо иметь доступ к файлу. Для этого ему должны быть назначены права чтения на уровне прав NTFS. Но этого недостаточно, поскольку данные зашифрованы. Предоставить файл в общий доступ с другими пользователями может только тот, кто зашифровал файл или агенты восстановления. Для этого пользователь имеющий доступ к зашифрованным данным (владелец) выбирает свойства файла, жмёт Advanced –> Details. Там он увидит список всех пользователей и агентов восстановления, которые могут читать файл. И в этом окошке он может добавить новых пользователей, нажав кнопку Add:
Примечание: не обращайте внимания на то, что на рисунке показан сетевой файл, суть одна и та же, что и с локальным файлом.
По умолчанию диалоговое окно показывает сертификаты тех пользователей, чьи сертификаты установлены в контейнере Trusted People локального компьютера. Вы можете выбрать какой-то из них и тогда для этого сертификата повторяются шаги 3-4. Т.е. образуется новое DDF с новым сертификатом и ключ FEK шифруется открытым ключом выбранного сертификата. И владелец этого сертификата (и связанного с ним закрытого ключа) сможет получить доступ к зашифрованному файлу. Всё очень просто.
Примечание: этим окошком категорически запрещается пользоваться в доменной среде! Добавлять пользователя необходимо только через поиск по Active Directory!
Если же пользователь, которому нужен доступ к файлу (предполагается, что файл будет ему передан на съёмном носителе. Никаких доступов по сети) работает на другом компьютере, нажимаете кнопку Find User… и поиском по Active Directory ищите нужного пользователя. Там же будут показаны доступные сертификаты удалённого пользователя.
Если вы внимательно прочитали предыдущую статью, значит вы знаете, что тот же самый процесс происходит и с файлами в сетевой папке, с той лишь разницей, что все сертификаты и криптографические операции производятся на удалённой машине. Т.е. когда вы шифруете файл в сетевой папке, ваш профиль загружается на удалённой машине. Когда вы добавляете пользователя в доступ к шифрованному файлу, убедитесь, что у пользователя на этом удалённом сервере есть свой сертификат EFS (если нету Credential Roaming Service) или они имеют доступ к закрытому ключу от сертификата, который вы будете добавлять в общий доступ. И именно поэтому вам нельзя пользоваться сертификатами из первого окошка, которое вылезает при нажатии кнопки Add. Ведь сертификаты шифрования пользователей находятся на удалённом сервере, а в окошке сертификаты с локального компьютера.
Вывод: при назначении общего доступа к сетевой папке (я так понимаю, что это просто расшаривание ресурса) ничего автоматически не расшифровывается. Даже при предоставлении общего доступа к зашифрованному файлу, т.к. в этом случае расшифровывается только FEK. Но не для подтверждения очевидного я тут распинался пол статьи. Я просто хотел показать тот кромешный ад, который вас ожидает при использовании EFS в масштабах предприятия. И если вы до сих пор не понимаете, как именно происходит весь процесс — не вздумайте даже приближаться к этой теме. Если вы всё поняли — you are welcome!
EFS Recovery agent
Ещё одна вещь, которую многие упускают. По умолчанию, как только зашифрован первый файл в домене, на первом контроллере домена (на котором создавался домен) в профиле первого администратора домена создаётся автоматический сертификат агента восстановления EFS. Этот же сертификат добавляется в Default Domain Policy. Поскольку контроллеры домена относительно часто меняются, риск потерять возможность восстановить зашифрованные файлы ~99,99%.
Более опытные и головастые администраторы у локального CA запрашивают себе отдельный сертификат агента восстановления EFS. Правда, часть из них забывают открытую часть этого сертификата доставить в групповую политику. Или забывают экспортировать его куда-то на съёмный носитель (а лучше два) вместе с ключевой парой на случай смены профиля. По умолчанию, шаблон агента восстановления рассчитан на срок 5 лет. За это время вы обязательно забудете его обновить и результат будет немного предсказуем.
Следовательно, это будет хорошей практикой создать самоподписанный сертификат, который будет действителен лет 20 с самым жирным ключом (например, 4096 бит), экспортировать его в PFX, сложить на 2 флешки (и они не должны храниться в одном месте) и заныкать их. Сертификат агента восстановления доставить в групповую политику в качестве агента восстановления и в Trusted Root CAs (потому что сертификат агента восстановления жёстко проверяется на валидность и если проверка будет провалена, шифрование не произойдёт). Но, это не единственное правильное решение. Вы можете сгенерировать несколько самоподписанных сертификатов и раздать их пользователям, которые будут выполнять функции агента восстановления.
Comments: