Windows acl что это

Обновлено: 08.07.2024

Списки управления доступом являются частью комплексной системы безопасности сети. Они позволяют запретить/разрешить определенным хостам доступ к ресурсам сети. Например, в корпоративной сети администраторы могут запретить доступ в интернет определенным пользователям, а остальным наоборот - разрешить.

Запретить/разрешить мы можем на основе IP адресов, портов и задействованных протоколов. На этом принципе и работают списки управления доступом ACL ( Access Control List ).

Другим примером использования списков доступа является запрет поступающих на маршрутизатор пакетов протокола ICMP. Как мы знаем с помощью ICMP работают утилиты Ping, Traceroute/Tracert. С помощью данных утилит можно просканировать сеть, а это нежелательно с точки зрения политики безопасности каждой сети.

Списки доступа позволяют фильтровать трафик на входе и выходе интерфейса маршрутизатора.

И в чем же разница?

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

Когда ACL настроены на выходе интерфейса, то трафик фильтруется сразу же после процесса маршрутизации:

Данная особенность может быть полезна при определенных обстоятельствах.

Так что же из себя представляют списки доступа и как они работают?

Списки доступа содержат просто набор инструкций какие порты и адреса блокировать, а какие наоборот разрешить. Этих инструкций может от нескольких единиц до десятков.

При поступлении трафика проверка списка доступа начинается сверху вниз, то есть с первой инструкции. Как только будет найдено совпадение проверка списка прекратится и будет выполнено действие, указанное в инструкции (заблокировать или пропустить).

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

Cisco IOS поддерживает 3 типа ACL:

стандартные списки
расширенные списки
именованные списки

Стандартные списки позволяют проверять только IP адрес отправителя. Например,в нашем 1-ом примере доступ в интернет Алисе и Кате можно закрыть с помощью стандартного списка. В данном случае блокируется абсолютно весь трафик, проходящий через маршрутизатор. Стандартные списки доступа рекомендуется устанавливать как можно ближе к отправителю.

Расширенные списки позволяют фильтровать пакеты на основе адресов, портов и протоколов получателя и отправителя.

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

Электронная почта работает по протоколам POP/SMTP (порты 110/ 25). Следовательно можно внести исключение в списки доступа исходя из выше описанных условий.

То же самое касается и IP телефонии - выбираем задействованный протокол и порт и вносим в список доступа.

Расширенные списки рекомендуется устанавливать ближе к получателю.

Именованные списки являются теми же стандартными и расширенными ACL, однако предоставляют более гибкие возможности для редактирования (об этом немного позже).

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

Стандартный список

Инструкция задается следующей командой:

Номер списка принимает значения от 1 до 99. Цифры не означают приоритет или упорядоченность. Это просто номер списка. Затем следует команда permit (разрешить) или deny (запретить). С помощью инвертированной маски (wildcard mask) мы можем определить диапазон адресов, на которые будет распространяться запрет/разрешение.

В первой команде мы запрещаем сеть 192.168.1.0/24, а во второй разрешаем сеть 10.1.0.0/16.

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

А как работает инвертированная маска (wildcard mask)?

Работа инвертированной маски основана на следующем принципе.

На тех битовых позициях, где установлен 0 IP адрес устройства должен совпадать с адресом, указанным в настройках ACL.

На тех битовых позициях, где установлена 1 IP адрес устройства может не совпадать с адресом, указанным в настройках ACL, то есть может принимать любые значения. Поясню сказанное на примерах.

Пример №1

Необходимо разрешить доступ диапазону адресов 192.168.1.0 - 192.168.1.255. Так как первые 3 октета должны совпадать полностью, а четвертый может принимать любые значения, то используем маску 0.0.0.255. Вот как это выглядит на рисунке

Пример №2

К диапазону 192.168.1.0-192.168.1.255 добавим еще один диапазон 192.168.2.0 - 192.168.2.255.

Теперь у нас должны совпадать первые 2 октета полностью и первые 6 бит третьего октета. Поэтому маска у нас 0.0.3.255. А в настройках ACL мы укажем адрес 192.168.0.0. Можно, конечно, указать сразу 2 отдельные команды на каждый диапазон, с помощью маски мы можем сократить запись

Пример №3

Необходимо разрешить/запретить диапазон 200.40.0.4 - 200.40.0.7. У нас совпадают полностью первые 3 октета и первые 6 бит четвертого октета:

После того, как список создан, необходимо определить направление (входящий или исходящий) трафика и на каком интерфейсе он будет фильтроваться:

in - входящий трафик

out - исходящий трафик

Алгоритм работы стандартного списка выглядит так:

Расширенный список доступа

Расширенные списки доступа имеют номера от 100 до 199.

Команды имеют довольно широкий набор опций, поэтому покажу наиболее общий пример команды:

Данная команда разрешает TCP трафик от хостов с диапазоном 192.168.1.0/24 на хосты с диапазоном 10.1.1.0/24. Причем порты отправителя должны быть равны 80, а порты получателя - 443. Если все эти условия соблюдаются, то пакет пропускается, если нет, то переходит к следующей команде.

А вот эта команда запрещает весь TCP трафик от любого хоста на конкретный хост с адресом 172.16.1.5. Причем запрет действует при условии, что запросы идут на порты получателя от 5001 и выше.

В конце списка всегда следует неявная команда, запрещающая весь трафик.

Не забудь определить интерфейс и направление трафика для фильтрации.

Вот как выглядит алгоритм работы расширенных списков:

Для просмотра настроек используй следующие команды:

Именованные списки

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

Стандартные и расширенные списки редактировать нельзя. К примеру, нельзя в середину списка вставить команду или удалить ее. Для этого нужно сначала деактивировать список на самом интерфейсе , а затем полностью его удалить и настроить заново.

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

Синтаксис команд представлен ниже.

Для стандартных списков:

Для расширенных списков:

Чтобы удалить ненужную команду достаточно узнать ее номер. Чтобы узнать номер введи команду:

а затем укажи ее номер при удалении:

Ну а чтобы добавить команду достаточно тоже указать номер и затем саму команду.

Обращаю твое внимание, что удаление и добавление строк списка происходит в режиме настройки ACL, например так:

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

Сеть состоит из 3 частей:

Внутренняя сеть - основная инфраструктура локальной сети любого предприятия.
Демилитаризованная зона DMZ - в ней располагаются сервера, которые доступны из интернета. Доступ во внутреннюю сеть из этой зоны закрыт из соображений безопасности.
Внешняя сеть - связывается напрямую с провайдером. Обычно состоит из маршрутизаторов и сетевых экранов (firewalls).

Именно по этому принципу и строятся сети предприятий.

Задача у нас следующая:

Всем серверам из DMZ запретить доступ во внутреннюю сеть
Всем серверам из DMZ разрешить двустороннюю связь в интернет
Пользователям из интернета разрешить доступ на серверы в DMZ, учитывая протокол взаимодействия и порты TCP/UDP
Разрешить доступ внутренним пользователям на серверы DMZ
Запретить Алине и Саше доступ в интернет и DMZ, то есть они могут работать только во внутренней сети.

Пункт №1 можно решить с помощью расширенного списка на маршрутизаторе LAN_Router

Поэтому список доступа на маршрутизаторе LAN_router безусловно необходим.

А какие ошибки могут привести к тому, что сеть LAN будет доступна для DMZ?

Например, на маршрутизаторе Firewall при настройке статического маршрута может быть по ошибке указан интерфейс, ведущий к маршрутизатору LAN_Router.

Или на маршрутизаторе LAN_Router будет выполнена команда redistribute connected . В данный момент между 2-мя маршрутизаторами настроен EIGRP. Если выполнить вышеназванную команду, то маршрутизатор Firewall узнает о сети LAN.

Пункты №2 и №3 не требуют списков доступа. Достаточно настроить правильно маршрутизацию и NAT на маршрутизаторе Firewall

Пункт №4. Внутренние пользователи уже имеют доступ в зону DMZ, однако связь будет работать только в одну сторону, так как мы закрыли доступ еще в п.1.

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

Решение простое - достаточно настроить NAT на маршрутизаторе LAN_Router. Тогда только внутренние пользователи смогут подключаться к серверам, а сервера уже не смогут из-за активированного списка доступа. Однако это не единственное решение

Список контроля доступа к системе (SACL)

Системный список управления доступом (SACL) позволяет администраторам регистрировать попытки доступа к защищенному объекту. Каждый ACE определяет типы попыток доступа указанного доверенного лица, которые заставляют систему генерировать запись в журнале событий безопасности. ACE в SACL может генерировать записи аудита, когда попытка доступа терпит неудачу, когда она успешна, или и то, и другое. Дополнительные сведения о SACLs см. В разделе генерация аудита и право доступа к SACL.

Списки управления доступом изначально реализованы на некоторых платформах операционных систем UNIX, таких как Solaris (который впервые реализовал ACL в версии 2.5.1), а также доступны в качестве стороннего программного обеспечения для других платформ UNIX.

Традиционно управление доступом в файловых системах UNIX осуществлялось с помощью команды chmod (change mode), но это обеспечивало лишь ограниченный или грубый контроль разрешений на доступ к файлам и не обеспечивало гибкости для настройки уникальных наборов разрешений на доступ для конкретных пользователей или групп.

Для установки и отображения списков управления доступом в Solaris используйте команды setfacl и getfacl. Другие пакеты UNIX и надстройки могут использовать различные команды, такие как setacl и getacl .

Зачем использовать ACL?

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

Для повышения безопасности с помощью ACL можно, например, запретить определенные обновления маршрутизации или обеспечить управление потоком трафика.

Как показано на рисунке ниже, устройство маршрутизации имеет ACL, который запрещает доступ хосту C в финансовую сеть, и в то же время он разрешает доступ к хосту D.

С помощью ACL вы можете фильтровать пакеты для одного или группы IP-адресов или различных протоколов, таких как TCP или UDP.

Так, например, вместо блокировки только одного хоста в команде разработчиков, вы можете запретить доступ ко всей сети и разрешить только один. Или вы также можете ограничить доступ к хосту C.

Если инженеру с хоста С необходимо получить доступ к веб-серверу, расположенному в финансовой сети, можно разрешить только порт 80, а все остальное заблокировать.

Список контроля доступа (ACL), с в отношении компьютерной файловой системы, список разрешений, прилагаемых к объект. ACL указывает, какие пользователи или системным процессам предоставляется доступ на объекты, а также какие операции разрешены на заданных объектах. каждый запись в типичном ACL указывает субъекта и операции. За экземпляр, если файл имеет ACL, который содержит (Алиса, удаление), это дать Алисе разрешение на удаление файл.

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

Вы можете посмотреть на это следующим образом.

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

Если вы удаляете пользователя с именем FRED, его серийный номер удаляется и удаляется из ACL. Фактически сериализованный номер FRED больше не связан с другими устройствами, и разрешения, которые у него были с этими устройствами, также удаляются.

Если вы заново создаете имя пользователя FRED, ему будет назначен новый серийный номер. ACL распознает это как новый номер. Поэтому он не будет восстанавливать никаких разрешений, которые удаляла учетная запись FRED.

Надеюсь, это поможет концептуализировать, что такое ACL, как это работает и почему это важно.

Список контроля доступа (ACL) имеет ноль или более записей контроля доступа (ACE). Многие объекты в Windows могут иметь ACL, такие как файлы, устройства, принтеры, записи в реестре и другие. (Проверьте WinObj SysInternal , если вы хотите получить обзор всех типы объектов в пространстве имен Windows - многие из них являются внутренними для Windows и не подвергаются прямому воздействию пользователя)

A main . Обычно это либо пользователь, либо группа. Это может быть пользователь, группа или компьютер в базе данных Active Directory на контроллере домена или локальном пользователе. Существуют «виртуальные» группы, такие как «Все» и «Аутентифицированные пользователи».

Один или несколько возможностей, для каждой возможности можно установить значение Разрешить или Отрицать. Некоторый пример возможностей - «Чтение», «Запись», «Содержание списка» и т. Д. Запрет принимает предварительную проверку над Разрешить. Большинство объектов, таких как файлы и т. Д., Не разрешают доступ или изменения, если только не имеется доступный ACL «Разрешить»; поэтому Deny следует использовать только в особых обстоятельствах.

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

Они важны, потому что именно так Windows дает и обеспечивает привилегии процессам. Каждый процесс выполняется как пользователь, и если этот пользователь «попадает под» один или несколько ACE, тогда Windows разрешает всем им определять, разрешено ли конкретное действие или нет.

14.05.2015

Windows Server 2012

комментария 3

Недостатки организации доступа на основе ACL

Каким образом реализовывался доступ к общим каталогам на файловых серверах до появления Dynamic Access Control. На общую папку на уровне NTFS и/или шары назначались определенные списки доступа, включающиеся в себя определенные группы в AD (или локальные группы сервера) или конкретные учетные записи. Чтобы пользователь получил доступ к нужному каталогу, администратор должен был включить его в соответствующую группу. Какие недостатки такой модели организации доступа?

· Доступ регулируется только на основании только членства в группе

· При большом количестве общих папок необходимо создавать большое количество групп (выливается в увеличение билета Kerberos)

· Отсутствует возможность контроля доступа на основании характеристик устройства пользователя, с которого подключается пользователь

· Невозможность реализации сложных сценариев доступа

При контроле доступа только на основе ACL нередки случаи, когда пользователь случайно выкладывает конфиденциальную информацию (зарплаты топ-менеджеров, например) на общедоступный (public) ресурс, где все желающие могут с ней познакомится.

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

Архитектура и принципы Windows Server 2012 Dynamic Access Control

В Windows Server 2012 Dynamic Access Control создает еще один уровень управления доступом к файловым объектам на уровне всего домена, причем на эти объекты продолжают действовать NTFS разрешениями
(ACL). Отметим, что правила DAC могут действовать повсеместно, независимо от того, какие NTFS права выставлены на объекте.

Одной из основных концептов модели DAC является понятие claim (заявка или утверждение). В модели управления доступом Windows Server 2012 claim представляет собой атрибут Active Directory, которой определен для использования с централизованными политиками доступа (Central Access Policies). В качестве критериев можно использовать практически любые сохранные в AD параметры, принадлежащие определенному объекту, например, ID устройства, способ входа в систему, местонахождение, личные данные и т.д. Настройка claim-ов осуществляется с помощью консоли управления Active Directory Administrative Center (ADAC) в новом контейнере Claim Based Access. В этом контейнере (изначально пустом) можно создавать собственные утверждения и связывать их с атрибутами пользователей или компьютеров. Основываясь на значениях claim-ов можно определить давать ли доступ данному пользователю/устройству к тому или иному объекту файловой системы.

Следующий компонент DAC – свойства ресурсов (Resource Properties), с помощью которых определяются свойства ресурсов, которые в дальнейшем будут использовать в правила авторизации. Resource Properties – это также отдельный контейнер в Dynamic Access Control.

Следующими элементами DAC являются правила Central Access Rules и политики Central Access Policy. CentralAccess Rules описывают какой уровень доступа предоставить к файлам, каким пользователям, с какими заданными утвержденями, с каких устройств и т.д. Central Access Policy – это политика, содержащая в себе правила Central Access Rules, которая в дальнейшем посредством GPO будет распространена по всей организации (или конкретной OU).

Каким образом можно перейти на модель управления доступом Dynamic Access Control в организации:

1. Создать один/несколько видов клаймов.

2. Активировать одни/несколько свойств ресурсов (метки или теги у файловых объектов)

3. Создать правило Central Access Rule, в котором определяется условия предоставления доступа

4. Добавить созданные правила в политику Central Access Policy

5. С помощью групповых политик распространить CAP на файловые сервера

Естественно, перед внедрением Dynamic Access Control необходимо настроить систему классификации файлов, как это сделать описывается в статье : Классификация файлов с помощью File Classification Infrastructure в Windows Server 2012. Этап определения и классификация данных, хранящихся на файл-серверах наиболее тяжелый и трудоемкий, результатом которого будет назначение управляемым файловым объектам NTFS тэгов.

Каким образом осуществляется проверка разрешений пи доступе к файлу/каталогу конечного пользователя, ведь теперь помимо прав доступа на NTFS осуществляется еще и проверка на соответствие клаймов? Последовательность проверки разрешений следующая:

· Central Access Policy

Пример использования Dynamic Access Control в Windows Server 2012

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

С помощью консоли AD Administrative Center создадим два новых claim-a: Department и Country. Для этого перейдите в контейнер Dynamic Access Control -> Claim Types и в меню выберите пункт New:

Создадим новое утверждение с именем Department :

и Country :

В атрибуте Country укажем два предопределенных (suggested) значения (EG – Египет, и QR – Катар):

Далее создадим новое свойство ресурса (Resource Properties) для утверждения Country: New-> Resource Properties.

Затем в контейнере Resource Properties активируйте утверждение Department

Теперь создадим новое правило Central Access Rule. В этом правиле будут указаны разрешения, которые применяются к объекту, если claim совпадает с правилом, описанном в CAR.

Предположим, мы правило, определяющее, что пользовали Finance Admins (Department=Finance и County=EG), имеют полный доступ, а пользователи Finance Execs (Department=Finance) – доступ только на чтение. Это правило будет применено ко всем правилам, классифицированным, как относящиеся к финансовому департаменту:

В итоге, правило будет выглядеть так:

Затем создадим политику Central Access Policy (CAP), которая с помощью GPO будет применена ко всем файловым серверам.

В новую политику CAP, включим правило для финансового департамента, созданное ранее:

Далее правило Central Access Policy с помощью групповых политик нужно применить ко всем файловым серверам. Для этого нужно создать новую политику GPO и прилинковать ее к OU с файловыми серверами.

В окне редактора групповых политик (Group Policy Management Editor) перейдите в раздел Computer Configuration->Policies->Windows Settings->Security Settings->File System-Central Access Policy->Manage Central access policies.

В окне настроек Central Access Policies Configuration добавим политику Finance Data и нажмем OK.

Закройте редактор групповых политик и обновите политики на контроллере домена и файловых серверах командой

Посмотрим, что же у нас получилось.

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

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

Проверим текущие разрешения на папку.

Перейдем на вкладку Central Policy и применим политику Finance Data.

Если у пользователя не назначены утверждения (он входит в нужную группу, но у него не определены атрибуты department и country), доступа к каталогу у него не будет.

Заключение

С помощью комбинации технологий DAC, AD RMS (как организовать динамическое шифрование файлов с помощью AD RMS и FCI )и FCI можно создавать мощные схемы управления доступом к документам и зашиты конфиденциальной информации, реализуя полноценную DLP систему на базе инфраструктуры Windows Server 2012.

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