Файловая система NTFS Механизм EFS реферат по информатике , Сочинения из Информатика

Скачай Файловая система NTFS Механизм EFS реферат по информатике и еще Сочинения в формате PDF Информатика только на Docsity! Содержание Введение 2 Файловая система NTFS 3 Структура NTFS на диске 3 Главная таблица файлов 5 Защита и шифрование 7 Механизм EFS 9 Регистрация функций обратного вызова 12 Первое шифрование файла 13 Создание связок ключей 14 Шифрование файловых данных 16 Схема процесса шифрование файла через EFS 18 Процесс расшифровки 19 Резервное копирование шифрованных файлов 21 Заключение 23 Приложение. Сокращения. 24 Список используемой литературы 25 Введение Защита конфиденциальных данных от несанкционированного доступа очень важна в любой среде, где множество пользователей обращается к одним и тем же физическим и сетевым ресурсам. У операционной системы, как и у отдельных пользователей, должна быть возможность защиты файлов, памяти и конфигурационных параметров от нежелательного просмотра и внесения изменений. Защищать файлы от несанкционированного доступа можно различными средствами, но в случае кражи файлов единственной защитой остается шифрование. Файловая система NTFS15 разрабатывалась специально для Windows 2000 и является системой корпоративного класса. Для шифрования файлов NTFS использует механизм EFS7. Обзор файловой системы NTFS и механизма EFS и является целью моей курсовой работы. Файловая система NTFS Формат файловых систем определяют принципы хранения данных на носителе и влияют на характеристики файловой системы. Формат файловой системы может налагать ограничения на размеры файлов и Метаданные – это данные, хранящиеся на томе и необходимые для поддержки управления файловой системой. Как правило, они не доступны приложениям. К метаданным NTFS относятся структуры данных, используемые для поиска и выборки файлов, начальный загрузочный код и битовая карта, в которой регистрируется состояние пространства всего тома. Главная таблица файлов (MFT14) занимает центральное место в структуре NTFS-тома. MFT реализована как массив записей о файлах. Размер каждой записи фиксирован и равен 1 Кб. Логически MFT содержит по одной строке на каждый файл тома, включая строку для самой MFT. Кроме MFT на каждом томе NTFS имеется набор файлов метаданных с информацией, необходимой для реализации структуры файловой системы. Имена всех файлов метаданных NTFS начинаются со знака $, хотя эти знаки скрыты. Так имя файла MFT - $Mft. Остальные файлы NTFS-тома являются обычными файлами и каталогами. Обычно каждая запись MFT соответствует отдельному файлу, но если у файла много атрибутов или он сильно фрагментирован, для него может понадобиться более одной записи. Тогда первая запись MFT, хранящая адреса других записей, называется базовой. При первом обращении к тому NTFS должна считать с диска метаданные и сформировать внутренние структуры данных, необходимые для обработки обращений к файловой системе. Для этого NTFS ищет в загрузочном секторе физический адрес MFT на диске. Запись о самой MFT является первым элементом в этой таблице, вторая запись указывает на файл в середине диска ($MftMirr), который называется зеркальной копией MFT и содержит копию первых нескольких строк MFT. Если по каким- либо причинам считать часть MFT не удастся, для поиска файлов метаданных будет использована именно эта копия MFT. Найдя запись для MFT, NTFS получает из ее атрибута данных информацию о сопоставлении VCN и LCN и сохраняет ее в памяти. В каждой группе хранится сопоставление VCN-LCN и длина этой группы – вот и вся информация, необходимая для того, чтобы найти LCN по VCN. Эта информация сообщает NTFS, где на диске искать группы, образующие MFT. Затем NTFS обрабатывает записи MFT еще для нескольких файлов метаданных и открывает эти файлы. Наконец, NTFS выполняет операцию восстановления файловой системы и открывает остальные файлы метаданных. С этого момента пользователь может обращаться к данному дисковому тому. В процессе работы системы NTFS ведет запись в файл метаданных – файл журнала с именем $LogFile. NTFS использует его для регистрации всех операций, влияющих на структуру тома NTFS, в том числе для регистрации создания файлов и выполнения любых команд, модифицирующих структуру каталогов. Файл журнала используется и при восстановлении тома NTFS после аварии системы. Еще один элемент MFT зарезервирован для корневого каталога, обозначаемого как «\». Его запись содержит индекс файлов и каталогов, хранящихся в корне структуры каталогов NTFS. Когда NTFS впервые получает запрос на открытие файла, она начинает его поиск с записи корневого каталога. Открыв файл, NTFS сохраняет файловую ссылку MFT для этого файла и поэтому в следующий раз, когда понадобится считать или записать тот же файл, сможет напрямую обратиться к его записи в MFT. NTFS регистрирует распределение дискового пространства в файле битовой карты с именем $Bitmap. Атрибут данных для файла битовой карты содержит битовую карту, каждый бит которой представляет кластер тома и сообщает, свободен кластер или выделен. Защита и шифрование Защита в NTFS построена на модели объектов Windows 2000. Файлы 0 0 1 Fи ка талоги защищены от доступа пользователей, не имеющих соответствующих прав. Открытый файл реализуется в виде объекта «файл» с дескриптором защиты, хранящимся на диске как часть файла. Прежде чем процесс сможет открыть описатель какого-либо объекта, в том 0 0 1 Fчисле и объекта «файл», сис тема защиты Windows 2000 должна 0 0 1 Fубедится, что у этого процесса есть соот ветствующие полномочия. Дескриптор защиты в сочетании с требованием регистрации пользователя при входе в систему гарантирует, что ни один процесс не получит доступа 0 0 1 Fк файлу без разрешения системного администра тора или владельца файла. Пользователи часто хранят на своих компьютерах конфиденциальную информацию. Хотя данные на серверах компаний обычно надежно 0 0 1 Fзащи щены, информация, хранящаяся на портативном компьютере, может попасть в чужие руки в случае потери или кражи компьютера. Права 0 0 1 Fдоступа к фай лам NTFS в таком случае не защитят данные, поскольку 0 0 1 Fполный доступ к то мам NTFS можно получить независимо от их защиты 0 0 1 F– достаточно восполь зоваться программами, умеющими читать файлы NTFS вне среды Windows 2000. Кроме этого, права доступа к файлам NTFS становятся бесполезны при использовании другой системы Windows 0 0 1 F2000 и учетной записи администра тора, т.к. учетная запись администратора обладает привилегиями захвата во владение и резервного копирования, любая из которых позволяет получить доступ к любому защищенному объекту в обход его параметров защиты. NTFS поддерживает механизм Encrypting File System (EFS), с помощью которого пользователи могут шифровать конфиденциальные данные. EFS полностью прозрачен для приложений. Это означает, что 0 0 1 Fданные автомати чески расшифровываются при чтении их приложением, работающим под учетной записью пользователя, который имеет права на 0 0 1 Fпросмотр этих дан ных, и автоматически шифруются при изменении их авторизованным приложением. NTFS не допускает шифрования файлов, расположенных в корневом 0 0 1 Fката логе системного тома или в каталоге \Winnt, поскольку многие 0 0 1 Fпользователя, но никто не сможет расшиф ровать с его помощью данные, 0 0 1 Fзашифрованные по этому ключу. Единствен ный способ расшифровки файла заключается в использовании операционной системой закрытого ключа, который она. Как правило, хранит в безопасном месте. Закрытый ключ помогает расшифровать нужный FEK файла. Windows 2000 хранит закрытые ключи на жестком диске, что не слишком безопасно, но в следующих выпусках операционной системы пользователи смогут 0 0 1 Fхра нить закрытые ключи на компактных носителях вроде смарт-карт. 0 0 1 FАлго ритмы на основе открытого ключа обычно довольно медленные. Поэтому они используется EFS только для шифрования FEK. Разделение ключей на открытый и закрытый немного упрощает управление ключами по сравнению с таковым в алгоритмах симметричного шифрования и 0 0 1 Fрешает дилемму, свя занную с защитой FEK. Функциональность EFS опирается на несколько компонентов, как видно на схеме архитектуры EFS (см. рисунок). Пользовательский режим LPC Режим ядра EFS реализована в виде драйвера устройства, работающего в режиме ядра и тесно связанного с драйвером файловой системы NTFS. Всякий раз, когда NTFS встречает зашифрованный файл, она вызывает функции из драйвера EFS, зарегистрированные им в NTFS при инициализации EFS. Функции EFS осуществляют шифрование и расшифровку файловых 0 0 1 Fданных по мере обра щения приложений к шифрованным файлам. Хотя EFS хранит FEK вместе с данными файла, FEK шифруется с помощью 0 0 1 Fоткрытого ключа индивидуаль ного пользователя. Для шифрования или расшифровки файловых данных EFS должна расшифровать FEK файла, 0 0 1 Fобращаясь к криптографическим сер висам пользовательского режима. Подсистема локальной аутентификации (Local Security Authentication Subsystem, Lsass13)(\Winnt\System32\Lsass.exe) не только управляет 0 0 1 Fсеансами ре гистрации, но и выполняет рутинные операции, связанные с управлением ключами EFS. Например, когда драйверу EFS требуется расшифровать FEK для расшифровки данных файла, к которому 0 0 1 Fобращается пользователь, драй вер EFS посылает запрос Lsass через вызов локальной процедуры (local procedure call или LPC11). Драйвер устройства KsecDD9 (\Winnt\System32\Drivers\Ksecdd.sys) экспортирует функции, необходимые драйверам для посылки Lpc- сообщений Lsass. Компонент Lsass, сервер локальной аутентификации (Local Security Authentication Server, Lsasrv12) (\Winnt\System32\Lsasrv.dll), ожидает запросы на расшифровку FEK через вызов отдаленной процедуры (remote procedure call или RPC16); расшифровка выполняется соответствующей функцией EFS. Которая также находится в Lsasrv. Для расшифровки FEK, получаемого от драйвера EFS в зашифрованном виде, Lsasrv использует функции Microsoft CryptoAPI, или сокращенно CAPI1. CAPI состоит из DLL компонентов доступа к криптографическим 0 0 1 Fсерви сам (шифрованию, дешифрованию и хэшированию). Например, эти DLL управляют получением открытого и закрытого ключей пользователя, 0 0 1 Fчто по зволяет Lsasrv не заботиться о деталях защиты ключей и об 0 0 1 Fособенностях ра боты алгоритмов шифрования. Расшифровав FEK, Lsasrv возвращает его драйверу EFS в ответном LPC-сообщении. Получив расшифрованный FEK, EFS с помощью DESX расшифровывает данные файла для NTFS. Регистрация функций обратного вызова Присутствие драйвера EFS(\Winnt\System32\Drivers\EFS.sys) не является необходимым условием для работы NTFS, но без него шифрованные файлы будут недоступны. NTFS предусматривает интерфейс для подключения драйвера EFS, поэтому при инициализации драйвер EFS может сам подключится к NTFS. Драйвер NTFS экспортирует несколько функций, используемых драйвером EFS, включая те, которые EFS вызывает для уведомления NTFS о своем присутствии и связанных с ним API-функциях. Первое шифрование файла Обнаружив шифрованный файл, драйвер NTFS вызывает функции, зарегистрированные EFS. О состоянии шифрования файла сообщают его атрибуты. NTFS и EFS имеют специальные интерфейсы для преобразования файла из незашифрованной в зашифрованную форму, но этот процесс протекает в основном под управлением компонентов пользовательского режима. Windows 2000 позволяет шифровать файлы двумя способами: утилитой командной строки cipber или с помощью FEK. Lsasrv шифрует FEK через CryptoAPI по алгоритму RSA с применением открытого ключа данного пользователя. Далее Lsasrv создает еще одну связку ключей, содержащую элементы ключей восстановления (recovery key entries). EFS хранит информацию об этих элементах в поле файла DRF6. Формат элементов DRF идентичен формату DDF. DRF служит для расшифровки пользовательских данных по определенным учетным записям (агентов восстановления) в тех случаях, когда администратору нужен доступ к пользовательским данным. Пользовательский SID (S-1-5-21-…) Имя контейнера (ее341-2144-55ba…) Имя компонента доступа (Microsoft Base Cryptographic Provider 1.0) Хэш сертификата EFS (cb3e4e…) Зашифрованный FEK (03fe4f3c…) Версия Контрольная сумма Число элементов ключей DDF DDF-элемент ключа 1 DDF-элемент ключа 2 Число элементов ключей DRF DRF-элемент ключа 1 Допустим, сотрудник компании использовал CryptoAPI для хранения своего закрытого ключа на смарт-карте, а потом потерял ее. В этом случае восстановить его зашифрованные данные можно только с помощью агентов восстановления. Агенты восстановления (Recovery Agents) определяются в политике безопасности Encrypted Data Recovery Agents (Агенты восстановления шифрованных данных) на локальном компьютере или в домене. Эта политика доступна через оснастку Group Policy (Групповая политика) консоли ММС. Можно добавить агенты восстановления и указать, какие криптографические пары (обозначенные их сертификатами) могут использовать эти агенты для восстановления шифрованных данных. Lsasrv интерпретирует политику восстановления в процессе своей инициализации или при получении уведомления об изменении политики восстановления. EFS создает DRF-элементы ключей для каждого агента восстановления, используя компонент доступа к криптографическим сервисам, зарегистрированный для EFS-восстановления. Компонентом по умолчанию служит Base Cryptographic Provider 1.0. На завершающем этапе создания информации EFS для файла Lsasrv вычисляет контрольную сумму для DDF и DRF по механизму хеширования MD5 из Base Cryptographic Provider 1.0. Lsasrv хранит вычисленную контрольную сумму в заголовке данных EFS. EFS ссылается на эту сумму при расшифровке, чтобы убедиться в том, что сопоставленные с файлом данные EFS не повреждены и не взломаны. Шифрование файловых данных После создания всех данных, необходимых для шифруемого пользователем файла, Lsasrv приступает к шифрованию файла и создает его резервную копию, Efs0.tmp (если есть другие резервные копии, Lsasrv просто увеличивает номер в имени резервного файла). Резервная копия помещается в тот каталог, где находится шифруемый файл. Lsasrv применяет к резервной копии ограничивающий дескриптор защиты, так что доступ к этому файлу можно получить только по учетной записи System. Далее Lsasrv инициализирует файл журнала, созданный им на первом этапе процесса шифрования и регистрирует в нем факт создания резервного файла. Lsasrv шифрует исходный файл только после его резервирования. Далее, Lsasrv посылает через NTFS драйверу устройства EFS команду на добавление к исходному файлу созданной информации EFS. NTFS получает эту команду, но поскольку она не понимает команд EFS, то просто вызывает драйвер EFS. Драйвер EFS принимает посланные Lsasrv данные EFS и применяет их к файлу через функции, экспортируемые NTFS. Эти функции позволяют EFS добавить к NTFS-файлу атрибут $LOGGED_UTILITY_STREAM. После этого управление возвращается к Lsasrv, который копирует содержимое шифруемого файла в резервный. Закончив создание резервной копии (в том числе скопировав все дополнительные потоки данных), Lsasrv отмечает в файле журнала, что резервный файл находится в актуальном состоянии. Затем Lsasrv посылает NTFS другую команду, требуя зашифровать содержимое исходного файла. Получив от EFS команду на шифрование файла, NTFS удаляет содержимое исходного файла и копирует в него данные резервного. По мере копирования каждого раздела файла NTFS сбрасывает данные раздела из КЭШа файловой системы, и они записываются на диск. Так как файл помечен как шифрованный, NTFS вызывает EFS для шифрования раздела данных перед записью на диск. EFS использует незашифрованный FEK, переданный NTFS, чтобы шифровать файловые данные по алгоритму DESX порциями, равными по размеру одному сектору (512 байт). В версиях Windows 2000, разрешенных к экспорту за пределы США, драйвер EFS реализует 56-битный ключ шифрования DESX, тогда как в версии, подлежащей использованию только в США, длина ключа DESX равна 128 битам. расшифрованный FEK файла, применяемый для обработки данных в операциях, которые пользователь может выполнять над файлом. EFS не может расшифровать FEK самостоятельно и полагается в этом на Lsasrv, который может использовать CryptoAPI. С помощью драйвера KsecDD.sys EFS посылает LPC-сообщение Lsasrv, чтобы тот извлек из атрибута $LOGGED_UTILITY_STREAM FEK пользователя, открывающего файл, и расшифровал его. Получив LPC-сообщение, Lsasrv вызывает функцию LoadUserProfile из Userenv.dll для загрузки в реестр профиля пользователя, если он еще не загружен. Lsasrv перебирает все поля ключей в данных EFS, пробуя расшифровать каждый FEK на основе закрытого ключа пользователя; с этой целью Lsasrv пытается расшифровать FEK в DDF или DRF элементе ключа. Если хэш сертификата в поле ключа не подходит к ключу пользователя, Lsasrv переходит к следующему полю ключа. Если Lsasrv не удастся расшифровать ни одного FEK в DDF или DRF, пользователь не получит FEK файла, и EFS запретит доступ к файлу приложению, которое пыталось открыть этот файл. А если Lsasrv найдет какой-нибудь хэш, который соответствует ключу пользователя, он расшифрует FEK по закрытому ключу пользователя через CryproAPI. Lsasrv, обрабатывая при расшифровке FEK связки ключей DDF и DRF, автоматически выполняет операции восстановления файла. Если к файлу пытается получить доступ агент восстановления, не зарегистрированный на доступ к шифрованному файлу, т.е. у него нет соответствующего поля в связке ключей DDF, EFS позволит ему обратиться к файлу, потому что агент имеет доступ к пере ключей для поля ключа в связке ключей DRF. Путь от драйвера EFS до Lsasrv и обратно требует довольно много времени – в процессе расшифровки FEK в типичной системе CryptoAPI использует результаты более 2000 вызовов API-функций реестра и 400 обращений к файловой системе. Чтобы сократить издержки от всех этих вызовов, драйвер EFS использует кэш в паре с NTFS. Открыв шифрованный файл, приложение может читать и записывать его данные. Для расшифровки файловых данных NTFS вызывает драйвер EFS по мере чтения этих данных с диска – до того, как помещает их в кэш файловой системы. Аналогичным образом, когда приложение записывает данные в файл, они остаются незашифрованными в кэше файловой системы, пока приложение или диспетчер кэша не сбросит данные обратно на диск с помощью NTFS. При записи данных шифрованного файла из кэша на диск NTFS вызывает драйвер EFS, чтоб зашифровать их. Драйвер EFS выполняет шифрование и расшифровку данных порциями по 512 байт. Такой размер оптимален для драйвера, потому что объем данных при операциях чтения и записи кратен размеру сектора. Резервное копирование шифрованных файлов Важный аспект разработки любого механизма шифрования файлов заключается в том, что приложения не могут получить доступ к расшифрованным данным иначе, чем через механизмы шифрования. Это ограничение особенно важно для утилит резервного копирования, с помощью которых файлы сохраняются на архивных носителях. EFS решает эту проблему, предоставляя утилитам резервного копирования механизм, с помощью которого они могут создавать резервные копии файлов и восстанавливать их в шифрованном виде. Таким образом, утилитам резервного копирования не обязательно шифровать или расшифровывать данные файла в процессе резервного копирования. Для доступа к шифрованному содержимому файлов утилиты резервного копирования в Windows 2000 используют новый EFS API: функции OpenEncryptedFileRaw, ReadEncryptedFileRaw, WriteEncryptedFileRaw и CloseEncryptedFileRaw. Эти функции, предоставляемые Advapi32.dll, вызывают соответствующие функции Lsasrv по механизму LPC. Например, после того как утилита резервного копирования открывает файл, она вызывает ReadEncryptedFileRaw, чтобы получить данные. Lsasrv-функция EfsReadFileRaw выдает управляющие команды, шифруемые по алгоритму DESX с помощью сеансового ключа EFS, драйверу NTFS для чтения сначала атрибута EFS файла, а затем его шифрованного содержимого. EfsReadFileRaw может понадобиться несколько операций чтения, чтобы считать большой файл. По мере того как EfsReadFileRaw считывает очередную порцию файла, Lsasrv посылает Advapi32.dll RPC-сообщение, в результате которого выполняется функция обратного вызова, указанная программой резервного копирования при вызове ReadEncryptedFileRaw. Функция EfsReadFileRaw передает считанные шифрованные данные функции обратного вызова, которая записывает их на архивный носитель. Восстанавливаются шифрованные файлы аналогичным образом. Программа резервного копирования вызывает API-функцию WriteEncryptedFileRaw, которая активизирует функцию обратного вызова программы резервного копирования для получения нешифрованных данных с архивного носителя, в то время как Lsasrv-функция EfsWriteFileRaw восстанавливает содержимое файла. Заключение Шифрованная файловая система защищает конфиденциальные данные в файлах на томах NTFS. EFS - основная технология шифрования и расшифровки файлов на томах NTFS. Открывать файл и работать с ним может только пользователь, его зашифровавший. Это чрезвычайно важно