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