Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Для простого выявления таких "косяков" я юзал fileacl.exe... 27.11.13 02:24 Число просмотров: 7526
Автор: :-) <:-)> Статус: Elderman
|
> ... но возможны ситуации, когда куда-то может даже
> временно, несанкционированно или по ошибке кто-то кому-то
> что-то дал. Собственно есть желание проверить размеры
> бедствия и по возможности исправить. Надеюсь, что косяков
> не будет больше процента или одной десятой его доли.
Для простого выявления таких "косяков" я юзал FILEACL.EXE. Сканирует ФС и выводит ACL в удобочитаемом виде, работает быстро, куча опций, например, можно указать, на сколько папок вглубь сканировать.
Если папка мега критичная, то должно работать регулярное автоматическое сравнение с некоторым бэйзлайном.
> К сожалению никуда не деться от хранилища на группу. Пусть
> шара в корне и называется "Отдел №1" в папке которой создан
> файлобменник (файлпомойка) "Проект №1" и папка "Юзерс" в
> которой есть папки "Иванов", "Петров", "Сидоров". В "Проект
> №1" дается доступ всем сотрудникам отдела полный доступ и
> доступ на просмотр группе "Контрлеры". В персональные
> каталоги, например, дается полный доступ каждому сотруднику
> в свою папку, а на только на просмотр всем остальным
> сотрудникам отдела. Вполне возможно существование "Проект
> №2" в папке "Отдел №1", полный доступ в котороую должен
> быть у нескольких сотудников отдела и нескольких
> сотрудников-подрядчиков других отделов, а больше никому
> даже на чтение.
> Это пример. Это не бардак, это жизнь, это бизнес, это
> система безопасности.
> Создать по шаре на хоум каталог каждого юзера и каждый
> проект - ужос. И пользователям удобнее ходить по дереву
> своего файлового ресурса.
Вполне обыденная ситуация, и все это укладывается в приведенную мною схему. Для каждой папки, к которой нужно ограничивать доступ, создаются 2 группы: одна на чтение, другая - на запись. Потом включаешь в эти группы пользователей. Тогда на вопрос "куда имеет доступ пользователь" можно ответить, просто взглянув на список его групп.
> Конечно все соблюдается, но есть не маленькая вероятность,
> что по каким-либо фантастическим причинам (например срочное
> указание "сверху") нужно дать что-то кому-то и вроде как
> временно, только через месяц все забывается или один
> дежурный дал и второму не сказал.
А вот это уже похоже на отсутствие change-менеджмента. Админу в любом случае нужен номер тикета, иначе он просто не сможет залогиниться на сервер.
И не админ должен давать доступ, а ID-менеджмент, путем включения пользователя в соответствующую группу. Ну а если это временно - то все равно это обязанность хозяина этой группы (а не дежурного админа) периодически ресертифицировать список ее членов.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
