{"schema_version":"1.0","service":"Publicasta","type":"article","id":391,"slug":"leaked_aws_keys_quarantine_cloud_security_checklist_2026","title":"Утёкший AWS-ключ — это действующий доступ, пока его не удалили","excerpt":"Truffle Security перепроверила тысячи AWS-ключей, которые уже появлялись в публичных артефактах. Главный урок не в том, что секреты утекают, а в том, что многие из них годами остаются рабочими, включая root и AdministratorAccess.","language":"ru","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ru","image":{"url":"https://publicasta.com/storage/projects/9/pages/391/2026/08/ea74d13c-c357-428a-a970-c2bec00446cc.webp","alt":"Абстрактная облачная консоль с утёкшим ключом, карантинной лентой и списком ротации"},"publisher":{"id":9,"slug":"cybersecurity","name":"Кибербезопасность без паники","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-08-23T17:27:43+00:00","updated_at":"2026-08-23T17:27:43+00:00","content_markdown":"Утёкший облачный ключ — это не событие в прошлом. Это действующий вход в аккаунт до тех пор, пока его не ротировали, не удалили и не проверили, куда он мог вести. Именно это делает исследование Truffle Security от августа 2026 года важным: опасной оказалась не только сама публикация AWS credentials, а их долгая жизнь после того, как секрет уже перестал быть секретом.\n\n ![Абстрактная облачная консоль с утёкшим ключом, карантинной лентой и списком ротации](https://publicasta.com/storage/projects/9/pages/391/2026/08/ea74d13c-c357-428a-a970-c2bec00446cc.webp)\n\n Truffle Security сообщила, что собрала 431 875 подтверждённых находок AWS-секретов, свела их к 64 024 уникальным access keys в 50 654 аккаунтах и повторно проверила 10 616 полных пар ключей, найденных публично с августа 2022 по август 2026 года. 88% всё ещё проходили аутентификацию. Среди 9 308 активных ключей исследователи выделили 817 корпоративных, а 768 из них давали полный контроль над AWS-аккаунтом компании: 526 root keys и 242 IAM users с AdministratorAccess.\n\n BleepingComputer, The Register, TNW и другие издания быстро подхватили тему. Corey Quinn в The Register добавил важный практический конфликт: AWSCompromisedKeyQuarantineV3 может ограничить часть действий, когда AWS видит публично раскрытый credential, но это не лечение. AWS описывает policy как способ снизить потенциальный fraud-related ущерб without impacting existing resources. Но если credential всё ещё authenticate, организация не должна считать инцидент закрытым.\n\n Это хороший сюжет для Cybersecurity Without Panic, потому что вывод скучный и полезный. Root access keys почти никогда не должны существовать. Долгоживущие IAM access keys должны иметь владельца, срок жизни и план ротации. Секрет, попавший в Git history, Docker image, CI log, notebook или датасет, надо считать опубликованным навсегда. А quarantine policy — это сигнал начать incident response, а не повод расслабиться.\n\n ## Что именно нашли\n\n Большое число 431 875 не должно сбивать с толку: сканеры часто видят повторения в форках, зеркалах, логах, образах и датасетах. Важнее другое: 64 024 уникальных AWS access keys and 10 616 complete key pairs, которые Truffle Security смогла перепроверить 10 августа 2026 года. Из них 9 308 всё ещё работали.\n\n Корпоративная часть меньше, но опаснее. 817 активных ключей были связаны с бизнесом, и 768 давали full administrative control. Это либо root keys, либо IAM users с AdministratorAccess. Отдельно указаны 130 live root keys на organization management accounts. Такой ключ — не просто забытый секрет разработчика, а потенциальный master key для облачной организации.\n\n Возраст ключей делает картину хуже. Median live leaked key age составил 1 831 день. То есть многие credentials были публичными годами и всё равно принимались AWS. Truffle Security также написала, что только у 13,7% ключей, где можно было перечислить access keys, рядом был более новый ключ. Это похоже не на аккуратную ротацию, а на оставленный в эксплуатации старый доступ.\n\n Hugging Face в исследовании фигурирует как крупный источник exposed keys across public datasets. Это не надо подавать как новый взлом Hugging Face. Более точная формулировка: публичные ML-датасеты, notebooks, model repositories and training corpora унаследовали старую проблему software repositories — люди загружают код, логи и артефакты, где иногда остаются credentials.\n\n ## Почему root key опаснее обычного секрета\n\n IAM user access key может быть очень опасен. Root access key опаснее. Root user представляет сам AWS account, а документация AWS рекомендует защищать root credentials, не использовать root для повседневной работы и переходить на IAM Identity Center, roles and temporary credentials.\n\n Причина в scope. Обычную IAM identity можно ограничить permissions, conditions, boundaries and service control policies. Root стоит выше значительной части этой структуры. Если утёк root key, проблема касается billing, account settings, recovery paths and sometimes organization management account. Поэтому 526 живых corporate root keys — не просто плохая гигиена, а провал управления.\n\n Root keys ещё и переживают владельцев. Стартапы меняют инженеров, подрядчики уходят, личные аккаунты становятся корпоративными, старая автоматизация продолжает работать на одном ключе, который “когда-то помог”. Никто не хочет его трогать, потому что удаление может сломать production. Но именно credential без владельца остаётся credential, которым может воспользоваться злоумышленник.\n\n Зрелая cloud-программа должна отвечать на три вопроса: есть ли root access keys, кто их утвердил и когда они будут удалены? Ответ “не знаем” означает отсутствие контроля.\n\n ## Почему удалить строку из репозитория недостаточно\n\n Главный урок secret scanning старый, но его всё ещё пропускают: если credential попал в публичный артефакт, считайте его скопированным. Удаление из последнего Git commit не удаляет Git history. Закрытие репозитория не удаляет forks, mirrors, package caches, Docker layers, CI logs, notebooks, search indexes or datasets.\n\n Поэтому утёкший AWS key надо рассматривать как опубликованный пароль. Безопасный ответ: rotate or delete credential, расследовать использование, проверить зависимые workloads. Если это root или AdministratorAccess, нужны CloudTrail review, billing checks, secret inventory and search for persistence or privilege escalation.\n\n Разработчики часто делают неверный вывод из secret-scanning alert: “я удалил строку”. Правильный вывод: “строка раскрыла credential, который теперь надо заменить”. Это не тонкость языка, а разница между косметической правкой и устранением доступа.\n\n Docker images and ML datasets усложняют задачу. Ключ может лежать в старом image layer, даже если финальный файл чистый. Он может быть в output cell ноутбука, debug log, model-card asset, benchmark corpus or ZIP. Поэтому современное управление секретами должно сканировать не только репозитории.\n\n ## Что означает AWS quarantine\n\n AWSCompromisedKeyQuarantineV3 — управляемая policy AWS. Официальная документация говорит, что она применяется к IAM user credentials, которые compromised or exposed publicly, и запрещает часть действий, чтобы снизить fraud-related damage while not impacting existing resources.\n\n Ключевая фраза — “not impacting existing resources”. Это harm reduction, не remediation. Quarantined key означает: credential плохой и требует реакции. Это не сертификат безопасности аккаунта. Если policy специально не ломает существующие ресурсы, значит часть существующих путей может продолжать работать.\n\n Corey Quinn в The Register критикует именно остаточный риск: database operations, systems-management sessions, role assumptions, audit-log disruption, messaging abuse, secret reads, backups and infrastructure changes. Не нужно превращать это в инструкцию для атаки. Для защитника достаточно вывода: quarantine is a temporary guardrail, not incident closure.\n\n Здесь есть реальный trade-off. Если AWS автоматически выключит каждый найденный публичный key, она может сломать клиентский production. Если оставит его authenticating, клиент избежит outage, но сохранит exposure. Поэтому у организаций должен быть собственный playbook, чтобы удаление ключей не зависело от осторожности провайдера.\n\n ## Что проверить сегодня\n\n Начните с root. В каждом AWS account проверьте, существуют ли root access keys. Если существуют, выясните owner, business reason, last used and removal date. Для большинства компаний целевое состояние — no root access keys. Root user должен быть защищён MFA и использоваться только для задач, где root действительно нужен.\n\n Сделайте inventory IAM access keys. Отсортируйте по age, last-used date, owner, workload and permission level. Ключи с AdministratorAccess, wildcard permissions, no owner, no recent use or no rotation date — high priority. Ключ старше команды, которая за него отвечает, — не стабильная зависимость, а unmanaged access.\n\n Отдельно ищите AWSCompromisedKeyQuarantine policy attachments. Если AWS поставила quarantine, treat it as incident signal. Найдите, где живёт credential, ротируйте его, удалите старый, проверьте CloudTrail, billing, budget anomalies and role assumption paths.\n\n Сканируйте не только код. Нужны Git history, forks, public registries, container images, build logs, CI variables, notebooks, support bundles, public datasets and model repositories. Исследование Truffle Security показывает, что секреты всё чаще живут в data and ML artifacts.\n\n Заменяйте static credentials. Для CI/CD используйте OIDC federation и short-lived role assumption вместо long-lived AWS keys in pipeline variables. Для людей — IAM Identity Center or federated access. Для workloads — instance, task, pod or service roles with scoped permissions. Static keys иногда остаются в legacy, но это должны быть исключения с expiration, monitoring and owner.\n\n ## Как исправлять без поломки production\n\n Причина, по которой утёкшие ключи живут годами, часто проста: страх outage. Он рационален. Резкое удаление неизвестного key может сломать build system, billing exporter, backup job, data pipeline or old service. Но ответ не “оставить навсегда”, а rotation with evidence.\n\n Сначала определите principal and last-used services. CloudTrail, IAM last-accessed data, application logs and cost anomalies помогут понять назначение ключа. Затем найдите владельца, создайте replacement path с меньшими permissions, разверните замену with monitoring and delete the old key. Если удалить немедленно нельзя, нужна time-boxed exception with expiry date, named owner and compensating controls.\n\n Для root и AdministratorAccess план должен быть жёстче. Считайте, что ключ мог использовать кто-то ещё. Проверьте recent API activity, secret access, role assumptions, security-group changes, bucket policies, backup operations, IAM changes and unusual spend. Включите budget alerts and cost anomaly detection: отсутствие финансовых alarm делает злоупотребление видимым слишком поздно.\n\n Цель — сделать rotation routine before emergency. Команда, которая умеет заменять credentials, отвечает на leak за часы. Команда, которая не знает владельцев, неделями ведёт переговоры с compromised key.\n\n ## Что стоит улучшить провайдерам и инструментам\n\n Shared responsibility остаётся. Клиенты не должны держать leaked keys живыми. Но ecosystem может сделать правильное действие проще: заметный quarantine status, safe-disable workflows with rollback, organization-wide exposed-credential reports, better root/static key defaults.\n\n Secret-scanning tools должны помогать с ownership mapping. “Key leaked” полезно. “This key belongs to production billing exporter, last used yesterday, has AdministratorAccess, appears in this Docker layer and has no replacement” — полезнее в десять раз. Работа не только в detection, а в сокращении time to rotation.\n\n Platform teams тоже отвечают за defaults. Если безопасный путь сложнее, чем скопировать static key в CI variable, static keys будут побеждать. Нужны готовые OIDC templates, approved role patterns, short-lived local credentials, pre-commit scanning and blocking rules before secrets enter history.\n\n ## Спокойный вывод\n\n Исследование не означает, что every AWS account compromised. Оно не означает, что AWS quarantine useless. И оно не означает, что надо удалять random keys без понимания workloads. Паника ломает production; отрицание создаёт breaches.\n\n Соразмерный ответ: считать public credential compromised, удалять root keys, заменять long-lived IAM keys roles and federation, сканировать реальные артефакты, реагировать на quarantine attachments, тренировать rotation and keep billing alarms on.\n\n Самая неприятная часть — облачный доступ часто проваливается тихо. Ключ утёк, scanner нашёл, provider ограничил часть действий, команда убрала строку из репозитория, и все пошли дальше. Но credential всё ещё authenticates. Это и надо исправить: ownership, inventory, short-lived credentials and discipline to treat leaked key as active access until it is gone.","available_translations":[{"language":"ar","title":"مفتاح AWS المسرّب يبقى وصولاً فعلياً حتى يُدار ويُحذف","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ar"},{"language":"de","title":"Ein geleakter AWS-Schlüssel bleibt Zugriff, bis er rotiert und gelöscht ist","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=de","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=de","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=de"},{"language":"en","title":"Leaked AWS keys are still working because rotation is the missing control","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=en","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=en","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=en"},{"language":"es","title":"Una clave AWS filtrada sigue siendo acceso hasta que se rota y se borra","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=es","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=es","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=es"},{"language":"fr","title":"Une clé AWS exposée reste un accès tant qu’elle n’est pas supprimée","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=fr"},{"language":"pl","title":"Wyciekły klucz AWS to aktywny dostęp, dopóki go nie usuniesz","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=pl"},{"language":"ru","title":"Утёкший AWS-ключ — это действующий доступ, пока его не удалили","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ru"},{"language":"zh","title":"泄露的 AWS 密钥只要还能认证，就仍然是有效访问","html_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=ru","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ru","html":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ru","canonical":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ru","markdown":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=ru","json":"https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=ru","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}