Почему скомпрометированные учетные данные остаются активными после обнаружения?

Обнаружение утечки учетных данных — это только половина дела. Настоящая проблема заключается в их своевременной деактивации. Тревожная тенденция последних лет показывает, что скомпрометированные учетные данные зачастую остаются действительными долгое время после их обнаружения, создавая значительные риски безопасности для организаций.
Почему скомпрометированные учетные данные остаются активными после обнаружения?
Изображение носит иллюстративный характер

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

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

Технические сложности также препятствуют быстрому реагированию на утечки. Жестко закодированные секреты, распространенные по многочисленным кодовым базам, создают трудности для их обнаружения и замены. Ротация секретных ключей требует координированного обновления во всех сервисах и системах, что может вызвать опасения относительно влияния на производственную среду. Устаревшие системы, не поддерживающие современные подходы к управлению секретами, создают дополнительные барьеры для эффективного реагирования.

Анализ данных за 2022-2024 годы выявил наиболее уязвимые сервисы. MongoDB возглавляет список с учетными данными, позволяющими извлекать или повреждать данные. Следом идут ключи для облачных платформ Google Cloud, AWS и Tencent Cloud, предоставляющие доступ к инфраструктуре, коду и клиентским данным. Учетные данные для MySQL и PostgreSQL также часто обнаруживаются в публичном коде. Важно отметить, что речь идет о реальных производственных учетных данных, а не тестовых.

Тенденции в области утечек за последние годы показывают значительные изменения. Доля облачных учетных данных среди активных скомпрометированных секретов выросла с примерно 10% в 2023 году до 16% в 2024 году, что отражает растущее внедрение облачной инфраструктуры и SaaS-решений. В то же время, доля учетных данных баз данных снизилась с более чем 13% нерешенных проблем в 2023 году до менее 7% в 2024 году.

Для MongoDB рекомендуется быстрая ротация скомпрометированных учетных данных, настройка белого списка IP-адресов, включение аудита логов, переход на динамические секреты и использование MongoDB Atlas API для программной ротации паролей.

В случае с Google Cloud ключами необходимо немедленно отзывать скомпрометированные ключи и переходить на методы аутентификации с коротким сроком действия, такие как Workload Identity Federation, прямое прикрепление сервисных аккаунтов к ресурсам и реализация имперсонации сервисных аккаунтов. Также важно обеспечить регулярную ротацию ключей и применять принципы минимальных привилегий.

Для учетных данных AWS IAM рекомендуется немедленная ротация при обнаружении утечки, отказ от долгоживущих ключей доступа пользователей в пользу ролей IAM и AWS STS для временных учетных данных, использование IAM Roles Anywhere для внешних систем, аудит политик доступа с помощью AWS IAM Access Analyzer и включение AWS CloudTrail для комплексного ведения журналов.

Организациям необходимо уделять приоритетное внимание быстрому реагированию на утечки, переходить к архитектурам, минимизирующим влияние компрометации учетных данных, внедрять надлежащие практики управления секретами и отказываться от долгоживущих учетных данных в пользу временных.


Новое на сайте

21008ИИ-агент в чужой сессии: кто отвечает за его действия 21007Какие версии Zoom Workplace для Windows уязвимы для удалённого повышения привилегий? 21006Как две уязвимости в Xen Orchestra открыли путь к захвату XCP-ng? 21005Поддельные сайты ИИ превращают опечатки в ловушки 21004Как обновление Node.js закрывает уязвимости HTTP/2 и TLS? 21003Почему Claude Fable5.2 обошёл GPT-6 Cyber в испытании многоэтапных кибератак? 21002Две уязвимости Red Hat Quay открыли доступ к чужим образам 21001После сигнала: почему для расследования нужны подробные сетевые данные 21000Критическая ошибка PTC Windchill и FlexPLM открывает путь к удалённому выполнению кода 20999Слепые зоны идентичности: чего не хватает SOC при расследовании атак 20998Обновления Apple закрыли лазейки в групповых чатах и Bluetooth 20997Уязвимость iPhone может открыть приложениям доступ к чужим файлам 20996Что раскрыла расширенная проверка утечки Fireworks AI? 20995Уязвимость в Apache HTTP/2: удалённое выполнение кода без входа 20994Как защитить виртуальные машины Google Cloud от утечек на AMD Turin?
Ссылка