4.Внутреннее устройство Windows (гл. 12-14)

Как уже говорилось, драйвер EFS выполняет шифрование и расшифровку данных порциями по 512 байтов. Такой размер оптимален для драйвера, потому что объем данных при операциях чтения и записи кратен размеру сектора.

Резервное копирование шифрованных файлов

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

Для доступа к шифрованному содержимому файлов утилиты резервного копирования в Windows используют новый EFS APL функции OpenEncrypted-FileRatv, ReadEncryptedFileRaw, WriteEncryptedFileRaw и CloseEncryptedFileRaiv. Эти функции, предоставляемые Advapi32.dll, вызывают соответствующие функции Lsasrv по механизму LPC Например, после того как утилита резервного копирования открывает файл, она vbi3biw‹kCTReadEncryptedFileRaiv, чтобы получить данные. Lsasrv-функция EfsReadFileRaw выдает управляющие команды (шифруемые по алгоритму DESX, AES или 3DES с помощью сеансового ключа EFS) драйверу NTFS для чтения сначала атрибута EFS файла, а затем его шифрованного содержимого.

EfsReadFileRaw может понадобиться несколько операций чтения, чтобы считать большой файл. По мере того как EfsReadFileRaw считывает очередную порцию файла, Lsasrv посылает Advapi32.dll RPC-сообщение, в результате которого выполняется функция обратного вызова, указанная программой резервного копирования при вызове ReadEncryptedFileRaw. Функция EfsReadFileRaiv передает считанные шифрованные данные функции обратного вызова, которая записывает их на архивный носитель. Восстанавливаются шифрованные файлы аналогичным образом. Программа резервного копирования вызывает API-функцию WriteEncryptedFileRaw, которая активизирует функцию обратного вызова программы резервного копирования для получения нешифрованных данных с архивного носителя, в то время как Lsasrv-функция EfsWriteFileRaw восстанавливает содержимое файла.

ЭКСПЕРИМЕНТ: просмотр информации EFS

EFS поддерживает массу других API-функций, с помощью которых приложения могут манипулировать шифрованными файлами. Так, функция AddUsersToEncryptedFile позволяет предоставлять доступ к шифрованному файлу дополнительным пользователям, а функция RemoveUsersFromEncryptedFile — запрещать доступ к нему указанным пользователям. Функция QueryUsersOnEncryptedFile сообщает о сопоставленных с файлом полях ключей DDF и DRE Она возвращает SID, хэш сертификата и содержимое каждого поля ключа DDF и DRE Ниже приведен образец вывода утилиты EFSDump (www.sysinternals.com).

B качестве параметра ее командной строки указано имя шифрованного файла.

Как видите, в файле test.txt имеется один элемент DDF, соответствующий пользователю Mark, и один элемент DRF, соответствующий Administrator, который является единственным агентом восстановления, зарегистрированным в системе на данный момент.

Чтобы убедиться в наличии атрибута $EFS в зашифрованном файле, используйте утилиту Nfi из OEM Support Tools:

Резюме

Windows поддерживает широкий спектр форматов файловых систем, доступных как локальной системе, так и удаленным клиентам. Архитектура драйвера фильтра файловой системы позволяет корректно расширять и дополнять средства доступа к файловой системе, a NTFS является надежным, безопасным и масштабируемым форматом файловой системы. B следующей главе мы рассмотрим поддержку сетей в Windows.

ГЛABA 13 Поддержка сетей

Windows создавалась с учетом необходимости работы в сети, поэтому в операционную систему включена всесторонняя поддержка сетей, интегрированная с подсистемой ввода-вывода и Windows API. K четырем базовым типам сетевого программного обеспечения относятся сервисы, API, протоколы и драйверы устройств сетевых адаптеров. Все они располагаются один над другим, образуя сетевой стек. Для каждого уровня в Windows предусмотрены четко определенные интерфейсы, поэтому в дополнение к большому набору API-функций, протоколов и драйверов адаптеров, поставляемых с Windows, сторонние разработчики могут создавать собственные компоненты, расширяющие сетевую функциональность операционной системы.

B этой главе будет рассмотрен весь сетевой стек Windows — снизу доверху. Сначала мы поговорим о том, как сетевые компоненты Windows соотносятся с уровнями эталонной модели OSI (Open Systems Interconnection). Далее мы кратко опишем сетевые API, доступные в Windows, и покажем, как они реализованы. Вы узнаете, что делают редиректоры, как происходит разрешение имен сетевых ресурсов и как устроены драйверы протоколов. Познакомившись с реализацией драйверов устройств сетевых адаптеров, мы расскажем о привязке, в ходе которой сервисы и стеки протоколов связываются с сетевыми адаптерами.

Сетевая архитектура Windows

Задача сетевого программного обеспечения состоит в приеме запроса (обычно на ввод-вывод) от приложения на одной машине, передаче его на другую, выполнении запроса на удаленной машине и возврате результата на первую машину. B ходе этих операций запрос неоднократно трансформируется. Высокоуровневый запрос вроде «считать x байтов из файла у на машине z» требует, чтобы программное обеспечение определило, как достичь машины z и какой коммуникационный протокол она понимает. Затем запрос должен быть преобразован для передачи по сети — например, разбит на короткие пакеты данных. Когда запрос достигнет другой стороны, нужно проверить его целостность, декодировать и послать соответствующему компоненту операционной системы. По окончании обработки запрос должен быть закодирован для обратной передачи по сети.

Эталонная модель OSI

Чтобы помочь поставщикам в стандартизации и интеграции их сетевого программного обеспечения, международная организация по стандартизации (ISO) определила программную модель пересылки сообщений между компьютерами. Эта модель получила название эталонной модели OSI (Open Systems Interconnection). B ней определено семь уровней программного обеспечения (рис. 13-1).

Эталонная модель OSI — идеал, точно реализованный лишь в очень немногих системах, но часто используемый при объяснении основных принципов работы сети. Каждый уровень на одной из машин считает, что он взаимодействует с тем же уровнем на другой машине. Ha данном уровне обе машины «разговаривают» на одном языке, или протоколе. Ho в действительности сетевой запрос должен сначала пройти до самого нижнего уровня на первой машине, затем он передается по несущей среде и уже на второй машине вновь поднимается до уровня, который его поймет и обработает.

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

• Прикладной уровень (application layer) Обрабатывает передачу данных между двумя сетевыми приложениями, включая проверку прав доступа, идентификацию взаимодействующих машин и инициацию обмена данными.

• Презентационный уровень (presentation layer) Отвечает за форматирование данных, в том числе решает, должны ли строки заканчиваться парой символов «возврат каретки/перевод строки» (CR/LF) или только символом «возврат каретки» (CR), надо ли сжимать данные, кодировать и т. д.