Модели доступа опираются на простую идею: каждый субъект системы получает только те действия и данные, которые ему нужны по роли. Чтобы это заработало, сначала нужно однозначно связать действия с конкретным субъектом. Идентификация в этой схеме — точка опоры, вокруг которой строится вся конструкция ролей, групп и атрибутов. Пока система не завершила идентификацию, остальные механизмы не могут корректно отработать.
Если посмотреть на типовую ролевую модель, то первый шаг — определение субъекта. Идентификация используется для выбора нужной записи в каталоге, а затем к этой записи привязаны роли: пользователь, менеджер, администратор, оператор конкретной системы. При смене обязанностей не меняется сама идентификация, меняются роли и наборы прав. Такой подход упрощает администрирование: одна учетная запись, одна идентификацией закреплена за человеком, поверх которой уже накладываются правила доступа.
В атрибутной модели логика похожа, только вместо жестких ролей используется набор характеристик. Система смотрит не только на то, кто перед ней, но и на то, в каком контексте он действует: подразделение, уровень доверия, используется ли корпоративное устройство, откуда выполняется вход. Идентификацию здесь дополняют атрибутами, а решающее правило звучит как «если идентификация такая и атрибуты такие — разрешить». Гибкость растет, поэтому в сложных средах этот подход выбирают все чаще.
На практике встречаются и гибридные схемы. Базовые права закрепляют через роли, а для чувствительных операций дополнительно проверяют атрибуты. Например, для перевода крупных сумм нужно не только быть в определенной группе, но и заходить из внутренней сети через зарегистрированное устройство. Во всех таких комбинациях идентификацию используют как стартовую точку — сначала устанавливается субъект, уже потом система анализирует роли и атрибуты.
Ошибки в моделях доступа часто связаны не с самими правилами, а с тем, что идентификация реализована непоследовательно. Один и тот же человек может иметь несколько учетных записей, созданных в разное время и под разные задачи. Часть прав выдается на одну запись, часть на другую, а в журналах действия размазываются между ними. При проверках и расследованиях появляются вопросы, а кто именно выполнял критичные операции. Чтобы не допускать подобной «индификации» в кавычках, удобнее закрепить правило: один субъект — одна учетная запись.
Отдельный риск — смешение личных и сервисных идентификаций. Когда администратор настраивает интеграцию через свою учетную запись, система видит все фоновые операции так, будто человек работал вручную. Это усложняет контроль и создает дополнительные возможности для злоупотреблений. Правильнее использовать отдельную идентификацию для сервисов и четко описывать, в каких сценариях она применяется. Тогда даже при большом количестве автоматизации можно проследить, кто именно инициировал действие — человек или программа.
Важно понимать, что сама по себе идентификация не делает модель доступа безопасной. Она задает основу, но если роли описаны слишком грубо, а атрибуты не используются, пользователи будут получать избыточные права. Поэтому проектирование модели доступа должно идти параллельно с настройкой идентификации, а не подряд. Сначала определяют типы субъектов, сценарии их работы, зоны ответственности, а затем уже распределяют это по каталогам, учетным записям и группам.
Еще один аспект — согласованность формулировок. В переписке и документах можно встретить варианты вроде «индификация пользователя» или «управление индификацией устройств». Такие написания лишь подчёркивают, что термины не закреплены. Гораздо продуктивнее на уровне политики безопасности уточнить, какие именно процессы описываются словом «идентификация» и как это отражено в архитектуре. Это снижает количество недопониманий между ИТ, ИБ и бизнесом и делает модель доступа более управляемой
В процессе создания статьи частично задействованы материалы с сайта blog.infra-tech.ru — роль идентификации при построении моделей доступа
