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

image alt text


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


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


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


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


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


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


  • Sysinternals AccessEnum (Freeware)


  • Netwrix Change Notifier for File Servers (Freeware)


  • Netwrix Auditor for File Servers


  • ScriptLogic Security Explorer


  • Ревизор 1 ХР

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


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


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


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

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


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

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


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


  2. Права на группу ролевого доступа. Тот же недостаток, что и в предыдущем случае. К тому же, без протокола назначения прав сложно понять, используется ли конкретная группа кем-нибудь, или может быть удалена.

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


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


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


  • При необходимости предоставляют права только к каталогам. Желательно избегать назначения прав на отдельные файлы.

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


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

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


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


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


image alt text


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


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

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


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


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


image alt text


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


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


image alt text


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


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


  • FILESRV1-Public


  • FILESRV1-Public-R


  • FILESRV1-Public-W


  • FILESRV1-Public-Новости-2016-R


  • FILESRV1-Public-Новости-2016-W

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


image alt text


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


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

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


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


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


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

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


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


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


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

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


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


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


image alt text


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


image alt text


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


image alt text


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


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


Что в итоге

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


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


  • Можем в любое время посмотреть, какими правами и на какие папки обладает пользователь.

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


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

Комментарии (2)

  • 27 сентября 2016 в 15:47

    0

    ↑

    ↓

    >Допустим, сотрудник Петя увольняется со скандалом, и вам нужно сделать так, чтобы он ничего напоследок не поломал

    Почему-то не упомянут пункт 0: «Блокируем его учетку».

    • 27 сентября 2016 в 15:54

      0

      ↑

      ↓

      Пункта »0» не существует — сотрудник подал заявление и у него есть еще две недели, учетная запись блокируется только после увольнения.

© Habrahabr.ru