Выделите время на планирование, и среда общих папок станет землей обетованной
![](http://www.osp.ru/data/689/526/1234/037_0.jpg)
Хранилища совместно используемых файлов могут служить важнейшими пунктами обмена файлами, предназначенными для совместной обработки, размеры которых не позволяют присоединять их к сообщениям электронной почты. Такие хранилища обеспечивают пользователям удобный доступ к необходимым материалам. Кроме того, поскольку обычно они организуются на серверах с избыточными дисковыми ресурсами, опасность потери данных вследствие отказа дисков сводится к минимуму, ведь в такой конфигурации резервирование данных можно осуществлять централизованно, не полагаясь на пользователей. Всякий, кому доводилось выплачивать специалистам по восстановлению данных по несколько тысяч долларов за извлечение жизненно важных данных с вышедшего из строя жесткого диска, может оценить значение резервных дисков файлового сервера.
Поэтому неудивительно, что хранилища совместно используемых файлов получили столь широкое распространение. Но надо сказать, что практика совместного использования файлов сопряжена с определенным риском. Я замечал, что многие системные администраторы, по сути, не разбираются в том, как взаимодействуют разрешения на совместное использование файлов и разрешения файловой системы NTFS и не имеют четкого плана предоставления ресурсов в общее пользование. Я предлагаю вниманию читателей 12 разработанных мною заповедей совместного использования файлов. Надеюсь, они помогут проанализировать имеющуюся в компании среду общих папок, а может быть, кто-то даже возьмется реализовать некоторые из предлагаемых решений.
1. Разработайте стандартные разрешения
В конечном итоге каждый владелец общего ресурса будет предоставлять тем или иным группам пользователей ресурса разрешения в том формате, который покажется ему наиболее рациональным. И тем не менее следует разработать стандартные разрешения на уровне групп и применять эти разрешения ко всем общим папкам в процессе их создания. Обычно такой набор включает разрешения на уровне Administrators и System-Full Control. Кроме того, стоит рассмотреть возможность использования группы Global Deny, члены которой не имеют никаких разрешений. Более подробно статус этой группы описывается в заповеди 9.
2. Система разрешений должна быть простой
Простой структурой разрешений легче управлять. Конечно, можно распределить пользователей, обращающихся к файловым ресурсам, по 47 группам и назначить им разрешения на нескольких уровнях, но будет ли это удобно? Если вы не помогаете владельцам разделяемых ресурсов готовить первоначальные варианты структурных требований, на основе которых будут предоставляться разрешения на доступ к совместно используемым файлам, эти владельцы окажутся в затруднительном положении. Ведь они нередко вместо требований составляют списки нереализуемых по сути пожеланий, которые лишь осложняют управление общими ресурсами — как для технических специалистов, так и для них самих. Когда владелец общего ресурса предлагает сложную схему разрешений, следует подумать, а нельзя ли добиться того же результата более простым способом? В ряде случаев в роли владельца выступает менеджер, который скажет, что ему нужно защитить данные от служащих. Допустим, он опасается, что один пользователь может злоупотреблять данными, а другой — подвергнуть их риску случайно. Но в таком случае вследствие пробелов в подготовке сотрудников или под влиянием сложившихся в отделе политических установок требования превращаются в излишне сложную схему разрешений на использование разделяемых ресурсов. А может быть, проще направить кого-то из пользователей на курсы по основам компьютерных знаний?
3. Используйте группы безопасности
Слушателям учебных сертификационных курсов Microsoft рекомендуют не предоставлять разрешения отдельным пользователям, а формировать из них группы безопасности. Как правило, слушатели старательно следуют этому совету, но в результате может возникнуть ситуация, в которой «всем разрешено все», и тогда администраторы переходят на предоставление разрешений отдельным пользователям. Но стоит только ступить на эту скользкую дорожку — и административное бремя станет непосильным. Если дополнительным пользователям требуется предоставить разрешения, аналогичные уже имеющимся, администраторам приходится создавать копии или клонировать пользовательские разрешения с помощью инструментов от независимых поставщиков, таких как Security Explorer компании Small Wonders Software. Если речь идет об объемном разделяемом ресурсе, то на выявление взаимосвязей клонированных разрешений может уйти несколько часов. Тому, кто не ведет подробную документацию, будет трудно уследить за объемом разрешений того или иного пользователя. И здесь опять-таки придется обращаться к инструментам независимых поставщиков для создания отчетов, в которых содержалась бы нужная информация. Так что, если вы хотите избежать подобных осложнений, всегда назначайте разрешения на уровне групп.
4. Присваивайте группам лаконичные и интуитивно понятные имена
Присваивайте группам безопасности такие имена, которые указывают на разрешения, предоставленные членам соответствующей группы, а также на общие файловые ресурсы, к которым относятся разрешения. Такой подход к именованию позволяет непосредственно ассоциировать группы с компьютерами, на которых размещаются совместно используемые ресурсы, и облегчает жизнь сотрудников, ответственных за безопасность данных или за консультирование пользователей, поскольку им придется включать в группы новых служащих после первоначальной настройки группы и общего ресурса. Желательно, чтобы имена состояли менее чем из 20 символов. Кроме того, внутри имен не должно быть символов пробела и амперсандов (&). При соблюдении этих условий облегчается выполнение в командной оболочке операций по назначению или сбору разрешений на доступ к общим ресурсам. Дело в том, что некоторые команды, например команда Net Localgroup, не выполняются, если имена состоят более чем из 20 символов. В таблице 1 показано, как в относительно коротком имени группы безопасности можно отразить местоположение общего ресурса и подкаталога, а также содержание разрешения на доступ к конкретной папке, которое предоставлено данной группе пользователей.
5. Определяйте наборы разрешений, отражающие название отдела или должности
После определения стратегии разрешений на доступ к разделяемым ресурсам и папкам и создания группы первого уровня можно приступать к процедуре включения в эти группы учетных записей пользователей. Но если вы работаете в собственном режиме Windows и можете создавать из локальных групп вложенные структуры, у вас появляется возможность упростить операцию по назначению разрешений, для чего требуется сформировать локальные группы второго уровня, содержащие учетные записи пользователей. Пусть имена этих групп отражают названия отделов или должностные обязанности сотрудников (например, SalesManagers). Следует добавить эти группы к группам безопасности верхнего уровня. Скажем, для того чтобы предоставить всем менеджерам по продажам доступ к подкаталогу Aircraft ресурса FileServerASales с правом изменять его содержимое (Change), нужно добавить локальную группу SalesManagers к указанной в таблице 1 группе безопасности SalesAircraft-C. Разумеется, менеджерам по продажам потребуется доступ и к другим ресурсам. Здесь мы подходим к концепции набора разрешений.
Набор разрешений — это полный пакет разрешений, которые требуются сотруднику указанного отдела для выполнения его обязанностей. Может оказаться, что необходимые пользователю документы хранятся на многих серверах и входят в состав различных общих ресурсов. Набор разрешений может меняться по мере добавления новых ресурсов и изменения потребностей пользователя в доступе к тем или иным материалам. Так, руководство может прийти к заключению, что консультантам по продажам, которые раньше довольствовались разрешениями только на чтение (Read), теперь требуются разрешения с правом модификации содержимого ресурса (Change). В конечном итоге идея набора разрешений состоит в том, чтобы сделать назначение разрешений простым и точным.
Наборы разрешений, формируемые по принадлежности пользователя к тому или иному отделу либо по занимаемой им должности, полезны в тех случаях, когда принятый на работу новый сотрудник определяется в конкретный отдел и назначается на должность, предполагающую доступ к некоторым разделам совместно используемого ресурса. К примеру, когда компания нанимает нового консультанта по продажам, имя этого сотрудника включается в состав группы SalesConsultants, после чего он автоматически наделяется всеми разрешениями, необходимыми консультанту по продажам. Когда этот консультант по продажам идет на повышение и назначается менеджером по продажам, набор его разрешений можно изменить. Нужно просто исключить имя этого пользователя из состава группы SalesConsultants и включить его в состав группы SalesManagers. Примерный набор разрешений представлен в таблице 2. Добавляя имена пользователей в список членов группы SalesManagers, можно автоматически предоставить им все необходимые разрешения и исключить возможность доступа к конфиденциальным материалам. Если кто-нибудь создаст новый общий ресурс и ассоциированную с ним группу безопасности (скажем, HReporting-С), которую необходимо включить в набор разрешений SalesManager, нужно будет просто добавить группу SalesManager к группе HReporting-C, и тогда все менеджеры по продажам будут иметь необходимые разрешения. При этом администратору не придется включать учетные записи отдельных менеджеров по продажам в состав группы HReporting-C.
6. Продумайте определение фактически действующих разрешений
Создание фактически применяемых разрешений на уровне разделяемых ресурсов, на уровне NTFS, а также глобальных разрешений не всегда проходит легко. В результате может оказаться, что права доступа раздаются слишком щедро. Возможна, впрочем, и другая крайность, когда пользователи, которым необходим доступ к разделяемому ресурсу, получают внушающее ужас сообщение Access Denied («Доступ запрещен»). Эмпирическое правило предоставления фактически применяемых разрешений гласит: «Щедро, щедро, скупо».
Первое «щедро» касается разрешений на доступ к папкам. Когда благодаря членству в той или иной группе пользователь имеет различные разрешения на уровнях файлов и папок NTFS, разрешение на доступ к реальному файлу или папке — это наименее ограничительное из всех разрешений, назначенных пользователю или группам, к которым он принадлежит. Пример: если пользователь по факту членства в одной группе получает разрешение на доступ к спискам файлов и папок (List file and folder permissions), а благодаря членству в другой группе имеет доступ на чтение файлов (Read permissions), фактически ему будет предоставлено наименее ограничительное из этих двух разрешений (т. е. разрешение на доступ с правом чтения файлов).
Создавая общую папку, не забывайте предоставлять пользователям право доступа к корневой папке, по крайней мере, с правами NTFS List или Read. Если этого не сделать, пользователи будут получать сообщение Access Denied, даже если их разрешения на доступ к разделяемому ресурсу и NTFS-разрешения к другим подкаталогам будут оформлены безупречно. Ведь эти пользователи просто не смогут «пробиться» к целевым папкам сквозь недоступную для них корневую папку.
Второе «щедро» касается разрешений на доступ к общему ресурсу. Когда пользователь, входящий в состав нескольких групп, имеет в силу этого обстоятельства разрешения на доступ к разделяемому ресурсу на разных уровнях, фактически ему должно предоставляться наименее ограничительное из всех разрешений, назначенных пользователю или группам, в состав которых он входит. Поэтому, если пользователь имеет право доступа к разделяемому ресурсу по одним основаниям только с правом чтения, а по другим — с правом внесения изменений, ему следует предоставлять право внесения изменений, поскольку это разрешение является наименее ограничительным из двух предоставленных.
Правило «скупо» относится к имеющим силу разрешениям, которые возникают в результате сочетания разрешений на доступ к папкам и к общему ресурсу. Пользователь из нашего примера на уровне NTFS имеет разрешение на доступ с правом чтения, а на уровне общего ресурса — разрешение с правом внесения изменений. Так вот, имеющее силу общее разрешение должно быть наиболее ограничительным из двух указанных. В нашем случае это разрешение на доступ с правом чтения.
7. Не используйте группу Everyone
Членам группы Everyone часто предоставляются права Full Control на доступ к разделяемому ресурсу и разрешения NTFS по умолчанию. Группа Everyone, наделенная разрешением Full Control, — это очевидный пробел в системе безопасности, и ее необходимо удалить как из разрешений на доступ к разделяемому ресурсу, так и из разрешений NTFS. Если необходимо иметь группу доступа, в которую могут входить все пользователи, нужно создать вместо этого группу Authenticated Users.
8. Не допускайте разрастания количества папок
В одном из эпизодов научно-фантастического сериала «The Outer Limits» звучит следующее заявление диктора: «Мы контролируем вертикаль. Мы контролируем горизонталь». Если бы администраторы с такой же легкостью контролировали вертикальные и горизонтальные структуры общих папок! Что касается горизонтали, то вполне возможно, что вы создали общедоступные ресурсы и предоставили пользователям разрешения с правом внесения изменений, чтобы они имели возможность организовывать собственные данные. И, обратившись к этому ресурсу в следующий раз, вы обнаружите, что на корневом уровне имеется 100 папок и 50 файлов. Из-за такого «перебора» пользователям, возможно, будет непросто отыскивать нужные файлы и папки.
Более целесообразно использовать разрешения NTFS и ограничивать круг лиц, имеющих право создавать папки на уровне корневого каталога, пользователями из группы Administrators. Внутри этой созданной в корневом каталоге папки, предназначенной только для чтения, следует создать от 3 до 10 логических папок для данных пользователей и предоставить им право внесения изменений в содержимое этих логических папок и папок, вложенных в эти папки. Имена для папок верхнего уровня необходимо назначать совместно с представителями отделов.
Проблема вертикальной структуры папок чуть сложнее. Дело в том, что с течением времени структура папок пользователей, как правило, разрастается вглубь и длина строки, отражающей путь к папкам, превышает предусмотренный Windows предел в 255 знаков. В результате пользователям бывает сложно отыскивать нужные файлы и могут возникать проблемы с выполнением процедуры резервирования данных. Лучшее решение этой проблемы — тщательный мониторинг и своевременное уведомление пользователей о том, что длина пути доступа к файлам приближается к лимиту в 255 символов.
9. Создайте группу Global Deny
Иногда возникают ситуации, когда требуется быстро заблокировать разрешения того или иного пользователя на доступ к разделяемым ресурсам сети. Но если в сети имеется несколько серверов и несколько разделяемых ресурсов, сделать это довольно сложно, особенно если отдельным пользователям даются разрешения на доступ вне разрешений, предоставленных группам, в которые эти пользователи входят. Для выявления и изменения назначенных пользователю разрешений на доступ, а также для исключения пользователя из состава групп, членам которых предоставляются такие разрешения, требуется время. При увольнении сотрудника или в случае, когда он становится объектом того или иного расследования, руководство может потребовать, чтобы данный пользователь был немедленно лишен всех прав доступа. Самый простой способ решения этой задачи — создать группу Global Deny, члены которой лишены прав доступа ко всем разделяемым ресурсам и всех разрешений NTFS. Я намеренно не использую термин Global для определения типа группы (т. е. не отношу группу к категориям local group или global group). Вместо этого я описываю группу, которая будет использоваться на всех серверах и на всех разделяемых ресурсах сети.
Выберите наглядное имя, скажем GlobalDeny-NA, чтобы в нем отражалась цель создания группы — предоставить ее членам нулевой доступ (No Access, NA). Как правило, в состав этой группы никто не зачисляется. Но когда поступает распоряжение лишить доступа того или иного пользователя, достаточно просто поместить учетную запись этого пользователя в данную группу. Поскольку Deny (отказ) всегда имеет приоритет перед другими разрешениями, этот пользователь будет лишен всех прав доступа. Позднее можно будет удалить учетную запись пользователя из всех ресурсов, доступ к которым был предоставлен ему лично или из групп разрешений.
10. Контролируйте процесс сокращения объема разрешений
Часто бывает так, что поначалу в сети действует хорошо продуманная система разрешений, подготовленная администраторами, но со временем эта структура модифицируется различными лицами. Когда на уровне файлов и папок NTFS или на уровне общего ресурса полномочия Full Control предоставляются слишком большому числу пользователей, последние получают возможность модифицировать структуру разрешений и открывать лазейки в системе безопасности или блокировать доступ к ресурсам для обладающих соответствующими полномочиями пользователей. Мне самому не раз доводилось видеть, как вполне благонадежные пользователи, настаивавшие на том, что им требуется уровень полномочий Full Control, удаляли из структуры разрешений группу Administrators и блокировали работу других администраторов, в том числе и мою.
Чтобы отслеживать состояние разрешений, нужно завести электронную таблицу и фиксировать в ней группы безопасности общих ресурсов и структуру разрешений. Эта информация может оказаться поистине неоценимой в случае реорганизации. С помощью регулярных выборочных проверок разрешений можно добиться соответствия структуры текущих разрешений проектным спецификациям, записанным в электронной таблице. Вы сможете использовать сценарии для сбора существующих разрешений и для того, чтобы наилучшим образом подготовиться к реконструкции разрешений в случае катастрофы или при необходимости быстро отреагировать на внезапно возникшую проблему.
11. Разработайте стратегию действий в чрезвычайных ситуациях
К сожалению, в наши дни хранилища совместно используемых файлов часто становятся объектами вирусных атак, которые могут привести к потере данных не только на локальных дисках пользователей, но и на накопителях. Вирус, безнаказанно орудующий в контексте пользователя с правом модифицировать содержимое общего ресурса, может вызвать массовую инфекцию или привести к катастрофическому удалению данных. Так что же делать, если в ходе новой атаки вирусы преодолеют корпоративные средства сетевой защиты и доберутся до пользователей, угрожая разделяемым ресурсам? Выключать все серверы? Изолировать их от сети? А может быть, временно перевести все совместно используемые ресурсы на доступ «только для чтения», чтобы дать пользователям возможность хоть как-то продолжать работу? Необходимо выработать стратегию действий в чрезвычайных ситуациях, которая потребует тесного сотрудничества и понимания со стороны руководства, так чтобы все осознавали угрозу, нависшую над совместно используемыми данными, и понимали целесообразность мер, предусмотренных в вашем плане для устранения этой опасности.
12. Обеспечьте пользователей средствами быстрого перехода к общим ресурсам
Чтобы предоставить пользователям более широкие возможности доступа к общим ресурсам, можно создать набор располагающихся на рабочих столах ярлыков, указывающих на совместно используемые каталоги. Помимо прочего, такая организация снижает опасность заражения вирусами накопителей пользователей на их настольных машинах. Эти ярлыки можно настроить в соответствии с тем, в каком отделе работает пользователь, или с тем, какие функции он выполняет, и разместить их с помощью Group Policy.
Управление ресурсами можно облегчить следующим образом: во-первых, создать на рабочем столе пользователя ярлык, указывающий на доступную только для чтения папку, входящую в состав общедоступного ресурса. Далее, внутри этой хранящейся на сервере папки нужно разместить ярлыки, указывающие на все разделяемые ресурсы, которые, по замыслу администратора, должен видеть соответствующий пользователь. При таком подходе можно будет централизованно модифицировать все ярлыки с сервера, причем все изменения будут вступать в силу немедленно. Если ресурсы будут перенесены в другие места или в строй будут введены дополнительные ресурсы, администратор сможет отразить все эти изменения с помощью размещенных на сервере указателей, ничего не меняя в ярлыках на рабочем столе пользователя. Если разместить на рабочем столе ярлык, предоставляющий отделам различные представления о разделяемых ресурсах, нужно будет просто по мере необходимости создавать на сервере дополнительные папки с ярлыками, настроенными в соответствии с потребностями каждого отдела. Кроме того, можно будет добавлять ярлыки, указывающие на ресурсы корпоративной сети или Internet.
Дик Льюис (dlewis@winnetmag.com.)- старший системный инженер в компании CKT Consulting в Калифорнии. Имеет сертификаты MCSE и MCT, специализируется на системах управления масштаба предприятия.