Регулярные сообщения о компрометации секретов формируют представление о том, что их защита неизбежно связана с множеством сложных и разрозненных мер. Так ли это на самом деле — разберём на примере типовых ошибок в управлении секретами.
- 1. Введение
- 2. Ошибка 1. Хранение ключей в коде
- 3. Ошибка 2. Некорректное управление жизненным циклом секрета
- 4. Ошибка 3. Передача секрета по незащищённому трафику
- 5. Ошибка 4. Избыточные привилегии
- 6. Ошибка 5. Отсутствие защиты от вредоносных программ
- 7. Ошибка 6. Использование ИИ-агентов
- 8. Ошибка 7. Человеческий фактор
- 9. Выводы
Введение
Секреты оказываются в руках злоумышленника гораздо чаще, чем это кажется на первый взгляд. Случайное включение токенов и ключей в репозиторий кода, хранение учётных данных в открытых контейнерах или неконтролируемая передача между сервисами создают прямые пути для компрометации. При масштабировании ИТ‑ландшафта количество таких секретов растёт на каждом этапе жизненного цикла приложения: в системах непрерывной интеграции и доставки, конфигурациях, средствах мониторинга и сторонних сервисах.
Фрагментированное хранение и отсутствие централизованного управления усугубляют ситуацию. На практике более 90 % скомпрометированных секретов остаются действительными минимум 5 дней, что даёт злоумышленнику достаточно времени для их эксплуатации. Ручное управление добавляет нагрузку на сотрудников: один специалист тратит в среднем 25 минут в день на операции с секретами, что повышает вероятность ошибок и человеческого фактора.
В итоге подобные просчёты в работе с секретами приводят к их компрометации и последующим потерям. Рассмотрим подробнее ошибки, которые уже привели к утечке секретов.
Ошибка 1. Хранение ключей в коде
Секрет встраивается в исходный код или конфигурационные файлы и сохраняется вместе с проектом. В таком случае он попадает в систему контроля версий и становится доступным через репозитории, логи или артефакты сборки. При недостаточной защите или ошибках в настройке доступа такие данные могут быть получены внешними лицами.
Пример ошибки: утечка секретного API-ключа в проекте xAI
В июле 2025 года сотрудник Department of Government Efficiency (DOGE) случайно опубликовал в публичном репозитории GitHub скрипт с закрытым API-ключом платформы xAI, который предоставлял доступ к 52 языковым моделям. О факте утечки впервые сообщила компания GitGuardian, которая отслеживает GitHub на наличие секретных токенов, учётных данных для баз данных и сертификатов. После уведомления репозиторий был удалён, однако ключ оставался действующим.
Чем опасна ошибка
Неотозванный секрет даёт злоумышленнику действующий ключ доступа к связанным сервисам. Это позволяет выполнять команды от имени системы, получать доступ к данным и изучать внутреннюю структуру используемых моделей. Проблема усугубляется тем, что удаление репозитория не делает такой секрет недействительным. Ключ продолжает работать и может использоваться дальше.
Как исправить
Необходимо отозвать секрет и заменить его новым, удалить репозиторий с ключом и проверить историю, очистив коммиты с секретом. Новый ключ следует хранить в хранилище секретов, не включая его в код или конфигурации. Также стоит проверить все скрипты и процессы, использующие старый ключ, чтобы исключить возможность его применения.
Ошибка 2. Некорректное управление жизненным циклом секрета
Жизненный цикл секрета — период действительности секрета, его пригодности для авторизации действий пользователя. Он начинается от момента его выпуска (создания его сервером и передачи запрашивающей стороне) и заканчивается в момент его аннулирования (истечения срока его действия или отзыва). В течение этого периода секрет используется для подтверждения личности пользователя и предоставления доступа к ресурсам в рамках заданных прав.
Корректно реализованный жизненный цикл включает контроль срока действия, возможность принудительного отзыва, а также ограничение области применения секрета. При нарушении этих условий он может сохранять активность вне предусмотренного периода или использоваться в сценариях, для которых он не предназначен.
Пример ошибки: одноразовые СМС-ссылки годами открывают доступ к личным данным
В ходе анализа 147 000 доступных ссылок исследователи выявили 701 конечную точку, предоставляющую доступ к персональным данным пользователей в 177 сервисах. Через такие URL становились доступны имена, номера телефонов, адреса, даты рождения, банковские реквизиты и иные чувствительные данные. Эти ссылки оставались активными и на момент проверки. Более половины из них имели возраст от одного до двух лет, 46 % — свыше двух лет, отдельные экземпляры датировались 2019 годом.
Чем опасна ошибка
Такие токены могут повторно применяться для получения доступа к ресурсам без необходимости прохождения повторной аутентификации. Это увеличивает поверхность атаки и усложняет контроль за актуальными точками входа в систему.
Дополнительно затрудняется управление доступом: становится сложно определить, какие токены ещё должны быть активны, а какие — аннулированы.
Как исправить
В этом случае можно использовать динамические секреты, при которых токены генерируются по запросу, имеют короткий срок жизни и автоматически становятся недействительными после завершения операции. Это исключит повторное использование и упростит управление их жизненным циклом.
Ошибка 3. Передача секрета по незащищённому трафику
Если секрет передаётся по незащищённому каналу связи без применения криптографической защиты, он становится доступен для перехвата в процессе передачи. Ключи шифрования, токены доступа и учётные данные могут быть извлечены из сетевого трафика в момент их обмена между компонентами системы.
Пример ошибки: Chrome-аддоны AVG и Microsoft передают данные по HTTP
Исследователи из Symantec обнаружили, что десятки расширений передают данные через незащищённый HTTP. В этом случае сетевые запросы содержат идентификаторы устройства, параметры использования, техническую информацию о браузере и другие чувствительные данные, которые передаются в открытом виде.
Чем опасна ошибка
Перехват такого трафика возможен на любом участке сети между клиентом и сервером, включая публичные Wi-Fi сети. В рамках атаки посредника (AitM) злоумышленник может не только просматривать передаваемые данные, но и модифицировать их в процессе передачи.
Как исправить
Передача данных должна выполняться по защищённому протоколу HTTPS с использованием современных версий TLS (Transport Layer Security).
Ошибка 4. Избыточные привилегии
Ключевая цель управления секретами: обеспечить пользователей ровно тем набором полномочий, который требуется для выполнения их обязанностей. Нарушение этого принципа приводит к формированию избыточных привилегий.
Пример ошибки: взлом Rockstar Games
Злоумышленники не взламывали систему безопасности Snowflake, а использовали токены, извлечённые из Anodot, чтобы действовать от имени легитимных учётных записей. При корректно реализованной модели разграничения доступа такие учётные записи должны были иметь ограниченные права.
Получив доступ, хакеры беспрепятственно извлекли данные. Среди них, вероятно, не было паролей или других данных, связанных с активной разработкой. Тем не менее в их распоряжении оказалась внутренняя корпоративная информация, которую Rockstar Games не планировала разглашать.
Чем опасна ошибка
В этом случае пользователи или сервисы получают доступ, выходящий за рамки их реальных задач. При компрометации такой учётной записи злоумышленник сразу получает расширенные возможности внутри системы: доступ к данным, функциям и сервисам, которые в норме должны быть ограничены. Это упрощает выполнение несанкционированных действий и ускоряет развитие атаки.
Избыточные привилегии также снижают эффективность разграничения доступа. Внутренние ограничения фактически перестают работать, так как доступ уже предоставлен заранее и не требует дополнительного обхода защитных механизмов.
В результате возрастает риск утечек других секретов, несанкционированных изменений и скрытого присутствия злоумышленника в инфраструктуре. Чем шире изначально выданные права, тем больше масштаб возможного ущерба.
Как исправить
После внедрения решения для управления секретами следующий шаг — ограничение доступа к ним только авторизованными пользователями и системами. В рамках такой модели каждая роль содержит строго определённый набор разрешений, необходимых для выполнения своих функций.
Ошибка 5. Отсутствие защиты от вредоносных программ
Защита от вредоносных программ — это совокупность технических и организационных мер, направленных на предотвращение проникновения, распространения и выполнения вредоносного кода в системе, а также на выявление и блокирование уже запущенных угроз.
Пример ошибки: взломщик секретов Android-троян Falcon
Falcon — вредоносное приложение, которое функционирует как «отмычка», предоставляющая злоумышленникам доступ к учётным записям пользователей в самых разных сервисах, включая банковские приложения. Оно маскируется под официальные приложения крупных банков, государственных органов, платёжных и VPN-сервисов, изменяя название и интерфейс, чтобы вводить пользователя в заблуждение.
Приложение нацелено на кражу данных более чем из 30 приложений российских банков и инвестиционных фондов, государственных сервисов, операторов сотовой связи, маркетплейсов, почтовых и «облачных» сервисов, YouTube, VPN и др.
Для упрощения своей работы Falcon автоматически получает необходимые разрешения на устройстве, имитируя действия пользователя: приложение находит соответствующие элементы интерфейса и подтверждает запросы, что происходит настолько быстро, что неопытный пользователь вряд ли заметит что-либо подозрительное.
Рисунок 1. Код автоматического нажатия на «Разрешить» при запросе разрешения. Источник: Эфшесть/F6
Чем опасна ошибка
По оценкам экспертов, число скомпрометированных карт уже исчисляется тысячами, и без дополнительных мер защиты масштабы атак могут существенно возрасти.
Наличие антивируса на устройстве не обеспечивает полной защиты. Разработчики вредоносной программы обходят механизмы антифрода, используя смену названий пакетов и высокий уровень обфускации, что позволяет трояну оставаться активным и получать доступ к данным пользователей.
Как исправить
Защита требует участия двух сторон: сервиса и пользователя.
Необходимо учитывать контекст работы приложения, включая географическое расположение и поведенческие особенности пользователей, чтобы своевременно выявлять аномалии. При использовании одноразовых паролей через СМС стоит проверять, какое приложение получает сообщение, и блокировать попытки перехвата. На стороне устройства нужно внедрять средства, способные обнаруживать сторонние вредоносные программы и контролировать доступ приложений к критическим службам.
Эффективна интеграция антифрод-систем, которые анализируют сессии, поведение пользователей и операции, позволяя выявлять подозрительную активность как отправителей, так и получателей платежей.
Помимо технических мер, одним из ключевых способов снизить риск заражения остаётся установка приложений только из официальных источников, внимательное отношение к запрашиваемым разрешениям и отказ от предоставления доступа к службам Accessibility.
Ошибка 6. Использование ИИ-агентов
Темпы внедрения ИИ-агентов в корпоративные контуры существенно опережают формирование регуляторных и внутренних требований к их эксплуатации. В действующих нормативных моделях такие системы зачастую не выделяются в отдельный класс и рассматриваются либо как прикладное программное обеспечение, либо как инструменты поддержки принятия решений.
Агенты интегрируются в ИТ-системы и используют общие платформы, облачные сервисы и сторонние библиотеки. В процессе работы им предоставляются токены доступа и API, ключи для взаимодействия с почтой, CRM, ERP, внутренними базами данных и внешними сервисами. Злоумышленники разработали целый арсенал техник для извлечения чужих данных из обученных моделей: от инъекций промптов до целенаправленного вытягивания секретов.
Рисунок 2. Структура управления идентичностями с учётом внедрения ИИ-агентов. Источник: AI Frontiers
Пример ошибки: ИИ-помощник Claude провёл для шпионов 30 атак
При помощи Claude было атаковано около 30 целей, в нескольких случаях — успешно. Задачи для ИИ формировались как отдельные, ограниченные по контексту задания с аккуратной формулировкой запросов, без раскрытия общей цели, которая могла бы выдать плохие намерения. Операторы вмешивались 4–6 раз, когда нужно было принять стратегическое решение по итогам выполнения задач агентским Claude.
Исполнители последовательно проводили анализ целевой инфраструктуры, определяли возможные точки входа, искали уязвимости, разрабатывали способы их эксплуатации. Также они выполняли компрометацию учётных записей с проверкой их работоспособности, собирали конфиденциальные данные.
Чем опасна ошибка
Компрометация сервисного аккаунта ИИ-агента эквивалентна получению полного доступа к связанным системам. Дополнительный риск связан с тем, что агент действует автономно и способен инициировать цепочки запросов к связанным системам. Это позволяет не только извлекать данные, но и изменять их, а также распространять доступ дальше по интеграциям, где используется тот же набор учётных данных или токенов.
Как исправить
Сервисные аккаунты ИИ-агентов не должны обладать универсальными правами на доступ. Все обращения к защищённым ресурсам должны фиксироваться в журнале событий для последующего анализа и контроля.
Ошибка 7. Человеческий фактор
Высокая нагрузка и многозадачность при работе с доступами и настройками повышают риск ошибок при обращении с секретами: возможны некорректное назначение прав, использование небезопасных способов хранения, передача данных по незащищённым каналам и их непреднамеренное раскрытие. В таких условиях снижается точность контроля за операциями с конфиденциальной информацией, что увеличивает вероятность её компрометации.
Пример ошибки: отсутствие автоматизации рутинных задач
На одном из эфиров AM Live Александр Гусев, технический директор HASPBOX, поделился интересным кейсом из своей практики. В одной крупной организации внедрили новое решение. По регламенту местные администраторы ежемесячно меняли пароли учётных записей для доступа к базам данных. При сотнях экземпляров обновление выполнялось вручную для каждого из них.
Чем опасна ошибка
Пропущенная или некорректная ротация приводит к сохранению устаревших учётных данных, которые могут быть использованы для несанкционированного доступа к базам данных. При большом количестве экземпляров такие риски накапливаются, а единичная ошибка способна привести к компрометации конфиденциальной информации и нарушению работы сервисов.
Как исправить
Для снижения риска ошибок при ручной смене паролей необходимо внедрить менеджер паролей. После первоначальной настройки автоматической ротации учётных данных система сама будет обновлять пароли в заданные сроки, исключая необходимость ручного вмешательства. Администратору останется только контролировать события и отслеживать корректность выполнения процессов, что существенно снижает вероятность пропусков и случайного раскрытия секретов.
Выводы
Перечисленные примеры ошибок сводятся к нарушению базовых принципов управления секретами в распределённых системах. Основная причина: отсутствие замкнутого жизненного цикла и единой точки контроля, что приводит к фрагментации процессов хранения и использования конфиденциальных данных. В результате секреты либо остаются долгое время активными, не выводятся из эксплуатации, либо используются за пределами предусмотренного контура безопасности. Ситуация усугубляется избыточными правами доступа, когда один и тот же секрет становится доступен большему числу компонентов, чем требуется.
Отсутствие учёта не позволяет определить текущее состояние секретов, реальные области их использования и взаимосвязи между системами. Это снижает уровень управляемости и усложняет как оперативный контроль, так и последующее расследование инцидентов.
Переход к централизованному управлению секретами устранит разрыв между этими этапами за счёт единой точки контроля. В такой модели пароли, ключи API, сертификаты и токены будут находиться в управляемом хранилище, а доступ к ним, их ротация и отзыв — реализоваться через единые механизмы политики безопасности и аудита. Но не стоит забывать, что внедрение таких систем требует сбалансированного подхода, включающего архитектурное проектирование, автоматизацию рутинных операций и постепенное вовлечение пользователей в новые процессы.
