Количество корпоративных учетных записей, которые принадлежат не людям, а программам и сервисам, растет вместе с автоматизацией, распространением облачных решений и внедрением ИИ. По данным исследования Palo Alto Networks 2026 Identity Security Landscape, машинных идентификаторов в компаниях уже в 109 раз больше, чем человеческих. Почему такие доступы становятся новой зоной риска для бизнеса и как их контролировать, рассказал Александр Гусев, технический директор HASPBOX.
Такие учетные записи нужны, чтобы корпоративные системы могли взаимодействовать друг с другом без участия человека. Например, интернет-магазин автоматически проверяет остатки товара на складе, бухгалтерская программа передает данные в банковский сервис, а система резервного копирования получает доступ к корпоративным файлам. Во всех этих случаях программа использует собственные учетные данные — пароль, цифровой ключ или токен.
«Представьте, что в офисе есть не только сотрудники с пропусками, но и курьерская служба, которой выдали ключ от склада. Машинный аккаунт — по сути такой же пропуск, только получает его не человек, а программа. Если одна система должна получить данные из другой, ей нужно подтвердить, что у нее есть на это право».
Александр Гусев, технический директор HASPBOX
В отличие от сотрудника у программы нет привычного жизненного цикла учетной записи. Ключ может годами храниться в настройках, конфигурационном файле или коде, а менять его бывает сложно из-за риска нарушить работу интеграции. При этом права у таких аккаунтов иногда оказываются шире, чем необходимо для конкретной задачи.
«Если сервису достаточно читать список товаров, но ему когда-то для удобства предоставили административные права, при утечке ключа злоумышленник получит гораздо более широкий доступ к системе. Поэтому важно контролировать не только сам факт существования машинного аккаунта, но и объем его прав», — отмечает эксперт.
Количество таких доступов увеличивается по мере того, как компании связывают между собой все больше сервисов: CRM с почтой, сайт со складом, бухгалтерию с банком, мессенджеры с внутренними системами. Дополнительным фактором стали облачные решения, боты и ИИ-инструменты. Чтобы ИИ-ассистент мог найти документ, ответить клиенту или создать заявку, ему также необходим доступ к корпоративным системам.
Основные риски связаны с долгоживущими и забытыми учетными данными. За несколько лет ключ может сохраниться в переписке, документации или коде, остаться у подрядчика или бывшего сотрудника. Бывает и так, что сервис уже отключен, а созданный для него аккаунт продолжает работать, и за его активностью никто не следит.
«Такой доступ особенно опасен тем, что его использование долго может не вызывать подозрений. Для корпоративной системы запросы продолжают приходить от легитимной учетной записи, поэтому первое время атака может выглядеть как обычная работа программы», — говорит Гусев.
Проблему усложняет то, что машинные аккаунты часто создаются децентрализованно — администратором, разработчиком или подрядчиком под конкретную задачу. Со временем ответственный может уйти, сервис перестают использовать, а доступ остается. В результате компания не всегда может быстро ответить, сколько таких учетных записей существует, зачем они нужны и кто за них отвечает.
Для базового контроля, по словам эксперта, необязательно начинать с перестройки всей ИТ-инфраструктуры. Сначала стоит провести инвентаризацию: определить, какие машинные аккаунты существуют, к каким системам они имеют доступ и какими правами обладают. У каждого такого аккаунта должен быть конкретный владелец, который может подтвердить необходимость доступа и его объем.
Следующий принцип — минимально необходимые права. Если программе достаточно читать данные, ей не нужны возможности их изменять или удалять. Критичные доступы к финансам, персональным данным или административным функциям необходимо регулярно пересматривать, а пароли, токены и ключи — хранить в защищенных системах, а не в переписках, коде или обычных файлах.
Пересматривать или отзывать доступ стоит после отключения сервиса, завершения проекта подрядчика или ухода сотрудника, который знал секрет. Поводом для реакции также должны стать попадание ключа в публичный репозиторий или необычная активность аккаунта.
«К программам в этом смысле стоит относиться примерно так же, как к сотрудникам: у каждой должен быть ответственный, понятная задача, ограниченные права и момент, когда доступ обязательно пересматривается. Когда таких аккаунтов становятся сотни и тысячи, без автоматизации делать это сложно. Но начинать в любом случае нужно с инвентаризации и ответственности».
Александр Гусев, технический директор HASPBOX