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