Привет Хабр! Это снова Дмитрий Закорючкин из компании Avanpost, и сегодня я продолжаю рассказывать про нашу службу каталогов — Avanpost Directory Service. Я уже писал про наш подход к групповым политикам, а мой коллега освещал такую важную тему как устройство бекенда каталога. Темой сегодняшней статьи станет контроль доступа в Avanpost DS (не ролевая модель — это тема для отдельной статьи, а именно механизмы контроля доступа).

Задача контроля доступа в службе каталогов

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

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

Как реализуется принцип наименьших привилегий

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

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

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

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

• Применяться единообразно независимо от интерфейса доступа: если система делегирования работает только при доступе через rest api и не применяется при доступе через ldap-интерфейс, неизбежно будут появляться сервисные учетные записи с избыточными привилегиями (которые могут быть использованы как вектор атаки на инфраструктуру).

Схематично это можно изобразить так

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

Как это решается в других службах каталогов

Выбирая способ реализации своей модели контроля доступа мы сначала изучили механизмы, использующиеся в наиболее распространенных службах каталогов: MS Active Directory, FreeIPA, Open LDAP.

Active Directory и SambaDC

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

Модель контроля доступа в Active Directory может быть использована для соблюдения принципа наименьших привилегий и обеспечивает возможности по делегированию на основе местоположения объектов в организационной структуре и их классов, а также гранулярный контроль доступа на уровне атрибутов. Отдельно рассматривать модель контроля доступа в Samba DC не имеет смысла, так как Samba по сути является продуктом реверс инжиниринга MS AD и воспроизводит те же самые механизмы

FreeIPA (389 directory server)

FreeIPA, построенна на базе 389 Directory Server и использует его механизм контроля доступа. 389 Directory Server использует свой собственный механизм контроля доступа – ACI (Access Control Instructions), инструкции контроля доступа 389 DS тоже достаточно гибки, реализуют наследование, доступ на уровне атрибутов и даже специфические правила привязки. Портит впечатление от этих возможностей сама архитектура FreeIPA, в которой оргструктура каталога является фиксированной, жестко ограничивая расположение пользователей, групп и других типов объектов одним заданным контейнером, что на корню рубит возможности делегирования, реализованные в 389 DS.

OpenLDAP

Структура доступа olcAccess в Open LDAP токже позволяет обеспечить делегирование и гранулярный контроль доступа и в дополнение поддерживает регулярные выражения, но предполагает хранение всех записей контроля доступа в одном местоположении, из-за чего при обращении к любому объекту каталога приходится вычитывать вообще все правила, определенные для всего домена до нахождения подходящего. Использование такой структуры контроля доступа создает серьезные проблемы при масштабировании решения на доменах с десятками тысяч пользователей.

Как устроен контроль доступа в Avanpost DS

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

• Система контроля доступа не должна оказывать существенного влияния на производительность, даже при очень большом количестве разнообразных разешени. (в отличии от модели OpenLDAP)

• Синтаксис записей контроля доступа должен быть наглядным и позволять быстро и понятно производить делегирование полномочий и анализировать выданные разрешения. (в отличии от 389 DS)

Поэтому за основу мы решили взять структуру разрешений NT ACL - помимо выполнения основных критериев, она позволяла снизить влияние на производительность за счет хранения записей контроля доступа в каждом объекте и относительную наглядность по сравнению с другими моделями. Дополнительным бонусом - схема NT ACL понятна и привычна для всех администраторов MS AD (а до начала импортозамещения MS AD составляла 99,9...% всех инсталляций служб каталогов).

Таким образом схема контроля доступа Avanpost DS во многом повторяет NT ACL, но есть некоторые особенности, о которых я отдельно расскажу в завершении статьи.

Списки контроля доступа Avanpost DS

Наиболее гранулярным элементом системы контроля доступа является запись контроля доступа – аналог Access Control Entry в MS AD. Запись контроля доступа состоит из:

• Актора – субъекта безопасности, которому предоставляется или запрещается доступ;

• Области применения, определяющей, на какие типы объектов будет распространятся данное разрешение;

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

Например, запись контроля доступа может содержать для актора группы «Account Operators» разрешение на блокировку учетной и сброс пароля для области «дочерние учетные записи».

Так выглядит запись контроля доступа из примера выше для группы Account Operators*

*Информация об акторе хранится в виде UID-объекта, а в веб-интерфейсе транслируется в понятное имя.

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

Для сравнения – фрагмент гранулярных разрешений для подразделения (слева) и для пользователя (справа)

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

Большинство записей контроля доступа для пользователя унаследованы

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

Механизм контроля доступа

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

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

Алгоритм предоставления доступа основывается на следующих принципах:

• Суммирование правил – для определения доступа все записи контроля доступа суммируются;

• Непрямой запрет – если в маркере доступа нет ни одного актора из списка контроля доступа объекта – доступ не предоставляется;

• Преобладание запрет – если в списке контроля доступа есть и разрешение и запрет для акторов в текущем маркере доступа – доступ не предоставляется.

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

При этом совершенно неважно, какой интерфейс доступа был использован, – панель администрирования, ldap-сервер или утилита командной строки – разрешения будут применяться одинаково.

Какие есть особые случаи

Фильтры безопасности групповых политик

Как я уже писал в статье про групповые политики, в Avanpost DS реализованы фильтры безопасности по аналогии с MS AD, но есть один специфичный нюанс их применения – если в AD фильтрация осуществлялась за счет разрешения или запрета на чтение объекта групповой политики, то в нашем каталоге у объекта групповой политики есть отдельное разрешение – «применение групповой политики».

Это позволяет, например, администратору заблокировать применение групповой политики для своей учетной записи, но иметь возможность её редактировать, или наоборот, разрешить применение групповой политики для сотрудника, при этом запретив её чтение (получение политики с контроллера домена всегда выполняется от имени учетной записи компьютера).

Хранение DNS записей в интегрированных зонах

Схема хранения DNS-записей также накладывает свой отпечаток на систему контроля доступа. Дело в том, что DNS-сервер, использующий ldap бекенд (и тут нет разницы, это bind9, pdns или кто-то ещё), ожидает видеть отдельные записи в виде атрибутов объекта, соответственно, когда у нас есть, например несколько A записей – хранятся они как несколько значений одного атрибута и не могут иметь разных разрешений по определению. В MS AD это приводило, например, к тому, что, если для динамически зарегистрированных записей вручную добавить записи даже других типов, разрешения сбивались и для записи с динамической регистрацией.

Avanpost DS решает эту проблему, реализуя собственную схему хранения DNS-записей, в которой каждая запись является отдельным объектом каталога, а для DNS-серверов эта схема транслируется в понятный им вид. Такая схема позволяет применять разные разрешения для отдельных DNS-записей, не ломая отображение для DNS-сервера.

Заключение

Принцип наименьших привилегий – это краеугольный камень контроля доступа в службе каталогов, его соблюдение позволяет снизить ущерб от компрометации учетных записей с уровня катастрофы до управляемого ИБ-инцидента. Поэтому обеспечить соответствие критериям, о которых я говорил выше, – основная задача системы контроля доступа службы каталогов, упор на которую мы и делали при разработке Avanpost DS.

За рамками этой статьи остались такие важные темы как ролевая модель и аудит, но о них я расскажу в следующий раз.

Спасибо за внимание, надеюсь, было интересно!