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

    image alt text


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


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


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


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


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


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



    В итоге, на 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 года он вполне может превратиться в традиционную «файлопомойку» со всеми вытекающими проблемами.


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

    Сервер Молл
    67,00
    серверы HP, Dell и Lenovo: новые и восстановленные
    Поделиться публикацией

    Комментарии 58

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

      Почему-то не упомянут пункт 0: «Блокируем его учетку».
        –1
        Пункта “0” не существует — сотрудник подал заявление и у него есть еще две недели, учетная запись блокируется только после увольнения.
          +1
          Так если вы ему перекроете кислород, как он будет исполнять свои обязанности две недели?
            0
            Возможность оперативно оценить риски ИБ не является “перекрытием кислорода”. Проанализировав доступы можно будет принять правильные решения, например, что необходимо предоставить приемнику для обеспечения непрерывности бизнес-процессов.
              0
              Т.е. предварительно он не мог уже накосячить? И вы только по факту скандала начинаете перекрывать доступы?

              Наблюдал одно феерическое увольнение: Во всем офисе вырубается интернет, сотрудников вызывают к шефу на ковер, в этот момент блокируют их учетки и они перестают иметь доступ к данным. Им сообщают, что они уволены с сей минуты и должны покинуть свои рабочие места. Сотрудники возвращаются на свои места за вещами, видят что их компы залочены, начинается крик, их вежливо просят покинуть помещение. Те просят вернуть им «фотки», которые у них на компе и вообще ***** ****. Их сопроводят на выход.

              Потом в этом офисе убили всю инфраструктуру и поставили бесконтрольную шару на *nix, но это уже совсем другая история.
                0
                Ну мы же не параноики… Основной посыл в том, как заблаговременно организовать доступы и потом получить более комфортные условия для контроля. Но никогда не поздно начать.
            +3
            > сотрудник подал заявление и у него есть еще две недели

            А вы случайно не забыли, что уведомление за две недели — это норма, защищающая работодателя, а не сотрудника? Пусть пишет заявление на увольнение с сегодняшнего дня, работодатель вправе сказать «хорошо, уходи». Зачем держать потенциально опасного и, вероятно, уже бесполезного человека, да ещё и платить ему.
              –1
              Не представляю сотрудника с достаточно широкими правами, в тоже время настолько бесполезного, что его можно уволить в один день без ущерба для бизнеса.
                +1
                Что значит «с достаточно широкими правами»? Достаточно широкими правами для чего, для удаления каких-либо документов? Это почти любой сотрудник.
                И что значит «уволить без ущерба для бизнеса»? Любое увольнение — это потеря денег, некоторый ущерб, независимо от наличия прав у увольняемого. А если увольнение человека приводит к остановке бизнеса, то это либо топ, либо у компании большие проблемы с преемственностью и менеджментом.

                Я, в свою очередь, не представляю человека, у которого можно отобрать права «без ущерба для бизнеса». Если он продолжает полноценно работать после лишения некоторых прав, значит, ему эти права были выданы ошибочно.
            0
            Теневые копии + аудит на «Удаление файлов» для учётки Пети.
              0
              Теневые копии для интенсивно используемого файлового сервера и последующий анализ журналов – вариант интересный, но трудозатраты по анализу логов могут потребовать отдельного, хотя бы, специально “натасканного” сотрудника.
                0
                Так логи можно тем же PowerShell'ом вытащить и отфильтровать нужное. А остальной анализ будет уже простым и особых навыков не требует.
                  0
                  Пример из жизни: сервер на 12 TB, ежеминутно что-то удаляется… я не хочу быть промежуточным звеном, запускающим скрипт или делающим выгрузки для ответственных сотрудников. Аудит ФС включен и используется для расследования фактов удаления данных.
                    0
                    Кстати, с удовольствием почитал бы подобную статью, но по настройке аудита ФС
                +1
                Резервное копирование требует меньше затрат.
                А Diskeeper Undelete Server edition и вовсе эмулирует полно-журналируемую файловую систему.
                  0
                  Я не стал про резервное копирование упоминать, потому что это то, что должно быть настроено по умолчанию. Но, как правило, оно делается раз в сутки, а теневые копии можно настроить на несколько раз за день.
              –4
              > Допустим, сотрудник Петя увольняется со скандалом
              А вы не пробовали не кидать сотрудников с зарплатой? Или это не вариант для вашего бизнеса?
                +1
                Постоянно попадаются люди, которым нечего сказать, но очень хочется.
                Задайте вопрос «по делу».
                  0
                  Мне жаль, что у Вас есть такой печальный опыт, но поводы и причины для скандала и увольнения могут быть самые разные…
                    0

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

                      0
                      Рутовые пароли бесполезно менять.
                    0
                      0
                      По сути, мы преследуем одни и те же цели.
                      0
                      Я правильно понял что в данном примере OU в AD создаются Чисто для красоты?
                        0
                        Для удобства обработки человеком. Компьютерам все равно, а мне удобнее. И когда в оушке будет больше 2000 объектов оснастка начнет выдавать предупреждения.
                        0
                        Спасибо за статью. Несколько замечаний:
                        • Для ресурсных групп обычно принято использовать Domain Local Groups. Они чуть гибче (если у вас один домен, то — на будущее) и заодно легко фильтровать ролевые и ресурсные группы.
                        • Вписывать имя сервера куда-либо я бы не рекомендовал. Сгорит/устареет он завтра, и что вы будете делать? Ночью подменять его на новый сервер с таким же именем? Я бы и file shares как domain-based DFS сразу оформил, пусть и с одним сервером пока, а уж вписывать имя сервера во все группы — где же тут универсальность?
                        • При именовании группы с включением названий всех подкаталогов можно потенциально упереться в 64 символа, и тогда придётся урезать — делать нестандартное название. Значащих слов в структуре каталогов, как правило, меньше, можно ограничиться только ими (например, последние 2 уровня или первый и последний уровень и т. д.), а полный путь указывать в комментарии.
                        • Зачастую названия файлов содержат достаточно информации, чтобы раскрытие их можно было считать утечкой (например, «Переговоры с фирмой ABC» — факт переговоров может держаться в секрете; «Проект решения о ...», принятие которого повлияет на курс акций и т. д.). Да и в целом это противоречит парадигме need-to-know. Кроме того, такая схема с ростом организации просто станет малопригодной: искать каждый раз нужный отдел среди десятков, при том, что доступ есть только к одному — зачем? Тут на помощь приходит Access-based enumeration, но для его использования нужно, чтоб доступа к чужим папкам не было совсем.
                        • У вас на скриншоте верно показано, но на этом не заострено внимание: Share Permissions не должны включать Full Control, хотя, казалось бы, файловые ACL должны бы ограничить доступ, но нет: если пользователь — хозяин файла/каталога (например, он его создал), то он может задавать права, что, как правило, нежелательно.
                          0
                          Спасибо за замечания.
                          • У меня лес доменов и область действия групп выбирается по необходимости – иногда необходимо организовать доступ так чтоб туда случайно не добавили учетную запись из другого домена.
                          • У меня несколько файловых серверов и мне удобно по имени группы определять где физически находится каталог. DFS – штука хорошая, но везде применяемая.
                          • Именно по этому я не приветствую “конские” имена каталогов и разграничение прав доступа ниже 3 ну максимум 5 уровня.
                          • У меня на 2012 сервере ABE скрывает имена файлов если нет прав на чтение или запись.
                          • Абсолютно согласен.
                            0
                            > Share Permissions не должны включать Full Control

                            Это весьма спорная рекомендация — применять к одному объекту права из двух совершенно разных источников тоже не есть хорошо. Явно настаивать права владельца можно, например, так — https://technet.microsoft.com/en-us/library/dd125370%28v=ws.10%29.aspx
                              0
                              Права для владельца вырезаются на уровне родительского каталога – делается это для того чтоб где-то “не выстрелил“ доступ данным фактическому владельцу мимо разрешений на каталог куда был перемещен объект.
                            0
                            Статья в тему, над будет обсудить на работе. Вопрос, как быть с логами? Виндовые логи ничуть не поменялись со времен Windows Server 2003, найти там быстро факт удаления/переименования/перемещения файла практически невозможно(на удаление файлом в зависимости от условий может быть до 5 кодов событий), может быть подскажите какие-то инструменты, что бы можно было выяснить, кто, когда с каким файлом на шаре что сотворил? Эта информация может быть очень полезна при разборе инцидентов… тот же Netwrix логи умеет(если я сейчас ничего не путаю) но стоит очень негуманных денег (что-то около 500тыс на 150 пользователей)
                              +1
                              Попробуйте Log Parser 2.2 от Microsoft.
                              Он умеет отбирать из журналов события с конкретным кодом (чтобы не выгребать всю кучу событий) хоть в csv, хоть в базу данных.
                              Далее уже дело техники (фильтры в csv или запросы к базе данных).
                              Так же умеет запоминать последнюю обработанную запись (id события) и при следующем запуске начинать обработку только со следующей (свежей) записи.
                                0
                                Посмотрите как работает ms office, и поймёте, что включение аудита дело тухлое. Ну и аудит на сервере с 4 тб офисных файлов, где работает примерно 500 пользователей, даёт дикие размеры логов.
                                По остальным вопросам согласен, сами подобную схему использовали, главное ограничить глубину раздачи прав не ниже 2-3 уровня вложенности.
                              +1
                              Схема немного похожа на нашу.

                              Корень DFS, в нём публикуются все общие ресурсы.
                              Каждому ресурсу назначено три группы:
                              1. Share Read (операторов архивов, ботов, автоматизированных задач обслуживания и т.п.), в основном только для чтения.
                              2. D DFS ShareName (Read) — группа доступа только для чтения.
                              3. D DFS ShareName (Write) — группа доступа с правами записи.

                              Чтобы дать пользователю доступ в каталог — достаточно добавить его в группу.
                              Чтобы запретить пользователю доступ — достаточно убрать его из группы.

                              Группу на явный запрет доступа (типа D DFS ShareName Access Denied) создавать не требуется — все общие ресурсы в DFS опубликованы с настройкой отображения на основе прав доступа. Т.е. если пользователь не входит в соответствующую группу — он общий ресурс в корне DFS просто не увидит.
                              Таким образом точка входа у всех пользователей одна (корень DFS), но видит каждый из них те ресурсы, на которые у него есть права доступа (чтение и/или запись).

                              Если сотрудник увольняется «по-хорошему» — то ставится дата истечения учётной записи равной дате увольнения + 1 день. После чего в день увольнения учётная запись удаляется (в корзину), заодно и из групп.
                              Если сотрудник увольняется «по-плохому» — то учётка блокируется сразу, и опять же удаляется из всех групп.

                              А отключение наследования — головная боль. Проблему, когда есть каталог, к которому имеют доступ на чтение или запись Вася, Петя, Дима, а внутри него каталог, к которому (и только к нему) нужно дать доступ Косте — так пока и не смогли решить. Очень много действий с каталогами приходится делать.
                              Поэтому, решили в принципе не отключать наследование (для группы администраторов DFS, ShareRead), а создавать такие хитрые ресурсы, посредством публикации в корне DFS с назначением прав отдельной группе пользователей.
                                0
                                Я правильно понимаю, что бОльшая часть статьи заменяется аббревиатурой AGDLP (в особо тяжёлых случаях AGUDLP)?
                                  0
                                  За аббревиатурой невидно деталей. Ко мне не раз обращались вопросом “как лучше сделать” или “а как у тебя сделано”. Здесь для широкого круга специалистов описано как я делаю на своих серверах. Надеюсь, это принесет определенную пользу.
                                    0
                                    Угу… основная-то проблема, к сожалению, не в том, что эти вещи малоизвестны или плохо документированы, а в том, что людям лень и читать, и думать. В результате идут по пути наименьшего сопротивления в каждой конкретной ситуации, неизбежно порождая бардак. :) Ещё одна статья на тему «как надо» тут, увы, мало что исправит.
                                    0
                                    Я бы не включал FILESERV1\Администраторы в доступ к папкам, а создал бы группу «Папка-F(ull)» и в неё включил нужных файловых операторов с полным доступом. При этом включил-бы ABE, чтобы избавиться от лишних вопросов: «Почему я не могу попасть в папку ХХХ?». Так-же не вижу практического смысла на просмотр структуры каталога и соответственно группы FILESRV1-Public. И вместо суффикса «FILESERV1» использовал-бы «RES», обозначающий, что группа ресурсная, потому как использование DFS сразу избавляет от добавления имени сервера в группу.
                                      0
                                      Не вижу смысла делать еще одну группу подменяющую локальных администраторов. Access Based Enumeration использую по умолчанию – вошло уже в привычку. Я описал ситуацию где есть сотрудники которые должны писать в подкаталог “2016” без прав на запись в “Public” или “Новости”. У меня несколько файловых серверов и случается, что необходимо по имени группы определить где физически находится каталог. Это экономит время – нет необходимости лезть в АД смотреть описание группы.
                                        0
                                        > Не вижу смысла делать еще одну группу подменяющую локальных администраторов.

                                        Во-первых, это позволяет дать техподдержке возможность управлять папками без назначения их администраторами серверов.
                                        Во-вторых, это позволяет решить общеизвестную проблему с UAC при работе администратора через Windows Explorer непосредственно с файлового сервера.
                                          0
                                          Техподдержку можно включить в группу …_R или …_W базового уровня. А права локального администратора для них избыточны. С другой стороны администраторы сервера должны иметь возможность управлять каталогами этого сервера.
                                            0
                                            > Техподдержку можно включить в группу …_R или …_W базового уровня.

                                            В общем случае нельзя, потому что случается так, что им нужен Full Control, а пользователям — нет.

                                            > А права локального администратора для них избыточны.

                                            Именно об этом речь и идет. :) Нужна группа, которая, с одной стороны, не обладает правами администратора, с другой — имеет Full Control на файлы. Если, конечно, администратор не хочет сам лично разбираться с созданием новых пользовательских папок и назначением на них прав, например.

                                            В принципе эти вопросы можно решить разными способами, но один из самых простых — отдельная группа с full control на все файлы.
                                              0
                                              Full Control им не нужен, права должен менять кто-то из администраторов. Если бы у администратора голова не болела за файловый сервер, то и обсуждения этого не было бы.
                                                0
                                                Ещё раз — администрирование серверов (в т.ч. файловых) и раздача прав на пользовательские папки — это, в общем случае, две РАЗНЫЕ задачи. Если так случилось, что их выполняют одни и те же люди — отлично, отдельная группа не нужна. Но если люди разные — вопрос надо как-то решать.
                                                  0
                                                  Новые каталоги и подкаталоги, на которые определяются права доступа отличные от родительского каталога, содеются и настраиваются администратором, а дальше специально обученные девочки добавляют пользователей в группы, на которые у них есть права, по заявке. Я учувствую в этом “празднике жизни” только на начальном этапе, что там дальше происходит мне не интересно. Если возникнет необходимость беспрепятственно можно получить состав группы, а по имени ясно куда применяется.
                                                    0
                                                    Да что такое-то, я вам пишу, что бывают разные случаи разграничения полномочий, а вы всё сугубо на личный опыт сводите. :) Я же вас не заставляю так делать, просто описываю, в каких ситуациях подобный подход оправдан.
                                          0
                                          Не пробовал применить у себя DAC (Dynamic Access Control)?
                                          Как раз подходит для того, чтобы выдавать различные права различным людям в зависимости от ситуации и при этом не иметь геморрой с ресурсными группами.
                                          И очень интересует ответ на вопрос: Зачем знать, где физически находится каталог?
                                          А насчёт локальных админов и полных прав на папку — это больше для разграничения ответственности, когда в фирме есть большой ИТ-отдел, либо готовится стать большим и информационной безопасности. Да, локальный админ, если сервер «взломан», сможет сменить права и получить доступ к файлам, но на это уйдёт время и на такое действие надо ставить триггер, чтобы раньше узнать, что сервер взломали и иметь возможность быстро прикрыть доступ к серверу. Но когда на фирме один админ, но при этом он не пользуется одной админской учёткой для всей инфраструктуры, а имеет отдельные учётки на администрирование разных задач, и эти задачи загнаны в группы ролей, то чувствуешь себя более уверенней, хотя и геморройней в плане запоминания кучи логинов и паролей. Но если самому трудно, то врагам тоже не легко. :)
                                        –1
                                        Хочу поделиться своим опытом. Лично я создавал папки с наименованиями отделов ( обычно доступы у сотрудников одного отдела совпадают — у автора это Ролевые группы), и раздавал необходимые доступы внутри этой группы. Для специфичных доступов ( Глав Бух, Директор) также создавались отдельные группы, но с объединением ресурсных возможностей ( ГлавБухВсяОтчетность например) — ибо довольно часто бывает что данные доступы делегируются кому-то другому.

                                        И далее в случае увольнения человек ( или окончания делегирования) просто исключался из группы…

                                        А так — все верно и правильно…
                                          +1
                                          В статье и комментариях очень подробно и красиво показано как это должно быть. Как конкретно назначать группы и называть папки — дело левой пятки админа. Но могу поделиться советом что делать с имеющейся помойкой: Складываете все старые файлы в одну папку с доступам для всех, кто в ней раньше мог копаться, но обязательно read only и с улыбкой всем сообщаете, что через месяц удалите этот бордак к черту и типа «кто не спрятался — я не виноват» (на самом деле просто через месяц обрубаете всем доступ). В последующем отдавать документы, которые не успели растащить «через сложную систему восстановления», по сути через несколько дней после слезных просьб. Проверенно лично на 6,5 компаний (до 01.10.2016)
                                            0
                                            Сурово конечно… но ведь работает! У нас в похожем случае стали тащить все подряд — так на “всякий случай” да “про запас”. Места не прибавилось, но хотя бы с владельцами определились.
                                              0
                                              Дык задача — определиться с владельцами) А место очистить… квоты)))
                                            0
                                            Хороший текст.

                                            1. Вот ещё немного лучших практик: http://windowsitpro.com/security/12-commandments-file-sharing

                                            2. Самое главное — никому не давать Full Access, кроме System и группы администраторов, только Write/Change

                                            3. Плюс FSRM квоты + уведомления + запреты на запись всех видов исполняемых вложений
                                              0
                                              Вопрос!
                                              После добавления пользователя в доменную группу, права на папку у него появятся только после перелогирования в систему.
                                              Как Вы боритесь с данным эффектом?
                                              Как сделать чтобы не перелогиниваться и доступ появился?
                                                0
                                                Не после перелогинивания, а после того, как клиент получит новый билет Kerberos, содержащий идентификатор новой группы. Чтобы удалить все старые билеты, достаточно выполнить команду klist purge на стороне клиента.
                                                  0
                                                  Использую Windows Server 2012R2 и там билеты отсылаются системой автоматически при изменении в AD.
                                                    0
                                                    Здравствуйте, подскажите, как называется эта фича?
                                                      0
                                                      Простите, а можно ссылку на источник?
                                                      Никогда не слышал, чтобы AD самостоятельно отсылала kerberos тикеты клиентам.Интересно взглянуть на то, как работает механизм поиска текущего местоположения (или даже местоположений) пользователя.
                                                        0
                                                        Хм… Малость перепутал — при изменении в AD ничего не меняется. Доступ к папке открывается сразу, если пользователя или группу, в которую он входит, добавить в ACL.
                                                  0
                                                  Ценность статьи в том, что автор переизобрёл ADGLP. Да, это очень здоровская система, хорошо, что вы дошли до этого. Плохо то, что вообще не описано, как происходил переход от кучи групп с пользователями с доступом к куче папок к аккуратным ролевым и ресурсным группам. Как мне кажется, это вообще очень сложно формализовать.

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

                                                  Самое читаемое