Cards2All

Готовый набор · beginner · 30 карточек · около 10 минут

Утечка данных: 30 карточек для безопасного ответа

30 карточек: проверить уведомление, понять, какие данные затронуты, и защитить один важный аккаунт без паники.

Автор: Cards2All. Обновлено: 2026-09-02.

Начать с первой карточки

Цель короткой сессии

  • Для кого: Для человека без технической подготовки, который получил письмо об утечке или увидел такое сообщение в новостях и хочет отделить факты от паники и сделать один безопасный шаг.
  • Результат: После короткой сессии ученик проверит источник независимо от ссылки в письме, назовёт затронутые данные и аккаунты, защитит почту или один повторно использованный пароль, включит MFA и распознает фишинг на фоне инцидента.
  • Когда пригодится: 2 сентября 2026 года Google Trends показал точный beginner-запрос «what is a data breach», а Wikimedia Pageviews — рост интереса к статье Data breach; тот же конечный навык повторяется после любого будущего уведомления.
  • Следующий шаг: Сегодня пройти первые 6/30, не нажимать ссылку в письме и заполнить шесть полей: источник, дата, данные, аккаунт, безопасное действие, официальный контакт. Затем защитить только один приоритетный аккаунт и закрыть сессию. Завтра повторить только слабые карточки и перейти к отзыву сессий и MFA.

Источники и проверка

Материал проверен 2026-09-02. Статус: проверено по источникам.

Термины и определения

1. Утечка данных

Инцидент, при котором защищаемая информация была потеряна, раскрыта, изменена или получена без разрешения.

Пример: Ошибочно отправленный не тому адресату файл с персональными данными может быть утечкой без взлома сервера.

Примечание: Модуль 1/5 · Источники: NIST и ICO. «Утечка» описывает событие, а не доказывает вред каждому человеку.

2. Инцидент и утечка — одно и то же?

Нет. Инцидент — более широкое событие безопасности; утечка означает подтверждённую потерю конфиденциальности, целостности или доступности данных.

Пример: Сбой сайта может быть инцидентом без доказанного раскрытия данных.

Примечание: Модуль 1/5 · Не додумывайте утечку только по недоступности сервиса.

3. Три свойства данных

Конфиденциальность — кто увидел; целостность — что изменилось; доступность — можно ли данными пользоваться.

Пример: Чужой доступ к адресу нарушает конфиденциальность; подмена адреса — целостность.

Примечание: Модуль 1/5 · Источник: NIST. Один инцидент может затронуть несколько свойств.

4. «Мои данные затронуты» не равно «мой аккаунт захвачен»

Уведомление может подтверждать попадание записи в набор, но не факт входа злоумышленника в конкретный аккаунт.

Пример: Адрес электронной почты мог утечь, а текущий уникальный пароль — нет.

Примечание: Модуль 1/5 · Проверяйте именно типы данных и активность аккаунта.

5. Пять полей полезного уведомления

Что произошло, когда, какие данные и люди затронуты, что уже сделала организация и какой проверяемый шаг нужен человеку.

Пример: Фраза «мы расследуем» не заменяет список затронутых полей.

Примечание: Модуль 1/5 · Источник: ICO. Отделяйте известное от предварительного.

6. Первый шаг после уведомления: шесть полей

Назовите источник, дату, типы данных, затронутый аккаунт, одно безопасное действие и официальный контакт.

Пример: «Страница статуса; 2 сентября; email; почта; проверить сессии; support из приложения» — учебная схема.

Примечание: Модуль 1/5 · Видимый прогресс: 6/30. Не вносите пароль или личные данные в карточку.

7. Проверка независимо от письма

Наберите известный адрес сами или откройте приложение, затем найдите то же уведомление или страницу статуса.

Пример: Вместо кнопки «срочно защитить» в письме откройте account security из закладки.

Примечание: Модуль 2/5 · Источники: FTC и CISA. Письмо может быть копией реального инцидента.

8. Домен и имя отправителя

Отображаемое имя можно подделать; адрес и домен тоже нужно сверять с каналом, который уже был известен до письма.

Пример: Домен с лишней буквой может имитировать знакомый бренд.

Примечание: Модуль 2/5 · Не делайте вывод только по логотипу, стилю или фамилии в подписи.

9. Почему нельзя открывать вложение «с отчётом»?

Вложение или ссылка в неожиданном сообщении могут вести к краже данных или вредоносному файлу; нужные детали следует искать на официальной странице.

Пример: Сохраните тему и дату письма, но не открывайте непроверенный ZIP или PDF.

Примечание: Модуль 2/5 · Источник: CISA Recognize and Report Phishing.

10. Время события, обнаружения и уведомления

Это три разные даты: данные могли быть затронуты раньше, чем организация поняла и сообщила об этом.

Пример: «Доступ 1 июля; обнаружено 8 июля; уведомление 10 июля» задаёт временную шкалу.

Примечание: Модуль 2/5 · Не переносите дату новости на дату самого инцидента.

11. Тип данных определяет следующий шаг

Адрес email, пароль, токен сессии, резервный код и контактная запись не равнозначны; мера должна закрывать именно затронутый секрет или канал.

Пример: Если утёк повторно использованный пароль, его меняют во всех местах повтора; если утёк токен — отзывают сессии.

Примечание: Модуль 2/5 · Не меняйте всё подряд до прочтения поля «какие данные».

12. Сохранить уведомление без новой утечки

Сохраните дату, официальный URL и краткий список затронутых типов данных, но не пересылайте пароль, код, полный номер документа или адрес.

Пример: В учебной записи достаточно «email и токен сессии» без самих значений.

Примечание: Модуль 2/5 · Минимизация данных нужна и в личных заметках.

13. Почему почта часто первая?

Почтовый аккаунт часто получает ссылки для сброса других паролей; его защват может открыть путь к нескольким сервисам.

Пример: Перед сменой пароля магазина проверьте почту: сессии, recovery-адрес и MFA.

Примечание: Модуль 3/5 · Это приоритет общего плана, а не гарантия для любой ситуации.

14. Какой пароль менять сначала?

Тот, который указан как затронутый или повторялся на другом сайте; смену делают из самого сервиса, а не по ссылке в письме.

Пример: Если утёк старый пароль магазина и он повторялся в почте, создайте два разных новых пароля.

Примечание: Модуль 3/5 · Источники: FTC и CISA. Не восстанавливайте старое значение.

15. Уникальный пароль

Пароль, который не используется ни в одном другом аккаунте; утечка одного сервиса тогда не даёт тот же секрет для входа в другой.

Пример: «Фраза-для-почты» и отдельная «фраза-для-магазина» ограничивают повтор.

Примечание: Модуль 3/5 · Не храните реальные пароли в учебном наборе.

16. Менеджер паролей

Инструмент, который создаёт и хранит длинные уникальные пароли в защищённом хранилище и уменьшает необходимость запоминать их все.

Пример: Вместо одного повторяемого пароля менеджер может создать разные значения.

Примечание: Модуль 3/5 · Источник: CISA. Выбирайте известный и обновляемый инструмент.

17. Отзыв сессий

Команда «выйти на всех устройствах» или удаление неизвестного сеанса закрывает уже выданный доступ, который одна смена пароля может не прекратить.

Пример: После смены пароля проверьте recent sessions и завершите незнакомые.

Примечание: Модуль 3/5 · Название пункта отличается по сервисам; открывайте его из настроек.

18. MFA, или многофакторная аутентификация

Проверка входа более чем одним видом секрета, что снижает риск входа по одному украденному паролю.

Пример: После ввода пароля сервис может потребовать passkey, аппаратный ключ или код из приложения.

Примечание: Модуль 3/5 · Источники: CISA и NIST SP 800-63B. Фишингоустойчивый фактор предпочтительнее, если доступен.

19. Фишинг после публичной утечки

Злоумышленник может использовать название реального инцидента, чтобы сообщение о «проверке» выглядело правдоподобно.

Пример: После новости об утечке приходит звонок с требованием назвать код «для защиты».

Примечание: Модуль 4/5 · Источник: CISA. Точное знание темы не доказывает легитимность контакта.

20. Одноразовый код не передают другому человеку

Код подтверждает конкретную попытку входа; сообщив его звонящему, человек может одобрить чужой вход.

Пример: Если вы не запрашивали код, не диктуйте его «службе безопасности».

Примечание: Модуль 4/5 · Найдите официальный support сами, если нужна помощь.

21. Проверка recovery-данных

После восстановления доступа сверьте резервный email, телефон, MFA-методы, passkeys и резервные коды, чтобы не оставить чужой канал.

Пример: Незнакомый recovery-email удаляют до завершения смены пароля.

Примечание: Модуль 4/5 · Сохраните новые резервные коды вне карточек и переписки.

22. Журнал входов и уведомления

История сессий, новых устройств, изменений пароля и recovery-полей помогает найти признаки доступа после утечки.

Пример: Отметьте неизвестное устройство и завершите его сессию через настройки аккаунта.

Примечание: Модуль 4/5 · Геолокация по IP может быть неточной; оценивайте время, устройство и действие вместе.

23. Обновление устройства и приложения

Обновления закрывают известные уязвимости; их устанавливают из системных настроек или официального магазина, а не из вложения к письму об утечке.

Пример: Откройте Software Update на устройстве, а не «security patch.exe» из чата.

Примечание: Модуль 4/5 · Источник: CISA Secure Our World. Обновление не заменяет смену затронутого пароля.

24. Официальный канал помощи и сообщения

Если обнаружен чужой вход или злоупотребление данными, свяжитесь с сервисом через его приложение или самостоятельно набраный сайт; для кражи личности или киберпреступления используйте официальный местный канал.

Пример: Сначала закройте активную сессию, затем сохраните дату и номер обращения.

Примечание: Модуль 4/5 · Правила и органы различаются по странам; этот набор не выбирает конкретный орган за вас.

25. Нужно ли менять все пароли?

Не автоматически. Если пароли уникальны, меняют подтверждённо затронутый и повторённые значения, а затем включают MFA и проверяют сессии.

Пример: Утечка пароля одного форума не требует смены совсем другого уникального пароля.

Примечание: Модуль 5/5 · Конечный план снижает ошибки от паники и переутомления.

26. Утечка не доказывает кражу личности

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

Пример: Адрес email в утёкшем наборе не означает, что от вашего имени уже создан счёт.

Примечание: Модуль 5/5 · Не игнорируйте риск, но не превращайте возможность в свершившийся факт.

27. Секретные вопросы и другие recovery-ответы

Если в утечке были ответы для восстановления, замените их на новые случайные и уникальные значения в самом аккаунте.

Пример: Девичья фамилия матери не становится новым секретом, если она уже известна из публичных источников.

Примечание: Модуль 5/5 · Источник: FTC. Менеджер паролей может хранить случайные ответы как секреты.

28. Минимизация новых данных

При восстановлении передавайте только то, что нужно для официальной процедуры, и не публикуйте скриншот с адресом, телефоном, кодом или номером документа.

Пример: Для обсуждения с support вырежьте лишние поля и сохраните только номер обращения.

Примечание: Модуль 5/5 · Проверяйте, какие поля действительно обязательны.

29. Одна конечная десятиминутная сессия

Проверьте источник, назовите данные, защитите один приоритетный аккаунт, отзовите сессии, включите MFA и закройте страницу.

Пример: Таймер не создаёт срочность: он ограничивает бесконечное перечитывание новостей.

Примечание: Модуль 5/5 · Если есть активная атака или злоупотребление, безопасное действие важнее учебного таймера.

30. Схема «источник — дата — данные — аккаунт — действие — контакт»

Шесть вопросов: кто сообщает, когда произошло и было обнаружено, какие данные затронуты, какой аккаунт приоритетен, какое одно безопасное действие нужно и где официальный контакт.

Пример: После 30/30 заполните схему без пароля и других секретов, выполните один шаг и остановитесь.

Примечание: Модуль 5/5 · Видимый прогресс: 30/30. Завтра повторите только слабые карточки, затем перейдите к фишингу или passkeys. Нет streak, стыда и бесконечных проверок.

Сначала выберите близкую тему, затем — новый повод из другой области.