Почему корпоративного менеджера паролей для защиты бизнеса уже недостаточно. Общество. Вести ПК

Корпоративные менеджеры паролей хорошо решают задачу пользовательских доступов: помогают сотрудникам хранить сложные пароли, не передавать их в открытом виде и безопасно делиться учетными данными.

Однако современная ИТ-инфраструктура состоит не только из людей, отметил в интервью радио Sputnik эксперт Александр Гусев.

По его словам, значительная часть взаимодействий происходит автоматически – между приложениями, базами данных, облачными сервисами, CI/CD-системами и микросервисами. Для этого используются API-ключи, токены, SSH-ключи, сертификаты и другие машинные секреты, отмечает технический директор HASPBOX Александр Гусев.

"Часто от компаний можно услышать: "У нас все под контролем, мы используем корпоративный менеджер паролей". Но затем разработчик случайно оставляет действующий токен от базы данных в репозитории, и выясняется, что обычный Password Manager здесь вообще не помог. Он создавался прежде всего для людей, а не для машин", – объяснил Александр Гусев.

Главное отличие машинных секретов, по словам эксперта, в том, что они могут одновременно находиться в коде, конфигурациях, переменных окружения, настройках CI/CD и старых скриптах. При этом у такого секрета часто нет конкретного владельца, который заметит проблему и быстро сменит доступ, уточнил он.

"Если компрометация пользовательского пароля обычно затрагивает одну учетную запись, утечка инфраструктурного секрета может открыть доступ сразу к нескольким системам. Например, скомпрометированный токен CI/CD с широкими правами потенциально позволяет вмешаться в процесс развертывания и получить доступ к продуктовой инфраструктуре. При этом для системы злоумышленник может выглядеть как легитимный сервис, поскольку использует действующий ключ", – рассказал Гусев.

По его мнению, проблема машинных секретов в том, что они часто живут годами.

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

По словам Александра Гусева, необходимость Secret Management определяется не размером компании, а сложностью ее ИТ-инфраструктуры. Небольшая технологическая компания с десятками микросервисов и интеграций может иметь больше машинных секретов, чем крупный бизнес с относительно статичными системами.

"Один из простых признаков – компания не может быстро ответить, сколько у нее действующих API-ключей и токенов, где они используются и кто способен их оперативно отозвать. В таком случае начинать нужно с инвентаризации: проверить код, конфигурации, переменные окружения, CI/CD и облачную инфраструктуру, а затем определить владельцев и зависимости найденных секретов", – уточнил Гусев.

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

Ответственность также должна быть распределена заранее: ИБ определяет политики и контролирует их выполнение, ИТ и DevOps отвечают за техническую реализацию, а владельцы бизнес-систем – за то, кому и зачем нужен конкретный доступ.

"Переходить на Secret Management лучше постепенно. Основной страх бизнеса – заменить старый ключ и случайно остановить интеграцию, которую никто уже полностью не понимает. Поэтому сначала нужно определить зависимости, затем переносить сервисы поэтапно и только после проверки автоматизировать ротацию. Цель здесь не просто собрать все ключи в одном сейфе, а сделать их использование управляемым и прозрачным", – заключил Александр Гусев.