Стандарт управления правами доступа к корпоративным файловым информационным ресурсам


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

    Сфера действия


    Стандарт управления правами доступа к корпоративным файловым информационным ресурсам (далее – Стандарт) регламентирует процессы предоставления доступа к файловым информационным ресурсам, размещенным на компьютерах, работающих под управлением операционных систем семейства Microsoft Windows. Стандарт распространяется на случаи, когда в качестве файловой системы используется NTFS, а в качестве сетевого протокола для совместного доступа к файлам SMB/CIFS.

    Термины и определения


    Информационный ресурс – поименованная совокупность данных, к которой применяются методы и средства обеспечения информационной безопасности (например, разграничение доступа).
    Файловый информационный ресурс – совокупность файлов и папок, хранящихся в каталоге файловой системы (который называется корневым каталогом файлового информационного ресурса), доступ к которой разграничивается.
    Составной файловый информационный ресурс – это файловый информационный ресурс, содержащий в себе один или несколько вложенных файловых информационных ресурсов, отличающихся от данного ресурса правами доступа.
    Вложенный файловый информационный ресурс – это файловый информационный ресурс, входящий в составной информационный ресурс.
    Точка входа в файловый информационный ресурс – каталог файловой системы, к которому предоставляется сетевой доступ (shared folder) и который используется для обеспечения доступа к файловому информационному ресурсу. Данный каталог обычно совпадает с корневым каталогом файлового информационного ресурса, но может быть и вышестоящим.
    Промежуточный каталог – каталог файловой системы, находящийся на пути от точки входа в файловый информационной ресурс к корневому каталогу файлового информационного ресурса. Если точка входа в файловый информационный ресурс является вышестоящим каталогом по отношению к корневому каталогу файлового информационного ресурса, то она также будет являться промежуточным каталогом.
    Группа доступа пользователей – локальная или доменная группа безопасности, содержащая в конечном счете учетные записи пользователей, наделенные одним из вариантов полномочий доступа к файловому информационному ресурсу.

    Основные принципы


    1. Доступ разграничивается только на уровне каталогов. Ограничение доступа к отдельным файлам не проводится.
    2. Назначение прав доступа выполняется на базе групп безопасности. Назначение прав доступа на отдельные учетные записи пользователей не проводится.
    3. Явно запрещающие полномочия доступа (deny permissions) не применяются.
    4. Разграничение прав доступа проводится только на уровне файловой системы. На уровне сетевых протоколов SMB/CIFS права не разграничиваются (Группа «Все» – полномочия «Чтение/Запись» / Everyone – Change).
    5. При настройке сетевого доступа к файловому информационному ресурсу в настройках SMB/CIFS устанавливается опция «Перечисление на основе доступа (Access based enumeration)».
    6. Создание файловых информационных ресурсов на рабочих станциях пользователей недопустимо.
    7. Не рекомендуется размещать файловые информационные ресурсы на системных разделах серверов.
    8. Не рекомендуется создавать несколько точек входа в файловый информационный ресурс.
    9. Следует по возможности избегать создание вложенных файловых информационных ресурсов, а в случаях, когда имена файлов или каталогов содержат конфиденциальную информацию, это вовсе недопустимо


    Модель разграничения доступа


    Доступ пользователей к файловому информационному ресурсу предоставляется путем наделения их одним из вариантов полномочий:

    • Доступ «Только на чтение (Read Only)».
    • Доступ «Чтение и запись (Read & Write)».

    В подавляющем количестве задач разграничения доступа подобных вариантов полномочий доступа будет достаточно, но при необходимости возможно формирование новых вариантов полномочий, например, «Чтение и запись, кроме удаления (Read & Write without Remove)». Для реализаций новый полномочий необходимо будет уточнить пункт В.3 Таблицы 1, в остальном применение Стандарта останется неизменным.

    Правила именования групп доступа пользователей


    Имена групп доступа пользователей формируются по шаблону:

    FILE-Имя файлового информационного ресурса–аббревиатура полномочий

    Имя файлового информационного ресурса
    должно совпадать с UNC именем ресурса или состоять из имени сервера и локального пути (если сетевой доступ к ресурсу не предоставляется). При необходимости в данном поле допускаются сокращения. Символы «\\» опускаются, а «\» и «:» заменяются на «-».

    Аббревиатуры полномочий:

    • RO — для варианта доступа «Только на чтение (Read Only)»
    • RW — для варианта доступа «Чтение и запись (Read & Write)».

    Пример 1
    Имя группы доступа пользователей, имеющих полномочия «Только чтение» для файлового информационного ресурса с UNC именем \\FILESRV\Report, будет:
    FILE-FILESRV-Report-RO

    Пример 2
    Имя группы доступа пользователей, имеющих полномочия «Чтение и запись» для файлового информационного ресурса, размещенного на сервере TERMSRV по пути D:\UsersData, будет:
    FILE-TERMSRV-D-UsersData-RW

    Шаблон прав доступа к каталогам файлового информационного ресурса



    Таблица 1 – Шаблон NTFS-прав доступа для корневого каталога файлового информационного ресурса.
    Субъекты Права Режим наследования
    Наследование прав доступа от вышестоящих каталогов отключено
    А) Обязательные права
    Специальная учетная запись:
    «СИСТЕМА (SYSTEM)»
    Полный доступ (Full access)
    Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
    Локальная группа безопасности:
    «Администраторы (Administrators)»
    Полный доступ (Full access)
    Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
    Б.1) Полномочия «Только чтение (Read Only)»
    Группа доступа пользователей:
    «FILE-Имя ресурса-RO»
    Базовые права:
    а) чтение и выполнение (read & execute);
    б) список содержимого папки (list folder contents);
    в) чтение (read);
    Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
    Б.2) Полномочия «Чтение и запись (Read & Write)»
    Группа доступа пользователей:
    «FILE-Имя ресурса-RW»
    Базовые права:
    а) изменение (modify);
    б) чтение и выполнение (read & execute);
    в) список содержимого папки (list folder contents);
    г) чтение (read);
    д) запись (write);
    Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
    Б.3) Другие полномочия при их наличии
    Группа доступа пользователей:
    «FILE-Имя ресурса-аббревиатура полномочий»
    Согласно полномочиям
    Для этой папки, ее подпапок и файлов (This folder, subfolders and files)

    Табилца 2 – Шаблон NTFS-прав доступа для промежуточных каталогов файлового информационного ресурса.
    Субъекты
    Права
    Режим наследования
    Наследование прав доступа от вышестоящих каталогов включено, но если данный каталог является вышестоящим по отношению к файловым информационным ресурсам и не входит ни в один другой файловый информационный ресурс, то наследование отключено
    А) Обязательные права
    Специальная учетная запись:
    «СИСТЕМА (SYSTEM)»
    Полный доступ (Full access)
    Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
    Локальная группа безопасности:
    «Администраторы»
    Полный доступ (Full access)
    Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
    Б.1) Полномочия «Проход через каталог (TRAVERSE
    Группы доступа пользователей информационных ресурсов, для которых этот каталог является промежуточным
    Дополнительные параметры безопасности:
    а) траверс папок / выполнение файлов (travers folder / execute files);
    б) содержимое папки / чтение данных (list folder / read data);
    в) чтение атрибутов (read attributes);
    в) чтение дополнительных атрибутов (read extended attributes);
    г) чтение разрешений (read permissions);
    Только для этой папки (This folder only)

    Бизнес процессы управления доступом к файловым информационным ресурсам


    А. Создание файлового информационного ресурса
    При создании файлового информационного ресурса выполняются следующие действия:
    1. Создаются группы доступа пользователей. Если сервер, на котором размещен файловый информационный ресурс, является членом домена, то создаются доменные группы. Если нет, то группы создаются локально на сервере.
    2. На корневой каталог и промежуточные каталоги файлового информационного ресурса назначаются права доступа согласно шаблонам прав доступа.
    3. В группы доступа пользователей добавляются учетные записи пользователей в соответствии с их полномочиями.
    4. При необходимости для файлового информационного ресурса создается сетевая папка (shared folder).

    Б. Предоставление пользователю доступа к файловому информационному ресурсу
    Учетная запись пользователя помещается в соответствующую группу доступа пользователя в зависимости от его полномочий.

    В. Изменение доступа пользователя к файловому информационному ресурсу
    Учетная запись пользователя перемещается в другую группу доступа пользователей в зависимости от указанных полномочий.

    Г. Блокирование доступа пользователя к файловому информационному ресурсу
    Учетная запись пользователя удаляется из групп доступа пользователей файлового информационного ресурса. Если работник увольняется, то членство в группах не меняется, а блокируется учетная запись целиком.

    Д1. Создание вложенного файлового информационного ресурса. Расширение доступа
    Данная задача возникает, когда к некоторому каталогу файлового информационного ресурса необходимо предоставить доступ дополнительной группе лиц (расширить доступ). При этом выполняются следующие мероприятия:
    1. Регистрируется вложенный файловый информационный ресурс (согласно процессу А)
    2. В группы доступа пользователей вложенного файлового информационного ресурса добавляются группы доступа пользователей вышестоящего составного файлового информационного ресурса.

    Д2. Создание вложенного файлового информационного ресурса. Сужение доступа
    Данная задача возникает, когда к некоторому каталогу файлового информационного ресурса необходимо ограничить доступ и предоставить его только ограниченной группе лиц:
    1. Регистрируется вложенный файловый информационный ресурс (согласно процессу А)
    2. В группы доступа пользователей создаваемого информационного ресурса помещаются те учетные записи пользователей, которым требуется предоставить доступ.

    Е. Изменение модели предоставления доступа к файловому информационному ресурсу
    В случаях, когда к стандартным вариантам полномочий «Только чтение (Read only)» или «Чтение и запись (Read & Write)» необходимо добавить новые типы полномочий, например, «Чтение и запись, кроме удаления (Read & Write without Remove)» выполняют следующие действия:
    1. Организационными (или техническими, но не связанными с изменением прав доступа к каталогам файловой системы) мерами блокируется доступ пользователей к данному и всем вложенным файловым информационным ресурсам.
    2. К корневому каталогу файлового информационного ресурса назначаются новые права доступа, при этом заменяются права доступа для всех дочерних объектов (активируется наследие).
    3. Перенастраиваются права доступа для всех вложенных информационных ресурсов.
    4. Настраиваются промежуточные каталоги для данного и вложенных информационных ресурсов.

    Примеры


    Рассмотрим применение данного стандарта на примере гипотетической организации ООО «ИнфоКриптоСервис», где для централизованного хранения файловых информационных ресурсов выделен сервер с именем «FILESRV». Сервер работает под управлением операционной системы Microsoft Windows Server 2008 R2 и является членом домена Active Directory с FQDN именем «domain.ics» и NetBIOS именем «ICS».

    Подготовка файлового сервера
    На диске «D:» сервера «FILESRV» создаем каталог «D:\SHARE\». Этот каталог будет единой точкой входа во все файловые информационные ресурсы, размещенные на данном сервере. Организуем сетевой доступ к данной папке (используем апплет «Share and Storage Management»):

    Создание файлового информационного ресурса
    Постановка задачи.
    Пусть в составе организации ООО «ИнфоКриптоСервис» имеется Отдел разработки информационных систем в составе: начальника отдела Иванова Сергея Леонидовича (SL.Ivanov@domain.ics), специалиста Маркина Льва Борисовича (LB.Markin@domain.ics), и для них нужно организовать файловый информационный ресурс для хранения данных подразделения. Обоим работникам требуется доступ на чтение и запись к данному ресурсу.

    Решение.
    В каталоге «D:\SHARE\» сервера «FILESRV» создадим папку «D:\SHARE\Отдел разработки информационных систем\», которая будет корневым каталогом для файлового информационного ресурса. Также создадим группы доступа пользователей (глобальные группы безопасности домена «ICS») для данного ресурса:
    • «FILE-FILESRV-SHARE-Отд. разр. ИС-RO»
    • «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

    Настроим права доступа для каталога «D:\SHARE\Отдел разработки информационных систем\»:

    Дамп NTFS разрешений, полученных командой cacls:
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:(OI)(CI)R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:(OI)(CI)C
    NT AUTHORITY\SYSTEM:(OI)(CI)F
    BUILTIN\Administrators:(OI)(CI)F

    Каталог D:\SHARE\ является точкой входа и промежуточным каталогом для данного ресурса. Добавим в него права на проход (Traverse) для групп: «FILE-FILESRV-SHARE-Отд. разр. ИС-RO» и «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

    Дамп NTFS разрешений, полученных командой cacls:
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:R
    NT AUTHORITY\SYSTEM:(OI)(CI)F
    BUILTIN\Administrators:(OI)(CI)F

    Поскольку пользователям требуется доступ на чтение и запись, добавим их учетные запаси в группу «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

    Предоставление доступа пользователю к файловому информационному ресурсу
    Постановка задачи.
    Предположим, в отдел разработки приняли еще одного работника – специалиста Егорова Михаила Владимировича (MB.Egorov@domain.ics), и ему, как и остальным работникам отдела, требуется доступ на чтение и запись к файловому информационному ресурсу отдела.

    Решение.
    Учетную запись работника необходимо добавить в группу «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

    Создание вложенного информационного ресурса. Расширение доступа
    Постановка задачи.
    Предположим, Отдел разработки информационных систем решил улучшить качество взаимодействия с Отделом маркетинга и предоставить руководителю последнего — Кругликовой Наталье Евгеньевне (NE.Kruglikova@domain.ics) — доступ на чтение к актуальной документации на продукты, хранящейся в папке «Документация» файлового информационного ресурса Отдела разработки информационных систем.

    Решение.
    Для решения данной задачи необходимо сделать вложенный ресурс «\\FILESRV\share\Отдел разработки информационных систем\Документация», доступ к которому на чтение и запись должен быть (остаться) у всех пользователей, имевших доступ к «\\FILESRV\share\Отдел разработки информационных систем\ и добавиться доступ на чтение для пользователя Кругликовой Натальи Евгеньевне (NE.Kruglikova@domain.ics)

    В каталоге «D:\SHARE\Отдел разработки информационных систем\» создадим папку «D:\SHARE\Отдел разработки информационных систем\Документация», которая будет корневым каталогом для нового ресурса. Также создадим две группы доступа пользователей:
    • «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO»
    • «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW»

    Настроим права доступа на папку «D:\SHARE\Отдел разработки информационных систем\Документация» следующим образом:

    Дамп NTFS разрешений, полученных командой cacls:
    NT AUTHORITY\SYSTEM:(OI)(CI)F
    BUILTIN\Administrators:(OI)(CI)F
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:(OI)(CI)R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:(OI)(CI)C

    Поскольку всем пользователям, имеющим доступ в «\\FILESRV\share\Отдел разработки информационных систем\», необходим аналогичный доступ в \\FILESRV\share\Отдел разработки информационных систем\Документация», то добавим группу «FILE-FILESRV-SHARE-Отд. разр. ИС-RO» в «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO» и «FILE-FILESRV-SHARE-Отд. разр. ИС-RW» в «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW» соответственно. Добавим учетную запись Кругликовой Натальи Евгеньевны (NE.Kruglikova@domain.ics) в группу «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW»

    Теперь, если Кругликова Наталья Евгеньевна (NE.Kruglikova@domain.ics) обратится по ссылке «\\FILESRV\share\Отдел разработки информационных систем\Документация», то она сможет попасть в интересующую ее папку, но обращаться по полному пути не всегда удобно, поэтому настроим сквозной проход к данной паке от точки входа «\\FILESRV\share\» («D:\SHARE\»). Для этого настроим права доступа на промежуточные каталоги «D:\SHARE\» и «D:\SHARE\Отдел разработки информационных систем\».

    Проведем настройку «D:\SHARE\»:

    Дамп NTFS разрешений, полученных командой cacls:
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R
    NT AUTHORITY\SYSTEM:(OI)(CI)F
    BUILTIN\Administrators:(OI)(CI)F

    и «D:\SHARE\Отдел разработки информационных систем»:

    Дамп NTFS разрешений, полученных командой cacls:
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:(OI)(CI)R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:(OI)(CI)C
    NT AUTHORITY\SYSTEM:(OI)(CI)F
    BUILTIN\Administrators:(OI)(CI)F

    Создание вложенного информационного ресурса. Сужение доступа
    Постановка задачи
    В целях организации резервного копирования наработок Отдела разработки информационных систем начальнику отдела Иванову Сергею Леонидовичу (SL.Ivanov@domain.ics), в рамках файлового информационного ресурса отдела, понадобилась сетевая папка «Архив», доступ к которой был бы только у него.

    Решение.
    Для решения данной задачи в файловом информационном ресурсе отдела требуется сделать вложенный ресурс «Архив» («\\FILESRV\share\Отдел разработки информационных систем\Архив»), доступ к которому предоставить только начальнику отдела.

    В каталоге «D:\SHARE\Отдел разработки информационных систем\» создадим папку «D:\SHARE\Отдел разработки информационных систем\Архив», которая будет корневым каталогом для нового ресурса. Также создадим две группы доступа пользователей:
    • «FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RO»
    • «FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RW»

    Проведем настройки прав доступа на каталоги «D:\SHARE\Отдел разработки информационных систем\Архив»:

    Дамп NTFS разрешений, полученных командой cacls:
    NT AUTHORITY\SYSTEM:(OI)(CI)F
    BUILTIN\Administrators:(OI)(CI)F
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RO:(OI)(CI)R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RW:(OI)(CI)C

    «D:\SHARE\Отдел разработки информационных систем»

    Дамп NTFS разрешений, полученных командой cacls:
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RO:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RW:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:(OI)(CI)R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:(OI)(CI)C
    NT AUTHORITY\SYSTEM:(OI)(CI)F
    BUILTIN\Administrators:(OI)(CI)F

    и «D:\SHARE\»:

    Дамп NTFS разрешений, полученных командой cacls:
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RO:R
    ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Архив-RW:R
    NT AUTHORITY\SYSTEM:(OI)(CI)F
    BUILTIN\Administrators:(OI)(CI)F

    Учетную запись пользователя Иванова Сергея Леонидовича (SL.Ivanov@domain.ics) добавим в группу FILE-FILESRV-Отд. раз.ИС-Архив-RW.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +2
      У вас не правильное название, должно называться «Рекомендации по организации и распределение прав доступов к файловым ресурсам на базе решений micorsoft, для малых предприятий»
      Заметено отсутствие опыта работы с не видовозными файловыми системами и средами.
      А как же Appned only & Read?
      Execute only?
      А уж про современные механизмы типа RSBAC я уж молу.
        0
        Название правильное, поскольку данный документ именно корпоративный стандарт конфигурирования.
        В нем нет цели покрыть все возможные способы организации общего доступа к файлам, что и отражено в сфере его действия.
        Для других систем и случаев нужны другие стандарты, Еще раз подчеркну что это один из возможных вариантов.
        0
        Круто! Тот редкий момент, когда на Хабре реально полезная статья)
        Здесь примерно то же самое: http://windowsitpro.com/security/12-commandments-file-sharing

        Единственный нюанс — есть ли смысл распространять ресурсы через ярлыки на рабочем столе, а не mapped drives — ведь свежие шифровальщики вроде Locky вполне самостоятельно сканируют подсети на предмет прав RW.
          0
          Mapped drive при управлением доступом это зло.
          Пример. К вам приходит заявка «Дайте доступ на папку отчет на диске О», у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий. Куда давать доступ? :)
            0
            «у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий»

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

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

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


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

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


            Вы все правильно говорите, но когда увольняется человек который раздавал права подобным образом, или когда к процессу выдачи прав нужно подключить нового админа, разобраться почему «Иван Федорович» не может прочитать тот или иной файл когда у него доступ «вроде как есть» бывает очень сложно.

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

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

                  А когда наступает этот момент и кто его определяет? Вы уверены что все ваши «стационарные» права переведены на группы?

                  Безусловно, у каждого подхода «per user» или «per group» есть свои плюсы и минусы. Исходя из собственного опыте лучше иметь список из сотен групп, нежели проводить аудит сотен «шар», в которых предоставлены права.
                    0
                    В тот момент, когда звучит «как у Петрова» или «Петрову нужно не только к Сидорову но и Иванову, потому что он тоже в отпуске».
              0
              Вы, простите, переломили схему именований групп в домене через колено, чтобы вам было удобнее. Основная схема групп в домене должна отражать реальную организационную структуру предприятия , то есть должны быть отделы, подотделы, должности и т.п. Тогда, если вам приходит из ОК служебка о том, что взяли Иванова И.И. на должность главного бухгалтера, вы просто заводите учетку и включаете ее в группу «Главные бухгалтеры», мало того, это же может сделать и специалист по кадрам без вашего участия, и даже система управления учетными записями (IDM).

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

                Вы говорите про ролевые группы, в которые помещаются работники обладающие одинаковыми привилегиями, а стандарте приведены правила наименования групп доступа, на базе которых происходит раздача прав. Замечу, что это не одно и тоже, да и вашем примере это четко видно.

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

                  Вижу существенный недостаток — необходимость прописывать КАЖДЫЙ раз права на траверс директорий при изменении доступов в нижних уровнях.
                  Тогда как гораздо удобнее один раз создать группу FILE-путь-TR с правами траверса и включать в нее все необходимое. Возможно, в вашей сети это обусловлено какими-либо дополнительными требованиями, но мне это существенно облегчило жизнь.

                  Что я еще реализовал в своей сети — это группы с запретом доступа. Считайте это паранойей, но у меня все shared-accounts, да и просто пользователи, которым нечего делать на этом ресурсе, внесены в них. И на каждом ресурсе таким группам запрещено любое действие. На всякий случай. Если у кого-то из админов AD рука дрогнет.

                  Резюмирую — в своей сети я на каждую папку навешиваю 4 группы доступа (за исключением описанных автором редких групп с неспецифическими правами) — это FILE-...-RO, FILE-...-RW, FILE-...-NA, FILE-...-TR в терминологии статьи. Не уверен, что это идеальный способ, но позволяет решить 99% возникающих у меня задач с разграничением доступа.
                    0
                    Тогда как гораздо удобнее один раз создать группу FILE-путь-TR

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

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

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

                        Если есть деньги (от 1 млн. р., из тех цен что нам предлагали) то это хороший выбор, если нет, то живем с тем что есть.
                    +1
                    Цитата: «Разграничение прав доступа проводится только на уровне файловой системы. На уровне сетевых протоколов SMB/CIFS права не разграничиваются (Группа «Все» – полномочия «Полный доступ» / Everyone – Full access).»
                    И после этого любой пользователь может отключить общий доступ к папке. Рекомендую ограничиться чтением/записью.
                    ps Прошу прощения, не разобрался как сделать цитатой.
                      0
                      Спасибо! Важный нюанс. Внес коррективы в статью.
                        0
                        Еще по группе «эвриван» на сетевую папку. Лучше (даже МС с этим соглашается) заменить ее на группу «пользователи домена».
                          0
                          Здесь не соглашусь, по следующей причине:
                          Группа пользователи домена в общем случае уже чем Everyone и в некоторых случаях данный аспект будет ограничивать доступ, в то время как идеология данного стандарта подразумевает что все доступы режутся только на уровне NTFS.
                          Когда мы используем такой подход есть еще одна не явная плюшка — предоставив доступ к файловому информационному ресурсу через FTP или HTTP (IIS с авторизация Windows) нам ничего менять не нужно будет.
                      +1
                      Во первых спасибо автору за изложение своего видения этого процесса.
                      Что хотелось бы отметить и каким опытом поделиться…
                      1. Никто не отменяет схему AGDLP. И в данном случае если автор говорит что это ресурсные группы, то они должны быть не Global, а Domain Local
                      2. Привязать имя сетевой папки к имени группы идея очень даже хорошая но не реализуемая в больших средах
                      3. Есть много вопросов ко вложенным ресурсам
                      — Траверсы нужно рубить на всей вложенности (и не всегда это второй уровень а может быть и 5ый и 10ый)
                      — В случае если пользователи которые имеют RW доступ к такой вложенной папке вложенного ресурса (ну возьмем из примера начальника отдела) решит в прекрасный день, что папка Документация должна лежать в другом месте его информационного ресурса, то все прорубленные траверсы до конкретного локейшена не будут иметь смысла, а вот новое местоположение не будет доступно ни по правам (потому что не будет траверса) ни по полному пути (потому что он изменится)
                      — В случае если информационный ресурс удаляется, то никак не может ограничиваться удалением папки пользователем, хотя бы потому, что надо еще выполнить ряд процедур (удаление из реестра информационных ресурсов, удаление ненужных в ад групп и т.д.). Но в данном случае у пользователей которые имеют права RW могут удалить эту папку потому что они понятия не имеют вложенный это информационный ресурс или обычная папка
                        0
                        В целом согласен.
                        В данной схеме имеются указанные вами недостатки. К сожалению пока не вижу простых способов их закрыть.

                        Для себя дублируем структуру папок на уровне OU в AD, например так:
                        Informations reourses:
                        — FILE
                        — FILESRV
                        — Имя точки входа
                        — вложенные ресурсы
                        Но это тоже костели.

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

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

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

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

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

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

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

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

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

                          Они есть это IDM — но это деньги.

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

                          На самом деле в данном стандарте есть один отрицательный момент — это сложность добавления прав на траверс и возможность их поломки пользователями.

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

                              В очередной раз переделывали свою систему управления правами и придумалось ( и сделалось) такое решение:

                              — на *nix системе генерится дерево неизменяемых каталогов для каждого пользователя на основании списка доступных ему проектов. В нашем случае это легко — уровни вложенности с 1 по N в нашей архитектуре статичны и изменяются только через админку;
                              — на N+1 уровне вложенности линкуются папки проектов из существующего Windows-файлового хранилища;
                              — на том же *nix сервере создается параметризованная по имени пользователя smb-шара, которая ведет его к персональному дереву каталогов.

                              Что достигаем таким образом:
                              1. Доступ пользователя к файлам теперь не зависит от AD групп, а только от групп в «админке». Таким образом, изменения доступа можно отрабатывать мгновенно;
                              2. Нет необходимости применять группы доступа к результирующим папкам в хранилище;
                              3. Сохраняются пути к файлам «как раньше», т.е. нет необходимости править ярлыки пользователям, переход на новую систему проходит абсолютно прозрачно, можно обмениваться путями к файлам в почте — если доступ к каталогу есть, то путь одинаков для всех пользователей, что UNC, что через примапленый диск;
                              4. В силу того, что софт построения дерева каталогов рисует только те папки, куда у пользователя есть доступ, то ликвидирован косвенный источник утечки — раньше, если даже не было доступа, пользователь видел имя папки (а она как правило называлась по имени клиента или пордукта)
                              5. Не ломая старую структуру хранения данных на Windows, получаем все преимущества мониторинга от *nix

                              Есть, конечно, и минусы, но в нашем случае, плюсы их существенно перевесили.
                                0
                                Доступ пользователя к файлам теперь не зависит от AD групп

                                Вот это как раз и не здорово. Когда нет iDM-систем очень сложно понять какие права есть у пользователя, поэтому хотелось все завязать именно на AD, чтобы зашел и сразу было понятно что есть чего нет.

                                Дополнительное звено в виде «админки» на *nix это возможно здорово для вас. Проблемы начнутся тогда, когда будут появляться новые люди. Въехать в данную систему для них боюсь будет не тривиальной задачей. К тому же возникают вопросы с масштабированием такой системы доступа.

                                Но повторюсь, в вашей корпоративной культуре это может быть вполне работающие и удобное решение.
                                  0

                                  С AD две проблемы:
                                  1 — обновление вектора пользователя, при добавлении/исключении в группы
                                  2 — ограничение на членство в группах в 1020 штук. Мы реально в это упёрлись


                                  Согласен, что система нетривиальная. Пока всё достаточно прозрачно, но, конечно, может и разрастись в неподъемного монстра. Именно поэтому мы решили, что добавление функционала проводиться не будет, только багфикс. Можно, конечно, перепилить ее с внутренней базы на кастомные поля в AD, но кмк это только всё усложнит. Если все понимают риски на входе и готовы их нести — почему нет? Ну и, конечно, везде своя специфика.

                                    0
                                    1 — обновление вектора пользователя, при добавлении/исключении в группы

                                    Что значит вектор пользователя?
                                    2 — ограничение на членство в группах в 1020 штук. Мы реально в это упёрлись

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

                                    Так что удобного красивого решения нет, к сожалению.
                                      0
                                      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
                                      The issue occurs when the logon user is an explicit or transitive member of about 1,010 or more security groups.

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

                              Готовлю UPDATE 1 для данной статьи (стандарта), который учтет выявленные недостатки, а также готовлю выделенную статью касательно организационных вопросов (регламентов) управления доступом к файловым информационным ресурсам.

                              Есть один важный нюанс. В update к данному стандарту и будущем регламенте будет применена вариативная схема построения, то есть будут документы будут содержать варианты решения той или иной задачи, а какой вариант выбрать будет уже за вами.

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

                              Также хотел пояснить почему данный документ называется стандарт. Во многих методиках по обеспечению ИБ, например в PCI DSS, указано требование что компания обязана выпустить (задокументировать) стандарты использования тех или иных технологий (в данном случае — управления доступом к папкам). Так вот цель данного документа — сделать как раз такой стандарт, который вы можете скопипастить к себе в норматику.
                                0
                                Не сочтите за труд, ответьте на этот коммент, когда опубликуете. Или просто в личку напишите.
                                Заранее спасибо.
                                0
                                Спасибо за статью, очень много всего совпало с теми стандартами, которые применяются в нашей компании.

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

                                Также, не особо в тему, но об этом мало где пишут, Windows 7 x64 имеют проблемы с траверс доступом в каталоги, если использовать для входа точный путь до каталога и копировать его в адресную строку. Лечится это апдейтом KB2821343.

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

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