Доступ отозван: в «Яндексе» рассказали, как модифицировали IDM для защиты сервисов
В «Яндексе» модифицировали систему управления доступом (IDM) для автоматического контроля ролей сотрудников. Основными задачами стали отзыв неиспользуемых доступов и интеграция с корпоративными сервисами, например, для учёта прохождения курсов по ИБ. Внедрение решения позволило сразу отозвать 25% активных ролей из-за их избыточности.
В IDM-системе «Яндекса», используемой в городских сервисах («Яндекс Go», «Маркет», «Еда», «Лавка» и прочие), насчитывается более 31 миллиона выданных ролей. Контролировать их распределение в таких масштабах становится нетривиальной задачей. При этом эта работа необходима, поскольку «потерянные» доступы рискуют быть скомпрометированными и попасть в чужие руки, либо сам сотрудник может нелегитимно воспользоваться имеющимся доступом. На площадке Yandex for Security старший менеджер проектов ИБ Андрей Аникин и аналитик-разработчик Владислав Альчиков рассказали, какой подход они использовали для решения этой проблемы.
Служба информационной безопасности начала дополнительную настройку IDM-системы из-за целого ряда факторов. Во-первых, система не понимает, использует сотрудник доступ или нет — она просто выдаёт доступы, а их дальнейшее использование никак не контролируется. Другая проблема — IDM «из коробки» не имеет интеграций с другими сервисами.
«Например, у нас в компании все сотрудники должны проходить различные курсы по ИБ. IDM не знает, прошёл сотрудник какой-то курс или нет. А мы хотели бы на основе этого какие-то доступы сотруднику отзывать: “Вот, не прошёл ты курс — мы у тебя доступы заберём. Проходи курс!”» — пояснил Аникин на презентации.
Третья проблема — большой поток запросов. Это увеличивает нагрузку на службу ИБ «Яндекса», да и сотрудникам приходится дольше ждать, прежде чем получить доступ и приступить к работе. Поэтому в компании решили попытаться автоматизировать и упростить выдачу доступов.
Работать с IDM-системой начали с анализа. Он показал, что более 90% избыточных доступов в IDM-системе компании — это роли, которыми не пользовались длительное время. Сперва разработчики собрали все активные роли и логи их использования. Затем логи объединяют, чтобы разобраться в них — берут данные в рамках одного дня, чтобы анализ был в управляемых масштабах.
Базовый порог неактивности, который отслеживали разработчики, — 60 дней. Но была проблема с редкими ролями. Например, руководитель может иметь необходимость в доступе к дашборду, но пользуется им раз в полгода. Чтобы это решить, систему научили уведомлять владельца роли о том, чтобы он перенастроил доступы. Другая проблема — сезонные роли. Так, зимой в сервисе «Самокаты Яндекс Go» они могут не использоваться, но при этом их нельзя назвать избыточными. Поэтому систему научили улавливать пользование ролями: если все сотрудники перестали использовать роль, то порог неактивности увеличивается в 2–3 раза.
Помимо этого, в «Яндексе» использовали проверку полноты логов — IDM может посчитать, что роль не используется, и отозвать её, если логи неполные. Чтобы избежать этого, проверяют целостность данных. Также отслеживают аномалии: если в день отзываются 2–3 роли, а потом их число резко увеличивается, то проверяют целостность процессов — для этого заведены специальные алерты.
Внедрение, как утверждают в «Яндексе», позволило отозвать на старте 25% всех активных на тот момент ролей из-за избыточности.
