Контроль доступа в Avanpost DS, часть первая: механизмы контроля доступа

Значимый прорыв формирует отрасль ИИ: HITmk5 9 минут назад Контроль доступа в Avanpost DS, часть первая: механизмы контроля доступа Средний 8 мин 445 Блог компании Avanpost Обзор Привет Хабр! Это снова Дмитрий Закорючкин из компании Avanpost, и сегодня я продолжаю рассказывать про нашу службу каталогов — Avanpost Directory Service. Я уже писал про наш подход к групповым политикам, а мой коллега освещал такую важную тему как устройство бекенда каталога.

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

Технические детали

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

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

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

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.