Почему корпоративного менеджера паролей для защиты бизнеса уже недостаточно — Радио Sputnik, 02.09.2026
Работа за компьютером. Архивное фото.
В России защита персональных данных станет надежнееПо его словам, значительная часть взаимодействий происходит автоматически – между приложениями, базами данных, облачными сервисами, CI/CD-системами и микросервисами. Для этого используются API-ключи, токены, SSH-ключи, сертификаты и другие машинные секреты, отмечает технический директор HASPBOX Александр Гусев.«»Часто от компаний можно услышать: «У нас все под контролем, мы используем корпоративный менеджер паролей». Но затем разработчик случайно оставляет действующий токен от базы данных в репозитории, и выясняется, что обычный Password Manager здесь вообще не помог. Он создавался прежде всего для людей, а не для машин», – объяснил Александр Гусев.Главное отличие машинных секретов, по словам эксперта, в том, что они могут одновременно находиться в коде, конфигурациях, переменных окружения, настройках CI/CD и старых скриптах. При этом у такого секрета часто нет конкретного владельца, который заметит проблему и быстро сменит доступ, уточнил он.«»Если компрометация пользовательского пароля обычно затрагивает одну учетную запись, утечка инфраструктурного секрета может открыть доступ сразу к нескольким системам. Например, скомпрометированный токен CI/CD с широкими правами потенциально позволяет вмешаться в процесс развертывания и получить доступ к продуктовой инфраструктуре. При этом для системы злоумышленник может выглядеть как легитимный сервис, поскольку использует действующий ключ», – рассказал Гусев.По его мнению, проблема машинных секретов в том, что они часто живут годами.«»Один ключ может быть скопирован в несколько систем, а человек, который когда-то его создал, уже давно не работает в компании. Если организация не знает, где находится конкретный секрет, кто его использует и что перестанет работать после его отзыва, значит, фактически она этим доступом не управляет», – считает эксперт.По словам Александра Гусева, необходимость Secret Management определяется не размером компании, а сложностью ее ИТ-инфраструктуры. Небольшая технологическая компания с десятками микросервисов и интеграций может иметь больше машинных секретов, чем крупный бизнес с относительно статичными системами.«»Один из простых признаков – компания не может быстро ответить, сколько у нее действующих API-ключей и токенов, где они используются и кто способен их оперативно отозвать. В таком случае начинать нужно с инвентаризации: проверить код, конфигурации, переменные окружения, CI/CD и облачную инфраструктуру, а затем определить владельцев и зависимости найденных секретов», – уточнил Гусев.При этом простого защищенного хранилища недостаточно. Secret Management предполагает управление всем жизненным циклом доступа: выдачей, сроком действия, ротацией, отзывом и аудитом использования. Сотрудник или сервис должен получать только необходимые права и только на необходимое время, подчеркнул эксперт.Ответственность также должна быть распределена заранее: ИБ определяет политики и контролирует их выполнение, ИТ и DevOps отвечают за техническую реализацию, а владельцы бизнес-систем – за то, кому и зачем нужен конкретный доступ.«»Переходить на Secret Management лучше постепенно. Основной страх бизнеса – заменить старый ключ и случайно остановить интеграцию, которую никто уже полностью не понимает. Поэтому сначала нужно определить зависимости, затем переносить сервисы поэтапно и только после проверки автоматизировать ротацию. Цель здесь не просто собрать все ключи в одном сейфе, а сделать их использование управляемым и прозрачным», – заключил Александр Гусев.Радио Sputnik в MAX. Подписывайтесь!
👉🏻 https://max.ru/radio_sputnik
