организация папок на файловом сервере лучшие практики

Как упорядочить корпоративные файлы: 10 советов по организации доступа

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

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

Почему доступ к файлам так важен?

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

рядовому сотруднику в среднем доступно почти 11 млн файлов, причем в зависимости от размера ИТ-инфраструктуры этот показатель мог увеличиваться вдвое;

около 20% сетевых папок открыты для всех внутренних пользователей;

39% участвовавших в исследовании компаний имеют более 10 000 устаревших, но все еще активных учетных записей, а 60% — не менее 500 (в среднем около 1000) паролей без истечения срока действия.

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

С чего начать процесс изменения?

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

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

Как организовать доступ?

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

К примеру, на сетевую папку всем пользователям можно назначить права (Share Permissions) на изменение, а полный доступ дать только локальным администраторам. Даже если внутри ресурса кому-то по ошибке разрешат полный контроль средствами NTFS, воспользоваться привилегиями по сети не получится. Крайне нежелательно создавать вложенные сетевые ресурсы, потому что они приводят к путанице с настройкой прав доступа — для этих целей есть DFS.

Советы по настройке прав доступа

• Определите стандарты для назначения прав доступа

Организации используют множество типов разрешений, включая чтение, запись, изменение, полный доступ и т. д. В большинстве случаев чтение и изменение — единственные разрешения, необходимые бизнес-пользователям. Они должны назначаться в зависимости от каталога, группы безопасности, а не на основе ролей. Использование групп безопасности при назначении прав доступа для конкретного каталога снижает риск появления прямых разрешений. Это уменьшает сложности администрирования, делает права пользователя более наглядными (убирает вложенные группы), сокращает размер токена (количество групп) для каждого пользователя, а также количество групп в AD. Другой вариант — для каждой папки верхнего уровня создать отдельную группу с правами только на просмотр содержимого.

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

• Определите структуру папок и разрешений

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

• Используйте глобальные группы только для общедоступной информации

Глобальные группы доступа следует использовать только для предоставления пользователям доступа к общедоступной информации. Если позволяют ресурсы сервера, нужно использовать ABE (Access-based Enumeration), когда пользователи видят только папки, к которым имеют доступ. Это помогает не разогревать излишнее любопытство и осложняет задачу злоумышленникам.

• Избегайте предоставления полного доступа обычным пользователям

Во многих случаях администраторы намеренно предоставляют разрешения на полный доступ обычным бизнес-пользователям. Такой подход в случае нарушения безопасности, проникновения вредоносного ПО или кибератаки Full Control может быть использован злоумышленниками для доступа к данным, их удалению, удалению всех разрешений из других групп и т. д. Бизнес-пользователи с разрешениями «Полный доступ» также могут случайно изменить настройки разрешений для папки, что приведет к потере доступа или удалению данных.

• Предоставляйте доступ к конфиденциальным данным, основываясь на их содержимом

Распространенной практикой является предоставление разрешений на общий доступ всей функциональной группе, бизнес-роли или глобальной группе доступа. Так как Microsoft требует, чтобы разрешения предоставлялись через группы Active Directory, этот метод гарантирует, что пользователи, которым он требуется, имеют достаточные права, но также создает угрозу безопасности. Многие пользователи получают доступ к конфиденциальным данным только потому, что им назначена определенная роль.

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

• Назначайте права доступа напрямую в ACL

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

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

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

• Ограничивайте ИТ-администраторам полный доступ к конфиденциальным данным

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

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

Источник

Организация папок и прав на файловом сервере

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

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

Группы в AD

Для распределения прав доступа создаются следующие группы (названия групп произвольные):

Синхронизация

Доступ к дискам

Папка «Private» (диск P:)

Для всех пользователей компании на файловом сервере создается личная папка:

Папка «Файлообмен» (Exchange)

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

Папка проектов (Projects/Teams)

Папки верхнего уровня с доступом для нескольких сотрудников работающих над одной задачей (проектом):

Папки отделов

Название папок верхнего уровня по названию отделов. Например: IT, АДМИНИСТРАЦИЯ, КОММЕРЧЕСКИЙ ОТДЕЛ, HR и т.п.

На папке отдела даны полные права для группы в которую входят сотрудники отдела и права на чтения для всех сотрудников компании. В папках отдела следующие подпапки:

Источник

Аспирин от настройки прав на файловом сервере

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

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

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

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

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

Вот что мы пробовали:

В итоге, на Powershell был написан скрипт для сбора данных через Get-Acl и последующего автоматического формирования отчета по форме, согласованной со службой безопасности. Но сразу всплыл ряд минусов:

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

Не подошел вариант ведения учета в виде бумажных заявок. Главным образом, из-за отсутствия механизма автоматического поиска;

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

О ресурсных группах

Обычно администраторами применяются два метода предоставления доступа:

Непосредственно учетной записи пользователя. Если не вести подробный протокол назначения прав, то быстро возникнет неразбериха;

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

Предоставляют права доступа только к одному сетевому ресурсу или подкаталогу, которые могут иметь несколько групп доступа с разными правами;

Могут быть вложенными;

Нарушение этих требований разрушит всю концепцию структурированной системы доступов.

Копнем чуть глубже

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

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

Структурированная система доступов ориентирована на файловые серверы Windows, но без проблем может быть адаптирована и под другие ОС.

Структурированная система доступов на основе ресурсных групп — это не вариация на тему ролевого доступа, а его важный элемент

Как выдаются «пропуска»

Доступ к общему сетевому ресурсу или подкаталогу предоставляется только соответствующим ресурсным группам — локальным «Administrators» и “System”. Каждый общий каталог должен рассматриваться как корень дерева, в котором все доступы наследуются подкаталогами от родительской папки. Права доступа на подкаталог могут быть предоставлены независимо от прав на родительский каталог. Я буду иллюстрировать основные идеи на примере собственного сервера и его структуры папок.

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

Глубина вложений каталогов на файловом сервере может быть произвольной. Но если часто приходится выдавать права на подкаталоги ниже 3 – 5 уровня, то такая структура станет перегруженной и потребует оптимизации.

Имя нового файлового сервера «FILESRV1». На файловом сервере в корне диска для данных создан каталог с именем “Shares”. Отключено наследование прав доступа от родительского каталога и ограничен доступ

Открываемые в общий доступ каталоги будут создаваться только в папке «Shares». Имя такого каталога должно совпадать с соответствующим именем общего файлового ресурса – например, “Public”.

Для упорядоченного размещения данных в Active Directory создана структура организационных единиц «…\Groups\Shares. «. Организационные единицы создаются для каждого файлового сервера и общего файлового ресурса. Для подкаталогов организационные единицы не создаются

Для примера я создал следующие ресурсные группы:

Последние две нужны для предоставления отдельным сотрудникам расширенных прав на каталог «2016».

Теперь нужно включить все это в состав группы «FILESRV1-Public»

Пара слов о выборе имен

В организационной единице с именем общего файлового ресурса создаются группы безопасности:

«имя_сервера-имя_общего_файлового_ресурса» для просмотра дерева каталогов без доступа к данным;

«имя_сервера-имя_общего_файлового_ресурса-R» для доступа к данным с правами чтения;

Эти группы обязательны для всех общих файловых ресурсов, в поле «описание» стоит указывать реальный сетевой путь.

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

Когда выдаете права, отличные от «только чтение» или “чтение и запись”, то вместо суффикса “R” или “W” используйте другую букву. Группы безопасности с особыми правами создаются только для тех каталогов, где это реально необходимо.

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

Для предоставления доступа по сети лучше выдавать права к общим ресурсам группе «Authenticated Users», но можно использовать и “Domain Users” или “Everyone”. Разрешения на уровне файловой системы не позволяют получить несанкционированный доступ к данным без явного разрешения.

На уровне файловой системы к каталогу «Public» предоставлены соответствующие права доступа для групп

Аналогично установлены права доступа для каталога «2016»

Никаких дополнительных действий с каталогом «Новости» выполнять не требуется

Теперь члены групп «FILESRV1-Public-Новости-2016-R» и “FILESRV1-Public-Новости-2016-W” получат доступ только к папке “2016”, а пользователи из “FILESRV1-Public-R” и “FILESRV1-Public-W” – к общему сетевому ресурсу “\FILESRV1\Public” и всем его подкаталогам.

Что в итоге

Конечно, при создании ресурсов масса времени уходит на подготовку, но зато мы получаем следующие преимущества:

Освобождаем себя от постоянных работ по предоставлению доступа с помощью делегирования этих функций ответственным сотрудникам;

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

Если вы знаете более простые методики организации и контроля прав доступа – обязательно делитесь опытом в комментариях.

Источник

Организация папок на файловом сервере лучшие практики

Вопрос

Поделитесь опытом у кого как организованна структура корпоративного файлового хранилище.

Это всё очень удобно пока:

1) Не меняется орг. структура

2) Людям не нужен перекрёстный доступ между папками департаментов

Все ответы

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

2) Следует создать и поддерживать следующие категории папок:

2.1) Личные папки пользователей. В пользовательскую папку должны иметь доступ только пользователь, которому принадлежит папка, и администраторы.

2.3) Проектные папки. Абсолютно все папки, предусматривающие перекрестный доступ сотрудников разных подразделений, должны выноситься в отдельный раздел (папку, сетевой диск) проектных папок. Не допускается давать доступ к папкам одного подразделения сотрудникам из другого подразделения. В случае такого запроса требуемая папка должна быть перемещена в раздел проектных папок независимо от пожеланий пользователей.

3) В целях безопасности следует избегать создания папок с общим доступом на запись для всех пользователей организации. Такие папки нередко любят создавать в целях обмена информацией.

Источник

Как навести порядок: основные сведения о файловых серверах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В примере, показанном на рис. 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 только для данной папки или для всех совместно используемых папок, размещенных на данном компьютере. Вот и все!

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

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

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

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

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

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

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

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

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

Поделитесь материалом с коллегами и друзьями

Источник