информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медСетевые кракеры и правда о деле ЛевинаSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Столлман возвращается в FSF 
 The Great Suspender предположительно... 
 Десятилетняя уязвимость в sudo 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / sysadmin
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
При правильной организации эта задача решается очень просто... 27.11.13 00:04  Число просмотров: 1726
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
При правильной организации эта задача решается очень просто - надо всего лишь посмотреть, в какие группы входит пользователь. Вот и всё.
А если по имени группы нельзя однозначно сказать, к какому ресурсу она применена, или одна и та же группа может быть применена сразу к нескольким ресурсам, или права даются не через группу, а напрямую пользователю - то значит, у вас бардак.

Для файловых помоек есть несколько простых правил:
- только стандартные права (чтение/запись, ну и иногда листинг). Никаких игр с наследованиями, специальными правами, и пр.
- одна папка -> одна группа (точнее 2 группы - одна на чтение, друга на запись);
- не применять группы на папки глубже 2-3 уровня вложенности. При необходимости - перенести папку на первый уровень.

В сетях с "десятков тысяч серверов с многими тысячами папок на сервере и сотен тысяч пользователей" эти несложные правила соблюдаются. Там вообще ID-менеджмент отделен от сисадминства (т.е. у сисадминов нет доступа напрямую в AD, и они не могут произвольно создать группу), а операции по созданию групп и включению/удалению в них пользователей выполняют специально обученные люди, либо автоматически через систему реквестов/аппрувов.
<sysadmin>
Как узнать, к каким ресурсам имеет доступ пользователь в Microsoft Network? 26.11.13 15:42  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 26.11.13 15:43  Количество правок: 1
<"чистая" ссылка>
Сразу исключаем варианты "Спросить у него самого", "Выпытать (паяльником) у сисадмина", "Куда угодно, если знает логин и пароль, под которым возможен доступ"...

Разобъем вопрос на две части: 1 - штатным образом, 2 - использование софта сторонних производителей (какой удобнее).

Итак, как правило имеем огромную сложную сеть на базе микрософтовского доменного контроллера. Огромное количество серверов, папок, ресурсов, гигабайт, огромное количество пользователей.

Необходимо построить табличку из трех полей [Логин пользователя], [\\Сервер\ресурс\папка], [Права:RWCD...].

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

Если я прав и ничего приличного в штатных инструментах нет, то может есть какой-то простенький софт, который сможет сделать ревизию?
ИМХО, только написанием программы с тупым перебором ресурсов... 27.11.13 14:51  
Автор: _Den_ Статус: Незарегистрированный пользователь
<"чистая" ссылка>
ИМХО, только написанием программы с тупым перебором ресурсов сети и проверкой на доступ
При правильной организации эта задача решается очень просто... 27.11.13 00:04  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
При правильной организации эта задача решается очень просто - надо всего лишь посмотреть, в какие группы входит пользователь. Вот и всё.
А если по имени группы нельзя однозначно сказать, к какому ресурсу она применена, или одна и та же группа может быть применена сразу к нескольким ресурсам, или права даются не через группу, а напрямую пользователю - то значит, у вас бардак.

Для файловых помоек есть несколько простых правил:
- только стандартные права (чтение/запись, ну и иногда листинг). Никаких игр с наследованиями, специальными правами, и пр.
- одна папка -> одна группа (точнее 2 группы - одна на чтение, друга на запись);
- не применять группы на папки глубже 2-3 уровня вложенности. При необходимости - перенести папку на первый уровень.

В сетях с "десятков тысяч серверов с многими тысячами папок на сервере и сотен тысяч пользователей" эти несложные правила соблюдаются. Там вообще ID-менеджмент отделен от сисадминства (т.е. у сисадминов нет доступа напрямую в AD, и они не могут произвольно создать группу), а операции по созданию групп и включению/удалению в них пользователей выполняют специально обученные люди, либо автоматически через систему реквестов/аппрувов.
Там все нормально организовано. Админы толковые и... 27.11.13 01:05  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 27.11.13 01:06  Количество правок: 1
<"чистая" ссылка>
> При правильной организации эта задача решается очень просто
> - надо всего лишь посмотреть, в какие группы входит
> пользователь. Вот и всё.

Там все нормально организовано. Админы толковые и адекватные. Но...

> А если по имени группы нельзя однозначно сказать, к какому
> ресурсу она применена, или одна и та же группа может быть
> применена сразу к нескольким ресурсам, или права даются не
> через группу, а напрямую пользователю - то значит, у вас
> бардак.

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

> Для файловых помоек есть несколько простых правил:
> - только стандартные права (чтение/запись, ну и иногда
> листинг). Никаких игр с наследованиями, специальными
> правами, и пр.
> - одна папка -> одна группа (точнее 2 группы - одна на
> чтение, друга на запись);
> - не применять группы на папки глубже 2-3 уровня
> вложенности. При необходимости - перенести папку на первый
> уровень.

К сожалению никуда не деться от хранилища на группу. Пусть шара в корне и называется "Отдел №1" в папке которой создан файлобменник (файлпомойка) "Проект №1" и папка "Юзерс" в которой есть папки "Иванов", "Петров", "Сидоров". В "Проект №1" дается доступ всем сотрудникам отдела полный доступ и доступ на просмотр группе "Контрлеры". В персональные каталоги, например, дается полный доступ каждому сотруднику в свою папку, а на только на просмотр всем остальным сотрудникам отдела. Вполне возможно существование "Проект №2" в папке "Отдел №1", полный доступ в котороую должен быть у нескольких сотудников отдела и нескольких сотрудников-подрядчиков других отделов, а больше никому даже на чтение.
Это пример. Это не бардак, это жизнь, это бизнес, это система безопасности.
Создать по шаре на хоум каталог каждого юзера и каждый проект - ужос. И пользователям удобнее ходить по дереву своего файлового ресурса.

> В сетях с "десятков тысяч серверов с многими тысячами папок
> на сервере и сотен тысяч пользователей" эти несложные
> правила соблюдаются. Там вообще ID-менеджмент отделен от
> сисадминства (т.е. у сисадминов нет доступа напрямую в AD,
> и они не могут произвольно создать группу), а операции по
> созданию групп и включению/удалению в них пользователей
> выполняют специально обученные люди, либо автоматически
> через систему реквестов/аппрувов.

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

Что-то мне подсказывает, что задача просто не решится. Просто бывают двухсторонние связи (например в БД), где и атрибутах папки (ACL) прописаны те, кто имеет доступ в нее, и в атрибутах пользователя прописано то, куда он имеет доступ. Не ужели когда на каком-то серваке дается доступ како-то группе, доменконтроллер и не знает об этом!
Для простого выявления таких "косяков" я юзал fileacl.exe... 27.11.13 02:24  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
> ... но возможны ситуации, когда куда-то может даже
> временно, несанкционированно или по ошибке кто-то кому-то
> что-то дал. Собственно есть желание проверить размеры
> бедствия и по возможности исправить. Надеюсь, что косяков
> не будет больше процента или одной десятой его доли.

Для простого выявления таких "косяков" я юзал FILEACL.EXE. Сканирует ФС и выводит ACL в удобочитаемом виде, работает быстро, куча опций, например, можно указать, на сколько папок вглубь сканировать.
Если папка мега критичная, то должно работать регулярное автоматическое сравнение с некоторым бэйзлайном.

> К сожалению никуда не деться от хранилища на группу. Пусть
> шара в корне и называется "Отдел №1" в папке которой создан
> файлобменник (файлпомойка) "Проект №1" и папка "Юзерс" в
> которой есть папки "Иванов", "Петров", "Сидоров". В "Проект
> №1" дается доступ всем сотрудникам отдела полный доступ и
> доступ на просмотр группе "Контрлеры". В персональные
> каталоги, например, дается полный доступ каждому сотруднику
> в свою папку, а на только на просмотр всем остальным
> сотрудникам отдела. Вполне возможно существование "Проект
> №2" в папке "Отдел №1", полный доступ в котороую должен
> быть у нескольких сотудников отдела и нескольких
> сотрудников-подрядчиков других отделов, а больше никому
> даже на чтение.
> Это пример. Это не бардак, это жизнь, это бизнес, это
> система безопасности.
> Создать по шаре на хоум каталог каждого юзера и каждый
> проект - ужос. И пользователям удобнее ходить по дереву
> своего файлового ресурса.

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

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

А вот это уже похоже на отсутствие change-менеджмента. Админу в любом случае нужен номер тикета, иначе он просто не сможет залогиниться на сервер.
И не админ должен давать доступ, а ID-менеджмент, путем включения пользователя в соответствующую группу. Ну а если это временно - то все равно это обязанность хозяина этой группы (а не дежурного админа) периодически ресертифицировать список ее членов.
ShareEnum от sysinternals не пробовал? 26.11.13 18:18  
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
<"чистая" ссылка>
Конечно, вложенных папок не просканирует и права на объекты всех ФС тоже - но права на шары в целом покажет.
Кроме того, у sysinternals еще куча тулз есть - те же AccessChk и AccessEnum - может пригодятся.

Sysinternals File and Disk Utilities
Да, если бы только на шару, тогда вопросов нет. Практика... 27.11.13 00:41  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Конечно, вложенных папок не просканирует и права на объекты
> всех ФС тоже - но права на шары в целом покажет.
> Кроме того, у sysinternals еще куча тулз есть - те же
> AccessChk и AccessEnum - может пригодятся.

Да, если бы только на шару, тогда вопросов нет. Практика такова, что у менее, чем у половины файловых хранилищ одной или нескольким группам (например одной только на просмотр, другой на все) даются права на шару и вниз. Более половины имеют как минимум права разным группам на разные каталоги первого уровня шары, и не менее часто встречаются вглубину на два-три уровня каталогов.
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach