Contents of this directory is archived and no longer updated.

Update 28.05.2012: новые фичи не были мною обнаружены в Windows 7 и Windows Server 2008 R2 (на других не проверял), а следовательно — выпилены из поста. Т.е. в Windows 7 и Windows Server 2008 R2 для шифрования по сети применяются те же правила и требования, что и для систем pre-Vista.


Наконец-то нашёл повод, чтобы написать в бложек. В последнее время как-то интересных тем не нахожу и занятных случаев для разбора не наблюдается. Всё самое интересное я публикую в своём буржуйском бложеке. Помогая разным пользователям на технетах решать их проблемы, пришёл к выводу, что очень многие не читают документацию по технологиям, которые они внедряют. С одной стороны это обычное явление. Зачем что-то читать, если можно залезть на технетики, где вам всё расскажут и починят? С другой стороны, они доставляют лулзы, когда у них всё накрывается медным тазом.

Казалось бы, а причём тут EFS? Недавний тред на русскоязычных технетах: Доступ к зашифрованным данным EFS с нескольких клиентских ПК (да, я обещал выпилиться оттуда насовсем, но иногда наведываюсь, чтобы снизить уровень ереси до более разумных размеров). Человек, очевидно, работает системным администратором и не знает про отличия отпечатков Кербероса и NTLM. Но это никому не интересно. Интересно другое — особенности работы EFS с сетевыми ресурсами.

Как известно (я так думал, что это известно всем), при шифровании файлов локально всё происходит очень просто. Берётся локальный сертификат EFS (если нету, он где-то добывается) и шифруются данные. Поскольку сертификат находится на локальной машине, никаких особых проблем нет, пока пользователь не зашифрует данные в сетевой папке или не поменяет рабочее место (компьютер). В чём проблема каждого случая:

1) если пользователь меняет рабочее место (пересаживается на другой компьютер), там загружается новый профиль и всё начинается сначала. Надо зашифровать данные — нужен сертификат. Очевидно, что другой компьютер ничего не знает, что сертификат уже есть где-то. Следовательно, сертификаты пользователя начинают плодиться на разных компьютерах, за которыми он работает. Это уже довольно серьёзная проблема, потому что пользователю всё равно, а решать проблему надо вам. Т.е. он работает чуть-чуть здесь, чуть-чуть там и ещё вон там и на сервере терминалов. А если у вас ещё ферма? Грубо говоря, пользователь в какой-то момент просто перестанет рандомно получать доступ к данным, потому что нужный сертификат находится на другом компьютере, а ИТ-суппорт будет тихо ненавидеть MSFT.

Перемещаемый профиль? Окай, пусть будет перемещаемый, только ключи к сертификатам НЕ ПЕРЕМЕЩАЮТСЯ вместе с профилем, они остаются там, где были сгенерированы. В Windows Server 2003 единственное средство, которое решало эту проблему хоть как-то, было Credential Roaming Service. Но оно, если не ошибаюсь, появилось слишком поздно (ближе к выходу Windows Server 2008). При применении Credential Roaming Service, ключи хранятся в Active Directory (что не есть очень безопасно).

2) шифрование файлов в сетевой папке. Многие администраторы имеют правильную привычку централизации ресурсов. Например, все документы должны храниться не на клиентских компьютерах, а на файловых серверах.

Здесь есть свои и более существенные проблемы. Что происходит в этом случае? А происходит вот что: на файловом сервере в бэкграунде загружается профиль пользователя и туда доставляется сертификат EFS. Если нету Credential Roaming Service, запрашивается или генерируется новый сертификат, который хранится на этом файловом сервере. Но не всё так просто, поскольку для загрузки профиля на удалённом компьютере, он должен быть доверен для делегирования (т.е. сервер представляется пользователем и получает право на доступ к ресурсам от его имени). По умолчанию только контроллеры домена доверены для делегирования, а остальные серверы нет, потому что это снижает безопасность (в случае компрометации сервера можно натворить кучу нехороших дел) и многие администраторы не решаются на это без необходимых на то оснований.

Хорошо, вы сделали сервер доверенным для делегирования, но представьте себе, что у вас DFS, который реплицирует данные между несколькими файловыми серверами. Пользователю, сидя за одним и тем же компьютером достаточно подключиться к другому файловому серверу (физическому) автоматически теряет доступ к зашифрованным файлам, потому что на другом сервере этого сертификата просто не существует. И снова на выручку приходит Credential Roaming Service.

Всё, казалось бы, хорошо и жизнь прекрасна. Но давайте зададим вопрос (ответ на который можно извлечь уже из написанного): а в каком виде зашифрованные файлы из сетевой папки поступают к пользователю? Совершенно очевидно, что они поступают расшифрованными. Т.е. зашифрованные файлы передаются по сети в ОТКРЫТОМ ВИДЕ (plain text). Поверьте, многие, кто внедрял EFS до сих пор этого не знают. Так что используете вы EFS или нет, знайте — от вашего EFS толк есть до тех пор, пока кто-нибудь не откроет файл из сетевой папки.

Примечание: поведение EFS при шифровании сетевых файлов применимо только если сервер или клиент работает под управлением устаревшей ОС (Windows 2000, Windows XP и Windows Server 2003/R2). Т.к. таковых ещё много, с этим приходится ещё считаться.

Начиная с Windows Vista и Windows Server 2008 эта проблема решена другим, более логичным способом. Файлы передаются как есть (т.е. зашифрованные файлы передаются в зашифрованном виде, остальные в открытом виде), а процесс шифрования и дешифрования происходит локально. И, как следствие, отпадает необходимость включения доверия для делегирования файлового сервере. Но и здесь мы сталкиваемся с проблемой перемещения пользователя между компьютерами. Поскольку сертификаты хранятся только локально, нужно снова применять Credential Roaming Service.

По правде говоря, начиная с Windows Vista и Windows Server 2008 вы можете хранить сертификаты EFS вместе с ключами на смарт-картах (здесь ссылки на все материалы по теме: EFS и смарт-карты в Windows Server 2008 (часть 4, заключительная)), но это снова затраты на дополнительное оборудование. Но, наверное, ваши данные стоят того. Или вам EFS просто не нужен.

По указанным выше причинам я стараюсь избегать применения EFS и запрещаю его на уровне политик, пока для этого не будет обоснованной необходимости.


Share this article:

Comments:

Comments are closed.