Служба Server входит в состав операционных систем на базе Windows NT с того дня, как эти системы появились на свет. К тому же преобладающая часть серверов Windows относится к категории файловых. Логично предположить, что мы, профессионалы в области ИT, в сотрудничестве со специалистами Microsoft давно уже решили все проблемы, связанные с упомянутой службой. К сожалению, это не так. Мне лично доводилось множество раз слышать от бизнес-клиентов (представляющих не семейные лавочки,а солидные компании), что ИT-специалисты по-прежнему настраивают файл-серверы ненадлежащим образом. И Microsoft не способствует изменению положения. Более того, в некоторых случаях корпорация лишь усугубляет проблемы в новейших версиях своих операционных систем, реализуя в них средства, которые я называю «инструментами для чайников». Назову для примера введенную в системе Windows Server 2008 новую команду Share, которая не допускает возможности настройки и предусматривает использование весьма неудачных параметров по умолчанию. Файловые серверы относятся к «раздражителям», доставляющим ИT-профессионалам массу хлопот, но ситуация не безнадежна. Вы можете привести технологии файловых серверов в соответствие с бизнес-требованиями, и я покажу вам обходные пути для решения проблем, связанных с разрешениями, такими как Full Control или Modify, а также некоторые из применяемых по умолчанию настроек, например стандартное наследование разрешений на удаление, которое вы, по рекомендации Microsoft, должны использовать.
Full Control или Modify
Об опасностях, связанных с использованием разрешения Full Control, знают практически все специалисты. Круг лиц, которым приходилось рассматривать сценарии, где определенную опасность представляют разрешения Modify, уже не столь широк. Я мог бы посвятить не одну страницу описанию угроз, вызванных предоставлением разрешений Modify и Full Control группам пользователей, но в рамках этой статьи ограничусь лишь самыми серьезными опасностями. Я имею в виду предоставление разрешения Delete.
Почти во всех случаях, предусматривающих совместное использование файлов специалистами по ИТ, такая группа пользователей получает разрешение Modify или Full Control. Так вот, опасность состоит в том, что шаблоны разрешений Modify и Full Control включают разрешение Delete, которое по умолчанию применяется к «данной папке, а также к вложенным в нее папкам и файлам». Получив такое разрешение и право его наследования, пользователь подобной группы может удалить любой файл или вложенную папку, а также все файлы и вложенные папки. Иначе говоря, любой член команды может выбрать любую папку, нажать клавишу Delete — и прощайте, данные. Такое удаление может быть умышленным или случайным, но так или иначе его можно предотвратить.
Выделите время для определения требований к папкам, доступным для нескольких пользователей при выполнении ими совместных проектов, и не забывайте о том, что разрешения могут быть использованы как во благо, так и во зло. Вы сможете убедиться, что в зависимости от требований, предъявляемых к папке, разрешения на работу с которой вы предоставляете, проблема разрешения Delete может быть решена несколькими способами. Способ первый: можно предоставить всей группе разрешение Allow::Write, в соответствии с которым любой член группы сможет создавать и изменять файлы и папки. Затем следует предоставить разрешение Delete ограниченной группе пользователей. Способ второй: предоставить группе разрешение Modify, но изменить диапазон действия этого разрешения, так чтобы оно применялось только к файлам. При этом возможность непреднамеренного или преднамеренного удаления файлов внутри папки сохраняется, но исключается рекурсивное удаление вложенных папок в случае непреднамеренного удаления.
Delete Subfolders and Files
Еще опаснее разрешение Delete Subfolders and Files, запись управления доступом (access control entry, ACE) в шаблоне разрешения Full Controls. Пользователь, имеющий такое разрешение для работы с той или иной папкой, может удалить любую вложенную папку или файл внутри нее, даже если ему было явно предоставлено разрешение Deny::Delete. Иными словами, любой пользователь, входящий в состав группы с разрешением Full Control применительно к той или иной папке, может удалить все ее содержимое и создать ситуацию отказа в обслуживании. А это значительно хуже, чем стандартное разрешение Delete, поскольку разрешение Delete Subfolders and Files переопределяет все другие разрешения, включая явно выраженные разрешения Deny. Как тут не вспомнить о револьвере в руках обезьяны.
Чтобы избежать такой ситуации, используйте оптимальный метод номер два: проявляйте исключительную осторожность при предоставлении разрешения Full Control. Я рекомендую ограничивать разрешения Full Control областью System. Предоставляйте шаблон разрешения Modify плюс разрешение Change Permissions группам, которым необходимо изменять разрешения на работу с папками. Между прочим, оптимальный метод номер один состоит в следующем: всегда назначайте разрешения не пользователям, а группам. Теперь я перехожу к следующему «раздражителю».
Запись управления доступом Creator Owner
В большинстве организаций мерам по обеспечению безопасности уделяется повышенное внимание, а это значит, что большое значение приобретает такая процедура, как определение правил доступа. Политика доступа к разделяемым папкам определяется списком управления доступом родительской папки. К примеру, папка, совместно используемая группой сотрудников, обычно конфигурируется таким образом, чтобы члены группы могли читать файлы друг друга. Часто они имеют право добавлять файлы в совместно используемый ресурс, а иногда могут даже вносить изменения в файлы своих коллег. Проблема заключается в том, что к каждой новой папке по умолчанию применяется запись управления доступом, предоставляющая разрешение Allow::Full Control (Apply To Subfolders and Files) для специального разрешения Creator Owner. Когда один из пользователей создает файл или папку, запись управления доступом, назначенная для Creator Owner, применяется к конкретному пользователю.
Рассмотрим пример. Если Дэн Холм становится членом группы и создает в разделяемом ресурсе группы новый файл, он получает разрешения Allow::Full Control для работы с этим файлом. А что произойдет, если Дэн перестанет быть членом группы? Его имя будет удалено из списка членов группы, обладающих правом читать и создавать файлы в совместно используемой папке. Но за ним останется право доступа к созданному им файлу, ибо оно явным образом выражено в разрешении Allow::Full Control записи управления доступом к данному файлу. Итак, лишь по той причине, что Дэн создал упомянутый файл, к нему неприменима вся политика доступа к разделяемой папке, постулирующая право доступа только со стороны членов группы. И если даже сотрудник с полномочиями администратора воспользуется функцией Change Owner для назначения файла другому члену группы, Эйми, Дэн сохранит свое явно выраженное разрешение (а Эйми не унаследует разрешение Full Control, имеющееся у Дэна), если только администратор не внесет изменения в разрешения на работу с файлом.
Как решить эту досадную проблему? Проанализируйте разрешения, которыми должны обладать пользователи разделяемой папки. Возможно, вы захотите вообще удалить запись управления доступом Creator Owner. Если вы назначили членам группы шаблон разрешений Allow::Write так, что они будут иметь возможность изменять файлы своих коллег в совместно используемой папке, запись управления доступом Creator Owner вам не понадобится. Пусть Дэн после удаления такой записи стал членом группы и создал новый файл. Этот файл наследует политику доступа родительской папки, но каких-либо явных записей управления доступом для Дэна при этом не создается. Он может вносить в свой файл изменения потому, что является членом группы, а когда Дэн выходит из состава группы, его права доступа удаляются. Правда, Дэн все еще может в качестве владельца вернуться к своему объекту и предоставить себе права. Этой проблемой мы и займемся прямо сейчас.
Изменение разрешений
Сотрудникам каждой организации приходится сталкиваться с проблемами, возникающими из-за того, что пользователи, действуя умышленно или непреднамеренно, изменяют разрешения на обращение к созданным ими файлам или папкам. В системе Windows предусмотрено неявное разрешение (WRITE_DAC), назначаемое идентификатору безопасности security identifier (SID) пользователя, который владеет файлом или папкой. Это разрешение дает пользователю возможность изменять разрешения на обращение к объекту даже в тех ситуациях, когда он без этого не имеет разрешений Allow::Change. Подобная возможность способна вызвать угрозу безопасности, поскольку владелец файла или папки может изменить политику доступа, определенную в списке управления доступом к родительской папке.
До выхода в свет системы Windows Vista единственное реальное решение состояло в том, чтобы изменить блок сообщений сервера Server Message Block (SMB), т. е. разрешения на обращение к совместно используемым ресурсам. Как правило, администраторы в качестве разрешений SMB используют разрешения Allow::Full Control. Но если вместо них задействовать налагающие более серьезные ограничения разрешения SMB Allow::Change, пользователи смогут выполнять любые действия, за исключением изменения разрешений.
В системах Vista и Windows Server 2008 рассматриваемая проблема решается еще проще. Разработчики этих систем ввели новое специальное разрешение, OWNER RIGHTS, которое представляет текущего владельца файла или папки. Разрешения, назначенные этому удостоверению, определят разрешения для владельца и переопределят неявные права владельца, в том числе право изменять разрешения. Поэтому новый оптимальный метод состоит в том, чтобы назначить OWNER RIGHTS::Allow::Modify. Разрешение Modify не подразумевает разрешений Change Permissions, Delete Subfolders and Files и Take Ownership, входящих в состав шаблона разрешений Full Control. Когда на ваших файловых серверах будет установлена система Server 2008, эта проблема уйдет в прошлое.
Когда пользователи открывают папки, они могут видеть все их содержимое, а к нему по умолчанию относятся, помимо прочего, файлы и папки, к которым пользователи не имеют доступа. Думаю, что это не так уж важно. Главное — не имеющие разрешений пользователи не могут открыть файл или папку, а то, что их видят посторонние, не имеет значения. Но если вы придерживаетесь другой точки зрения, вот мой совет: реорганизуйте свои файлы и папки или используйте средство Access-Based Enumeration; его версию для системы Windows Server 2003 можно получить по адресу microsoft.com/downloads/details.aspx?FamilyID=04A563D9–78D9–4342-A485-B030AC442084&displaylang=en.
Делегирование разделяемых папок
Еще одним «раздражителем», с моей точки зрения, является реализованная в системах Windows 2000 и Windows Server 2003 процедура предоставления разрешений на доступ к разделяемым папкам. Честно говоря, очень хочется сказать пару нелестных слов в адрес разработчиков этих продуктов. Проблема весьма серьезна и многогранна; о том, чтобы подробно рассмотреть ее в данной статье, не может быть и речи. Так что, если кто из сотрудников Microsoft читает эти строки — пригласите меня на беседу! Корень проблемы — делегирование разрешений на создание разделяемых папок.
Представьте себе, что вы работаете в организации с несколькими уровнями административного управления. В организации имеются специалисты по технической поддержке, попечению которых вверены серверы. Эти сотрудники занимаются аппаратными компонентами, резервным копированием, настройкой, установкой модулей коррекции и т. д. — выполняют те задачи, которые возлагаются на настоящих Администраторов (с большой буквы!). В системе Windows член группы администраторов может выполнять любые действия и работать с любым компонентом сервера. Предположим далее, что существует также роль сотрудника службы поддержки с задачей создания папок общего доступа. С моей точки зрения, а также с точки зрения всех клиентов, с которыми мне приходится работать, эта задача относится к администрированию более низкого уровня, нежели другие задачи, выполняемые администраторами. Но, к сожалению, в глазах специалистов Microsoft эти два типа задач равнозначны. Чтобы создать папку общего доступа, пользователь должен быть членом привилегированной группы, такой как Administrators, Power Users или Server Operators, а члены этих групп по определению имеют и другие неотъемлемые права. Microsoft не предусматривает возможности делегировать право создания общедоступных папок лицам, занимающим более низкое положение в административной иерархии.
Я очень обрадовался, узнав, что утилита TweakUI из комплекта PowerToy Windows XP предоставляет возможность делегирования этой функции. Но, к сожалению, программа TweakUI не является официальным компонентом Windows и Microsoft не поддерживает ее. Разрешение создавать ресурс общего пользования содержится в двоичной записи в реестре, и изменение данной записи тоже не предусмотрено. Таким образом, как это ни прискорбно, я должен признать, что делегировать функцию создания папок общего доступа членам групп технической поддержки можно только одним способом — включив этих сотрудников в состав групп Server Operators или Power Users рядового сервера. По крайней мере, вы сможете обойтись без предоставления им полномочий администраторов.
Но это еще не самое интересное. При создании общедоступной папки возникает необходимость задать ее настройки: разрешения, параметры кэширования, функции просмотра разрешений и, возможно, ее описание либо предельное число соединений. Эти настройки для первых трех случаев наиболее полезны и распространены. Но как установить их в обход пользовательских интерфейсов общедоступной папки?Как задействовать командную строку или сценарий? Разрешения можно назначать с помощью пользовательского интерфейса или из командной строки (скажем, выполнив команду NET SHARE), но не средствами языка VBScript. Настройки кэша можно устанавливать с помощью пользовательского интерфейса или команды NET SHARE, но не средствами языка VBScript. Функцию просмотра списков можно активировать только через пользовательский интерфейс. Средства командной строки для нее не предусмотрены, а задача использования функции NetShareSetInfo в сценарии для простого смертного неразрешима. Ну и где же здесь логика? Нет, автоматизировать процесс создания папок общего доступа может только профессиональный разработчик.
Наконец, применяемые по умолчанию настройки для новых разделяемых папок в большинстве случаев выбраны неудачно. Стандартное разрешение Everyone::Allow::Read ограничивает права всех пользователей, включая администраторов. Никто не может получить доступ к ресурсу на более высоком уровне, даже если разрешения NTFS предусматривают применение более либеральных политик. Все клиенты, с которыми мне доводилось работать в последнее время, используют очень четкие политики, в которых указывается, что Full Control — это корректное разрешение на обращение к разделяемым ресурсам практически во всех случаях и что фактическая политика доступа определяется разрешениями NTFS. Перед нами наглядный пример того, что корпорация Microsoft упрятала инструмент слишком глубоко и не дает клиентам возможности заменить применяемые по умолчанию механизмы чем-то более полезным.
Подобным же образом применяемые по умолчанию настройки кэширования позволяют пользователям выбирать любой файл разделяемого ресурса для последующей работы с ним в автономном режиме. Если при этом речь не идет о папке, содержащей исключительно файлы «только для чтения», такие настройки открывают возможность для редактирования файлов в автономном режиме, что может вызвать конфликты при синхронизации. По соображениям безопасности я рекомендую рассмотреть возможность блокировки предусмотренного по умолчанию доступа к файлам в автономном режиме.
Чтобы изменить применяемые по умолчанию настройки кэширования, используйте сценарий или командную строку для инициализации и автоматизации совместно используемых ресурсов. Так, команда NET SHARE позволяет с легкостью создавать общедоступные папки; в ней предусмотрены переключатели для настройки разрешений Full Control и отключения автономных файлов для разделяемого ресурса:
/GRANT: Everyone, Full и /CACHING: None
Совместное использование файлов для «чайников»
Все, о чем я только что говорил, относится к Windows Vista и Windows Server 2008. Увы, в системе Windows Server 2008 все осталось по-прежнему. Поэтому считайте данный раздел предварительным обзором проблем, связанных с использованием Windows Server 2008.
Когда я знакомился с системой Windows Server 2008, меня прежде всего неприятно поразила команда Share. Нечего и думать о том, чтобы отыскать ее в контекстном меню окна Windows Explorer. Новая команда Share сведена к «совместному использованию файлов для ‘чайников’». При ее выполнении на экране открывается окно File Sharing (см. экран).
В диалоговом окне File Sharing пользователь может устанавливать разрешения на уровнях Reader, Contributor или Co-Owner. В этом окне для доступа к разделяемым ресурсам и для разрешений NTFS предусмотрены уровни Read, Change/Modify или Full Control. Подобная реализация разрешений противоречит письменным политикам и процедурам практически всех клиентов, с которыми мне приходилось работать. Обычно в соответствии с требованиями политик разрешения на доступ к разделяемым папкам должны устанавливаться на уровне Full Control, а уровень доступа определяться разрешениями NTFS. Кроме того, многие из нас научились сначала защищать папку, а уж потом открывать ее для доступа других пользователей, поэтому мы иногда выделяем какое-то время на подготовку безупречного списка управления доступом. Но команда, о которой идет речь, предоставляет доступ к папке только группам, использующим стандартные шаблоны разрешений NTFS Read, Modify или Full Control. Проведите небольшой эксперимент. Защитите папку таким образом, чтобы группа пользователей имела разрешение на запись, а затем попытайтесь открыть ее для совместного использования. Вы увидите, что группа не получает разрешений на доступ к ресурсу.
Эта проблема усугубляется в связи с тем, как именно Microsoft реализует роли в диалоговом окне. В большинстве построенных на снове ролей моделях безопасности, включая разработанные специалистами Microsoft модели общедоступных папок SharePoint и xchange, роль Contributor не имеет права на выполнение операции Modify, а роль Editor имеет такое право. Различие между ролями Contributor и Editor состоит в следующем. Contributor может дополнять ресурс новыми материалами и изменять содержимое этих материалов. В отличие от этой роли пользователь Editor может вносить изменения в файлы, поступившие от любого пользователя Contributor. Мы можем соглашаться или не соглашаться с такими определениями ролей Editor и Contributor, но суть не в этом. Главное, что Microsoft присваивает себе право толковать возможные представления о ролях всех своих клиентов. Разработчики не позволяют компаниям вносить изменения в процессы, происходящие в диалоговом окне.
Наконец, Microsoft еще более усугубляет ситуацию, заменяя старый добрый (и эффективный) интерфейс Share инструментом, который я называю «средством совместного использования файлов для чайников». Теперь, чтобы добраться до действительно требующих изменения настроек, пользователю нужно отыскать команду Advanced Sharing. И вот я спрашиваю: если для того, чтобы предоставить доступ к папке нескольким лицам, пользователь должен входить в привилегированную группу (такую, как группа администраторов) и если мы, в конце концов, имеем дело не с клиентской, а с серверной операционной системой, неужели нельзя допустить, что администраторы знают, что они делают? Даже в замечательном мастере Provision a Shared Folder Wizard, который реализован в диспетчере Server Manager, по умолчанию применяются просто безумные настройки — такие, как Everyone:: Allow:: Read и Caching=Manual, и их нельзя изменять в соответствии с потребностями организации.
Лучшее решение этих проблем, доставляющих массу хлопот администраторам систем Server 2008, состоит в использовании команды Net Share или других сценариев, с помощью которых можно установить для папок совместного доступа необходимые параметры. Ведь даже превосходная новая оболочка PowerShell не позволяет установить для разделяемой папки все настройки блока сообщений сервера Server Message Block. Что тут сказать? Досадно.
Тема не закрыта
Проблем, мешающих работе администраторов файловых серверов, а также способов их решения слишком много для того, чтобы их можно было рассмотреть в одной статье. Мы еще будем возвращаться к этой теме.
Дэн Холм (danh@intelliem.com) — директор консалтинговой службы Intelliem, которая организовывает консультации для предприятий, внедряющих SharePoint, Office, Windows и Active Directory