Інциденти без паніки: що відомо, кого зачепило, що робити

Ця сторінка — точка входу до кластера «Інциденти». Тут зібрані матеріали, які допомагають зрозуміти, що насправді сталося, кого це стосується і які дії безпечні на момент перевірки. Жодних неперевірених висновків і жодного поспіху.

Повний розділ безпеки доступний за посиланням: Безпека Solana: спокійно, конкретно, перевірено.

Що охоплює цей кластер

Кластер «Інциденти» охоплює ситуації, коли порушується нормальне функціонування продукту, протоколу або постачальника послуг у екосистемі Solana. Це не про фішинг чи аудити смартконтрактів — ці теми розкриті в окремих матеріалах.

Тут зосереджені такі теми:

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

Кожен матеріал у кластері відповідає на одне конкретне запитання і веде до наступного кроку — а не намагається пояснити все одразу.

Що зазвичай хоче з’ясувати читач

Коли з’являється повідомлення про інцидент, виникає кілька типових запитань. Їх можна розділити на три групи.

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

• Чи підтверджений інцидент офіційними джерелами?
• Яка межа відомого: де закінчуються факти й починаються припущення?
• Чи є редакційна хронологія з чіткими етапами?

Це стосується мене?

• Чи використовував я цей продукт, протокол чи постачальника?
• Чи зачіпає інцидент саме мій тип гаманця чи застосунку?
• Чи є різниця між «продукт уражений» і «мої кошти під загрозою»?

Що робити зараз?

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

Короткий маршрут по темі

Якщо ви тільки-но побачили повідомлення про інцидент і не знаєте, з чого почати, прочитайте ці два матеріали.

Як читати повідомлення про злам і не поширювати неперевірені висновки — допоможе відокремити підтверджені факти від гіпотез і панічних пересилань. Підходить для будь-якого рівня підготовки.

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

Що читати далі

Коли ви зрозуміли базову картину й хочете розібратися, чи можна довіряти реакції команди, перейдіть до цих матеріалів.

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

Як зрозуміти, чи команда вже усунула причину, а не лише наслідок — пояснює різницю між тимчасовим патчем і фундаментальним виправленням. Допомагає не помилитися з висновком «все вже виправлено».

Як звіряти свіжість інформації

Інформація про інциденти швидко застаріває. Ось критерії, за якими редакція оцінює актуальність кожного матеріалу в кластері.

1. Джерело оновлення. Перевіряються офіційні security advisories, статусні сторінки проєктів, постмортеми команд і документація гаманців. Якщо жодне з цих джерел не містить нових даних, матеріал залишається без змін.
2. Межа знання. Якщо статус інциденту невідомий, редакція прямо пише про це замість припущень. Формулювання «на момент перевірки» вказує на межу актуальності.
3. Ризик дій. Будь-яка інструкція, наведена в матеріалах, перевіряється на безпеку: вона не може погіршити стан користувача. Дії, що потребують експертної оцінки, позначені окремо.
4. Дата наступної перевірки. Кожен матеріал, що залежить від поточного стану, містить орієнтовний період, після якого інформація потребує повторної перевірки. Конкретна дата не вказується, якщо її неможливо обґрунтувати на момент публікації.

Чого не робити під час інциденту

• Не поширювати неперевірені висновки, навіть якщо їх публікують великі акаунти.
• Не вводити seed-фразу в будь-які сторонні сервіси «для перевірки».
• Не виконувати команди терміналу, отримані з неперевірених джерел.
• Не перекладати відповідальність на себе: інцидент продукту — це не результат ваших помилок.
• Не робити різких дій з активами до того, як зрозумієте межу ураження.

Коли потрібна додаткова допомога

Зупиніться й зверніться до фахівця, якщо:

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

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

Редакція солана.укр