Понад 9300 витеклих ключів AWS залишалися активними роками

Сам факт появи ключа у відкритому репозиторії ще не доводить, що він і досі небезпечний. Серйозною активною загрозою він стає тоді, коли його не відкликали, він усе ще працює і має суттєві дозволи. У цьому дослідженні всі три умови нерідко збігалися.

Сотні корпоративних ключів давали повний контроль

Серед активних ключів, які вдалося пов’язати з корпоративними акаунтами, 817 належали компаніям. До цієї групи входили:

• 526 ключів root-акаунтів AWS;
• 242 ключі користувачів IAM, пов’язані з політикою AWS AdministratorAccess;
• 768 ключів загалом, що забезпечували повний адміністративний контроль над корпоративним акаунтом AWS.

Root-облікові дані — це найвищий рівень доступу, доступний клієнту AWS. Користувач IAM із політикою AdministratorAccess також може виконувати широкий спектр операцій у різних сервісах AWS. Чинний ключ із такими правами може відкрити шлях до захоплення акаунта, несанкціонованого створення ресурсів, доступу до даних або зловживань із хмарними рахунками.

Отже, проблема полягає не лише в дисципліні роботи з вихідним кодом, а й в управлінні дозволами та життєвим циклом облікових даних. Видалити ключ із видимого файлу недостатньо: якщо хтось уже скопіював секрет, акаунт залишається під загрозою. Ключ потрібно відкликати або замінити.

Hugging Face стало найбільшим окремим джерелом

На Hugging Face припало 8482 випадки оприлюднення облікових даних AWS — це найбільший окремий показник серед джерел, визначених у звіті. За даними Truffle Security, 17,9% цих AWS-облікових даних були root-ключами.

Цей результат узгоджується з ширшим скануванням публічних даних Hugging Face. Truffle Security повідомила, що перевірила 7,6 петабайта відкритих наборів даних і знайшла чинні облікові дані в тисячах із них. Це показує, що секрети можуть зберігатися не лише у звичайних репозиторіях програмного коду, а й у публічно поширюваних даних.

Для команд із кібербезпеки висновок очевидний: перевіряти лише актуальні репозиторії недостатньо. Ключі можуть залишатися в історії Git, артефактах збірки, образах контейнерів, реєстрах, опублікованих наборах даних і виводі CI — навіть після того, як розробники вважають, що вже видалили їх.

Багато ключів були дуже старими й майже не змінювалися

Медіанний вік облікових даних становив приблизно 1831 день, тобто близько п’яти років. Найстарішому ключу було 17,4 року. Лише 13,7% записів мали новіший ключ, пов’язаний із тим самим користувачем. Це свідчить, що більшість ключів не замінювали в межах звичайної процедури ротації.

Довгоживучі ключі збільшують час, протягом якого ними можуть скористатися сторонні, а також ускладнюють визначення відповідального власника. Вони можуть пережити зміну працівників, міграцію застосунків, очищення репозиторіїв і передачу операційних обов’язків іншій команді.

Тому вік ключа варто розглядати як сигнал ризику. Якщо ключ опинився у відкритому доступі кілька років тому, не можна автоматично вважати його застарілим: його потрібно перевірити, відкликати та дослідити, якщо власник не може підтвердити, що ключ більше не чинний.

Моніторинг витрат був рідкістю

Truffle Security змогла прочитати інформацію про акаунти 2754 організацій, але лише 262 із них мали налаштовані бюджетні сповіщення AWS.

Бюджетні сповіщення не замінюють відкликання ключів або виявлення атак, однак можуть рано попередити про створення дорогих ресурсів після компрометації — наприклад, для майнінгу криптовалют чи інших видів зловживань хмарною інфраструктурою. Якщо повідомлення не надходить людині, здатній швидко відреагувати, нетипові витрати можуть тривати й після захоплення акаунта.

Що вирішують сповіщення AWS — і чого вони не вирішують

У матеріалах описано механізми AWS, здатні виявляти розкриті ключі доступу, повідомляти про це клієнтів і застосовувати обмеження або карантинні заходи. Водночас чинність такої кількості перевірених ключів свідчить, що виявлення чи сповіщення не завжди призводили до швидкого відкликання або заміни ключів із боку клієнтів.

Виявлення — лише перший етап реагування на витік. Повна процедура має встановити власника ключа, визначити доступні йому ресурси та дозволи, перевірити можливі зловживання й анулювати ключ. Truffle Security характеризує власну перевірку як таку, що виконувалася лише для читання: дослідники перевіряли автентифікацію та метадані дозволів або акаунта, не змінюючи ресурси клієнтів. Ця методологія наведена зі слів Truffle Security і не підтверджена незалежно кожним із наданих джерел.

Що робити після витоку ключа AWS

1. Негайно відкликати або замінити ключ

Видаліть або вимкніть будь-які публічно оприлюднені облікові дані, а нові створюйте лише за потреби. Видалення секрету з репозиторію, файлу чи історії Git не анулює копії, які могли вже потрапити до сторонніх.

2. Відмовитися від root-ключів для щоденних операцій

Root-ключі AWS не слід використовувати для звичайного програмного доступу. Видаліть їх і переведіть робочі навантаження на контрольовані ідентичності з чітко обмеженими дозволами.

3. Перевірити дозволи та власника

Встановіть, до якого акаунта, користувача, сервісу й ресурсів належав ключ. Найперше перевіряйте ключі з root-привілеями, AdministratorAccess, широким доступом до даних або можливістю створювати інфраструктуру.

4. Провести розслідування до та після відкликання

Перегляньте активність автентифікації, записи CloudTrail, зміни IAM, новостворені ресурси та рахунки на ознаки підозрілої активності. Відкликання припиняє подальше використання ключа, але не показує, чи встигли ним скористатися до цього.

5. Замінити довгоживучі ключі короткостроковими ідентичностями

За можливості використовуйте короткострокові ролі IAM та ідентичності робочих навантажень замість постійних ключів доступу. Принцип найменших привілеїв зменшує шкоду від витоку.

6. Налаштувати бюджетні сповіщення та план реагування

Увімкніть сповіщення AWS Budgets і моніторинг аномалій витрат, а повідомлення спрямовуйте контактам, які можуть оперативно діяти. Фінансовий моніторинг — це додатковий запобіжник, а не заміна сканування секретів, ротації ключів і перевірки доступів.

Ширший урок для безпеки хмари

Найважливішим результатом дослідження стала не сама кількість секретів, а поєднання публічного розкриття, чинності, високих привілеїв, надмірного віку та слабкого моніторингу. Публічні сховища можуть зберігати облікові дані ще довго після того, як організація забула, де їх використовували, а скопійований ключ може залишатися корисним зловмиснику, доки його явно не відкличуть.

Для команд, що працюють із хмарною інфраструктурою, безпечніше виходити з простого правила: вважати кожен оприлюднений ключ AWS скомпрометованим, перевіряти, до чого він має доступ, негайно відкликати або замінювати його та переходити від довгоживучих ключів до короткострокових ідентичностей із мінімально необхідними дозволами.