Допустим, сотрудник Петя увольняется со скандалом, и вам нужно сделать так, чтобы он ничего напоследок не поломал. Или Вася переводится в другой отдел, и ему не следует больше копаться в файлах своего бывшего подразделения. Теперь самое интересное: нужно каким-то образом вспомнить, к каким конкретно данным у этих товарищей был доступ, и что следует прикрыть в первую очередь. Если с доступом к приложениям все очевидно и просто, то о файловых ресурсах такого не скажешь. Наш корпоративный файловый сервер представлял собой достаточно печальное зрелище. С одной стороны — накопленные за годы объемы данных, а с другой — наследие в виде нигде не учтенных прав доступа, предоставленных предыдущими поколениями администраторов. Все это происходило еще до внедрения системы заявок на доступ и оперативно уже никак не разобраться. В то время мы рассмотрели несколько программ для сбора информации о правах доступа. Но они очень долго обрабатывали тонны данных файлового сервера, да и формируемые отчеты требовали дополнительной доработки напильником. Вот что мы пробовали: Sysinternals AccessEnum (Freeware) Netwrix Change Notifier for File Servers (Freeware) Netwrix Auditor for File Servers ScriptLogic Security Explorer В итоге, на Powershell был написан скрипт для сбора данных через Get-Acl и последующего автоматического формирования отчета по форме, согласованной со службой безопасности. Но сразу всплыл ряд минусов: Слишком неудобно каждый раз запускать скрипт и часами ждать, пока сформируется матрица доступов; Не подошел вариант ведения учета в виде бумажных заявок. Главным образом, из-за отсутствия механизма автоматического поиска; Лучшим решением проблемы стала организация структурированной системы доступов на основе ресурсных групп. Обычно администраторами применяются два метода предоставления доступа: Непосредственно учетной записи пользователя. Если не вести подробный протокол назначения прав, то быстро возникнет неразбериха; В качестве альтернативного и более удобного варианта можно использовать модель ресурсных групп. Это обычные группы безопасности, которые отвечают следующим требованиям: Предоставляют права доступа только к одному сетевому ресурсу или подкаталогу, которые могут иметь несколько групп доступа с разными правами; Могут быть вложенными; Нарушение этих требований разрушит всю концепцию структурированной системы доступов. На первый взгляд, система доступов на основе ресурсных групп избыточна и требует дополнительных манипуляций при создании общих сетевых ресурсов и подкаталогов с собственными правами. Но все это компенсируется простотой управления правами и возможностью делегирования полномочий ответственным сотрудникам без административных прав на сервере или в домене.  За годы использования такой системы я ни разу не пожалел о потраченном на подготовку времени. Теперь можно в любой момент посмотреть членство пользователя в группах и сразу определить, куда у него есть доступ. Структурированная система доступов ориентирована на файловые серверы Windows, но без проблем может быть адаптирована и под другие ОС.  Структурированная система доступов на основе ресурсных групп — это не вариация на тему ролевого доступа, а его важный элемент Доступ к общему сетевому ресурсу или подкаталогу предоставляется только соответствующим ресурсным группам — локальным "Administrators" и “System”. Каждый общий каталог должен рассматриваться как корень дерева, в котором все доступы наследуются подкаталогами от родительской папки. Права доступа на подкаталог могут быть предоставлены независимо от прав на родительский каталог. Я буду иллюстрировать основные идеи на примере собственного сервера и его структуры папок. Если нужно на каком-то подуровне отключить наследование или установить запрет доступа – значит, с точки зрения информационной безопасности, структура каталогов выбрана неверно. Информация ограниченного доступа не должна размещаться на ресурсе с более широким доступом из-за риска ее компрометации.  Глубина вложений каталогов на файловом сервере может быть произвольной. Но если часто приходится выдавать права на подкаталоги ниже 3 – 5 уровня, то такая структура станет перегруженной и потребует оптимизации.  Имя нового файлового сервера "FILESRV1". На файловом сервере в корне диска для данных создан каталог с именем “Shares”. Отключено наследование прав доступа от родительского каталога и ограничен доступ Открываемые в общий доступ каталоги будут создаваться только в папке "Shares". Имя такого каталога должно совпадать с соответствующим именем общего файлового ресурса – например, “Public”.  Для упорядоченного размещения данных в Active Directory создана структура организационных единиц "…\Groups\Shares...". Организационные единицы создаются для каждого файлового сервера и общего файлового ресурса. Для подкаталогов организационные единицы не создаются Для примера я создал следующие ресурсные группы: FILESRV1-Public FILESRV1-Public-R FILESRV1-Public-W FILESRV1-Public-Новости-2016-R Последние две нужны для предоставления отдельным сотрудникам расширенных прав на каталог "2016".  Теперь нужно включить все это в состав группы "FILESRV1-Public" В организационной единице с именем общего файлового ресурса создаются группы безопасности: "имя_сервера-имя_общего_файлового_ресурса" для просмотра дерева каталогов без доступа к данным; "имя_сервера-имя_общего_файлового_ресурса-R" для доступа к данным с правами чтения; Эти группы обязательны для всех общих файловых ресурсов, в поле "описание" стоит указывать реальный сетевой путь. Если нужно предоставить права, начинающиеся с имени подкаталога, то в организационной единице общего файлового ресурса создаются две группы безопасности: "имя_сервера-имя_общего_файлового_ресурса-цепочка_имен_каталогов_разделенных_тире-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 года он вполне может превратиться в традиционную «файлопомойку» со всеми вытекающими проблемами. Если вы знаете более простые методики организации и контроля прав доступа – обязательно делитесь опытом в комментариях.