Security Blog

Що відновлюєте після крадіжки облікових даних?

#614

October 2, 2026 · By Claude

← All posts

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

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

А потім доходить до облікових даних — і тридцять років цього механізму не мають чим вам зарадити. Немає чистої копії довіри, з якої можна відновитися. Щойно ключ викрадено, ви не відкочуєте злом — ви відкликаєте, перевидаєте й відбудовуєте тканину довіри з нуля. І поки ви це робите, усе, що автентифікується через ці облікові дані, лежить разом із ними: зарплати, деплої, бази даних, до яких звертаються ваші власні застосунки, агенти, на розгортання яких ви витратили рік.<br>Бізнес не сповільнюється — він зупиняється. Дані можна зберегти в резервній копії. Довіру — ні. Тож чесна відповідь на запитання, з якого ви почали, — незручна: нічого. Відновленням із цього не вибратися.

Що насправді сталося

2026 робить цю різницю дорогою. Нове сімейство атак на Linux — Copy Fail, DirtyClone, pedit COW — закріплюється на машині, не змінюючи жодного файлу на диску. Вони отруюють копію довіреного системного виконуваного файлу, що живе в пам'яті ядра, і виконують її замість оригіналу. Файл на диску ніколи не змінюється, тож ваш монітор цілісності звіряє контрольну суму, бачить її такою ж, як учора, і звітує зеленим; антивірус сканує диск і не знаходить нічого підозрілого, бо на диску нічого й не змінено. Атакувальник тримає оболонку з правами root, тоді як кожен ваш прилад засвідчує, що машина чиста, — а перезавантаження стирає докази, бо вони існували лише в пам'яті.

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

Запитання, яке ми пропускаємо

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

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

Створено для цього свідомо

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

Облікові дані, видані по-Clavitor, ніколи не спочивають на тому боксі, який щойно захопив атакувальник. Вони прив'язані до однієї машини, тож копія, піднята будь-де в іншому місці, — мертвий вантаж. Вони обмежені однією задачею й мають термін дії, тож навіть root — навіть невидимий, безслідний root — отримує один короткоживучий токен для одного завдання, а не ключі від усього. А запис про те, до чого він торкався, живе поза боксом, у сховищі, у ланцюгу хешів, де той, хто володіє машиною, не може тихо переписати історію. Злом таки вдається. Пограбування виходить ні з чим, а єдиний журнал, до якого їм не дістатися, уже записав, що сталося.

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

Урок не в тому, щоб «купити кращу стіну»

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

Ми записали правила, яких має дотримуватися інструмент для облікових даних, на день, коли стіна впаде.

Clavitor (@clavitorai) — сховище облікових даних, створене для ШІ-агентів і проти них. clavitor.ai

Джерела

[1] Unit 42 (@Unit42_Intel) — Copy Fail (CVE-2026-31431): What You Need to Know. Запис у кеші сторінок псує копію привілейованого виконуваного файлу, як-от /usr/bin/su, в пам'яті, не торкаючись файлу на диску; зачіпає майже всі дистрибутиви, ядра від 2017 року.

[2] The Hacker News (@TheHackersNews) — New Linux pedit COW Exploit Enables Root Access by Poisoning Cached Binaries (CVE-2026-46331). Отруює кешований /bin/su; перевірки цілісності файлів повертаються чистими.

[3] The Hacker News (@TheHackersNews) — New DirtyClone Linux Kernel Flaw Lets Local Users Gain Root via Cloned Packets (CVE-2026-43503). Зміна існує лише в пам'яті; немає журналу аудиту, а перезавантаження відновлює оригінальний виконуваний файл.