Прав доступа к информационным ресурсам
Прав доступа к информационным ресурсамСкачать файл - Прав доступа к информационным ресурсам
Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Что может быть проще, чем разграничить права на папку в NTFS? Чтобы эффективно работать в подобных условиях, требуется определенная договоренность, или стандарт, который бы описывал, как решать подобные задачи. В данной статье мы как раз и рассмотрим один из вариантов подобного стандарта. Сфера действия Стандарт управления правами доступа к корпоративным файловым информационным ресурсам далее — Стандарт регламентирует процессы предоставления доступа к файловым информационным ресурсам, размещенным на компьютерах, работающих под управлением операционных систем семейства Microsoft Windows. Термины и определения Информационный ресурс — поименованная совокупность данных, к которой применяются методы и средства обеспечения информационной безопасности например, разграничение доступа. Файловый информационный ресурс — совокупность файлов и папок, хранящихся в каталоге файловой системы который называется корневым каталогом файлового информационного ресурса , доступ к которой разграничивается. Составной файловый информационный ресурс — это файловый информационный ресурс, содержащий в себе один или несколько вложенных файловых информационных ресурсов, отличающихся от данного ресурса правами доступа. Вложенный файловый информационный ресурс — это файловый информационный ресурс, входящий в составной информационный ресурс. Точка входа в файловый информационный ресурс — каталог файловой системы, к которому предоставляется сетевой доступ shared folder и который используется для обеспечения доступа к файловому информационному ресурсу. Данный каталог обычно совпадает с корневым каталогом файлового информационного ресурса, но может быть и вышестоящим. Промежуточный каталог — каталог файловой системы, находящийся на пути от точки входа в файловый информационной ресурс к корневому каталогу файлового информационного ресурса. Если точка входа в файловый информационный ресурс является вышестоящим каталогом по отношению к корневому каталогу файлового информационного ресурса, то она также будет являться промежуточным каталогом. Группа доступа пользователей — локальная или доменная группа безопасности, содержащая в конечном счете учетные записи пользователей, наделенные одним из вариантов полномочий доступа к файловому информационному ресурсу. Основные принципы Доступ разграничивается только на уровне каталогов. Ограничение доступа к отдельным файлам не проводится. Назначение прав доступа выполняется на базе групп безопасности. Назначение прав доступа на отдельные учетные записи пользователей не проводится. Явно запрещающие полномочия доступа deny permissions не применяются. Разграничение прав доступа проводится только на уровне файловой системы. Создание файловых информационных ресурсов на рабочих станциях пользователей недопустимо. Не рекомендуется размещать файловые информационные ресурсы на системных разделах серверов. Не рекомендуется создавать несколько точек входа в файловый информационный ресурс. Следует по возможности избегать создание вложенных файловых информационных ресурсов, а в случаях, когда имена файлов или каталогов содержат конфиденциальную информацию, это вовсе недопустимо Модель разграничения доступа Доступ пользователей к файловому информационному ресурсу предоставляется путем наделения их одним из вариантов полномочий: Для реализаций новый полномочий необходимо будет уточнить пункт В. Правила именования групп доступа пользователей Имена групп доступа пользователей формируются по шаблону: FILE-Имя файлового информационного ресурса—аббревиатура полномочий Имя файлового информационного ресурса должно совпадать с UNC именем ресурса или состоять из имени сервера и локального пути если сетевой доступ к ресурсу не предоставляется. При необходимости в данном поле допускаются сокращения. FILE-TERMSRV-D-UsersData-RW Шаблон прав доступа к каталогам файлового информационного ресурса Таблица 1 — Шаблон NTFS-прав доступа для корневого каталога файлового информационного ресурса. Субъекты Права Режим наследования Наследование прав доступа от вышестоящих каталогов отключено А Обязательные права Специальная учетная запись: Субъекты Права Режим наследования Наследование прав доступа от вышестоящих каталогов включено , но если данный каталог является вышестоящим по отношению к файловым информационным ресурсам и не входит ни в один другой файловый информационный ресурс, то наследование отключено А Обязательные права Специальная учетная запись: Создание файлового информационного ресурса При создании файлового информационного ресурса выполняются следующие действия: Создаются группы доступа пользователей. Если сервер, на котором размещен файловый информационный ресурс, является членом домена, то создаются доменные группы. Если нет, то группы создаются локально на сервере. На корневой каталог и промежуточные каталоги файлового информационного ресурса назначаются права доступа согласно шаблонам прав доступа. В группы доступа пользователей добавляются учетные записи пользователей в соответствии с их полномочиями. При необходимости для файлового информационного ресурса создается сетевая папка shared folder. Предоставление пользователю доступа к файловому информационному ресурсу Учетная запись пользователя помещается в соответствующую группу доступа пользователя в зависимости от его полномочий. Изменение доступа пользователя к файловому информационному ресурсу Учетная запись пользователя перемещается в другую группу доступа пользователей в зависимости от указанных полномочий. Блокирование доступа пользователя к файловому информационному ресурсу Учетная запись пользователя удаляется из групп доступа пользователей файлового информационного ресурса. Если работник увольняется, то членство в группах не меняется, а блокируется учетная запись целиком. Создание вложенного файлового информационного ресурса. Расширение доступа Данная задача возникает, когда к некоторому каталогу файлового информационного ресурса необходимо предоставить доступ дополнительной группе лиц расширить доступ. При этом выполняются следующие мероприятия: Регистрируется вложенный файловый информационный ресурс согласно процессу А В группы доступа пользователей вложенного файлового информационного ресурса добавляются группы доступа пользователей вышестоящего составного файлового информационного ресурса. Сужение доступа Данная задача возникает, когда к некоторому каталогу файлового информационного ресурса необходимо ограничить доступ и предоставить его только ограниченной группе лиц: Регистрируется вложенный файловый информационный ресурс согласно процессу А В группы доступа пользователей создаваемого информационного ресурса помещаются те учетные записи пользователей, которым требуется предоставить доступ. Организационными или техническими, но не связанными с изменением прав доступа к каталогам файловой системы мерами блокируется доступ пользователей к данному и всем вложенным файловым информационным ресурсам. К корневому каталогу файлового информационного ресурса назначаются новые права доступа, при этом заменяются права доступа для всех дочерних объектов активируется наследие. Перенастраиваются права доступа для всех вложенных информационных ресурсов. Настраиваются промежуточные каталоги для данного и вложенных информационных ресурсов. Этот каталог будет единой точкой входа во все файловые информационные ресурсы, размещенные на данном сервере. Создание файлового информационного ресурса Постановка задачи. Обоим работникам требуется доступ на чтение и запись к данному ресурсу. Дамп NTFS разрешений, полученных командой cacls: OI CI F Каталог D: Добавим в него права на проход Traverse для групп: Предположим, в отдел разработки приняли еще одного работника — специалиста Егорова Михаила Владимировича MB. Расширение доступа Постановка задачи. Предположим, Отдел разработки информационных систем решил улучшить качество взаимодействия с Отделом маркетинга и предоставить руководителю последнего — Кругликовой Наталье Евгеньевне NE. Также создадим две группы доступа пользователей: Добавим учетную запись Кругликовой Натальи Евгеньевны NE. OI CI F Создание вложенного информационного ресурса. Сужение доступа Постановка задачи В целях организации резервного копирования наработок Отдела разработки информационных систем начальнику отдела Иванову Сергею Леонидовичу SL. OI CI F Учетную запись пользователя Иванова Сергея Леонидовича SL. Разработка игр 1,3k авторов , 2,9k публикаций. Разработка мобильных приложений 1k авторов , 2,8k публикаций. JavaScript 1,9k авторов , 4,1k публикаций. Высокая производительность авторов , 1,2k публикаций. Разработка под Android 1k авторов , 2,3k публикаций. Разработка под iOS автора , 1,9k публикаций. HTML авторов , публикации. Разработка под e-commerce автора , публикаций. Машинное обучение авторов , публикация. PHP 1,4k авторов , 2,6k публикаций. Быстрые сетки для верстальщиков 3,4k Добавить в закладки Сутки Неделя Месяц Искусственная глупость: А уж про современные механизмы типа RSBAC я уж молу. Название правильное, поскольку данный документ именно корпоративный стандарт конфигурирования. В нем нет цели покрыть все возможные способы организации общего доступа к файлам, что и отражено в сфере его действия. Для других систем и случаев нужны другие стандарты, Еще раз подчеркну что это один из возможных вариантов. Тот редкий момент, когда на Хабре реально полезная статья Здесь примерно то же самое: Mapped drive при управлением доступом это зло. К сожалению на практике так сделать не получается. В жизни возникают ситуации когда происходит поглощения бизнеса, что неминуемо тянет за собой поглощение инфраструктуры, вот вам и два диска О ссылающиеся на разные места. Второй нюанс это историческое развитие сети. Если вы ее разработали и ведете на протяжении всей жизни это одно, а если вам приходится наводить порядок в уже существующей это совсем другое. Поэтому сценарий с едиными mapped dirve обречен на неудачу. Вы круто всё так категорически написали. Расскажите, пожалуйста, на чём основывается ваша уверенность, что такого подхода достаточно для реализации любого рабочего сценария? Лично я в свою виндовую давность deny вполне пользовался, и индивидуальные права per user выдавал. И оно вовсе не превращалось в ад, потому что это были вполне осознанные исключения, которые конвертировались в правила то есть превращались в группы как только оказывались постоянно востребованными. Потому в тот момент, когда права становятся стационарными — они переходят в группу. Потому в тот момент, когда права становятся стационарными А когда наступает этот момент и кто его определяет? Вы, простите, переломили схему именований групп в домене через колено, чтобы вам было удобнее. Основная схема групп в домене должна отражать реальную организационную структуру предприятия , то есть должны быть отделы, подотделы, должности и т. Тогда, если вам приходит из ОК служебка о том, что взяли Иванова И. Основная схема групп в домене должна отражать реальную организационную структуру предприятия, то есть должны быть отделы, подотделы, должности и т. Вы говорите про ролевые группы , в которые помещаются работники обладающие одинаковыми привилегиями, а стандарте приведены правила наименования групп доступа , на базе которых происходит раздача прав. Замечу, что это не одно и тоже, да и вашем примере это четко видно. Стандарту этому не противоречит. Статья интересная и полезная. Реализовал в сети примерно то же самое. Вижу существенный недостаток — необходимость прописывать КАЖДЫЙ раз права на траверс директорий при изменении доступов в нижних уровнях. Тогда как гораздо удобнее один раз создать группу FILE-путь-TR с правами траверса и включать в нее все необходимое. Возможно, в вашей сети это обусловлено какими-либо дополнительными требованиями, но мне это существенно облегчило жизнь. Что я еще реализовал в своей сети — это группы с запретом доступа. Считайте это паранойей, но у меня все shared-accounts, да и просто пользователи, которым нечего делать на этом ресурсе, внесены в них. И на каждом ресурсе таким группам запрещено любое действие. Если у кого-то из админов AD рука дрогнет. Резюмирую — в своей сети я на каждую папку навешиваю 4 группы доступа за исключением описанных автором редких групп с неспецифическими правами — это FILE Тогда как гораздо удобнее один раз создать группу FILE-путь-TR В разных организациях данная схема была реализована по разному в том числе с траверс группами. В текущей, админам проще прописывать каждый раз новые траверсы, но как говорится каждому свое. По поводу групп согласен -NA, стандарт можно расширить на указанные полномочия. Сразу описывать их не стал, поскольку у тех кто столкнулся с данной задачей впервые будет взрыв мозга. А дерево зачастую настолько велико, что назначение прав может занимать до часа. Боюсь даже представить, насколько вырастет база AD при таком подходе, и как эффективно отслеживать удаление папок и т. Если есть деньги от 1 млн. Здесь не соглашусь, по следующей причине: Группа пользователи домена в общем случае уже чем Everyone и в некоторых случаях данный аспект будет ограничивать доступ, в то время как идеология данного стандарта подразумевает что все доступы режутся только на уровне NTFS. Когда мы используем такой подход есть еще одна не явная плюшка — предоставив доступ к файловому информационному ресурсу через FTP или HTTP IIS с авторизация Windows нам ничего менять не нужно будет. Во первых спасибо автору за изложение своего видения этого процесса. Что хотелось бы отметить и каким опытом поделиться… 1. Никто не отменяет схему AGDLP. И в данном случае если автор говорит что это ресурсные группы, то они должны быть не Global, а Domain Local 2. Привязать имя сетевой папки к имени группы идея очень даже хорошая но не реализуемая в больших средах 3. Есть много вопросов ко вложенным ресурсам — Траверсы нужно рубить на всей вложенности и не всегда это второй уровень а может быть и 5ый и 10ый — В случае если пользователи которые имеют RW доступ к такой вложенной папке вложенного ресурса ну возьмем из примера начальника отдела решит в прекрасный день, что папка Документация должна лежать в другом месте его информационного ресурса, то все прорубленные траверсы до конкретного локейшена не будут иметь смысла, а вот новое местоположение не будет доступно ни по правам потому что не будет траверса ни по полному пути потому что он изменится — В случае если информационный ресурс удаляется, то никак не может ограничиваться удалением папки пользователем, хотя бы потому, что надо еще выполнить ряд процедур удаление из реестра информационных ресурсов, удаление ненужных в ад групп и т. Но в данном случае у пользователей которые имеют права RW могут удалить эту папку потому что они понятия не имеют вложенный это информационный ресурс или обычная папка. В данной схеме имеются указанные вами недостатки. К сожалению пока не вижу простых способов их закрыть. Для себя дублируем структуру папок на уровне OU в AD, например так: Если есть идеи как улучшить стандарт, давайте сделаем это: Можно в личку отписать или обменяться контактами. Мне кажется, важно понимать, что эффективную систему документооборота на таких средствах сделать невозможно. В нашей компании, например, достаточно жестко в том числе и в связи с требованиями ISO ограничена структура контролируемых папок, поэтому достаточно эффективно удается работать с разрешениями на папки. Было бы очень полезно, достаточно много времени уходит на ручную работу с правами на папки. Поэтому и остается в рамках имеющихся механизмов пытаться делать максимально возможное, увы. Думаю что вынесение на коллективное обсуждение этой темы будет более полезным, чем частный обмен опытом. Я давно хотел увидеть какие-то подобные решения, которые были бы определенными стандартами в данной области и на которые можно было бы ссылаться при дизайне файловых хранилищ. А для чего Вам так нужен траверс для дополнительных ресурсов? На мой взгляд когда пользователь все равно не видит этих папок, то ему удовольствия нет прыгать пять уровней непонятно для чего. В своей практике я использую немного другую модель. Я не делаю ресурсы вложенными. Я исхожу того, что должно быть четкое правило определение ресурса. Я определяю, что один ресурс — это один набор ACL. Если есть потребность для какой-то части ресурса изменить ACL, то это сигнал к тому, что информационный ресурс надо разделить на два ресурса. Все ресурсы всегда находятся на одном уровне вложенности то есть всегда размещаются рядом и не надо искать где-то на 10ом уровне вложенности ничего. Соответственно права пользователей не позволяют им не двигать ни удалять ресурсы. Если Вам уж очень захочется склеить в дерево эти ресурсы, то можно потом на базе той модели, что я описал используя DFS что-то придумать в этом направлении. Конечно и эта модель не идеальна и иногда пользователи не понимают необходимости создания отдельных ресурсов, но такова жизнь… И поэтому если бы были стандарты или бестпрактиксы на которые можно было бы ссылаться, было значительно проще. Вообще считаю что NTFS это очень низкоуровневое решение для задач полноценного файлового хранилища управления файловыми ресурсами, их учета и т. В бизнесе моей организации такое — сплошь и рядом. Обычно это, конечно, не 5-й уровень, но второй-третий — запросто. Имеем проектную группу — 1й уровень. В проектной группе — проект — 2й уровень. Внутри проекта — идет деление по папкам — ТЗ, переписка с клиентом, калькуляция и т. Для каждой папки — свои права. В ТЗ имеют дополнительный доступ, например, юристы, в документацию — нормативщик и т. Это не реальный слепок, но общую ситуацию вполне характеризует. Для сквозного прохода от точки доступ. Я не делаю ресурсы вложенными Делали бы так с удовольствием, но требования бизнеса другие, искоренить пробовали — не вариант. В частных случаях это можно делать, но в общем случае это тупиковый путь — пробовали. Плюс очень много негатива от пользователей. NTFS это очень низкоуровневое решение для задач полноценного файлового хранилища управления файловыми ресурсами, их учета и т. Они есть это IDM — но это деньги. Сказать пользователю, что мы не разграничиваем доступ к такой-то папке потому как это запрещено нашим внутренним стандартом — тупиковый путь. Был подобный опыт, но когда на этом настаивает топ-менеджер, то тут 2 варианта остается 1. Искать новую работу 2. Переделывать стандарт думаю это предпочтительней. На самом деле в данном стандарте есть один отрицательный момент — это сложность добавления прав на траверс и возможность их поломки пользователями. Я Вас прекрасно понимаю и все сложности озвученные тоже мне понятны. Один комментарий по поводу топ менеджеров — например бухгалтера и финансисты работают в соответствии регламентов, которые определяют их деятельность и возможно тоже кто-то хотел бы видеть их работу другой. Но их работа основывается на требованиях законов, документов и т. Пока в ИТ не будет таких же стандартов — на технические решения будет влиять любой менеджер причем под разных менеджеров можно даже разные решения внедрять по их пожеланию ;-. Поэтому я изначально и говорил, что если бы были правила на которые можно было бы ссылаться — было бы проще. Если вы готовы идти только по своему пути развития своего файлового хранилища и четко понимаете свои проблемы, то я думаю надо тогда и думать: Как автоматизировать задачу прописывания траверсов 2. Как забрать права у пользователей на удаление и перемещения папок вложенных ресурсов и промежуточных папок. Друзья, спасибо вам за ваши комментарии. Вы помогли взглянуть на то с чем я уже давно работал свежим взглядом. Готовлю UPDATE 1 для данной статьи стандарта , который учтет выявленные недостатки, а также готовлю выделенную статью касательно организационных вопросов регламентов управления доступом к файловым информационным ресурсам. Есть один важный нюанс. В update к данному стандарту и будущем регламенте будет применена вариативная схема построения, то есть будут документы будут содержать варианты решения той или иной задачи, а какой вариант выбрать будет уже за вами. В общем случае архитектура документов по данной тематике следующая: Стандарт управления доступом к файловым информационным ресурсам. Сугубо технический документ описывающий технические аспекты предоставления доступов 2. Документ описывающий взаимодействие структурны подразделений компании в части предоставления доступов, в также особенности данного взаимодействия. На уровне регламента и следует политические вопросы, например делать ли вообще вложенные ресурсы или ограничиться сугубо плоской моделью,. Также хотел пояснить почему данный документ называется стандарт. Во многих методиках по обеспечению ИБ, например в PCI DSS, указано требование что компания обязана выпустить задокументировать стандарты использования тех или иных технологий в данном случае — управления доступом к папкам. Так вот цель данного документа — сделать как раз такой стандарт, который вы можете скопипастить к себе в норматику. Не сочтите за труд, ответьте на этот коммент, когда опубликуете. Или просто в личку напишите. Спасибо за статью, очень много всего совпало с теми стандартами, которые применяются в нашей компании. Правда, в нашей ситуации, траверс папок мы обошли банальным созданием ярлыков, которые ведут на промежуточные каталоги другого подразделения. Каталог с ярлыками защищен от изменений и в нем отражены все возможные директории, которые доступны всем сотрудникам их собственного подразделения. Также, не особо в тему, но об этом мало где пишут, Windows 7 x64 имеют проблемы с траверс доступом в каталоги, если использовать для входа точный путь до каталога и копировать его в адресную строку. Лечится это апдейтом KB Метки лучше разделять запятой. Сейчас Вчера Неделя Возможен ли асинхронный процессор 10,6k Увольнение — это маленькая смерть. Как сохранить ценного специалиста решившего уволиться? Интересные публикации Хабрахабр Geektimes. Биомеханика и искусственный интеллект в медицине. Лекция на YaC Пиратство и четыре валюты: Pay What You Want и Free-to-Play. Как иприт начал лечить рак более-менее GT. SpaceX запустит Falcon Heavy уже в ноябре GT. Doctrine Specification Pattern или ваш реюзабельный QueryBuilder. Взлом казино через умный аквариум и DDoS биржевых брокеров: Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары. Наследование прав доступа от вышестоящих каталогов включено , но если данный каталог является вышестоящим по отношению к файловым информационным ресурсам и не входит ни в один другой файловый информационный ресурс, то наследование отключено. Группы доступа пользователей информационных ресурсов, для которых этот каталог является промежуточным.
Управление доступом к информационным ресурсам. Аутентификация
Эксель сводная таблица формулы
Политика обеспечения информационной безопасности
Повяли верхушки помидор что делать
Сколько магазинов в санкт петербурге
Пользование информационными ресурсами
Микробиологическое исследование мочи