Comments 58
>Допустим, сотрудник Петя увольняется со скандалом, и вам нужно сделать так, чтобы он ничего напоследок не поломал
Почему-то не упомянут пункт 0: «Блокируем его учетку».
Почему-то не упомянут пункт 0: «Блокируем его учетку».
Пункта “0” не существует — сотрудник подал заявление и у него есть еще две недели, учетная запись блокируется только после увольнения.
Так если вы ему перекроете кислород, как он будет исполнять свои обязанности две недели?
Возможность оперативно оценить риски ИБ не является “перекрытием кислорода”. Проанализировав доступы можно будет принять правильные решения, например, что необходимо предоставить приемнику для обеспечения непрерывности бизнес-процессов.
Т.е. предварительно он не мог уже накосячить? И вы только по факту скандала начинаете перекрывать доступы?
Наблюдал одно феерическое увольнение: Во всем офисе вырубается интернет, сотрудников вызывают к шефу на ковер, в этот момент блокируют их учетки и они перестают иметь доступ к данным. Им сообщают, что они уволены с сей минуты и должны покинуть свои рабочие места. Сотрудники возвращаются на свои места за вещами, видят что их компы залочены, начинается крик, их вежливо просят покинуть помещение. Те просят вернуть им «фотки», которые у них на компе и вообще ***** ****. Их сопроводят на выход.
Потом в этом офисе убили всю инфраструктуру и поставили бесконтрольную шару на *nix, но это уже совсем другая история.
Наблюдал одно феерическое увольнение: Во всем офисе вырубается интернет, сотрудников вызывают к шефу на ковер, в этот момент блокируют их учетки и они перестают иметь доступ к данным. Им сообщают, что они уволены с сей минуты и должны покинуть свои рабочие места. Сотрудники возвращаются на свои места за вещами, видят что их компы залочены, начинается крик, их вежливо просят покинуть помещение. Те просят вернуть им «фотки», которые у них на компе и вообще ***** ****. Их сопроводят на выход.
Потом в этом офисе убили всю инфраструктуру и поставили бесконтрольную шару на *nix, но это уже совсем другая история.
> сотрудник подал заявление и у него есть еще две недели
А вы случайно не забыли, что уведомление за две недели — это норма, защищающая работодателя, а не сотрудника? Пусть пишет заявление на увольнение с сегодняшнего дня, работодатель вправе сказать «хорошо, уходи». Зачем держать потенциально опасного и, вероятно, уже бесполезного человека, да ещё и платить ему.
А вы случайно не забыли, что уведомление за две недели — это норма, защищающая работодателя, а не сотрудника? Пусть пишет заявление на увольнение с сегодняшнего дня, работодатель вправе сказать «хорошо, уходи». Зачем держать потенциально опасного и, вероятно, уже бесполезного человека, да ещё и платить ему.
Не представляю сотрудника с достаточно широкими правами, в тоже время настолько бесполезного, что его можно уволить в один день без ущерба для бизнеса.
Что значит «с достаточно широкими правами»? Достаточно широкими правами для чего, для удаления каких-либо документов? Это почти любой сотрудник.
И что значит «уволить без ущерба для бизнеса»? Любое увольнение — это потеря денег, некоторый ущерб, независимо от наличия прав у увольняемого. А если увольнение человека приводит к остановке бизнеса, то это либо топ, либо у компании большие проблемы с преемственностью и менеджментом.
Я, в свою очередь, не представляю человека, у которого можно отобрать права «без ущерба для бизнеса». Если он продолжает полноценно работать после лишения некоторых прав, значит, ему эти права были выданы ошибочно.
И что значит «уволить без ущерба для бизнеса»? Любое увольнение — это потеря денег, некоторый ущерб, независимо от наличия прав у увольняемого. А если увольнение человека приводит к остановке бизнеса, то это либо топ, либо у компании большие проблемы с преемственностью и менеджментом.
Я, в свою очередь, не представляю человека, у которого можно отобрать права «без ущерба для бизнеса». Если он продолжает полноценно работать после лишения некоторых прав, значит, ему эти права были выданы ошибочно.
Теневые копии + аудит на «Удаление файлов» для учётки Пети.
Теневые копии для интенсивно используемого файлового сервера и последующий анализ журналов – вариант интересный, но трудозатраты по анализу логов могут потребовать отдельного, хотя бы, специально “натасканного” сотрудника.
Так логи можно тем же PowerShell'ом вытащить и отфильтровать нужное. А остальной анализ будет уже простым и особых навыков не требует.
Резервное копирование требует меньше затрат.
А Diskeeper Undelete Server edition и вовсе эмулирует полно-журналируемую файловую систему.
А Diskeeper Undelete Server edition и вовсе эмулирует полно-журналируемую файловую систему.
> Допустим, сотрудник Петя увольняется со скандалом
А вы не пробовали не кидать сотрудников с зарплатой? Или это не вариант для вашего бизнеса?
А вы не пробовали не кидать сотрудников с зарплатой? Или это не вариант для вашего бизнеса?
Постоянно попадаются люди, которым нечего сказать, но очень хочется.
Задайте вопрос «по делу».
Задайте вопрос «по делу».
Мне жаль, что у Вас есть такой печальный опыт, но поводы и причины для скандала и увольнения могут быть самые разные…
А я например менял рутовые пароли в то время, когда в соседнем помещении текущий ИТ отдел оповещали об увольнении с этой минуты.
Еще могу вспомнить аналогичный инцидент, когда админа компании в соседнем офисе забирала группа захвата прямо на рабочем месте — промшпионаж.
Интересная статья, во многом перекликается с моей «Стандарт управления правами доступа к корпоративным файловым информационным ресурсам»
Я правильно понял что в данном примере OU в AD создаются Чисто для красоты?
Спасибо за статью. Несколько замечаний:
- Для ресурсных групп обычно принято использовать Domain Local Groups. Они чуть гибче (если у вас один домен, то — на будущее) и заодно легко фильтровать ролевые и ресурсные группы.
- Вписывать имя сервера куда-либо я бы не рекомендовал. Сгорит/устареет он завтра, и что вы будете делать? Ночью подменять его на новый сервер с таким же именем? Я бы и file shares как domain-based DFS сразу оформил, пусть и с одним сервером пока, а уж вписывать имя сервера во все группы — где же тут универсальность?
- При именовании группы с включением названий всех подкаталогов можно потенциально упереться в 64 символа, и тогда придётся урезать — делать нестандартное название. Значащих слов в структуре каталогов, как правило, меньше, можно ограничиться только ими (например, последние 2 уровня или первый и последний уровень и т. д.), а полный путь указывать в комментарии.
- Зачастую названия файлов содержат достаточно информации, чтобы раскрытие их можно было считать утечкой (например, «Переговоры с фирмой ABC» — факт переговоров может держаться в секрете; «Проект решения о ...», принятие которого повлияет на курс акций и т. д.). Да и в целом это противоречит парадигме need-to-know. Кроме того, такая схема с ростом организации просто станет малопригодной: искать каждый раз нужный отдел среди десятков, при том, что доступ есть только к одному — зачем? Тут на помощь приходит Access-based enumeration, но для его использования нужно, чтоб доступа к чужим папкам не было совсем.
- У вас на скриншоте верно показано, но на этом не заострено внимание: Share Permissions не должны включать Full Control, хотя, казалось бы, файловые ACL должны бы ограничить доступ, но нет: если пользователь — хозяин файла/каталога (например, он его создал), то он может задавать права, что, как правило, нежелательно.
Спасибо за замечания.
- У меня лес доменов и область действия групп выбирается по необходимости – иногда необходимо организовать доступ так чтоб туда случайно не добавили учетную запись из другого домена.
- У меня несколько файловых серверов и мне удобно по имени группы определять где физически находится каталог. DFS – штука хорошая, но везде применяемая.
- Именно по этому я не приветствую “конские” имена каталогов и разграничение прав доступа ниже 3 ну максимум 5 уровня.
- У меня на 2012 сервере ABE скрывает имена файлов если нет прав на чтение или запись.
- Абсолютно согласен.
> Share Permissions не должны включать Full Control
Это весьма спорная рекомендация — применять к одному объекту права из двух совершенно разных источников тоже не есть хорошо. Явно настаивать права владельца можно, например, так — https://technet.microsoft.com/en-us/library/dd125370%28v=ws.10%29.aspx
Это весьма спорная рекомендация — применять к одному объекту права из двух совершенно разных источников тоже не есть хорошо. Явно настаивать права владельца можно, например, так — https://technet.microsoft.com/en-us/library/dd125370%28v=ws.10%29.aspx
Статья в тему, над будет обсудить на работе. Вопрос, как быть с логами? Виндовые логи ничуть не поменялись со времен Windows Server 2003, найти там быстро факт удаления/переименования/перемещения файла практически невозможно(на удаление файлом в зависимости от условий может быть до 5 кодов событий), может быть подскажите какие-то инструменты, что бы можно было выяснить, кто, когда с каким файлом на шаре что сотворил? Эта информация может быть очень полезна при разборе инцидентов… тот же Netwrix логи умеет(если я сейчас ничего не путаю) но стоит очень негуманных денег (что-то около 500тыс на 150 пользователей)
Попробуйте Log Parser 2.2 от Microsoft.
Он умеет отбирать из журналов события с конкретным кодом (чтобы не выгребать всю кучу событий) хоть в csv, хоть в базу данных.
Далее уже дело техники (фильтры в csv или запросы к базе данных).
Так же умеет запоминать последнюю обработанную запись (id события) и при следующем запуске начинать обработку только со следующей (свежей) записи.
Он умеет отбирать из журналов события с конкретным кодом (чтобы не выгребать всю кучу событий) хоть в csv, хоть в базу данных.
Далее уже дело техники (фильтры в csv или запросы к базе данных).
Так же умеет запоминать последнюю обработанную запись (id события) и при следующем запуске начинать обработку только со следующей (свежей) записи.
Посмотрите как работает ms office, и поймёте, что включение аудита дело тухлое. Ну и аудит на сервере с 4 тб офисных файлов, где работает примерно 500 пользователей, даёт дикие размеры логов.
По остальным вопросам согласен, сами подобную схему использовали, главное ограничить глубину раздачи прав не ниже 2-3 уровня вложенности.
По остальным вопросам согласен, сами подобную схему использовали, главное ограничить глубину раздачи прав не ниже 2-3 уровня вложенности.
Схема немного похожа на нашу.
Корень 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 с назначением прав отдельной группе пользователей.
Корень 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 с назначением прав отдельной группе пользователей.
Я правильно понимаю, что бОльшая часть статьи заменяется аббревиатурой AGDLP (в особо тяжёлых случаях AGUDLP)?
За аббревиатурой невидно деталей. Ко мне не раз обращались вопросом “как лучше сделать” или “а как у тебя сделано”. Здесь для широкого круга специалистов описано как я делаю на своих серверах. Надеюсь, это принесет определенную пользу.
Угу… основная-то проблема, к сожалению, не в том, что эти вещи малоизвестны или плохо документированы, а в том, что людям лень и читать, и думать. В результате идут по пути наименьшего сопротивления в каждой конкретной ситуации, неизбежно порождая бардак. :) Ещё одна статья на тему «как надо» тут, увы, мало что исправит.
Я бы не включал FILESERV1\Администраторы в доступ к папкам, а создал бы группу «Папка-F(ull)» и в неё включил нужных файловых операторов с полным доступом. При этом включил-бы ABE, чтобы избавиться от лишних вопросов: «Почему я не могу попасть в папку ХХХ?». Так-же не вижу практического смысла на просмотр структуры каталога и соответственно группы FILESRV1-Public. И вместо суффикса «FILESERV1» использовал-бы «RES», обозначающий, что группа ресурсная, потому как использование DFS сразу избавляет от добавления имени сервера в группу.
Не вижу смысла делать еще одну группу подменяющую локальных администраторов. Access Based Enumeration использую по умолчанию – вошло уже в привычку. Я описал ситуацию где есть сотрудники которые должны писать в подкаталог “2016” без прав на запись в “Public” или “Новости”. У меня несколько файловых серверов и случается, что необходимо по имени группы определить где физически находится каталог. Это экономит время – нет необходимости лезть в АД смотреть описание группы.
> Не вижу смысла делать еще одну группу подменяющую локальных администраторов.
Во-первых, это позволяет дать техподдержке возможность управлять папками без назначения их администраторами серверов.
Во-вторых, это позволяет решить общеизвестную проблему с UAC при работе администратора через Windows Explorer непосредственно с файлового сервера.
Во-первых, это позволяет дать техподдержке возможность управлять папками без назначения их администраторами серверов.
Во-вторых, это позволяет решить общеизвестную проблему с UAC при работе администратора через Windows Explorer непосредственно с файлового сервера.
Техподдержку можно включить в группу …_R или …_W базового уровня. А права локального администратора для них избыточны. С другой стороны администраторы сервера должны иметь возможность управлять каталогами этого сервера.
> Техподдержку можно включить в группу …_R или …_W базового уровня.
В общем случае нельзя, потому что случается так, что им нужен Full Control, а пользователям — нет.
> А права локального администратора для них избыточны.
Именно об этом речь и идет. :) Нужна группа, которая, с одной стороны, не обладает правами администратора, с другой — имеет Full Control на файлы. Если, конечно, администратор не хочет сам лично разбираться с созданием новых пользовательских папок и назначением на них прав, например.
В принципе эти вопросы можно решить разными способами, но один из самых простых — отдельная группа с full control на все файлы.
В общем случае нельзя, потому что случается так, что им нужен Full Control, а пользователям — нет.
> А права локального администратора для них избыточны.
Именно об этом речь и идет. :) Нужна группа, которая, с одной стороны, не обладает правами администратора, с другой — имеет Full Control на файлы. Если, конечно, администратор не хочет сам лично разбираться с созданием новых пользовательских папок и назначением на них прав, например.
В принципе эти вопросы можно решить разными способами, но один из самых простых — отдельная группа с full control на все файлы.
Full Control им не нужен, права должен менять кто-то из администраторов. Если бы у администратора голова не болела за файловый сервер, то и обсуждения этого не было бы.
Ещё раз — администрирование серверов (в т.ч. файловых) и раздача прав на пользовательские папки — это, в общем случае, две РАЗНЫЕ задачи. Если так случилось, что их выполняют одни и те же люди — отлично, отдельная группа не нужна. Но если люди разные — вопрос надо как-то решать.
Новые каталоги и подкаталоги, на которые определяются права доступа отличные от родительского каталога, содеются и настраиваются администратором, а дальше специально обученные девочки добавляют пользователей в группы, на которые у них есть права, по заявке. Я учувствую в этом “празднике жизни” только на начальном этапе, что там дальше происходит мне не интересно. Если возникнет необходимость беспрепятственно можно получить состав группы, а по имени ясно куда применяется.
Не пробовал применить у себя DAC (Dynamic Access Control)?
Как раз подходит для того, чтобы выдавать различные права различным людям в зависимости от ситуации и при этом не иметь геморрой с ресурсными группами.
И очень интересует ответ на вопрос: Зачем знать, где физически находится каталог?
А насчёт локальных админов и полных прав на папку — это больше для разграничения ответственности, когда в фирме есть большой ИТ-отдел, либо готовится стать большим и информационной безопасности. Да, локальный админ, если сервер «взломан», сможет сменить права и получить доступ к файлам, но на это уйдёт время и на такое действие надо ставить триггер, чтобы раньше узнать, что сервер взломали и иметь возможность быстро прикрыть доступ к серверу. Но когда на фирме один админ, но при этом он не пользуется одной админской учёткой для всей инфраструктуры, а имеет отдельные учётки на администрирование разных задач, и эти задачи загнаны в группы ролей, то чувствуешь себя более уверенней, хотя и геморройней в плане запоминания кучи логинов и паролей. Но если самому трудно, то врагам тоже не легко. :)
Как раз подходит для того, чтобы выдавать различные права различным людям в зависимости от ситуации и при этом не иметь геморрой с ресурсными группами.
И очень интересует ответ на вопрос: Зачем знать, где физически находится каталог?
А насчёт локальных админов и полных прав на папку — это больше для разграничения ответственности, когда в фирме есть большой ИТ-отдел, либо готовится стать большим и информационной безопасности. Да, локальный админ, если сервер «взломан», сможет сменить права и получить доступ к файлам, но на это уйдёт время и на такое действие надо ставить триггер, чтобы раньше узнать, что сервер взломали и иметь возможность быстро прикрыть доступ к серверу. Но когда на фирме один админ, но при этом он не пользуется одной админской учёткой для всей инфраструктуры, а имеет отдельные учётки на администрирование разных задач, и эти задачи загнаны в группы ролей, то чувствуешь себя более уверенней, хотя и геморройней в плане запоминания кучи логинов и паролей. Но если самому трудно, то врагам тоже не легко. :)
UFO just landed and posted this here
В статье и комментариях очень подробно и красиво показано как это должно быть. Как конкретно назначать группы и называть папки — дело левой пятки админа. Но могу поделиться советом что делать с имеющейся помойкой: Складываете все старые файлы в одну папку с доступам для всех, кто в ней раньше мог копаться, но обязательно read only и с улыбкой всем сообщаете, что через месяц удалите этот бордак к черту и типа «кто не спрятался — я не виноват» (на самом деле просто через месяц обрубаете всем доступ). В последующем отдавать документы, которые не успели растащить «через сложную систему восстановления», по сути через несколько дней после слезных просьб. Проверенно лично на 6,5 компаний (до 01.10.2016)
Хороший текст.
1. Вот ещё немного лучших практик: http://windowsitpro.com/security/12-commandments-file-sharing
2. Самое главное — никому не давать Full Access, кроме System и группы администраторов, только Write/Change
3. Плюс FSRM квоты + уведомления + запреты на запись всех видов исполняемых вложений
1. Вот ещё немного лучших практик: http://windowsitpro.com/security/12-commandments-file-sharing
2. Самое главное — никому не давать Full Access, кроме System и группы администраторов, только Write/Change
3. Плюс FSRM квоты + уведомления + запреты на запись всех видов исполняемых вложений
Вопрос!
После добавления пользователя в доменную группу, права на папку у него появятся только после перелогирования в систему.
Как Вы боритесь с данным эффектом?
Как сделать чтобы не перелогиниваться и доступ появился?
После добавления пользователя в доменную группу, права на папку у него появятся только после перелогирования в систему.
Как Вы боритесь с данным эффектом?
Как сделать чтобы не перелогиниваться и доступ появился?
Не после перелогинивания, а после того, как клиент получит новый билет Kerberos, содержащий идентификатор новой группы. Чтобы удалить все старые билеты, достаточно выполнить команду klist purge на стороне клиента.
Использую Windows Server 2012R2 и там билеты отсылаются системой автоматически при изменении в AD.
UFO just landed and posted this here
Sign up to leave a comment.
Аспирин от настройки прав на файловом сервере