С механизмом разграничения прав доступа на базе списка управления доступом, или Discretionary access control list (DACL), на практике знакомы 99,9% специалистов по технологиям Microsoft, а вот с аналогичной динамической функцией Dynamic Access Control (DAC) — лишь единицы.

Корпорация Microsoft старается активно продвигать DAC, в том числе посвящая этой технологии значительную часть материалов в рамках программы сертификации специалистов Microsoft Certified Solutions Associate. Ранее механизм DAC был описан в статье «Изменения в функциях безопасности Active Directory в Windows Server 2012» (опубликованной в Windows IT Pro/RE № 4 за 2013 год). На этот раз мы хотели бы сравнить использование DAC и DACL на практике.

Первый раунд

Зачастую простота развертывания и администрирования берет верх над используемым набором функций. Как показывает практика, при реализации большинства сложных решений используются настройки по умолчанию. Для высокодинамичной с точки зрения изменений области управления доступом это особенно актуально. Рассмотрим пример DACL и DAC. Входными данными для сравнения послужат:

  • доменная архитектура;
  • пользовательские рабочие места под управлением операционной системы Windows 8.1;
  • файловый сервер под управлением Windows Server 2012 R2 c набором файловых каталогов.

Настройка списка DACL, в отличие от DAC, не требует никаких предварительных действий по активации функции на сервере и включает в себя следующие операции:

  • создание группы в Active Directory (если необходимо) и назначение ей заданных прав доступа на уровне файловой системы NTFS к соответствующему каталогу, файлу или папке (то есть объекту);
  • добавление учетной записи пользователя (то есть субъекта), которой необходимо предоставить доступ к данному объекту, в созданную группу.

Таким образом, доступ субъекта к объекту регулируется только на основании членства в группе, следовательно, отсутствует возможность реализовать более гибкие сценарии доступа.

Настройка DAC предварительно требует:

  • установить службу диспетчера ресурсов файлового сервера File Server Resource Manager;
  • создать типы утверждений Claim Type;
  • создать и настроить списки свойств ресурсов Resource Property;
  • создать центральные правила доступа Central Access Rules;
  • создать центральные политики доступа Central Access Policies;
  • распространить центральные политики доступа на файловые серверы с помощью групповых политик.

Далее необходимо настроить значения свойств ресурсов (вручную или автоматически классифицировать файлы), а затем настроить учетные записи пользователей. Пример настроек разрешений DAC показан на экране 1.

 

Пример настройки разрешений DAC
Экран 1. Пример настройки разрешений DAC

На первый взгляд кажется, что это слишком трудоемко, а теперь предположим, что возникла необходимость создания новых файловых каталогов. Для DAC задача с новым файловым каталогом решается автоматически, так как у него нет привязки к конкретному файловому каталогу. DACL потребует проверки необходимости наследования прав от родительского каталога, и если это неприменимо (то есть каталог независимый), то нужно повторить все действия по «развертыванию» DACL. А теперь представьте, что у нас таких каталогов 10, 100 или 1000.

Как уже отмечалось, управление доступом — это не разовая задача, а непрерывный процесс, так что посмотрим, что могут предложить наши претенденты. Пересмотр прав доступа в случае использования DAC осуществляется централизованно, путем изменения правил и политик доступа, а список DACL потребует работы вручную с каждым каталогом и отдельного внимания к особым разрешениям, которые далеко не всегда «прозрачны» даже для опытных специалистов по технологиям Microsoft. Дополнительная информация приведена в статье «Ограничения доступа для каждого набора особых разрешений NTFS» по адресу: https://technet.microsoft.com/ru-ru/library/cc732880.aspx.

Например, после того как установлены разрешения на доступ к родительской папке, создаваемые в ней новые файлы и подпапки будут наследовать эти разрешения. Если вложенным папкам требуются другие разрешения, необходимо запретить наследование и скорректировать текущие разрешения, как показано на экранах 2 и 3.

 

Запрет наследования разрешений
Экран 2. Запрет наследования разрешений

 

Корректировка текущих разрешений
Экран 3. Корректировка текущих разрешений

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

При создании правил доступа DAC используются встроенные атрибуты учетных записей пользователей (например, «Офис», «Город», «Должность» и т. п.), что позволяет избежать создания и администрирования избыточного количества групп пользователей, которые фактически дублируют информацию из пользовательских учетных записей.

Однако не следует забывать о том, что пользователь может самостоятельно изменять некоторые характеристики своей учетной записи (например, «Город», «Страна»). Следовательно, целесообразно не задействовать такие характеристики при создании правил доступа или же запретить пользователям изменять те атрибуты своих учетных записей, которые применяются при разграничении прав доступа (см. экран 4).

 

Запрет изменения атрибутов учетной записи
Экран 4. Запрет изменения атрибутов учетной записи

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

Второй раунд

По определению несанкционированный доступ к информации — это доступ к информации, нарушающий правила разграничения доступа с использованием штатных средств, предоставляемых средствами вычислительной техники или автоматизированными системами. Согласно регулирующим документам Гостехкомиссии России на автоматизированные системы и одной из первичных проверок в стандарте ISO/IEC 27002, управление доступом — это первая подсистема системы защиты информации от несанкционированного доступа. Поэтому управление доступом, или Access Control, — одна из ключевых составляющих в системе защиты информации.

Давайте теперь проверим, какой из двух механизмов готов обеспечить лучшую защиту от несанкционированного доступа к информации.

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

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

Впрочем, возникает вопрос: насколько легко в таком случае «обмануть» механизм классификации? Ответ напрямую зависит от качества сделанных настроек. Например, установив параметр «Агрегировать значения», который объединяет новое значение атрибута с уже имеющимися, можно избежать случаев понижения степени важности файла (если такое свойство ресурса используется).

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

Третий раунд

Предположим, документ пропал. Что делать? Конечно же, смотреть журналы аудита! Настройка аудита доступа к объектам осуществляется при настройке расширенной политики аудита. Как список DACL, так и функция DAC зафиксируют все необходимые сведения для анализа попыток доступа к файлам.

При этом DAC более наглядно продемонстрирует, на каком основании пользователю было отказано в доступе (см. экран 5).

 

Аудит попыток доступа к объектам
Экран 5. Аудит попыток доступа к объектам

Стоит отметить, что и DACL, и DAC поддерживают механизм обработки отказа в доступе Access-Denied Assistance, который может помочь заинтересованным лицам получить доступ к файловым ресурсам. К сожалению, на практике им мало кто пользуется.

Итак, по результатам сравнения можно сказать, что DAC выглядит более привлекательно с точки зрения полноты функциональности, удобства эксплуатации и гибкости.

Однако DAC имеет значительное ограничение в области применения — повышенные требования к операционной системе, а именно операционная система сервера и клиентской системы не должны быть ниже Windows Server 2012 и Windows 8 соответственно. На сегодня лишь небольшая часть организаций может похвастаться полным парком современных операционных систем. В то время как DACL исправно служит пользователям начиная с версии Windows NT.

К тому же DAC является довольно «тяжелым» инструментом с точки зрения подготовки, и его использование представляется целесообразным только тогда, когда есть четкое понимание бизнес-процессов в организации, существуют политики управления доступом и классификации информационных ресурсов. А функцию DACL можно начать использовать здесь и сейчас.

Поэтому, взвесив все «за» и «против», а также руководствуясь принципом защиты в глубину (Defense in Depth), мы делаем вывод, что победила дружба, и рекомендуем следующее:

  • на уровне верхнего файлового каталога или общих папок использовать механизм DACL, который позволит «отсечь» всех не допущенных лиц по классической схеме назначения разрешений Read, Write, Execute, Modify и т. д.;
  • внутри файлового каталога задействовать механизм DAC, который будет гранулированно управлять и отслеживать работу с документами, в том числе позволит принять дополнительные меры защиты в случае их «выхода» за пределы файлового каталога при действиях от имени легитимного пользователя.