Применение файловой системы ntfs для обеспечения информационной безопасности в windows

Файловая система NTFS появилась еще в Windows NT. Но пусть ее возраст не приводит вас в замешательство. Эта файловая система обладает целым рядом качеств, которые могут обеспечить безопасную, стабильную и надежную работу жестких дисков.

NTFS обеспечивает безопасность на уровне файлов, в отличие от общей безопасности файловой системы FAT. При использовании FAT вы можете запретить или разрешить доступ из сети к части дискового пространства. А с помощью NTFS можно установить доступ к конкретным папкам и файлам. При работе с FAT любой пользователь, расположившийся за компьютером, независимо от способа его регистрации, имеет доступ ко всем вашим файлам.

NTFS является частью сетевой и Windows XP Professional-систем безопасности. В этой лекции рассматриваются методы обеспечения безопасности и использование системы NTFS в Windows XP Professional. Сначала мы рассмотрим отличительные черты NTFS, затем обсудим применение разрешений NTFS. Наконец, если NTFS — это то, что вам подходит, мы поговорим о конвертации FAT в NTFS на вашем жестком диске.

Отличительные черты NTFS

Термины FAT и NTFS являются общими названиями, каждое из которых заключает в себе несколько различных версий этих форматов. Например, существует несколько разновидностей FAT: FAT12, FAT16 и FAT32. Для простоты изложения в этом курсе мы будем их называть просто FAT. С другой стороны, существуют две версии NTFS, а именно версия 4.0 и 5.0.

В этом разделе мы поговорим об отличительных особенностях NTFS, и почему эта система лучше подходит вашей организации, чем FAT. Мы рассмотрим сжатие, шифрование, квоты, а также работу системы в целом. Но сначала давайте разберемся, в чем состоит отличие версии 4.0 файловой системы NTFS от версии 5.0.

4.0 и 5.0

Windows XP Professional предлагает самую свежую версию NTFS. В Windows NT использовалась версия 4.0 NTFS. Система Windows XP Professional пользуется версией 5.0, представленной в Windows 2000. Хотя файловые системы обеих версий приспособлены к взаимному чтению и записи, в Windows XP Professional есть ряд новых качеств, которыми Windows NT не может пользоваться при доступе к жесткому диску с NTFS 5.0.

• Reparse points (Точки повторной обработки). Windows NT не может пользоваться этими точками.
• Disk Quotas (Квотирование диска). Windows NT будет игнорировать квоты на дисковое пространство, установленные Windows XP Professional.
• Encryption (Шифрование). Windows NT не может ни читать, ни делать запись в шифрованных файлах.
• Sparse files (Разреженные файлы). Windows NT не может пользоваться разреженными файлами.
• Change journal (Журнал изменений). Windows NT игнорирует журнал изменений.

Эти добавления делают NTFS v.5.0 мощным инструментом со встроенными возможностями управления, который при правильном применении сделает организацию более продуктивной и эффективной.

Сжатие

Жесткие диски компьютеров становятся все более вместительными. Это происходит потому, что цены на жесткие диски падают, а потребность в дисковом пространстве для хранения файлов растет. Что бы вы ни сохраняли, будь то приложения или мультимедийные файлы, всегда требуется дополнительное место на диске. Но вместо добавления или обновления жестких дисков Windows XP Professional предлагает механизм, который поможет использовать пространство жесткого диска самым оптимальным образом. Это — сжатие папок.

Типы сжатия Windows XP Professional

Windows XP Professional предлагает два типа сжатия папок: NTFS-сжатие и ZIP-сжатие. Выбор метода сжатия будет зависеть от цели, которую вы преследуете, применяя этот метод. Если надо заархивировать данные, то лучше всего применить zip-сжатие. С другой стороны, если файлы, которые вы постоянно используете, захватывают все большее пространство (или есть файлы, которые вы хотите сохранять на жестком диске, но редко ими пользуетесь), то следует обратиться к NTFS-компрессии. Ниже мы рассмотрим особенности этих двух видов сжатия.

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

Примечание. ZipMagic является инструментом сторонних разработчиков, который позволяет работать с ZIP-файлами, как если бы они были системными файлами. Для получения более подробной информации о ZipMagic зайдите на http://www.ontrack.com/zipmagic.

NTFS. Сейчас нас больше интересует NTFS-сжатие. Этот вид компрессии подходит как для папок, так и для файлов, но работает только при NTFS-делении дискового пространства (еще один повод конвертировать диск в NTFS). Кроме того, NTFS-компрессия совершенно «прозрачна» (незаметна) для приложений и пользователей. Когда приложение открывает сжатый файл, то NTFS выполняет декомпрессию только той части файла, которая читается в данный момент, и копирует ее в память. Так как порция данных в памяти находится в сжатом состоянии, то работе системы ничто не мешает. Если данные нужно сохранить в файле, то компьютер должен сжать файл. В NTFS это выполняется достаточно легко. Просто включите компрессию в меню Properties (Свойства) файла или папки.

Размер сжатого файла или папки будет зависеть от типа файла. Например, при сжатии документа Word можно ожидать довольно значительного сжатия — со 120 Кб до 50 Кб. С другой стороны, при сжатии графического файла вы не достигнете такого же уровня компрессии. Изображение вашей тети Матильды, составляющее 120 Кб, после сжатия будет занимать на диске около 90 Кб.

Обращаясь к компрессии, вы также должны подумать о том, что она затронет процесс доступа к файлу (хотя и не так сильно, как об этом упоминалось ранее в связи с NTFS-сжатыми файлами). Это особенно заметно, когда сжат весь диск целиком, а не отдельный файл или папка. Компьютеру приходится выполнять задание по сжатию и декомпрессии файла, так что, если таких файлов много, то система будет загружена работой.

Тома

Если вы хотите выжать из своего жесткого диска все пространство «до последней капли», то можете подвергнуть сжатию весь том. В зависимости от величины тома, количества файлов, содержащихся в нем, и скорости компьютера процесс может занять несколько минут. По сравнению со сжатием файлов или папок выполнение этого задания занимает больше времени, потому что Windows XP Professional должна пройтись по всем папкам и изменить уровень сжатия, а затем сжать (или наоборот) каждый файл в папке.

Для сжатия полного тома проделайте следующие шаги.

1. Используя Windows Explorer или через меню My Computer (Мой компьютер), найдите том, который надо сжать.
2. Щелкните правой кнопкой мыши на томе и выберите Properties (Свойства).
3. На вкладке General (Общие) (рис. 10.1) отметьте (или снимите отметку, если вы хотите декомпрессировать том) флажок Compress drive to save disk space (Сжать диск для экономии места).
4. Нажмите на ОК.
5. Далее вы увидите диалоговое окно Confirm Attribute Changes (Подтверждение изменения атрибутов). Выберите либо сжатие всего тома, либо корневой папки.

Файлы и папки

В зависимости от потребностей и желаний вы можете выбрать только несколько папок или файлов, которые надо компрессировать. Система NTFS позволяет сжимать отдельные папки и файлы. Для выполнения компрессии отдельных файлов и папок проделайте следующие действия.

1. Используя Windows Explorer или через меню My Computer (Мой компьютер), найдите файл или папку, который вы хотите компрессировать.
2. Щелкните правой кнопкой мыши на объекте и выберите Properties (Свойства).
3. На вкладке General (Общие) щелкните на кнопке Advanced (Дополнительно).
4. В диалоговом окне Advanced Attributes (Дополнительные атрибуты) (рис. 10.2) выберите (или очистите, если вы хотите провести декомпрессию раздела) флажок Compress contents to save disk space (Сжать содержимое для экономии места).

   

   Рис.
   10.2.
   Сжатие файла или папки

5. Щелкните на ОК.
6. В окне свойств щелкните на ОК.
7. При сжатии папки Windows XP Professional спросит, нужно ли сжать только папку или сжать папку со всеми подкаталогами и файлами. Сделайте свой выбор и нажмите на ОК.

Когда вы посмотрите на Windows Explorer, то заметите, что сжатые файлы и папки выглядят несколько иначе. Имена сжатых файлов и папок напечатаны синим шрифтом. Это служит напоминанием о том, какие папки и файлы являются сжатыми, а какие нет.

Как известно, файловая система NTFS оснащена функцией шифрования данных на диске, поэтому, если в свойствах файла поставить галочку на соответствующей опции, то он будет физически зашифрован. Кроме этого, пользователь может манипулировать правами доступа к тем или иным объектам (см. скриншоты)
Однако при переустановке Windows или подключении жесткого диска к другому компьютеру все указанные ранее права доступа пропадут, и файл будет доступен абсолютно всем. Если же файл был зашифрован, то при сбросе прав доступа он все равно останется зашифрованным, и прочитать его с другой машины будет невозможно (если туда не были предварительно экспортированы соответствующие сертификаты шифрования). Теоретически все просто и надёжно.

Как известно, файловая система NTFS оснащена функцией шифрования данных на диске, поэтому, если в свойствах файла поставить галочку на соответствующей опции, то он будет физически зашифрован. Кроме этого, пользователь может манипулировать правами доступа к тем или иным объектам (см. скриншоты)
Однако при переустановке Windows или подключении жесткого диска к другому компьютеру все указанные ранее права доступа пропадут, и файл будет доступен абсолютно всем. Если же файл был зашифрован, то при сбросе прав доступа он все равно останется зашифрованным, и прочитать его с другой машины будет невозможно (если туда не были предварительно экспортированы соответствующие сертификаты шифрования). Теоретически все просто и надёжно.

А практически сами файлы ключей не зашифрованы, так как по умолчанию пароль к ним хранится на том же системном диске. Как следствие, вскрыть информацию в таком случае — плевое дело. Добавьте сюда массу общедоступных хакерских утилит, в большинстве случаев позволяющих за разумное время «распотрошить» любой зашифрованный файл, достаточно только подключить винчестер к другому ПК (или загрузиться с компакт-диска Windows PE (версии Windows, которые запускаются и работают непосредственно с компакт-диска. Используются для восстановления системы или данных).

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

Далее — в меню «Управление компьютером -> Служебные программы -> Локальные пользователи и группы -> Пользователи».

Сразу предупредим, что разные системные аккаунты трогать не следует, особенно если вы не знаете, зачем они нужны (однако можно их просто отключить и посмотреть результаты). Удалите явно ненужных пользователей.
Обратите внимание, что в Windows XP по умолчанию обычно получается два администраторских логина: один стандартный, а второй — первого из пользователей, вошедших в систему сразу после установки. И по невнимательности на одном из них может вообще не быть пароля. Дополнительно на всех существующих аккаунтах следует установить пароли не короче 16 символов! В противном случае их легко вскрыть в течение нескольких дней или даже часов (На то две причины. Во-первых, пароли короче 14 знаков можно быстрее подбирать по старому упрощенному алгоритму. Во-вторых, каждый дополнительный знак увеличивает общее время перебора примерно в 140 раз.)
В пароле не следует использовать словарные слова и какие-либо осмысленные названия (существуют базы, в которых содержится порядка трех миллионов популярных парольных слов). Пароль также не должен состоять из одних только цифр. Помните, что менять пароль можно только в меню «Панель управления -> Учетные записи пользователей», иначе доступ к ранее зашифрованным файлам безвозвратно пропадет.
Пункт второй. Не используйте автоматический вход в Windows. Система должна всегда запрашивать имя и пароль. Если вход в операционную систему автоматический, это надо устранить. Идем в меню «Пуск -> Выполнить», вводим команду control userpasswords2.

В появившемся окне ставим галочку на опции «Требовать ввод имени пользователя и пароля».

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

Проходим в меню «Пуск -> Выполнить», вводим команду syskey. Должно появиться окно управления шифрованием базы данных паролей.

Нажимаем кнопку «Обновить» для отображения настроек.

Как видим, по умолчанию ключ шифрования паролей хранится в системе. Выбираем режим требования ввода пароля при запуске системы. Указываем пароль — тоже не словарный и длинный. Готово. Теперь ключевое слово будет запрашиваться при каждой загрузке Windows, еще задолго до появления привычного окна выбора пользователя.

Этот пароль — общий для всех, его необходимо знать всем пользователям (что, кстати, снимает все преимущества такой дополнительной защиты в том случае, если ломать систему будет один из знающих пароль пользователей). Обычные персональные пользовательские логины и пароли никуда не денутся, они будут тоже запрашиваться как обычно, после ввода общего пароля.
Наконец, отметим еще одну потенциальную уязвимость зашифрованных данных. Большинство программ при работе создают временные файлы, в которых хранят обрабатываемые данные (или, к примеру, копию для возможности Undo), и эти временные файлы обычно не зашифрованы. Злоумышленник может, воспользовавшись любой из многочисленных Unerase-программ, восстановить эти файлы.
Для борьбы с этим следует после работы с зашифрованными файлами затирать пустое место на жестком диске при помощи Wipe-утилит (они входят, в частности, в ОС Windows и в состав Norton Utilities, Acronis, PGP Desktop и других подобных пакетов). В ряде случаев обход этой проблемы обеспечивается установкой шифрования временной папки (на которые ссылаются системные переменные %temp% и %tmp%), применяя шифрование не к отдельному файлу, а к целым директориям.
P.S. Следует трезво осознавать, что вышеперечисленные меры не дают стопроцентной гарантии безопасности. Если диск украден целенаправленно, и данные заведомо представляют коммерческий интерес, то злоумышленники, скорее всего, найдут возможность как-то обойти эти меры.

Операционные системы Microsoft семейства Windows NT нельзя представить без файловой системы NTFS — одной из самых сложных и удачных из существующих на данный момент файловых систем. Данная статья расскажет вам, в чем особенности и недостатки этой системы, на каких принципах основана организация информации, и как поддерживать систему в стабильном состоянии, какие возможности предлагает NTFS и как их можно использовать обычному пользователю.

Часть 1. Физическая структура NTFS

Начнем с общих фактов. Раздел NTFS, теоретически, может быть почти какого угодно размера. Предел, конечно, есть, но я даже не буду указывать его, так как его с запасом хватит на последующие сто лет развития вычислительной техники — при любых темпах роста. Как обстоит с этим дело на практике? Почти так же. Максимальный размер раздела NTFS в данный момент ограничен лишь размерами жестких дисков. NT4, правда, будет испытывать проблемы при попытке установки на раздел, если хоть какая-нибудь его часть отступает более чем на 8 Гб от физического начала диска, но эта проблема касается лишь загрузочного раздела.

Лирическое отступление. Метод инсталляции NT4.0 на пустой диск довольно оригинален и может навести на неправильные мысли о возможностях NTFS. Если вы укажете программе установки, что желаете отформатировать диск в NTFS, максимальный размер, который она вам предложит, будет всего 4 Гб. Почему так мало, если размер раздела NTFS на самом деле практически неограничен? Дело в том, что установочная секция просто не знает этой файловой системы Программа установки форматирует этот диск в обычный FAT, максимальный размер которого в NT составляет 4 Гбайт (с использованием не совсем стандартного огромного кластера 64 Кбайта), и на этот FAT устанавливает NT. А вот уже в процессе первой загрузки самой операционной системы (еще в установочной фазе) производится быстрое преобразование раздела в NTFS; так что пользователь ничего и не замечает, кроме странного «ограничения» на размер NTFS при установке.

Структура раздела — общий взгляд

Как и любая другая система, NTFS делит все полезное место на кластеры — блоки данных, используемые единовременно. NTFS поддерживает почти любые размеры кластеров — от 512 байт до 64 Кбайт, неким стандартом же считается кластер размером 4 Кбайт. Никаких аномалий кластерной структуры NTFS не имеет, поэтому на эту, в общем-то, довольно банальную тему, сказать особо нечего.

Диск NTFS условно делится на две части. Первые 12% диска отводятся под так называемую MFT зону — пространство, в которое растет метафайл MFT (об этом ниже). Запись каких-либо данных в эту область невозможна. MFT-зона всегда держится пустой — это делается для того, чтобы самый главный, служебный файл (MFT) не фрагментировался при своем росте. Остальные 88% диска представляют собой обычное пространство для хранения файлов.

Свободное место диска, однако, включает в себя всё физически свободное место — незаполненные куски MFT-зоны туда тоже включаются. Механизм использования MFT-зоны таков: когда файлы уже нельзя записывать в обычное пространство, MFT-зона просто сокращается (в текущих версиях операционных систем ровно в два раза), освобождая таким образом место для записи файлов. При освобождении места в обычной области MFT зона может снова расширится. При этом не исключена ситуация, когда в этой зоне остались и обычные файлы: никакой аномалии тут нет. Что ж, система старалась оставить её свободной, но ничего не получилось. Жизнь продолжается… Метафайл MFT все-таки может фрагментироваться, хоть это и было бы нежелательно.

MFT и его структура

Файловая система NTFS представляет собой выдающееся достижение структуризации: каждый элемент системы представляет собой файл — даже служебная информация. Самый главный файл на NTFS называется MFT, или Master File Table — общая таблица файлов. Именно он размещается в MFT зоне и представляет собой централизованный каталог всех остальных файлов диска, и, как не парадоксально, себя самого. MFT поделен на записи фиксированного размера (обычно 1 Кбайт), и каждая запись соответствует какому либо файлу (в общем смысле этого слова). Первые 16 файлов носят служебный характер и недоступны операционной системе — они называются метафайлами, причем самый первый метафайл — сам MFT. Эти первые 16 элементов MFT — единственная часть диска, имеющая фиксированное положение. Интересно, что вторая копия первых трех записей, для надежности — они очень важны — хранится ровно посередине диска. Остальной MFT-файл может располагаться, как и любой другой файл, в произвольных местах диска — восстановить его положение можно с помощью его самого, «зацепившись» за самую основу — за первый элемент MFT.

Метафайлы

Первые 16 файлов NTFS (метафайлы) носят служебный характер. Каждый из них отвечает за какой-либо аспект работы системы. Преимущество настолько модульного подхода заключается в поразительной гибкости — например, на FAT-е физическое повреждение в самой области FAT фатально для функционирования всего диска, а NTFS может сместить, даже фрагментировать по диску, все свои служебные области, обойдя любые неисправности поверхности — кроме первых 16 элементов MFT.

Метафайлы находятся корневом каталоге NTFS диска — они начинаются с символа имени «$», хотя получить какую-либо информацию о них стандартными средствами сложно. Любопытно, что и для этих файлов указан вполне реальный размер — можно узнать, например, сколько операционная система тратит на каталогизацию всего вашего диска, посмотрев размер файла $MFT. В следующей таблице приведены используемые в данный момент метафайлы и их назначение.

Файлы и потоки

Итак, у системы есть файлы — и ничего кроме файлов. Что включает в себя это понятие на NTFS?

• Прежде всего, обязательный элемент — запись в MFT, ведь, как было сказано ранее, все файлы диска упоминаются в MFT. В этом месте хранится вся информация о файле, за исключением собственно данных. Имя файла, размер, положение на диске отдельных фрагментов, и т. д. Если для информации не хватает одной записи MFT, то используются несколько, причем не обязательно подряд.
• Опциональный элемент — потоки данных файла. Может показаться странным определение «опциональный», но, тем не менее, ничего странного тут нет. Во-первых, файл может не иметь данных — в таком случае на него не расходуется свободное место самого диска. Во-вторых, файл может иметь не очень большой размер. Тогда идет в ход довольно удачное решение: данные файла хранятся прямо в MFT, в оставшемся от основных данных месте в пределах одной записи MFT. Файлы, занимающие сотни байт, обычно не имеют своего «физического» воплощения в основной файловой области — все данные такого файла хранятся в одном месте — в MFT.

Довольно интересно обстоит дело и с данными файла. Каждый файл на NTFS, в общем-то, имеет несколько абстрактное строение — у него нет как таковых данных, а есть потоки (streams). Один из потоков и носит привычный нам смысл — данные файла. Но большинство атрибутов файла — тоже потоки! Таким образом, получается, что базовая сущность у файла только одна — номер в MFT, а всё остальное опционально. Данная абстракция может использоваться для создания довольно удобных вещей — например, файлу можно «прилепить» еще один поток, записав в него любые данные — например, информацию об авторе и содержании файла, как это сделано в Windows 2000 (самая правая закладка в свойствах файла, просматриваемых из проводника). Интересно, что эти дополнительные потоки не видны стандартными средствами: наблюдаемый размер файла — это лишь размер основного потока, который содержит традиционные данные. Можно, к примеру, иметь файл нулевой длинны, при стирании которого освободится 1 Гбайт свободного места — просто потому, что какая-нибудь хитрая программа или технология прилепила в нему дополнительный поток (альтернативные данные) гигабайтового размера. Но на самом деле в текущий момент потоки практически не используются, так что опасаться подобных ситуаций не следует, хотя гипотетически они возможны. Просто имейте в виду, что файл на NTFS — это более глубокое и глобальное понятие, чем можно себе вообразить просто просматривая каталоги диска. Ну и напоследок: имя файла может содержать любые символы, включая полый набор национальных алфавитов, так как данные представлены в Unicode — 16-битном представлении, которое дает 65535 разных символов. Максимальная длина имени файла — 255 символов.

Каталоги

Каталог на NTFS представляет собой специфический файл, хранящий ссылки на другие файлы и каталоги, создавая иерархическое строение данных на диске. Файл каталога поделен на блоки, каждый из которых содержит имя файла, базовые атрибуты и ссылку на элемент MFT, который уже предоставляет полную информацию об элементе каталога. Внутренняя структура каталога представляет собой бинарное дерево. Вот что это означает: для поиска файла с данным именем в линейном каталоге, таком, например, как у FAT-а, операционной системе приходится просматривать все элементы каталога, пока она не найдет нужный. Бинарное же дерево располагает имена файлов таким образом, чтобы поиск файла осуществлялся более быстрым способом — с помощью получения двухзначных ответов на вопросы о положении файла. Вопрос, на который бинарное дерево способно дать ответ, таков: в какой группе, относительно данного элемента, находится искомое имя — выше или ниже? Мы начинаем с такого вопроса к среднему элементу, и каждый ответ сужает зону поиска в среднем в два раза. Файлы, скажем, просто отсортированы по алфавиту, и ответ на вопрос осуществляется очевидным способом — сравнением начальных букв. Область поиска, суженная в два раза, начинает исследоваться аналогичным образом, начиная опять же со среднего элемента.

Вывод — для поиска одного файла среди 1000, например, FAT придется осуществить в среднем 500 сравнений (наиболее вероятно, что файл будет найден на середине поиска), а системе на основе дерева — всего около 12-ти (2^10 = 1024). Экономия времени поиска налицо. Не стоит, однако думать, что в традиционных системах (FAT) всё так запущено: во-первых, поддержание списка файлов в виде бинарного дерева довольно трудоемко, а во-вторых — даже FAT в исполнении современной системы (Windows2000 или Windows98) использует сходную оптимизацию поиска. Это просто еще один факт в вашу копилку знаний. Хочется также развеять распространенное заблуждение (которое я сам разделял совсем еще недавно) о том, что добавлять файл в каталог в виде дерева труднее, чем в линейный каталог: это достаточно сравнимые по времени операции — дело в том, что для того, чтобы добавить файл в каталог, нужно сначала убедится, что файла с таким именем там еще нет — и вот тут-то в линейной системе у нас будут трудности с поиском файла, описанные выше, которые с лихвой компенсируют саму простоту добавления файла в каталог.

Какую информацию можно получить, просто прочитав файл каталога? Ровно то, что выдает команда dir. Для выполнения простейшей навигации по диску не нужно лазить в MFT за каждым файлом, надо лишь читать самую общую информацию о файлах из файлов каталогов. Главный каталог диска — корневой — ничем не отличается об обычных каталогов, кроме специальной ссылки на него из начала метафайла MFT.

Журналирование

NTFS — отказоустойчивая система, которая вполне может привести себя в корректное состояние при практически любых реальных сбоях. Любая современная файловая система основана на таком понятии, как транзакция — действие, совершаемое целиком и корректно или не совершаемое вообще. У NTFS просто не бывает промежуточных (ошибочных или некорректных) состояний — квант изменения данных не может быть поделен на до и после сбоя, принося разрушения и путаницу — он либо совершен, либо отменен.

Пример 1: осуществляется запись данных на диск. Вдруг выясняется, что в то место, куда мы только что решили записать очередную порцию данных, писать не удалось — физическое повреждение поверхности. Поведение NTFS в этом случае довольно логично: транзакция записи откатывается целиком — система осознает, что запись не произведена. Место помечается как сбойное, а данные записываются в другое место — начинается новая транзакция.

Пример 2: более сложный случай — идет запись данных на диск. Вдруг, бах — отключается питание и система перезагружается. На какой фазе остановилась запись, где есть данные, а где чушь? На помощь приходит другой механизм системы — журнал транзакций. Дело в том, что система, осознав свое желание писать на диск, пометила в метафайле $LogFile это свое состояние. При перезагрузке это файл изучается на предмет наличия незавершенных транзакций, которые были прерваны аварией и результат которых непредсказуем — все эти транзакции отменяются: место, в которое осуществлялась запись, помечается снова как свободное, индексы и элементы MFT приводятся в с состояние, в котором они были до сбоя, и система в целом остается стабильна. Ну а если ошибка произошла при записи в журнал? Тоже ничего страшного: транзакция либо еще и не начиналась (идет только попытка записать намерения её произвести), либо уже закончилась — то есть идет попытка записать, что транзакция на самом деле уже выполнена. В последнем случае при следующей загрузке система сама вполне разберется, что на самом деле всё и так записано корректно, и не обратит внимания на «незаконченную» транзакцию.

И все-таки помните, что журналирование — не абсолютная панацея, а лишь средство существенно сократить число ошибок и сбоев системы. Вряд ли рядовой пользователь NTFS хоть когда-нибудь заметит ошибку системы или вынужден будет запускать chkdsk — опыт показывает, что NTFS восстанавливается в полностью корректное состояние даже при сбоях в очень загруженные дисковой активностью моменты. Вы можете даже оптимизировать диск и в самый разгар этого процесса нажать reset — вероятность потерь данных даже в этом случае будет очень низка. Важно понимать, однако, что система восстановления NTFS гарантирует корректность файловой системы, а не ваших данных. Если вы производили запись на диск и получили аварию — ваши данные могут и не записаться. Чудес не бывает.

Сжатие

Файлы NTFS имеют один довольно полезный атрибут — «сжатый». Дело в том, что NTFS имеет встроенную поддержку сжатия дисков — то, для чего раньше приходилось использовать Stacker или DoubleSpace. Любой файл или каталог в индивидуальном порядке может хранится на диске в сжатом виде — этот процесс совершенно прозрачен для приложений. Сжатие файлов имеет очень высокую скорость и только одно большое отрицательное свойство — огромная виртуальная фрагментация сжатых файлов, которая, правда, никому особо не мешает. Сжатие осуществляется блоками по 16 кластеров и использует так называемые «виртуальные кластеры» — опять же предельно гибкое решение, позволяющее добиться интересных эффектов — например, половина файла может быть сжата, а половина — нет. Это достигается благодаря тому, что хранение информации о компрессированности определенных фрагментов очень похоже на обычную фрагментацию файлов: например, типичная запись физической раскладки для реального, несжатого, файла:

кластеры файла с 1 по 43-й хранятся в кластерах диска начиная с 400-го

кластеры файла с 44 по 52-й хранятся в кластерах диска начиная с 8530-го…

Физическая раскладка типичного сжатого файла:

кластеры файла с 1 по 9-й хранятся в кластерах диска начиная с 400-го

кластеры файла с 10 по 16-й нигде не хранятся

кластеры файла с 17 по 18-й хранятся в кластерах диска начиная с 409-го

кластеры файла с 19 по 36-й нигде не хранятся

Видно, что сжатый файл имеет «виртуальные» кластеры, реальной информации в которых нет. Как только система видит такие виртуальные кластеры, она тут же понимает, что данные предыдущего блока, кратного 16-ти, должны быть разжаты, а получившиеся данные как раз заполнят виртуальные кластеры — вот, по сути, и весь алгоритм.

Безопасность

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

Права файловой системы NTFS неразрывно связаны с самой системой — то есть они, вообще говоря, необязательны к соблюдению другой системой, если ей дать физический доступ к диску. Для предотвращения физического доступа в Windows2000 (NT5) всё же ввели стандартную возможность — об этом см. ниже. Система прав в своем текущем состоянии достаточно сложна, и я сомневаюсь, что смогу сказать широкому читателю что-нибудь интересное и полезное ему в обычной жизни. Если вас интересует эта тема — вы найдете множество книг по сетевой архитектуре NT, в которых это описано более чем подробно.

На этом описание строение файловой системы можно закончить, осталось описать лишь некоторое количество просто практичных или оригинальных вещей.

Hard Links

Эта штука была в NTFS с незапамятных времен, но использовалась очень редко — и тем не менее: Hard Link — это когда один и тот же файл имеет два имени (несколько указателей файла-каталога или разных каталогов указывают на одну и ту же MFT запись). Допустим, один и тот же файл имеет имена 1.txt и 2.txt: если пользователь сотрет файл 1, останется файл 2. Если сотрет 2 — останется файл 1, то есть оба имени, с момента создания, совершенно равноправны. Файл физически стирается лишь тогда, когда будет удалено его последнее имя.

Symbolic Links (NT5)

Гораздо более практичная возможность, позволяющая делать виртуальные каталоги — ровно так же, как и виртуальные диски командой subst в DOSе. Применения достаточно разнообразны: во-первых, упрощение системы каталогов. Если вам не нравится каталог Documents and settingsAdministratorDocuments, вы можете прилинковать его в корневой каталог — система будет по прежнему общаться с каталогом с дремучим путем, а вы — с гораздо более коротким именем, полностью ему эквивалентным. Для создания таких связей можно воспользоваться программой junction (junction.zip, 15 Кб), которую написал известный специалист Mark Russinovich. Программа работает только в NT5 (Windows 2000), как и сама возможность.

Для удаления связи можно воспользоваться стандартной командой rd.
ВНИМАНИЕ: Попытка уделения связи с помощью проводника или других файловых менеджеров, не понимающих виртуальную природу каталога (например, FAR), приведет к удалению данных, на которые ссылается ссылка! Будьте осторожны.

Шифрование (NT5)

Полезная возможность для людей, которые беспокоятся за свои секреты — каждый файл или каталог может также быть зашифрован, что не даст возможность прочесть его другой инсталляцией NT. В сочетании со стандартным и практически непрошибаемым паролем на загрузку самой системы, эта возможность обеспечивает достаточную для большинства применений безопасность избранных вами важных данных.Часть 2. Особенности дефрагментации NTFS

Вернемся к одному достаточно интересному и важному моменту — фрагментации и дефрагментации NTFS. Дело в том, что ситуация, сложившаяся с этими двумя понятиями в настоящий момент, никак не может быть названа удовлетворительной. В самом начале утверждалось, что NTFS не подвержена фрагментации файлов. Это оказалось не совсем так, и утверждение сменили — NTFS препятствует фрагментации. Оказалось, что и это не совсем так. То есть она, конечно, препятствует, но толк от этого близок к нулю… Сейчас уже понятно, что NTFS — система, которая как никакая другая предрасположена к фрагментации, что бы ни утверждалось официально. Единственное что — логически она не очень от этого страдает. Все внутренние структуры построены таким образом, что фрагментация не мешает быстро находить фрагменты данных. Но от физического последствия фрагментации — лишних движений головок — она, конечно, не спасает. И поэтому — вперед и с песней.

К истокам проблемы

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

Диск NTFS поделен на две зоны. В начала диска идет MFT зона — зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется — зона сокращается ровно в два раза :). И так далее. Таким образом мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном на около 90% — фрагментация растет как бешенная.

Попутное следствие — диск, заполненный более чем на 88%, дефрагментировать почти невозможно — даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет свободного места для маневра.

Далее. NTFS работает себе и работает, и всё таки фрагментируется — даже в том случае, если свободное место далеко от истощения. Этому способствует странный алгоритм нахождения свободного места для записи файлов — второе серьезное упущение. Алгоритм действий при любой записи такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем по очень интересному алгоритму: сначала заполняются большие дырки, потом маленькие. Т.е. типичное распределение фрагментов файла по размеру на фрагментированной NTFS выглядит так (размеры фрагментов):

16 — 16 — 16 — 16 — 16 — [скачек назад] — 15 — 15 — 15 — [назад] — 14 — 14 — 14 …. 1 — 1 — 1 -1 — 1…

Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что на диске наверняка есть и гораздо более большие куски свободного места.

Вспомните сжатые файлы — при активной перезаписи больших объемов сжатой информации на NTFS образуется гигантское количество «дырок» из-за перераспределения на диске сжатых объемов — если какой-либо участок файла стал сжиматься лучше или хуже, его приходится либо изымать из непрерывной цепочки и размещать в другом месте, либо стягивать в объеме, оставляя за собой дырку.

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

Средства решения?

В NT существует стандартное API дефрагментации. Обладающее интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров (!), причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия:

1. В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это неинтересные в данный момент тонкости).
2. Файл, будучи перемещенный в другое место, оставляет после себя (на новом месте) «временно занятое место», дополняющее его по размеру до кратности 16 кластерам.
3. При попытке как-то неправильно (»не кратно 16») переместить файл результат часто непредсказуем. Что-то округляется, что-то просто не перемещается… Тем не менее, всё место действия щедро рассыпается «временно занятым местом».

«Временно занятое место» служит для облегчения восстановления системы в случае аппаратного сбоя и освобождается через некоторое время, обычно где-то пол минуты.

Тем не менее, логично было бы использовать это API, раз он есть. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, состоит из следующих фаз (не обязательно в этом порядке):

• Вынимание файлов из MFT зоны. Не специально — просто обратно туда их положить не представляется возможным Безобидная фаза, и даже в чем то полезная.
• Дефрагментация файлов. Безусловно, полезный процесс, несколько, правда, осложняемый ограничениями кратности перемещений — файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.
• Дефрагментация MFT, виртуалки (pagefile.sys) и каталогов. Возможна через API только в Windows2000, иначе — при перезагрузке, отдельным процессом, как в старом Diskeeper-е.
• Складывание файлов ближе к началу — так называемая дефрагментация свободного места. Вот это — воистину страшный процесс.

Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий — после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку <16 кластеров размером. Которую потом невозможно заполнить через API дефрагментации! В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации — одна дыра в конце диска, и много маленьких <16 кластеров дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно, находящиеся ближе к началу диска мелкие дырки <16 кластеров… Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз.. и еще.. и так — желательно каждую неделю. Бред? Реальность.

Таким образом, имеется два примерно равнозначных варианта. Первый — часто оптимизировать диск таким дефрагментатором, смиряясь при этом с дикой фрагментацией заново созданных файлов. Второй вариант — вообще ничего не трогать, и смириться с равномерной, но гораздо более слабой фрагментацией всех файлов на диске.

Пока есть всего один дефрагментатор, который игнорирует API дефрагментации и работает как-то более напрямую — Norton Speeddisk 5.0 для NT. Когда его пытаются сравнить со всеми остальными — Diskeeper, O&O defrag, т. д. — не упоминают этого главного, самого принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере уж точно не афишируется на каждом шагу. Speeddisk — единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места. Стоит добавить также, что при помощи стандартного API невозможно дефрагментировать тома NTFS с кластером более 4 Кбайт, а SpeedDisk и это может.

К сожалению, в Windows 2000 поместили дефрагментатор, который работает через API, и, соответственно, плодит дырки <16 кластеров. Так что как только появится (если еще не появился) — так сразу надо качать Speeddisk для W2k.

Как некоторый вывод из всего этого: все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз — нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации новоприбывающих файлов. В этом основная суть сложности дефрагментации NTFS теми средствами, которые сложились исторически.Часть 3. Что выбрать?

Любая из представленных ныне файловых систем уходит своими корнями в глубокое прошлое — еще к 80-м годам. Да, NTFS, как это не странно — очень старая система! Дело в том, что долгое время персональные компьютеры пользовались лишь операционной системой DOS, которой и обязана своим появлением FAT. Но параллельно разрабатывались и тихо существовали системы, нацеленные на будущее. Две таких системы, получившие всё же широкое признание — NTFS, созданная для операционной системы Windows NT 3.1 еще в незапамятные времена, и HPFS — верная спутница OS/2.

Внедрение новых систем шло трудно — еще в 95м году, с выходом Windows95, ни у кого не было и мыслей о том, что что-то нужно менять — FAT получил второе дыхание посредством налепленной сверху заплатки «длинные имена», реализация которых там хоть и близка к идеально возможной без изменения системы, но всё же довольно бестолкова. Но в последующие годы необходимость перемен назрела окончательно, поскольку естественные ограничения FAT стали давать о себе знать. FAT32, появившаяся в Windows 95 OSR2, просто сдвинула рамки — не изменив сути системы, которая просто не дает возможности организовать эффективную работу с большим количеством данных.

HPFS (High Performance File System), активно применяемая до сих пор пользователями OS/2, показала себя достаточно удачной системой, но и она имела существенные недостатки — полное отсутствие средств автоматической восстанавливаемости, излишнюю сложность организации данных и невысокую гибкость.

NTFS же долго не могла завоевать персональные компьютеры из-за того, что для организации эффективной работы с её структурами данных требовались значительные объемы памяти. Системы с 4 или 8 Мбайт (стандарт 95-96 годов) были просто неспособны получить хоть какой-либо плюс от NTFS, поэтому за ней закрепилась не очень правильная репутация медленной и громоздкой системы. На самом деле это не соответствует действительности — современные компьютерные системы с памятью более 64 Мб получают просто огромный прирост производительности от использования NTFS.

В данной таблице сведены воедино все существенные плюсы и минусы распространенных в наше время систем, таких как FAT32, FAT и NTFS. Вряд ли разумно обсуждать другие системы, так как в настоящее время 97% пользователей делают выбор между Windows98, Windows NT4.0 и Windows 2000 (NT5.0), а других вариантов там просто нет.

Хотелось бы выразить искреннюю признательность Андрею Шабалину, без которого эта статья просто не была бы написана, а даже будучи написанной, содержала бы много досадных неточностей

Продолжение читайте в статье «Надежность дисковой системы NT»

Файловая
система NTFS делит дисковое
пространство тома на кластеры размером
от 512 байт до 64 Кб. Размер кластера обычно
не превышает 4Кб. Все дисковое пространство
в NTFS делится на две неравные
части. Первые 12% диска отводятся под
зону MFT – главной таблицы
файлов. Эта таблица представляет собой
специальный файл, содержащий информацию
о размещении всех остальных файлов.
Остальные 88% тома представляют собой
обычное пространство для записи файлов.

Каждая
запись соответствует конкретному файлу.
Первые 16 файлов тома являются служебными
и недоступны через интерфейс операционной
системы. Эти файлы называются метафайлами,
причем самый первый метафайл – это сам
файл MFT.
Метафайлы находятся в корневом каталоге
тома NTFS.
Их имена начинаются с символа « $ ».

В
таблице MFT
хранится вся информация о файлах: имя
файла, его размер, расположение на диске
и т.п. Если для размещения информации
не хватает одной записи MFT,
то используется несколько таких записей,
причем необязательно последовательных.

Файлы
NTFS имеют полезный атрибут — «сжатый».
NTFS имеет встроенную поддержку сжатия
дисков. Любой файл или каталог в
индивидуальном порядке может хранится
на диске в сжатом виде — этот процесс
совершенно прозрачен для приложений.

Плюсы NTFS:

1. Возможность доступа
   к фрагментам файла;

2. Быстрый
   доступ к коротким файлам.

Минусы NTFS:

1. ОЗУ не меньше 64
   Мбайт;

2. Медленные
   диски снижают быстродействие NTFS;

3. Значительное
   снижение быстродействия если диска
   заполнен на 80%.

Возможности
NTFS
по отношению к FAT:

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

2. Шифрование
   файла.

3. RAID
   – дисковый массив, зеркалирование
   диска.

4. Volume
   Set
   – возможность объединять в один
   логический том несколько разделов на
   логических и физических дисках.

5. Hard
   link.
   Файл может иметь несколько жёстких
   ссылок, то есть одновременно фигурировать
   на диске под различными именами и/или
   различных каталогах. Количество жёстких
   ссылок файла (то есть количество его
   имён) хранится в метаинформации на
   уровне файловой системы.

6. Переходы.
   Внутри каталога можно смонтировать
   физический диск.

7. Квотирование
   дискового пространства.

8. Ведение
   журнала изменений.

1. Назначение
   и структура алгоритмов шифрования.
   Обзор криптографических методов
   (электронная подпись, суммирование по
   ключу, применение генераторов
   псевдослучайных чисел). Структура
   алгоритмов шифрования и их эволюция.

Криптография
— это наука о защите информации. Шифрование
решает одну из основных проблем защиты
информации – а именно, проблему
обеспечения конфиденциальности данных.
Большое число современных алгоритмов
шифрования работают весьма схожим
образом: над шифруемым текстом выполняется
некое преобразование с участием ключа
шифрования, которое повторяется
определенное число раз (раундов).

Классификация
алгоритмов шифрования

• Симметричные
  (с секретным, единым ключом, одноключевые,
  single-key).

  • Потоковые
    (шифрование потока данных):

    • с
      одноразовым или бесконечным ключом
      (infinite-key cipher);

    • с
      конечным ключом (система Вернама —
      Vernam);

    • на
      основе генератора псевдослучайных
      чисел (ПСЧ).

  • Блочные
    (шифрование данных поблочно):

    • Шифры
      перестановки (permutation, P-блоки);

    • Шифры
      замены (подстановки, substitution, S-блоки):

    • моноалфавитные
      (код Цезаря);

    • полиалфавитные
      (шифр Видженера, цилиндр Джефферсона,
      диск Уэтстоуна, Enigma);

  • Cоставные:

    • Lucipher
      (фирма IBM, США);

    • DES
      (Data Encryption Standard, США);

    • FEAL-1
      (Fast Enciphering Algoritm, Япония);

    • IDEA/IPES
      (International Data Encryption Algorithm/

    • Improved
      Proposed Encryption Standard, фирма
      Ascom-Tech AG, Швейцария);

    • B-Crypt
      (фирма British Telecom, Великобритания);

    • ГОСТ
      28147-89 (СССР); * Skipjack (США).

• Асимметричные
  (с открытым ключом, public-key):

  • Диффи-Хеллман
    DH (Diffie, Hellman);

  • Райвест-Шамир-Адлeман
    RSA (Rivest, Shamir, Adleman);

  • Эль-Гамаль
    ElGamal.

Электронная
цифровая подпись (ЭЦП) используется для
подтверждения целостности и авторства
данных. Как и в случае асимметричного
шифрования, в данном методе применяются
двухключевые алгоритмы с таким же
простым вычислением открытого ключа
из секретного и практической невозможностью
обратного вычисления. Однако назначение
ключей ЭЦП совершенно иное. Секретный
ключ применяется для вычисления ЭЦП,
открытый ключ необходим для ее проверки.
При соблюдении правил безопасного
хранения секретного ключа никто, кроме
его владельца, не в состоянии вычислить
верную ЭЦП какого-либо электронного
документа.

Хэширование
— это метод криптозащиты, представляющий
собой контрольное преобразование
информации: из данных неограниченного
размера путем выполнения криптографических
преобразований вычисляется хэш-значение
фиксированной длины, однозначно
соответствующее исходным данным.
Хэширование может выполняться как с
использованием некоторого секретного
ключа, так и без него. Данный метод
применяется в схемах электронной подписи
(«подписывается» обычно хэш-значение
данных, а не все данные целиком), а также
в схемах аутентификации пользователей
(при проверке, действительно ли
пользователь является тем, за кого себя
выдает).

Потоковые
шифры

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

Гаммирование
— наложение на открытые данные гаммы
шифра (случайной или псевдослучайной
последовательности единиц и нулей) по
определенному правилу. Обычно используется
«исключающее ИЛИ», называемое также
сложением по модулю 2 и реализуемое в
ассемблерных программах командой XOR.
Для расшифровывания та же гамма
накладывается на зашифрованные данные.

Бесконечный
ключ – это означает, что гамма не
повторяется.

Понятно,
что обмен ключами размером с шифруемую
информацию не всегда уместен. Поэтому
чаще используют гамму, получаемую с
помощью генератора псевдослучайных
чисел (ПСЧ). В этом случае ключ — порождающее
число (начальное значение, вектор
инициализации, initializing value, IV) для запуска
генератора ПСЧ. Каждый генератор ПСЧ
имеет период, после которого генерируемая
последовательность повторяется.
Очевидно, что период псевдослучайной
гаммы должен превышать длину шифруемой
информации.

Генератор
ПСЧ считается корректным, если наблюдение
фрагментов его выхода не позволяет
восстановить пропущенные части или всю
последовательность при известном
алгоритме, но неизвестном начальном
значении.

При
использовании генератора ПСЧ возможны
несколько вариантов:

1.
Побитовое шифрование потока данных.
Цифровой ключ используется в качестве
начального значения генератора ПСЧ, а
выходной поток битов суммируется по
модулю 2 с исходной информацией. В таких
системах отсутствует свойство
распространения ошибок.

2.
Побитовое шифрование потока данных с
обратной связью (ОС) по шифртексту. Такая
система аналогична предыдущей, за
исключением того, что шифртекст
возвращается в качестве параметра в
генератор ПСЧ. Характерно свойство
распространения ошибок. Область
распространения ошибки зависит от
структуры генератора ПСЧ.

3.
Побитовое шифрование потока данных с
ОС по исходному тексту. Базой генератора
ПСЧ является исходная информация.
Характерно свойство неограниченного
распространения ошибки.

4.
Побитовое шифрование потока данных с
ОС по шифртексту и по исходному тексту.

Блочные
шифры

При
блочном шифровании информация разбивается
на блоки фиксированной длины и шифруется
поблочно. Блочные шифры бывают двух
основных видов:

• шифры
  перестановки
  (transposition, permutation, P-блоки);

• шифры
  замены (подстановки, substitution, S-блоки).

Шифры
перестановок переставляют элементы
открытых данных (биты, буквы, символы)
в некотором новом порядке. Различают
шифры горизонтальной, вертикальной,
двойной перестановки, решетки, лабиринты,
лозунговые и др.

Шифры
замены заменяют элементы открытых
данных на другие элементы по определенному
правилу. Paзличают шифры простой, сложной,
парной замены, буквенно-слоговое
шифрование и шифры колонной замены.
Шифры замены делятся на две группы:

• моноалфавитные
  (код Цезаря) ;

• полиалфавитные
  (шифр Видженера, цилиндр Джефферсона,
  диск Уэтстоуна, Enigma).

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

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

В
современных криптографических системах,
как правило, используют оба способа
шифрования (замены и перестановки).
Такой шифратор называют составным
(product cipher). Oн более стойкий, чем шифратор,
использующий только замены или
перестановки.

Блочное
шифрование можно осуществлять двояко:

1. Без
обратной связи (ОС). Несколько битов
(блок) исходного текста шифруются
одновременно, и каждый бит исходного
текста влияет на каждый бит шифртекста.
Однако взаимного влияния блоков нет,
то есть два одинаковых блока исходного
текста будут представлены одинаковым
шифртекстом. Поэтому подобные алгоритмы
можно использовать только для шифрования
случайной последовательности битов
(например, ключей). Примерами являются
DES в режиме ECB и ГОСТ 28147-89 в режиме простой
замены.

2. С
обратной связью. Обычно ОС организуется
так: предыдущий шифрованный блок
складывается по модулю 2 с текущим
блоком. В качестве первого блока в цепи
ОС используется инициализирующее
значение. Ошибка в одном бите влияет на
два блока — ошибочный и следующий за
ним. Пример — DES в режиме CBC.

Генератор
ПСЧ может применяться и при блочном
шифровании:

1.
Поблочное шифрование потока данных.
Шифрование последовательных блоков
(подстановки и перестановки) зависит
от генератора ПСЧ, управляемого ключом.

2.
Поблочное шифрование потока данных с
ОС. Генератор ПСЧ управляется шифрованным
или исходным текстом или обоими вместе.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Управление доступом к файлам и папкам в системе Windows — процесс непростой; для обеспечения безопасности ресурсов необходим эффективный механизм защиты. Именно такой механизм реализован в модели безопасности NTFS, которая позволяет администратору жестко контролировать действия пользователей, осуществляющих чтение или запись в файлах системы и так или иначе работающих с ними.

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

1. Ограничивайтесь пятью стандартными разрешениями на обращение к файлам

Система NTFS позволяет предоставлять 14 особых разрешений, которые точно определяют, каким образом пользователь может обращаться к тому или иному файлу. Эти разрешения достаточно детализированы, поэтому, не вдаваясь в подробности, отметим, что в NTFS 14 разрешений сводятся к пяти стандартным — или видовым — разрешениям, как показано в таблице. К примеру, стандартные разрешения дают возможность предоставить пользователю полный контроль (Full Control) над файлом, вместо того чтобы предоставлять ему по отдельности каждое из 14 особых разрешений.

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

В окне командной строки хорошо видно, в чем состоит различие между записью в файл и присоединением данных. Чтобы записать данные в файл, нужно ввести следующую команду:

C:>echo «new text» > test.txt

Если в программе Notepad открыть файл test.txt, вы увидите, что он содержит одну строку — «new text».

Теперь попробуем присоединить данные к файлу. Для этого можно использовать следующую команду:

C:>echo «Line 2» >> test.txt

Теперь, если вы откроете файл test.txt в приложении Notepad, то увидите, что он содержит две строки:

«new text»

«Line 2»

К сожалению, такие детализированные разрешения часто невозможно использовать. Сейчас я объясню почему. Система NTFS «понимает» разницу между записью и присоединением данных, так что у вас может возникнуть желание установить такое разрешение, которое позволяет присоединять данные, но отказывает в доступе с правом записи. Итак, установим разрешение на доступ к файлу test.txt с предоставлением прав на выполнение любых операций, кроме записи данных (Write Data), как показано на экране 1.

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

C:>echo «Line 3» >> test.txt

вам будет отказано в доступе. Более того, теперь вы не сможете ни записывать данные в файл, ни присоединять данные к файлу из командной строки. Но и это еще не все. Если попытаться добиться обратного эффекта и дать разрешение на запись данных (Write Data) с одновременным запретом на присоединение данных (Append Data), увидим, что и эта комбинация не дает результата. Иначе говоря, если вы блокируете одну операцию, одновременно блокируется и вторая.

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

Одни разработчики программ прилежно указывают в запросах именно те разрешения, которые требуются для выполнения той или иной операции, другие же идут на поводу у собственной лени и всегда запрашивают разрешение Full Control вне зависимости от того, какие задачи должен выполнять их код. Чаще всего программисты запрашивают разрешение на доступ со стандартными правами чтения или записи. В большинстве случаев этого вполне достаточно. Но здесь есть проблема, и состоит она в том, что невозможно определять разрешения NTFS с большей степенью детализации, чем указывают программисты в своих запросах.

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

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

2. Помните о двух исключениях из порядка наследования разрешений

Модель наследования, используемая системой NTFS для управления доступом, играет важную роль в определении того, кто имеет право доступа к тому или иному файлу. Чтобы определиться с разрешениями, Windows должна свериться со списком управления доступом, относящимся к данному файлу. Каждый файл и папка имеют собственный список управления доступом, где предоставляется или блокируется доступ для конкретных пользователей или групп. Но этот объект может к тому же наследовать разрешения от своей родительской папки или от любой комбинации папок более высокого уровня. Все эти разрешения могут конфликтовать друг с другом — один список управления доступом может разрешать пользователю доступ к файлу, тогда как другой может явным образом отказывать ему в доступе. Более того, пользователь может быть членом нескольких групп, которые имеют различные разрешения.

Для решения проблемы конфликтующих списков управления доступом в Windows используется базовый набор правил:

• на любом данном уровне разрешения от нескольких групп объединяются;

• на любом данном уровне отрицательные разрешения (запреты) имеют приоритет над положительными;

• разрешения, предоставленные объекту напрямую, имеют приоритет над наследуемыми разрешениями;

• разрешения, унаследованные от «близких родственников», имеют приоритет над разрешениями, унаследованными от «дальних родственников».

Любой объект может быть защищен от наследования разрешений от родительских папок.

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

Объект можно защитить от процесса наследования. Для этого в диалоговом окне Advanced Security Settings нужно перейти на вкладку Permissions и снять флажок Allow inheritable permissions from the parent to propagate to this object and all child objects, как показано на экране 2. Если вы выполните эту операцию, настройки родительской папки уже не будут влиять на параметры безопасности текущего файла либо папки или любых других файлов или папок, расположенных ниже в иерархической структуре — почти во всех случаях.

Два малоизвестных исключения в этой системе защиты от наследования разрешений могут привести к путанице. Первое состоит в том, что отказ в предоставлении доступа к файлу с правом чтения(Read Attributes) недействителен, если родительская папка разрешает составлять список каталога. Если вы явным образом отказываете пользователям в доступе к файлу с правом чтения, любой пользователь, имеющий право составления списка содержимого каталога, может также просматривать атрибуты любого файла в данном каталоге. Очевидно, что это исключение нарушает правила 2 и 3 — оно позволяет записи «Разрешить» получать приоритет над записью «Отказать» и дает возможность разрешениям родительской папки получать приоритет над ограничениями, которые наложены непосредственно на объект. Кроме того, это исключение нарушает правила 4 и 5, потому что, даже если вы явным образом защитите файл от наследования разрешений, сняв флажок Allow inheritable permissions from the parent to propagate to this object, родительская папка будет по-прежнему влиять на разрешения объекта.

Второе исключение состоит в том, что отказ в разрешении на удаление (Delete Attributes) применительно к файлу или папке не действует, если родительская папка имеет разрешение на удаление подпапок и файлов (Delete Subfolders and Files). Поскольку по умолчанию почти все папки имеют разрешение на удаление подпапок и файлов, отказ в разрешении на удаление файла редко будет иметь эффект. Это исключение может привести к путанице, ибо вы, к примеру, можете лишить кого-то права на удаление того или иного файла, а потом обнаружится, что этот человек тем не менее имеет право на его удаление. Это исключение из нескольких правил наследования, и опять-таки оно сохраняет силу, даже если вы явным образом защитите файл от наследования разрешений со стороны его родительской папки.

Но этим сложности не исчерпываются. Возможно, вы подумали, что, если при предоставлении разрешения на удаление подпапок и файлов для некоторой папки пользователи могут удалять подпапки и файлы, из этого следует, что при отказе в таком разрешении пользователи не смогут удалять подпапки и файлы. Ничуть не бывало. Отказ в разрешении на удаление подпапок и файлов для той или иной папки, в сущности, означает предоставление права применять разрешение на удаление к любым дочерним объектам. Для исключения возможности удаления файлов нельзя использовать одно из двух разрешений — разрешение на удаление подпапок и файлов или разрешение на удаление. Защита файла от удаления — это процесс, состоящий из двух этапов. Сначала нужно отказать в праве на удаление применительно к файлу, а затем — в праве удалять подпапки и файлы применительно к родительской папке.

3. Разрешение на исполнение файла может оказаться полезным

Выше я говорил о том, что администраторам не стоит тратить силы на установление разрешений с высоким уровнем детализации, но из данного правила, на мой взгляд, есть одно исключение — это разрешение на исполнение файла (Execute File). Одно из стандартных разрешений формулируется как Read and Execute, но в действительности для выполнения файла пользователю не нужен доступ с правом чтения. В большинстве случаев для выполнения файла пользователю нужен только доступ с правом Execute and Read Attributes. Более того, обычно пользователю не нужно даже предоставлять доступ с правом Read Attributes, потому что он автоматически получит это право от родительской папки, о чем я уже упоминал.

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

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

При предоставлении разрешения на исполнение файла детализированный контроль может быть полезным. Не будем забывать, однако, что для выполнения сценариев и командных файлов необходимо соблюдение тех же условий, только, что называется, с точностью до наоборот: пользователю должно быть предоставлено право на чтение, а разрешение на исполнение файла не требуется. Любопытно отметить, что в случае отказа в разрешении на выполнение файла применительно к компоненту ActiveX DLL или OLE Custom Control (OCX) пользователи лишаются возможности обращения к файлу regsvr32.exe с целью регистрации этого компонента.

4. Некоторые разрешения не столь полезны, как остальные

Некоторые разрешения на манипуляции с файлами менее полезны, чем другие, просто потому, что такие разрешения переопределяются другими принимаемыми по умолчанию системными привилегиями. Невозможно, к примеру, отказать в разрешении принимать объекты во владение (Take Ownership) тем пользователям, которые имеют системную привилегию на восстановление файлов и каталогов (последняя по умолчанию предоставляется администраторам и операторам резервного копирования, поскольку эти пользователи имеют системную привилегию принимать во владение файлы либо другие объекты). Вы можете лишить этой системной привилегии администраторов, но, будучи администраторами, они, в свою очередь, могут восстановить ее.

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

Специальные разрешения на чтение (Read Permissions) и на внесение изменений (Change Permissions) неприменимы к владельцу файла, даже если администратор явным образом откажет ему в этих разрешениях. Следовательно, упомянутые разрешения неприменимы также к любому пользователю, располагающему правом принимать во владение файлы или другие объекты. Если вы хотите отказать кому-то в разрешении на считывание данных или на внесение изменений, вам придется отказать этому пользователю в возможности принимать объекты во владение.

Отметим, что хотя в разрешениях на чтение и в разрешениях на внесение изменений не содержится явно выраженного разрешения либо ограничения на доступ к настройкам аудита (т.е. к системным спискам ACL-SACL), в большинстве механизмов просмотра, таких как вкладка Security в диалоговом окне программы Windows Explorer, не отображается список SACL, если эти разрешения (т.е. дискреционные списки ACL-SACL) не предоставлены.

Наконец, вам, вероятно, нет нужды устанавливать разрешения на перемещение по каталогам (Traverse Folder), поскольку по умолчанию каждый пользователь системы имеет привилегию обхода проверки перемещения (Bypass Traverse Checking), которая, по сути дела, сводит на нет это разрешение. Более того, специалисты Microsoft давно уже рекомендуют не осуществлять проверок перемещения, ибо известно, что в результате возникают проблемы с приложениями, которые не обеспечивают корректной обработки ошибок перемещения по каталогам.

5. Разрешения на совместный доступ к ресурсам дополняют, но не заменяют разрешений NTFS

Когда вы предоставляете разрешения на совместное использование файла, эти разрешения действуют независимо от разрешений NTFS на доступ к файлам и папкам, но в сочетании с данными разрешениями. Система Windows рассматривает оба набора разрешений и использует разрешения из той группы, где предоставляется наименьший объем прав.

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

Кроме того, важно отметить, что разрешения на доступ к каждому совместно используемому ресурсу касаются лишь данного ресурса — они не наследуются и не распространяются на отдельно хранимые совместно используемые ресурсы, даже если последние располагаются на более низких этажах той же структуры физического каталога. Пусть, например, у вас имеется предназначенный для всех пользователей разделяемый ресурс, расположенный в каталоге D:users. Все пользователи могут обращаться к этому ресурсу и ко всем объектам, расположенным на более низких уровнях структуры. Теперь представьте себе, что вы создаете предназначенный только для администраторов ресурс по адресу D:usersadmin. Второй ресурс, хотя он и является вложенным в первый, не имеет с ним никакой связи. Даже если вы откажете обычным пользователям в доступе к ресурсу D:usersadmin, они смогут обратиться к этой папке, открыв каталог D:users и перейдя в папку admin. Для блокировки доступа пользователей к каталогу admin придется назначить соответствующие разрешения NTFS. Чтобы такие ситуации не возникали, в большинстве случаев лучше избегать вложенных структур совместно используемых ресурсов.

6. Привязывайте разрешения к встроенным группам

При назначении разрешений на обращение к файлам и папкам следует использовать большой набор встроенных групп, к которым Windows автоматически причисляет пользователей в зависимости от того, как они регистрируются в системе. Существует, к примеру, группа удаленных пользователей настольных систем (Remote Desktop Users). Можно устанавливать весьма детализированные разрешения NTFS в зависимости от типа регистрации. Так, у вас может возникнуть необходимость предоставить доступ к определенным конфиденциальным файлам только администратору или пользователю, который входит в систему с локальной консоли. Это можно сделать, предоставив доступ только группам Administrators и Interactive Logon Users. Можно также ограничить доступ к определенным файлам, так чтобы они были доступны лишь для учетных записей, зарегистрированных в качестве служб. Полный список встроенных участников безопасности приведен в статье «Well-known security identifiers in Windows operating systems», опубликованной по адресу http://support.microsoft.com/kb/243330 .

(Дополнительные сведения о встроенных участниках безопасности содержатся также в статье «Встроенные участники системы безопасности», опубликованной в Windows ITPro/RE № 1 за 2006 г. — Прим. ред.).

7. Проявляйте осторожность при использовании группы Everyone

Пришло время дать последний совет: проявляйте осторожность при работе с группой Everyone. В версиях Windows, выпущенных до выхода в свет Windows XP, в группу Everyone по умолчанию включались анонимные пользователи, поэтому администраторам всегда советовали не предоставлять права доступа членам этой группы. Но в версиях Windows XP, Windows Server 2003 и Windows Vista анонимные пользователи по умолчанию не входят в группу Everyone, так что в зависимости от конкретных разрешений отказ в доступе членам группы Everyone не означает отказа анонимным пользователям. Самый безопасный способ заблокировать доступ к ресурсам со стороны анонимных и других нежелательных пользователей состоит не в том, чтобы отказывать им в праве доступа, а в том, чтобы предоставлять это право только конкретным пользователям и группам.

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

(Дополнительную информацию о разрешениях NTFS и разрешениях на обращение к разделяемым ресурсам можно найти в статье «Путеводитель по разрешениям файловой системы» по адресу http://www.osp.ru/win2000/2007/06/4367585/  — Прим. ред.).

Марк Барнетт (mburnett@xato.net ) — независимый консультант по безопасности и автор, специализирующийся на проблемах безопасности Windows. Обладатель сертификата IIS MVP

Безопасность на файловом уровне

Безопасность файловой системы NT (NTFS)

Файлы в Windows Server 2008 R2 безопасны лишь постольку, поскольку для них опреде­лены права доступа. Поэтому неплохо знать, что Windows Server 2008 R2 не предоставляет группе Everyone (Все пользователи) полный контроль над правами доступа уровня общих ресурсов и уровня NTFS. Кроме того, критические файлы и каталоги операционной систе­мы защищены от их несанкционированного использования. Несмотря на наличие общих усовершенствований, рекомендуется тщательно разобраться в безопасности на файловом уровне, чтобы не снизить безопасность сервера на этом уровне.

В Windows Server 2008 R2 для обеспечения безопасности в операционной системе на файловом уровне применяется последняя версия файловой системы NT (NT File System — NTFS). Каждый объект, на который имеется ссылка в NTFS, в том числе файлы и папки, помечается записью контроля доступа (Access Control Entry — АСЕ), которая физически ограничивает круг пользователей, имеющих доступ к ресурсу. Права доступа NTFS исполь­зуют эту концепцию для жесткого управления доступом на чтение, запись и другие типы доступа к файлам.

Файловые серверы должны обоснованно применять права доступа уровня NTFS, и сле­дует проверить права доступа файлового уровня во всех каталогах для обнаружения воз­можных брешей в наборе прав доступа NTFS. Изменение прав доступа NTFS в Windows Server 2008 R2 — простой процесс. Достаточно выполнить следующие действия.

1. Щелкните правой кнопкой мыши на папке или файле, к которому нужно приме­нить установки безопасности, и выберите в контекстном меню пункт Properties (Свойства).
2. Перейдите на вкладку Security (Безопасность).
3. Щелкните на кнопке Advanced (Дополнительно).
4. Щелкните на кнопке Change Permissions (Изменить права доступа).
5. Снимите отметку с флажка Include Inheritable Permissions from This Object’s Parent (Включать права доступа, наследуемые от родителя этого объекта).
6. На вопрос о применении родительских прав доступа щелкните на кнопке Remove (Удалить).
7. В диалоговом окне Advanced (Дополнительно) используйте кнопки Add (Создать), чтобы получить доступ к группам и/или пользователям, которым нужен доступ к файлам или папкам.
8. Установите флажок Replace All Child Object Permissions with Inheritable Permissions from This Object (Заменять права во всех объектах-потомках на права, наследуемые от данного объекта), и щелкните на кнопке ОК.