Комментарии (33)

1. 

   Cobolorum

   21.04.2016 09:58

   #8862369

   +2

   У вас не правильное название, должно называться «Рекомендации по организации и распределение прав доступов к файловым ресурсам на базе решений micorsoft, для малых предприятий»
   Заметено отсутствие опыта работы с не видовозными файловыми системами и средами.
   А как же Appned only & Read?
   Execute only?
   А уж про современные механизмы типа RSBAC я уж молу.

   
   

   1. 

      imbasoft

      21.04.2016 11:58

      #8862647

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

1. 

   whiplash

   21.04.2016 10:34

   #8862451

   Круто! Тот редкий момент, когда на Хабре реально полезная статья)
   Здесь примерно то же самое: http://windowsitpro.com/security/12-commandments-file-sharing
   
   Единственный нюанс — есть ли смысл распространять ресурсы через ярлыки на рабочем столе, а не mapped drives — ведь свежие шифровальщики вроде Locky вполне самостоятельно сканируют подсети на предмет прав RW.

   
   

   1. 

      imbasoft

      21.04.2016 12:01

      #8862655

      Mapped drive при управлением доступом это зло.
      Пример. К вам приходит заявка «Дайте доступ на папку отчет на диске О», у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий. Куда давать доступ? :)

      
      

      1. 

         whiplash

         21.04.2016 12:20

         #8862711

         «у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий»
         
         что это вы написали такое? сами же пишете про стандарты и регламенты) ДИСК О — У ВСЕХ ОДИНАКОВЫЙ.
         иначе это либерализм и разброд в инфраструктуре)))

         
         

         1. 

            imbasoft

            21.04.2016 12:29

            #8862735

            К сожалению на практике так сделать не получается.
            В жизни возникают ситуации когда происходит поглощения бизнеса, что неминуемо тянет за собой поглощение инфраструктуры, вот вам и два диска О ссылающиеся на разные места.
            Второй нюанс это историческое развитие сети. Если вы ее разработали и ведете на протяжении всей жизни это одно, а если вам приходится наводить порядок в уже существующей это совсем другое.
            
            Поэтому сценарий с едиными mapped dirve обречен на неудачу.

1. 

   amarao

   21.04.2016 11:13

   #8862519

   Вы круто всё так категорически написали. Расскажите, пожалуйста, на чём основывается ваша уверенность, что такого подхода достаточно для реализации любого рабочего сценария?
   
   Лично я в свою виндовую давность deny вполне пользовался, и индивидуальные права (per user) выдавал. И оно вовсе не превращалось в ад, потому что это были вполне осознанные исключения, которые конвертировались в правила (т.е. превращались в группы) как только оказывались постоянно востребованными.

   
   

   1. 

      imbasoft

      21.04.2016 12:15

      #8862699

      Расскажите, пожалуйста, на чём основывается ваша уверенность, что такого подхода достаточно для реализации любого рабочего сценария?

      
      
      Уверенность основана на опыте работы по данному документу, но на слово «любой» я не претендую.
      
      

      Лично я в свою виндовую давность deny вполне пользовался, и индивидуальные права (per user) выдавал. И оно вовсе не превращалось в ад, потому что это были вполне осознанные исключения, которые конвертировались в правила (т.е. превращались в группы) как только оказывались постоянно востребованными.

      
      
      Вы все правильно говорите, но когда увольняется человек который раздавал права подобным образом, или когда к процессу выдачи прав нужно подключить нового админа, разобраться почему «Иван Федорович» не может прочитать тот или иной файл когда у него доступ «вроде как есть» бывает очень сложно.
      
      Выдача «per user» прав плоха тем, что когда необходимо предоставить доступ как у «Ивана Федоровича» сделать это очень сложно. В то время как при выдаче прав «per group» можно просто скопировать и переименовать учетку в АД.
      Да и еще, когда к вам приходит запрос «Куда Иван Федорович имеет доступ», то по составу групп в его учетной записи вы всегда сможете это быстро сделать не проводя аудит всех систем организации.
      

      
      

      1. 

         imbasoft

         21.04.2016 12:21

         #8862713

         Еще забыл сказать. Когда выдаются права «per group» делать это могут сотрудники тех. поддержки, которым делегирован доступ в АД на изменения состава групп, но которые не являются администраторами файловых серверов.
         
         Короче сплошные плюсы :)

      
      

      1. 

         amarao

         21.04.2016 14:27

         #8862965

         Потому в тот момент, когда права становятся стационарными — они переходят в группу. Далеко не все бизнес-задачи являются постоянными и городить группы по каждому чиху — это оставлять следующему админу список из пары сотен групп «Петрову нужен доступ к презентациям Сидорова пока Сидоров в отпуске и ничего друго».

         
         

         1. 

            imbasoft

            21.04.2016 14:58

            #8863009

            Потому в тот момент, когда права становятся стационарными ....

            
            А когда наступает этот момент и кто его определяет? Вы уверены что все ваши «стационарные» права переведены на группы?
            
            Безусловно, у каждого подхода «per user» или «per group» есть свои плюсы и минусы. Исходя из собственного опыте лучше иметь список из сотен групп, нежели проводить аудит сотен «шар», в которых предоставлены права.
            

            
            

            1. 

               amarao

               21.04.2016 15:38

               #8863101

               В тот момент, когда звучит «как у Петрова» или «Петрову нужно не только к Сидорову но и Иванову, потому что он тоже в отпуске».

1. 

   lovecraft

   21.04.2016 12:25

   #8862723

   Вы, простите, переломили схему именований групп в домене через колено, чтобы вам было удобнее. Основная схема групп в домене должна отражать реальную организационную структуру предприятия , то есть должны быть отделы, подотделы, должности и т.п. Тогда, если вам приходит из ОК служебка о том, что взяли Иванова И.И. на должность главного бухгалтера, вы просто заводите учетку и включаете ее в группу «Главные бухгалтеры», мало того, это же может сделать и специалист по кадрам без вашего участия, и даже система управления учетными записями (IDM).
   
   А вот уже «на вашей стороне» группа «Главные бухгалтеры» входит в служебные группы FOLDER-FILESRV-Общая_бухгалтерии-RW, FOLDER-FILESRV-Дирекция_Главбух-RW, FOLDER-FILESRV-Дирекция_общая-RO и т.п.
   

1. 

   imbasoft

   21.04.2016 13:27

   #8862831

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

   
   Вы говорите про ролевые группы, в которые помещаются работники обладающие одинаковыми привилегиями, а стандарте приведены правила наименования групп доступа, на базе которых происходит раздача прав. Замечу, что это не одно и тоже, да и вашем примере это четко видно.
   
   В вашем примере есть ролевая группа «Главные бухгалтера», которую вы помещаете в группу доступа FOLDER-FILESRV-Общая_бухгалтерии-RW. Стандарту этому не противоречит.
   

1. 

   sturi

   22.04.2016 13:11

   #8864805

   +1

   Статья интересная и полезная. Реализовал в сети примерно то же самое.
   
   Вижу существенный недостаток — необходимость прописывать КАЖДЫЙ раз права на траверс директорий при изменении доступов в нижних уровнях.
   Тогда как гораздо удобнее один раз создать группу FILE-путь-TR с правами траверса и включать в нее все необходимое. Возможно, в вашей сети это обусловлено какими-либо дополнительными требованиями, но мне это существенно облегчило жизнь.
   
   Что я еще реализовал в своей сети — это группы с запретом доступа. Считайте это паранойей, но у меня все shared-accounts, да и просто пользователи, которым нечего делать на этом ресурсе, внесены в них. И на каждом ресурсе таким группам запрещено любое действие. На всякий случай. Если у кого-то из админов AD рука дрогнет.
   
   Резюмирую — в своей сети я на каждую папку навешиваю 4 группы доступа (за исключением описанных автором редких групп с неспецифическими правами) — это FILE-...-RO, FILE-...-RW, FILE-...-NA, FILE-...-TR в терминологии статьи. Не уверен, что это идеальный способ, но позволяет решить 99% возникающих у меня задач с разграничением доступа.

   
   

   1. 

      imbasoft

      22.04.2016 15:29

      #8865161

      Тогда как гораздо удобнее один раз создать группу FILE-путь-TR

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

      
      

      1. 

         sturi

         22.04.2016 15:43

         #8865193

         Меня к использованию групп для траверсов подтолкнула особенность распространения прав в Windows — даже в случае применения прав «только на эту папку», система все равно норовит обежать все дерево поддиректорий. А дерево зачастую настолько велико, что назначение прав может занимать до часа.
         
         Подозреваю, что изобретаю велосипед, но, чтобы избежать подобного, надо в каком-то автоматическом режиме создавать группы AD и назначать права _при создании_ папки на сервере. Боюсь даже представить, насколько вырастет база AD при таком подходе, и как эффективно отслеживать удаление папок и т.д.

         
         

         1. 

            imbasoft

            22.04.2016 15:50

            #8865215

            Да, для целей ИБ нужна «третья» учетная система, которая бы вела учет прав доступа и выполняла бы работы по предоставлению доступа, а это классический IDM.
            
            Если есть деньги (от 1 млн. р., из тех цен что нам предлагали) то это хороший выбор, если нет, то живем с тем что есть.

1. 

   PegasusDuh

   22.04.2016 15:12

   #8865119

   +1

   Цитата: «Разграничение прав доступа проводится только на уровне файловой системы. На уровне сетевых протоколов SMB/CIFS права не разграничиваются (Группа «Все» – полномочия «Полный доступ» / Everyone – Full access).»
   И после этого любой пользователь может отключить общий доступ к папке. Рекомендую ограничиться чтением/записью.
   ps Прошу прощения, не разобрался как сделать цитатой.

   
   

   1. 

      imbasoft

      22.04.2016 15:13

      #8865123

      Спасибо! Важный нюанс. Внес коррективы в статью.

      
      

      1. 

         MinamotoSoft

         23.04.2016 15:37

         #8866513

         Еще по группе «эвриван» на сетевую папку. Лучше (даже МС с этим соглашается) заменить ее на группу «пользователи домена».

         
         

         1. 

            imbasoft

            23.04.2016 15:57

            #8866523

            Здесь не соглашусь, по следующей причине:
            Группа пользователи домена в общем случае уже чем Everyone и в некоторых случаях данный аспект будет ограничивать доступ, в то время как идеология данного стандарта подразумевает что все доступы режутся только на уровне NTFS.
            Когда мы используем такой подход есть еще одна не явная плюшка — предоставив доступ к файловому информационному ресурсу через FTP или HTTP (IIS с авторизация Windows) нам ничего менять не нужно будет.

1. 

   Alex-plastid

   22.04.2016 15:14

   #8865127

   +1

   Во первых спасибо автору за изложение своего видения этого процесса.
   Что хотелось бы отметить и каким опытом поделиться…
   1. Никто не отменяет схему AGDLP. И в данном случае если автор говорит что это ресурсные группы, то они должны быть не Global, а Domain Local
   2. Привязать имя сетевой папки к имени группы идея очень даже хорошая но не реализуемая в больших средах
   3. Есть много вопросов ко вложенным ресурсам
   — Траверсы нужно рубить на всей вложенности (и не всегда это второй уровень а может быть и 5ый и 10ый)
   — В случае если пользователи которые имеют RW доступ к такой вложенной папке вложенного ресурса (ну возьмем из примера начальника отдела) решит в прекрасный день, что папка Документация должна лежать в другом месте его информационного ресурса, то все прорубленные траверсы до конкретного локейшена не будут иметь смысла, а вот новое местоположение не будет доступно ни по правам (потому что не будет траверса) ни по полному пути (потому что он изменится)
   — В случае если информационный ресурс удаляется, то никак не может ограничиваться удалением папки пользователем, хотя бы потому, что надо еще выполнить ряд процедур (удаление из реестра информационных ресурсов, удаление ненужных в ад групп и т.д.). Но в данном случае у пользователей которые имеют права RW могут удалить эту папку потому что они понятия не имеют вложенный это информационный ресурс или обычная папка

   
   

   1. 

      imbasoft

      22.04.2016 15:22

      #8865141

      В целом согласен.
      В данной схеме имеются указанные вами недостатки. К сожалению пока не вижу простых способов их закрыть.
      
      Для себя дублируем структуру папок на уровне OU в AD, например так:
      Informations reourses:
      — FILE
      — FILESRV
      — Имя точки входа
      — вложенные ресурсы
      Но это тоже костели.
      
      Если есть идеи как улучшить стандарт, давайте сделаем это :) Можно в личку отписать или обменяться контактами.

      
      

      1. 

         sturi

         22.04.2016 15:36

         #8865171

         Мне кажется, важно понимать, что эффективную систему документооборота на таких средствах сделать невозможно. В нашей компании, например, достаточно жестко (в том числе и в связи с требованиями ISO) ограничена структура контролируемых папок, поэтому достаточно эффективно удается работать с разрешениями на папки.
         
         Если есть идеи/механизмы более оптимального отслеживания/переназначения — маякните и мне. Было бы очень полезно, достаточно много времени уходит на ручную работу с правами на папки.

         
         

         1. 

            imbasoft

            22.04.2016 15:55

            #8865227

            Варианты есть — IDM, но там цены «уж больно уж».

            
            

            1. 

               sturi

               22.04.2016 15:58

               #8865235

               Поэтому и остается в рамках имеющихся механизмов пытаться делать максимально возможное, увы

      
      

      1. 

         Alex-plastid

         22.04.2016 16:52

         #8865369

         Думаю что вынесение на коллективное обсуждение этой темы будет более полезным, чем частный обмен опытом. Я давно хотел увидеть какие-то подобные решения, которые были бы определенными стандартами в данной области и на которые можно было бы ссылаться при дизайне файловых хранилищ.
         Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов? Зачем пользователю который по факту не видит всей структуры папок и их содержимого (ведь мы хотим скрыть папки к которым доступа нет у пользователя) должен пробираться например на 5ый уровень вложенности чтобы увидеть папку ДОКУМЕНТАЦИЯ?
         На мой взгляд когда пользователь все равно не видит этих папок, то ему удовольствия нет прыгать пять уровней непонятно для чего.
         В своей практике я использую немного другую модель. Я не делаю ресурсы вложенными. Я исхожу того, что должно быть четкое правило определение ресурса. Я определяю, что один ресурс — это один набор ACL. Если есть потребность для какой-то части ресурса изменить ACL, то это сигнал к тому, что информационный ресурс надо разделить на два ресурса. Т.е. модель файловых ресурсов с точки зрения ACL получается плоской и нет никаких вложенностей. Все ресурсы всегда находятся на одном уровне вложенности (т.е. всегда размещаются рядом и не надо искать где-то на 10ом уровне вложенности ничего). Соответственно права пользователей не позволяют им не двигать ни удалять ресурсы.
         Если Вам уж очень захочется склеить в дерево эти ресурсы, то можно потом на базе той модели, что я описал используя DFS что-то придумать в этом направлении.
         Конечно и эта модель не идеальна и иногда пользователи не понимают необходимости создания отдельных ресурсов, но такова жизнь… И поэтому если бы были стандарты или бестпрактиксы на которые можно было бы ссылаться, было значительно проще.
         Вообще считаю что NTFS это очень низкоуровневое решение для задач полноценного файлового хранилища (управления файловыми ресурсами, их учета и т.д). Т.е. не хватает целой прослойки ПО которая бы автоматизировала бы эти процессы и стояла уже выше NTFS и обеспечивала бы интерфейс для управления администратору.

         
         

         1. 

            sturi

            24.04.2016 14:23

            #8867115

            >>Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов? Зачем пользователю который по факту не видит всей структуры папок и их содержимого (ведь мы хотим скрыть папки к которым доступа нет у пользователя) должен пробираться например на 5ый уровень вложенности чтобы увидеть папку ДОКУМЕНТАЦИЯ?
            
            В бизнесе моей организации такое — сплошь и рядом. Обычно это, конечно, не 5-й уровень, но второй-третий — запросто.
            Имеем проектную группу — 1й уровень. В проектной группе — проект — 2й уровень. Внутри проекта — идет деление по папкам — ТЗ, переписка с клиентом, калькуляция и т.п. — 3й уровень. Для каждой папки — свои права. В ТЗ имеют дополнительный доступ, например, юристы, в документацию — нормативщик и т.д. Это не реальный слепок, но общую ситуацию вполне характеризует.

1. 

   imbasoft

   22.04.2016 17:32

   #8865461

   Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов?

   
   Для сквозного прохода от точки доступ. Так обычным юзерам намного проще они говорят друг-другу «Возьми файлы в паке отчеты нашего отдела», а передавать полную ссылку на путь, а тем более копировать ее в поле адрес explorerа доступно далеко не всем.
   
   

   Я не делаю ресурсы вложенными

   
   Делали бы так с удовольствием, но требования бизнеса другие, искоренить пробовали — не вариант.
   
   

   … сигнал к тому, что информационный ресурс надо разделить на два ресурса…

   
   Менять структуру файловой системы ради распределения доступа — в общем случае не вариант, так как на нее могут быть завязаны приложения, которые «привыкли» искать файлы в определенных местах. В частных случаях это можно делать, но в общем случае это тупиковый путь — пробовали. Плюс очень много негатива от пользователей.
   
   

   NTFS это очень низкоуровневое решение для задач полноценного файлового хранилища (управления файловыми ресурсами, их учета и т.д). Т.е. не хватает целой прослойки ПО которая бы автоматизировала бы эти процессы и стояла уже выше NTFS и обеспечивала бы интерфейс для управления администратору.

   
   Они есть это IDM — но это деньги.
   
   По поводу стандартизации. Сказать пользователю, что мы не разграничиваем доступ к такой-то папке потому как это запрещено нашим внутренним стандартом — тупиковый путь. Был подобный опыт, но когда на этом настаивает топ-менеджер, то тут 2 варианта остается
   1. Искать новую работу
   2. Переделывать стандарт (думаю это предпочтительней).
   
   На самом деле в данном стандарте есть один отрицательный момент — это сложность добавления прав на траверс и возможность их поломки пользователями.
   
   Как вариант решения, думаю можно запретить удаления/переименования промежуточных каталогов.

   
   

   1. 

      Alex-plastid

      22.04.2016 17:49

      #8865485

      Я Вас прекрасно понимаю и все сложности озвученные тоже мне понятны.
      Один комментарий по поводу топ менеджеров — например бухгалтера и финансисты работают в соответствии регламентов, которые определяют их деятельность и возможно тоже кто-то хотел бы видеть их работу другой. Но их работа основывается на требованиях законов, документов и т.д. Т.е. они работают по своим стандартам. Пока в ИТ не будет таких же стандартов — на технические решения будет влиять любой менеджер (причем под разных менеджеров можно даже разные решения внедрять по их пожеланию ;-) ). Поэтому я изначально и говорил, что если бы были правила на которые можно было бы ссылаться — было бы проще.
      Если вы готовы идти только по своему пути развития своего файлового хранилища и четко понимаете свои проблемы, то я думаю надо тогда и думать:
      1. Как автоматизировать задачу прописывания траверсов
      2. Как забрать права у пользователей на удаление и перемещения папок вложенных ресурсов и промежуточных папок.

1. 

   imbasoft

   23.04.2016 16:14

   #8866531

   Друзья, спасибо вам за ваши комментарии. Вы помогли взглянуть на то с чем я уже давно работал свежим взглядом.
   
   Готовлю UPDATE 1 для данной статьи (стандарта), который учтет выявленные недостатки, а также готовлю выделенную статью касательно организационных вопросов (регламентов) управления доступом к файловым информационным ресурсам.
   
   Есть один важный нюанс. В update к данному стандарту и будущем регламенте будет применена вариативная схема построения, то есть будут документы будут содержать варианты решения той или иной задачи, а какой вариант выбрать будет уже за вами.
   
   В общем случае архитектура документов по данной тематике следующая:
   1. Стандарт управления доступом к файловым информационным ресурсам. Сугубо технический документ описывающий технические аспекты предоставления доступов
   2. Регламент управления доступом. Документ описывающий взаимодействие структурны подразделений компании в части предоставления доступов, в также особенности данного взаимодействия. На уровне регламента и следует политические вопросы, например делать ли вообще вложенные ресурсы или ограничиться сугубо плоской моделью,.но это внутреннее дело каждой компании, каждый работает как ему удобней.
   
   Также хотел пояснить почему данный документ называется стандарт. Во многих методиках по обеспечению ИБ, например в PCI DSS, указано требование что компания обязана выпустить (задокументировать) стандарты использования тех или иных технологий (в данном случае — управления доступом к папкам). Так вот цель данного документа — сделать как раз такой стандарт, который вы можете скопипастить к себе в норматику.
   

   
   

   1. 

      sturi

      24.04.2016 14:17

      #8867109

      Не сочтите за труд, ответьте на этот коммент, когда опубликуете. Или просто в личку напишите.
      Заранее спасибо.