Windows dac что это

Обновлено: 04.07.2024

Отображает или изменяет избирательные списки управления доступом (DACL) для указанных файлов и применяет сохраненные списки DACL к файлам в указанных каталогах.

Эта команда заменяет устаревшую команду cacls.

Синтаксис

Параметры

Комментарии

Идентификаторы SID могут быть в виде числовых или понятных имен. Если используется числовая форма, прикреплять символ-шаблон * к началу идентификатора SID.

Эта команда сохраняет канонический порядок записей ACE следующим образом:

<perm> Параметр — это маска разрешений, которая может быть указана в одной из следующих форм:

Последовательность простых прав:

F — полный доступ

M— изменение доступа

RX — доступ для чтения и выполнения

R — доступ только для чтения

W — доступ только на запись

Список с разделителями-запятыми в скобках для конкретных прав:

D — удаление

RC — контроль чтения

WDAC — запись DAC

WO — владелец записи

S — синхронизация

Безопасность системы как доступа

MA — максимально допустимый

GR — универсальное чтение

GW — универсальная запись

GE — универсальное выполнение

Общедоступная версия-общий

RD -чтение данных или каталога списка

WD : запись данных и добавление файла

AD — Добавление данных и Добавление вложенного каталога

Реа — чтение расширенных атрибутов

ВЕА — запись расширенных атрибутов

X -выполнение и обход

Контроллер домена -Удаление дочернего элемента

RA -чтение атрибутов

Атрибуты записи WA

Права на наследование могут предшествовать любой <perm> форме, и они применяются только к каталогам:

(OI) — наследование объектов

(CI) — наследование контейнера

(IO) — только наследование

(NP) — не распространять наследование

Примеры

чтобы сохранить списки dacl для всех файлов в каталоге C:\ Windows и его подкаталогах в файле аклфиле, введите:

чтобы восстановить списки dacl для каждого файла в аклфиле, который существует в каталоге C:\ Windows и его подкаталогах, введите:

Чтобы предоставить пользователю User1 разрешения на удаление и запись DAC в файл с именем Test1, введите:

Чтобы предоставить пользователю, заданному с помощью SID S-1-1-0, разрешения DAC и Write в файл с именем test2, введите:



Мы продолжаем перевод и публикацию материалов, связанных с Windows Server 2012 и обновлениями штатных систем аудита Microsoft. Приглашаем заинтересованных читателей ознакомиться с рассказом сотрудника команды Windows Server о новых возможностях Dynamic Access Control.

Здравствуйте, меня зовут Nir Ben-Zvi, я работаю в команде Windows Server. Я рад представить вам сегодня новый набор функций для Динамического контроля доступом (Dynamic Access Control), который имеется в Windows Server 2012.

Сначала я вкратце расскажу о процессе планирования, затем мы рассмотрим новую модель политики центрального доступа (Central Access Policy) и опишем что нового в Файловом Сервере, решении, которое мы встроили в Windows Server 2012. Я также вопросов постепенного внедрения, так чтобы Вам не нужно было перемещать всю среду на Windows Server 2012, если Вам нужно использовать данную функцию. В конце мы рассмотрим вопросы, связанные с тем какие решения наших партнеров помогут расширить предлагаемых функционал наших решений.
Введение

В современных (читай: сложных) IT-инфраструктурах создание данных происходит с ошеломляющей скоростью в рассредоточенных системах; одновременно доступ к этим данным осуществляется с многочисленных устройств. Выполнение требований нормативов по информационной безопасности и потребность в защите конфиденциальной информации от утечек – одни из важнейших проблем для бизнеса и IT. Чтобы эти проблемы были успешно решены – необходимо контролировать, кто получил доступ к определенной информации, причем желательно, чтобы желательно, чтобы при осуществлении такого контроля информация о доступе была представлена максимально наглядно.
Мы были в курсе этим проблем, стоящих перед бизнесом и IT уже пару лет назад, когда планировали, каким будет Windows Server 2012. Вот только несколько часто встречающихся запросов со стороны наших клиентов:

• Централизованное управление доступом к информации как на основе запросов бизнеса, так и с целью выполнения требований нормативов
• Должен осуществляться аудит доступа к информации для целей анализа и выполнения требований нормативов по ИБ
• Конфиденциальная информация должна быть защищена
• Владельцы контента должны быть ответственны за свою информацию – администраторы не должны заниматься не своей работой
• Ключевым аспектом является поддержание продуктивности деятельности специалистов, работающих с информацией
Мы взглянули на отдельные должностные позиции в организации и их взаимодействие в процессе выполнения запросов со стороны бизнеса, и регулирующих органов, чтобы представить адекватный запросам набор технологий и решений.
Таким образом, список должностей, вовлеченных в решение обозначенных проблем, начинается с CSO/CIO, который определяет потребности с позиций бизнеса и выполнения требований нормативов. За ними следуют IT-администраторы, которые осуществляют управление системами, и владельцы контента, которые контролируют фактическую информацию. Что касается тех, кто непосредственно работает с информацией, то влияние применяемых решений на них должно быть минимальным (в идеале его не должно быть совсем).

image

Чтобы помочь организациям выполнить требования нормативов и решить стоящие перед ними бизнес-задачи, мы в конечном итоге, сфокусировались на следующих сферах:
• Определение информации, управление которой должно осуществляться для достижения поставленных целей
• Применение политик доступа к информации
• Аудит доступа к информации
• Шифрование информации
Эти задачи были переведены в набор функций Windows, которые делают возможным защиту данных с помощью решений Windows и решений партнеров.
• Добавлена возможность конфигурировать в Active Directory централизованный доступ (Central Access) и политики аудита. Эти политики основаны на условных требованиях (см. ниже); при этом могут быть значительно снижено число групп безопасности для контроля доступа:
o Кем является пользователь
o Какое устройство он использует
o К каким данным получен доступ
• Заявки (claims) интегрированы в аутентификацию Windows (Kerberos), так что пользователи и устройства могут быть описаны не только посредством групп безопасности, в которых они состоят, но также и по заявкам, например: “Пользователь из Отдела финансов”, и “Категория доступа (security clearance) пользователя высокая”.
• Улучшена инфраструктура классификации файлов (File Classification Infrastructure), что позволит владельцам контента и пользователям идентифицировать (присваивать теги) их данные, так что IT-администраторы могут создавать целевые политики, основываясь на этих тегах. Эта возможность работает наряду с возможностью инфраструктуры классификации файлов автоматически классифицировать файлы на основании их содержимого или других характеристик.
• Интегрированы службы управления правами (Rights Management Services), чтобы автоматически защищать (шифровать) конфиденциальную информацию на серверах, так что даже тогда, когда она покидает сервер, она защищена.

Политики центрального доступа

Политики центрального доступа можно сравнить со страховкой, которую организация применяют на своих серверах. Эти политики улучшают (но не заменяют) политику локального доступа (например, дискреционный ACL), которая применяются к информации. Например, если локальный DACL файла разрешает доступ определенному пользователю, но Центральная политика запрещает доступ этому же пользователю, то он не сможет получить доступ к файлу (и наоборот).

Инициатива по внедрению и усилению политики центрального доступа произрастает из различных причин и из различных уровней организации:
• Политика, связанная с выполнением требований нормативов: Эта политика соотносится с требованиями нормативов и бизнеса и нацелена на защиту правильного (адекватно установленного) доступа к информации, управление которой осуществляется. Например, дать доступ к информации, которая подпадает под регулирующие документы “US-EU Safe Harbor”, только определенной группе пользователей.
• Политика разрешений на уровне отделов: Каждый отдел в организации имеет определенные требования к работе с данными, которые бы они хотели бы защитить (укрепить). Такая ситуация часто встречается в организациях с разветвленной организационной структурой. Например, отдел финансов хочет ограничить доступ к финансовой информации только для финансовых работников.
• Политика “необходимо знать” (Need to know policy): Эта политика гарантирует, что доступ допускается только тем, кому “необходимо знать”. Например:
o Вендоры должны получать доступ к информации и редактировать только файлы, которые относятся к проектам, над которым они работают.
o В финансовых учреждениях “стены” между информацией важны, например, аналитики не должны получать доступ к брокерской информации, а брокеры – к аналитической.
Политики центрального аудита

Политика центрального аудита (Central Audit Policy) – мощный инструмент, который позволяют поддерживать безопасность организации. Одной из ключевых целей аудита безопасности является выполнение требований нормативов по информационной безопасности. Отраслевые стандарты, такие как SOX, HIPPA, PCI и другие требуют от организаций следовать жестко установленному набору правил, связанных с информационной безопасностью и конфиденциальностью данных (privacy). Работа аудиторов заключается в том, чтобы установить наличие (или отсутствие) таких политик, тем самым доказывается выполнение (или не выполнение) требований этих стандартов. Вдобавок, аудит безопасности позволяют фиксировать аномальное поведение, определять и избегать образования дыр в системе безопасности и ограничивать несанкционированное поведение – любая важная деятельность пользователей записывается, а такие записи могут быть использованы при проведении расследования.

Windows Server 2012 позволяет администраторам разрабатывать политики аудита, используя выражения, которые принимают во внимание то, к какой информации пользователи получают доступ и кем эти пользователи являются, так что организация может осуществлять аудит доступа только к определенной информации, вне зависимости от того, где бы они не находилась. Это открывает дорогу к более целевым и в то же время простым в использовании политикам аудита. Теперь можно реализовывать сценарии, которые до настоящего момента было сложно осуществить. Например, Вы можете легко разработать политики аудита, которые перечислены ниже:
• Аудит всех, у которого нет высокой категории допуска и кто, тем не менее, пытается получить доступ к “важной” информации
• Аудит всех вендоров, которые пытаются получить доступ к документам по проектам, над которыми они не работают.

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

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

Основываясь на подобной инфраструктуре, мы разработали комплексное решение для Windows Server 2012 Active Directory, Windows Server 2012 File Server и Windows 8 client. Это решение позволяет вам:
• Идентифицировать данные, используя автоматическую и ручную классификацию файлов.
• Контролировать доступ к файлам по всем серверам, применяя гарантию (safety net) политик центрального доступа. Например, Вы можете контролировать, кто получает информацию о здоровье сети по всей организации.
• Аудит доступа к файлам на файловых серверах, используют политики центрального аудита для целей выполнения нормативов по информационной безопасности и проведения расследований. Например, Вы можете определить, кто получил доступ к высоко конфиденциальной информации за последние три месяца.
• Шифрование данных посредством автоматического применения шифрования служб управления правами (Rights Management Services (RMS)) для конфиденциальных документов. Например, Вы можете настроить RMS на шифрование всех документов, которые содержат информацию, защищаемую нормативом HIPAA.

image

Для того чтобы поддержать внедрение на множестве файловых серверов в организации, мы также предоставляем Data Classification Toolkit, который позволяет осуществлять настройку и формирования отчетов среди многочисленных серверов.
Бета-версию Data Classification Toolkit можно скачать здесь.

Концепция постепенного внедрения

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

Вы можете использовать большинство из возможностей Dynamic Access Control в файловом сервере Windows Server 2012 и обновленной схеме домена Active Directory. Добавление минимального числа контроллеров доменов Windows Server 2012 позволить включить пользовательские заявки и т.д. Каждая часть системы, которую Вы обновите, даст Вам больше возможностей, однако задавать скорость внедрения – это уже на ваше усмотрение.

image

Решения партнеров

Решения партнеров и ряд бизнес приложений может повысить эффективность использования инвестиций в инфраструктуру Windows для Dynamic Access Control, обеспечивая ценность для организаций, использующих Active Directory. Вот лишь некоторые примеры партнерских решений, которые представляли на конференции в прошлом году:
• Интеграция систем предотвращения утечки данных (Data Leakage Prevention) с системой автоматической классификации содержимого
• Централизованный анализ данных аудита
• Авторизация служб управления правами (Rights Management Services) с использованием Central Access Policies
• Многие другие…

Отображает или изменяет избирательные списки управления доступом (DACL) для указанных файлов и применяет сохраненные списки DACL к файлам в указанных каталогах.

Эта команда заменяет устаревшую команду cacls.

Синтаксис

Параметры

Комментарии

Идентификаторы SID могут быть в виде числовых или понятных имен. Если используется числовая форма, прикреплять символ-шаблон * к началу идентификатора SID.

Эта команда сохраняет канонический порядок записей ACE следующим образом:

<perm> Параметр — это маска разрешений, которая может быть указана в одной из следующих форм:

Последовательность простых прав:

F — полный доступ

M— изменение доступа

RX — доступ для чтения и выполнения

R — доступ только для чтения

W — доступ только на запись

Список с разделителями-запятыми в скобках для конкретных прав:

D — удаление

RC — контроль чтения

WDAC — запись DAC

WO — владелец записи

S — синхронизация

Безопасность системы как доступа

MA — максимально допустимый

GR — универсальное чтение

GW — универсальная запись

GE — универсальное выполнение

Общедоступная версия-общий

RD -чтение данных или каталога списка

WD : запись данных и добавление файла

AD — Добавление данных и Добавление вложенного каталога

Реа — чтение расширенных атрибутов

ВЕА — запись расширенных атрибутов

X -выполнение и обход

Контроллер домена -Удаление дочернего элемента

RA -чтение атрибутов

Атрибуты записи WA

Права на наследование могут предшествовать любой <perm> форме, и они применяются только к каталогам:

(OI) — наследование объектов

(CI) — наследование контейнера

(IO) — только наследование

(NP) — не распространять наследование

Примеры

чтобы сохранить списки dacl для всех файлов в каталоге C:\ Windows и его подкаталогах в файле аклфиле, введите:

чтобы восстановить списки dacl для каждого файла в аклфиле, который существует в каталоге C:\ Windows и его подкаталогах, введите:

Чтобы предоставить пользователю User1 разрешения на удаление и запись DAC в файл с именем Test1, введите:

Чтобы предоставить пользователю, заданному с помощью SID S-1-1-0, разрешения DAC и Write в файл с именем test2, введите:

С механизмом разграничения прав доступа на базе списка управления доступом, или 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 на практике.

Первый раунд

  • доменная архитектура;
  • пользовательские рабочие места под управлением операционной системы 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.

Например, после того как установлены разрешения на доступ к родительской папке, создаваемые в ней новые файлы и подпапки будут наследовать эти разрешения. Если вложенным папкам требуются другие разрешения, необходимо запретить наследование и скорректировать текущие разрешения, как показано на экранах 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), мы делаем вывод, что победила дружба, и рекомендуем следующее:

Читайте также: