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

Беспорядочные россыпи данных

В штате одной компании, с которой мне довелось сотрудничать, насчитывается менее 100 служащих, но они располагают восемью файловыми серверами и сотнями совместно используемых ресурсов. Администратору было непросто находить нужные файлы, а рабочий стол каждого пользователя представлял собой целый лес из аббревиатур ярлыков. В подобных условиях консолидация серверов и совместно используемых ресурсов в один крупный сервер представляется разумным решением. В зависимости от соглашения об уровне обслуживания (service level agreement, SLA), заключенного ИТ-подразделением предприятия, можно рассмотреть возможность использования кластерной или иной технологии, с тем чтобы снизить уровень риска и, как говорится, не держать все яйца в одной корзине. Но в любом случае важно, чтобы с точки зрения пользователей структура файлового сервера была максимально простой.

Компаниям, в которых данные разбросаны буквально повсюду, я рекомендую провести полную реорганизацию структуры файловых серверов. Это не так сложно, как может показаться, если тщательно спланировать процесс и должным образом согласовать его с остальными сотрудниками компании. Об уровне организации файлового сервера можно судить по тому, насколько удовлетворенными — или неудовлетворенными — чувствуют себя пользователи. Если вопрос стоит не особенно остро (т.е. пользователи, как правило, в состоянии отыскать нужную им информацию), можно обойтись простой «уборкой помещения». Но как бы то ни было, я не устану повторять: независимо от того, насколько значительны масштабы осуществляемой реорганизации, проведение упомянутой «уборки» является целью всей компании, а не просто проектом ее ИТ-подразделения. Одним словом, потребуется поддержка руководства.

Рисунок 1. Очищенная структура папок на сервере

В моем представлении идеальный файловый сервер имеет лишь один совместно используемый ресурс, который включает в себя ряд родительских подпапок. Это структура простая и четкая, она обеспечивает пользователей исчерпывающим набором возможностей. Каждая компания отличается от других, но структура файлового сервера обычно чем-то напоминает ту, что изображена на рис. 1. Как мы видим, серверу присвоено подходящее имя, совместно используемый ресурс описывает содержимое сервера, и подпапки имеют логическую структуру. А как быть с подпапками, помещенными внутрь родительских папок? Сотрудники каждого департамента должны сами заниматься своими папками, однако можно дать им некоторые рекомендации. Я обычно задаю пользователям наводящие вопросы, например:

  • Существуют ли в вашей организации подотделы или группы? Если да, то вы можете создать подпапки для более детального разделения данных. В крупном ИТ-подразделении можно создать подпапки «Инфраструктура», «Разработка», «Управление проектами» и «Обеспечение качества».
  • Работаете ли вы в одном месте или ваши сотрудники разбросаны по различным географическим точкам? Если служащие из разных городов ежедневно обмениваются данными, нет смысла создавать папки «Сиэтл», «Портланд» и «Нью-Йорк» для служащих, работающих в одном офисе. Если же бизнес-подразделения функционируют независимо друг от друга, одной папки для них будет недостаточно. Этот пример показывает, почему данный проект нельзя рассматривать как проект информационной службы; владельцем плана должна быть вся компания.
  • Реализован ли в вашем департаменте механизм доступа к материалам с различными уровнями обеспечения безопасности данных? Защита отдельных файлов связана с большими затратами времени и при ее обеспечении трудно избежать ошибок. Об «одноразовых» мерах легко забыть, и уровень защиты документа может быть изменен, если настройки безопасности переходят от родительской папки к файлу. Если отдел имеет границы безопасности, сотрудники службы поддержки создают собственные подпапки, отражающие эти границы.

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

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

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

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

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

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

  • роль «вице-президент по вопросам учета»;
  • роль «менеджер по вопросам учета»;
  • роль «помощник бухгалтера»;
  • роль «бухгалтер»;
  • роль «временный сотрудник бухгалтерии»;
  • роль «все сотрудники бухгалтерии».

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

Рисунок 2. Добавление роли

При добавлении ролей к системе безопасности папки можно использовать описанное выше соглашение об именовании, и добавление не будет вызывать никаких затруднений. Найдите папку, для которой вы хотите изменить настройки безопасности. Щелкните на ней правой клавишей мыши и в открывшемся меню выберите пункт Properties. Перейдите на вкладку Security и щелкните на пункте Add. В поле Enter the object names to select нужно ввести слово Role, и на экране появится список ролей, содержащихся в Active Directory (AD).

Папка, доступная всем

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

При создании новой структуры данных или реорганизации существующей необходимо позаботиться о том, чтобы в разрешениях NTFS на доступ к корневой папке было указано: группа Everyone, List Folder Contents and Read, как показано на рис. 3. Эти базовые разрешения защищают корневую папку от включения ошибочных файлов и новых папок, которые не соответствуют вашей новой структуре.

Рисунок 3. Базовые разрешения для группы Everyone

На рис. 4 представлен пример разрешений, которые следует установить на доступ к структуре файлового сервера, отображенной на рис. 1. Установив разрешения указанным образом, вы предоставите членам группы Everyone доступ на чтение к папкам, чтобы они могли перейти в подпапки. Затем пользователи смогут вносить записи в соответствующие папки согласно ролям, к которым они относятся.

Рисунок 4. Примеры разрешений для папок сервера

Видеть только то, что нужно

В примере, показанном на рис. 2, можно увидеть все папки, входящие в совместно используемый ресурс Data. По всей вероятности, и ваши пользователи тоже видят все подпапки структуры файлов вне зависимости от того, имеют ли они разрешения на обращение к ним. До недавнего времени такая прозрачность была необходима, поскольку именно таким образом функционировали все серверы Windows; разрешения на обращение к папке не имели никакого отношения к возможности увидеть эту папку. Те, кто работал раньше с сетями Novell, вероятно, полагают, что описанная выше видимость папок — это огромный недосмотр со стороны специалистов Microsoft. К счастью, в конце концов корпорация Microsoft решила эту проблему (правда, только для системы Windows Server 2003), выпустив небольшой дополнительный модуль Windows Server 2003 Access-based Enumeration (ABE).

По словам представителей Microsoft, ABE делает видимыми только те файлы и папки, к которым пользователь имеет право доступа. После активизации Access-based Enumeration система Windows не отображает файлы и папки, к которым пользователь не имеет права доступа. Весьма вероятно, что большинство пользователей компании не имеют доступа ко всем родительским папкам, но тогда зачем же демонстрировать им весь список? Например, пользователю, имеющему разрешение на работу только с материалами папки Production, нет нужды видеть все папки, отображенные в списке на рис. 1. В случае активизации модуля ABE список папок на рис. 1 сокращается до одного пункта — папки Production.

Мне не раз приходилось слышать, будто ABE обеспечивает «безопасность через скрытность». Но ведь ABE не просто скрывает папку для того, чтобы пользователи случайно не открывали ее. ABE скрывает такие папки, доступа к которым пользователь не имеет. Это не средство защиты; это функция управления, которая облегчает навигацию по серверу.

Установка и настройка модуля ABE выполняются просто. Программу можно получить на сайте загрузки Microsoft по адресу http://www.microsoft.com/downloads; достаточно ввести в поле поиска слова download ABE. Установка ABE не занимает много времени; система запрашивает у пользователя лишь базовые сведения — принимает ли он условия лицензионного соглашения и где именно он хотел бы установить дополнительный модуль. По завершении установки найдите разделяемую папку (или настройте папку так, чтобы к ней могли обращаться несколько пользователей), щелкните на ней правой клавишей мыши и в открывшемся меню выберите пункт Properties. Появится новая вкладка, именуемая Access-based Enumeration (она показана на рис. 5). Находясь на этой вкладке, можно активизировать модуль ABE только для данной папки или для всех совместно используемых папок, размещенных на данном компьютере. Вот и все!

Рисунок 5. Закладка ABE в диалоговом окне свойств папки

Защита папки: кто несет ответственность?

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

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

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

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

Так как же убедить руководство компании в необходимости перехода к обеспечению безопасности на базе ролей? Во врезке «Развертывание безопасности на базе ролей» приводится несколько вопросов, которые руководители компании могут задать вам, когда вы предложите им эту идею.

Рисунок 6. Наложение разрешений при доступе к файлу по сети

Разрешения на обращение к совместно используемым ресурсам и к файлам NTFS

Как я учу младших администраторов выяснять причины неполадок в системе защиты папок? На семинарах это происходит следующим образом.

Сначала немного истории. Идея совместно используемых ресурсов впервые была представлена (во всяком случае, специалистами Microsoft) в 1987 г. В это время был выпущен пакет LAN Manager, который дает пользователям возможность подключаться к жесткому диску на сервере. Затем администраторы назначают разрешения на обращение к совместно используемому ресурсу, такие как Full Control, Change или Read. Теперь эта концепция кажется простой, а совместно используемые ресурсы функционируют сегодня так же, как и в конце 80-х годов.

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

Теперь, когда мы знаем, что назначение прав доступа предусмотрено как при работе с совместно используемыми ресурсами, так и с папками NTFS (даже при том, что первоначально разрешения применялись по-разному), возникает вопрос: «Как использовать эти механизмы наилучшим образом?». Один из вариантов — просто сделать совместно используемые материалы доступными для членов группы Everyone с объемом полномочий Full Control, а затем отрегулировать права доступа с помощью разрешений NTFS. Другая возможность — одновременно применять разрешения как для совместно используемых ресурсов, так и для файлов NTFS. В любом случае вы должны быть в состоянии определить, каков уровень полномочий того или иного пользователя при работе с данными материалами.

На рис. 6 приведен пример того, как можно выбрать наилучший вариант защиты информации для пользователя. При работе с материалами папки D:data пользователь Боб имеет следующие разрешения NTFS: Full Control, Modify, Read & Execute и Read. Из перечисленных разрешений наименьшие ограничения содержит разрешение Full Control. Кроме того, Боб имеет разрешение Read при работе с совместно используемым ресурсом. Поскольку это единственное разрешение, которым Боб располагает применительно к данному ресурсу, оно же имеет наименьшие ограничения. Если бы Боб при работе с совместно используемым ресурсом имел разрешения Read и Change, наименее ограничительным было бы разрешение Change.

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

Выяснение причин неполадок в работе смешанной системы прав доступа (через NTFS и через разделяемые ресурсы) может быть весьма непростой задачей. Поэтому многие компании поступают следующим образом: предоставляют членам группы Everyone доступ к материалам совместно используемого ресурса с объемом прав Full Control, а затем ограничивают доступ к файлам и папкам с помощью разрешений NTFS.

От теории к практике

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

Эрик Ракс (ebrux@mvps.org) — старший администратор сети Windows в крупной консалтинговой компании

Развертывание безопасности на базе ролей

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

Что это даст компании?

Плохо структурированная незащищенная информация на сервере выливается для компании в дополнительные затраты. Сотрудники тратят время на поиск данных, а для компании возникает риск попадания данных в чужие руки.

Как это будет работать?

Вместо назначения разрешений для пользователей на индивидуальные папки, пользователи получают роли (которые в Active Directory-AD называются группами безопасности). Роли привязываются к папкам и файлам. Когда принимается новый работник или какой-либо сотрудник переводится в другое подразделение, разрешения можно быстро переназначить простым добавлением сотрудника в группу с соответствующей ролью.

Почему это повысит безопасность?

Собственники данных сами решают, кто имеет доступ к данным. Связывая имеющиеся в компании производственные роли сотрудников с ролями в AD, можно создать мощную систему назначения нужных разрешений соответствующим пользователям. Кроме того, в этой системе ответственность за безопасность ложится на ее владельцев, а не на ИТ-службу, в соответствующих подразделениях компании.

Кто ответит на возникающие вопросы?

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