Неочікуваний запит MFA: що робити, якщо ви не входили в обліковий запис

Головне, що варто запам’ятати

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

1. Відреагуйте на запит, який з'явився перед вами

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

Залиште автентифікатор увімкненим. Видалення застосунку, відключення робочого облікового запису або вимкнення MFA, щоб позбутися сповіщень, створює додаткові труднощі з доступом. Якщо запити продовжують надходити, зверніться до служби підтримки за перевіреним номером або через корпоративний портал і поясніть ситуацію. Ніколи не схвалюйте запит «як експеримент», щоб перевірити, що станеться.

2. Зрозумійте, про що свідчить і про що не свідчить неочікуваний запит

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

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

Джерела розділу: Цифрова ідентичність: вимоги до автентифікаторів і систем перевірки, SP 800-63B-4

3. Перевірте особу, яка пояснює причину сповіщення

Уявіть ситуацію: ви відхилили три запити. Вам телефонує людина, представляється співробітником ІТ-відділу і каже: «Ми блокуємо підозрілу сесію. Схваліть наступний запит, щоб ми могли завершити процедуру». Таке пояснення не робить запит вашим власним. Справжнє сповіщення та впевнений голос у слухавці цілком можуть бути частиною однієї атаки соціальної інженерії.

Завершіть небажану розмову та самостійно знайдіть контакт у корпоративному довіднику, на порталі підтримки або скористайтеся збереженим перевіреним номером. Запитайте офіційну команду підтримки, чи дійсно для вашого облікового запису потрібні якісь дії. Не використовуйте для перевірки номери телефонів, посилання або QR-коди, надані співрозмовником. Ніколи не диктуйте одноразові коди, коди відновлення або числа з чужого екрана входу.

Збільшити зображення · Знімок екрана гри · Англійський інтерфейс

1. Знайдіть офіційний довідник

   Скористайтеся корпоративним телефонним довідником для пошуку надійного контакту підтримки, перш ніж виконувати чутливий запит.

2. Не використовуйте надані номери

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

Джерела розділу: Microsoft Authenticator: поширені запитання та невідомі контакти

4. Дізнайтеся, який метод захисту використовує ваша організація

Термін MFA охоплює методи з різною стійкістю до обману. CISA рекомендує стійку до фішингу MFA та розглядає зіставлення чисел як проміжне вдосконалення там, де перехід ще неможливий. NIST відрізняє підтвердження поза основним каналом і коди, що передаються вручну, від автентифікації, криптографічно прив’язаної до легітимного сервісу. Практичне питання залишається тим самим: яку дію з обліковим записом ви дозволяєте?

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

Збільшити зображення

Джерела розділу: Впроваджуйте багатофакторну автентифікацію · Цифрова ідентичність: вимоги до автентифікаторів і систем перевірки, SP 800-63B-4 · Рекомендації CISA щодо стійкої до фішингу MFA та зіставлення чисел

5. Якщо ви вже схвалили запит — негайно повідомте про це

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

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

6. Надішліть короткий, інформативний звіт про інцидент

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

Приклад вигаданого звіту: «Близько 10:14 мій робочий автентифікатор показав чотири запити на вхід у корпоративний обліковий запис SSO. У цей час я редагував локальний документ і спроб входу не робив. Три запити я відхилив, один помилково схвалив. Після цього мені зателефонували з проханням підтвердити ще один запит. Я поклав слухавку й одразу набрав відомий номер служби підтримки».

• Точний час, часовий пояс, назва облікового запису та застосунку.
• Що саме ви робили безпосередньо перед першим сповіщенням.
• Приблизна кількість запитів та наявність сторонніх дзвінків.
• Що було схвалено, введено, відхилено чи передано (вкажіть сумніви).
• Безпечний спосіб зворотного зв'язку та назва пристрою.

7. Відпрацюйте сценарій тиску у грі The Social Engineer

У The Social Engineer показано ситуацію в офісі з повторними запитами Northline SSO, спробою маніпулятивного переконання, перевіркою через службу підтримки та надсиланням повідомлення про кіберінцидент. Це змодельовані рішення у вигаданій компанії. Сенс вправи полягає в тому, щоб чітко розмежувати сам запит на вхід, аргументи того, хто телефонує, та перевірену відповідь ІТ-підтримки перед вибором дії.

Цей посібник, інтерфейс платформи CyberPlay та гра The Social Engineer доступні українською мовою. У навчальному епізоді з MFA визначте неініційований запит, скористайтеся офіційним каналом зв'язку та надішліть коректне повідомлення про інцидент. На скриншоті гри наведено оригінальний англійський інтерфейс. Успішне проходження гри є навчальною практикою і не гарантує безпеки реального облікового запису. Воно також не доводить, що поведінка на робочому місці вже змінилася.

Збільшити зображення · Знімок екрана гри · Англійський інтерфейс

1. Відхиліть неініційований запит

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

2. Повідомте через офіційну підтримку

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

8. Перевірте рішення на новому прикладі

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

9. Зробіть безпечний алгоритм дій простим і зрозумілим

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

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

Відпрацюйте це рішення на практиці

Скористайтеся грою The Social Engineer, щоб відпрацювати описані в посібнику рішення. Посібник, інтерфейс CyberPlay та гра доступні українською мовою.

Джерела й додаткові матеріали

1. Цифрова ідентичність: вимоги до автентифікаторів і систем перевірки, SP 800-63B-4 — NIST. Переглянуто 2026-09-13
2. Впроваджуйте багатофакторну автентифікацію — CISA. Переглянуто 2026-09-13
3. Microsoft Authenticator: поширені запитання та невідомі контакти — Підтримка Microsoft. Переглянуто 2026-09-13
4. Рекомендації CISA щодо стійкої до фішингу MFA та зіставлення чисел — CISA / DHS. Переглянуто 2026-09-13

Досліджуйте далі

• Вправи із соціальної інженерії: підміна особи та перевірка платежів

  Практикуйте захист від соціальної інженерії: фальшивої ІТ-підтримки, зміни рахунків та підміни голосу. Використайте діалоги, перевірки й обговорення рішень.

  UK · 7 хв читання
• Ігри для протидії фішингу: перевіряйте запити та повідомляйте про підозри

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

  UK · 8 хв читання
• Пароль чи парольна фраза: як захистити робочі облікові записи

  Порівняйте паролі та парольні фрази, уникайте повторного використання, дізнайтеся про настанови NIST і користуйтеся схваленим менеджером паролів українською.

  UK · 8 хв читання
• Приклади фішингових листів для навчання: перевірка та повідомлення

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

  UK · 8 хв читання
• Навчання захисту від QR-фішингу: перевіряйте адресу призначення

  Навчайте перевіряти адреси QR-кодів на прикладах паркування, плакатів і входу до сервісів. Використайте попередній перегляд, незалежну перевірку та вправи.

  UK · 8 хв читання
• Безпечне використання ШІ на роботі: навчання щодо інструментів і даних

  Навчайте працівників безпечно користуватися ШІ: обирати інструменти, захищати дані, перевіряти відповіді та дозволи. Використайте вигадані приклади рішень.

  UK · 8 хв читання