Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
У вас не правильное название, должно называться «Рекомендации по организации и распределение прав доступов к файловым ресурсам на базе решений micorsoft, для малых предприятий»
Заметено отсутствие опыта работы с не видовозными файловыми системами и средами.
А как же Appned only & Read?
Execute only?
А уж про современные механизмы типа RSBAC я уж молу.
Заметено отсутствие опыта работы с не видовозными файловыми системами и средами.
А как же Appned only & Read?
Execute only?
А уж про современные механизмы типа RSBAC я уж молу.
Название правильное, поскольку данный документ именно корпоративный стандарт конфигурирования.
В нем нет цели покрыть все возможные способы организации общего доступа к файлам, что и отражено в сфере его действия.
Для других систем и случаев нужны другие стандарты, Еще раз подчеркну что это один из возможных вариантов.
В нем нет цели покрыть все возможные способы организации общего доступа к файлам, что и отражено в сфере его действия.
Для других систем и случаев нужны другие стандарты, Еще раз подчеркну что это один из возможных вариантов.
Круто! Тот редкий момент, когда на Хабре реально полезная статья)
Здесь примерно то же самое: http://windowsitpro.com/security/12-commandments-file-sharing
Единственный нюанс — есть ли смысл распространять ресурсы через ярлыки на рабочем столе, а не mapped drives — ведь свежие шифровальщики вроде Locky вполне самостоятельно сканируют подсети на предмет прав RW.
Здесь примерно то же самое: http://windowsitpro.com/security/12-commandments-file-sharing
Единственный нюанс — есть ли смысл распространять ресурсы через ярлыки на рабочем столе, а не mapped drives — ведь свежие шифровальщики вроде Locky вполне самостоятельно сканируют подсети на предмет прав RW.
Mapped drive при управлением доступом это зло.
Пример. К вам приходит заявка «Дайте доступ на папку отчет на диске О», у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий. Куда давать доступ? :)
Пример. К вам приходит заявка «Дайте доступ на папку отчет на диске О», у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий. Куда давать доступ? :)
«у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий»
что это вы написали такое? сами же пишете про стандарты и регламенты) ДИСК О — У ВСЕХ ОДИНАКОВЫЙ.
иначе это либерализм и разброд в инфраструктуре)))
что это вы написали такое? сами же пишете про стандарты и регламенты) ДИСК О — У ВСЕХ ОДИНАКОВЫЙ.
иначе это либерализм и разброд в инфраструктуре)))
К сожалению на практике так сделать не получается.
В жизни возникают ситуации когда происходит поглощения бизнеса, что неминуемо тянет за собой поглощение инфраструктуры, вот вам и два диска О ссылающиеся на разные места.
Второй нюанс это историческое развитие сети. Если вы ее разработали и ведете на протяжении всей жизни это одно, а если вам приходится наводить порядок в уже существующей это совсем другое.
Поэтому сценарий с едиными mapped dirve обречен на неудачу.
В жизни возникают ситуации когда происходит поглощения бизнеса, что неминуемо тянет за собой поглощение инфраструктуры, вот вам и два диска О ссылающиеся на разные места.
Второй нюанс это историческое развитие сети. Если вы ее разработали и ведете на протяжении всей жизни это одно, а если вам приходится наводить порядок в уже существующей это совсем другое.
Поэтому сценарий с едиными mapped dirve обречен на неудачу.
Вы круто всё так категорически написали. Расскажите, пожалуйста, на чём основывается ваша уверенность, что такого подхода достаточно для реализации любого рабочего сценария?
Лично я в свою виндовую давность deny вполне пользовался, и индивидуальные права (per user) выдавал. И оно вовсе не превращалось в ад, потому что это были вполне осознанные исключения, которые конвертировались в правила (т.е. превращались в группы) как только оказывались постоянно востребованными.
Лично я в свою виндовую давность deny вполне пользовался, и индивидуальные права (per user) выдавал. И оно вовсе не превращалось в ад, потому что это были вполне осознанные исключения, которые конвертировались в правила (т.е. превращались в группы) как только оказывались постоянно востребованными.
Расскажите, пожалуйста, на чём основывается ваша уверенность, что такого подхода достаточно для реализации любого рабочего сценария?
Уверенность основана на опыте работы по данному документу, но на слово «любой» я не претендую.
Лично я в свою виндовую давность deny вполне пользовался, и индивидуальные права (per user) выдавал. И оно вовсе не превращалось в ад, потому что это были вполне осознанные исключения, которые конвертировались в правила (т.е. превращались в группы) как только оказывались постоянно востребованными.
Вы все правильно говорите, но когда увольняется человек который раздавал права подобным образом, или когда к процессу выдачи прав нужно подключить нового админа, разобраться почему «Иван Федорович» не может прочитать тот или иной файл когда у него доступ «вроде как есть» бывает очень сложно.
Выдача «per user» прав плоха тем, что когда необходимо предоставить доступ как у «Ивана Федоровича» сделать это очень сложно. В то время как при выдаче прав «per group» можно просто скопировать и переименовать учетку в АД.
Да и еще, когда к вам приходит запрос «Куда Иван Федорович имеет доступ», то по составу групп в его учетной записи вы всегда сможете это быстро сделать не проводя аудит всех систем организации.
Еще забыл сказать. Когда выдаются права «per group» делать это могут сотрудники тех. поддержки, которым делегирован доступ в АД на изменения состава групп, но которые не являются администраторами файловых серверов.
Короче сплошные плюсы :)
Короче сплошные плюсы :)
Потому в тот момент, когда права становятся стационарными — они переходят в группу. Далеко не все бизнес-задачи являются постоянными и городить группы по каждому чиху — это оставлять следующему админу список из пары сотен групп «Петрову нужен доступ к презентациям Сидорова пока Сидоров в отпуске и ничего друго».
Потому в тот момент, когда права становятся стационарными ....
А когда наступает этот момент и кто его определяет? Вы уверены что все ваши «стационарные» права переведены на группы?
Безусловно, у каждого подхода «per user» или «per group» есть свои плюсы и минусы. Исходя из собственного опыте лучше иметь список из сотен групп, нежели проводить аудит сотен «шар», в которых предоставлены права.
Вы, простите, переломили схему именований групп в домене через колено, чтобы вам было удобнее. Основная схема групп в домене должна отражать реальную организационную структуру предприятия , то есть должны быть отделы, подотделы, должности и т.п. Тогда, если вам приходит из ОК служебка о том, что взяли Иванова И.И. на должность главного бухгалтера, вы просто заводите учетку и включаете ее в группу «Главные бухгалтеры», мало того, это же может сделать и специалист по кадрам без вашего участия, и даже система управления учетными записями (IDM).
А вот уже «на вашей стороне» группа «Главные бухгалтеры» входит в служебные группы FOLDER-FILESRV-Общая_бухгалтерии-RW, FOLDER-FILESRV-Дирекция_Главбух-RW, FOLDER-FILESRV-Дирекция_общая-RO и т.п.
А вот уже «на вашей стороне» группа «Главные бухгалтеры» входит в служебные группы FOLDER-FILESRV-Общая_бухгалтерии-RW, FOLDER-FILESRV-Дирекция_Главбух-RW, FOLDER-FILESRV-Дирекция_общая-RO и т.п.
Основная схема групп в домене должна отражать реальную организационную структуру предприятия, то есть должны быть отделы, подотделы, должности и т.п.
Вы говорите про ролевые группы, в которые помещаются работники обладающие одинаковыми привилегиями, а стандарте приведены правила наименования групп доступа, на базе которых происходит раздача прав. Замечу, что это не одно и тоже, да и вашем примере это четко видно.
В вашем примере есть ролевая группа «Главные бухгалтера», которую вы помещаете в группу доступа FOLDER-FILESRV-Общая_бухгалтерии-RW. Стандарту этому не противоречит.
Статья интересная и полезная. Реализовал в сети примерно то же самое.
Вижу существенный недостаток — необходимость прописывать КАЖДЫЙ раз права на траверс директорий при изменении доступов в нижних уровнях.
Тогда как гораздо удобнее один раз создать группу FILE-путь-TR с правами траверса и включать в нее все необходимое. Возможно, в вашей сети это обусловлено какими-либо дополнительными требованиями, но мне это существенно облегчило жизнь.
Что я еще реализовал в своей сети — это группы с запретом доступа. Считайте это паранойей, но у меня все shared-accounts, да и просто пользователи, которым нечего делать на этом ресурсе, внесены в них. И на каждом ресурсе таким группам запрещено любое действие. На всякий случай. Если у кого-то из админов AD рука дрогнет.
Резюмирую — в своей сети я на каждую папку навешиваю 4 группы доступа (за исключением описанных автором редких групп с неспецифическими правами) — это FILE-...-RO, FILE-...-RW, FILE-...-NA, FILE-...-TR в терминологии статьи. Не уверен, что это идеальный способ, но позволяет решить 99% возникающих у меня задач с разграничением доступа.
Вижу существенный недостаток — необходимость прописывать КАЖДЫЙ раз права на траверс директорий при изменении доступов в нижних уровнях.
Тогда как гораздо удобнее один раз создать группу FILE-путь-TR с правами траверса и включать в нее все необходимое. Возможно, в вашей сети это обусловлено какими-либо дополнительными требованиями, но мне это существенно облегчило жизнь.
Что я еще реализовал в своей сети — это группы с запретом доступа. Считайте это паранойей, но у меня все shared-accounts, да и просто пользователи, которым нечего делать на этом ресурсе, внесены в них. И на каждом ресурсе таким группам запрещено любое действие. На всякий случай. Если у кого-то из админов AD рука дрогнет.
Резюмирую — в своей сети я на каждую папку навешиваю 4 группы доступа (за исключением описанных автором редких групп с неспецифическими правами) — это FILE-...-RO, FILE-...-RW, FILE-...-NA, FILE-...-TR в терминологии статьи. Не уверен, что это идеальный способ, но позволяет решить 99% возникающих у меня задач с разграничением доступа.
Тогда как гораздо удобнее один раз создать группу FILE-путь-TR
В разных организациях данная схема была реализована по разному в том числе с траверс группами. В текущей, админам проще прописывать каждый раз новые траверсы, но как говорится каждому свое.
По поводу групп согласен -NA, стандарт можно расширить на указанные полномочия. Сразу описывать их не стал, поскольку у тех кто столкнулся с данной задачей впервые будет взрыв мозга.
Меня к использованию групп для траверсов подтолкнула особенность распространения прав в Windows — даже в случае применения прав «только на эту папку», система все равно норовит обежать все дерево поддиректорий. А дерево зачастую настолько велико, что назначение прав может занимать до часа.
Подозреваю, что изобретаю велосипед, но, чтобы избежать подобного, надо в каком-то автоматическом режиме создавать группы AD и назначать права _при создании_ папки на сервере. Боюсь даже представить, насколько вырастет база AD при таком подходе, и как эффективно отслеживать удаление папок и т.д.
Подозреваю, что изобретаю велосипед, но, чтобы избежать подобного, надо в каком-то автоматическом режиме создавать группы AD и назначать права _при создании_ папки на сервере. Боюсь даже представить, насколько вырастет база AD при таком подходе, и как эффективно отслеживать удаление папок и т.д.
Цитата: «Разграничение прав доступа проводится только на уровне файловой системы. На уровне сетевых протоколов SMB/CIFS права не разграничиваются (Группа «Все» – полномочия «Полный доступ» / Everyone – Full access).»
И после этого любой пользователь может отключить общий доступ к папке. Рекомендую ограничиться чтением/записью.
ps Прошу прощения, не разобрался как сделать цитатой.
И после этого любой пользователь может отключить общий доступ к папке. Рекомендую ограничиться чтением/записью.
ps Прошу прощения, не разобрался как сделать цитатой.
Спасибо! Важный нюанс. Внес коррективы в статью.
Еще по группе «эвриван» на сетевую папку. Лучше (даже МС с этим соглашается) заменить ее на группу «пользователи домена».
Здесь не соглашусь, по следующей причине:
Группа пользователи домена в общем случае уже чем Everyone и в некоторых случаях данный аспект будет ограничивать доступ, в то время как идеология данного стандарта подразумевает что все доступы режутся только на уровне NTFS.
Когда мы используем такой подход есть еще одна не явная плюшка — предоставив доступ к файловому информационному ресурсу через FTP или HTTP (IIS с авторизация Windows) нам ничего менять не нужно будет.
Группа пользователи домена в общем случае уже чем Everyone и в некоторых случаях данный аспект будет ограничивать доступ, в то время как идеология данного стандарта подразумевает что все доступы режутся только на уровне NTFS.
Когда мы используем такой подход есть еще одна не явная плюшка — предоставив доступ к файловому информационному ресурсу через FTP или HTTP (IIS с авторизация Windows) нам ничего менять не нужно будет.
Во первых спасибо автору за изложение своего видения этого процесса.
Что хотелось бы отметить и каким опытом поделиться…
1. Никто не отменяет схему AGDLP. И в данном случае если автор говорит что это ресурсные группы, то они должны быть не Global, а Domain Local
2. Привязать имя сетевой папки к имени группы идея очень даже хорошая но не реализуемая в больших средах
3. Есть много вопросов ко вложенным ресурсам
— Траверсы нужно рубить на всей вложенности (и не всегда это второй уровень а может быть и 5ый и 10ый)
— В случае если пользователи которые имеют RW доступ к такой вложенной папке вложенного ресурса (ну возьмем из примера начальника отдела) решит в прекрасный день, что папка Документация должна лежать в другом месте его информационного ресурса, то все прорубленные траверсы до конкретного локейшена не будут иметь смысла, а вот новое местоположение не будет доступно ни по правам (потому что не будет траверса) ни по полному пути (потому что он изменится)
— В случае если информационный ресурс удаляется, то никак не может ограничиваться удалением папки пользователем, хотя бы потому, что надо еще выполнить ряд процедур (удаление из реестра информационных ресурсов, удаление ненужных в ад групп и т.д.). Но в данном случае у пользователей которые имеют права RW могут удалить эту папку потому что они понятия не имеют вложенный это информационный ресурс или обычная папка
Что хотелось бы отметить и каким опытом поделиться…
1. Никто не отменяет схему AGDLP. И в данном случае если автор говорит что это ресурсные группы, то они должны быть не Global, а Domain Local
2. Привязать имя сетевой папки к имени группы идея очень даже хорошая но не реализуемая в больших средах
3. Есть много вопросов ко вложенным ресурсам
— Траверсы нужно рубить на всей вложенности (и не всегда это второй уровень а может быть и 5ый и 10ый)
— В случае если пользователи которые имеют RW доступ к такой вложенной папке вложенного ресурса (ну возьмем из примера начальника отдела) решит в прекрасный день, что папка Документация должна лежать в другом месте его информационного ресурса, то все прорубленные траверсы до конкретного локейшена не будут иметь смысла, а вот новое местоположение не будет доступно ни по правам (потому что не будет траверса) ни по полному пути (потому что он изменится)
— В случае если информационный ресурс удаляется, то никак не может ограничиваться удалением папки пользователем, хотя бы потому, что надо еще выполнить ряд процедур (удаление из реестра информационных ресурсов, удаление ненужных в ад групп и т.д.). Но в данном случае у пользователей которые имеют права RW могут удалить эту папку потому что они понятия не имеют вложенный это информационный ресурс или обычная папка
В целом согласен.
В данной схеме имеются указанные вами недостатки. К сожалению пока не вижу простых способов их закрыть.
Для себя дублируем структуру папок на уровне OU в AD, например так:
Informations reourses:
— FILE
— FILESRV
— Имя точки входа
— вложенные ресурсы
Но это тоже костели.
Если есть идеи как улучшить стандарт, давайте сделаем это :) Можно в личку отписать или обменяться контактами.
В данной схеме имеются указанные вами недостатки. К сожалению пока не вижу простых способов их закрыть.
Для себя дублируем структуру папок на уровне OU в AD, например так:
Informations reourses:
— FILE
— FILESRV
— Имя точки входа
— вложенные ресурсы
Но это тоже костели.
Если есть идеи как улучшить стандарт, давайте сделаем это :) Можно в личку отписать или обменяться контактами.
Мне кажется, важно понимать, что эффективную систему документооборота на таких средствах сделать невозможно. В нашей компании, например, достаточно жестко (в том числе и в связи с требованиями ISO) ограничена структура контролируемых папок, поэтому достаточно эффективно удается работать с разрешениями на папки.
Если есть идеи/механизмы более оптимального отслеживания/переназначения — маякните и мне. Было бы очень полезно, достаточно много времени уходит на ручную работу с правами на папки.
Если есть идеи/механизмы более оптимального отслеживания/переназначения — маякните и мне. Было бы очень полезно, достаточно много времени уходит на ручную работу с правами на папки.
Думаю что вынесение на коллективное обсуждение этой темы будет более полезным, чем частный обмен опытом. Я давно хотел увидеть какие-то подобные решения, которые были бы определенными стандартами в данной области и на которые можно было бы ссылаться при дизайне файловых хранилищ.
Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов? Зачем пользователю который по факту не видит всей структуры папок и их содержимого (ведь мы хотим скрыть папки к которым доступа нет у пользователя) должен пробираться например на 5ый уровень вложенности чтобы увидеть папку ДОКУМЕНТАЦИЯ?
На мой взгляд когда пользователь все равно не видит этих папок, то ему удовольствия нет прыгать пять уровней непонятно для чего.
В своей практике я использую немного другую модель. Я не делаю ресурсы вложенными. Я исхожу того, что должно быть четкое правило определение ресурса. Я определяю, что один ресурс — это один набор ACL. Если есть потребность для какой-то части ресурса изменить ACL, то это сигнал к тому, что информационный ресурс надо разделить на два ресурса. Т.е. модель файловых ресурсов с точки зрения ACL получается плоской и нет никаких вложенностей. Все ресурсы всегда находятся на одном уровне вложенности (т.е. всегда размещаются рядом и не надо искать где-то на 10ом уровне вложенности ничего). Соответственно права пользователей не позволяют им не двигать ни удалять ресурсы.
Если Вам уж очень захочется склеить в дерево эти ресурсы, то можно потом на базе той модели, что я описал используя DFS что-то придумать в этом направлении.
Конечно и эта модель не идеальна и иногда пользователи не понимают необходимости создания отдельных ресурсов, но такова жизнь… И поэтому если бы были стандарты или бестпрактиксы на которые можно было бы ссылаться, было значительно проще.
Вообще считаю что NTFS это очень низкоуровневое решение для задач полноценного файлового хранилища (управления файловыми ресурсами, их учета и т.д). Т.е. не хватает целой прослойки ПО которая бы автоматизировала бы эти процессы и стояла уже выше NTFS и обеспечивала бы интерфейс для управления администратору.
Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов? Зачем пользователю который по факту не видит всей структуры папок и их содержимого (ведь мы хотим скрыть папки к которым доступа нет у пользователя) должен пробираться например на 5ый уровень вложенности чтобы увидеть папку ДОКУМЕНТАЦИЯ?
На мой взгляд когда пользователь все равно не видит этих папок, то ему удовольствия нет прыгать пять уровней непонятно для чего.
В своей практике я использую немного другую модель. Я не делаю ресурсы вложенными. Я исхожу того, что должно быть четкое правило определение ресурса. Я определяю, что один ресурс — это один набор ACL. Если есть потребность для какой-то части ресурса изменить ACL, то это сигнал к тому, что информационный ресурс надо разделить на два ресурса. Т.е. модель файловых ресурсов с точки зрения ACL получается плоской и нет никаких вложенностей. Все ресурсы всегда находятся на одном уровне вложенности (т.е. всегда размещаются рядом и не надо искать где-то на 10ом уровне вложенности ничего). Соответственно права пользователей не позволяют им не двигать ни удалять ресурсы.
Если Вам уж очень захочется склеить в дерево эти ресурсы, то можно потом на базе той модели, что я описал используя DFS что-то придумать в этом направлении.
Конечно и эта модель не идеальна и иногда пользователи не понимают необходимости создания отдельных ресурсов, но такова жизнь… И поэтому если бы были стандарты или бестпрактиксы на которые можно было бы ссылаться, было значительно проще.
Вообще считаю что NTFS это очень низкоуровневое решение для задач полноценного файлового хранилища (управления файловыми ресурсами, их учета и т.д). Т.е. не хватает целой прослойки ПО которая бы автоматизировала бы эти процессы и стояла уже выше NTFS и обеспечивала бы интерфейс для управления администратору.
>>Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов? Зачем пользователю который по факту не видит всей структуры папок и их содержимого (ведь мы хотим скрыть папки к которым доступа нет у пользователя) должен пробираться например на 5ый уровень вложенности чтобы увидеть папку ДОКУМЕНТАЦИЯ?
В бизнесе моей организации такое — сплошь и рядом. Обычно это, конечно, не 5-й уровень, но второй-третий — запросто.
Имеем проектную группу — 1й уровень. В проектной группе — проект — 2й уровень. Внутри проекта — идет деление по папкам — ТЗ, переписка с клиентом, калькуляция и т.п. — 3й уровень. Для каждой папки — свои права. В ТЗ имеют дополнительный доступ, например, юристы, в документацию — нормативщик и т.д. Это не реальный слепок, но общую ситуацию вполне характеризует.
В бизнесе моей организации такое — сплошь и рядом. Обычно это, конечно, не 5-й уровень, но второй-третий — запросто.
Имеем проектную группу — 1й уровень. В проектной группе — проект — 2й уровень. Внутри проекта — идет деление по папкам — ТЗ, переписка с клиентом, калькуляция и т.п. — 3й уровень. Для каждой папки — свои права. В ТЗ имеют дополнительный доступ, например, юристы, в документацию — нормативщик и т.д. Это не реальный слепок, но общую ситуацию вполне характеризует.
Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов?
Для сквозного прохода от точки доступ. Так обычным юзерам намного проще они говорят друг-другу «Возьми файлы в паке отчеты нашего отдела», а передавать полную ссылку на путь, а тем более копировать ее в поле адрес explorerа доступно далеко не всем.
Я не делаю ресурсы вложенными
Делали бы так с удовольствием, но требования бизнеса другие, искоренить пробовали — не вариант.
… сигнал к тому, что информационный ресурс надо разделить на два ресурса…
Менять структуру файловой системы ради распределения доступа — в общем случае не вариант, так как на нее могут быть завязаны приложения, которые «привыкли» искать файлы в определенных местах. В частных случаях это можно делать, но в общем случае это тупиковый путь — пробовали. Плюс очень много негатива от пользователей.
NTFS это очень низкоуровневое решение для задач полноценного файлового хранилища (управления файловыми ресурсами, их учета и т.д). Т.е. не хватает целой прослойки ПО которая бы автоматизировала бы эти процессы и стояла уже выше NTFS и обеспечивала бы интерфейс для управления администратору.
Они есть это IDM — но это деньги.
По поводу стандартизации. Сказать пользователю, что мы не разграничиваем доступ к такой-то папке потому как это запрещено нашим внутренним стандартом — тупиковый путь. Был подобный опыт, но когда на этом настаивает топ-менеджер, то тут 2 варианта остается
1. Искать новую работу
2. Переделывать стандарт (думаю это предпочтительней).
На самом деле в данном стандарте есть один отрицательный момент — это сложность добавления прав на траверс и возможность их поломки пользователями.
Как вариант решения, думаю можно запретить удаления/переименования промежуточных каталогов.
Я Вас прекрасно понимаю и все сложности озвученные тоже мне понятны.
Один комментарий по поводу топ менеджеров — например бухгалтера и финансисты работают в соответствии регламентов, которые определяют их деятельность и возможно тоже кто-то хотел бы видеть их работу другой. Но их работа основывается на требованиях законов, документов и т.д. Т.е. они работают по своим стандартам. Пока в ИТ не будет таких же стандартов — на технические решения будет влиять любой менеджер (причем под разных менеджеров можно даже разные решения внедрять по их пожеланию ;-) ). Поэтому я изначально и говорил, что если бы были правила на которые можно было бы ссылаться — было бы проще.
Если вы готовы идти только по своему пути развития своего файлового хранилища и четко понимаете свои проблемы, то я думаю надо тогда и думать:
1. Как автоматизировать задачу прописывания траверсов
2. Как забрать права у пользователей на удаление и перемещения папок вложенных ресурсов и промежуточных папок.
Один комментарий по поводу топ менеджеров — например бухгалтера и финансисты работают в соответствии регламентов, которые определяют их деятельность и возможно тоже кто-то хотел бы видеть их работу другой. Но их работа основывается на требованиях законов, документов и т.д. Т.е. они работают по своим стандартам. Пока в ИТ не будет таких же стандартов — на технические решения будет влиять любой менеджер (причем под разных менеджеров можно даже разные решения внедрять по их пожеланию ;-) ). Поэтому я изначально и говорил, что если бы были правила на которые можно было бы ссылаться — было бы проще.
Если вы готовы идти только по своему пути развития своего файлового хранилища и четко понимаете свои проблемы, то я думаю надо тогда и думать:
1. Как автоматизировать задачу прописывания траверсов
2. Как забрать права у пользователей на удаление и перемещения папок вложенных ресурсов и промежуточных папок.
Понимаю, что жуткий некропостинг, но, возможно, кому-то пригодится.
В очередной раз переделывали свою систему управления правами и придумалось ( и сделалось) такое решение:
— на *nix системе генерится дерево неизменяемых каталогов для каждого пользователя на основании списка доступных ему проектов. В нашем случае это легко — уровни вложенности с 1 по N в нашей архитектуре статичны и изменяются только через админку;
— на N+1 уровне вложенности линкуются папки проектов из существующего Windows-файлового хранилища;
— на том же *nix сервере создается параметризованная по имени пользователя smb-шара, которая ведет его к персональному дереву каталогов.
Что достигаем таким образом:
1. Доступ пользователя к файлам теперь не зависит от AD групп, а только от групп в «админке». Таким образом, изменения доступа можно отрабатывать мгновенно;
2. Нет необходимости применять группы доступа к результирующим папкам в хранилище;
3. Сохраняются пути к файлам «как раньше», т.е. нет необходимости править ярлыки пользователям, переход на новую систему проходит абсолютно прозрачно, можно обмениваться путями к файлам в почте — если доступ к каталогу есть, то путь одинаков для всех пользователей, что UNC, что через примапленый диск;
4. В силу того, что софт построения дерева каталогов рисует только те папки, куда у пользователя есть доступ, то ликвидирован косвенный источник утечки — раньше, если даже не было доступа, пользователь видел имя папки (а она как правило называлась по имени клиента или пордукта)
5. Не ломая старую структуру хранения данных на Windows, получаем все преимущества мониторинга от *nix
Есть, конечно, и минусы, но в нашем случае, плюсы их существенно перевесили.
В очередной раз переделывали свою систему управления правами и придумалось ( и сделалось) такое решение:
— на *nix системе генерится дерево неизменяемых каталогов для каждого пользователя на основании списка доступных ему проектов. В нашем случае это легко — уровни вложенности с 1 по N в нашей архитектуре статичны и изменяются только через админку;
— на N+1 уровне вложенности линкуются папки проектов из существующего Windows-файлового хранилища;
— на том же *nix сервере создается параметризованная по имени пользователя smb-шара, которая ведет его к персональному дереву каталогов.
Что достигаем таким образом:
1. Доступ пользователя к файлам теперь не зависит от AD групп, а только от групп в «админке». Таким образом, изменения доступа можно отрабатывать мгновенно;
2. Нет необходимости применять группы доступа к результирующим папкам в хранилище;
3. Сохраняются пути к файлам «как раньше», т.е. нет необходимости править ярлыки пользователям, переход на новую систему проходит абсолютно прозрачно, можно обмениваться путями к файлам в почте — если доступ к каталогу есть, то путь одинаков для всех пользователей, что UNC, что через примапленый диск;
4. В силу того, что софт построения дерева каталогов рисует только те папки, куда у пользователя есть доступ, то ликвидирован косвенный источник утечки — раньше, если даже не было доступа, пользователь видел имя папки (а она как правило называлась по имени клиента или пордукта)
5. Не ломая старую структуру хранения данных на Windows, получаем все преимущества мониторинга от *nix
Есть, конечно, и минусы, но в нашем случае, плюсы их существенно перевесили.
Доступ пользователя к файлам теперь не зависит от AD групп
Вот это как раз и не здорово. Когда нет iDM-систем очень сложно понять какие права есть у пользователя, поэтому хотелось все завязать именно на AD, чтобы зашел и сразу было понятно что есть чего нет.
Дополнительное звено в виде «админки» на *nix это возможно здорово для вас. Проблемы начнутся тогда, когда будут появляться новые люди. Въехать в данную систему для них боюсь будет не тривиальной задачей. К тому же возникают вопросы с масштабированием такой системы доступа.
Но повторюсь, в вашей корпоративной культуре это может быть вполне работающие и удобное решение.
С AD две проблемы:
1 — обновление вектора пользователя, при добавлении/исключении в группы
2 — ограничение на членство в группах в 1020 штук. Мы реально в это упёрлись
Согласен, что система нетривиальная. Пока всё достаточно прозрачно, но, конечно, может и разрастись в неподъемного монстра. Именно поэтому мы решили, что добавление функционала проводиться не будет, только багфикс. Можно, конечно, перепилить ее с внутренней базы на кастомные поля в AD, но кмк это только всё усложнит. Если все понимают риски на входе и готовы их нести — почему нет? Ну и, конечно, везде своя специфика.
1 — обновление вектора пользователя, при добавлении/исключении в группы
Что значит вектор пользователя?
2 — ограничение на членство в группах в 1020 штук. Мы реально в это упёрлись
Можно попробовать делать вложенные группы, для файловых шар это работает, но другие софты могут их не понимать. Была такая проблема, что ряд софтин, умеющих авторизовывать и разграничивать доступ через AD анализировали только группы в которых учетная запись пользователя состояла явным образом, а вложенные группы не понимала.
Так что удобного красивого решения нет, к сожалению.
1 — When a user logs on to a computer, the Local Security Authority (LSA, a part of the Local Security Authority Subsystem) generates an access token that represents the user's security context. The access token consists of unique security identifiers (SID) for every group that the user is a member of. These SIDs include transitive groups and SID values from SIDHistory of the user and the group accounts.
И перевыпустить это токен можно только путем манипуляций со стороны клиента. Ко всему прочему, нужно дропать и переустанавливать все существующие соединения. Фактически — помогает только логоф-логон, что в середине дня делать крайне неудобно.
2 — так это не работает, увы
support.microsoft.com/en-us/help/328889/logging-on-a-user-account-that-is-a-member-of-more-than-1010-groups-ma
Да и если бы работало — членство, все равно, было бы неочевидно. Та же внешняя база, только с другого ракурса.
И перевыпустить это токен можно только путем манипуляций со стороны клиента. Ко всему прочему, нужно дропать и переустанавливать все существующие соединения. Фактически — помогает только логоф-логон, что в середине дня делать крайне неудобно.
2 — так это не работает, увы
support.microsoft.com/en-us/help/328889/logging-on-a-user-account-that-is-a-member-of-more-than-1010-groups-ma
The issue occurs when the logon user is an explicit or transitive member of about 1,010 or more security groups.
Да и если бы работало — членство, все равно, было бы неочевидно. Та же внешняя база, только с другого ракурса.
Друзья, спасибо вам за ваши комментарии. Вы помогли взглянуть на то с чем я уже давно работал свежим взглядом.
Готовлю UPDATE 1 для данной статьи (стандарта), который учтет выявленные недостатки, а также готовлю выделенную статью касательно организационных вопросов (регламентов) управления доступом к файловым информационным ресурсам.
Есть один важный нюанс. В update к данному стандарту и будущем регламенте будет применена вариативная схема построения, то есть будут документы будут содержать варианты решения той или иной задачи, а какой вариант выбрать будет уже за вами.
В общем случае архитектура документов по данной тематике следующая:
1. Стандарт управления доступом к файловым информационным ресурсам. Сугубо технический документ описывающий технические аспекты предоставления доступов
2. Регламент управления доступом. Документ описывающий взаимодействие структурны подразделений компании в части предоставления доступов, в также особенности данного взаимодействия. На уровне регламента и следует политические вопросы, например делать ли вообще вложенные ресурсы или ограничиться сугубо плоской моделью,.но это внутреннее дело каждой компании, каждый работает как ему удобней.
Также хотел пояснить почему данный документ называется стандарт. Во многих методиках по обеспечению ИБ, например в PCI DSS, указано требование что компания обязана выпустить (задокументировать) стандарты использования тех или иных технологий (в данном случае — управления доступом к папкам). Так вот цель данного документа — сделать как раз такой стандарт, который вы можете скопипастить к себе в норматику.
Готовлю UPDATE 1 для данной статьи (стандарта), который учтет выявленные недостатки, а также готовлю выделенную статью касательно организационных вопросов (регламентов) управления доступом к файловым информационным ресурсам.
Есть один важный нюанс. В update к данному стандарту и будущем регламенте будет применена вариативная схема построения, то есть будут документы будут содержать варианты решения той или иной задачи, а какой вариант выбрать будет уже за вами.
В общем случае архитектура документов по данной тематике следующая:
1. Стандарт управления доступом к файловым информационным ресурсам. Сугубо технический документ описывающий технические аспекты предоставления доступов
2. Регламент управления доступом. Документ описывающий взаимодействие структурны подразделений компании в части предоставления доступов, в также особенности данного взаимодействия. На уровне регламента и следует политические вопросы, например делать ли вообще вложенные ресурсы или ограничиться сугубо плоской моделью,.но это внутреннее дело каждой компании, каждый работает как ему удобней.
Также хотел пояснить почему данный документ называется стандарт. Во многих методиках по обеспечению ИБ, например в PCI DSS, указано требование что компания обязана выпустить (задокументировать) стандарты использования тех или иных технологий (в данном случае — управления доступом к папкам). Так вот цель данного документа — сделать как раз такой стандарт, который вы можете скопипастить к себе в норматику.
Спасибо за статью, очень много всего совпало с теми стандартами, которые применяются в нашей компании.
Правда, в нашей ситуации, траверс папок мы обошли банальным созданием ярлыков, которые ведут на промежуточные каталоги другого подразделения. Каталог с ярлыками защищен от изменений и в нем отражены все возможные директории, которые доступны всем сотрудникам их собственного подразделения.
Также, не особо в тему, но об этом мало где пишут, Windows 7 x64 имеют проблемы с траверс доступом в каталоги, если использовать для входа точный путь до каталога и копировать его в адресную строку. Лечится это апдейтом KB2821343.
Правда, в нашей ситуации, траверс папок мы обошли банальным созданием ярлыков, которые ведут на промежуточные каталоги другого подразделения. Каталог с ярлыками защищен от изменений и в нем отражены все возможные директории, которые доступны всем сотрудникам их собственного подразделения.
Также, не особо в тему, но об этом мало где пишут, Windows 7 x64 имеют проблемы с траверс доступом в каталоги, если использовать для входа точный путь до каталога и копировать его в адресную строку. Лечится это апдейтом KB2821343.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стандарт управления правами доступа к корпоративным файловым информационным ресурсам