Управление доступом к файлам и папкам в системе 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.

Экран 1. Установка разрешений для text.txt

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

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. Если вы выполните эту операцию, настройки родительской папки уже не будут влиять на параметры безопасности текущего файла либо папки или любых других файлов или папок, расположенных ниже в иерархической структуре — почти во всех случаях.

Экран 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